Duty limit not respected

JackGruber commented 5 years ago

Hi,

it looks to me like the duty limit is no longer working?! I have set up da transmition of two byte for every 10 second and about every 10 seconds, the data was sent. Shouldn't there be a transmission every 130 seconds or I'm missing something?

11360: engineUpdate, opmode=0x808
11406: EV_TXSTART
11472: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Packet queued
Duty Avail: 0
Duty Rate: 0
76848: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 3
76979: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 77315 rxtime: 76973 entry-rxtime: 342 now-entry: 4 rxtime-txend: 62596
139636: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
139768: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 141064 rxtime: 139761 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 125384
141082: processRx2DnData txrxFlags 0x2 --> 00
141142: processDnData_norx txrxFlags 00 --> 20
141403: EV_TXCOMPLETE (includes waiting for RX windows)
141710: engineUpdate, opmode=0x900
Duty Avail: 2362
Duty Rate: 0
Duty Avail: 2362
Duty Rate: 0
766710: engineUpdate, opmode=0x908
766733: EV_TXSTART
766794: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Packet queued
832170: setupRx1 txrxFlags 0x20 --> 01
start single rx: now-rxtime: 4
832302: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 832638 rxtime: 832295 entry-rxtime: 343 now-entry: 3 rxtime-txend: 62596
894958: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
895090: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 896386 rxtime: 895083 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 125384
896403: processRx2DnData txrxFlags 0x2 --> 00
896462: processDnData_norx txrxFlags 00 --> 20
896722: EV_TXCOMPLETE (includes waiting for RX windows)
897032: engineUpdate, opmode=0x900
Duty Avail: 14447
Duty Rate: 0
Duty Avail: 14447
Duty Rate: 0
1522031: engineUpdate, opmode=0x908
1522053: EV_TXSTART
1522115: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Packet queued
Duty Avail: 14447
Duty Rate: 0
1587491: setupRx1 txrxFlags 0x20 --> 01
start single rx: now-rxtime: 4
1587623: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 1587959 rxtime: 1587616 entry-rxtime: 343 now-entry: 4 rxtime-txend: 62596
1650279: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
1650411: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 1651707 rxtime: 1650404 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 125384
1651725: processRx2DnData txrxFlags 0x2 --> 00
1651800: processDnData_norx txrxFlags 00 --> 20
1652066: EV_TXCOMPLETE (includes waiting for RX windows)
1652380: engineUpdate, opmode=0x900
Duty Avail: 26533
Duty Rate: 0
Duty Avail: 26533
Duty Rate: 0
2277380: engineUpdate, opmode=0x908
2277403: EV_TXSTART
2277463: TXMODE, freq=868100000, len=15, SF=7, BW=125, CR=4/5, IH=0
Packet queued
2342839: setupRx1 txrxFlags 0x20 --> 01
start single rx: now-rxtime: 3
2342970: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 2343307 rxtime: 2342964 entry-rxtime: 343 now-entry: 3 rxtime-txend: 62596
2405627: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
2405759: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 2407055 rxtime: 2405752 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 125384
2407073: processRx2DnData txrxFlags 0x2 --> 00
2407147: processDnData_norx txrxFlags 00 --> 20
2407413: EV_TXCOMPLETE (includes waiting for RX windows)
2407728: engineUpdate, opmode=0x900
Duty Avail: 38618
Duty Rate: 0

Regards Alex

terrillmoore commented 5 years ago

@JackGruber, sorry you're having problems. Can you please advise what platform you're using, which sketch, and which version of the LMIC?

JackGruber commented 5 years ago

Good morning @terrillmoore

i have tried the example code ttn-abp with PlatformIO and Arduino. As hardware i use a TTGO Lora T-beam (Board iheltec_wifi_lora_32 in PlatformIO and Arduino)

The only modification is LMIC_disableChannel for Channel 1 to 9, the TX_INTERVAL to 10. and print every 5 sec

    Serial.print(F("Duty Avail: "));
    Serial.println(osticks2ms(LMIC.globalDutyAvail));
    Serial.print(F("Duty Rate: "));
    Serial.println(osticks2ms(LMIC.globalDutyRate));

platformio.ini

build_flags =
    -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
    -D CFG_eu868=1
    -D LMIC_DEBUG_LEVEL=2
    -D CFG_sx1276_radio=1
    -D LMIC_PRINTF_TO=Serial

lmic_project_config.h for Arduino

#define CFG_eu868 1
#define CFG_sx1276_radio 1
#define LMIC_DEBUG_LEVEL 2

LMIC Version 3.0.99

grafik

console.log

terrillmoore commented 5 years ago

Hi,

LMIC timing is very fragile. It's not a good idea to run tests of timing with LMIC_DEBUG_LEVEL set to anything other than 0. It make things worse.

There is no global duty cycle on EU868; that's done on a per-channel basis. Since you're on SF7, I think it's possible that you're not hitting the limit on channel 0, which is 1%. That looks like a 70 or 80 ms packet, and 1% of every 12 seconds (based on uplink logs) says that you'd be able to TX up to 120ms.

To test global duty cycle, you have to either call an API or update the variables directly. Since global duty cycle rate is zero, you are not rate limiting.

Some notes:

The best script at the moment for timing investigations is the compliance script, because it's very careful not to do anything that slows down the operation of the device at critical moments.
I don't test ABP -- no time, and I don't ever use ABP. For repros, OTAA is better, because the network sends a number of important things at JOIN, and we are sure to get the data. There may be things that were not formerly needed for OTAA, but are now needed. So if there's a problem with ABP, best to test with OTAA and compare results.
Disabling channels in the default set is no longer supported, as this is tested by compliance (even for ABP devices). I think that might have been added between 3.0.99 and 3.0.99.5.
In any case, if you're really using 3.0.99, please update to 3.0.99.5 and retest; there are updates which fix bugs, including timing bugs.
Note that the compliance sketch won't actually go into compliance mode unless you have a tester upstream; it will just idle sending messages periodically.

Thanks! --Terry

JackGruber commented 5 years ago

Hi Terry,

i try the newer version and OTA and get you a feedback.

Alex

JackGruber commented 5 years ago

Hi Terry,

with the latest version from git the OTAA sketch works. I was thinking the limit is 0.1% ... and the 30 seconds Fair Access Policy is a soft TTN limit.

https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html https://avbentem.github.io/lorawan-airtime-ui/ttn/eu868/13

I'm going to read some more about the Duty limit.

terrillmoore commented 5 years ago

@JackGruber glad to hear it, thanks for following up!

mcci-catena / arduino-lmic

Duty limit not respected #461