Optimizing radio settings for power (rfm69w/hw) [+300kbps settings]

[joelucid]

I did some test recently to evaluate long range settings for the rfm69hw (see https://lowpowerlab.com/forum/index.php/topic,1767.0.html and https://lowpowerlab.com/forum/index.php/topic,1468.msg12905.html#msg12905).

This led to the insight that noise on the receiving Moteino has a substantial impact on range for these long range settings.

Today - also inspired by reading through one of Tom's old threads (https://lowpowerlab.com/forum/index.php/topic,688.0.html) - I wanted to figure out what consequences this might have for more normal setups. In particular I was wondering how you could tune your radio settings if you use a low noise receiver to maximize the overall performance, with a particular eye on power consumption.

If you have a more sensitive receiver you can reduce TX power at the sender or increase the bitrate. Which one is better?

Looking at http://www.eletrica.ufpr.br/evelio/TE111/Eb_N0.pdf the bit error rate at the same modulation index only depends on the power per bit and the noise spectral density. So power per bit is what counts and doubling the bit rate increases the error rate by the same amount as cutting tx power in half. So it's the same, right?

Not so fast. First we note that we need an ack back from the receiver and have to wait it RX for that. So total power for one exchange is txpower * txtime + rxpower * rxtime. You can only reduce txpower, so a decrease in rx and txtime is better than a decrease in txpower. This is more relevant for the w than hw obviously.

But much more significant: the data sheet shows txpower for 0 dBm at 20mA and for 10 dBm at 33mA. So an 10x increase in TX power costs only a 65% increase in current. This continues at higher power levels although not quite as striking. Still, all these rfm69hw's we have sitting around at powerLevel 0 are wasting a LOT of energy. ATC does not provide the savings one would assume.

So what's the lesson? I think it follows that one should use radio settings that cause the maximum tx power level to just be received by the gw. An automatic tuning mechanism should first increase the baud rate and only decrease tx power if at the maximum rate there's still excess power.

The maximum bitrate is 300kbit. I did a test using battery powered Moteino's today with these settings and could rx down to a max of -100dBm. -95dBm was pretty reliable.

Now I don't think I have any Moteino at the standard setting with the Pi2 gw that ever received lots of packets at that level. And most sit at powerLevel 0. In other words I think that with a low noise gateway all my HW's could run at 300kbit. And many at a very low powerLevel.

Now lets assume that these Moteinos are barely viable now at powerLevel 0. To take the bitrate from 55kbit to 300kbit we have to increase the power 6x. Looking at the data sheet we get from -1 to 10dBm, more than a 10x increase,  by increasing txpower by 17mA, which just about doubles it. Now this is an understatement, since some of the moteinos are very viable at power 0 can could easily exist at 300kbit at a lower power setting.

So there you have it: less than 1/3rd of power consumption just by using different radio settings. And much more with a low noise GW.

Of course the implementation will be a bit tricky if lower bitrates are needed for some nodes since the radios will need to share the same bandwidth using different radio settings.

There's is a side benefit to increasing baud rate: Given the lower rx times it is easier to get a signal through in a busy rf environment. So retransmits should be lower at an otherwise identical bit error rate.

Joe

PS: here are the settings used in the test:

Code: [Select]

RF_BITRATEMSB_300000, RF_BITRATELSB_300000, 
RF_FDEVMSB_300000, RF_FDEVLSB_300000,
RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0,
RF_PARAMP_40, RF_PACKET2_RXRESTARTDELAY_1BIT | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF,
RF_TESTLNA_HIGH_SENSITIVITY, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF,

   

[emjay]

@joelucid,

The thrust of your argument is largely correct - don't forget though that an increased bit rate requires a wider RxBw setting. This allows in more noise, dropping the critical rx signal S/N ratio.  So doubling the bit rate increases the error rate by the same amount as cutting tx power in half is not quite right.

[joelucid]

The thrust of your argument is largely correct - don't forget though that an increased bit rate requires a wider RxBw setting. This allows in more noise, dropping the critical rx signal S/N ratio.  So doubling the bit rate increases the error rate by the same amount as cutting tx power in half is not quite right.

That was exactly my view when I started to look at this. However according to the linked article carrier to noise is equal to Eb/N0  * fb/Bw. So if the modulation index (and thus fb/Bw) stays the same doubling the bitrate really should be the same as cutting tx in half, right?

[WhiteHare]

Maybe I'm not getting the point, but at the risk of oversimplifying, I think there may be an easier way to look at this:

1.  Temporarily setting aside the issue of BER by making the assumption that BER is zero, it seems clear that running at the highest bitrate is the optimal choice.  e.g. if, say, you can boost speed by 10x at an increase in cost of 70% current while transmitting, it's a huge win.  Yes the current is higher, but the area under the curve (with time as the x-axis) is so much less that it becomes a no-brainer.

2.  Then, adding BER back as a consideration, if most of the nodes can do the maximum bitrate, the question is whether you let the weakest link (perhaps the one in Joe's cesspit) govern the maximum bitrate allowed, or do you in some sense sacrifice it for the good of the many?  So to speak, do the needs of the many outweigh the needs of the few, or the one?

Well, if it means changing the battery more often in the cesspit node because it's struggling to do 300kbps and needs a lot more retransmits, then yeah, maybe the needs of the one are more important.     But if the weakest link is any other node (especially an easily accessible node), then the needs of the many (i.e. the net energy savings across all nodes) are what matter.

[Edit: Anyhow, getting good links at 300kbps obviously may be more difficult, and a low noise gateway is the cheapest way to help get there and should be the first choice in preference to raising Tx power.  Having the option of extra oopmh of an RFM69HW has always seemed desirable for this reason also.  As a last resort, if some nodes just can't do the higher speeds, then (as Joe noted on a different thread) it's cheap to just add another gateway (or possibly more than one) that's tailored to them and their lower bitrate requirements, or maybe you're able to position some extra gateways closer to them so that they can succeed at the higher bitrates. ]

[joelucid]

1.  Temporarily setting aside the issue of BER by making the assumption that BER is zero, it seems clear that running at the highest bitrate is the optimal choice.

Of course. The question is if BER is too low at 55kbit, tx power 31 what do you do? Do you decrease power or increase bitrate? Or both? The answer I've given is you increase bitrate until you're at 300kbit. Only then do you start decreasing tx power if the BER is still too low.

then the needs of the many (i.e. the net energy savings across all nodes) are what matter.

You want to run the weak nodes also at their optimum setting. Which means set tx power to 31 and reduce bitrate until BER is acceptable. If that's not possible then yeah you need to decide on cost of battery replacement where the pit scores pretty high 

[WhiteHare]

You want to run the weak nodes also at their optimum setting.

Right, though at present that may be a sticking point, as the standard gateway configuration only supports one bitrate on the theory that any node might Tx at any time.  In the general case (such as an alarm system with wireless nodes any one of which could be tripped at any random moment), I don't see a way to get around that limitation, unless maybe you're willing to accept some latency waiting for a tripped node's potential Tx window to open, with the gateway adjusting its receive bitrate beforehand to the node's individualized bitrate.  Or is there a way that I'm not aware of where in such a scenario you can have your cake and eat it too?

[joelucid]

Or is there a way that I'm not aware of where in such a scenario you can have your cake and eat it too?

Sure: two gateways 

Of course half a second in latency is hardly a problem with any scenario I can imagine. So I think you can run multiple nodes at different settings with one gw too.

[joelucid]

In other words I think that with a low noise gateway all my HW's could run at 300kbit. And many at a very low powerLevel.

It's really frustrating to try and test this:

I primarily have rfm69hw's. Even if I set tx power to -2 dBm (lowest the radio can deliver, that's a powerLevel of -4 in Felix nomenclature) and the bitrate to 300kbit there is no place in my apartment where I get an error rate of larger than zero.

Here's a typical run with the receiver in the fridge upstairs (metal case), sender downstairs, both moteinos powered from battery. Around 6750 packets, not one failure:

Code: [Select]

Apr 26 22:38:44 espgw.lx  1523581: !0, RS: -88, P: -2, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:46 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:46 espgw.lx  1524150: !0, RS: -87, P: -1, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:47 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:47 espgw.lx  1523828: !0, RS: -85, P: 0, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:49 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:49 espgw.lx  1523893: !0, RS: -85, P: 1, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:50 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:50 espgw.lx  1523793: !0, RS: -84, P: 2, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:52 espgw.lx  [20] [RX_RSSI:-35,1,8,45]
Apr 26 22:38:52 espgw.lx  1524107: !0, RS: -83, P: 3, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:53 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:53 espgw.lx  1523866: !0, RS: -82, P: 4, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:55 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:55 espgw.lx  1523429: !0, RS: -81, P: 5, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:56 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:56 espgw.lx  1524073: !0, RS: -80, P: 6, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:58 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:58 espgw.lx  1523889: !0, RS: -79, P: 7, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:38:59 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:38:59 espgw.lx  1523919: !0, RS: -78, P: 8, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:01 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:01 espgw.lx  1523791: !0, RS: -77, P: 9, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:03 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:03 espgw.lx  1523740: !0, RS: -76, P: 10, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:04 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:04 espgw.lx  1523990: !0, RS: -75, P: 11, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:06 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:06 espgw.lx  1523435: !0, RS: -74, P: 12, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:07 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:07 espgw.lx  1523672: !0, RS: -73, P: 13, Suc: 307, Fail: 0, Rt: 0
Apr 26 22:39:09 espgw.lx  [20] [RX_RSSI:-35,1,8,45]
Apr 26 22:39:09 espgw.lx  1521565: !0, RS: -76, P: 14, Suc: 305, Fail: 0, Rt: 0
Apr 26 22:39:10 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:10 espgw.lx  1524970: !0, RS: -74, P: 15, Suc: 306, Fail: 0, Rt: 0
Apr 26 22:39:12 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:12 espgw.lx  1524807: !0, RS: -74, P: 16, Suc: 306, Fail: 0, Rt: 0
Apr 26 22:39:13 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:13 espgw.lx  1524636: !0, RS: -73, P: 17, Suc: 306, Fail: 0, Rt: 0
Apr 26 22:39:15 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:15 espgw.lx  1524776: !0, RS: -72, P: 18, Suc: 306, Fail: 0, Rt: 0
Apr 26 22:39:16 espgw.lx  [20] [RX_RSSI:-34,6,8,45]
Apr 26 22:39:16 espgw.lx  1524819: !0, RS: -71, P: 19, Suc: 306, Fail: 0, Rt: 0
Apr 26 22:39:18 espgw.lx  [20] [RX_RSSI:-34,1,8,45]
Apr 26 22:39:18 espgw.lx  1524990: !0, RS: -70, P: 20, Suc: 306, Fail: 0, Rt: 0

Seems like I need to get an rfm69w moteino. Or hook one of my th-motes up to a real battery so I can run these tests on it.

If the receiving moteino is powered from the macbook usb outlet the picture looks completely different (same positions for both motes). Basically no matter what power, nothing gets through:

Code: [Select]

Apr 26 22:35:36 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:36 espgw.lx  3221857: !0, RS: -1, P: -2, Suc: 0, Fail: 32, Rt: 100
Apr 26 22:35:38 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:38 espgw.lx  2105193: !0, RS: -1, P: -1, Suc: 0, Fail: 32, Rt: 100
Apr 26 22:35:41 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:41 espgw.lx  3199072: !0, RS: -87, P: 0, Suc: 2, Fail: 31, Rt: 93
Apr 26 22:35:45 espgw.lx  [20] [RX_RSSI:-31,1,8,45]
Apr 26 22:35:45 espgw.lx  3197078: !0, RS: -91, P: 1, Suc: 2, Fail: 31, Rt: 93
Apr 26 22:35:46 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:46 espgw.lx  1523754: !0, RS: -89, P: 2, Suc: 3, Fail: 31, Rt: 91
Apr 26 22:35:48 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:48 espgw.lx  1550397: !0, RS: -1, P: 3, Suc: 0, Fail: 32, Rt: 100
Apr 26 22:35:49 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:49 espgw.lx  1527859: !0, RS: -87, P: 4, Suc: 4, Fail: 31, Rt: 88
Apr 26 22:35:51 espgw.lx  [20] [RX_RSSI:-31,1,8,45]
Apr 26 22:35:51 espgw.lx  2085991: !0, RS: -87, P: 5, Suc: 2, Fail: 31, Rt: 93
Apr 26 22:35:53 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:53 espgw.lx  1526920: !0, RS: -85, P: 6, Suc: 4, Fail: 31, Rt: 88
Apr 26 22:35:54 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:54 espgw.lx  1549319: !0, RS: -85, P: 7, Suc: 1, Fail: 32, Rt: 96
Apr 26 22:35:57 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:57 espgw.lx  2111610: !0, RS: -85, P: 8, Suc: 1, Fail: 32, Rt: 96
Apr 26 22:35:58 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:35:58 espgw.lx  1524769: !0, RS: -83, P: 9, Suc: 1, Fail: 31, Rt: 96
Apr 26 22:36:00 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:00 espgw.lx  1524826: !0, RS: -83, P: 10, Suc: 1, Fail: 31, Rt: 96
Apr 26 22:36:02 espgw.lx  [20] [RX_RSSI:-31,1,8,45]
Apr 26 22:36:02 espgw.lx  2092145: !0, RS: -80, P: 11, Suc: 5, Fail: 31, Rt: 86
Apr 26 22:36:03 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:03 espgw.lx  1549375: !0, RS: -79, P: 12, Suc: 1, Fail: 32, Rt: 96
Apr 26 22:36:05 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:05 espgw.lx  2090091: !0, RS: -79, P: 13, Suc: 4, Fail: 31, Rt: 88
Apr 26 22:36:07 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:07 espgw.lx  1528875: !0, RS: -79, P: 14, Suc: 3, Fail: 31, Rt: 91
Apr 26 22:36:08 espgw.lx  [20] [RX_RSSI:-31,1,8,45]
Apr 26 22:36:08 espgw.lx  1526876: !0, RS: -79, P: 15, Suc: 3, Fail: 31, Rt: 91
Apr 26 22:36:10 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:10 espgw.lx  1552467: !0, RS: -77, P: 16, Suc: 2, Fail: 32, Rt: 94
Apr 26 22:36:11 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:11 espgw.lx  1554772: !0, RS: -74, P: 17, Suc: 11, Fail: 31, Rt: 73
Apr 26 22:36:14 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:14 espgw.lx  2666357: !0, RS: -80, P: 18, Suc: 1, Fail: 32, Rt: 96
Apr 26 22:36:16 espgw.lx  [20] [RX_RSSI:-32,1,8,45]
Apr 26 22:36:16 espgw.lx  1554491: !0, RS: -77, P: 19, Suc: 2, Fail: 32, Rt: 94
Apr 26 22:36:17 espgw.lx  [20] [RX_RSSI:-31,1,8,45]
Apr 26 22:36:17 espgw.lx  1531958: !0, RS: -76, P: 20, Suc: 4, Fail: 31, Rt: 88

Joe

[WhiteHare]

Most of us would be happy to have zero errors, but if you want some errors for testing purposes, just stick with the first setup and add some impairments.  For example, set up a second unit and have it broadcast continuously at a different bitrate at low power or keep changing its transmission power from one burst to the next, and then bring it closer to your gateway/node until you get some failures.  Or even simpler, change the center frequency on your gateway so that there's only partial overlap with your wandering node.  I'm sure you can think of lots of ways.  Just detuning the antenna might be the easiest of all.

[joelucid]

Or even simpler, change the center frequency on your gateway so that there's only partial overlap with your wandering node.

Great idea! My first morning test was to move one node to the ground floor of our 5 story apartment building. Still: zero failures at -2 dBm. But now I moved the center frequency of one node by 318 khz and finally the zero failure purgatory doesn't begin until 8 dBm transmit power.

In this test I'm using an rxbw of 333 khz. Really speaks to the power of these transceivers that I have to detune by a full rxbw to finally see decent errors.

Most of us would be happy to have zero errors

I am pretty happy about that part. But I want test the assumptions of this thread, namely that doubling tx power is the same as cutting bitrate in half.

[joelucid]

Really speaks to the power of these transceivers that I have to detune by a full rxbw to finally see decent errors.

Or to the stupidity of the tester - you need to write the LSB of the freq register for the changes to become effective. Now I do get errors even at 76khz offset, but regardless of powerlevel. I'm just going to use a TH mote instead.

[joelucid]

Just detuning the antenna might be the easiest of all.

Turns out that was the most useful suggestion. And boy did I detune the antenna: I simply removed it.

Moteino 1 upstairs with antenna, Moteino 2 downstairs without. At 100kbit that's error free starting from ~0 dBm (1 mW). At 300kbit it's error free starting from 5 dBm (3.2 mW). 300 : 100 ~= 3.2 : 1, so early indications support  the theory.

Joe

[WhiteHare]

Yeah, when I was doing the RSSI measurement experiments emjay had me not only remove the antenna, but solder tack it to ground.  Surprisingly, even then I could still receive and successfully decode some packets.  So, to finally remove all that as well as all other RF sources from the equation, I later shifted to the more extreme method of running the Moteino on a battery and putting the entire shebang in a sealed metal can.

As you probably know--but for the benefit of anyone else reading this--you should refrain from transmitting on a  Moteino whose antenna has been removed (or even just highly detuned), or else you allegedly risk damaging the unit.  Apparently there's no risk to receiving with it though.

[joelucid]

Yeah, when I was doing the RSSI measurement experiments emjay had me not only remove the antenna, but solder tack it to ground.  Surprisingly, even then I could still receive and successfully decode some packets.

That's what they call a loop antenna 

As you probably know--but for the benefit of anyone else reading this--you should refrain from transmitting on a  Moteino whose antenna has been removed (or even just highly detuned), or else you allegedly risk damaging the unit.  Apparently there's no risk to receiving with it though.

- but then how do I test with RFM69HW's given they show perfect transmission in the entire house with 300kbit and -2dBm? Hey - if it dies at least it was for science ...

[joelucid]

Update with RFM69W:

-17 dBm @ 300kbit all throughout the house. I guess the adaptive bitrate feature just dropped a little in priority.

So I thought once you have a gw that is as sensitive as a battery powered Moteino how would you take advantage of it? As test I curled up the 433 mhz antenna on the mote into a 1cm long tight spiral (see below). This setup now achieves perfect transmission at 300kbit at -8 dBm. I always disliked these wires ...

[perky]

Why not just solder a 50R SMD resistor (0603) across the ANT and GND terminals on the top of the package? Minimal stub, matched with a dummy load so you can TX without damage. We're talking 100mW of power so should be OK (you can get 100mW 0603s as standard, but that's 100mW transmitting continuously so lower duty cycles will be fine).
Mark.

