I have an TTIG indoor gateway and a heltec encapsulate node.
Today I had time to do some test. The first power on was good joined. Next power on with same code not accepted by node. Whats wrong? Is it normal between join request and accept 4sec?
1 Like
Not sure what and how you are testing. Any additional information is lacking.
If you want useful feedback from others, you should provide good and detailed information yourself first. To prevent others having to guess for it and prevent unnecessary speculations.
What I observe in above screenshot is that the node appears to make join requests like crazy which is abnormal.
First the node appears to make join requests every 6 seconds, then later the node appears to be manually reset every few seconds. Both are not normal.
What sketch is used? Which LoRaWAN library is used (I assume the one integrated in the CubeCell Arduino Core)? What version of the core are you using?
A standard unmodified sketch like the ‘LoRaWAN’ example or a modified example/custom sketch? Do you only use the TTIG or are other gateways also in range of the node? What is the distance between node and TTIG?
Have you tested another node with the TTIG (preferably a different type)?
Join accepts that are being missed by a node are often caused by timing issues on the node.
Give the node some time and leave it joining for 10 to 20 minutes and observe what happens in the console application data and the console gateway traffic. Also check the times between each subsequent join request and the spreading factor of each join request and a possible join accept.
The node seems to retry a failed join request every 6 seconds which is very uncommon.
This could be caused by ill-behaving code (sketch) running on the node or a problem in the LoRaWAN library.
According to the LoRaWAN Regional Specifications:
JOIN_ACCEPT_DELAY2 is 6 seconds.
JOIN_ACCEPT_DELAY1 is 5 seconds.
I’m not sure if latter means exactly 5 seconds or max 5 seconds but max seems most plausable.
In case of max 5 seconds, a 4 seconds delay is valid and in case of exactly 5 seconds, 4 seconds will be too short.
@bluejedi I know more details are good.
I use an standard library core arduino and the heltec lib from git in older versions and a newer had no brought no change. I have no influence how fast this join process is because it seems when a problem of the library but heltec sad it seems to be OK. So I just wanna know if others person had such problems in combination TTIG and cubecell cabsulate.
No I am the only Gateway in this area and distance is around 4 through a wall.
The facts that TTN Console shows that it received the Join Request (orange icon in the gateway’s Traffic page), accepted it and activated the device by assigning it a new DevAddr and some secrets (orange icon in device’s Data page), and has commanded a gateway to transmit the Join Accept (green icon in gateway’s Traffic page) tells you that you should investigate if the gateway indeed transmits it, and if yes: why the node does not receive it. That’s all we can tell from the screenshots.
If the CubeCell’s LoRaWAN library is based on LMIC, then maybe LMIC_setClockError helps. But lacking links to the libraries you use, I’m not going to see if that’s the case.
The gateway needs to transmit it at the exact time, so TTN delegates it to the gateway a bit earlier to allow for some network latency and to allow the gateway to prepare itself. The time in TTN Console shows when TTN has sent the OTAA Join Accept (plus some extra details such as frequency, data rate and transmission power) to the gateway. Given the frequencies that are used, that’s for RX1 in this case.
1 Like
It is not LMIC based but LoRaMac-node based. LMIC will also not retry joins every 6 seconds (based on my own experience with LMIC and missed join accepts).
If exact, could the reported 4 seconds delay be an issue then (either on backend, gateway or node)?
No, the reported 4 seconds is when TTN sends off the command to the gateway, relative to the time it received it. So, as this is RX1 which the gateway should transmit 5 seconds after receiving the Join Request, this nicely allows for 1 second of latency and processing at the gateway. This includes the latency for the Join Request to arrive at TTN: the reported time for the Join Request is the time at which TTN received it, and TTN does not know how long it took for that to travel from gateway to TTN.
So, bad network latency could also cause the Join Accept to arrive too late at the gateway.
2 Likes
Oh really? So then why are you still not providing al requested information and why are you not following up advice that was given?
@bluejedi because too many information could cause a wrong way in answer. The given answers are perfectly to this topic and helps to determine some other things.
So as a read now from TTN and TTIG it should work.
So my to do is.:
To search in library and look to the network latence time.
Is there a way to see when my gateway send it to air?
Use a cheap SDR stick with a computer with RTLSDR to check transmissions.
Don’t try to play wise guy if you are asking others for help and then neglect them with remarks like above. That behavior is not respectful and is not tolerated on the forum!
No they are not and not anyway near. Based on your questions, you were explicitly asked to provide certain very relevant information, which you repeatedly neglect and do not provide because, as you mentioned, you yourself have decided that it will not lead to the correct answer. Which you based on what, the knowledge that you lack and ask others help for? That is not a very smart approach for getting useful answers and does not exactly motivate others to help you.
I had seen the same behavior on CubeCell HTCC-AB01 with my gateway based on iMST iC880 concentrator. I did not investigate what was the problem but switched to APB for my device.
I have complete updated my libs. It seems to work now.