Archived Forum

Hi Jérôme, it would be interesting if you could describe your scenario: building / number walls, distance between nodes.

Well, what I described was in my former house. The base was in the garage, so it was like:

emonBase - 3m - garage door (wood, about 2cm) - 1.5m - caravan (metal, 3m length) - 2.5m - vegetal hedge - gas meter with emonTX inside

The distance was not the issue: a TX placed further but so that the caravan wouldn't be in the way could reach the base.

And when the TX was in a room, it could reach the base through a few brick walls.

I have lots of problems with radio dropout so much so that I've turned off ACKs on most of my nodes as they seemed to be blocking each other. It seems to mainly be a problem when sending multiple data items in one transmission (bigger packets I assume) and if a lower bitrate would help that would be great. I'm even looking at changing the code to cope with missing data where this is important (e.g. rain tipping bucket pulses from my weather station) as I often have gaps of a few minutes in receiving data from nodes that are transmitting every minute. I've even tried a full wave antenna at the receiver without much improvement.

I believe NeilK found that 600 mm thick masonry walls gave him problems and he saw an improvement when he lowered the bit rate.

Hi Jérôme,

Using EmonTX/TH is large buildings, I'm not happy with the range (maximum 2/3 walls/floors).

So if modifying the biterate can improve the range,  it is worth developing this feature !

Eric

I had also reception problems with an emonTH and a Jeelink that were fixed by lowering the bitrate with rf12_control.

I have also asked in that thread, is there any downside to lowering the rate? I can't think  and haven't noticed any problems since lowering the bitrate (I have set mine to 3.918kbps).

The only downside of lowering the bitrate, AFAIK, is that the same packet will take more time to transfer.

I think one node is not "allowed" to emit for too long (how long ? says who ? source needed).

Besides, this increases the risk of several nodes emitting in the same time. Bra1n, if you have nodes blocking each other (as in speaking in the same time), then I'm not sure it will help.

Those of you who are interested and able to fiddle a bit with the code can copy what I did in the code I link to in the GitHub issue. The TX part is dead easy. The base part is not more difficult to code, but it needs to setup the environment to compile the sketch (not arduino default) and reflash the base (this can be done from the Pi if you're using a Pi).

Thank you for your answers. There seems to be an interest, so it is worth digging into this.

Most of the information you need is somewhere on the JeeLabs site. The rules are for the proportion of the time that one transmitter is transmitting, therefore if you lengthen the time it takes to transmit one message, you need to increase the gap between messages (or send less bytes). "Who says" is International Treaties, backed up by National laws. There are very many bands in the RF spectrum and each has its own rules, which vary from country to country and area to area.

Yes. I'm pretty sure I remember reading about this on this forum (or in the doc). With precise figures and all. But we shall take a look at the Jeelabs website for reference. At least.

Lowering the bit rate is only part of the story.  In brief, a lower bit rate can use a lower frequency deviation - this results in a narrower spectrum around the nominal carrier. Adjusting the RxBandwidth down to match allows less junk into the receiver section.  Result - higher signal to noise ratio which is really where the best range gain comes from.

There are limits - setting the RxBandwidth to the minimum requires that the corresponding pairs of crystals on the communicating RF modules agree closely on their versions of '10MHz'.  A few ppm is auto corrected by the AFC - a larger ppm delta can take the received signal partly out of the RxBandwidth filter passband, causing the AFC and hence the entire packet reception to fail.

The current settings are at a sweet spot of range/energy consumed per packet (lower bit rates of course take longer, consequently more joules eaten).  If remote node battery life is not an issue and the chosen RF channel is lightly loaded, then slowing right down to even 1200baud can have substantial range gains (provided the corresponding tweaks are made as described plus probably a little crystal tuning).

Thanks Martin.

Good point about the battery usage. This advocates for the search of a better trade-off instead of just picking the lowest bitrate.

Adjusting the RxBandwidth down to match allows less junk into the receiver section.  Result - higher signal to noise ratio which is really where the best range gain comes from.

Do you mean that by lowering the bitrate I gained in SNR but only a part of what I could have gained if I had also adjusted the Rx BW ? Is this what you refer to as "corresponding tweaks" ? Is this achievable with the RFM12 or RF69 ?

In the GitHub thread, Paul says that for compatibility reasons, it would be even better to propose this upstream (Jeelib). Or maybe they didn't do it because they thought it was not such a good idea. In which case it is still a good idea to raise the point there.

@Jérôme,

  > lowering the bitrate .. gains... in SNR

No, not at all.  Lowering the bitrate lowers the minimum SNR needed to decode the signal.

Reducing the RxBandwidth improves the SNR.  Think of it as a squarish window on the RF world - the amount of RF junk picked up is proportional to the width of the window (the 'noise' in the SNR formula).   Provided the useful part of the transmitted spectrum fits neatly into the window, that is the 'signal'.   Hence the improvement in ratio which maps to more range.

Chopping off one side of the received spectrum by mismatch in the two crystals, and/or chopping off both sides by an overly narrow filter gives worse results, since the information required to recover the modulation is smeared around in the whole of the transmitted spectrum (with repeats in the side lobes).

Oversimplified, but close enough for a guideline.  If you really want to get deeper into the dark mysteries of FSK, prepare for a dunking into Bessel functions etc.

Note that the magic table in the RFM12B spec sheet about sweetspot combinations of the key parameters (bit rate, deviation, RxBW) is hard to follow since there is an additional constraint in play - the limited, quantized choices for RxBW.   The RFM69 series has more flexibility here, plus a more sensitive receiver section.  Provided there is not too wide a mix of incoming signal strengths, the RFM69 in general will squeeze out more range with like-for-like parameter settings.

No, not at all.  Lowering the bitrate lowers the minimum SNR needed to decode the signal.

Right. My formulation was incorrect.

Thanks again for the explanations.

I studied signal processing a while ago. I suppose if I had the time I could dig into the datasheets, docs, etc. and discuss this here or at Jeelabs. But it is not reasonable. I don't have that kind of time, let alone the skills, and I guess other people at Jeelabs have been thinking about this much more than I did and are way ahead of me.

As a RFM12B or RFM69 user, I am sort of a client of the Jeelib, I never really meant to hack into it.

I just observed that lowering the bitrate (by using the bitrate feature proposed in the jeelib (the #define in the .h file)) did improve my communication and thought I might as well share that and try to facilitate it by adding a simple feature in the code.

In the Jee code, the job is half done, somehow, as the bitrate #define exist but are not used in the code.

If you have grounds to believe that we shouldn't use this feature because it can worsen things, or if you think the Jeelib manages the bitrate it in a way that is not optimal, then please warn us so that we can wonder where we should go from here: forget about it all, see with people at Jeelabs how this could be improved, etc.

I don't want to push a feature that will be a mess. I don't think I even need it anymore myself (I used it in my former house and never switched back). It just seems like other people have had (or expect to have) range issues, and this seemed like an easy improvement.

(In fact, if I manage to use OpenEnergyMonitor someday at work, it is likely to be in big buildings where the range will be an issue, so an easy config would be nice. So I do have an interest in this.)

Lowering the bit rate is not new. MartinR used the technique a while ago. My view - and I too am not an expert on communications theory - is that the chosen default values are a good choice in most circumstances, but as has been pointed out above, lowering the bit rate too far, or indiscriminately, would usually not be an advantage and could be a major disadvantage. Done with discretion and only when necessary, it is a useful tool.

I just want my modules to work and currently they don't work well enough, to the point that I'm looking to use cabling and serial communication where at all possible. I'm not talking about long range here either just one side of a modest house to the other, maybe there are other avenues I can explore like reducing transmission packet size but lowering bit rate seems like a good option.

Hello Bra1n,

          I've even tried a full wave antenna at the receiver without much improvement.

The impedance of an end fed 1/2, or full wave antenna is quite high, typically 1800 ohms or so, but definitely not the 50 to 75 ohms the RFM12 (and lots of other radio frequency transmitter/receiver equipment) wants to be connected to. The resulting mismatch causes a significant amount of RF energy loss affecting the strength of both the radiated, and received signals. End result, poor range.

Your best bet is to use a 1/4 wave antenna with a counterpoise (aka a ground plane). Here's a link that shows how easy it can be to build one: http://www.rcgroups.com/forums/showthread.php?t=1333382.

Connecting the feed line to the RFM12 can be an issue, but if small diameter coaxial cable, say something like RG-174, is used, and the length kept to a meter or less, the results will be a considerable improvement over the 1/4 wave wire antenna alone. One solution is to buy a pre-made cable that has an SMA or BNC male connector on one or both ends and use a female SMA/BNC connector at the antenna feedpoint. It's even possible to build one with no connector at all. The link above has pictures and instructions for two slightly different build methods, neither with RF connectors at the antenna.

Regards,

Bill

@Bra1n: You seem to be in the same case I was in my former house. Although a user-friendly "bitrate selection" feature has not been implemented already, you could try to modify the bitrate yourself. See my links above. The TX part is the easy part. Just one line or two in the init. The Base part is pretty much the same code-wise, but the extra amount of work is the flashing of the RFM2Pi board. You need to setup avrdude and all. See the docs. If you can reflash the RFM2Pi with the stock firmware and it works, then the most difficult part is done. Modifying the code to hardcode another bitrate is piece of cake.

Thanks for the tips Bill and Jerome, I'll get back onto that when I've finished sorting my CCTV issues out.

This link (found on top of RF12.h bitrate section) deals with bitrate and bandwidth:

http://blog.strobotics.com.au/2009/07/27/rfm12-tutorial-part-3a/

I moved to RFM69 now. From what I understand, the bit rate setting mechanism is different from the RFM12.

For RFM12, see page 17 of datasheet and above link.

For RFM69, see page 19 of datasheet.

As far as I understand, the bitrate setting was not implemented in the Jeelib RFM69 driver. But I may be wrong. (Can anyone confirm ?)

If this is the case, it will be a bit harder to add this feature here: need to add it to the driver first.

It would also mean that the few people using other bitrates are currently stuck on RFM12.

Are you saying it cannot be done by writing to the Arduino SPI, as MartinR did in his PLL energy diverter for the RFM12B?
(N.B. I'm not saying I've even looked at the problem!)

I'm sorry, I might not have looked deep enough into it myself, and I don't have a clue what you're talking about.

What I'm saying is that I could achieve it easily with the RF12 driver thanks to this enum

/// See http://blog.strobotics.com.au/2009/07/27/rfm12-tutorial-part-3a/
/// Transmissions are packetized, don't assume you can sustain these speeds!
///
/// @note Data rates are approximate. For higher data rates you may need to
/// alter receiver radio bandwidth and transmitter modulator bandwidth.
/// Note that bit 7 is a prescaler - don't just interpolate rates between
/// RF12_DATA_RATE_3 and RF12_DATA_RATE_2.
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,
};

and the rf12_control() function.

Just use rf12_control(RF12_DATA_RATE_1) and you're done.

However, AFAIU, the command and registers differ on the RFM69 and there is no equivalent in the RF69 driver.

I may (and I hope I am) misleaded.

In MartinR's sketch, he includes SPI.h, and he has a function:

// write a command to the RFM12
word rfm_write(word cmd)
{
  word result;
  
  digitalWrite(RFMSELPIN,LOW);
  result=(SPI.transfer(cmd>>8)<<8) | SPI.transfer(cmd & 0xff);
  digitalWrite(RFMSELPIN,HIGH);
  return result;
}

Then to set up the RFM12B, he uses:

  // start the SPI library:
  SPI.begin();
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(0);
  SPI.setClockDivider(SPI_CLOCK_DIV8);
  // initialise RFM12
  delay(200); // wait for RFM12 POR
  rfm_write(0x0000); // clear SPI
  rfm_write(0x80D7); // EL (ena dreg), EF (ena RX FIFO), 12.0pF 
  rfm_write(0x8208); // Turn on crystal,!PA
  rfm_write(0xA640); // 434MHz 
  rfm_write(0xC606); // approx 49.2 Kbps, as used by emonTx
  //rfm_write(0xC657); // approx 3.918 Kbps, better for long range
  rfm_write(0xCC77); // PLL 
  rfm_write(0x94A0); // VDI,FAST,134kHz,0dBm,-103dBm 
  rfm_write(0xC2AC); // AL,!ml,DIG,DQD4 
  rfm_write(0xCA83); // FIFO8,2-SYNC,!ff,DR 
  rfm_write(0xCEd2); // SYNC=2DD2
  rfm_write(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN 
  rfm_write(0x9850); // !mp,90kHz,MAX OUT 
  rfm_write(0xE000); // wake up timer - not used 
  rfm_write(0xC800); // low duty cycle - not used 
  rfm_write(0xC000); // 1.0MHz,2.2V 

which I guess is much the same as the library does. If you do go this way, it would be a good idea to reverse engineer the library for the RFM69CW to check what it does set up, then do the same but change the settings you want changing. OK, I see it is harder this way, but it looks possible while the library catches up.

Yes, he uses the 0xC6xx command to set a bit rate, like the RFM12 lib does.

I didn't see anything similar in the RFM69 lib, but I don't claim I took an extensive look.

I think the whole code above is RFM12 specific and would require adaptation to RFM69.