[WhiteHare]

Code: [Select]

RF_BITRATEMSB_300000, RF_BITRATELSB_300000, 
RF_FDEVMSB_300000, RF_FDEVLSB_300000,
RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0,
RF_PARAMP_40, RF_PACKET2_RXRESTARTDELAY_1BIT | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF,
RF_TESTLNA_HIGH_SENSITIVITY, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF,

 

This is a good thread.  After a hiatus, I'm now circling back to upgrade my code to run at 300kbps.  Are the above still regarded as the optimal settings for 300kbps bitrate?

[Edit: Looks as though for 300kbps the current preferred RxBw is 500khz:  https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/changing-the-rmf69hcw-configuration-and-back/msg15219/#msg15219  , which is in agreement with the above.

I seem to recall the LNA high sensitivity setting was only to be enabled for the narrowest bandwidth, whereas the above seems (?) to have it enabled even at the widest bandwidth. Is that an error, or is it correct?  The datasheet seems to imply it reduces the noise floor, which might always be a good idea to run in any case if the increased power of running it is an acceptable trade-off.  Anyone know how much extra current draw is with the LNA turned on?  Or is that yet to be measured?]

[joelucid]

WhiteHare, I have since run pretty extensive tests testing different modulation indexes at 300kbit. I would send the best settings I've come up with but I won't have my laptop around until end of the week. I'll follow up then.

