cyberman54
commented
5 years ago Messages are spread over LoRa FPorts, not channels. FPorts and channels are completely different things in LoRa happening on different layers.
LoRa channels are dynamically selected by MCCI LMIC stack. This should not be touched, since it's logic is close to certification as being LoRaWAN compliant.
Using FPorts allows to minimize the payload for a selected use case. This is important to stay in duty cycle limitations of frequency band and in fair use policy of the network operator:
https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
E.g. if location data is not needed for an application, no airtime should be wasted to transfer it.
If you want combined message on 1 FPort, ensuring that complete payload always goes out in 1 LoRa packet, select Cayenne LPP 2.0 format with packed encoding. This format does no message splitting, which comes on the price of using messages types which increase the payload.
By splitting messages on FPorts the FPort number (which is present in every LoRa packet) can be hitchhiked to transfer message type information, without increasing payload size.
Paxcounter is designed for use on very limited LPWAN, not IP, networks. Every bit counts!
https://github.com/cyberman54/ESP32-Paxcounter/blob/master/src/paxcounter.conf#L14 https://github.com/cyberman54/ESP32-Paxcounter/blob/master/src/payload.cpp#L280
davidex720
Searching around I found that the main reason to have 8 channels in Lora is to make a more reliable transmission randomly selecting one of them for the communication for every package. Doing so the traffic is spread homogeneously across all channels. This prevents loosing messages sent on too used channels.
For this reason I think maybe it could be a better solution for this project to not differentiate information sent based on channel but rather:
use one byte to describe the type of message
send all the available information on the same message without splitting
(1 pax, 4gps, 8 battery.... to randomNumber allTheInfo)