Dropped Packets with High RSSI

Started by Aerokeith, July 02, 2025, 02:06:45 AM

Felix

Sorry I didn't reply yet, I did read through the post but didn't have a better suggestion so wasn't sure what alternatives I could recommend.
What you are trying is what I would probably try as well.
There are many variables in the radio configuration. This is certainly more of an edge case and perhaps the library is not optimized for this so you might have to tweak the library functions to try and see if that gets you closer. I just don't have insight without trying to solve the exact problem you're facing.

Aerokeith

Thanks. By the way, I reduced the Teensy 4's clock rate from 600MHz to 100MHz, and that seemed to reduce the drop rate in the intermittent-tx scenario. No drops at all when sending/receiving continuously.

Felix

Oh interesting. There's a related forum post where the user reports the Teensy as causing their issues  :-X
I think that was one of the first things I suggested eliminating as a variable to see if it reduces the problem  ;)

Aerokeith

I'm back again, still struggling and frustrated, with my deadline days away. But I have new data that will hopefully shed some light on the root cause. I'm sending packets continuously, and I'm seeing that the packet drop is heavily dependent on the data contents of the packet and the position of the data within the packet. For example, if a packet contains all zeros, I'll get a certain successful-receive rate (pkts/sec), and the rate remains fairly constant if the data isn't changed. If I change the first 5 or 6 bytes in the packet, the packet rate changes (sometimes up, sometimes down) and stabilizes. But if I change any bytes beyond byte 6-ish, the packet receive rate drops to zero and stays there.

I've seen this behavior from the beginning, and I thought there might be another cause (unrelated to the radio). But now I've created a more thorough test to measure the packet rate. I'm currently testing at 300 Kbps.

Does this give you any clues?

Felix

Do you use encryption?
There is no data whitening by default. It's good to ensure you don't have too much data that consists of repeated bits. Maybe play with the whitening and see if it yields any different results (bits 6-7 in register 37):

void RFM69::set300KBPS() {
  writeReg(0x03, 0x00);  //REG_BITRATEMSB: 300kbps (0x006B, see DS p20)
  writeReg(0x04, 0x6B);  //REG_BITRATELSB: 300kbps (0x006B, see DS p20)
  writeReg(0x19, 0x40);  //REG_RXBW: 500kHz
  writeReg(0x1A, 0x80);  //REG_AFCBW: 500kHz
  writeReg(0x05, 0x13);  //REG_FDEVMSB: 300khz (0x1333)
  writeReg(0x06, 0x33);  //REG_FDEVLSB: 300khz (0x1333)
  writeReg(0x29, 240);   //set REG_RSSITHRESH to -120dBm
  writeReg(0x37, 0b10010000); //DC=WHITENING, CRCAUTOOFF=0
  //                ^^->DC: 00=none, 01=manchester, 10=whitening
}