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 :-).

More eyes

I have now lured another developer into the project ;-). Peter is a professional WEB-developer and has already begun on a very interesting new function in the HomeManager, I hope to be able to report more when the implementation progresses…

It is always good to get a fresh pair of eyes on the code. Peter immediately started harassing me about the unorganized package structure and the unfinished ant build scripts – and of course he is right. It is easy to get lazy when you are the only one roaming around in the code. So I have spent some time on house-cleaning the code now and it has improved the quality and readability. Thanks Peter.

Beta Testing Analyzer

The ProtocolAnalyzer 1.1 is finally ready for beta testing. I am aiming for supporting Windows, Linux and Mac OS X in this release. A group of active users have agreed to help me with the testing, and they have now started using it (and started giving feedback).

I have tried to find users that cover the main areas of OS and hardware like Windows, Linux, Mac, UPM-based samplers and CUL-transceiver.

MAC OS X

I am now working on a new release of the Analyzer. My goal is to include support for MAC OS X in this release, and I am currently getting help in solving the problems that surface in that OS. The old Java promise “Write once – run everywhere” is not entirely true… There are still some problems with both SWT and the sound samplings. Hopefully we will have these problems solved soon so beta testing can begin.

I have also discovered that the hardware modification of the UPM-thermometer does not work well with some USB-sound cards. I have received good feedback and alternative connections from users (thanks Walter) and I will update the descriptions on the site.

UPM Checksum

A while ago I discovered four extra bits in the UPM temperature RF protocol. Two of the bits are sequence counters which simply adds one for each message in the three message bursts sent by the sensors. The other two bits seemed to be some kind of checksum. I have had some reports of people getting bad readings sometimes, so I finally took the time to figure the checksum out. After a bit of experimenting and analyzing, I finally managed to decode it: Bit 0 is all even bits in the message XOR:ed together and bit 1 is all the odd bits. So now bad messages will not be reported from the receiver any more!

This is SO frustrating. I spent the day rewriting the CUL firmware so it sends the USB data more directly via the hardware, bypassing the higher level USB print functions. To no use it seems. The received pulse lengths still vary way too much, so the USB overhead was not the problem. The problem seems to be worse for short pulses, which makes CUL useless for at least the NexaL protocol.

I may have to release CUL-support with only sending enabled, I think it will only annoy people if I include reception and it works bad...

This feels like a lot of time wasted.

Ok, still no real luck in getting a better reception from the CUL-stick. I have exposed some of the radio parameters of the receiver circuit in the Protocol Analyzer settings, so I can try different settings easier, but I have not managed to get very much better signal.
The only theory I have left is that the USB sending routines spend too much time in interrupt disabled mode so it disturbs the interrupt driven sampling. So the last thing I will try is to bypass the higher level sending functions and program closer to the metal of the CPU to send the data. If does not work, I think I will give up the CUL for reception.