Why OTAA mode is always activation

1

Why OTAA mode is always activation.
image

2

Why did the TTN platform deliver the data successfully, but the terminal module did not receive the data? But a week ago the terminal module could receive the data.

3

Please don’t open a new topic for every piece of information you want to share with us. Instead, please add much more detail to this topic.

So, apparently it worked before? What has changed? What node are you using? What do you see in the gateway’s Traffic page (if you have access to that)? If you see a Join Accept then search for “join accept not received”.

Finally, please use the right terminology. Your “terminal module” is not something that we know on this forum.

(Aside, not related to your problem: what’s up with that weird DevEUI?)

1 Like
4

Hello,

I’m countering the same problem. I’m using the RN2483 LoRa chip in combination with an EFM32 Microcontroller. I got only activation messages in the console but never ACK or uplink messages. I use OTAA Activation. Can someone help me with this problem?

Thanks in advance,

SimonAantekening 2020-03-03 161330

5

Hi There,
Similar problem here… For the last months I’ve had a very stable sensor node (Metro M0 with RFM95W LoRa transciever from Adafruit plus sensors) connected through a The-Things-Gateway to The-Things-Network. Now I’m trying to set up a second node, identical to the first, and I can’t get it to JOIN the network successfully. I’m using the MCCI LoRaWAN LMIC library and using the ttn-otaa.ino example.

For the new node, the Application Data shows an Activation (yellow bolt)…
image
… and the Gateway shows a Join Accept (green bolt)…
image
… but nothing happens after this and the Serial output stops at the following…

Initializing SD card. Card initialized. Logging to file: LOGGER33.TXT
Date     	 Time   	 T(C)	 P(hPa)	 Alt(m)	 RH(%)	 CO2(ppm)
2020:03:03	11:34:55	21.01	1002.02	30.03	42.04	410.23
197681: EV_JOINING
197777: EV_TXSTART

…after which it also hangs the IDE :thinking:.

Now, the first node that’s been working flawlessly for months has the following Activation and Uplinks:
image
…and the Gateway shows the Join Accept and all works fine. The Serial output on reset follows…

Initializing SD card. Card initialized. Logging to file: LOGGER43.TXT
Date     	 Time   	 T(C)	 P(hPa)	 Alt(m)	 RH(%)	 CO2(ppm)
2020:03:03	13:28:34	28.51	997.20	134.51	23.46	0.00
858769: EV_JOINING
858878: EV_TXSTART
1200418: EV_JOINED
netid: 19
devaddr: 26022DEC
artKey: 90-D7-92-13-37-FC-D1-23-77-4E-5A-52-96-56-A1-7
nwkKey: 71-FB-41-E3-1F-AE-C2-E4-FB-7C-36-84-33-5F-35-0
1200808: EV_TXSTART
1370641: EV_TXCOMPLETE (includes waiting for RX windows)
1402001: EV_TXSTART
1537247: EV_TXCOMPLETE (includes waiting for RX windows)
Date     	 Time   	 T(C)	 P(hPa)	 Alt(m)	 RH(%)	 CO2(ppm)
2020:03:03	13:29:15	28.52	997.22	134.31	23.41	423.00
3416489: EV_TXSTART
3552938: EV_TXCOMPLETE (includes waiting for RX windows)

What could have changed since around October last year when I compiled the working node?

Am I missing something obvious?

Thanks for help in advance.

6

SOLVED (?)
Here are some unsettling things I’ve discovered since I last posted here.
My setup:

  • 2 Nodes: MetroM0+RFM95W+sensors;
  • Software: Based on ttn-otaa.ino + MCCI LoRaWAN LMIC library
  • Gateway: TheThingsGateway under my control and only one around
  • Network: TTN

The first node has been working flawlessly since Oct 2019. Second (new) node, identical in all respects, is highly unstable, won’t always join the network, and loses connectivity often with lockup. I have a watchdog timer that resets the system if not poked within 16 seconds. Here is my void loop, modified from otaa-ttn.ino example:

void loop() {
// we call the LMIC’s runloop processor […] beware that LoRaWAN timing is pretty tight, so if you do more than a few milliseconds of work, you
// will want to call os_runloop_once() every so often, to keep the radio running.

digitalWrite(5,HIGH);
os_runloop_once();
digitalWrite(5,LOW);
Watchdog.reset(); // poke the dog…
}

I added the digitalWrites to time the loop with an oscilloscope. I found that the Watchdog.reset() is adding 5ms to the loop. If I remove the Watchdog.reset() the loop runs in a few microsecs (~15us) and the JOIN never completes. I added a 5ms delay to the void loop and now it’s been running for about an hour without issues!

void loop() {
digitalWrite(5,HIGH);
os_runloop_once();
digitalWrite(5,LOW);
delay(5);
Watchdog.reset(); // poke the dog…
}

I suspect that the original node has a delay from the Watchdog that, by luck, is a little longer than the one I’m measuring on the current system, and that is why it has been so stable. I’ll never find out because I’m not going to touch that original node.

  1. How much delay can I add before the timing is broken? Is there a sweet-spot delay for maximum stability?
  2. Is this related to what I’ve been reading about relaxing the timing by adding LMIC_setClockError(MAX_CLOCK_ERROR * 2 / 100) which I tried originally but didn’t solve the JOIN issue?

I’ve never liked systems that rely on sloppy timing and this has given me cold feet to use RFM95W+LMIC. I’m going to give the Microchip RN2903 a try.

Edit: Now it’s been over 12h and it’s still running without problems.

7

The module was available before. The module is currently unchanged. The only changes are the values of Device EUI, Application EUI, and App Key.

image

image

image