mcci-catena / arduino-lorawan

User-friendly library for using arduino-lmic with The Things Network and other LoRaWAN® networks
MIT License
288 stars 54 forks source link

EV_TXCOMPLETE hardly seen when using Feather M0 #166

Closed d-a-v closed 3 years ago

d-a-v commented 3 years ago

I am using the provided example ttn_abp.ino (CFG_eu868) from the git head version of this library, modified with this configuration:

#if defined(ARDUINO_AVR_UNO)
const lmic_pinmap lmic_pins =
{
    .nss = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = LMIC_UNUSED_PIN,
    .dio = { 2, 9, 8 },
    .rxtx_rx_active = 0, // ignored <= rtxt=unused
    .rssi_cal = 8, // magic
    .spi_freq = 1000000, //LMIC_SPI_FREQ,
    .pConfig = NULL,
};
#elif defined(ADAFRUIT_FEATHER_M0)
const lmic_pinmap lmic_pins = {
    .nss = 8,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 4,
    .dio = { 3, 6, LMIC_UNUSED_PIN },
    .rxtx_rx_active = 0, // ignored <= rtxt=unused
    .rssi_cal = 8, // magic
    .spi_freq = 8000000, //LMIC_SPI_FREQ,
    .pConfig = NULL,
};
#endif

It works fine with the AVR, TX_COMPLETE comes 2 secs after TX_START (see logs below).

With the Feather M0 I get this:

22:35:11.322 -> Starting
22:35:11.322 -> 175244: EV_TXSTART
22:35:11.322 -> Packet queued

and TX_COMPLETE very hardly or never comes. However, what has to be noted is that the packet is sent, and correctly received (I'm using TTN for testing). But the state machine stay stuck in the state "not complete".

Also, I sometimes get failures when the sketch is booting:

22:27:23.866 -> Starting
22:27:23.898 -> 258805: EV_TXSTART
22:27:23.898 -> Packet queued
22:27:23.898 -> FAILURE 
22:27:23.898 -> ...libraries/arduino-lmic/src/lmic/radio.c:1065

which is

    ASSERT( (readReg(RegOpMode) & OPMODE_MASK) == OPMODE_SLEEP );

Am I the only one having such failures with the Feather M0 ? (as a side note, I also have similar issues with the Feather 32u4)

This is the same exact sketch with the goo'old AVR which never fails:

21:54:58.507 -> Starting
21:54:58.539 -> 8423: EV_TXSTART
21:54:58.539 -> Packet queued
21:55:00.631 -> 139116: EV_TXCOMPLETE (includes waiting for RX windows)
21:56:00.733 -> 3889603: EV_TXSTART
21:56:00.733 -> Packet queued
21:56:02.824 -> 4020309: EV_TXCOMPLETE (includes waiting for RX windows)
21:57:02.910 -> 7770799: EV_TXSTART
21:57:02.943 -> Packet queued
21:57:05.002 -> 7901583: EV_TXCOMPLETE (includes waiting for RX windows)
…
22:10:32.153 -> 58226660: EV_TXSTART
22:10:32.153 -> Packet queued
22:10:34.275 -> 58357364: EV_TXCOMPLETE (includes waiting for RX windows)
22:11:34.386 -> 62107856: EV_TXSTART
22:11:34.386 -> Packet queued
22:11:36.475 -> 62238562: EV_TXCOMPLETE (includes waiting for RX windows)
… …
terrillmoore commented 3 years ago

Is DIO1 connected to D6? The Feather M0 doesn't do this by default.

d-a-v commented 3 years ago

Well, it was not and when it is, it works very well !

I was falsely convinced that it was not needed on the M0 because of the same issue for the 32u4, which is quite visible on search engines (and this recently received a commit in your examples). I never saw similar comments about the M0. I will submit a pull request then, thanks very much !

bkkl commented 1 year ago

So is the solution to this issue soldering a wire from DIO1 to D6? Or is it a pin map setup change?

bkkl commented 1 year ago

Answering my own question: https://blog.werktag.io/posts/adafruit-feather-m0-lora-on-ttn/