Join Fails

Hi, I need some help. I have two V1.0 T-Beam boards, one is working as I expected and one is not. The failing one will, upon power up, send a Join request that I see on my gateway as an “Accept join-request” and then a “Forward join-request message”. After that the device keeps posting messages, I am using a GPS tracker sketch (GitHub - kizniche/ttgo-tbeam-ttn-tracker: TTGO T-Beam Tracker for TTN Mapper and TTN Tracker using US (915 MHz) and EU (868 MHz) frequencies) that posts the GPS location every 20 secs. I see these messages also on the gateway but they never go to the end-device application I have defined. I do know it save the session keys so I modified the code so it would force a Join every time I reboot it just see if something it has saved from a previous session is causing it to not work. Any ideas as to where I can start looking? I have tried deleting the end-device and making a new one but still the same issue.

Thanks. Mike

Hallo Mike,
I own three of these T-Beams and use them for mapping with TTN-mapper. I use the code of Kizniche but fixed it to SF7/125kHz and use ABP.
Do you see data arriving in the console? What payload-formatter have you installed?
I use LoRaWAN V 1.0.3, everything is running fine.

btw: here you find the T-beam thread:
https://www.thethingsnetwork.org/forum/forum/t/ttgo-t-beam-topic/

It’s a bit hard to tell from your description because it would be a bit odd for an OTAA configuration to try to send normal payloads if it hasn’t joined. So can you confirm that the one that does not work is actually sending uplinks or is it trying a join again?

Is this device in the same application as the working one?

Or do you mean that that the working one joins OK but then the uplinks never get to the application console?

What does the serial log output for both of them say?

This would massively breach the Fair Use Policy - check out https://avbentem.github.io/airtime-calculator/ttn/eu868/12 for what would be appropriate

Thanks for the response. As far as Fair Use Goes, I increased the transmission rate to aid in debugging on my gateways, I have three. It would not be used that way in the wild.

Also the “non-working” board did work at one point in the past using these sketches, just not now.

I used to use ABP early on but as it was recommended to use OTAA for better security so I focused just on that protocol with all my LORAWAN experiment and I have not tried these boards using ABP. I would prefer to get OTAA working. I do not see data arriving in the console. That is the problem. It does not reach the application to use a payload formatter. I see the packets hitting my gateway in live data and can recognize the device address. I also use an SDR to see the T-Beam transmitting so I know it is sending out data.

The working one, called T-Beam1 with a sketch of the same name, joins and then every 20secs sends its GPS data and in the application I use a java formatter and see the GPS coordinates. T-Beam2 uses the same sketch except that credentials are changed to match up with the t-beam2 end device in TTN. What I see for that board is an Accept join-request and then a Forward join-request message. Nothing else in the application.

image

I can load the T-Beam2 sketch on to the working board and it works normally. Does a join and sends the GPS coordinates every 20 secs as I see in the application for the T-Beam2 end device. So it seems to be isolated to the hardware of the none working one.

The serial monitor for both looks the same for both;

14:41:09.093 → Hdop: 21
14:41:09.093 → Sats: 9
14:41:09.093 → Screen: Message queued
14:41:09.093 →
14:41:09.140 → TRANSMITTED
14:41:15.545 → EV_TXCOMPLETE (inc. RX win. wait)
14:41:15.545 → Screen: Message sent

When the non-working one starts up, from the serial console, it says EV_JOINED and displays the new device-id and session keys. Then it proceeds to send the location data every 20 secs as shown above.

My thought as to where the issue is lies with the data the sketch saves so it does not do a join every time the device reboots. Would it have something to do with the FCnt value? I read that it is suppose to reset to zero when a device joins. I don’t see that happening with my devices. I modified the sketch to force a join every time it boots and FCnt value never resets. Or is that value kept track of on the TTN server?

I’ve far more than three but far less than others - how does this influence FUP? And even if it was inside FUP, can you really analyse the results that fast?

Please review recent posts on the issues of joining, rebooting and saving state, it will get you up to speed without us repeating it all over again.

I mentioned how many gateways I had in case that could some how be related to my issue, even if I couldn’t understand how. I did not mention it to justify contravening the FUP.

I did try to look for other posts on this but I did not find any that helped. It may be the search keywords I was using. I will try searching on joining, rebooting and saving state and see what I can find.

Thanks