RADIOLIB_LORAWAN_NO_DOWNLINK when calling activateOTAA() with Tock setup #1140
Comments
|
Hi @alistair23, thanks for including logs, but in LW, timestamps on logs are almost even more crucial than the log contents itself. So please, retry with millisecond-precision timestamps enabled. |
|
By the way, I will provide no help whatsoever as long as you don't decrease your uplink interval by orders of magnitude - you are breaching laws, and let's not even start about FUP if you are using TTN. |
|
Does LoRaWAN require more precise timing? It's possible that's an issue there. How do I get ms level precision logs? I'm connecting to a TTN network. The gatway is in the same room and I see events like this in the TTN console, so it is able to communicate with the gateway
|
I don't follow. I am not changing anything related to uplink intervals |
Yes, LW requires that the receive is turned on a few milliseconds before the Rx1 window which is 5 seconds from the end of the uplink. The receiver will listen for the preamble, if it misses it, game over. But as @StevenCellist mentions, you are hammering a shared community resource provided free of charge once every 1 second which is not only illegal in most jurisdictions (because the law limits use of the shared spectrum) but is also in breach of the TTN Fair Use Policy. The ISM band is generally very busy - you are currently pretty much jamming parts of the airwaves so other people will likely see a degradation in their devices connectivity. No where in our examples do we send more than once every few minutes and we reference the FUP to boot. And there is the no small matter that LoRaWAN works on the basis of an uplink then opening a window 5 seconds later and then again 1 second after that for a response. So apart from the law and FUP, LW can't work at the rate you are using. |
|
^^ thank you @HeadBoffin
That depends on what terminal you are using. ArduinoIDE has a clock button, PlatformIO has a |
Hmmm... I'm probably missing that window. Ah! For the delay in the loop I just checked in something to open this issue. It's just copied from something else. The loop isn't currently being run, but I will be sure to increase the delay considerably |
|
I have updated the original PR description to include timing information. The timing information comes from minicom and as the printing is async it isn't going to be 100% accurate. I have also updated the WIP code at https://github.com/alistair23/libtock-c/blob/alistair/lora-wan/examples/lora/sensor-lorawan/main.cc to use a long delay. So it won't spam any thing
From a quick look I think I'm too slow for this window |
|
A few observations.
|
|
Oh and by the way, please fix the printf not being able to handle floating values - it might not be the problem but definitely won't hurt. |
Before TTI lose the will to live with this sort of stuff, can you tell us where you copied this from so we can try & purge it from the internet - it won't work with any LNS but it definitely hurts TTN. There's also trying to track down the how & why of having the Rx2 window extended by 5 seconds. What is the RSSI & SNR of the Join Request? One of the standard gotchas is the gateway hearing the JR but the device not hearing the JA due to being too far away, or more often, too close! Side note, you are mixing an issue with a PR - this is an issue, a PR would be you providing code to make a change - different tab on the main page! |
|
I think there has been some confusion, so I'll try to clarify. This is an issue. I am getting a The code at https://github.com/alistair23/libtock-c/blob/alistair/lora-wan/examples/lora/sensor-lorawan/main.cc is just my local testing changes. I only checked it in to create this issue. I appreciate you pointing out the excess communication. I have fixed the delay to ensure it is run on every iteration of the loop. That code has never been run though The code is based on the LoRa example (not LoRaWAN) from here: https://github.com/jgromes/RadioLib/blob/master/examples/NonArduino/Tock/main.cpp#L61 As for the Rx1 window, the Tock syscall interface usually results in delays, as the process of acquiring the current time and delays can take a few extra I'll try the latest from upstream to see if that helps, this is the full console output from TTN
|
We understand perfectly fine what is going on, but ...
Yeah, sure, I believe that for now, but that says nothing about what you will be doing with it once it does work. And since this is all about a shared resource being provided free of service, we care about these details. We don't solve problems here, we educate on apparently lots of missing knowledge. TTN provides a great Learn section which might prove very useful...
Very interesting that this provided code also breaks laws. How's your knowledge on dutycycles?
An easy way to check this is by widening the
There is no way for us to confirm whether this is the full output - what are the next lines? Does TTN even schedule a JoinAccept? We can't see that... what is it that you are so actively trying to hide from us? A naughty DeviceID? Come on man - a little less coffee, a little more effort to work together and I'm sure we can get it working! |
|
I tried a I tried the latest mainline and that doesn't even get this far. Something has changed recently that causes me to get TTN forwards the join-accept, as you can see in the log. That's all of the lines on the TTN side. The next line is the next attempt at a different time. I'm not hiding anything
|
Please do so, as this is something crucial. The point is that you are not allowed to join at SF12 in AU915 region due to the dwell time limitations of 400ms that I did not see earlier. I added the dwell time checks but also corrected the join-request to be sent at SF10 instead, which should work. I might have made a mistake there in some way, but we do need to fix that. Sending the JR at an appropriate SF may just as well be a reason why this is not working correctly. I am not sure how TTN handles this as Australia is pretty much other side of the world!
Sorry, I was mistaken on that one, I thought there was an extra line to show that a downlink occurred with a downward arrow. I stand corrected.
Definitely looks much better now, but the Rx1 and Rx2 windows are shifting forwards; how sure are you that your clock is stable and not drifting? CubeCells for example drift by 16 ms every 1000 ms, and the logs indicate something similar here. There are some instructions in |
But you have access to the location warper 915 TTIG - so let the testing commence. From the logs, and yes, precise timing issues etc etc, the Rx1 window was opened 4.854s - with a scan guard of 50ms that means it closed at 4.954s (50ms listening for preamble, 50ms early as per new setting) - you need to hit 5s. It may be time for an oscilloscope or digital signal logger to be used. It would be prudent to get something working on a known good device / platform so you can see RadioLib in action with the logs showing what is good. Along the way it may fill in some of the details you need to wrestle with the whole LoRaWAN thing - it's like |
That's not exactly the case ;) it listens for as long as a preamble can take given the SF and BW. ^ that's a 291 ms window of which 100 ms is due to |
|
For context this is using the latest (commit ce8e6fd) |
|
Thanks for the log, will have to figure out why that is the case... because the ToA is calculated for 23 bytes, which as per the air-time calculator (set at 13+10=23 bytes) should not exceed 400ms.. but that will require to dig deeper and see what values are being calculated. If you can figure out what the stability of your clock is, I will check what is up with the dwell time calculation tomorrow. |
|
What is the RSSI and SNR of the Join Request? |
|
Please pull from upstream - latest commit is tested on AU915/2 and joins perfectly fine on SF10 under dwell time limitations (forgot to convert microseconds to milliseconds). |
Great! Thanks. That fixes the dwell time issue. Now back to the I think the next step is to try and hookup a logic analyser and see if that provides any hints. I'll let you know when I have my breakout board setup |
|
The experts think there are two open questions awaiting your response, namely:
... and ...
... which are both questions that easily supersede connecting a logic analyzer. |
I see this in the TTN logs and this in the gateway logs
The hardware clock is stable, at least as accurately that I can measure. I suspect there are timing errors though as the print statements are async. I'm hoping I can get a better idea of the timing via a LA to see if I'm missing the window |
A wall in between the device & gateway wouldn't hurt (and actually be better), but not completely catastrophical. Regarding the async: yes I got that. But what I see in your logs, is that your clock is running too fast, because the Rx1 and Rx2 window are opening and closing increasingly earlier. And given the timeout that is printed being 290 ms and the prints occurring with 291 ms between them, that async stuff doesn't appear to impact timing that much. Really, I recommend investing whether your clock is running at the same speed as the rest of the world. Ideally, as instructed in |
Yeah they are in the same room.
Good point. I'll test and let you know |
StevenCellist
added
bug
|
This is what I am seeing So that's a clock drift of about -23. I surprised that it's negative! Setting |
|
Ahw, you're missing one line in the final log: the Rx Delay Start! Meanwhile, I'll have to check whether it should be positive or negative.. given that Rx2 now starts 25ms earlier than Rx1 so might have meant for the value to be positive this way round... |
|
Sorry, full log is |
|
This is the capture from a Saleae You should be able to open it with https://www.saleae.com/pages/downloads if you are interested |
|
I see that the clock drift compensation is not used, as you are using a different HAL. Please refer to the ArduinoHAL and implement these calculations in your own HAL (all four of them). Hopefully then the clock drift compensation works nicely. I downloaded Saleae but it says I need a .sal file which is not in your zip. |
|
Aw, sorry. Just rename the |
Describe the bug
When trying to activate a LoRaWAN device I see the following failure
[OP edited this log to add the timestamps as requested below]
To Reproduce
The full code is here: https://github.com/alistair23/libtock-c/blob/alistair/lora-wan/examples/lora/sensor-lorawan/main.cc
The main snippet is below
Expected behavior
https://github.com/jgromes/RadioLib/wiki/Troubleshooting-Guide seems to indicate that no downlink (-1116) is ok to ignore, but the actual examples check for it when running
activateOTAA().I would expect
activateOTAA()to returnRADIOLIB_LORAWAN_NEW_SESSIONScreenshots
Additional info (please complete):
The text was updated successfully, but these errors were encountered: