Author Topic: Optimizing radio settings for power (rfm69w/hw) [+300kbps settings]  (Read 23304 times)

joelucid

  • Hero Member
  • *****
  • Posts: 868
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,

   
« Last Edit: November 17, 2016, 08:56:36 PM by Felix »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #1 on: April 15, 2016, 08:19:51 AM »
@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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #2 on: April 15, 2016, 08:28:54 AM »
Quote
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

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #3 on: April 15, 2016, 11:21:16 AM »
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. ]

« Last Edit: April 15, 2016, 12:09:58 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #4 on: April 15, 2016, 11:58:40 AM »
Quote
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.

Quote
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

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #5 on: April 15, 2016, 12:42:22 PM »

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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #6 on: April 15, 2016, 12:57:36 PM »
Quote
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  :D

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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #7 on: April 26, 2016, 04:43:13 PM »
Quote
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

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #8 on: April 26, 2016, 08:13:12 PM »
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.
« Last Edit: April 26, 2016, 09:00:13 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #9 on: April 27, 2016, 12:28:40 AM »
Quote
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.

Quote
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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #10 on: April 27, 2016, 12:59:32 AM »
Quote
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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #11 on: April 27, 2016, 02:25:35 AM »
Quote
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

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #12 on: April 27, 2016, 04:15:17 AM »
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

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #13 on: April 27, 2016, 04:36:16 AM »
Quote
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  ;)

Quote
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 ...
« Last Edit: April 27, 2016, 04:47:47 AM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Optimizing radio settings for power (rfm69w/hw)
« Reply #14 on: April 27, 2016, 05:33:20 AM »
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 ...