I did now move the devices to another platform, NASYS.
All devices works smothly, so i am quite shure that something whent wrong in the TTN application.
the string can be closed
No.
The only safe conclusion right now is that you still do not understand that the decision to re-join is the responsibility of the node and not the network.
Whatever the actual issue that caused that remains unknown to you, and it’s quite likely that it will fail again in the future for the same reason, leaving you no more aware of the issue then than you are now.
If you want to be prepared, start archiving the metadata of uplinks now, so that when it breaks again you have something meaningful to examine.
I have 2 years of metadata stored for the same purpose.
My conclusion is that after the break -down the devices try to rejoin the platform.
To some extent i guess that the app rejects the device possibly not recognized the port.
When i restarted the device at another platform it joined immediately, so the issue is somewhere else.
One possibility is that there is an issue in the firmware that causes them to crash after a certain amount of time.
Strictly not necessary but it’s a shame you didn’t try a new application with TTN, connecting them to a different platform still leaves many many questions unanswered.
I guess we’ll hear from you in a couple of years time 
1 Like
Then please use that data to answer the specific questions which were asked about it above.
Not only is there no evidence of a break down, by itself, a break down cannot cause a join attempt.
You need to understand why the devices decided to do that.
Your own screen shot shows that TTN accepted the join attempts, but that does not explain why your node’s firmware failed to take the offered sessions, or why it started trying to join in the first place.
A proper LoRaWAN device, even if being ignored, would show a days or at least hours long record of trying increasing spreading factors before it gave up and tried to join - or if not such a record, then a corresponding time gap in expected uplinks.
Most likely in your device firmware, at the outside with a gateway.
Chances are rebooting the node or deleting it from TTN and re-creating it would have made things work, too.
You shook things loose, but you neither determined nor understood the actual problem, and it’s likely to happen again with you none the wiser as to why.
2 Likes
There is no such thing as a port for an OTAA Join. If you’re referring to uplinks being faulty as the device used a specific port, then the same will happen on another network. Also, the device won’t know if TTN rejected a faulty uplink, unless you were using confirmed uplinks, which you should do sparsely.
Confirmed uplink, while a bad idea, is not the only situation.
Ordinary adaptive data rate needs to get a response occasionally or it will decide it has to switch to a higher, slower, longer range spreading factor. And when it has run out of longer range options to ramp to, it will probably eventually give up, declare the link dead, and the firmware may rejoin.
But that should take a while, not just to give up, but also that unless the device was already at the limit of range, to ramp from whatever spreading factor was typically used, up to the last choice of desperation.
And there should be either evidence of that ramping, or evidence of a long period of entirely missing uplink packets.
I guess it’s possible that if a device used confirmed uplink all the time and never got confirmations it might give up in a shorter timeframe, but it really shouldn’t do that.
Which all goes to say we really, really need to see the metadata of the the last few dozen ordinary packets preceding the switch to sending join requests. And also to know if that metadata is in any way different from what the nodes had been doing a week earlier.
The metadata is the same as it has always been, the devices has ben operating from the same place for a very long time.
there was 4 devices and they all where placed at four different locations.
For the future you really want to capture the spreading factor of the uplinks, and also the gateway identities. Also try to keep timestamps in some useful form, scientific notation is hiding changes representative of the seconds/minutes/hours between packets.
And your data series does not span from normal operation on port 2 to the abnormal situation of the join attempts starting on port 0 - its in a data set showing the transition where you would really learn things - time gaps, if all nodes did it at the exact same time or at different times such that there were normal messages on port 2 from some for a brief time even after others started with joins on port 0, etc. If you’re simply not capturing joins but only application messages, you’ll want to include those in the future, too.
What appears to be RSSI in your table (though mislabeled) has extremely high values all the way up to -40 which suggests you have at least one gateway extremely close to the node. There are actually some known issues with things that close sometimes causing confusion.
Additionally if you have a very close gateway, then ADR should ramp the nodes to a very low transmit power level and a very fast spreading factor. If that gateway then stops for some reason, you may have a data outage until the ramp back to settings which reach additional more distant gateway(s). If that process doesn’t work right, it could cause the nodes to give up entirely and try to re-join.
To help debug that, you will also want to start retaining at least the fopts field of the uplink - if you start seeing the ADRACKReq bit a lot, the node is getting desperate to hear anything back to know that there’s still a live network out there. Ideally you’d also have the transmit records from at least the nearby gateway that is presumably yours.
The one thing your data does seem to rule out is a frame count overflow…
1 Like
Here is a follow up on the story:
The Gateway antenna is placed at 7 meters roof, and there ar trees btwn. antenna and 2 sensors placed 400 meters away inside a concrete bulding and spread outbehind another concrete building.
Sensors are 2 meters above ground.
the radio strenght are fine and low noise for all four, pic are enlosed.
All 4 died same time, AND ALL 4 RETURNED at the exactly same time.
Were all sensors commissioned at the same time?
And between October 8th 6:30 AM and October 11th they were sending OTAA Join Requests, which TTN accepted but still somehow were repeated over and over again?
(Also, just to be sure: I assume they’re not doing an OTAA Join Request for every uplink, even when all is fine? That’s not how OTAA should be used, and in that case, you’d be seeing rejected duplicates for Join Request DevNonces, I assume, which would also not make TTN show the Activation in its Data pages.)
Hi Arjan, i thing you are hitting the point, as far as i can see the devices keep sending join requests in the period. They should not do a request but once. You are probably right that TTN reject the duplicates in order to avoid DevNonces and if the devices keep sending JointRequests they will be banned in a period. I will se if i can change the settings.
No i think it there is a week inbetween
Hi @Cfosvang, I have seen similar behaviour. The following was my situation:
- COTS devices that routinely send unconfirmed uplinks and periodically (once per 24hrs in my case) send confirmed uplinks. If uplink is not confirmed then device enters an OTAA join process.
- Gateway RX continues normally and forwards the device uplinks to the core.
- Gateway TX has silently failed and downlinks are not TX’d to devices.
- Devices are stuck in OTAA join loop.
In my situation power-cycling the gateway fixed the situation.
thks. this is worth trying 
Hey everyone, I have a similar problem. I’ve changed my protocol from ABP to OTAA and now I can only see activation messages on the data page. There is no payload provided where I need to see some ascii characters. It only shows me device eui, app eui, device id and dev addr. No payload. Also counter and port seems empty. What couldthe problem be? I am still using the version 2. I would be glad if you help.