RF birate configuration

[lafrech]

Hi all.

There has been talk already about lowering the bitrate to improve the communication range. I did it myself and I would like to share a few thoughts, with the hope that we could make that easier for anyone needing it.

How

emonTX / emonTH

On emonTX side, it is pretty simple. Just add a call to rf12_control() with the proper value during initialization.

This is how I did it on emonTX.

And this is how I did it on emonTH. It is just the same, except I also added a few lines to print the bitrate on the serial port at startup, along with the other parameters.

emonBase

Of course, the bitrate needs to be set accordingly on the emonBase. This shows how I did it (see other commits on same branch for other bitrate values). Again, just the same, except the call to rf12_control() appears several times in the code.

Remarks / questions

Before trying to improve the code for integration, I would like to be sure there is a real interest in this. Otherwise, I'll just keep it dirty for myself.

I think it could be added as a parameter in each sketch, just like Node ID and all, without adding too much confusion to the end user. What do you think ?

I'm listing below a few points to be discussed.

emonBase parameter

Instead of hardcoding, we could modify the RFM2Pi code to make the bitrate a parameter that could be set just like the frequency, Node ID, etc. I'm pretty sure it is not so big a deal, although I never went down to it.

This would allow a user to choose the bitrate by only reprogramming the TX and changing the bitrate smoothly on the base. With this, I'd iterate until I find the fastest bitrate with acceptable throughput. Currently, I justed picked the lowest to spare me the hassle of the tests.

Max packet length and bandwidth occupation

According to the RFM12B page , "the library accepts a variable length packet of data, the limit is 66 bytes".

I can't find the source, but I think this 66 limit is based on the max time a single unit should occupy the bandwidth. I don't know exactly how this is calculated, but if the bitrate is lowered, maybe the max length should be decreased.

Should we come up with a way to enforce this ? What are the requirements ?

Is the 66 limit actually enforced ? Does it depend on the bitrate as I suspect ?

User friendly #defines

In my code, I picked the #defines from the jeelib: RF12_DATA_RATE_1 to RF12_DATA_RATE_9.

Those do not contain the bitrate explicitly, as opposed to something like RF12_DATA_RATE_1200. Should we create such explicit #defines?

Where ? In EmonLib ?

Note that maybe the user does not care about the actual value, and picking in [1-9] makes it easier for him.

Minimize runtime code

In my emonTH implementation, I added a few lines to print the bitrate (real bps value) on the serial port for debug/logging. I copied the lines used to print the frequency.

It should be possible to do more work at compile time, thus generating a code slightly smaller and with a few less work to do at runtime. It is a small detail, really. Besides, it is executed in debug mode, nothing critical. But is sounds like good practice, so while we're at it, we may want to give it a thought. It should be just a few preprocessor directives to add (like #if and such).

Any interest in this ?

[glynhudson]

Hi Jérôme,

Thanks for your mail. This in an interesting development. I've not experimented at all with lowering the bitrate. I have a couple of questions:

What's the default bitrate? What sort of range increase did you experience after lowering the bitrate? Would all nodes on a particular network need to be on the same lowered bitrate? ​

On 25 November 2014 at 11:08, Jérôme Lafréchoux notifications@github.com wrote:

Hi all.

There has been talk already about lowering the bitrate to improve the communication range. I did it myself and I would like to share a few thoughts, with the hope that we could make that easier for anyone needing it. How emonTX / emonTH

On emonTX side, it is pretty simple. Just add a call to rf12_control() with the proper value during initialization.

This https://github.com/Jerome-github/oem_emonTxFirmware/commit/4991180c1a730825c790d7c1d6f0f521131a10df is how I did it on emonTX.

And this https://github.com/Jerome-github/oem_emonTH/commit/e0d3d04e4d8168b1d6ed3ea9328bf74cd8b33679 is how I did it on emonTH. It is just the same, except I also added a few lines to print the bitrate on the serial port at startup, along with the other parameters. emonBase

Of course, the bitrate needs to be set accordingly on the emonBase. This https://github.com/Jerome-github/RFM2Pi/commit/335cb69b48e2c87227e04daa64bde4af2620000f shows how I did it (see other commits on same branch for other bitrate values). Again, just the same, except the call to rf12_control() appears several times in the code. Remarks / questions

Before trying to improve the code for integration, I would like to be sure there is a real interest in this. Otherwise, I'll just keep it dirty for myself.

