Porting MySensors to work with the RadioHead library
-
Just (2)
-
Good. Let's call it prepare-to-sleep or power-down or something rather than sleep.
-
@Zeph Fair enough.
Since I'm not getting any response on their mailing list, perhaps we should just go ahead and implement something. My plan is to create a virtualised powerdown in RHGenericDriver and then implement a reasonable default at least for the two radios we use. We can then expand this as we gain more experience. I know that for the RF69 driver this should be no more than five minutes work. Does anyone want to take care of your radios?
-
@Zeph Fair enough.
Since I'm not getting any response on their mailing list, perhaps we should just go ahead and implement something. My plan is to create a virtualised powerdown in RHGenericDriver and then implement a reasonable default at least for the two radios we use. We can then expand this as we gain more experience. I know that for the RF69 driver this should be no more than five minutes work. Does anyone want to take care of your radios?
If it works out, we can send them a patch :-)
-
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....
