If you’ve read any of my previous posts on the topic I’m trying to get OOK, FSK and potentially PPM (Differential Pulse Position Modulation) working in the Linux kernel with the HopeRF RFM12B adapter. This is mostly for ARM SBC/SoC type situations like the RaspberryPi or beaglebone.
The intention here is to allow you to easily intercept, and transmit consumer wireless signals on the 434/868 MHz bands. There are existing ways to do this. However they all appear to depend on the Jeenode or at least an atmega chip running JeeLib.
I want to remove the dependency on the atmega, and yet still exploit the RFM12B to provide OOK/FSK transmission. Right now I’m adapting the existing RFM12B-Linux module to allow sending and receiving OOK signals, I’m also adding in the code to interact with specific defined devices. So far my thoughts are that it shouldn’t be too hard to have drivers for multiple devices in the module.
I thought best to do a link dump of everything that is currently important to this endeavour;
After merging someone else’s OOK sending efforts. I’m not too sure that listening for OOK and FSK is really important. After all an SDR can happily listen across the frequencies and decode the signals.
I unfortunately get very little time to work on this, or other projects on this blog but try to keep it updated with my experiments from time to time. Once I have my Salus under control I plan to release the branch on github. Until then I get a little time here and there to experiment. My latest outcomes have been hampered by insufficient power to my Pi3. There have also been some issues with transmitting on the 868 band.
I’ve been busying myself with fixing up and adapting the RFM12B Linux driver. My first thought was simply to give people support for sending and listening for OOK signals as an extension, then taking the device support in the rtl_433 decoder to extend RFM12B driver to include lots of OOK device support for things like weather stations and energy monitors.
JeeLib already does most of this work on Arduino so for the most part this is simply a matter of joining lots and lots of code together from different places and making sure it sits right. I’ve decided that in order to do this it would probably be better to re-write the driver while trying to fix some of the original driver’s TODO list along the way.
The driver will loosely allow :-
- Compatibility with the original RFM12B driver & original JeeLib compatibility.
- Send OOK, FSK messages to devices.
- Listen for OOK, FSK messages from devices.
- Set tuning to a specific frequency.
Continue reading →
Fitted the Salus RT500RF today, this wasn’t such a difficult job but I did blow two fuses following bad advice. The wiring of my Vaillant Turbomax doesn’t require bridging the COM and Live as suggested in many online videos, nor do I need to add a LOAD resistor between pins 4 and 5 on the boiler.
Here’s a simple diagram to demonstrate how to connect the Salus RT500RF to a Vaillant. Now simply when pins 3 & 4 of the Vaillant are bridged they will start the boiler up. An optional pipe thermostat to switch the boiler off if the pipe overheats can be inserted in between pins 3 on the Vaillant and N/O on the Salus RT500RF.
Now I’m getting ready to start sniffing the airwaves with my SDR and my RFM12B to see what I can do. All I really want is to set/get the current state of the boiler.
Thanks to impshum digging around with epic google foo I found the correct GPIO_BASE for the Raspberry Pi B2. Raspberry Pi used to have a peripheral base address of 0x20000000 now it’s 0x37000000 on the B2, so the GPIO peripheral address is 0x37200000 which has broken the odd GPIO based product (including the HotPi). I’ve added a pull request to RFM12B-Linux and that should be that. I still need to merge in changes for OOK and see if that works and of course, figure out how to set the frequency to listen/transmit on.
RFM12B’s will soon become a must add hardware to the Raspberry Pi, I just need to get that software working :). It’s a great piece of kit, and the code already in github is a good jumping off point. I’ve merged in a OOK sender fork, and I’ll be adding code to put the device into OOK listen mode. All of this controlled via ioctl. Essentially with the little RFM12B’s hooked directly into the Raspberry Pi GPIO port’s SPI pins you’ll have the ability to mess with anything out there, which uses 433/434MHz or 315MHz if you’re in the US, or 915MHz or 868MHz whatever HopeRF board matches with your locations radio standards.
At present I’m looking at getting the OWL to work because I already understand most of that. Next I’ll be looking at getting RF light sockets, lightwaveRF devices, indoor/outdoor weather sensors and even doorbells into the supported devices list.
The Owl energy monitor uses OOK/ASK via the Oregon Scientific v3 protocol. It looks like I might have to hardware hack my RFM12Bs to work with this protocol according to this article… Not ideal.
Receiving OOKASK with a modified RFM12B – JeeLabs Café – JeeLabs . net.
Although it seems there’s a branch of RFM12B-Linux which can do OOK already. I’m not entirely sure how this is going to work out, but I’ll keep posting.
I found some problems with RFM12B Linux, specifically it doesn’t work at all on the Raspberry Pi B+ 2. I’ve created an issue for this but I might be able to fix it if I can get some tinkering time. In the mean time I’m testing things with the original model B.
I have an Owl energy monitor model CM160, which has been mostly just acting as a real time monitor. In order to really USE the device I’m going to need to connect it to one of my running computers. At first I was using Eagle OWL on github. However it requires me keeping the LCD receiver and I want to eventually get rid of that, mostly because the only useful thing about it, the thermometer isn’t accessible over USB.
I decided that I should start experimenting around the 434MHz band with my SDR’s and see what I could come up with. Continue reading →
I’ve started building a mesh network in C++, it’s a small library intended for use on Raspberry Pi and Arduino. Currently I want to support one kind of radio, an NRF24L01+ which you can get pretty cheap on ebay.
These radios provide us with a Layer 1 (Physical) of a OSI network but to build a functional mesh network we need a Layer 2 (Data link, addressing) and Layer 3 (Packets), once we have those two layers we need a Layer 4 (Segments, connection management) then onto the final layer, Layer 5 (Data).
Continue reading →
The stock from the kickstarter has run dry a long time ago and we’re now shipping a slow methodical number of units via the pi hut. We’re running out of green boards now, all new boards are red, and new orders will start to come through that way.
I recently published a new page for the HotPi and the new User Manual. You can get both over on this page.
I’m going to be designing a new small board or two which will fit in to the range of HotPi products. This should take 1-2 months to get back from manufacture and I’ll keep the blog updated along the way.