joe

[WhiteHare]

WhiteHare, I have since run pretty extensive tests testing different modulation indexes at 300kbit. I would send the best settings I've come up with but I won't have my laptop around until end of the week. I'll follow up then.

joe

Thanks!  I look forward to that.

I'm thinking that since the gateway isn't battery powered, it can transmit at high power for free, which would in a home environment likely save a wireless node from needing to turn-on the LNA sensitivity, except maybe as a last ditch fallback if it fails to receive.  Conversely, if it turns out turning-on LNA sensitivity has benefit at the high bandwidth (and I guess your testing might show whether or not it does), then the gateway could use it, and perhaps a wireless node could use a lower Tx (although in your case you said even the lowest Tx setting on an RFM69HW was still sufficient, so maybe it might matter on an RFM69W).  I remember from my RSSI noise floor testing that turning on LNA sensitivity does indeed appear to lower the noise floor at the narrowest bandwidth.

[WhiteHare]

In theory RxBwAfc should be wider than RxBw, but the way this radio works that's not possible if RxBw=500kHz, because 500kHz is the widest bandwidth that can be specified for RxBwAfc.  [Edit: Not sure if that may have unintended consequences, like possibly impairing (?) AFC or something like that.  On the other hand, maybe at the wider bandwidths the worst case frequency misalignment  would not be significant enough (?) to worry about. ]

