markqvist

Thanks a bunch for putting all this effort into it and collecting information. I'll be looking into this and trying to replicate it when I have a chance, but if...

Could you try this again with the latest versions of RNS (0.7.4) and the RNode firmware (1.71)? A range of improvements were made that could affect this problem too.

Assuming fixed in 1.71, closing. If problem persist, please refer to issue in https://github.com/liberatedsystems/RNode_Firmware_CE.

I'm not sure I understand it completely. Do you mean that it waits for a while to see if another digi repeats the packet, and if not, it will digipeat...

By the way, this firmware is very unfinished (although it does work), but I am thinking of putting the finishing work in it, and getting it tested. Do you run...

Yes, that makes sense. I could certainly implement that. I'll put it on my list, but it'll be another few weeks before I get around to this, I'm pretty busy...

It's offset so as to allow negative values. All the current boards support this, and will report values correctly, even at negative SNRs below the noise floor. I'm not sure...

For reference look at how `RNodeInterface` in the Reticulum source code applies an offset to the received statistics value when receiving it over USB/Bluetooth from the hardware.

Ok, just had a look now, and I misremembered something in my earlier posts. Only the *RSSI* values are offset, not SNR. The firmware currently handles SNR like this: -...

Currently TX power is handled down to 0dBm only (1mW), it's not possible to set it more fine-grained than that, ie. with negative dBm values. But since most (in practice...