SteveRan
commented
1 year ago On investigation the cause of the problem seems to be the send_to_wait() retry timeout logic. As standard the logic causes the transmitted message to be sent 4 times - in rapid succession (1 second pause between each) - I believe the slower ModemConfig values mean that the receive end can still be processing the processing the previous message before the next one comes in and partly overwrites it (hence the message corruption). Lower reties to 0 and the problem disappears. The line: while time.time() - start < self.retry_timeout + (self.retry_timeout * (getrandbits(16) / (2**16 - 1))): with retry_timeout = 0.2 seems a bit illogical. time.time() on the pi pico seems to have a precision of 1 second (although being returned as a float). I can see what the timeout code is trying to archive (a random timeout between 1x and 2x retry_timeout - but for values less than 0.5 seconds its always going to result in a 1 second timeout.
Hi - I'm running your "out of the box" client and server examples on a pi picos (+ RFM98s) - the code works fine with the Default ModemConfig value (Bw125Cr45Sf128) - but with a couple of the other values I get corruption in the received message - e.g. : From: 1 Received: b'This\xa0is \x99\xb8\xd9\xef\xc2\xd3J4\xff\x80Gz<\x11' RSSI: -52.47; SNR: 22.75 From: 1 Received: b'This(a\xf3\xa8y\xd0\x8b\xfa\xd1\x8b\x86\xbd\t\x8a0\xdb\xf6\x93' RSSI: -52.47; SNR: 58.5
with Bw125Cr48Sf4096 Any clues where to start looking for a problem?