Feather 32u4 with TinyLoRa for weeks-long balloon contest

End Devices (Nodes)
14

Did you enable the correct region in the TinyLoRa library? See:


So, did you follow that tutorial? That seems quite solid to me, except for not mentioning the region settings…?

Maybe show us the code that you used, so we can compare that to the screenshots you posted. (See How do I format my forum post? [HowTo])

As for the jumper, it seems that it’s needed for LMIC, but not for TinyLoRa, regardless whether you’re using the M0 or 32u4.

The jumper is documented for the M0 as:

Pin 3 is internally connected to pin io0, but we’ll need to add a jumper wire between the Feather Digital Pin 6 and Feather Pin io1.

Looking at the pin layout of the M0, you’ll read:

Since not all pins can be brought out to breakouts, due to the small size of the Feather, we use these to control the radio module

  • #8 - used as the radio CS (chip select) pin
  • #3 - used as the radio GPIO0 / IRQ (interrupt request) pin.
  • #4 - used as the radio Reset pin

…

There are also breakouts for 3 of the RFM’s GPIO pins (IO1, IO2, IO3 and IO5).

So, the IOx pins are connected to the little green RFM LoRa board, but on the M0 no pin from the MCU is connected to the RFM’s GPIO1.

Now, things are not much different for the 32u4, though now pin 7 is internally connected to pin IO0, instead of pin 3:

  • #8 - used as the radio CS (chip select) pin
  • #7 - used as the radio GPIO0 / IRQ (interrupt request) pin.
  • #4 - used as the radio Reset pin

…

There are also breakouts for 3 of the RFM’s GPIO pins (IO1, IO2 and IO3).

Indeed, when using the TinyLoRa library, you’ll see a small difference in the code:

// Pinout for Adafruit Feather 32u4 LoRa
TinyLoRa lora = TinyLoRa(7, 8);

// Pinout for Adafruit Feather M0 LoRa
TinyLoRa lora = TinyLoRa(3, 8);

But no mention of pin 6 anywhere, in TinyLoRa. However, the M0 tutorial uses LMIC, and things are different in Arduino-LMIC:

// Pin mapping for Adafruit Feather M0 LoRa
const lmic_pinmap lmic_pins = {
    .nss = 8,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 4,
    .dio = {3, 6, LMIC_UNUSED_PIN},
    .rxtx_rx_active = 0,
    .rssi_cal = 8, // LBT cal for the Adafruit Feather M0 LoRa, in dB
    .spi_freq = 8000000,
};

For Arduino-LMIC, the DIO pins are documented as:

In LoRa mode the DIO pins are used as follows:

  • DIO0: TxDone and RxDone
  • DIO1: RxTimeout

So, for LMIC the wire to pin 6 (or another pin of your choice) is needed to detect a RxTimeout; without it, LMIC will probably hang after an uplink, when it’s trying to determine if there’s any downlink in RX1 or RX2.

I’d guess TinyLoRa does not support downlinks at all?

So, (very) long story short: when using LMIC on the 32u4 I’d say you’ll need the jumper wire as well. (But I’ve not used the Adafruit boards, nor TinyLoRa.)


“Privilege” doesn’t seem to be the correct translation for what you’re trying to say, but when far away from the gateway, indeed use SF12, which is the slowest transmission speed with the best range. Using SF12 the transmission will take a lot longer (so you can send far fewer packets per hour) but chances that a gateway receives the transmission are better. When SF12 works, go down to SF11 and so on.

Also, as long as you’ve not received anything: put the device as high as possible, outside, to improve the chances of a gateway receiving the transmission. And check the length of your antenna wire.

So: do you know how to set the device to use SF12 for your first tests?


Reading that, I was expecting that LMIC would simply not work at all. But the MCCI Arduino-LMIC documentation explicitly mentions it is supported. Maybe using LMIC leaves not enough flash memory for other code and libraries, like to read some sensors.

Still then: if possible, then LMIC is better, as OTAA is better than ABP, and LMIC supports ADR. But as OTAA needs a downlink for the Join Accept and as you don’t have access to any gateway logs, starting with ABP is better now. And the Adafruit tutorial looks great, so I’d say that starting with TinyLora (which only supports ABP) seems fine too.


That’s correct when using ABP.


Also correct for ABP; blue upward icons denote uplinks. (For OTAA, you’d first see orange and green icons for the Join Request and Join Accept, if all is well, where the green icon is only shown in the gateway’s Traffic page, which you cannot see.)

As an aside: Adafruit’s Decoder for a TTN Payload Format does not support negative values. If you ever get to that point, then see Negative Temperature - #3 by arjanvanb.

4 Likes