Obviously my software works well to receive messages from the radiator controllers if they are just sent sporadically – every now and then.
But the software is unable to receive sequences of messages, in case they are sent directly one after the other, without temporal gap. In fact, the Room Unit sents sequences of messages in case the temperature of a zone has to change.
Why does the software fail?
Because it tries to read one message into the 64 byte FIFO receive buffer. As it is not possible to find out how long the message will be (without decoding it), the software just reads until the 64 bytes are read. And this is fatal, as in this case the software already reads the beginning (e.g. the RF preamble of alternating “1” and “0”) from the subsequent message.
66 55 56 55 2B 2B 52 B2 AD 53 4A CD 52 B5 55 55 55 55 55 55 55 4C B5 2C AB 4B 4A B5 2C AB 32 CA B2 B5 4B 2C D2 B4 CD 59 55
- Alternative #1: Forget to read messages in the FIFO buffer and decode after that, instead do “direct stream processing”, bit by bit ?
- Alternative #2: Fill the FIFO buffer byte by byte, and somehow try to find out when the complete message is read, then (very quickly) process the message and receive the next message using the RF receiver. The problem is that it takes some amount of time to decode the message and send the result to the client – probably too much time so we miss the RF preamble of the subsequent message.
The electronic radiator controllers in my house send out the current temperature every now and then. I receive this messages with my CC1101 based hardware solution and needed a solution how to graph diagrams that show the room temperature over time of day.
Librato is a cloud service provider that allows me to visualize this metrics in beautiful charts … in just a few minute’s time! It is really awesome how fast it was able to compose a dashboard using the charts I created for temperature values and the received signal strengh (RSSI) of the radiator controller as sender of the data.
I used python (librato-python) to send the metrics up to Librato:
api = librato.connect(“firstname.lastname@example.org”, “some_api_key”, sanitizer=librato.sanitize_metric_name)
q = api.new_queue()
q.add(“RSSI_” + controller[deviceId], convertRSSI(rssi))
Librato provides even more, check out their website at https://www.librato.com
Check out his picture of my dashboard
What can you see? In some rooms, at night the temperature slightly goes down from 21°C to approx. 19 °C. In the morning at 7am, the central heating controller puts it up to 21°C again, and 23°C in the bathroom.
Now that we are in the middle of autumn in Germany, and the daylight gets less and less, I decided to re-activate this little project of mine.
First thing was to update my Raspberry Pi (1) to Raspbian “Jessie”.
First check of my CC1101 Socket Driver Stack – and: Of course, it did not work.
Reason was that with Raspbian “Jessie” the way to enable the SPI kernel driver has changed. You can enable it using the “Advanced options” in the “raspi-config” configuration tool. Check out the description here: http://www.raspberrypi-spy.co.uk/2014/08/enabling-the-spi-interface-on-the-raspberry-pi/
Okay, after a reboot
- lsmod shows the SPI kernel driver spi_bcm2835
- The device files /dev/spidev0.0 and /dev/spidev0.1 exist
After that, the CC1101 Socket Driver Stack still did not work. Nothing was received over the air. Doing some analysis revealed that the ioctl calls responsible for the SPI data transfers between RPi and CC1101 failed.
Reason was that Raspbian “Jessie” uses a newer kernel than “Wheezy” and that the main ioctl message structure got a new field named “pad”
After I did take some more care to initialize this message structure in the code, everything worked will again.
And now the bad new: When analyzing the issue, I also killed my cross-compile installation on Mac OS. It still does not work until now 😦
I played around a little bit with iMovie and created this video showing the hardware devices I use for this project.
The picture shows the board plugged into GPIO expansion headers of the Raspberry Pi. The question was: Will the “new” hardware work with the “old” software controlling the CC1101 and responsible for receiving the RF messages? Well, only partly. The SPI communication worked directly without any changes neccessary. But, not a single RF message was received by this “new” hardware. The reason is, that the Anaren A1101R08A-EM1 evaluation module uses a 27 MHz crystal osciallator, while the previous hardware and also the RFBee used a 26 MHz crystal oscillator. All my calculations regarding the frequencies (frequency related configuration registers in the CC1101) where of course based on 26 MHz, and had to be recalculated. After having done that, everything worked pretty well.
Message from socket: 1810755110755130C903000849EF -81dBm
Message from socket: 1800A20100A20130C9030008CCD2 -66dBm
Message from socket: 1810755132BC3F10600301FF0171 -82dBm
Message from socket: 1810755132BC3F2309030101F4C0 -82dBm
Message from socket: 1810751A32BC3F315002010098 -79dBm
Message from socket: 1632BC3F0B1F09030008205F -79dBm
Message from socket: 1632B44AE21F09030008574E -73dBm
Message from socket: 1800A1E2FFFFFF10600301FF01F4 -74dBm
Message from socket: 181071F91071F930C9030008CC24 -68dBm
Message from socket: 181071E8FFFFFF23090302083415 -50dBm
Message from socket: 181071E532B44A3150020100CE -80dBm
Message from socket: 1810755132BC3F10600301FF0171 -81dBm
Message from socket: 1800A20132B44A230903010834A9 -66dBm
Message from socket: 1810751A32BC3F2309030101F4F7 -81dBm
This is how the board looks like after soldering the two plug connectors and the GPI connector for the Raspberry Pi. Can’t wait to check if my software will work it …
BTW: I still have one PCB left and also the required plug connectors and a GPIO socket. So, if you like to have it please contact me and we can talk about a fair compensation.
Although it is not in production yet, Elektor PCB Service has made available a first picture of the PCB I designed a few days before in Eagle. I am really excited and wonder if everything will work as expected … as soon I hold it in my hands.
On the right side you can see the holes for the 2×13 pin socket for putting the PCB on the Raspberry PI’s GPIO header, while on the left side you can see the holes for the two Samtec TFM-110-01-L-D-A headers.