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:
Hmmm, that’s good news, but also weird, as earlier screenshots showed that the Join Request was received at SF7, and that the Join Accept was then transmitted in RX1 (using SF7), not RX2 (SF12 with the default settings).
Your new log shows:
…which is SF12. As your RX2 code changes make the join work, apparently TTN uses RX2 for the Join Accept, if the Join Request was sent at SF12. (TTN surely prefers RX2 for high SF responses after the join, hence after it has changed the RX2 network settings in the Join Accept. I don’t know when TTN prefers RX1 or RX2 for the Join Accept though.) It would be great if the node could join using a better SF though.
I have never managed to get TTN to accept joins higher than SF10.
SF11, and SF12 always return denied. I think I have read about SF12 not being allowed, but not sure about SF11. I usually do all joins on sf10 and switch ADR on to optimise datarate, this model works great for me in most cases. The issue is if SF10 is not enough foR the join it will not work of course. If I manage to get a device to join, then move it into an area requiring higher SF, ADR will adapt and it will start working a day or two later…but that is of course not a viable solution. However I can also understand the reasoning if a device tries and tries and never manages to join on SF10, the coverage is too poor in the location. (If you get through on SF12, you usually would be able to get occasional packets through on SF10).
Note that “denied” is just a message from the LoRaWAN stack in the device (like from the RN2483). When the network rejects a join, it will not send a response at all. In theory, the device could receive a Join Accept that it somehow denies (like due to a bad MIC when someone is trying to mess with the joins), but in practice this message means that the device did not receive any response to the Join Request at all (maybe due to wrong settings for RX2), even though a Join Accept might have been sent.
I’ve seen joins on SF12 (even above in this very topic), so TTN surely allows those. You’ll have to peek into the gateway traffic to see if TTN sent a Join Accept.
Did you make any progress solving the very same issue for SF7 (using RX1)?
I’ve submitted a bug report for RX2:
I’ll pick it up after the weekend.
Thanks, probably a limitation in the TTN-library then. Planning to write my own library soon anyway, so will sort it out then if not before 
Conclusion (up till now); the TTN library can successfully join with the following code changes:
TheThingsNetwork.cpp
Comment out line 630: // sendMacSet(MAC_RX2, "3 869525000”);
Sketch, f.e. SendOTAA.ino
Change:
TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);
to:
TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan, 12);
i.e. use Spreading Factor 12.
Remarks:
- The first join request fails most of the time
- The console does not show a successful join (yellow icon, not green one)
- After 7 succesful transmissions we get: Response is not OK: no_free_ch
That’s not quite ideal…
Things run fine up till now. The _no_free_ch _issue has to do with duty cycle restrictions, but that’s not the subject of this post.