Looking at the source I can see the software logs airtime but what I do not see is what is being done to make sure the transmission does not exceed the max channel dwell time (duration of transmission) of 400 ms as shown below is bold?
The following table summarizes all the important parameters we have discussed in this section for US902-928 band.
|Default frequency band|902-928 MHz|
|Mandatory channel frequencies for join-request|Upstream: 64 channels - 902.3 – 914.9 MHz in 200 kHz increments)
Upstream: 8 channels - 903.0 – 914.2 MHz in 1.6 MHz increments
Downstream: 8 channels - 923.3 – 927.5 MHz in 600 kHz increment|
|Mandatory data rates for join-request|64 (125kHz channels) using DR0 and 8 (500kHz channels) using DR4|
|Optional data rates|5-6|
|Number of channels|Upstream: 64 (125kHz) + 8 (500 kHz)
Downstream: 8 (500 kHz)|
|Default channels|Ch0 - Ch71|
|Duty cycle|No limit|
Dwell time limitation|Ch0-Ch63: 400 ms
|Max EIRP (default) - TXPower 0|+30 dBm|
|Default RX2 data rate|DR8|
|Default RX2 frequency|923.3 MHz|
reference: Regional Parameters | The Things Network
Based on this calculator: https://www.thethingsnetwork.org/airtime-calculator
Packets should not exceed these limits:
|Mode||Bitrate (bits/sec)||Max payload size (bytes)|
It just appears at first glance (I am still digging into the code) of mesh.pb.h that the MeshPacket is at least 2 to 3 times the max payload size to fit into the 400ms max dwell time permitted by the FCC.
Was this max dwell time (max transmitting time) considered? I understand if it wasn’t, the United States is different in regulating the 902 - 928 MHz ISM band not by duty cycle but by regulating how long the transmission can take. Based on the above referenced calculator make packet length based on mode is anywhere from 11 to 242 bytes of data.
I wanted to hear from developers before starting a United States version that I would call MeshLite which would adhere to the 400ms max dwell time rule.