I think it could be added as a parameter in each sketch, just like Node ID and all, without adding too much confusion to the end user. What do you think ?

I'm listing below a few points to be discussed. emonBase parameter

Instead of hardcoding, we could modify the RFM2Pi code to make the bitrate a parameter that could be set just like the frequency, Node ID, etc. I'm pretty sure it is not so big a deal, although I never went down to it.

This would allow a user to choose the bitrate by only reprogramming the TX and changing the bitrate smoothly on the base. With this, I'd iterate until I find the fastest bitrate with acceptable throughput. Currently, I justed picked the lowest to spare me the hassle of the tests. Max packet length and bandwidth occupation

According to the RFM12B page http://openenergymonitor.org/emon/buildingblocks/rfm12b2, "the library accepts a variable length packet of data, the limit is 66 bytes".

I can't find the source, but I think this 66 limit is based on the max time a single unit should occupy the bandwidth. I don't know exactly how this is calculated, but if the bitrate is lowered, maybe the max length should be decreased.

Should we come up with a way to enforce this ? What are the requirements ?

Is the 66 limit actually enforced ? Does it depend on the bitrate as I suspect ? User friendly #defines

In my code, I picked the #defines from the jeelib: RF12_DATA_RATE_1 to RF12_DATA_RATE_9.

Those do not contain the bitrate explicitly, as opposed to something like RF12_DATA_RATE_1200. Should we create such explicit #defines?

Where ? In EmonLib ?

Note that maybe the user does not care about the actual value, and picking in [1-9] makes it easier for him. Minimize runtime code

In my emonTH implementation, I added a few lines to print the bitrate (real bps value) on the serial port for debug/logging. I copied the lines used to print the frequency.

It should be possible to do more work at compile time, thus generating a code slightly smaller and with a few less work to do at runtime. It is a small detail, really. Besides, it is executed in debug mode, nothing critical. But is sounds like good practice, so while we're at it, we may want to give it a thought. It should be just a few preprocessor directives to add (like #if and such).

Any interest in this ?

— Reply to this email directly or view it on GitHub https://github.com/openenergymonitor/emonTxFirmware/issues/8.

Glyn Hudson

Home: +44(0)1286479462 Mobile: +44(0)7769871550 Office: +44(0)1248672607

http://openenergymonitor.org http://megni.co.uk http://adventuresplusnorthwales.blogspot.com

[lafrech]

Hi Glyn.

What's the default bitrate?

I believe the default bitrate is 49200 bps.

I didn't check. This is a guess from the Jeelib header:

enum rf12DataRates {
RF12_DATA_RATE_CMD = 0xC600,
RF12_DATA_RATE_9 = RF12_DATA_RATE_CMD | 0x02, // Approx 115200 bps
RF12_DATA_RATE_8 = RF12_DATA_RATE_CMD | 0x05, // Approx 57600 bps
RF12_DATA_RATE_7 = RF12_DATA_RATE_CMD | 0x06, // Approx 49200 bps
RF12_DATA_RATE_6 = RF12_DATA_RATE_CMD | 0x08, // Approx 38400 bps
RF12_DATA_RATE_5 = RF12_DATA_RATE_CMD | 0x11, // Approx 19200 bps
RF12_DATA_RATE_4 = RF12_DATA_RATE_CMD | 0x23, // Approx 9600 bps
RF12_DATA_RATE_3 = RF12_DATA_RATE_CMD | 0x47, // Approx 4800 bps
RF12_DATA_RATE_2 = RF12_DATA_RATE_CMD | 0x91, // Approx 2400 bps
RF12_DATA_RATE_1 = RF12_DATA_RATE_CMD | 0x9E, // Approx 1200 bps
RF12_DATA_RATE_DEFAULT = RF12_DATA_RATE_7,
};

This is why in my commit on emonTH, I left 49200 as a default.

This could be checked in the code or with a test. At least to make sure we keep the default the same after integrating the bitrate feature.

Would all nodes on a particular network need to be on the same lowered bitrate?

Yes. Nodes and base need to be set to the same bitrate.

What sort of range increase did you experience after lowering the bitrate?

I can't give any figure. Ranges are hard to qualify. Even for a given bitrate, it is hard to estimate a range (except for a line-of-sight range).

It is even possible that lowering the bitrate extends the line-of-sight range just a few, but makes the signal much more robust to interferences, walls, and such.