[perky]

At 300kHz FDEV and 300kbps BR you'll need RxBw >= 450kHz, the nearest to that is 500kHz. Setting RxBwAfc to 500kHz gives you 50kHz for clock offsets. RxBwAfc doesn't have to be wider than RxBw, it just needs to be big enough to cover the signal bandwidth plus the LO offset.
Mark.

[WhiteHare]

At 300kHz FDEV and 300kHz BR you'll need RxBw >= 450kHz, the nearest to that is 500kHz. Setting RxBwAfc to 500kHz gives you 50kHz for clock offsets. RxBwAfc doesn't have to be wider than RxBw, it just needs to be big enough to cover the signal bandwidth plus the LO offset.
Mark.

Oh, I get it now.  Thanks.  I keep forgetting that the RxBw is only used for setting the Rx, and has no affect on Tx.  [Edit: apparently the Tx bandwidth is purely a function of the bitrate, and so the Tx bandwidth just naturally widens as bitrate increases.  i.e. Tx bandwidth is not a parameter you set per se, but just a physical consequence of the bitrate.  At least, without really knowing, I'm inferring that's how it works...  ]

[WhiteHare]

So, I upgraded now to running at 300kbps as the default, and all is good.   

Not surprisingly, RSSI is a lot lower than with a narrower bandwidth.  What did surprise me, though, is that RSSI seems to fall at a much lower rate with distance.    Not sure why that is, but I'm glad for it.   

