Join not accepted: denied with Sodaq Explorer

arjanvanb · January 18, 2019, 5:05pm

…but I actually only read your last post, @koennetwork, so I missed that you’re getting a join error. Such error should only occur for OTAA, which needs a Join Request to be received by one or more gateways, and the Join Accept to be transmitted by one gateway and received by the node. So, the numerous OTAA attempts might just be caused by the device not receiving the OTAA Join Accept for some reason.

In other words: maybe the device will actually only join once, if it succeeds, in which case my previous references don’t make much sense.

Seeing the OTAA join in the application data implies that the device has the correct settings, and that TTN accepts those. With incorrect settings, TTN would not know to which application the device belongs.

If you click on the join message, you might see some details about the gateway. Given its id you can get more details, for example from http://noc.thethingsnetwork.org:8085/api/v2/gateways or http://noc.thethingsnetwork.org:8085/api/v2/gateways/the-gateway-id

koennetwork · January 18, 2019, 10:42pm

Tested: all OK.

koennetwork · January 18, 2019, 10:59pm

But when using the Simple LoRa sketch, the OTAA join is accepted by TTN and a join response is received by the device. Furthermore, data can then be send to the TTN servers.
As you might have noticed, the Simple LoRa sketch uses these libraries:

#include "Arduino.h"
#include <Sodaq_RN2483.h>

And the SendOTAA sketch uses:

#include <TheThingsNetwork.h>

It is my guess, that this is the cause of the problem, although I still don’t understand why the SendOTAA sketch won’t work.

koennetwork · January 18, 2019, 11:37pm

Found this for the gateway in Haarlem:

“eui-0000024b080606d8”:{“timestamp”:“2019-01-18T23:42:09.650702719Z”,“uplink”:“723433”,“downlink”:“2650”,“location”:{“latitude”:52.38169,“longitude”:4.6297584,“altitude”:12},“frequency_plan”:“EU_863_870”,“platform”:“Kerlink IoT Station”,“gps”:{“latitude”:52.38169,“longitude”:4.6297584,“altitude”:12},“time”:“1547854929650702719”,“rx_ok”:723433,“tx_in”:2650}

BoRRoZ · January 19, 2019, 7:18am

did you try to add
…
…
#include <TheThingsNetwork.h>
#include <Sodaq_RN2483.h>
…
…

another thing is. use the latest rn2483 firmware, if necessary upgrade
for more info see http://forum.sodaq.com/c/explorer

arjanvanb · January 19, 2019, 11:10am

Ah, that one is provided by Sodaq itself (and you’re using it for OTAA), but the other is based on an example provided by the Things Network, for their arduino-device-lib.

To summarize:

For both libraries you’re seeing OTAA joins in TTN Console. OTAA works with the Sodaq library, so we know that the gateway and the settings in TTN Console seem fine. (And the Haarlem gateway is a full-blown gateway.) The keys in both sketches seem to match (the TTN library takes the DevEUI from the RN2483, but that looks good too, and as the failing join is still shown in TTN Console, TTN accepts the configuration). So the handling in the backend should be the same for both sketches, if the Join Requests are simular.

Maybe the SF used for the Join Request (and hence for the Join Accept) is different; click the entry in TTN Console to see and compare the details. If it’s SF12:

However, I guess it’s not SF12:

…which shows TTN’s library starts with SF7 (data rate 5). Maybe the Sodaq library starts with a higher SF? (Longer air time, better reach.)

It might also help to know if the Join Accepts for both libraries are sent in RX1 (5 seconds after the Join Request) or RX2 (6 seconds), which might be different if they use a different SF. For RX1, TTN will use the same SF as the Join Request, so SF7, which somehow might not be received by the device.

In the TTN library you can change the default SF using the constructor’s optional parameters:

TheThingsNetwork ttn(Stream& modemStream, Stream& debugStream, fp_ttn_t fp,
   uint8_t sf = 7, uint8_t fsb = 2);

I also wonder if some settings in the RN2483 are configured differently for both libraries, while it seems that the TTN library does not reset it to its factory state first (at least: the log does not show that), somehow affecting its ability to receive the Join Accept? Using the Soday “LoRa Serial Passthrough” sketch you could issue sys reset, but maybe that’s really the same as a reset caused by a power cycle/programming.

koennetwork · January 19, 2019, 12:05pm

I added #include <Sodaq_RN2483.h> but, as expected, it made no difference. If the Sodaq_RN2483 library would have been used by the sketch and it was not included, the sketch would have thrown a compilation error.

arjanvanb · January 19, 2019, 12:18pm

It’s indeed SF7, but the specific Haarlem gateway just got an SF12 too. I’d assume you started with the TTN library’s version? Is the SF12 the Sodaq version?

…where only the SF12 version also shows uplinks, using SF9:

BoRRoZ · January 19, 2019, 12:42pm

I’m thinking also of a factory reset for the module ’ sys factoryReset’

and delete TTN device and application
then register again with different names.

arjanvanb · January 19, 2019, 12:46pm

I’m quite sure deleting and re-registering is not needed; all is fine for one sketch, but not for the other. So as for TTN, the handling should be the same, if the Join Requests are alike. The difference must be in the Join Requests, which I think is what the gateway’s Traffic shows as well.

(Or in the device’s libraries, but not caused by TTN, I think.)

BoRRoZ · January 19, 2019, 12:53pm

because he stated that it worked before… so I’m thinking there must be a setting somewhere
in this sodaq otaa example they use include <Sodaq_RN2483.h> only

https://support.sodaq.com/sodaq-one/lorawan/

arjanvanb · January 19, 2019, 12:55pm

Could be a setting in the RN2483 indeed, but not anything related to TTN Console, I think.

BoRRoZ · January 19, 2019, 12:56pm

yes, that what I mean, something persistant from previous 'experiments.

also… firmware version ?

koennetwork · January 19, 2019, 1:10pm

Well analyzed!
I started with changing the SF in the SendOTAA sketch. From the TTN library constructor:

TheThingsNetwork ttn(Stream& modemStream, Stream& debugStream, fp_ttn_t fp, uint8_t sf = 7, uint8_t fsb = 2);

And: uint8_t sf = 7: Optional custom spreading factor. Can be 7 to 10 for TTN_FP_US915 and 7 to 12 for other frequency plans. Defaults to 7.

As you can see, the default SF=7. I changed the SF in the SendOTAA sketch (7,8,9,10,11,12): no success. Still Join not accepted: denied.

N.B.: the Sodaq library start with SF12

{
“time”: “2019-01-19T12:19:35.782707653Z”,
“frequency”: 868.3,
“modulation”: “LORA”,
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-0000024b080606d8”,
“timestamp”: 1907788868,
“time”: “2019-01-19T12:19:35.729521Z”,
“channel”: 1,
“rssi”: -106,
“snr”: -9.2,
“rf_chain”: 1
}
]
}

arjanvanb · January 19, 2019, 1:29pm

SF, not SP. Did you indeed see that SF used for the Join Request then? (I guess so.)

Maybe compare the gateway’s meta data (frequency and all) of the Join Accepts for both, when both use SF12?

Does the Sodaq library give you debug info on the serial port too?

Maybe the TTN library indeed needs a recent version of the RN2483 (though I hope not, as I still have some Kickstarter hardware that I’d hate to need to upgrade, if I ever unbox it). But 1.0.4 seems quite recent?

It’s surely the latest available with Microchip:

I’ve read that the following is ignored for OTAA; I hope it indeed is, as OTAA Join Accept is using the LoRaWAN default of SF12 for RX2, not TTN’s SF9 which should only be used after a successful join (and which in EU868 is also set in the network settings that are included in the Join Accept).

…but maybe that’s only ignored for some libraries:

~~Anyway, it might help to know if RX1 or RX2 is used. For RX1, TTN uses the defaults anyhow.~~ But the gateway traffic shows that for SF7 RX1 is used anyhow, which uses the LoRaWAN defaults.

As an aside: the Sodaq library is probably just fine. But of course we want to know why the TTN library doesn’t work…

koennetwork · January 19, 2019, 1:58pm

I ran the SendOTAA (TTN lib) with SP 7,8,9,10,11,12. And the Sodaq sketch with its default SP 12. So that explains why you saw all kinds of SP’s appearing.

koennetwork · January 19, 2019, 2:32pm

I compared the join request logs from the console (SF12).
I see no difficulties there:

Application:

{
“time”: “2019-01-19T14:27:37.278739297Z”,
“frequency”: 868.1,
“modulation”: “LORA”,
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-0000024b080606d8”,
“timestamp”: 999352740,
“time”: “2019-01-19T14:27:37.230242Z”,
“channel”: 0,
“rssi”: -119,
“snr”: -7.5,
“rf_chain”: 1
}
]
}

Gateway:

{
“gw_id”: “eui-0000024b080606d8”,
“payload”: “ANpoAdB+1bNwK5ofAAujBAB5IDYs91k=”,
“dev_eui”: “0004A30B001F9A2B”,
“lora”: {
“spreading_factor”: 12,
“bandwidth”: 125,
“air_time”: 1482752000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-01-19T14:27:37.281Z”,
“rssi”: -119,
“snr”: -7.5,
“app_eui”: “70B3D57ED00168DA”,
“frequency”: 868100000
}

No extensive debug info. Only:
“Communication to LoRaBEE successful.”
“Successful transmission.”

I’m just now trying to find out how to get debug info from this library.

I’ve downloaded the most recent version of these libraries, so that should be OK.

arjanvanb · January 19, 2019, 4:09pm

As for debugging the Sodaq, I guess you just need to uncomment line 26 here:

github.com

SodaqMoja/Sodaq_RN2483/blob/master/src/Sodaq_RN2483.cpp#L26-L31


      
          //#define DEBUG
          
          #ifdef DEBUG
          #define debugPrintLn(...) do { if (this->_diagStream) this->_diagStream->println(__VA_ARGS__); } while(0)
          #define debugPrint(...) do { if (this->_diagStream) this->_diagStream->print(__VA_ARGS__); } while (0)
          #warning "Debug mode is ON"

And back to your first post

This is ERR_JOIN_NOT_ACCEPTED as printed by:

github.com

TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L532-L538


      
          }
          
          ttn_response_code_t TheThingsNetwork::getLastError(){
          
          	int match, pos;
          	for (pos=0; pos <= CMP_ERR_LAST; pos++){
          		match = pgmstrcmp(buffer, pos, CMP_ERR_TABLE);

So, the text “denied” is really the response created by the RN2483.

GitHub - SodaqMoja/Sodaq_RN2483 shows that Sodaq seems to be using the same commands, though in a different order:

github.com

SodaqMoja/Sodaq_RN2483/blob/master/src/Sodaq_RN2483.cpp#L149-L157


      
              return init(stream, resetPin, true, true)
                     && initOTA(devEUI, appEUI, appKey, adr);
          }
          
          bool Sodaq_RN2483::initOTA(const uint8_t devEUI[8], const uint8_t appEUI[8], const uint8_t appKey[16], bool adr)
          {
              return setMacParam(STR_DEV_EUI, devEUI, 8)
                  && setMacParam(STR_APP_EUI, appEUI, 8)
                  && setMacParam(STR_APP_KEY, appKey, 16)

But seeing the Sodaq’s serial output makes comparing the RN2483 commands much easier, especially settings for the frequency plan. In case you did not know: using Sodaq’s “LoRa Serial Passthrough” sketch you could even execute the RN2483 commands manually.

kersing · January 19, 2019, 6:28pm

That just means the module did not receive the join response it is waiting for (default response of the module to a join). After some attempts at SF12 that will lead to ‘no_free_ch’ as the retries are relatively close and going on beyond the 3th attempt would violate airtime regulations. (The module uses the 3 join channels)

This looks extremely fishy. I expect this to cause joining issues for all responses in RX2. For OTAA the default (SF12) should be used. I haven’t looked at the TTN library, is there a way to disable this?

Also, just to be sure, I would suggest a factory reset of the module. If the RX2 settings has been saved in some way a module reset will just restore that faulty setting, not the required SF12.

koennetwork · January 22, 2019, 12:21pm

Just to be sure, re-registered application and device: indeed, no effect, no join with SendOTAA

sys factoryRESET: no effect, no join with SendOTAA

Here are the logs for:
SendOTAA

-- STATUS
EUI: 0004A30B001F9A2B
Battery: 3325
AppEUI: 70B3D57ED00168DA
DevEUI: 0004A30B001F9A2B
Data Rate: 0
RX Delay 1: 1000
RX Delay 2: 2000
-- JOIN
Model: RN2483
Version: 1.0.4
Sending: mac set deveui 0004A30B001F9A2B
Sending: mac set adr off
Sending: mac set deveui 0004A30B001F9A2B
Sending: mac set appeui 70B3D57ED00168DA
Sending: mac set appkey D861DB7C58D63473D48A6887FAD93A68
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 0
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa

Simple_Lora_Sketch_Sodaq

[initOTA]
[init]
[sleep]
>> sys sleep 259200000
[wakeUp]
[resetDevice]
>> sys reset
[expectString] ("RN") .--> "RN2483 1.0.4 Oct 12 2017 14:59:25" found a match!

The device type is RN2483
[setPowerIndex]
>> mac set pwridx 1
[expectString] ("ok") .--> "ok" found a match!

[setSpreadingFactor]
>> mac set dr 0
[expectString] ("ok") .--> "ok" found a match!

>> mac set deveui 0004A30B001F9A2B
[expectString] ("ok") .--> "ok" found a match!

>> mac set appeui 70B3D57ED00168DA
[expectString] ("ok") .--> "ok" found a match!

>> mac set appkey D861DB7C58D63473D48A6887FAD93A68
[expectString] ("ok") .--> "ok" found a match!

>> mac set adr off
[expectString] ("ok") .--> "ok" found a match!

[joinNetwork]
>> mac join otaa
[expectString] ("ok") .--> "ok" found a match!

[expectString] ("accepted") ...............................................--> "accepted" found a match!

Communication to LoRaBEE successful.
[setSpreadingFactor]
>> mac set dr 3
[expectString] ("ok") .--> "ok" found a match!

[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.
[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.
[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.
[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.
[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.
[send]
[macTransmit]
>> mac tx uncnf 1 534F444151
[expectString] ("ok") .--> "ok" found a match!

Waiting for server response.............
(mac_tx_ok)
Received mac_tx_ok
Successful transmission.

Can you see a cause of the join problem?