Is packet loss common?

[madsci1016]

I'm not sure if it's related to Chem's settings. If I go back to stock library settings, and reduce update interval to 330 ms, I still have packet loss in promiscuous mode :

Code Select Expand

213:0:0:0:-16
217:0:0:0:-15
221:0:0:0:-15
223:0:0:0:-16
226:0:0:0:-16
228:0:0:0:-16
230:0:0:0:-15
233:0:0:0:-16
236:0:0:0:-16
240:0:0:0:-16
244:0:0:0:-16
245:0:0:0:-27
253:0:0:0:-16
254:0:0:0:-26
0:0:0:0:-15
4:0:0:0:-16
5:0:0:0:-26
6:0:0:0:-27
14:0:0:0:-27
15:0:0:0:-27
17:0:0:0:-15

SO do many people run these radios with no ACK in promiscuous mode? Maybe it's just nature of them?

[perky]

Then it might be that there are lots of 0x00 or 0xFFs in the datastream. There has to be a transition every 16 bits or so to keep the bit synchronizer happy, this would explain why it appears to be packet length related.

Try turning on data whitening on both ends, change:

Code Select Expand

{ REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF },    // 0x37

to

Code Select Expand

  { REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF },    // 0x37

Mark.

[madsci1016]

That was exactly it. All looks awesome now. Is there a drawback to whitening not to enable it by default in the library? Would have saved me 2 days of debugging.

Even the stock library settings, at 4800 bps seems happy to send 41 bytes every 33 ms (14432 bps).

* thinks about it *

Wait a minute. Me thinks the comments are outdated or I misunderstood them

Code Select Expand

/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_55555}, // default: 4.8 KBPS

Library is using 55,555 bps isn't it?

[perky]

Nice!

This has caught out others before, I'm not sure why whitening is not default. It makes sense to do that IMO. Also the default comment of 4.8k is for power up default of the radio, not the library. The library does indeed default to 55555.

Mark.

[perky]

BTW you should now turn on CRC on both ends, you'll need that protection against getting bit errors with such large packets. Your packet error rate should be somewhat less than 1% as you've got quite strong signals I think.

Mark.

[madsci1016]

BTW you should now turn on CRC on both ends, you'll need that protection against getting bit errors with such large packets. Your packet error rate should be somewhat less than 1% as you've got quite strong signals I think.

Mark.

It is, I went back to full stock with the whitening mod. I don't need more than the 20-30 Kps so I won't push the bitrate higher than the stock 55k.

Now if I could get back my two lost days...

I'm not bitter or anything.... May have opened an issue on the RFM69 github though....

But otherwise, THANK YOU for putting up with my ramblings and multiple posts and helping me. If I did want to try something higher, say 100kbps just to improve latency, is there a good guide you could point me too for setting the other attributes like FDEV?

[perky]

You're welcome, glad it's working 

If you need to fiddle there's a sticky thread that I started that gives the rules for FDEV, BR and RXBW and how they are related:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/definition-of-rxbw-with-rfm69/

Mark.

[madsci1016]

Exactly what I needed, thanks again.

[ChemE]

I thought data whitening instantly doubled the size of the payload by turning 0s into 01s and 1s into 10 so the stream stays DC-free regardless of composition.  This is why I've always avoided data whitening.  Is that not the case?

[perky]

You're thinking of Manchester encoding which does double the number of bits. Data whitening is basically a scrambler that converts a stream of bytes into another stream of the same number of bytes but scrambled. A descrambler the other end recovers the original byte stream. So exactly the same number of bytes are sent.

Mark.