Low activity during summer… I have started using a wireless numeric keyboard as an extra remote for controlling the lamps in my living room. I use the xbindkeys-tool in Linux to catch the key presses and with that I use the NetCat-program (nc) to send commands to an UDPCommandPort in the NetHomeServer. The shell command to toggle the reading lamp at my sofa becomes:

echo "call,SofaRead,toggle" | nc -u 127.0.0.1 8005

I use UDP to avoid the overhead of setting up a TCP-connection first.

Java sampler problems

The last couple of weeks have not been very productive. I started getting feedback that the audio based reception in NetHomeServer had started to hang for some users using Windows. It seems this behavior started with one of the latest Java updates. So I have spent a couple of weeks trying to hunt down this problem. To make things worse this behavior does not occur in any of my environments (One Linux and two Windows). Fortunately I have been getting great help from Walter Krämbring and David Näslund, who have received and tested numerous versions helping me to hunt down the problem. Thanks David and thanks Walter! I think I am almost there now finding a solution, but I am not sure yet. My impression is that the Java sound system is not the most reliable part of the environment. If anyone else has seen the problem that a TargetDataLine stops working after a couple of hours or that Java refuses to open a new TargetDataLine once the old one is closed, I would be glad to hear any suggestions on how to get around those problems – my current solutions are quite ugly…

Protocol Analyzer 1.1

Finally, Protocol Analyzer 1.1 is released! It contains a lot of goodies like the Pulse distribution view, Pulse re-anayzing and CUL support – see the release notes for all details. A big thanks to the beta testers for test and feedback! The release now also includes a manual for the program.

Bad reception

While fixing the transmission on CUL, I discovered that changing the data-rate settings on the CC1101-chip changed the behavior on the reception side as well. I don’t quite understand why, since I do not use any of the built in decoding features. But it awakened my hope of getting the reception to work. So I tried increasing the data rate setting to 10KBaud. The result was that it could now decode the fast pulses of the NexaL-protocol, but no other, slower protocol now worked. The signals of them now were drowned in noise instead. Deep sigh. I will have to release without support for reception.

CUL on MAC

The work with the CUL transmitter progresses. The Pronto Encoder now supports both the one time burst sequence and the repeated burst sequence of the Pronto Code, which are often used by IR protocols.
We have now also tested the CUL-support on MAC (Both a MAC Book Pro and a MacMini) and verified that it works.

Sending IR with CUL

I finally had a positive breakthrough with the CUL-stick. It has been working fine for sending to all supported protocols on the 433MHz band for controlling switches. But this band is also used for IR-extension devices such as the PowerMid, which is used to transmit IR remote control signals via radio. If I could tap in to their protocol, the CUL-stick could also be used as a generic IR-transmitter via a PowerMid! And now I finally got that to work. By modulating the mark pulses with 40KHz, the signal is received by the PowerMid receiver and sent as IR signals! This makes the CUL stick kind of a Swiss army knife of home control – both light switches and any IR remote controlled device can be managed!

Automatic Build

Now I have finally managed to get a complete tool chain for continuous automated builds of the NetHomeServer. I have been using Subversion, JUnit and Eclipse for quite a while, but always been building and running the JUnit tests from Eclipse. Now I have completed the tool chain with ant-scripts to do the builds and tests and finally Hudson to actually perform the builds and tests automatically every night. Hudson was a new experience for me, and quite a pleasant one. Hudson is a relatively new open source tool for automated builds and it was very easy to set up and configure on my Ubuntu-server. A really nice touch is that it can automatically download and install the Java-JDK:s and Ant-versions you need.

There is however one little detail that is very poorly documented, and that is how you configure the local URL-path when you run it as a daemon. You need to change it so it is not directly under the root-url in order to be able to access it via an Apache proxy (for example to http://myserver:8080/hudson). This is done by editing “/etc/default/Hudson” and adding the argument “--prefix=/hudson” in the HUDSON_ARGS-variable. It’s these little annoying things that take up 90% of the time when you are installing new stuff.

The automatic build are now transferred to the download page every night together with the test report for that build. The builds are made from the current state of the trunk, so they may be unstable and contain unfinished functions – but they are fresh :-).