The things UNO connecting problems

End Devices (Nodes) [obsolete] SCPF-related
1

Good day,

Setup:
1x The things uno
1x RPI w/ dragino hat lora-gps as GW - single channel 868.1 Mhz - SF 7
both indoor, ca 3 meters away from each other.

Problem:
The things uno can’t connect to TTN/GW, I’m getting this error:

The things UNO output
– STATUS
EUI: 0004A30B001FF56C
Battery: 3294
AppEUI: 70B3D57ED0019A93
DevEUI: 0004A30B001FF56C
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
– JOIN
Model: RN2483
Version: 1.0.5
Sending: mac set deveui 0004A30B001FF56C
Sending: mac set adr off
Sending: mac set deveui 0004A30B001FF56C
Sending: mac set appeui 70B3D57ED0019A93
Sending: mac set appkey same as device
Sending: mac save
Sending: mac set rx2 3 869525000
Sending: mac set ch drrange 1 0 6
Sending: mac set ch dcycle 0 799
Sending: mac set ch dcycle 1 799
Sending: mac set ch dcycle 2 799
Sending: mac set ch dcycle 3 799
Sending: mac set ch freq 3 867100000
Sending: mac set ch drrange 3 0 5
Sending: mac set ch status 3 on
Sending: mac set ch dcycle 4 799
Sending: mac set ch freq 4 867300000
Sending: mac set ch drrange 4 0 5
Sending: mac set ch status 4 on
Sending: mac set ch dcycle 5 799
Sending: mac set ch freq 5 867500000
Sending: mac set ch drrange 5 0 5
Sending: mac set ch status 5 on
Sending: mac set ch dcycle 6 799
Sending: mac set ch freq 6 867700000
Sending: mac set ch drrange 6 0 5
Sending: mac set ch status 6 on
Sending: mac set ch dcycle 7 799
Sending: mac set ch freq 7 867900000
Sending: mac set ch drrange 7 0 5
Sending: mac set ch status 7 on
Sending: mac set pwridx 1
Sending: mac set retx 7
Sending: mac set dr 5
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa

this shows up @ my gateway:

{
“gw_id”: “eui-b827ebffff8707b4”,
“payload”: “AJOaAdB+1bNwbPUfAAujBACANnonzic=”,
“dev_eui”: “0004A30B001FF56C”,
“lora”: {
“spreading_factor”: 7,
“bandwidth”: 125,
“air_time”: 61696000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-03-23T19:59:03.726Z”,
“rssi”: -57,
“snr”: 9,
“app_eui”: “70B3D57ED0019A93”,
“frequency”: 868100000
}

afbeelding

1 weird thing: I’m getting 2 app eui at the same time, as i got only 1 reg. device in my app.

afbeelding

My Device:
afbeelding

My RNmodule 2438 + setup(didn’t change anything yet, straight out of the box setting):

afbeelding
2
4

Any solution how i get The things UNO connected?

Thanks in advance,
Greetz

Leon

3

and what code do you use for the UNO ?

4

Hi BoRRoZ,

see below:

Standard SendOTAA UNO Sketch:

#include <TheThingsNetwork.h>

// Set your AppEUI and AppKey
const char *appEui = “70B3D57ED0019A93”;
const char *appKey = “same as device”;

#define loraSerial Serial1
#define debugSerial Serial

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup()
{
loraSerial.begin(57600);
debugSerial.begin(9600);

// Wait a maximum of 10s for Serial Monitor
while (!debugSerial && millis() < 10000)
;

debugSerial.println("-- STATUS");
ttn.showStatus();

debugSerial.println("-- JOIN");
ttn.join(appEui, appKey);
}

void loop()
{
debugSerial.println("-- LOOP");

// Prepare payload of 1 byte to indicate LED status
byte payload[1];
payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;

// Send it off
ttn.sendBytes(payload, sizeof(payload));

delay(10000);
}

5

in general : do your single channel gateway work with other nodes / is other data coming in and forwarded ?

6

I’m using only 1 UNO, no nodes

Gateway overview
afbeelding

Gateway traffic/Every time i run this sketch(shown earlier) i will receive this:
afbeelding

Devices:
afbeelding

Device overview
afbeelding

App. data
afbeelding

8

All in a row, there is something strange going on…

Only 1 device, Device:
Device uei: 0004A30B001FF56C
App eui: 70B3D57ED0019A93

Setings arduino sendOTAA
#include <TheThingsNetwork.h>
// Set your AppEUI and AppKey
const char *appEui = “70B3D57ED0019A93”;
const char *appKey = “F00AF646E1135F26859E7812F8419E50”;

Arduino sendOTAA after upload
AppEUI: 70B3D57ED0019A93
DevEUI: 0004A30B001FF56C

Join request in gateway:
afbeelding

Conclusion: After uploading sketch into things uno:
2 join request on Gateway.
2 others App eui, both not the same as Sketch. Both App uei remain the same after another upload but dev. eui changes randomly.

10

if you click on the yellow thunder / blue arrow you get more info.

11

Pic: 1
afbeelding

Pic 2
afbeelding

Pic 3
afbeelding

12

it’s probably (?) a TTN uno vs single channel gateway problem as mentioned here
https://www.thethingsnetwork.org/forum/t/the-things-uno-with-single-channel-gateway-problem/8842

13

It probably is… thanks for your support anyways:)

14

Can’t be more clear sorry.
The Dev_Addr I see on one screenshot is not from the TTN network, your probably very close to your gateway and the channels from your node are not set for a single channel gateway.
Furthermore I don’t know if your gateway is working (does it transmit) too.

15

