Porting MySensors to work with the RadioHead library
-
I just had a quick look at the RadioHead implementation.
All drivers are derived from RHGenericDriver (from http://www.airspayce.com/mikem/arduino/RadioHead/classRHGenericDriver.html):
If you pass an instance of RHGenericDriver in e.g. the c'tor of MySensors you're done.... But maybe I had a too-quick look ;-)
-
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
On the other hand, each driver seems to come with a relatively intelligent set of defaults, so I think it is quite easy to cater for the generic case, and then we can expose the internals for those who really want to get into the specifics. Still, if you want to try to generalise it in a different way, feel free :-)
-
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
On the other hand, each driver seems to come with a relatively intelligent set of defaults, so I think it is quite easy to cater for the generic case, and then we can expose the internals for those who really want to get into the specifics. Still, if you want to try to generalise it in a different way, feel free :-)
@kolaf said:
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
Are those driver-specific functions needed during normal operation, or are they only for non-default setup? (eg: frequency, bandwidth, etc)
-
What about packet size? I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options) right?
(This approach is frequently called "least common denominator", tho the actual mathematical concept being misreferenced is actually the greatest common denominator)
-
I don't think the flash and RAM footprint is a deal breaker in this application, but it could be a concern for some multi-sensor nodes which include several sensor libraries. So I was wondering how much heavier it is, but not saying (yet) that it's too large.
Remember to save room for a possible crypto library, if we do a more secure version.
My own use case is unusual. I am using nRF24L01+ for christmas light control, which involves a high bandwidth transmission from hub to nodes (and uses a fair amount of RAM on the nodes for buffers). I've been thinking that I could have the Christmas light display nodes also transmit sensor data to a MySensors network periodically,since they use the same radio and processor. That isn't critical tho. I could just use separate nodes on different channels for the two applications.
-
What about packet size? I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options) right?
(This approach is frequently called "least common denominator", tho the actual mathematical concept being misreferenced is actually the greatest common denominator)
@Zeph said:
I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options)
Why? MySensors can easily handle payloads with different sizes. Only when you start mixing different radios in one network ( hek apparently thinks in this direction) you have to handle fragmentation.
-
@hek Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
I haven't looked into the radiohead interface yet (have to admit you guys got me curious, though) but isn't there simply one base class defining the interface and every radio derives from it? That would definately make things simple!@hek said:
Yes, defines certainly make sense now! But it would be cool to have gateway-nodes between different radio models in the future@Yveaux said:
Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
The RF69 has some nice possibilities for range using 433 or 868/915 MHz, albeit with less bandwidth than the nRF24L01+ at 2.4 GHz. That makes the former attractive for low bandwidth applications like a sensor network. I like the latter for some other projects that make use of the higher bandwidth, but it could be nice to include MySensor network as well using the same radio. That's what brought me here. So I could envision using both radios - RF69 for pure low bandwidth sensors and nRF for combined nodes.
@Yveaux, is there really a way to tie two hubs together for MySensors.
-
@Zeph said:
I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options)
Why? MySensors can easily handle payloads with different sizes. Only when you start mixing different radios in one network ( hek apparently thinks in this direction) you have to handle fragmentation.
@Yveaux said:
@Zeph said:
I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options)
Why? MySensors can easily handle payloads with different sizes. Only when you start mixing different radios in one network ( hek apparently thinks in this direction) you have to handle fragmentation.
Yeah, but handling fragmentation might add a lot of complication and code. If the network was designed around "expect all radios to handle at least 32 byte packets" it could be lighter and simpler.
And this is not just about mixing radios in one system; if one writes a sensor which makes use of more than 32 byte packets because it's initially using the RF69, then it would not port well to another system using a non-fragmentation nRF implementation.
-
@hek said:
Yes, defines certainly make sense now! But it would be cool to have gateway-nodes between different radio models in the future@Yveaux said:
Maybe, but I have yet to see a valid usecase for this. You can always use 2 Arduino's running the default serial gateway and tie them together ;-)
The RF69 has some nice possibilities for range using 433 or 868/915 MHz, albeit with less bandwidth than the nRF24L01+ at 2.4 GHz. That makes the former attractive for low bandwidth applications like a sensor network. I like the latter for some other projects that make use of the higher bandwidth, but it could be nice to include MySensor network as well using the same radio. That's what brought me here. So I could envision using both radios - RF69 for pure low bandwidth sensors and nRF for combined nodes.
@Yveaux, is there really a way to tie two hubs together for MySensors.
@Zeph said:
is there really a way to tie two hubs together for MySensors.
Maybe it won't work out of the box, but in principe the serial format for send/receive is identical. I think that just cross-connecting the serial ports of two gateways will get you close to a working solution. When different speeds have to bridged, of (de)fragmentation is required the whole story changes...
Btw. if you want different networks, why not just use a different gateway for each network? Or is Vera not able to handle multiple gateways?
-
One other consideration - there is a thread on Security. if MySensors were to migrate towards multi-radio support (the nRF and the RF69 being the most attractive options), then it might be tempting to design any security layer to make use of the latter's built in AES encryption, with its strengths (fast with little code) and weakneses (less flexible than a software implementation). That is, use AES in software on the nRF to do the same approach as is done in hardware with the RF69.
This would not be required (each radio could use it's own security approach, or the same software security could be used for all of them), just somewhat attractive to keep down the number of separate implementation while also making use of the hardware.
-
@Yveaux said:
@Zeph said:
I'm guessing that the idea is to use the 32 byte limit of the nRF24L01+ for all radios (even if they have larger packet options)
Why? MySensors can easily handle payloads with different sizes. Only when you start mixing different radios in one network ( hek apparently thinks in this direction) you have to handle fragmentation.
Yeah, but handling fragmentation might add a lot of complication and code. If the network was designed around "expect all radios to handle at least 32 byte packets" it could be lighter and simpler.
And this is not just about mixing radios in one system; if one writes a sensor which makes use of more than 32 byte packets because it's initially using the RF69, then it would not port well to another system using a non-fragmentation nRF implementation.
@Zeph said:
Yeah, but handling fragmentation might add a lot of complication and code. If the network was designed around "expect all radios to handle at least 32 byte packets" it could be lighter and simpler.
I'm certainly not in favour of implementing fragmentation in MySensors, and if it would be added it should be handled at a lower level anyway.
And this is not just about mixing radios in one system; if one writes a sensor which makes use of more than 32 byte packets because it's initially using the RF69, then it would not port well to another system using a non-fragmentation nRF implementation.
All the examples that come with the MySensors library use a lot less than the maximum MySensors payload (which is less than 32 bytes due to the header btw). I don't have the actual figures, but I think the largest payload is sent in the sensor presentation (the version string).
For radio-portability it would indeed be benificial to have a minimum payload size defined. -
@Zeph said:
is there really a way to tie two hubs together for MySensors.
Maybe it won't work out of the box, but in principe the serial format for send/receive is identical. I think that just cross-connecting the serial ports of two gateways will get you close to a working solution. When different speeds have to bridged, of (de)fragmentation is required the whole story changes...
Btw. if you want different networks, why not just use a different gateway for each network? Or is Vera not able to handle multiple gateways?
@Yveaux said:
Maybe it won't work out of the box, but in principe the serial format for send/receive is identical. I think that just cross-connecting the serial ports of two gateways will get you close to a working solution. When different speeds have to bridged, of (de)fragmentation is required the whole story changes...
I've been thinking of using a APM as a "smart peripheral" to a node (for Christmas lighting, because driving some pixel light strings requires turning off interrupts for long periods). A 5V APM is as little as $2.30 shipped, so I could make a light controller intermediary with a more asynchronous interface (so the main node processor can be interrupted).
Something similar might also work with two MySensor radio hubs, especially given the relatively low bandwidth. One radio hub might be an APM connected to the main hub.
If the home automation controller will accept multiple gateways, tho, you may be right that it would be the simpler solution.
-
@Yveaux said:
Maybe it won't work out of the box, but in principe the serial format for send/receive is identical. I think that just cross-connecting the serial ports of two gateways will get you close to a working solution. When different speeds have to bridged, of (de)fragmentation is required the whole story changes...
I've been thinking of using a APM as a "smart peripheral" to a node (for Christmas lighting, because driving some pixel light strings requires turning off interrupts for long periods). A 5V APM is as little as $2.30 shipped, so I could make a light controller intermediary with a more asynchronous interface (so the main node processor can be interrupted).
Something similar might also work with two MySensor radio hubs, especially given the relatively low bandwidth. One radio hub might be an APM connected to the main hub.
If the home automation controller will accept multiple gateways, tho, you may be right that it would be the simpler solution.
-
I think we need to think about choosing a bitter atmega for this.. Its a bit too bad that atmega havn't made a atmega628p which is pin compatible with 328 but with 64KB of program storage instead.. :) so the next up is 644 which arduino has no boards for. but there is sanguino.cc - https://code.google.com/p/sanguino/ though.
Next up would be Arduino Mega 2560 with what it feels like 'Unlimited ram!'
They are not That expensive today since china made its own ch340 usb - serial chip (Why this was the expensive component blows my mind :P) ATmega2560-16AU CH340G MEGA 256 you can find for ~10EUR / 13.50USD..@Damme said:
I think we need to think about choosing a bitter atmega for this..
Next up would be Arduino Mega 2560 with what it feels like 'Unlimited ram!'
They are not That expensive today since china made its own ch340 usb - serial chip (Why this was the expensive component blows my mind :P) ATmega2560-16AU CH340G MEGA 256 you can find for ~10EUR / 13.50USD..Also note the ATMega2560 small form factor offering: http://www.ebay.com/itm/261541870545 which is similar to an Arduino Pro Mini but with the larger processor. And it has even more pins broken out than the Arduino Mega2560.
-
@kolaf said:
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
Are those driver-specific functions needed during normal operation, or are they only for non-default setup? (eg: frequency, bandwidth, etc)
@Zeph said:
@kolaf said:
It is not that simple because all the different specific drivers implement a bunch of their own functions which are not virtualised. This means that you need to static cast or dynamic cast the driver every time you want to use it which is a real pain.
Are those driver-specific functions needed during normal operation, or are they only for non-default setup? (eg: frequency, bandwidth, etc)
Just for setup. Runtime operation is handled by the manager and is independent of the radio driver.
-
@Damme said:
I think we need to think about choosing a bitter atmega for this..
Next up would be Arduino Mega 2560 with what it feels like 'Unlimited ram!'
They are not That expensive today since china made its own ch340 usb - serial chip (Why this was the expensive component blows my mind :P) ATmega2560-16AU CH340G MEGA 256 you can find for ~10EUR / 13.50USD..Also note the ATMega2560 small form factor offering: http://www.ebay.com/itm/261541870545 which is similar to an Arduino Pro Mini but with the larger processor. And it has even more pins broken out than the Arduino Mega2560.
@Zeph And you even get the "mini mega" presoldered with the radio chip of your choice for $20 :-)
-
@Zeph And you even get the "mini mega" presoldered with the radio chip of your choice for $20 :-)
@kolaf said:
And you even get the "mini mega" presoldered with the radio chip of your choice for $20 :-)
Well, it's actually another $6-7 for the radio, $1 for pins, and optionally $3 for extra flash. But it's still a good deal.
It's nice to have more ATMega1284 based Arduino styles options available. The official Arduino folks went for the ATMega1280/2560 instead for their high end AVR based system, and they have their advantages, but the extra RAM on the 1284 is probably more useful than the extra Flash memory.
For our nodes, the Moteino Mega probably has more than enough IO. Compared to the Arduino Pro Micor, it basically has 10 additional digital pins (plus all 8 analog pins can be used as digital, not just 6 of them). I2c is done with digital IO pins rather than analog pins. And it has another serial port.
The ATMega2560-core (I posted an ebay link a couple msgs back) has a huge number of IO pins, including many that were not available in the Arduino Mega board - eg: the pins needed for doing SPI master mode with the additional USARTS. There are applications that might be useful for, but for sensor network nodes we would rarely need so many I/Os.
(I'll stop there - these messages on other boards and chip might be a good candidate for a moderator to move to another thread)
-
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 :-)
I took a look at the freeRam function to see if memory was part of my radio performance issues. However, are not able to make sense of the readings. It reports consistently -152 which seems a bit weird to me. Can anyone help me understand what this means, and whether it is a problem?
-
I took a look at the freeRam function to see if memory was part of my radio performance issues. However, are not able to make sense of the readings. It reports consistently -152 which seems a bit weird to me. Can anyone help me understand what this means, and whether it is a problem?
-
It is the function that is included in the bottom of the radio library main file.
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
I'm guessing that a negative value here is not a good sign. I have been battling with a very poor radio performance (10 cm range) and I think it is related to memory usage. If a switch from the mesh manager to the reliable datagram manager I suddenly get much better range, as well as heaps of free memory. I have started a thread on this on the Radiohead forum, so let's see if some bright guy there can help me.
In the meantime I have two options: use only point to point links, or reimplement the multihop routing existing in the original MySensors library. For the moment I'll hold off to see what the other guys can tell me.
