Is packet loss common?

[madsci1016]

Getting up to speed with this Moeino boards. Have several with RFM69HW  radios. Testing them in promiscuous mode in one direction. I have some test code that goes

Code: [Select]

  payload[VAL_MODE]++;
  radio.send(0, payload, sizeof(payload), false);
  delay(30);

And the output on the other end

Code: [Select]

New RX
2:0:0:0
New RX
4:0:0:0
New RX
6:0:0:0
New RX
12:0:0:0
New RX
14:0:0:0
New RX
17:0:0:0
New RX
22:0:0:0
New RX
25:0:0:0
New RX
28:0:0:0
New RX
29:0:0:0
New RX
31:0:0:0
New RX
33:0:0:0
New RX
38:0:0:0
New RX
40:0:0:0
New RX
45:0:0:0
New RX
52:0:0:0
New RX
55:0:0:0
New RX
58:0:0:0
New RX
62:0:0:0
New RX
67:0:0:0
New RX
69:0:0:0
New RX
78:0:0:0
New RX
80:0:0:0
New RX
82:0:0:0
New RX
84:0:0:0
New RX
89:0:0:0

So as you can see I'm missing a bunch of packets. Radios are both being powered by FTDI boards. They are 6" away from each other on my lab bench. I slow it down to 1 second waits and i still miss packets.

IS this normal for these radios? Is this why the majority of the examples all use ACK mode for transmission?

[madsci1016]

look like situation improves when I reduce the size of the payload. Was using 41 bytes @ 33ms delay, dropping down to 10 bytes looks almost perfect.

Is there a speed limit I am hitting somewhere? Should I fiddle with bitrate?

*looks at library code*

So by default the bitrate is 4800, so I'm hitting that limit. I've tried un-commenting #define BR_300KBPS  but the radios don't work when I do. What is the upper limit for bitrate in these radios?

[ChemE]

The upper limit is 300kbps and a bunch of us run at this speed to maximize battery life.  I tend to get around 1% packet loss when I do my testing but then I live in a neighborhood <2 miles from downtown.  Not sure if this would fall significantly if I was out in the country but others should be able to speak to that.

There are other threads in the RFM69 section of the forums that discuss running at 300kbps but here are the settings which work for me:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/changing-the-rmf69hcw-configuration-and-back/msg17071/#msg17071

[madsci1016]

I got both radios working at 300kbps, seems like I just had to turn off encryption. But I'm still getting high packet loss sending 41 bytes every 33ms. Is there some limit I'm hitting elsewhere?

[WhiteHare]

From a recent thread, JoeLucid's experience suggested that at 300kbps you're better off with at least 4 preamble bytes and and at least three sync bytes.  Those are greater than the defaults, so you may want to try increasing yours.

Data whitening might help.  It's not defaulted either.

Beyond that, what RSSI levels are you getting?  Higher speeds need a higher signal-to-noise ratio, so you may want to measure both.

My first guess though: 6" apart sounds too close.  You're probably saturating your radios.  Try moving them apart to a more reasonable distance, like, say, 10 or 15 feet apart, line-of-sight.  That's still close, but not overly so.

My second guess: your FTDI adapters  don't supply enough juice.  So, when you send packets at a faster pace, that becomes more noticeable, because any caps are draining and not given enough time to refill before the next packet.  As a workaround, try powering your moteino's with batteries instead.

[madsci1016]

Thanks, moved radios to 8' with similar results.

So my application I'm looking at a need for 41 bytes bytes every 33ms. I'm actually trying to stream 40 DMX channels to several receivers in a broadcast type setup. So by my math I really only need about 20kbps.

I'm trying it now at 115k just because it's any even modem rate.

Code: [Select]

  radio.writeReg(0x03, RF_BITRATEMSB_115200  );  
  radio.writeReg(0x04, RF_BITRATELSB_115200 );  
  radio.writeReg(0x19, 0x40);  //REG_RXBW: 500kHz
  radio.writeReg(0x1A, 0x80);  //REG_AFCBW: 500kHz
  radio.writeReg(0x05, 0x13);  //REG_FDEVMSB: 300khz (0x1333)
  radio.writeReg(0x06, 0x33);  //REG_FDEVLSB: 300khz (0x1333)
  radio.writeReg(0x29, 240);   //set REG_RSSITHRESH to -120dBm

But I'm having a hard time finding the guidance on how to adjust the other radio attributes to mesh with the change in bitrate.

I'm also seeing a lot of references to 'continuous mode' TX, which may be what I want in my application but haven't found any instructions or examples of how to use that mode.

I'll dig into the library code to look for preamble sync and whitening to make those changes. 

[madsci1016]

Arg.

My settings:

Code: [Select]

/* 0x2D */ { REG_PREAMBLELSB, 0x4 },
 /* 0x2E */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_3 | RF_SYNC_TOL_0 },
  radio.writeReg(0x03, RF_BITRATEMSB_115200  );  //REG_BITRATEMSB: 300kbps (0x006B, see DS p20)
  radio.writeReg(0x04, RF_BITRATELSB_115200 );  //REG_BITRATELSB: 300kbps (0x006B, see DS p20)
  radio.writeReg(0x19, 0x40);  //REG_RXBW: 500kHz
  radio.writeReg(0x1A, 0x80);  //REG_AFCBW: 500kHz
  radio.writeReg(0x05, 0x13);  //REG_FDEVMSB: 300khz (0x1333)
  radio.writeReg(0x06, 0x33);  //REG_FDEVLSB: 300khz (0x1333)
  radio.writeReg(0x29, 240);   //set REG_RSSITHRESH to -120dBm

TX code:

Code: [Select]

void loop() {
  
  payload[VAL_MODE]++;
  radio.send(255, payload, sizeof(payload), false);
  delay(33);

RX

 

Code: [Select]

if (radio.receiveDone())
  {
    //new packet received. 
    //Serial.println("New RX");
    /*
    Serial.print("Got [");
    Serial.print(radio.SENDERID);
    Serial.print(':');
    Serial.print(radio.DATALEN);
    Serial.print("] > ");
    for (byte i = 0; i < radio.DATALEN; i++)
      Serial.print(radio.DATA[i], HEX);
    Serial.println();
    */
    //if it's 4 bytes, it's probably OTA Update request
    if(radio.DATALEN == 4)
    {
      Serial.println("OTA?");
      CheckForWirelessHEX(radio, flash, false);
    }
    else
    {
      uint16_t base_address = (SUITADDRESS - 1) * 4;
      
      strip.setBrightness(radio.DATA[base_address + VAL_BRIGHTNESS]);
      
      Serial.print(radio.DATA[base_address + VAL_MODE]);
      Serial.print(':');
      Serial.print(radio.DATA[base_address + VAL_BRIGHTNESS]);
      Serial.print(':');
      Serial.print(radio.DATA[base_address + VAL_COLOR]);
      Serial.print(':');
      Serial.print(radio.DATA[base_address + VAL_SPEED]);
      Serial.print(':');
      Serial.println(radio.readRSSI(false));

Result:

Code: [Select]

28:0:0:0:-21
30:0:0:0:-21
34:0:0:0:-21
38:0:0:0:-21
45:0:0:0:-21
48:0:0:0:-21
51:0:0:0:-21
54:0:0:0:-21
55:0:0:0:-27
58:0:0:0:-21
60:0:0:0:-21
62:0:0:0:-21
73:0:0:0:-22
78:0:0:0:-21
81:0:0:0:-21
83:0:0:0:-22
87:0:0:0:-21
91:0:0:0:-22
96:0:0:0:-21
107:0:0:0:-22

All sorts of packet loss @ 41 byte payload.

[WhiteHare]

A lot of radio problems turn out to be power supply related.  I'd check that next.

[madsci1016]

The upper limit is 300kbps and a bunch of us run at this speed to maximize battery life.  I tend to get around 1% packet loss when I do my testing but then I live in a neighborhood <2 miles from downtown.  Not sure if this would fall significantly if I was out in the country but others should be able to speak to that.

There are other threads in the RFM69 section of the forums that discuss running at 300kbps but here are the settings which work for me:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/changing-the-rmf69hcw-configuration-and-back/msg17071/#msg17071

Woah, his settings are an improvement.

Code: [Select]

79:0:0:0:-103
80:0:0:0:-96
81:0:0:0:-98
82:0:0:0:-88
83:0:0:0:-103
84:0:0:0:-103
85:0:0:0:-100
86:0:0:0:-102
87:0:0:0:-104
88:0:0:0:-104
89:0:0:0:-104
90:0:0:0:-98
91:0:0:0:-108
92:0:0:0:-91
93:0:0:0:-102
94:0:0:0:-98
95:0:0:0:-100
96:0:0:0:-101
97:0:0:0:-102
98:0:0:0:-104
99:0:0:0:-98
100:0:0:0:-104
101:0:0:0:-98
102:0:0:0:-104
103:0:0:0:-103
104:0:0:0:-106
105:0:0:0:-107
106:0:0:0:-103
107:0:0:0:-102
108:0:0:0:-97
109:0:0:0:-98
110:0:0:0:-102
111:0:0:0:-98
112:0:0:0:-99
113:0:0:0:-103
114:0:0:0:-100
115:0:0:0:-102
116:0:0:0:-107
117:0:0:0:-102
118:0:0:0:-104
119:0:0:0:-108
120:0:0:0:-97
121:0:0:0:-103
122:0:0:0:-92
123:0:0:0:-101
124:0:0:0:-100
125:0:0:0:-104

But RSSI is bottomed out. Should that be expected?

Sorry for question overload. Appreciate any who help me understand these radios.

[madsci1016]

A lot of radio problems turn out to be power supply related.  I'd check that next.

Definitely agree I used ESP8266's often, I'm using sparkfun FTDI boards here straight off a 7 port powered hub, so I hope it's not related to power.

[ChemE]

Your RX code it waiting until the last possible microsecond to read the radio's RSSI and after a bunch of slow serial.prints.  You really should be reading it as soon as you detect that a packet has been received and cache it for later output.  Reason being is RSSI is most accurate as the packet comes in and starts becoming less accurate as time passes.  Probably wont push those -108s up to -27 but it will increase them some.  I don't get anywhere near those low signals when I test at power level 0 with my settings btw.  I get -50s at power level 0 and -25ish at power level 31.

[madsci1016]

I moved it to

Code: [Select]

 if (radio.receiveDone())
  {
    int pwr = radio.readRSSI(false);
    //new packet received. 

And still get

Code: [Select]

206:0:0:0:-103
207:0:0:0:-104
208:0:0:0:-99
209:0:0:0:-104
210:0:0:0:-102
211:0:0:0:-110
212:0:0:0:-93
213:0:0:0:-103
214:0:0:0:-103

And just to be sure my TX is now

Code: [Select]

void setup() {
  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
  radio.setPowerLevel(31);
  radio.setHighPower(); //uncomment only for RFM69HW!

I'm actually using your settings ChemE, not sure why just changing from stock to yours is showing a 80 difference in power.

[madsci1016]

Just to be sure, without changing the user sketchs; just the config structure in the RF69 library, stock I get

Code: [Select]

49:0:0:0:-18
54:0:0:0:-18
56:0:0:0:-18
62:0:0:0:-18
71:0:0:0:-18
73:0:0:0:-18
74:0:0:0:-26
80:0:0:0:-18
82:0:0:0:-18
89:0:0:0:-20
92:0:0:0:-17
96:0:0:0:-19
97:0:0:0:-27
103:0:0:0:-18
104:0:0:0:-28
105:0:0:0:-28
107:0:0:0:-17
109:0:0:0:-18

And using your posted config:

Code: [Select]

225:0:0:0:-104
226:0:0:0:-104
227:0:0:0:-105
228:0:0:0:-103
229:0:0:0:-99
230:0:0:0:-100
231:0:0:0:-102
232:0:0:0:-103
233:0:0:0:-103
234:0:0:0:-93
235:0:0:0:-99
236:0:0:0:-92
237:0:0:0:-92
238:0:0:0:-102
239:0:0:0:-102
240:0:0:0:-99
241:0:0:0:-103
242:0:0:0:-106
243:0:0:0:-85
244:0:0:0:-103
245:0:0:0:-101
246:0:0:0:-107
247:0:0:0:-103

Definite difference is packet loss, by alarming jump in RSSI.

[madsci1016]

Well in trying to find the setting that affects RSSI, (I would change one thing about the config and test to see if it changes result) I found by leaving the bitrate 'stock' to the library

Code: [Select]

    /* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_55555}, // default: 4.8 KBPS
    /* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_55555},
    /* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_50000}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
    /* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_50000},

I suddenly get good reception with high RSSI.

Code: [Select]

24:0:0:0:-27
25:0:0:0:-27
26:0:0:0:-27
27:0:0:0:-27
28:0:0:0:-27
29:0:0:0:-27
30:0:0:0:-27
31:0:0:0:-27
32:0:0:0:-27
33:0:0:0:-28
34:0:0:0:-26
35:0:0:0:-27
36:0:0:0:-28
37:0:0:0:-27
38:0:0:0:-27
39:0:0:0:-27
40:0:0:0:-26
41:0:0:0:-27
42:0:0:0:-27
43:0:0:0:-28
44:0:0:0:-28

Which doesn't make sense. How am I getting reception of 41 bytes every 33ms @ 4800 baud? And why does just turning off CRC make that happen?

Code: [Select]

RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON

to

Code: [Select]

RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF

[ChemE]

What happens if you use my 300kbps settings but dial down your broadcast frequency to just a few times a second?  I'm wondering if like WhiteHare said you have power supply issues.