TTN UNO was working with OTA and ABP now not


(Mwalczak5603) #1

I will attempt to keep this as short as possible. I received both The Things Gateway and The Things UNO. Since we are new to Lora and IOT world we wanted to do some testing and figured keeping everything from the same company would be easier. The activation process of the both the gateway and the Uno went well and operated fine for a few hours. After which the Uno could no longer join the network. Thinking we violated the Fair Use Policy we turned off the UNO for 24 hours. Ater 24 hours we ran the same example sketch SendOTAA, but we still were denied, “keys were correct”. But there was an oddity, periodically we would see data in consoles gateway traffic that indicated the the join was successful. and followed with one payload of data, after that nothing. Getting frustrated with this we reconfigured for ABP, again as before things were working, then I powered off the UNO and when I started it again 12 hours later by running the same sketch SendABP with correct keys, I get
11:01:01.867 -> Sending: mac tx uncnf 1 00
11:01:04.028 -> Successful transmission
in the debug window, but no data is shown being received by gateway or the device in the TTN consoles.

This is the results that I am getting from the sketch SendOTAA

09:20:05.680 -> – STATUS
09:20:05.697 -> EUI: 0004A30B001B8EA2
09:20:05.697 -> Battery: 3283
09:20:05.731 -> AppEUI: 70B3D57ED0017510
09:20:05.731 -> DevEUI: 0004A30B001B8EA2
09:20:05.731 -> Data Rate: 3
09:20:05.731 -> RX Delay 1: 1000
09:20:05.767 -> RX Delay 2: 2000
09:20:05.767 -> – JOIN
09:20:06.466 -> Model: RN2903
09:20:06.466 -> Version: 1.0.5
09:20:06.466 -> Sending: mac set deveui 0004A30B001B8EA2
09:20:06.466 -> Sending: mac set adr off
09:20:06.503 -> Sending: mac set deveui 0004A30B001B8EA2
09:20:06.503 -> Sending: mac set appeui 70B3D57ED0017510
09:20:06.503 -> Sending: mac set appkey 8A6ED4D9C5700B8A4B9F44517B1B7D6C

09:20:06.537 -> Sending: mac save
09:20:07.452 -> Sending: mac set ch status 8 on
09:20:07.452 -> Sending: mac set ch drrange 8 0 3
09:20:07.487 -> Sending: mac set ch status 9 on
09:20:07.487 -> Sending: mac set ch drrange 9 0 3
09:20:07.487 -> Sending: mac set ch status 10 on
09:20:07.487 -> Sending: mac set ch drrange 10 0 3
09:20:07.520 -> Sending: mac set ch status 11 on
09:20:07.520 -> Sending: mac set ch drrange 11 0 3
09:20:07.520 -> Sending: mac set ch status 12 on
09:20:07.520 -> Sending: mac set ch drrange 12 0 3
09:20:07.555 -> Sending: mac set ch status 13 on
09:20:07.555 -> Sending: mac set ch drrange 13 0 3
09:20:07.555 -> Sending: mac set ch status 14 on
09:20:07.555 -> Sending: mac set ch drrange 14 0 3
09:20:07.590 -> Sending: mac set ch status 15 on
09:20:07.590 -> Sending: mac set ch drrange 15 0 3
09:20:07.590 -> Sending: mac set ch status 16 off

09:20:08.048 -> Sending: mac set pwridx 5
09:20:08.048 -> Sending: mac set retx 7
09:20:08.048 -> Sending: mac set dr 3
09:20:08.048 -> Sending: mac join otaa
09:20:14.544 -> Join not accepted: denied

The AppEUI and the DEVEUI are correct and match what is in the console.


#2

pls show some TTN appl console output and FORMAT your 1e post.
long logs like this are terrible to read on a mobile.


(Mwalczak5603) #3

Thanks for helping out. This is from the console for the gateway

{
“gw_id”: “abc027615742zed2”,
“payload”: “ABB1AdB+1bNwoo4bAAujBACweeTsT1g=”,
“dev_eui”: “0004A30B001B8EA2”,
“lora”: {
“spreading_factor”: 10,
“bandwidth”: 125,
“air_time”: 370688000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-02-04T15:29:22.645Z”,
“rssi”: -33,
“snr”: 11,
“app_eui”: “70B3D57ED0017510”,
“frequency”: 904500000
}

There is no data in the console for the device.


#4

ok but that’s a frame thats received So the node has joined, The problem was not joining I thought.

one thing I noticed is that DR=3 don’t correspond with a SF=7 (has that device been mobile ?)


(Mwalczak5603) #5

Agreed, but I keep getting this in the debug window “09:47:26.383 -> Join not accepted: denied” and no traffic in the device console.


(Mwalczak5603) #6

Answering your question DR=3 with SF 7, This is just the thing UNO on my desk, I know so little that I am not even to the point of being dangerous. We are just covering the basics here with the examples. The strange thing is that it did work, then stopped.


#7

ok… difficult to trace this type of problems.

I would start again, remove old appl.
create a new application (in console, with a different appl. name) and register your device (uno) with a different name (and add to the new appl).
start your basic otaa example again.

show some console output when device starts joining (yellow thunder-leave browser window open before powering device)

to be honest, yesterday evening I took my ttn node that I didn’t use for months, put new batteries in and it started, blue light, but nothing visible in console, I didn’t change the application !
So, more or less the same problem, I have a closer look tonight


(Mwalczak5603) #8

I have done what you have recommended multiple times, and end in the I am up at the same pont. I will repeat process to gather data. I noticed online there are a number of people having similar problems, but no solutions. So I hope we can figure this out.


#9

OK… I am possibly one of those people :sweat_smile: we’ll find it


(Afremont) #10

Data rate 3 in US is SF7 bandwidth 125kHz. That should be okay, shouldn’t it? Maybe he’s missing the receive window?


#11

indeed… but look at the frame he received


(Afremont) #12

It shows in console gateway tab, but not in device tab. Wouldn’t that point to device ID mismatch, or something like that. Or maybe application key/I’d?


#13

this supprised me a bit (hence my Q 'has that device been mobile ?)


(Mwalczak5603) #14

OK I have it working now. I reflashed the firmware in the RN2903. The thinking there was that it was working and stopped. I then dropped the device on TTN and reinstall it so all was fresh. When I ran the Send OTAA it started working. I had the firmware scrambled earlier and reflashed, something must have gone wrong with the process. But this begs the question is why did it get scrambled in the first place. I haven’t read the data sheet on the RN2903 or looked at the schematic so no suggestions yet. I have seen this happen in the past when the rails did not come up or go done fast enough. Thanks for the help.

How is the spreading factor determined and set?

Thanks again,

Mike


(system) #15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.