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.
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}
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
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.
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.
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:
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.
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.)
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
Could be a setting in the RN2483 indeed, but not anything related to TTN Console, I think.
yes, that what I mean, something persistant from previous 'experiments.
also… firmware version ?
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
}
]
}
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…
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.
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.
As for debugging the Sodaq, I guess you just need to uncomment line 26 here:
And back to your first post
This is ERR_JOIN_NOT_ACCEPTED as printed by:
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:
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.
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.
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?
I can change or disable it in https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L630
Change to what, or just disable?
Hola! That seemed to do the trick! Disabling:
// sendMacSet(MAC_RX2, “3 869525000”);
SendOTAA now joins TTN and payloads are coming through.
But alas, after 7 Successful transmissions:
Sending: mac tx uncnf 1 01
Response is not OK: no_free_ch
Send command failed
Probably to do with: