Is packet loss common?

[ChemE]

And why does just turning off CRC make that happen?

Code Select Expand

RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON

to

Code Select Expand

RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF

Could be that you are getting one or more bit errors in a large fraction of your packets.  I turn off CRC which would let bit error packets come through.  So you might be getting a high fraction through but they are malformed.  Also regarding high packet loss originally at 55kbps but at a very tight spacing, it takes 40ish ms to get a packet across at slower speeds with ACKs and retries.  It could be that you were just sending packets too fast and the transmits were not done before the next tried to start.  Maybe try dialing down your packet TX frequency to see if that helps you.

[perky]

I think it might be due to timing, and specifically when RSSI register is read.

It seems ChemE's settings gave a low packet error rate, but was reading a very low RSSI. With your settings you were getting a high packet error rate but with much more sensible RSSI. There could be differences in timing.

Since the RSSI threshold is set to very low, as soon as the packet is read from the FIFO and the radio put back into RX mode (which is done in the ISR triggered by PayloadReady), the radio will re-trigger again on noise setting the RSSI register to the noise value it read. You're getting values that are close to that noise value. So if there is any delay in your main loop (like for example lots of prints) before you call radio.receiveDone() but after a packet had been received then the original RSSI value will have been overwritten.

So I think the RSSI register should be read in the ISR, not in the main loop, just prior to reading the FIFO. Strangely enough such an RSSI read is actually done in the ISR! I think you should be using that value not re-reading the RSSI register in your main loop.

You also might want to check that the speed of the SPI is as fast as it can be and not set to a few hundred kHz.

Mark.

[madsci1016]

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.

Same reported RSSIs, with a bunch of noise receptions too since I guess CRC is turned off and the TX is sitting idle for a while.

Code Select Expand

35:0:0:0:-102
167:68:133:247:-97
141:200:200:238:-98
246:185:221:180:-100
36:0:0:0:-97
37:0:0:0:-104
64:91:118:4:-93
186:23:77:33:-95
38:0:0:0:-99
39:0:0:0:-103
189:183:129:177:-101
65:128:107:6:-96
50:60:197:225:-100
35:161:120:157:-93
227:56:156:135:-99

[perky]

Try using ChemE's settings and changing

Code Select Expand

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

to

Code Select Expand

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

Mark.

[madsci1016]

I think it might be due to timing, and specifically when RSSI register is read.

It seems ChemE's settings gave a low packet error rate, but was reading a very low RSSI. With your settings you were getting a high packet error rate but with much more sensible RSSI. There could be differences in timing.

Since the RSSI threshold is set to very low, as soon as the packet is read from the FIFO and the radio put back into RX mode (which is done in the ISR triggered by PayloadReady), the radio will re-trigger again on noise setting the RSSI register to the noise value it read. You're getting values that are close to that noise value. So if there is any delay in your main loop (like for example lots of prints) before you call radio.receiveDone() but after a packet had been received then the original RSSI value will have been overwritten.

So I think the RSSI register should be read in the ISR, not in the main loop, just prior to reading the FIFO. Strangely enough such an RSSI read is actually done in the ISR! I think you should be using that value not re-reading the RSSI register in your main loop.

You also might want to check that the speed of the SPI is as fast as it can be and not set to a few hundred kHz.

Mark.

I'm too beginner with understanding these registers but this seems to make sense, if someone with the same radios can confirm the same behavior.

The RFM69 library looks to be using SPI clockDIV4 which would be around 2Mhz on a 16Mhz crystal, so that seems fast enough.

As for the RSSI, there's something funky in this library. It's not commented out in the ISR, it's just after the if statment at the bottom of the ISR. But when I call readRSSI from userspace, that value will get overwritten. Why do that? Why not just read back the RSSI saved from the ISR?

[madsci1016]

That did it perky, I see what's going on now. I missed RSSI as a public variable and only saw readRSSI as a public function.

Now output at 300kbps

Code Select Expand

64:0:0:0:-27
65:0:0:0:-26
66:0:0:0:-26
67:0:0:0:-26
68:0:0:0:-27
69:0:0:0:-27
57:221:130:68:-96
70:0:0:0:-28
71:0:0:0:-28
72:0:0:0:-27
73:0:0:0:-27
74:0:0:0:-27
75:0:0:0:-27
76:0:0:0:-26
77:0:0:0:-27