[Edit: Doh!  Of course, because it's a logarithmic scale, not a linear one.   ]

[joelucid]

Actually RSSI should not be lower using a higher fdev. You're just spreading out the signal across a larger freq range. If rxbw is large enough there should be little difference. What you will see is a higher noise floor and better rssi needed to get the signal across.

Joe

[WhiteHare]

I guess my settings are wrong then, because RSSI appears to be a lot lower.  Here are the settings and then results from 10 feet away:

Radio Configuration:
====================
Receiver-Mode(RX)
Packet Mode, FSK modulation scheme
RegDioMapping1=B1000000=0x40
RegDioMapping2=B111=0x7
[ActualBitrate] 299065.406bps
[theDccFreq] B10 (equals Semtech default)
[RxBw] 500000Hz
  [RxBwMant] 16
  [RxBwExp] 0
[FDEV] 250000Hz
Beta=((2*FDev)/BitRate)=1.67
Fcutoff=19894.37Hz
  Percentage=3.98%
Warning: low Beta.
[theDccFreqAfc] B100 (equals Semtech default)
[RxBwAfc] 500000Hz
  [RxBwMantAfc] 16
  [RxBwExpAfc] 0
[frequency-center] 915000000Hz
[regLNA] B1000
  [LnaZin] B0 -> Input Impedance = 50 ohm (Warning: Semtech default is 200 ohm).
  [LnaCurrentGain] B1 -> G1
  [LnaGainSelect] B0 -> gain set by the internal AGC loop.  Matches Semtech default.
[regAFCFEI] B10000
  [FeiDone] B0 -> FEI is on-going (i.e. not finished).  Matches Semtech default.
  [AfcDone] B1 -> AFC is finished (i.e. not on-going).  Matches Semtech default.
  [AfcAutoclearOn] B0 -> Invalid, because AfcAutoOn is not set.
  [AfcAutoOn] B0 -> AFC is performed each time AfcStart is set (i.e. not each time Rx mode is entered).
               ^Matches Semtech default.
RegPaLevel=B1111111
theRegOCP=0xF
RegTestPa1=0x55
RegTestPa2=0x70
RegRssiThresh=0xDC
   ==> RSSI Threshold = -110.0dB
---------------------------------------------------------------------
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-104]
 - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-103]
 - ACK sent.
#[3][2] 12   [RX_RSSI:-107]
 - ACK sent.
#[4][2] 123   [RX_RSSI:-111]
 - ACK sent. Pinging node 2 - ACK...ok!
#[5][2] 123    [RX_RSSI:-102]
 - ACK sent.
#[6][2] 123    [RX_RSSI:-102]
 - ACK sent.
#[7][2] 123 A   [RX_RSSI:-104]
 - ACK sent. Pinging node 2 - ACK...ok!
#[8][2] 123 AB   [RX_RSSI:-103]
 - ACK sent.

[perky]

You have a low modulation index, I think you forgot to change FDEV to 300kHz as well.
Mark.

[WhiteHare]

Thanks.  Made that change, but still no joy:

Radio Configuration:
====================
Receiver-Mode(RX)
Packet Mode, FSK modulation scheme
RegDioMapping1=B1000000=0x40
RegDioMapping2=B111=0x7
[ActualBitrate] 299065.406bps
[theDccFreq] B10 (equals Semtech default)
[RxBw] 500000Hz
  [RxBwMant] 16
  [RxBwExp] 0
[FDEV] 299987Hz
Beta=((2*FDEV)/BitRate)=2.01
Fcutoff=19894.37Hz
  Percentage=3.98%
[theDccFreqAfc] B100 (equals Semtech default)
[RxBwAfc] 500000Hz
  [RxBwMantAfc] 16
  [RxBwExpAfc] 0
[frequency-center] 915000000Hz
[regLNA] B1000
  [LnaZin] B0 -> Input Impedance = 50 ohm (Warning: Semtech default is 200 ohm).
  [LnaCurrentGain] B1 -> G1
  [LnaGainSelect] B0 -> gain set by the internal AGC loop.  Matches Semtech default.
[regAFCFEI] B10000
  [FeiDone] B0 -> FEI is on-going (i.e. not finished).  Matches Semtech default.
  [AfcDone] B1 -> AFC is finished (i.e. not on-going).  Matches Semtech default.
  [AfcAutoclearOn] B0 -> Invalid, because AfcAutoOn is not set.
  [AfcAutoOn] B0 -> AFC is performed each time AfcStart is set (i.e. not each time Rx mode is entered).
               ^Matches Semtech default.
RegPaLevel=B1111111
theRegOCP=0xF
RegTestPa1=0x55
RegTestPa2=0x70
RegRssiThresh=0xDC
   ==> RSSI Threshold = -110.0dB
---------------------------------------------------------------------
#[1][2] FLASH_MEM_ID:0xEF30   [RX_RSSI:-103]
 - ACK sent. Pinging node 2 - ACK...ok!
#[2][2] 1   [RX_RSSI:-102]
 - ACK sent.
#[3][2] 12   [RX_RSSI:-102]
 - ACK sent.