Indeed, that uplink with the 0xA5692148 DevAddr might not be originating from your node at all. (Just some other device in your neighbourhood, or maybe not even LoRaWAN at all.) Or, just like with the join requests, the packet is not received correctly and then TTN just cannot know for sure if it’s an uplink or something else. But as your node keeps trying to join, it should not be sending any uplinks (blue icons) yet at all. So, forget about that and focus on the join requests.

Like @borroz suggested: increase the distance between your node and gateway until you see a single entry, with the expected AppEUI and DevEUI. You might simply be seeing cross talk and/or overload of the receiver circuits due to the signal being too strong.

Also check the quality of the wiring in your gateway.

When you see the expected AppEUI and DevEUI then using a single-channel test gateway is still troublesome. But even with a single-channel test gateway you should at least see the Join Request including a DevAddr in the application/device’s Data page (orange icon), and a Join Accept in the gateway’s Traffic page (green icon).

16

I created a new application and device, moved my UNO and gateway to about 6m from each other,

The good thing is, Dev uei and App eui are the same as i look up in my gateway.

afbeelding
Event
{
“gw_id”: “eui-b827ebffff8707b4”,
“payload”: “AJ6aAdB+1bNwbPUfAAujBADZMMPnFhA=”,
“dev_eui”: “0004A30B001FF56C”, (Device) Dev uei 0004A30B001FF56C
“lora”: {
“spreading_factor”: 7,
“bandwidth”: 125,
“air_time”: 61696000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-03-24T12:56:20.101Z”,
“rssi”: -65,
“snr”: 9,
“app_eui”: “70B3D57ED0019A9E”, (Device) App uei 70B3D57ED0019A9E
“frequency”: 868100000
}

but i still receive te message:

Sending mac join
Join not accepted: denied
Check your coverage, keys, backend status
Response is not OK= no free ch.

Gateway says:
rxpk update: {“rxpk”:[{“tmst”:2843631189,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9,“rssi”:-65,“size”:23,“data”:“AJ6aAdB+1bNwbPUfAAujBACOMov/Kd4=”}]}
stat update: {“stat”:{“time”:“2019-03-24 13:00:09 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:1,“rxok”:1,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:00:39 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:01:09 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:01:39 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:02:09 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:02:39 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
stat update: {“stat”:{“time”:“2019-03-24 13:03:09 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}
Packet RSSI: -65, RSSI: -86, SNR: 10, Length: 23
rxpk update: {“rxpk”:[{“tmst”:3048600994,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-65,“size”:23,“data”:“AJ6aAdB+1bNwbPUfAAujBADlP3QN7A8=”}]}
stat update: {“stat”:{“time”:“2019-03-24 13:03:39 GMT”,“lati”:51.87293,“long”:4.64568,“alti”:10,“rxnb”:1,“rxok”:1,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single test Gateway”,“mail”:“test”,“desc”:“test”}}

Could this be the problem settings (using the single_chan_pkt_fwd - main.cpp)?:
I’m using: Rasp. pi model 3b+ and Dragino Lora/GPS hat v1.4.

17

Maybe your TTN uno (original ?) is working, that’s possible too, but you’re gateway not.
That’s why I asked you before ’ if you leave the gateway traffic page open’ do you receive any other packets … in your location there must be more lorawan users.

To use a (TTN uno) node with a single channel gateway you make sure you have the right channels set because they change everytime on the node but your gateway is listening to only one and therefore misses a lot of data.

just an idea:
What you can do is leave your application (with the added node) browser page open and move closer to a know other gateway location with the TTN uno ?
When you come back home you could see

  • it joined the network- conclusion its your gateway
  • it didn’t join- conclusion my node OR gateway is not ok
18

Did you also make sure the AppKey matches? It’s not shown in the gateway’s Traffic page, but if it does not match, then TTN cannot validate the Message Integrity Code (MIC) of the message, and will reject it, which also implies you won’t see the Join Request in the application/device’s Data page.

If the AppKey matches too, you really should see the following:

1 Like
19

…which assumes that your single-channel test gateway supports downlinks. If it doesn’t, well, then TTN will probably detect it’s not fetching any downlink commands from the server, so won’t consider your gateway for the Join Accept response. But then I think TTN Console will show more info when clicking an item in the gateway’s Traffic page. (Apart from the Even Data that you showed us, there’s also Trace data there, which might reveal something.)

20

App key matches 100%, just checked it for the 10th time, so does the dev uei and app eui.
Only event data is showing, no trace data.

I keep searching for the problem:)

21

I’m not seeing anything that might relate to your gateway fetching any possible downlinks from the server. So: are you sure it supports downlinks? What packet forwarder are you using?

22

regarding this screenshot

afbeelding

joinrq

23

Beware that, without knowing the secret keys, such online decoder can only make a best guess. It’s just interpreting the bytes it sees, but:

Also note that erroneous packets (including packets that are just LoRa, not LoRaWAN) are likely to show incorrect results without any warning, so specify the secrets to validate the Message Integrity Code (MIC).

If the 4 bytes MIC is valid, then it’s safe to assume the packet has not been altered, that it is indeed a LoRaWAN packet, and that the secret NwkSKey is valid too. But even then one cannot tell if the secret AppSKey is valid as well; specifying the wrong AppSKey simply yields different decryption results.

Same goes for TTN: when it receives erroneous packets, it might think it’s not directed to TTN, but will then still decode the non-encrypted parts to show you some details, assuming it’s a valid LoRaWAN packet of some other network. But it really does not know if it’s decoding a valid packet.

As increasing the distance between node and gateway seems to have solved seeing the weird data, I think it’s safe to assume that the screenshot just showed a failed attempt to interpret garbage.

@borroz, if you wanted to show the differences in the EUIs in TTN Console and the online decoder, there are a few errors in the Base64 encoded string that you typed:

It’s easier to copy the hexadecimal representation :wink: