mcci-catena/arduino-lmic

ttn-otaa-feather-us915 hangs on os_init

Closed this issue · 16 comments

Hi, I'm currently trying the master (and 3.x) branch and in both cases the setup hangs on os_init. Using the 2.x tag works better, however never joins via OTAA network.

I'm testing with an Adafruit Feather M0 RFM9x.

I did the soldering of io1 and 6, as suggested here

Couple of possibilities come to mind. I actually test with a Feather M0 RFM9x, ... but I use the MCCI BSP.

Just to confirm, can you attach the sketch you're using? And... do you have anything attached to the Feather M0 (beyond the required wire)?

I'm using the example provided and just changed the APPEUI etc.

Nothing attached, just the one wire and an antenna

There are several examples, and ... some are better than others. Can you give me the exact name? Thanks!

OK, I'll double check.

Adafruit has apparently changed some default in the board support package that conflicts with the LMIC. The code that used to work to autoddetect the Feather M0 no longer does. The workaround, while we're researching this, is to use the MCCI Board Support Package and select the MCCI Catena 4410 (which is Feather M0 based and has no additional features).

I have just tested both, and the LMIC works with the MCCI BSP, but no longer works with the 1.5.1 Adafruit BSP. Sorry for any inconvenience.

@brentru I'm busy the next several days; more details about analysis sent offline. It's almost got to be a problem in the default GPIO or SPI setup. (Anyone else who wants to jump in and look at this, please feel welcome.)

@aparcar I also tried the Adafruit Feather M0 Express option with the Adafruit BSP; no luck. That also used to work.

@terrillmoore thank you very much for looking into this issue! Using the 4410 board starts the process, however appears to be deaf.

15:07:06.701 -> 9618358: EV_JOIN_TXCOMPLETE: no JoinAccept
15:07:07.629 -> 9674410: EV_TXSTART
15:07:13.732 -> 10056290: EV_JOIN_TXCOMPLETE: no JoinAccept
15:07:13.732 -> 10056303: EV_JOIN_FAILED
15:07:21.935 -> 10569574: EV_TXSTART
15:07:28.410 -> 10972835: EV_JOIN_TXCOMPLETE: no JoinAccept
15:07:29.107 -> 11016989: EV_TXSTART
15:07:35.215 -> 11398865: EV_JOIN_TXCOMPLETE: no JoinAccept

Is it possible that even the 4410/master is broken?

@aparcar It worked fine for me (joined, sent messages, got downlinks, etc., using TTN as the network.)

Although anything is possible, since it worked for me, we have to rule out a setup or environment problem at your location.

My suggestion is that you try the compliance test example, as it gives much more diagnostic information. Also, check your gateway; they often (in my experience) get into a state where uplinks work but downlinks don't. Cycling power can help. Check the TTN status page and make sure US is not out (I've chased "bugs" for hours based on that). Finally, if you have two boards, try the raw sketch and make sure you can send data back and forth.

Thanks I'll get in contact with the Gateway admins and see if downlink is broken...

The compliance does not really help me, but maybe the problem is obvious for others...

16:43:40.126 -> 
16:43:40.126 -> ------------------------------------------------------------------------------
16:43:40.126 -> compliance-otaa-halconfig.ino
16:43:40.126 -> Version 3.0.99.10
16:43:40.126 -> LMIC version 3.0.99.10 configured for region 2.
16:43:40.126 -> Remember to select 'Line Ending: Newline' at the bottom of the monitor window.
16:43:40.126 -> ------------------------------------------------------------------------------
16:43:40.126 -> 
16:43:40.126 -> calibration not supported
16:43:40.159 -> Packet queued
16:43:53.038 -> 313916 (5022 ms): EV_JOINING
16:43:53.038 -> 314004 (5024 ms): EV_TXSTART: ch=2 rps=0x04 (SF10 BW125 CR 4/5 Crc IH=0), datarate=0, opmode=88C, txend=313912, avail=0
16:43:53.038 -> 648972 (10383 ms): EV_RXSTART: freq=924.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate=0, opmode=88C, txend=337221, avail=0, rxtime=649596, rxsyms=7
16:43:53.038 -> 711472 (11383 ms): EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate=0, opmode=88C, txend=337221, avail=0, rxtime=712096, rxsyms=7
16:43:53.038 -> 715700 (11451 ms): EV_JOIN_TXCOMPLETE, saveIrqFlags 0x80, nLateRx=0 ticks=0
16:43:53.038 -> 738864 (11821 ms): EV_TXSTART: ch=64 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate=4, opmode=88C, txend=739407, avail=0
16:43:53.038 -> 1052435 (16838 ms): EV_RXSTART: freq=923.3 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate=4, opmode=88C, txend=740685, avail=0, rxtime=1053060, rxsyms=14
16:43:53.038 -> 1114936 (17838 ms): EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate=4, opmode=88C, txend=740685, avail=0, rxtime=1115560, rxsyms=7
16:43:53.038 -> 1119163 (17906 ms): EV_JOIN_TXCOMPLETE, saveIrqFlags 0x80, nLateRx=0 ticks=0

@aparcar thanks very much for posting the log. Everything looks fine (which means that it's less likely to be an LMIC problem).

On the TTN console.thethingsnetwork.org, you will see a clear indication on your device's page, if the network is hearing your JoinRequests. If it's not, then you have a credential problem of some kind, probably (or a gateway problem). If the network is hearing your JoinRequests, you can poke around and see the RSSI. If this is "low" (like -120 or less) you might have an antenna problem on your board. If those are "ok" (like -70 or greater, can go as high as -30), then it starts looking like a gateway downlink problem. In between -120 and -70 is a gray area; I've seen boards without antennas picked up with RSSI of about -90, when the gateway is not too far away. Gateways are more sensitive than devices; propagation is pretty symmetric but the device receiver is not as sensitive as the gateway receiver, so you have less budget, and you can have devices that can talk to the network but not receive.

I raised a bug on the Adafruit BSP adafruit/ArduinoCore-samd#203 -- they requested that I find the commit that broke things, but... that's a big project. I think it would be easier to debug. But I have no time to debug at the moment (even though that would be less time than finding the commit that causes problems).

The issue here been actually a broken gateway, I informed the admins and they fixed it.

Should I close this issue or leave it open until the adafruit issue is resolved?

Please leave this issue open until we can close #524.

I believe this is closed in v3.1.0 (by #528 and #529).