2009-11-21

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.

2009-11-19


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.

2009-09-08



Ok, I have finally finished the Pulse Length Distribution View in the ProtocolAnalyzer. It's like a spectrum analyzer for the pulse lengths of a signal. It's really useful when determining the lengths and tolerances for pulses in a decoder.

It also shows the current problems I have with the CUL-receiver. The two pictures are from the same signal (Nexa). The top one is collected with the CUL-stick and the one below via the AudioSampler via an UPM-receiver. The signal received with CUL is all over the place. I still don't know what the problem really is. There seems to be a big variation in the received pulse lengths from the CUL-Stick.

2009-09-01

Sending

I finally think I cracked the sending problem! It was not a timing problem, it was the transmitter circuit that was in a bad state due to wrong initializing.  Now the protocol encoders seem to work with the CUL-Device (at least X10 and Nexa which I have tried).

2009-08-31

Almost there

Ok, I have finally managed to control the lights (X10) via the CUL-device and NetHomeServer. There seems to be some kind of timing problem when sending the data to the device. I am not sure what the problem is, but it might be the "command framwork"  I am using that cannot handle high data rates. I might have to have some kind of acknowledge sceme from the CUL-device to slow down the transmission.

2009-08-27

CUL-Transmission


I am currently working with adding support for the CUL-Transceiver ( BusWare ) for NetHomeServer and ProtocolAnalyzer. Unfortunately this also means writing firmware for the stick. I just finished first version of firmware which can both receive and transmit.

The low level interface to the transceiver is a serial port, so to test it I connect with HyperTeminal and Type:
A03E81388
This adds a pulse to the transmit buffer with the length 03E8 (=1000 uS) and a space of 1388 (=5000 uS)
Then I type:
S05
Which sends the transmit buffer 5 times. This gave the above result from the ProtocolAnalyzer (connected to an UPM-Receiver)
It works!!! Currently no error checking, so there is work left to do, but now I will write the NetHomeServer-port so I can test sending real protocol messages!