LoPy and nanogateway example: Inaccurate timing prevent OTAA join
-
This is a continuation of this post https://forum.pycom.io/topic/2676/abp-mode-and-frame-counters/18
It drifted away from the initial topic too far. The result form this topic was:
The node had pretty good timing, but the gateway delivers downlink messages from the TTN server too late. Some further obervations:
a) The downlink message form the TTN server with the join accept arrives at the gateway early enough (like 1 second before it's about to be sent)
b) A simple timing test using utime.ticks_us() and and utime.ticks_diff() to create a 5000ms pulse creates a 5025ms pulse, too late for the tight TTN timing constraints.
c) Additionally, the gateway determines time difference by subtracting time stamps, instead of using ticks_diff(). That may lead to lockouts. But that's another story.
-
@livius I made a version in which you can control the join behaviour. It is just a handful of code lines. You'll find it here:
https://github.com/robert-hh/pycom-micropython-sigfox/tree/otaa
I added an optional parameter to join.
Edit: While testing it came again to my mind to me that you can achieve the same thing with the standard SW:
step1: do an otaa join
step2: take the parameters from the web console, use them as ABP parameters and use ABP join then with just the single frequency in the list of channels. If you then save the state to nvs_ram, you do not have to call join again. The keys will be restored by nvs_restore(), which you must call anyhow to set the counters.
-
@jcaron I agree. Another place to change that would be the gateway. But after a first glance into the spec it seems to me, that the data is protected with a cryptographic MIC, which the gateway cannot recreate.
The problem with join at the nanogateway seems to be the timing. I tried to adapt that with my flavor of the nanogateway, and at my tests it now works all the time. But I have no genuine node to test.
-
@robert-hh the “right” way to do this would probably be to have the network send the right list of channels to use (I.e. 3 times the same) and set the data rate as well.
Joins would still be a bit of a problem, but that’s supposed to be a one-time thing.
But really, the whole nano-gateway concept is just for testing using LoPys on both sides in very controlled environments.
-
@livius Making a table of what works and what no, I get that state:
So it is the yellow combination that would be changed. Non-Pycom nodes will still not work well with the Nanogateway
-
@robert-hh
For me it is :)
I can not speak for pycom but many vendors e.g. RDBMS follow standard but contain some useful exceptions required by their users :) If it work in SQL world why not here ;-)
-
@livius The implementation would be pretty straight forward. Just a flag and maybe a little helper function in loramac.c, called by init_helper in modlora.c. But I do not know whether this is welcome.
-
@robert-hh
meybe not compliant to the spec but it is interesting solution
will be good to see it as parameter in init
-
@kiromn Just out of curiosity I made the change to the loramac.c code mentioned below, and indeed then all packets are sent at the same frequency, being seen by the LoPy gateway. The ttn server does not complain. Only the node is then not compliant to the spec.
-
@robert-hh I will just get multichannel gateway. Thank you for the support :)
-
@kiromn Yes and no. I found the place in loramac.c (starting around line 760), where the channels setting are taken from the OTAA join response. This evening, I will try to supress that. If it works, one can make special Lopy nodes with match the special LoPy gateway.
Anyway, if you need a fully compliant gateway, use another product. The LoPy is designed as a Lora node and works good enough as such.
-
@robert-hh Yep i see. So, this gateway is not very usable.
-
@kiromn I have again used OTAA join and have sent 10 packets. Below if a screen dump of the TTN console. Only 5 of the 10 packets were seen by my Lopy based gateway. The IC880A gateway has seen them all. You see, that the other packets have been sent at other frequencies, which have been submitted in the join response. At least its SF7BW125. So unless the node cannot be forced to ignore these other frequencies, the nanogateway will not catch them.
-
@robert-hh i use OTAA
-
@kiromn did you use OTAA join or ABP join?
-
@robert-hh I have tried disabling channels, changing port, but it does not work. Do you think you will be able to fix it? I can help with testing :)
-
@kiromn I can confirm your observation. After OTAA join, only few of the messages are captured by the Lopy gateway. A second gateway based on an IC880a receives all messages.
using ABP activation and disabling all channels but one, all messages are receievd by the LoPy gateway.
-
@kiromn Interesting. I can try this evening again.
For my tests, I usually use ABP join, by transferring the device ID and keys from a previous OTAA join. The keys can be taken form the TTN server console.
-
No luck with disabling channels also.
-
@kiromn That's antoher effect, cause by the gateway being singel channel only. After joining, you have to delete in the node script every channel but the first. There was some communication about that in the forum, maybe hard to find. Like:
# remove all channels but the first for i in range(1, 3): lora.remove_channel(i)Edit: I changed the gateway script yesterday, such that the delay compensation adapts to different downlink message lengths.