#[4][2] 123   [RX_RSSI:-104]
 - ACK sent. Pinging node 2 - ACK...nothing
#[5][2] 123    [RX_RSSI:-107]
 - ACK sent.
#[6][2] 123 A   [RX_RSSI:-101]
 - ACK sent.
#[7][2] 123 AB   [RX_RSSI:-103]
 - ACK sent. Pinging node 2 - ACK...nothing

[perky]

Ok, try turning auto Afc on? Currently AfcAutoOn is not set, which means unless you're manually triggering there may be a local oscillator offset in your TX and RX frequencies.
RegOcp, RegTestPa1 and RegTestPa2 are set strangely. I'm not sure what the library you're using does with these, see section 3.3.7 in the sx1231h spec.

Mark.

[joelucid]

Here are my 300kbit settings:

Code: [Select]

SX1231_REG_BITRATEMSB, SX1231_BITRATEMSB_300000,
SX1231_REG_BITRATELSB, SX1231_BITRATELSB_300000,
SX1231_REG_FDEVMSB, SX1231_FDEVMSB_200000,
SX1231_REG_FDEVLSB, SX1231_FDEVLSB_200000,
SX1231_REG_RXBW, SX1231_RXBW_DCCFREQ_010 | SX1231_RXBW_400000,
SX1231_REG_RSSITHRESH, 255,
SX1231_REG_PREAMBLELSB, 6,
SX1231_REG_PACKETCONFIG2, SX1231_PACKET2_RXRESTARTDELAY_2BITS | SX1231_PACKET2_AUTORXRESTART_OFF |  SX1231_PACKET2_AES_OFF,
SX1231_REG_PACKETCONFIG1, SX1231_PACKET1_FORMAT_VARIABLE | SX1231_PACKET1_DCFREE_WHITENING | SX1231_PACKET1_CRC_ON | SX1231_PACKET1_CRCAUTOCLEAR_ON | SX1231_PACKET1_ADRSFILTERING_OFF,
SX1231_REG_PARAMP, SX1231_PARAMP_10,
SX1231_REG_LNA, SX1231_LNA_GAINSELECT_MAX

I'm using a fairly low modulation index which was determined by trying the full range. AFC and AGC are off, gain at max and rssi thresh at 255 - this works well when nodes aren't too close to each other. I found I needed a longer preamble at 300kbit - here it's 6 bytes. I don't recall why this was necessary.

Joe

[WhiteHare]

Ok, try turning auto Afc on? Currently AfcAutoOn is not set, which means unless you're manually triggering there may be a local oscillator offset in your TX and RX frequencies.
RegOcp, RegTestPa1 and RegTestPa2 are set strangely. I'm not sure what the library you're using does with these, see section 3.3.7 in the sx1231h spec.

Mark.

I decided to start with a clean slate.  I boiled it down to the following, which I add to the end of setup in Felix's node and gateway examples:

Code: [Select]

  // set baud rate to 300kbps
  // equals 0x006B according to datasheet table 9
  radio.writeReg(0x03,0x00);  //set regBitrateMsb
  radio.writeReg(0x04,0x6B);  //set regBitrateLsb

  //set RxBW to 500kHz
  radio.writeReg(0x19,0x40);  

  //set RxBWAfc to 500kHz
  radio.writeReg(0x1A,0x80);

  // Set FDEV to 300khz, implies Fdev=0x1333
  // Set Fdev registers:
  radio.writeReg(0x05,0x13);  //write MSB of Fdev
  radio.writeReg(0x06,0x33);  //write LSB of Fdev  
}

The result is the same.  It must be something obvious that's staring me in the face, but so far I don't see what it is.

[WhiteHare]

It probably has something to do with how I'm setting the bitrate, because if I keep the bitrate the same as in Felix's example code, but change the RxBw, RxBwAfc, and FDEV as in the boiled down version, then RSSI is correct (i.e. the same as before changing them), and I continue to receive packets at the lower bitrate (55,555bps).

[perky]

BR calcs are wrong, I use 12kb/s and the MSB is 0xA!
Forget that, my mistake. I calculate 0x006B for 300kHz.

Mark.

[perky]

Didn't we have some strange anomoly with reading RSSI before that appeared to be BR dependent? I came to the conclusion the best place to read it was after the payloadreay interrupt, but before reading data out of the FIFO as this is frozen until the next RX reset event (i.e. reading data out of the FIFO).

[WhiteHare]

I think I found my  mistake.  I wasn't raising the RSSI threshhold.  -110db worked OK at the narrower threshhold bandwidth, but I should have raised the threshhold for the much higher (and noisier) bandwidth.  So, apparently RSSI would trigger on noise alone but then decode anyway.  So, the RSSI that was getting reported was the abnormally low noise figure rather than the actual transmitted RSSI.

