I’m quite new to LoRa / TTN and the last few months I’ve been playing around with some hardware/software. Basically I built a node (Frank Beks,Creating a TTN node using a Pro Mini, and a few weeks ago also a Gateway based on a RPi 2 and IMST IC880 concentrator board. The good news is that everything is up, running, reliable and functional however…
OTAA joining on the TTN network does not work as expected. Joining the TTN network takes up to 15 minutes and I never get a faster / better join than SF11. I’ve seen quite some topics covering the problem I also experience, but the solutions that are presented don’t solve my issue nor I understand the real cause.
(I tried changing lmic.c file with DR_SF9 iso DR_SF7 and adding the LMIC_setClockError function without success.)
I also signed up for a developers account on the KPN LORA network and using exactly the same hardware/software (I only changed the DEVEUI, APPEUI and APPKEY) it joins flawless and within seconds using SF7. Everytime, every boot/restart. With this “knowledge” I can only conclude there is nothing wrong with the hardware/software used on the node.
As I had no TTN gateway reach nearby I decided to build a gateway myself. When I try to join the TTN using OTAA I can see the gateway receives all Join Request messages and also sends a Join Accept in return however the node does not seem to receive these Join Accept messages until the node starts sending SF11 messages. After sending the first SF11 Join Request message the Join Accept message is received and the join is succesful.
(It seems this node-behaviour is the same on other nearby (Eindhoven) TTN Gateways.)
I really hope someone can point out “the one thing” that I am missing or guide me in the right direction.
I must admit that most tests take place within 5 meters of my Gateway, however I tried multiple distances (up to 1km) without a noticable change in the Join proces. (Ofcourse SNR/RSSI change, but as expected.)
After a succesful Join it never misses a message/transmission in a range from 3-xxx meters.
Somehow it “feels” like the node is listening on the wrong freq or at the wrong time however if that is the case I wouldn’t expect it to Join at all. (And why does it Join KPN instantanious?)
As this is my first and only node I will continue to experiment with other hardware in the near future.
There must be an explanation but for now I lack the experience and knowledge to get to the bottom of this. Maybe Frank Beks can write down his experience as he built many of these nodes? (Do all these nodes show the same behaviour?)
The problem with using nodes too close to a gateway is that the gateway receives the same packet on multiple frequencies (cross-talk). Chances are the response will be at the wrong frequency resulting in the node not receiving it.
Another possible cause of join errors is the transmissions by the gateway not being received by the node because of low signal strength. Just a (silly) question, are you sure your gateway antenna is connected to the right u.Fl connector? (Should be the one furthest away from the row of 20 pins)
What kind of antenna are you using for the gateway?
Hi Koen, I can share my thoughts. After doing a lot of workshops (running into the same problems on SOME nodes) i have stopped using OTAA in my workshops. Simply too time consuming, and ABP works like a charm, instantly. Took me many days (and nights) and at some point I gave up, In workshops there is always a lack of time, so avoiding OTAA problems is a good start. RN2483 nodes work fine on this point. May be it is an oscillator / stability problem (RN2483 has a temperature compensated XTAL). Strange that KPN works here fine, so it can be a TTN gateway-RFM95 issue? Sorry, no solution for this, but if you find one, just let me know
What about the TTN specific OTAA timing?
Somewhere on this forum i read that in TTN the downlink in OTAA is shifted to the end of the timing slot, to give slow gateways a better chance.
This effect can be watched on the console. It takes around 4-5 seconds until a successful OTAA join is finished. On other networks this goes faster.
Maybe this behaviour can cause reception timing problems on nodes with unstable time base (temperature of oscillator, etc.)?
@kersing I understand the problem of cross-talk between channels. I’ve done some tests the last few days with my node 20-30 meters apart from the gateway with quite some obstacles in between. Does not make a difference. Also I am 100% certain the gateway antenna is connected to the correct connector. Looking at the Traffic data a few days ago I saw a “strange” node with a Join Request, a succesful Join, sending uplink and downlink messages using SF7 all in a time frame of 13 seconds… ( The used antenna is this SMA 1/4 868Mhz 17cm version. )
Evidence:
It’s really difficult to “blame” the hardware so far…
@galagaking Thank you very much for this first hand experience and thoughts. What other hardware did you use with the RN2483 chip? Maybe I should try the RFM95 with an original UNO board to rule out these cheap Chinese Pro Mini clones and see what happens then.
@Verkehrsrot Interesting approach! I really lack a lot of knowledge down that road, but maybe @kersing or another TTN developer can shed some light on that idea? I can hook up a DCF77 receiver to the Pro Mini board involved and measure how many seconds it’s off in 1 or more days if that would deliver any useful information?
I have exactly the same problem: the node is unable to OTAA link in SF7, but it finally links in SF9 or SF11.
I have used cheap chinese pro mini clones, but also original Arduino UNO and Sparkfun original Arduino pro mini without any success.
Now i only use ABP, but would love to find a solution to this issue.
I used the ‘Kiss-Lora’ https://github.com/TheThingsIndustries/KISSLoRa-demo. But as the RN2483 comes with processor included, it will function nearly stand-alone. It is just controlled by TX/RX serial commands. I have tried several Arduino boards (original and Chinese) -> no difference. In the ‘early days’ i suggested a change in the join frequency in LMIC.C during workshops:
Go to line 684 (or find ‘setDrJoin’ to find the line below)
Change setDrJoin(DRCHG_SET, DR_SF7); to: setDrJoin(DRCHG_SET, DR_SF9);
It could be coincidence, but that gave far better results in the OTAA join process. But also this change has nowadays no effect anymore…
A real good test should include both gateway and node logs with an exact timing reference. Would be great to solve this problem. May be the tolerance of the RFM95 is the problem, even the LMIC in combination with RFM could have some timing problems. Nice puzzle!
I have the same problem that the join procedure takes long time on some nodes and in that case SF9 or SF10 is used finally. Compared the nodes that work well (SF7) with the slow ones, I have done configurations to safe power on the slow ones to let them operate on a battery. During my experiments I modified the US_PER_OSTICK_EXPONENT in config.h of the (Arduino) LMIC, and by that I got one node that joined formerly with SF9 or SF10 now to join with SF8. I have not finished my analysis, but it seems that the timing of the connected microcontroller is very critical on lower speading factors.
Update: I found here Over-the-air-activation OTAA with LMIC a hint which makes the RX window(s) longer. That works for me. My formerly not joining with SF7 node now joins with SF7. So the timing seems not to be accurate enough.
Just to add something useful to this topic. Found some spare time this evening and decided to try an OTAA join with different hardware. I used an original Arduino Uno (5v with 16Mhz crystal) and a RFM95W chip. Connected the inputs/outputs of the RFM95W directly to the Uno using some soldering of jumper wires. The most “dirty” way of prototyping
Added a sensor to TTN, used the example that came with the LMIC library and powered it all up…
Instant SF7 connection! (Without using the LMIC_setClockError function.) Also switched on the Pro Mini as you can see, but no luck joining there… Definitely hardware playes a role as well as software. (As KPN OTAA let’s the Pro Mini join SF7.)
