Hi,
I’m trying to capture small streets in TTN mapper. Every 10s a package will be sent. After ca. 50 minutes, no more packets arrive in TTN Mapper, although the GW receives the packets (TTN-Console-GW Traffic). Even if I write myself the packages with MQTT in a database it writes after 50 min no packets in the database. The Device Frame-counter stops at 255(Activation Method ABP). Is there a limit by the TTN?
Every 10 secs? you will be breaking the allowable daily bandwidth usage - its possible your device is scaling back its airtime usage, have you tried setting to send every 30min and see how it does.
Yes, every 10 s, because than wie got a measuring point every 20 m. Of course it is not a permanent operation, it is done once!
The TTN Fair Access Policy limits the data each end-device can send, by allowing:
An average of 30 seconds uplink time on air, per day, per device.
At most 10 downlink messages per day, including the ACKs for confirmed uplinks.
Is it a hard boundary being monitored?
Some libraries enforce it, some less so - depends on the code used.
10s sees high, I’ve done roaming every 30s with few issues.
What SF are you using?
I use SF7 BW 125, payload size 23 Bytes airtime 61,7 ms!
With airtime 61,7ms and 30s airtime par day i can send about 486 packeges, but now after 7 houres, after reset the device packet counter the packeges arrived normaly, i will test if the number 255 is the limit.
Ok, here the result of the test, the packet counter rolls over, after 255 the next number is 0! Possible the software is the problem!
What … a bug ?
Surley not !
1 Like
I will check if the TTN-Mapper software (https://github.com/xoseperez/ttgo-beam-tracker) is the problem or the arduino lmic library.
Who generates the number? The lmic library?
The uplink frame count is generated by the node firmware.
LMiC does not have the erroneous behavior you are seeing, it must be introduced by some change you have made or error in porting it to a given platform.
While this looks somewhat related to the failure to maintain the count across the first transition of the of 8th to 9th bit, there might be other possibilities as well: Is your node resetting itself for some reason? It seems somewhat unlikely given the consistent timing across the counter reset, but it could perhaps happen due to some fault leading to an assert and watchdog restart.
Whatever the cause, a rollback or restart of the frame count should ordinarily lead to packets being silently rejected by the network server’s decoding, as it looks like a replay attack.
cslorabox
Thank you!
The packages were send every 10 s, even from counter 255 to counter 0, when, caused by watchdog, the T-Beam boots up. I do a reset by button and the gps keep working, so it is possible that the cpu do a reset and the GPS give immediately a new position. But that there is no delay seems implausible. I will look!
I think I found the error:
In main.ino there is RTC_DATA_ATTR uint32_t count = 0;
then ttn_cnt(count);
but the implementation of ttn_cnt in file ttn.ino
void ttn_cnt(unsigned char num) {
LMIC_setSeqnoUp(num);
}
I will test it tomottow!
Sounds like this is a mistaken use of an 8-bit type in code that tries to restore the fCnt sequence number after a low power mode that looses state.
Normally you should not touch LMiC’s internal variables, but preserving state is about the one reasonable reason to do so.
And yes, the value needs to be 32 bits - even though only 16 bits are transmitted, the upper bits are tracked on both sides and the cryptographic checksum will come out wrong if they are lost.
1 Like