[perky]

OK, that sounds sensible.

[WhiteHare]

I'll try Joe's settings now.  His RSSI threshhold is set to the absolute lowest possible, though, so maybe he's doing something non-standard wrt to that?

[joelucid]

I'll try Joe's settings now.  His RSSI threshhold is set to the absolute lowest possible, though, so maybe he's doing something non-standard wrt to that?

You can either set the rssi thresh so low that it triggers on background noise right away or try to set it such that it's above the noise floor. The RFM69 uses the first approach due to its very low threshold. The advantage is that then you don't need to determine the noise floor which can be a pretty dynamic problem esp with low bitrates that only require minimal signal to noise ratios. The disadvantage is that AGC doesn't work because it sets gain according to background noise.

For these tests I've also used the first approach but made it more explicit by setting rssithresh to 255. Even if for this particular bitrate signal to noise needs to be fairly high so determining a good enough noise floor might work.

Rfm69 lib records rssi at packet available so it shouldn't matter either way.

[WhiteHare]

Here are my 300kbit settings:

Code: [Select]

SX1231_REG_BITRATEMSB, SX1231_BITRATEMSB_300000,
SX1231_REG_BITRATELSB, SX1231_BITRATELSB_300000,
SX1231_REG_FDEVMSB, SX1231_FDEVMSB_200000,
SX1231_REG_FDEVLSB, SX1231_FDEVLSB_200000,
SX1231_REG_RXBW, SX1231_RXBW_DCCFREQ_010 | SX1231_RXBW_400000,
SX1231_REG_RSSITHRESH, 255,
SX1231_REG_PREAMBLELSB, 6,
SX1231_REG_PACKETCONFIG2, SX1231_PACKET2_RXRESTARTDELAY_2BITS | SX1231_PACKET2_AUTORXRESTART_OFF |  SX1231_PACKET2_AES_OFF,
SX1231_REG_PACKETCONFIG1, SX1231_PACKET1_FORMAT_VARIABLE | SX1231_PACKET1_DCFREE_WHITENING | SX1231_PACKET1_CRC_ON | SX1231_PACKET1_CRCAUTOCLEAR_ON | SX1231_PACKET1_ADRSFILTERING_OFF,
SX1231_REG_PARAMP, SX1231_PARAMP_10,
SX1231_REG_LNA, SX1231_LNA_GAINSELECT_MAX

It looks as though you're setting DCC to 010 even though, in this scenario, that results in low beta?

Or, maybe I'm calculating it wrong.  With your other settings, my calculations are:
[FDev] 3277Hz
[FDEV] 200012Hz
Beta=((2*FDev)/BitRate)=0.02
Fcutoff=15915.50Hz
  Percentage=3.98%

On a different topic: you aren't doing address filtering, and I guess maybe that's because you aren't sending addresses?  And that is because... why?  Is it to save energy (or make smaller frames) from not sending address bits?  Instead of addresses I gather you used time division to differentiate the intended recipient?  Or just embed the address  in the packet if and when it's needed?

It's also interesting that you aren't doing encryption.  Any particular reason?

[Edit1: Also, for the benefit of anyone else who may be reading this, I presume when you're setting the REG_LNA that you're setting LnaZin (bit 7) to zero to designate an input impedance of 50 ohms.  The default setting is 200 ohms.]

[Edit2: Likewise, I presume you have AFC turned off because of the wide RxBW?  I also presume that because you don't appear to be setting RxBwAFC anywhere.]

[perky]

Or, maybe I'm calculating it wrong.  With your other settings, my calculations are:
[FDev] 3277Hz
[FDEV] 200012Hz
Beta=((2*FDev)/BitRate)=0.02
Fcutoff=15915.50Hz
  Percentage=3.98%

Note sure how you got this value for FDEV, that beta calculation is way off! ;-)
Mark.

[WhiteHare]

OK, thanks.  Apparently I need to revisit the topic.

[WhiteHare]

Anyway, Joe's settings run great.  They are my new defaults.  Thanks, Joe!

[joelucid]

Beta is 2x fdev / Bitrate which is around 1.3 which is not yet low beta. I've tested multiple betas and this gets me the best PER.

Great that these settings work well for you. I generally go only up to 200kbit since then I can use 3 bytes preamble for all settings. Yeah I use neither AGC nor AFC and 50 Ohm.

You're right, I don't use address filtering. Originally that was because I'm used to it (RFM69 does that too to enable promiscuous mode). But today it also comes in handy because it allows reception of the smallest possible variable size packet: just a 0 Len byte. Even with encryption enabled this doesn't add the 16 bytes for the first chunk of encrypted data. This makes rapid sync possible for frequency hopping.