Porting MySensors to work with the RadioHead library
-
Hi guys,
I have received my Moteinos and anarduinos with RFM69HW radios. The anarduino webpage recommends a radio library called RadioHead which supports multiple radio tips and provides a common API for communication. http://www.airspayce.com/mikem/arduino/RadioHead/
It even supports quite complex things such as mesh networks. It currently supports the following radios:
- RH_RF22 Works with Hope-RF RF22B and RF23B based transceivers, and compatible chips and modules, including the RFM22B transceiver module. Supports GFSK, FSK and OOK. Access to other chip features such as on-chip temperature measurement, analog-digital converter, transmitter power control etc is also provided.
- RH_RF69 Works with Hope-RF RF69B based radio modules, such as the RFM69 module, (as used on the excellent Moteino and Moteino-USB boards from LowPowerLab http://lowpowerlab.com/moteino/) and compatible chips and modules such as RFM69W, RFM69HW, RFM69CW, RFM69HCW (Semtech SX1231, SX1231H). Also works with Anarduino MiniWireless -CW and -HW boards http://www.anarduino.com/miniwireless/ including the marvellous high powered MinWireless-HW (with 20dBm output for excelent range). Supports GFSK, FSK.
- RH_NRF24 Works with Nordic nRF24 based 2.4GHz radio modules, such as nRF24L01 and others. Also works with Hope-RF RFM73 and compatible devices (such as BK2423). nRF24L01 and RFM73 can interoperate with each other.
- RH_NRF905 Works with Nordic nRF905 based 433/868/915 MHz radio modules.
- RH_RF95 Works with Semtech SX1276/77/78 and HopeRF RFM95/96/97/98 and other similar LoRa capable radios. Supports Long Range (LoRa) with spread spectrum frequency hopping, large payloads etc. FSK/GFSK/OOK modes are not (yet) supported.
- RH_ASK Works with a range of inexpensive ASK (amplitude shift keying) RF transceivers such as RX-B1 (also known as ST-RX04-ASK) receiver; TX-C1 transmitter and DR3100 transceiver; FS1000A/XY-MK-5V transceiver; HopeRF RFM83C / RFM85. Supports ASK (OOK).
- RH_Serial Works with RS232, RS422, RS485, RS488 and other point-to-point and multidropped serial connections, or with TTL serial UARTs such as those on Arduino and many other processors, or with data radios with a serial port interface. RH_Serial23 provides packetization and error detection over any hardware or virtual serial connection.
- RH_TCP For use with simulated sketches compiled and running on Linux. Works with tools/etherSimulator.pl to pass messages between simulated sketches, allowing testing of Manager classes on Linux and without need for real radios or other transport hardware.
``
Seeing as the radio that is currently supported by MySensors is also supported by RadioHead I was wondering if anyone was interested in helping me porting MySensors to work with the RadioHead library. This will greatly increase the versatility of the MySensors library and magically allow it to work with a range of different radios :-).
I have briefly looked at the MySensors source code and it looks like most of the changes have to be done in MySensors.h and .cpp files.
I am willing to take a stab at it, but as everyone else I am limited on time. Still, it looks like it should not be a very difficult task. As discussed in another thread, it should be sufficient either to subclass the new radio library and replace a bunch of function calls, or drop the subclassing altogether and simply use the radio library as a regular included library.
The obvious difficulty comes soon as MySensors requires a function that is not available in the new radio library. However, seeing as MySensors is a pretty high-level library, and the API support from radioHead seems quite good, I suspect it should be possible to get around any such problems.
Anyway, I'm thinking of creating a branch of the library and spending a few hours trying to port it and get some basic functionality to work. Is anyone else is any value in this it would be great to have some help :-)
Scratch my previous messages. I took a new look at the documentation and there appears to be a function setMode which can set the radio to TX, RX, and idle. I think the idle mode is as close as you come to sleeping, and I know that several of the drivers have a function called setIdleMode which you can use to define how the radio sleeps. This means that we can initialise the sleep function in the same way as we initialise the the other radio specific parameters (e.g. power and frequency), and then simply set the radio to the generic idle mode when sleeping.
-
Just a small update on my effort to get RadioHead & MySensors working with nRF24L01+...
I managed to get the node configured correctly using the MySensors 'defaults'.
I see data getting sent over the air (as my sniffer captures it). The only data on air, captured by Wireshark, is:ff:7e:01:00:ff:7e:00:52:00:01:01:00 ff:7e:02:00:ff:7e:00:53:00:01:01:00 ff:7e:03:00:ff:7e:00:54:00:01:01:00 ff:7e:04:00:ff:7e:00:55:00:01:01:00 etc.Roughly 4 seconds apart.
I have to dive deeper into the protocol , but I suspect this is the node sending broadcasting requests to find a parent.
The gateway doesn't acknowledge these broadcasts yet...
Fixed a few small issues in the nRF24 driver along the way (see https://github.com/Yveaux/RadioHead/commits/MySensors/RadioHead/RH_NRF24.cpp)
Seems like I'm almost there!Some things I miss in the library:
- Normally the nRF24 changes its destination address when sending to the destination's node address. The current driver/RadioHead implementation just always broadcasts and the header of the data determines which node the data is really for. This means any node within range will always have to process all messages coming in to determine if they are meant for it or not. From a generic driver point-of-view I understand this approach, but it ignores powerful functionality of the nRF24. As the nRF24 is still the main radio target for the MySensors library we might have to think about a solution.
- The library does not use the auto-acknowledge feature of the nRF24 but instead seems to retry on application level. Another nice feauture of the nRF24 which remains unused...
-
I would guess it is a arp request. Weird that it does not use the radio properly, I think both addressing and retransmission works well with rf69.
-
Using auto-ack would be impossible (i think) using the in radioheads mesh-setup where every message basically is a broadcast.
I wondoer if it would it be possible to implement a mySensors class similar to RHMesh which actually works like MySensors do today using a star-topology and direct-addressed messages?
-
Using auto-ack would be impossible (i think) using the in radioheads mesh-setup where every message basically is a broadcast.
I wondoer if it would it be possible to implement a mySensors class similar to RHMesh which actually works like MySensors do today using a star-topology and direct-addressed messages?
radiohead uses direct messaging, with an arp protocol and route discovery to build local routing tables, much as original mysensors. At least as far as I understand it.
Do you use the same library in both the sensor and gateway? It won't work of you mix network layer protocols.
-
radiohead uses direct messaging, with an arp protocol and route discovery to build local routing tables, much as original mysensors. At least as far as I understand it.
Do you use the same library in both the sensor and gateway? It won't work of you mix network layer protocols.
-
@Yveaux said:
ff:7e:01:00:ff:7e:00:52:00:01:01:00
Ok, read a bit through the docs. Apparently this is what is sent:
RHDatagram: ff:7e:01:00 (TO:FROM:ID:FLAGS) RHRouter: ff:7e:00:52:00 (DEST:SOURCE:HOPS:ID:FLAGS) RHMesh: 01:01:00 (ROUTE_DISCOVERY_REQUEST:<RESERVED>:DEST)Therefore the destination and source address are sent TWICE (destination even 3 times with nRF24, as the destination address is part of the nRF24 header). An ID byte (incremented with each message sent) is also present in RHDatagram & RHRouter.
After the route is known, sending through RHMesh still requires 1 byte to indicate application payload is transmitted.
For short, Every message will require 10 bytes header, at least, to which the MySensors payload is added (including its own header of currently 4 bytes) giving at least 14 bytes overhead of 32 bytes total.
To me this feels like too much.... -
@hek Maybe we should just use reliable datagram. The ms header could contain just "source, destination, and last", and rhreliabledatagram deals with hop by hop ack and addressing.
@kolaf Just because of the size of the header?
I would prefer to use the RadioHead library also for routing, but maybe the current implementation can be made more efficient, in terms of header length and also code space.
Currently I can barely fit in a simple sensor example and Ethernet gateway also gives warning about ram usage... -
@Yveaux Good to hear that it is working out for you. I'm very curious to see whether you can get my version of the library working with your radio.
I have posted on the Radiohead group to see whether they can implement a generic sleep function in the driver or in the manager. This would make it much easier for us to put everything to sleep when required. Short of that the only reasonable solution I can see to fix this is to create a sleep function in the sensor source code and pass this as a parameter to the library. Alternatively we can build a different sleep functions in the library, but I guess this will cause the same problems as you talked about earlier with bringing in a lot of code we do not need.
@kolaf said:
I'm very curious to see whether you can get my version of the library working with your radio.
Got it to work with nRF24!
Still some issues every now and then and I have to verify the radio config but messages are exchanged between node & gateway, using RHMesh.Can't believe I ran into the same trap again as with the CRC8 calculation (remember @hek ?)
sizeof(message) in MySensor::sendWrite is 33 bytes, which is one byte more than nRF24 can send, causing all transmissions to fail...See my changes here: https://github.com/Yveaux/Arduino/commits/radiohead_port
-
@kolaf said:
I'm very curious to see whether you can get my version of the library working with your radio.
Got it to work with nRF24!
Still some issues every now and then and I have to verify the radio config but messages are exchanged between node & gateway, using RHMesh.Can't believe I ran into the same trap again as with the CRC8 calculation (remember @hek ?)
sizeof(message) in MySensor::sendWrite is 33 bytes, which is one byte more than nRF24 can send, causing all transmissions to fail...See my changes here: https://github.com/Yveaux/Arduino/commits/radiohead_port
-
@Yveaux maybe I could give you write access to my repository. Will be much easier if we are working on the same thing, less hassle with keeping up to date.
@kolaf OK, fine, but it's working now so I don't plan on much changes anymore.
Could you merge all 1.4 changes to your fork? I feel it's quite running behind.
Next I'll focus on a Wireshark dissector, as I'm not convinced everything on air is needed/correct...
It would be great BTW if the sniffer would work with the Radiohead drivers, so it supports different radios.... -
I pulled in the latest eight commits, merged, and pushed. I think I should be completely up-to-date with the development branch.
-
@kolaf OK, fine, but it's working now so I don't plan on much changes anymore.
Could you merge all 1.4 changes to your fork? I feel it's quite running behind.
Next I'll focus on a Wireshark dissector, as I'm not convinced everything on air is needed/correct...
It would be great BTW if the sniffer would work with the Radiohead drivers, so it supports different radios.... -
Memory is usually not a big problem. When I turn off debug messages a normal actuator (e.g. DimmableLED) produces the following.
Sketch uses 11,868 bytes (36%) of program storage space. Maximum is 32,256 bytes. Global variables use 423 bytes (20%) of dynamic memory, leaving 1,625 bytes for local variables. Maximum is 2,048 bytes.But if you start combining sensors using external libraries such as OneWire, LEDDisplay I guess it adds up. The RadioHead library is very well written and would probably not add much overhead.
Inclusion mode is only handled between gateway and controller so it would not be affected.
Gateway would probably not need much changed. But the MyMessage class would need some tweaking lifting out the routing part.
RadioHead library does not store any routing info in eeprom so everytime a node is powered up it need to rebuild this.@hek said:
RadioHead library does not store any routing info in eeprom so everytime a node is powered up it need to rebuild this.
That's beneficial in terms of available EEPROM space for other purposes - but would be interesting to see the shit-storm after a power-outage when all nodes power-up at the same time and need to rebuild the entire network tree from scratch?
-
Using auto-ack would be impossible (i think) using the in radioheads mesh-setup where every message basically is a broadcast.
I wondoer if it would it be possible to implement a mySensors class similar to RHMesh which actually works like MySensors do today using a star-topology and direct-addressed messages?
@hek said:
I wondoer if it would it be possible to implement a mySensors class similar to RHMesh which actually works like MySensors do today using a star-topology and direct-addressed messages?
@Kolaf said:
@hek Maybe we should just use reliable datagram. The ms header could contain just "source, destination, and last", and rhreliabledatagram deals with hop by hop ack and addressing.
@Yveaux said:
I would prefer to use the RadioHead library also for routing, but maybe the current implementation can be made more efficient, in terms of header length and also code space.
Currently I can barely fit in a simple sensor example and Ethernet gateway also gives warning about ram usage...Just a thought (I did NOT review the entire RH code) - from the RH documentation it sounds like we could use the RH Drivers without using any of the RH Managers - keeping routing etc. within MySensors responsibility.
Just checking as it appears that @kolaf and @Yveaux have spent significant time reviewing the code and I would want to understand if that's an option or a totally stupid idea :) -
@hek said:
I wondoer if it would it be possible to implement a mySensors class similar to RHMesh which actually works like MySensors do today using a star-topology and direct-addressed messages?
@Kolaf said:
@hek Maybe we should just use reliable datagram. The ms header could contain just "source, destination, and last", and rhreliabledatagram deals with hop by hop ack and addressing.
@Yveaux said:
I would prefer to use the RadioHead library also for routing, but maybe the current implementation can be made more efficient, in terms of header length and also code space.
Currently I can barely fit in a simple sensor example and Ethernet gateway also gives warning about ram usage...Just a thought (I did NOT review the entire RH code) - from the RH documentation it sounds like we could use the RH Drivers without using any of the RH Managers - keeping routing etc. within MySensors responsibility.
Just checking as it appears that @kolaf and @Yveaux have spent significant time reviewing the code and I would want to understand if that's an option or a totally stupid idea :)@ToSa It is definitely not a stupid idea, it is a variation of what I suggested previously which you quoted in your post (using the reliable datagram manager instead). It is a question of the abstraction level we want to use. Personally I prefer to use a library where everything is built in and that has widespread use. This gives us much more features for "free", and depending on the user base also a lot more testing. However, it turns out that not everything is perfect. The header is too big, and the library is perhaps not as efficient as it could be.
This boils down to whether we should do things more efficiently ourselves, or try to fix the library, either officially or unofficially. It looks like the maintainer of the project is very open to suggestions. In fact, I just saw a post where he said he had implemented a generic powerdown mode for all the drivers that I suggested a few days ago. My guess is that if we work with him we could get a lean and mean radio library which could benefit both the MySensors project and the Arduino community as a whole. There appears to be people here with quite good radio knowledge, so think this could be a very powerful combination. Still, it is a question of time, effort, and priorities...
