TX power does not support negative values

[jacobeva]

At present, the return of the packetSnr function is an unsigned integer. This is a bad idea, since some LoRa modems are actually capable of receiving transmissions below the noise floor (meaning the SNR will be negative). These values should be changed to be signed if possible, else this may cause problems when investigating packet SNR in long-range use cases.

[jacobeva]

This is also the case with the TX power parameter. The SX1262 and SX1280 support negative TX values (e.g. -5dBm), this value should also not be unsigned.

[markqvist]

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 this issue is actually still relevant after your recent fixes to the SNR functions for SX1262, but can you please confirm?

It definitely should work with negative SNRs, and currently does with the other boards with SX127X chips.

[markqvist]

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.

[jacobeva]

Yes, I can see what you mean with this, my bad! Closing...

[jacobeva]

How could you propose we handle the negative TX power parameter for the SX1262 and SX1280? Should I change it in the firmware so they are offset so that all the values are positive? Or is it possible to implement these as negative values?

[markqvist]

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:

• The packetSnr() function should return a floating point number with the actual SNR of the packet, positive or negative. This method is primarily used internally in the firmware, while calculating signal quality and such.
• The packetSnrRaw() function should return the raw register value from the modem, which can then be sent unmodified to the host. Yes, this is really a signed number, but we don't care about that here, since we just want to send it as a single byte over the host connection, where the Reticulum interface driver will then interpret it as a signed int and divide it by four to obtain the actual SNR value (positive or negative).

The above assumes the way that SNR statistics are represented by the SX1276 modem registers, which may be different in the SX1262/8 chips.

I think the most frictionless way forward here is to just make sure the packetSnr() and packetSnrRaw() functions just output in the same format as before, which will then make everything work on the host side, even though that may entail adding a simple calculation to get the register values from the SX1262 formatted into the same as the old ones.

Hope it all makes sense and is more clear now!

[jacobeva]

In that case, everything probably already works with SNR then! What of TX power?

[markqvist]

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 all I have seen) come with only the high power output connected, this is not possible anyways, due to the hardware configuration.

[jacobeva]

Please see page 79 of this document: https://www.rfsolutions.co.uk/downloads/1537522490DS_SX1280-1_V2.2_SEMTECH.pdf

Regardless, this is a minor issue and probably does not matter for now, but it may be something that might be wise to extend functionality for in the future.

[jacobeva]

e.g. the LoRa1280F27 has a 200mA power consumption even at TXPower = 0 currently.

[markqvist]

Aha, that makes sense. Well, we definitely need to solve this then ;)

In general, the current way of setting TX power was conceived way back when RNode was basically just one device, compiling on one platform, with one modem chip, so in the current implementation it is not really sufficient anymore.

We'll need to implement something more universal.

[markqvist]

I'll just reopen this actually, better to have it visible as a status tracker for the implementation.

[jacobeva]

Issue will be addressed in the community fork.