Pic: 1
Pic 2
Pic 3
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
It probably is… thanks for your support anyways:)
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.
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).
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.
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.
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
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
…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.)
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:)
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?
regarding this screenshot
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:
- AJOaftVs9Quj488eYzW801w/5QZ6nIc=
- AJOaftVs9Quj4B8eYzW8Olw/5QZ6nIc=
It’s easier to copy the hexadecimal representation 
yes… and without my glasses … sorry 
Made a new device, now settings set to ADP instead of OTAA, results:
So the problem is your ss gateway that don’t work with OTAA.
To set your node to one channel ABP (set the same channel in your 'gateway)
but this setup is for experimenting only… its not LoRaWAN compliant
Yes, probably because ADP is confirmed selected instead if OTAA inside RN2483 module.
I will try OTAA button ON tomorrow:)
It’s ABP, not ADP.
The software in the Things Uno is not affected by whatever tool you used for the screenshot above. Your earlier screenshots clearly show that OTAA was used; the sketch you uploaded to the device will have switched to OTAA regardless what another tool might show you.
OTAA needs downlinks for the Join Accept. ABP does not need any downlinks. (Well, unless one wants to use confirmed uplinks, or ADR, or wants a downlink to send some application data to the node.) Even more, ABP does not need any uplink to join either; it’s simply already joined while programming it, so can start transmitting uplinks right away.
I’m quite sure your single-channel test gateway simply does not support downlinks. Then it will never support OTAA either. (Some single-channel test gateways do support downlinks, others don’t. We don’t know what forwarder you’re using.)
Hello, i have the same setup @ home (1x RPI w/ dragino hat lora-gps as GW - single channel 868.1 Mhz - SF 7 with different types of nodes) I confirm that the RPI together with the dragino hat is the limiting factor. So ADP mode only is a fact. Also be aware that it is a single channel GW, this means that most of the transmitted (nodee) packages will be lost. I can live with that, but if you want full functinonality you need a full swing GW.
Kind regards, Henk