Discussion of LoRA Address and Reading ID on sensor

[aviateur17]

In FDRS_Sensor the readings have a READING_ID in fdrs_sensor_config.h which is designed to be modified by end user for each sensor. However, there is also a LoRaAddress configured in fdrs_sensor.h which file is not designed to be modified by end user. Therefore each sensor would have the same LoRaAddress which is not desirable. Can we make READING_ID part of LoRaAddress?

In fdrs_sensor_config.h (change value to hex)

#include READING_ID 0x01

In fdrs_sensor.h (change first byte to READING_ID value)

uint8_t LoRaAddress[] = {READING_ID, 0x00};

That way we don't need to go into fdrs_sensor.h to make any changes to LoRaAddress.

[timmbogner]

Currently the sensors don't need addresses since they are always general/unregistered traffic. You definitely brought up something I hadn't considered, which is that they will need an address now that they're getting confirmations. You're right that the reading ID would work. However in the future, reading ID may change during runtime. The LoRa address is on a lower layer than the reading ID, so I don't think we should base one on the other.

On ESP-NOW, I plan to use the full manufacturer MAC to address sensors with the system packets. If we transferred this to LoRa we'd just assign random addresses. Perhaps while we are messing around with packet structure to add CRC, we may consider extending LoRa addressing to 6 bytes like MAC. This might facilitate more randomness, if that makes sense. Also could just be a good idea for LoRa address to be more robust.

[aviateur17]

If we can't correlate the Reading ID with the LoRa MAC address then I suggest we make another #define in fdrs_sensor_config.h to add the LoRa MAC since fdrs_sensor.h is not designed to be modified by end user. I haven't yet seen why Reading ID would change at runtime but I don't have a whole lot of time in with the project either.

On the topic of length of LoRa MAC address, increasing to 6 byte address would increase the packet size by 8 bytes (4 byte increase for source and 4 byte increase for destination), thus possibly reduce the amount of other data in the packet, and seem to be excessive for the amount of addressing that 2 bytes allows (0 - 65535). I'm not sure I understand your comment about randomness. Maybe you can elaborate on that a bit more. Is the randomness aspect more important than the 8 byte increase in each packet? How many LoRa sensors are you thinking the project would accommodate?

[timmbogner]

Addressing with the reading ID should be fine, and there is no harm to it. The issue is confusion around terminology that might happen in the future. The idea is that the user should never need to worry about a sensor's physical (MAC) address. It also doesn't really matter what it is, as long as its always the same.

Ignore the stuff about 6 bytes then, I was overthinking. The reason the current header takes up 5 bytes is just because it was nice to keep it the same size as an ESP-NOW packet (250) at one time. You're right though, and we wouldn't want the amount of LoRa traffic that a 6-byte address would facilitate anyhow.

[aviateur17]

Sounds good, Will use Reading_ID and will be an easy change later when you want to expand on changing the reading ID at runtime.

[aviateur17]

Submitted PR so closing this discussion.