LoPy and nanogateway example: Inaccurate timing prevent OTAA join
-
No luck with disabling channels also.
-
@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. -
@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. -
@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 did you use OTAA join or ABP join?
-
@robert-hh i use OTAA
-
@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 Yep i see. So, this gateway is not very usable.
-
@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 I will just get multichannel gateway. Thank you for the support :)
-
@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
meybe not compliant to the spec but it is interesting solution
will be good to see it as parameter in init -
@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
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 ;-)think about people first, then computers
-
@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 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.
-
@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. -
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login