@kersing Yea, the join requests goes through the GW I’m looking at, I’m usually looking at the traffic view of the GW (also checked the device itself).
@arjanvanb I cannot see any error when I open any of the many join requests I have inspected.
No, I did not try that, but if it’s a workaround, is there a known issue?
Did you open them at gateway level? Then there won’t be any error related to the node. Only on application level that kind of information is available.
While debugging it helps to have both gateway and application/node traffic/data tabs open.
Yes, it is an issue in the LoRaWAN spec < 1.1. It is mentioned in the previous messages which you dismissed as not being the cause of your issues.
Can you show a screen shot of the application/node data join entries expanded for failing join requests and the first one that works?
Only on application level that kind of information is available.
Checked it on application and device level and there is no error.
On application level:
On application level, one message expanded:
Yes, it is an issue in the LoRaWAN spec < 1.1
But if it was this issue, there should be an error, right?
I will also post screenshots of the case where I get the join response but for this, I need to delete and recreate it first.
The changing dev addr values indicate the back-end accepts the join request and assigns a new address. Is there one or are there two gateways listed in the metadata?
Right, good catch, didn’t notice that. I checked although I was sure and no, there is only one GW and no error (my own one). And this is exactly the behaviour where we have no explanation for.
Ok, I can confirm that if I change the App Key of the device via ttnctl, it seems to reset something (probably the nonces as you propose) and I get join responses again. But, then I should get a proper error message in the console which I don’t, so this smells like a bug to me.
1 Like
Hi everyone,
I’ve the same problem with my node (ATxmega32E5 with a RFM95W module).
There are only ‘activation’ messages in my console visible, despite I get a proper joined message in the callback.
I already tried the following things:
-
Compared the differences between the lmic.c and oslmic.c from this library (Matthijs Kooijman) with the lmic.c of the original library from IBM and applied the changes/improvements (?) from Matthijs.
-
Added
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);after LMIC_reset();
Therefore the changes in lmic.c from Matthijs Kooijman where necessary. -
Changed
setDrJoin(DRCHG_SET, DR_SF7);
to
setDrJoin(DRCHG_SET, DR_SF9);
and I also tried
setDrJoin(DRCHG_SET, DR_SF12);
on lines 686 and 879 of lmic.c
Screenshot console:
I hope someone has another suggestion, because I’m out of ideas right now.
Thanks in advance 
.
Finally found a solution for the described problem in my previous post. It was definitely a timing issue.
I decided to use an external clock (16 MHz, crystal) instead of the built in oscillator of my microcontroller.
After changing the clock input I had to change the timer prescaler settings of course.
LMIC requires ticks to be 15.5μs - 100 μs long, in my current setup a tick is 32 μs.
Previous config (snippet hal.cpp):
static void hal_time_init () {
TCC4.CTRLB = TC_WGMODE_NORMAL_gc;
//32MHz/1024 = 31250kHz -> 32 μs
TCC4.CTRLA = TC_CLKSEL_DIV1024_gc;
EVSYS_CH0MUX=EVSYS_CHMUX_TCC4_OVF_gc;
TCC5.CTRLB = TC_WGMODE_NORMAL_gc;
TCC5.CTRLA=TC_CLKSEL_EVCH0_gc;
}
New config (snippet hal.cpp):
static void hal_time_init () {
TCC4.CTRLB = TC_WGMODE_NORMAL_gc;
//16MHz/256= 16000kHz-> 62,5 μs
TCC4.CTRLA = TC_CLKSEL_DIV256_gc;
EVSYS_CH0MUX=EVSYS_CHMUX_TCC4_OVF_gc;
TCC5.CTRLB = TC_WGMODE_NORMAL_gc;
TCC5.CTRLA=TC_CLKSEL_EVCH0_gc;
}
Now it’s running fine. After this successful observation I changed the prescaler settings of my built in oscillator to run on 16 MHz instead of 32 MHz and it’s still running fine 
.
3 Likes
Good to read that it works now.
I set up a new Lorix Gateway today and have 3 devices that I am trying to use with it but I only see join requests from all of the devices… These are tabs.io devices and I thought that they would register and then work with the app from their vendor but for some reason they are not being registered or anything. What am I missing here? I feel like it’s likely something dumb but I can’t seem to figure it out.
I’m not 100 % sure but I think they only work ‘out of the box’ with their gateways (called HUBS)
to use the TTN network you need to be able to program keys into these devices.
they have a support page
Thanks so much for the help Borroz! It really helps to have someone active in a community like yourself. Sorry for the possibly dumb questions but I think I may have totally misunderstood what TTN and Lora was about. So we also were trying this with another type of device (also off the shelf) but I thought that since we have a Lorawan gateway set up and these devices communicate over the Lora network that that would be enough…
If I understand you correctly though, it seems like the Lora gateways communicate with some backend (like TTN) and to use something like TTN, we will need to have devices that we can set up with specific codes for our applications withing the TTN. In other words, for an off the shelf product to work, it needs to connect to not just any lora gateway but rather ones that are set up for a specific backend and for any other “off the shelf” products to be used by an application that we have built in TTN, we have to reprogram them to have the appropriate keys.
Lastly just to be sure, if I reprogram these devices to connect to my application in TTN, they will only be able to connect to a gateway that is also set up to communicate with the TTN and that other gateway or my own will be able to send the payloads etc to my application?
if you can set the (3) keys on these devices (see manual) then yes, all gateways on the TTN network can receive these devices and forward their data to your application.
1 Like
I fixed this problem generating a new APP KEY. 
I ran in exactly the same problem. Did you find out a root cause meanwhile?
Not really, no one is responding to the issue here from TTN. I wanted to try again with the V3 Stack.
I have the same problem, but after a lot of activation messages it finally connects and I can successfully send. Did you found out why?
Using ABP I don’t have any problem sending
I had the same issue and the solution was as simple as having the gateway traffic open while I sent the OTAA.
the solution was as simple as having the gateway traffic open while I sent the OTAA.
That would be a useful approach to seeing what is going on, but it would have absolutely no impact on the actual behavior of the components.
Any apparent difference in behavior would be coincidence - there are a variety of ways a “not fully right” join process could work sometimes while it fails others.
1 Like