I’m working through the LoRaWAN Academy using the SODAQ ExpLoRer Board, and I’m having an issue activating the device via OTAA on TTN.
I followed the steps one-by-one and I can’t seem to get the device to join the network. I’ve added the required libraries and uploaded the TTN DeviceInfo sketch to obtain the DevEUI. I then created an application in the TTN Console and I used the DevEUI to register the device to the network.
Then, I uploaded the SendOTAA sketch from the TTN library, ensuring that I changed the loraSerial, debugSerial, and freqPlan parameters to their required values. Prior to uploading the sketch, I then copied the AppEUI and AppKey from the TTN Console and pasted these in the correct area of the sketch.
When I uploaded the sketch, the serial console states:
“Join not accepted: denied Check your coverage, keys and backend status”
I ran the DeviceInfo sketch again and noticed that the AppEUI value had been updated to match the AppEUI from TTN Console.
Any ideas why I am not able to authenticate this device with TTN? Thanks in advance for any help you can provide!
Hi @Paul_Stewart. I’m using US915, but I suspect you might be on to something re: channel selection. I’m still stuck and can’t seem to pinpoint what’s causing data to not flow through and I’m not sure where to go from here.
Yesterday, I reviewed the gateway traffic on TTN console and I was able to see JoinReq and JoinAccept messages for my device. However, even though the TTN console indicated that I successfully joined the network, the serial monitor was still showing me the same error message “Join not accepted: denied. Check your coverage, keys, and backend status.” I can verify that my keys are correct, and it appears there are no issues with TTN backend, so that leads me to believe it’s some type of issue related to coverage.
Additionally, I am trying to send a temperature payloads but only a couple of the messages came through despite the JoinAccept. At one point yesterday, I did receive a couple of temperature payloads, yet the serial monitor still showed that the JoinReq was denied. Now today, I am seemingly back at square one because I cannot consistently get the device to join the network. TTN says my device is online, but FramesUp still reads 0.
I’ve attached another screenshot that outlines which channels are on/off–I’m guessing these are defined by the TTN library. Is it possible that I’m experiencing unreliability because the gateway and device are attempting to communicate on different channels?
Yeah I was thinking about correct channels because thats what it sounded like - still kind of does with the intermittent messages getting through.
Channels match the frequency plan listed for US915 (I use an RN2903 version on AU915 which is just a derivative of yours)
With the node looking ok, I suppose you could look towards your gateway - what are you using including which packet forwarder?
Or another route could be to use the Sodaq library to join - I don’t use the TTN library, I just use a sketch to set my channels the first time I use an Explorer, and then with them set, I can run any sketch after that without worrying about setting channels each time. If you want to try that out I can share my code too.
It might be worth trying your code because I’m running out of ideas about how to resolve this. I’d consider using the Sodaq libraries, but part of me wants to get to the route cause of this problem since it seems to be pretty straightforward in the LoRaWAN Academy instructions.
I’m having some trouble understanding why it would be channel issue if it’s defined by the frequency plan since both the device and gateway should be utilizing the specified channels. That leds me to believe that perhaps the gateway is not utilizing the correct channels for some reason. I’m using a Kerlink iFemotcell and Semtech packet forwarder.
What version of the Explorer are you using? I have an older version (Rev 5b - US Version) and the board definitions that Sodaq supplies doesn’t work for my older version - same kind of symptoms.
I had to roll back my boards library to 1.6.15 and my RN2483 library to 1.0.10
My board is Rev6c, I just got this board a couple of weeks ago so I believe it is the most recent version.
Another note–I noticed this morning that there was an activation message for the device in TTN, pictured below:
From my understanding, this indicates that the activation message was sent on ch7. However, reviewing the serial monitor logs I uploaded in the earlier post, ch7 is set to ‘off’?
yep that looks like your gateway isn’t setup correctly (and your node)
From what I can gather US915 on TTN should be talking on 8-15
cheers
Paul
edit: I just fired up a node here and one try showed on Channel 2 which didn’t work and then the second successful join attempt was on Channel 8.
So probably not your gateway sorry but something to do with the code
Here is the Channel set code I use
// Adapted by Paul Stewart from code found here https://www.thethingsnetwork.org/forum/t/how-to-make-rn2483-node-use-a-fixed-channel-and-spreading-factor/2156/3
// This code sets up 8 channels (8-15) for use on the TTN and disables all the others
// It could be done much neater I'm sure - but this works
// You can check if a channel is on or off by using this command in the serial monitor
// mac get ch status # - where # is the channel you would like to check.
#define debugSerial SerialUSB
#define loraSerial Serial2
void setup() {
// digitalWrite(ENABLE_PIN_IO, HIGH);
delay(3000);
while (!debugSerial){
// Wait for the debugSerial
}
debugSerial.begin(57600);
//loraSerial.begin(LoRaBee.getDefaultBaudRate());
loraSerial.begin(57600);
debugSerial.println("RN2483/2903 serial passthrough");
// channels to turn on - TTN in Australia uses sub-band 2 or channels 8-15
exec("mac set ch status 8 on");
exec("mac set ch status 9 on");
exec("mac set ch status 10 on");
exec("mac set ch status 11 on");
exec("mac set ch status 12 on");
exec("mac set ch status 13 on");
exec("mac set ch status 14 on");
exec("mac set ch status 15 on");
// unused channels to turn off
exec("mac set ch status 0 off");
exec("mac set ch status 1 off");
exec("mac set ch status 2 off");
exec("mac set ch status 3 off");
exec("mac set ch status 4 off");
exec("mac set ch status 5 off");
exec("mac set ch status 6 off");
exec("mac set ch status 7 off");
exec("mac set ch status 16 off");
exec("mac set ch status 17 off");
exec("mac set ch status 18 off");
exec("mac set ch status 19 off");
exec("mac set ch status 20 off");
exec("mac set ch status 21 off");
exec("mac set ch status 22 off");
exec("mac set ch status 23 off");
exec("mac set ch status 24 off");
exec("mac set ch status 25 off");
exec("mac set ch status 26 off");
exec("mac set ch status 27 off");
exec("mac set ch status 28 off");
exec("mac set ch status 29 off");
exec("mac set ch status 30 off");
exec("mac set ch status 31 off");
exec("mac set ch status 32 off");
exec("mac set ch status 33 off");
exec("mac set ch status 34 off");
exec("mac set ch status 35 off");
exec("mac set ch status 36 off");
exec("mac set ch status 37 off");
exec("mac set ch status 38 off");
exec("mac set ch status 39 off");
exec("mac set ch status 40 off");
exec("mac set ch status 41 off");
exec("mac set ch status 42 off");
exec("mac set ch status 43 off");
exec("mac set ch status 44 off");
exec("mac set ch status 45 off");
exec("mac set ch status 46 off");
exec("mac set ch status 47 off");
exec("mac set ch status 48 off");
exec("mac set ch status 49 off");
exec("mac set ch status 50 off");
exec("mac set ch status 51 off");
exec("mac set ch status 52 off");
exec("mac set ch status 53 off");
exec("mac set ch status 54 off");
exec("mac set ch status 55 off");
exec("mac set ch status 56 off");
exec("mac set ch status 57 off");
exec("mac set ch status 58 off");
exec("mac set ch status 59 off");
exec("mac set ch status 60 off");
exec("mac set ch status 61 off");
exec("mac set ch status 62 off");
exec("mac set ch status 63 off");
exec("mac set ch status 64 off");
exec("mac set ch status 65 off");
exec("mac set ch status 66 off");
exec("mac set ch status 67 off");
exec("mac set ch status 68 off");
exec("mac set ch status 69 off");
exec("mac set ch status 70 off");
exec("mac set ch status 71 off");
exec("sys get hweui");
}
void loop() {
if (debugSerial.available()) {
loraSerial.write(debugSerial.read());
}
if (loraSerial.available()) {
debugSerial.write(loraSerial.read());
}
}
String exec(const char* cmd) {
debugSerial.print(cmd);
debugSerial.print(F(": "));
loraSerial.println(cmd);
while(!loraSerial.available()) {
delay(50);
}
String s = "";
// This includes \r\n newline:
while(loraSerial.available()) {
s.concat((char)loraSerial.read());
}
debugSerial.write(s.c_str());
}
Thank you for sharing Paul, I will take a look at it this weekend to see if I can adjust the configuration.
I seemed to make some progress yesterday. I tried starting from scratch:
Removed the gateway from TTN
Factory reset the gateway
Reconfigured the gateway to route data to TTN
Reinstalled packet forwarder
Add gateway back to TTN
This yield some interesting results. I now see multiple joinReqs from the device and joinAccepts from the gateway when I view the gateway traffic, and each series of joinReq/joinAccept is exactly 5 minutes apart. So at least there is some consistency now instead of receiving intermittent messages, but I’m still unable to see any uplinks with temperature data.
Edit: More good news! I’m finally receiving temperature payloads! I h ave no idea what changed but I;m relieved that data is finally flowing through.