When Trystan came to my house, I was experiencing trouble receiving the signal from my TX, which was outside, while the base was in my garage. In between was a caravan (big metal cage), which was probably cutting the transmission. We moved about to see where the signal would pass and where it would not. It became clear the caravan was the culprit, but I couldn't move it anyway. The day I lowered drastically the bitrate, I had all my samples back to my base.

I've seen people on the forums asking about the range, but I'm surprised so few actually complain about range issue or try to modify the bitrate. I think I'll post on the forum to bring attention to this end eventually get other testimonies/impressions/opinions.

Edit: here is the forum thread.

[glynhudson]

Thanks for answering my questions. Yes, I think posting on the forum would be a good next step to try and establish how well this works for different people over different ranges.

Have you tested with RFM69CW modules? We are in the process of moving all units over to these new modules.

• sent from my mobile device On 26 Nov 2014 08:43, "Jérôme Lafréchoux" notifications@github.com wrote:

Hi Glyn.

What's the default bitrate?

I believe the default bitrate is 49200 bps.

I didn't check. This is a guess from the Jeelib header https://github.com/jcw/jeelib/blob/master/RF12.h#L151:

enum rf12DataRates { RF12_DATA_RATE_CMD = 0xC600, RF12_DATA_RATE_9 = RF12_DATA_RATE_CMD | 0x02, // Approx 115200 bps RF12_DATA_RATE_8 = RF12_DATA_RATE_CMD | 0x05, // Approx 57600 bps RF12_DATA_RATE_7 = RF12_DATA_RATE_CMD | 0x06, // Approx 49200 bps RF12_DATA_RATE_6 = RF12_DATA_RATE_CMD | 0x08, // Approx 38400 bps RF12_DATA_RATE_5 = RF12_DATA_RATE_CMD | 0x11, // Approx 19200 bps RF12_DATA_RATE_4 = RF12_DATA_RATE_CMD | 0x23, // Approx 9600 bps RF12_DATA_RATE_3 = RF12_DATA_RATE_CMD | 0x47, // Approx 4800 bps RF12_DATA_RATE_2 = RF12_DATA_RATE_CMD | 0x91, // Approx 2400 bps RF12_DATA_RATE_1 = RF12_DATA_RATE_CMD | 0x9E, // Approx 1200 bps RF12_DATA_RATE_DEFAULT = RF12_DATA_RATE_7, };

This is why in my commit on emonTH, I left 49200 as a default.

This could be checked in the code or with a test. At least to make sure we keep the default the same after integrating the bitrate feature.

Would all nodes on a particular network need to be on the same lowered bitrate?

Yes. Nodes and base need to be set to the same bitrate.

What sort of range increase did you experience after lowering the bitrate?

I can't give any figure. Ranges are hard to qualify. Even for a given bitrate, it is hard to estimate a range (except for a line-of-sight range).

It is even possible that lowering the bitrate extends the line-of-sight range just a few, but makes the signal much more robust to interferences, walls, and such.

When Trystan came to my house, I was experiencing trouble receiving the signal from my TX, which was outside, while the base was in my garage. In between was a caravan (big metal cage), which was probably cutting the transmission. We moved about to see where the signal would pass and where it would not. It became clear the caravan was the culprit, but I couldn't move it anyway. The day I lowered drastically the bitrate, I had all my samples back to my base.

I've seen people on the forums asking about the range, but I'm surprised so few actually complain about range issue or try to modify the bitrate. I think I'll post on the forum to bring attention to this end eventually get other testimonies/impressions/opinions.

— Reply to this email directly or view it on GitHub https://github.com/openenergymonitor/emonTxFirmware/issues/8#issuecomment-64530932 .

[lafrech]

Here's the forum post: http://openenergymonitor.org/emon/node/6178

I haven't tried the RFM69 yet. I got one in the mail while I was on holidays. I hadn't ordered anything, so I assumed you sent it to me so that I can test it. I mailed Trystan to ask him but I think he didn't see my message. Anyway, thanks for the radio module. Testing it is on my TODO list as I dive back into emonHub.

Regarding the bitrate issue specifically, I didn't actually test the RFM12 module itself. I mean I had a range issue, I chose the lowest bitrate and it worked. Fine. It would be interesting to make more extensive tests. But since the process of flashing both TX and base for each bitrate can be a bit of a hassle by itself, a comprehensive benchmark would be easier done with a code in the base that allows for hot reconfiguration (even if this code is incomplete, for instance if the change is not persistent after reboot, or any real life limit that does not affect the tests).

This makes me think I believe the RFM69 has some sort of RSSI reporting feature. If this is usable, it would be definitely very helpful for the bitrate benchmark. With the RFM12, there's not much to measure, only a packet loss rate when close to the range limit. But plotting RSSI against bitrate for different configurations (distance, walls, etc) would be much more efficient indeed.

I guess trying the RFM69 and seeing how to get the RSSI would be a prerequisite, then.

Any doc you'd like to point me to regarding this ? Anything I need to know about the RFM69 ? The support in emonHub ? It is just replacing the module and there you go ? Do I need to do something specific ? Should it be flashed with the same firmware / same method (in-place flashing from Pi) ? I shall pay a look at the documentation.

[pb66]

Hi Jérôme,

I think this could be a good idea, with regards to extended tests it wouldn't be too difficult to add a "bitrate" setting to emonhub, (even if only temporary in anther branch), you should also see the Flashing RFM12Pi with Raspberry thread as it may possibly be easier to "experiment" with the RF12demo on a Pi and upload directly from IDE without compiling sketch for avrdude each time.

If there are just 9 available options an "r" (for rate) could be added to the existing "menu" maybe

 <n> r - set Bitrate (9=115200,8=57600,7=49200,6=38400,5=19200,4=9600,3=4800,2=2400,1=1200 bps)

I also wonder if JeeLabs have tried this or have anything to contribute if an issue was started on the JeeLib repo, it would be good to keep the compatibility going.

The "testng" branch of emonhub is "rfm69" ready. If you had an existing emonhub&rfm2pi set up you could just swap the boards and emonhub will work with it, the 69's use a baud of 57600 rather than 9600 which emonhub selects automatically (unless manually over-ridden in conf) it also handles the RSSI (passed as a neg value in parenthesis) and also the firmware on the 69 passes the data with a leading "OK" which fails OEM gateways checks. emonhub also picks out and logs the firmware version and current settings (in DEBUG) the current settings are also used to establish whether a command is actually needed rather than sending all settings at start up.

Glyn has also been running the "testing" branch to test rfm69 compatibility there are also links there for the firmwares but the board comes pre-loaded.

Paul

[lafrech]

Hi Paul. Thanks for the details.

I'm still running good old oemgateway and was planning on switching to emonHub. So I think I'll proceed by steps:

• move to emonHub/development
• move to emonHub/testing
• replace RF board

Given a setup with an RF69 working and the ability to reflash it easily, it shouldn't be too difficult to test several bitrates for different positions and plot RSSI vs. bitrate for each position.

[pb66]

I know exactly what you mean about OEMG, I have to admit it wasn't that long ago that I changed my live system over to emonHub from OEMG :-)

If we set up a temp "btrate switching" branch we could append the current bitrate setting to the payload before it's sent to emoncms so that it's easier to plot, review and compare the different settings over each test period.

[lafrech]

I know exactly what you mean about OEMG, I have to admit it wasn't that long ago that I changed my live system over to emonHub from OEMG :-)

I don't really have a live system. Only a test system. I don't care about my data. I just had no time to work on it...

If we set up a temp "btrate switching" branch we could append the current bitrate setting to the payload before it's sent to emoncms so that it's easier to plot, review and compare the different settings over each test period.

Yes, sure. I was thinking of something simpler: set the bitrate on both ends, then move the TX, keep it in place a few minutes (send several samples per minute), note the RSSI average value, move it, and after a few places, change bitrates. Having the RSSI in the payload may facilitate the process.

[pb66]

If it helps I've modified the avrdude-rpi "autoreset" mod so it will work with Arduino IDE on Pi over VNC (I just use windows remote desktop and xrdp on the Pi) so minor sketch edits and uploads to the rfm2pi should be easier to do.

The bootloader part however, is untested as if there was an issue I'm not confident I could definitely recover the bootloader and that may render my rfm2pi useless. but that shouldn't be needed for this.

avrdude-rpi

[lafrech]

I just saw this issue I opened a while ago, so I stopped by to say that on my side, this is "on hold". At least because I didn't see how to change the bitrate easily on the RF69. This is apparently not provided by the driver like on the RFM12. This makes it more difficult. And maybe there's a good reason it is not provided.

I thought it was possible so why not add it, but it appears to be more complicated than I expected.

http://openenergymonitor.org/emon/node/6178

I still think it might help in some cases, but I don't see myself implementing this on short or middle term.