mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
636 stars 207 forks source link

Problems setting DR_SF12 #765

Open Coimbra1984 opened 3 years ago

Coimbra1984 commented 3 years ago

Hello,

I'm using an SX1276 on a custom hardware with your library. I use European frequency bands and push data to TTN at the moment 11 bytes of payload every 5 seconds (5 seoncds for testing, in real application we will push much slower of course). So far everything works fine, we send data and can receive data from the gateway as well. Now when I change the spreading factor to 12 by calling LMIC_setDrTxpow(DR_SF12, 14); I see that my device only sends the data once and than never again. Changing to spreading factor 10 I see that it sends the data "sometimes". Spreading factor 7 works fine. Any ideas how I can get DR_SF12 to work properly?

terrillmoore commented 3 years ago

You're almost certainly hitting duty-cycle limitations. (5 seconds is not going to work at SF12 unless you wait a LONG time, given the duty cycle limits).

There's a hack in the compliance sketch to work around this. Look at the following lines: https://github.com/mcci-catena/arduino-lmic/blob/93108f01871dca16ef564dd6c4bd5a3a7cb0ae1a/src/lmic/lmic_compliance.c#L216-L225

When entering compliance state, the compliance library saves the old txcap values for each band, and then sets the value to 1 (essentially disabling duty-cycle limitations).

Coimbra1984 commented 3 years ago

Okay, thank you for this hint. I found this documentation about duty cycle: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/ which says that the allowed duty cycle depends on the subband (0.1-10% dc): g (863.0 – 868.0 MHz): 1% g1 (868.0 – 868.6 MHz): 1% g2 (868.7 – 869.2 MHz): 0.1% g3 (869.4 – 869.65 MHz): 10% g4 (869.7 – 870.0 MHz): 1%

If I understand this correctly, than I need to wait 100s if my packet has an airtime of 1s and I'm in subband g, g1 or g4 (1% dc). After that I can send again the next packet, right? But that would also mean that I should plan with a worst-case dc of 0.1% for g2...