It's obviously getting some noise packets without CRC enabled. Wonder if it's better to bring up the minimum RSSI or just implement my own checksum in userspace.

[perky]

CRC should now work

Mark.

[ChemE]

Worth noting that I had CRC off because I wanted to send very tiny packets and with CRC on the radio pads out your payload to be a multiple of 16 bytes.  So your 41 bytes is actually 48, probably not a biggie to you.  It was causing my 3-byte payload to become 16 which I railed against.

[madsci1016]

CRC should now work

Mark.

Not quite.

Simply changing to

Code Select Expand

RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON

yields

Code Select Expand

60:0:0:0:-24
96:0:0:0:-25
124:0:0:0:-26
224:0:0:0:-25
248:0:0:0:-28
3:0:0:0:-25
7:0:0:0:-25
55:0:0:0:-28
67:0:0:0:-25
96:0:0:0:-25
159:0:0:0:-25
192:0:0:0:-25
204:0:0:0:-27

epic packet loss.

[perky]

You need to set CRC enabled for both transmission and reception, have you done that on both ends?

Mark.

[ChemE]

Try turning up your RSSI threshold to something above the noise floor but well below your RSSI.  Something like -80dbm or -90dbm.

[madsci1016]

You need to set CRC enabled for both transmission and reception, have you done that on both ends?

Mark.

If you mean do I make that change in the RFM69 library and then recompile and flash both the TX and RX, than yes I did it on both ends. Otherwise not sure what you mean.

Testing also shows it's related to packet size. If I reduce to a 15 byte packet:

Code Select Expand

200:0:0:0:-25
203:0:0:0:-24
204:0:0:0:-27
206:0:0:0:-27
207:0:0:0:-27
208:0:0:0:-26
209:0:0:0:-28
212:0:0:0:-24
215:0:0:0:-24
216:0:0:0:-27
219:0:0:0:-27
222:0:0:0:-24

Still some loss but not as epic.

[perky]

That's still a very bad packet loss. ChemE's settings produce next to no packet loss. You shouldn't be getting more than 1% really, especially with such a strong signal. Are you using ChemE's settings but just with CRC enabled (both ends)?

[madsci1016]

Here's the settings:

Code Select Expand

  const uint8_t CONFIG[][2] =
  {
{ REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },    // 0x01
    { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 },    // 0x02
    { REG_BITRATEMSB, RF_BITRATEMSB_300000 },    // 0x03
    { REG_BITRATELSB, RF_BITRATELSB_300000 },    // 0x04
    { REG_FDEVMSB, RF_FDEVMSB_300000 },    // 0x05
    { REG_FDEVLSB, RF_FDEVLSB_300000 },    // 0x06
    { REG_FRFMSB, RF_FRFMSB_915 },    // 0x07
    { REG_FRFMID, RF_FRFMID_915 },     // 0x08
    { REG_FRFLSB, RF_FRFLSB_915 },    // 0x09
    { REG_RXBW, RF_RXBW_DCCFREQ_111 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 },    // 0x19
    { REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 },    // 0x25
    { REG_DIOMAPPING2, RF_DIOMAPPING2_CLKOUT_OFF },    //0x26
    { REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN },    // 0x28
    { REG_RSSITHRESH, 220 },    // 0x29
    { REG_PREAMBLELSB, RF_PREAMBLESIZE_LSB_VALUE },    // 0x2D
    { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 },    // 0x2E
    { REG_SYNCVALUE1, 0x2D },    // 0x2F
    { REG_SYNCVALUE2, networkID },    // 0x30
    { REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF },    // 0x37
    { REG_PAYLOADLENGTH, 66 },    // 0x38
    { REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE },    // 0x3C
    { REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF },    // 0x3D
    { REG_TESTDAGC, RF_DAGC_IMPROVED_LOWBETA0 },    // 0x6F
    { 255, 0 }
  };

And yes just Chem's settings with the change on CRC.

[madsci1016]

And before someone thinks power again I have tried powering the TX with a fully charged li-po battery at 3.9V into Vin and same result. Can't get more hearty than that.

Also with two other Moteino sets to make sure it wasn't a hardware issue.