[solved] Arduino-based device is joining and activating over and over

End Devices (Nodes) LMIC
1

I recently bought a Things Indoor Gateway and successfully registered it and connected it to TTN. Now I’ve built a simple IoT device that consists of an Arduino Pro Mini 3.3 and HopeRF RFM95. I’m running Matthijs Kooijman’s arduino-lmic library and its ttn-oota example program. In TTN my Gateway shows successful Joins and my Application shows successful Activations. However, the Arduino doesn’t seem to hear about these successes and keeps trying to join and activate again. It looks like the problem could be related to the receive timeouts shown below:

12:26:10.165 -> Starting
12:26:10.234 -> RXMODE_RSSI
12:26:10.234 -> 335: engineUpdate, opmode=0x8
12:26:10.268 -> Packet queued
12:26:10.305 -> 426: EV_JOINING
12:26:10.305 -> 1261: engineUpdate, opmode=0xc
12:26:10.339 -> 3737: EV_TXSTART
12:26:10.372 -> 4446: engineUpdate, opmode=0x88c
12:26:10.372 -> 6722: TXMODE, freq=906500000, len=23, SF=10, BW=125, CR=4/5, IH=0
12:26:15.709 -> start single rx: now-rxtime: 10
12:26:15.743 -> 338378: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
12:26:15.811 -> rxtimeout: entry: 338368 rxtime: 338316 entry-rxtime: 52 now-entry: 9 rxtime-txend: 312692
12:26:16.767 -> start single rx: now-rxtime: 10
12:26:16.767 -> 401326: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
12:26:16.868 -> rxtimeout: entry: 401660 rxtime: 401392 entry-rxtime: 268 now-entry: 9 rxtime-txend: 375768
12:26:16.971 -> 407334: engineUpdate, opmode=0xc
12:26:17.585 -> 450916: engineUpdate, opmode=0xc
12:26:17.619 -> 451435: EV_TXSTART

I’ve also verified that there are RxTimeout pulses on the DI1 pin that seem to correspond with the EV_TXSTART events. The device keeps trying to join and showing me EV_TX_START events with the occasional EV_JOIN_FAILED event.

The only thing I’ve changed in the ttn-oota example is the APPEUI, DEVEUI, APPKEY, and pin mapping:

const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {4, 5, 6},
};

My theory is that the APPEUI, DEVEUI, APPKEY are correct in my code because the device is successfully joining and activating (from TTN’s perspective). Also that the SPI interface is working correctly or I would not have successful radio transmissions from the device.

I’ve also tried deleting and recreating the Application and Device in TTN, and replacing both the Arduino hardware and the RFM95 hardware.

Can anyone suggest how I can determine what’s going wrong? Is there some kind of accessible logging in the Things Indoor Gateway that could help? Could my receive problem be that I’m listening on the wrong frequency(s)? I’m new to LoRaWAN so I could be missing something obvious.

I’ve included some TTN screenshots below:

image

image

image

image

2

it continues like that or it stops after 3 times ?

  • I see that you’re node and TTIG are very close… probably to close
  • you have other gw’s nearby ?
  • did you reset framecounters
3

Thanks for your response:

I see that you’re node and TTIG are very close… probably too close

I didn’t know that too close could be a problem. I’m accustomed to WiFi where I’ve never encountered that issue, so it didn’t occur to me. How does that impact the LoRaWAN communication?

you have other gw’s nearby ?

According to the TTN map, the closest TTN gateway is 14 km away. I don’t know about other LoRaWAN gateways nearby but I don’t think it’s likely. I’ve been watching the 915 Mhz uplink frequencies with an amateur radio receiver and haven’t seen much in my area.

did you reset framecounters

No. I read a little about that but didn’t really understand what problem it solved, and I wasn’t sure if I should be resetting my device at the same time that I reset the frame counters in TTN.

4

I forgot to answer your first question:

it continues like that or it stops after 3 times ?

It continues until I remove the power.

5

I’ve move the gateway as far away as I can without losing its WiFi connection. I also tried resetting the framecounters but didn’t see any affect. If I look at my Gateway in TTN it looks like it is sending the Join Accept on different frequencies with different spreading factors (screenshot below). Does my LMiC-based RFM95 need any configuration to be listening at those frequencies? I’m also wondering about the receive window. Does my device need some configuration to make sure it’s listening when the gateway is transmitting to it?

If I’m asking a lot of newbie questions I could answer myself by reading I’d be happy to go learn some more, if you can direct me to the right material.

image

6

For OTAA resetting frame counters is not required.

Sending with the devices in close vicinity might cause crosstalk between channels resulting in downlinks at the wrong frequency because TTN instructs the gateway to respond at a frequency based upon the uplink frequency, if that is the wrong one your node won’t receive any answer as it is listening on the wrong frequency.

Can you use something like SDR to check if the gateway is actually sending any data when a join response is generated by the back-end?

7

Ah, that’s out of your arduino’s node range, I was thinking can your node join through another GW and what happends then.

  • What’s the power source of your node
8

Good idea about the SDR. I just used my RTL-SDR dongle to capture what looks like the gateway transmitting a Join Accept in response to the Join Request from my device. It’s a short burst 500 kHz wide at 923.9 MHz, just as TTN says. Screenshot below:

image

9

My power source is the USB-Serial adapter I use to program the Arduino Pro Mini. It normally sits at 3.4V but I just put it on an oscilloscope and can see that it occasionally drops to about 3.1V for a short time. The screenshot below shows one of those drops that lasted for 350ms.

image

10

I caught another Join Accept radio transmission. This one was on 923.3 and lasted longer then the last one. I presume that’s because this one used SF10 and the previous one used SF7.

image

1 Like
11

Looks like the gateway works. That means the issue is probably in the node, but there is one thing to check first. Take a look at the regional parameters for your location to check if the frequency and spreading factor used for the response match the specification. (They should, but it is better to make sure.)
If the otaa response matches the regional parameters you need to check the node firmware. Best is to start with a basic example configured for your region if you can find one.

BTW, for LMIC on Arduino you might need to relax the timing. Search the forum for the magic on how to do that :wink:

12

BoRRoZ, I’ve changed power supplies and now the voltage drop (while transmitting?) isn’t as noticeable. Screenshot below. Unfortunately, the behavior hasn’t changed.

image

1 Like
13

Jac,
Thanks for the suggestions. I’ve looked at the regional parameters and TTN frequencies for my location (Austin, Texas) and I don’t see any discrepancies. I’ve included a capture of a radio transmission from my device on 904.1 MHz with SF=10. I’m using the basic ttn-otaa example that came with the arduino-lmic library and have only made the minimum required changes. I’ll go investigate the relaxed timing for Arduino.

image

14

Sounds like a DIO pins issue to me, triple check DIO0 and DIO1 are correct, also disconnect DIO2 as its not needed and I have seen issues before with it connected.

15

+1, considering also the platform.

16

Relaxing the timing fixed the problem! I don’t understand why yet but I’m very happy to see it start working. I’ll go read some posts about that timing. Thanks to everyone who answered and made suggestions.

image

1 Like
17

Well, relaxing the timing hasn’t turned out as well as I’d hoped. At first it allowed my device to join pretty quickly but in subsequent tests sometimes it joins and sometimes it doesn’t. Also, after joining it doesn’t seem to send my data consistently. Some uplink transmissions just don’t seem to succeed.

As I’ve been reading more about the timing considerations and reading more about other people’s struggles with the Arduino with 8 Mhz 328p processor I’m starting to wonder if I’m just trying to use the wrong platform. Any opinions? Can the Arduino Pro Mini + HopeRF RFM95 be made to work reliably with TTN? If not I’d like to know now so that I have time to make a better choice.

18

I think there are a lot of successful experience with this combination or equally light-power ones. Loss of some packets is something that some TTIG owners experienced (me too, having other gateways around I can tell when this happens), so do not blame the node only.

19

Thanks, that’s very helpful. I wanted to make sure I hadn’t made a platform choice that was going to make it more difficult than necessary. I’m excited about LoRaWAN, but after 2 days of trying to get a basic example program to work I was having doubts. I feel better knowing that there are helpful and experienced people on this forum who can help me if I need it.

20

After reading the Timing section of the README.md file that comes with the MCCI_LoRaWAN_LMIC_library, I moved DI0 and DI1 to interrupt-enabled Arduino pins 2 and 3 and enabled the use of interrupts in lmic_project_config.h:

#define LMIC_USE_INTERRUPTS

I also set the ‘clock relaxation’ value to 20% right after calling LMIC_reset():

// Reset the MAC state. Session and pending data transfers will be discarded._
LMIC_reset();

// Cause the RX windows to open earlier to accomodate issues caused by the 
// Arduino Mini's relatively slow (8 MHz) clock
LMIC_setClockError(MAX_CLOCK_ERROR * 20 / 100);

My device’s uplinks are working much more consistently now. I’ve integrated my TTN Application with IFTTT’s Notification service so that I’ll have a record of any missing data uploads. The 20% clock relaxation may be more than I need, and causing additional airtime and battery use, so I’ll try lowering that value after I feel confident that the radio side of things is working consistently.

Again, thanks to everyone who’s helped me get this far.

1 Like