"Starting LoRa...", "Failed"

[jhjulkun]

Basically the same problem as this when running hello_LoRa.ino
#23

I'm using RFM95 on a M0 arduino (however non adafruit), and I know it worked twice (coming out of power cycle),
but if I run more than once it fails, maybe the device is in slightly different state after power cycle
versus just pulling RESET low ? (I did hook up reset)

So fix is to remove the version check:
uint8_t ver = RFM_Read(REG_VER); if (ver != RFM9x_VER) return 0;

Once the check has been removed, it sends data to TTN as expected, so the code works, but why it fails is curious.
When it fails, the RFM_Read returns 0 (or maybe its just the first SPI read after reset that is flaky?)

[brentru]

What RFM95 product are you using - could you provide a link?

Our guide for this library includes a step where you connect a wire between Arduino pin 6 and the RFM9x's io1 pin. Please make sure youve done this since it's required to power cycle the RFM9x module:
https://learn.adafruit.com/the-things-network-for-feather/arduino-wiring

[jhjulkun]

But D6 is not used in TinyLoRa.cpp, nor in hello_LoRa.ino?

This is the board schematics
https://lowpowerlab.com/wp-content/uploads/2018/05/MoteinoM0_schematic.png

I did solder a wire from D5 to reset on the RFM95
TinyLoRa lora = TinyLoRa(9, A2, 5);

Like stated TinyLoRa is able to send data to TTN.

[jhjulkun]

Some updates: I have two boards.
Both worked first time around (after power cycle) but then started failing on new uploads.
I changed one and hooked up D6 to dio1, and then it worked!
I then tried the 2nd one (w/o any modifications), and it now also works all the time..

Since D6 doesn't seem to be used (correct me if I'm wrong), maybe dio1 needs some additional pullup?
BUT: this is where it gets interesting, yesterday I had D7 hooked up to dio1 (not D6), so if a pullup is necessary,
then it should have worked every time then too?
And again, the 2nd device (with only D5 hooked up to reset) now also works (every time so far).
I'm baffled. I also added a 3 time retry to reading the register, but it seems to pass on the first go.

[danalvarez]

This is happening to me as well. My setup is slightly different: Using Arduino Nano with RFM95C breakout board from Adafruit. The pins are connected as in this guide: https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/arduino-wiring, and modified hello_LoRa.ino to reflect these pin changes (basically TinyLoRa lora = TinyLoRa(3, 4, 2);).

The board managed to transmit to my Chirpstack LoRa Server several times until, at some point, it starting throwing out Version 0 and Failed, check your radio. Even if I comment out the version check from the TinyLoRa library, the board then gets stuck in Sending LoRa data... and never increases the frame counter (aka never transmits).

I managed to get it to transmit sometimes by power cycling, but this is not consistent. Resetting via the Arduino reset pin does not seem to work.

Here's an example of what happens (note I've disabled the version check in the library for this example):

Starting LoRa...Version:18
OK
Sending LoRa Data...
Frame Counter: 0
delaying...
Sending LoRa Data...
Frame Counter: 1
delaying...
Sending LoRa Data...
Frame Counter: 2
delaying...
Sending LoRa Data...
Frame Counter: 3
delaying...
Sending LoRa Data...
Frame Counter: 4
delaying...
Sending LoRa Data...
Starting LoRa...Version:0
OK
Sending LoRa Data...

It transmits 5 packets correctly, then gets stuck in Sending LoRa Data.... I then reset the code via the Arduino reset pin, and the device returns Version:0 and gets stuck in Sending LoRa Data....

Any idea or fixes at this point, @brentru ? Thanks in advance for your help!

[brentru]

my Chirpstack LoRa Server

This library is untested with chirpstack (was designed to work with TTN v2) so I'm not really sure where the instability is and can't test (I don't have a chirpstack server set up)

[danalvarez]

Hi @brentru, I moved to TTN v2 to test this out. Unfortunately, the same thing is happening. I get it to transmit a couple times after power cycling, but it then gets stuck in Sending LoRa Data.... I turned on the debug output and this is what I get:

Starting LoRa...SPI Read ADDR: 42 DATA: 12
SPI Write ADDR: 1 DATA: 0
SPI Write ADDR: 1 DATA: 80
SPI Write ADDR: 9 DATA: FF
SPI Write ADDR: 1F DATA: 25
SPI Write ADDR: 20 DATA: 0
SPI Write ADDR: 21 DATA: 8
SPI Write ADDR: 26 DATA: C
SPI Write ADDR: 39 DATA: 34
SPI Write ADDR: 33 DATA: 27
SPI Write ADDR: 3B DATA: 1D
SPI Write ADDR: E DATA: 80
SPI Write ADDR: F DATA: 0
OK
Sending LoRa Data...
Package length: 14
SPI Write ADDR: 1 DATA: 81
SPI Write ADDR: 40 DATA: 40
SPI Write ADDR: 6 DATA: E2
SPI Write ADDR: 7 DATA: 2C
SPI Write ADDR: 8 DATA: F3
SPI Write ADDR: 1E DATA: A4
SPI Write ADDR: 1D DATA: 72
SPI Write ADDR: 26 DATA: 4
SPI Write ADDR: 22 DATA: 12
SPI Write ADDR: D DATA: 80
SPI Write ADDR: 0 DATA: 40
SPI Write ADDR: 0 DATA: A1
SPI Write ADDR: 0 DATA: 14
SPI Write ADDR: 0 DATA: 2
SPI Write ADDR: 0 DATA: 26
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 1
SPI Write ADDR: 0 DATA: 92
SPI Write ADDR: 0 DATA: 6B
SPI Write ADDR: 0 DATA: B2
SPI Write ADDR: 0 DATA: 57
SPI Write ADDR: 0 DATA: 28
SPI Write ADDR: 0 DATA: B0
SPI Write ADDR: 0 DATA: C
SPI Write ADDR: 0 DATA: D4
SPI Write ADDR: 0 DATA: 54
SPI Write ADDR: 1 DATA: 83
SPI Write ADDR: 1 DATA: 0
sent package!
Frame Counter: 0
delaying...
Sending LoRa Data...
Package length: 14
SPI Write ADDR: 1 DATA: 81
SPI Write ADDR: 40 DATA: 40
SPI Write ADDR: 6 DATA: E2
SPI Write ADDR: 7 DATA: 20
SPI Write ADDR: 8 DATA: 26
SPI Write ADDR: 1E DATA: A4
SPI Write ADDR: 1D DATA: 72
SPI Write ADDR: 26 DATA: 4
SPI Write ADDR: 22 DATA: 12
SPI Write ADDR: D DATA: 80
SPI Write ADDR: 0 DATA: 40
SPI Write ADDR: 0 DATA: A1
SPI Write ADDR: 0 DATA: 14
SPI Write ADDR: 0 DATA: 2
SPI Write ADDR: 0 DATA: 26
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 1
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 1
SPI Write ADDR: 0 DATA: 75
SPI Write ADDR: 0 DATA: 20
SPI Write ADDR: 0 DATA: 3F
SPI Write ADDR: 0 DATA: EE
SPI Write ADDR: 0 DATA: 86
SPI Write ADDR: 0 DATA: AD
SPI Write ADDR: 0 DATA: 11
SPI Write ADDR: 0 DATA: B1
SPI Write ADDR: 0 DATA: 1B
SPI Write ADDR: 1 DATA: 83

Note that it transmits one packet correctly (shows up in TTN console), but it then gets stuck on SPI Write ADDR: 1 DATA: 83.

So Chirpstack is not the issue. Any ideas?

[danalvarez]

Hi again @brentru upon further investigation, it seems the code is getting stuck at SPI Write ADDR: 1 DATA: 83 because the _irq pin is never pulled high by the RFM95C Adafruit breakout. I read here that the SX127x modules (albeit I am using RFM95) might get stuck on TX if the Arduino is not able to provide at least 120 mA, so to discard this I connected the RFM95 to an external power supply, but no luck, same behaviour. I also read on the same link that some level shifters may not support high frequencies on the SPI lines. The Adafruit breakout for the RFM95 uses the 74HC4050D, which is a "high speed level shifter" as per the datasheet, so I wouldn't expect that to be the issue either. I still went ahead and changed the SPI frequency from 4 MHz to 1 MHz in the library: static SPISettings RFM_spisettings = SPISettings(1000000, MSBFIRST, SPI_MODE0);, but no luck, same behaviour.

Have you any ideas as to why the _irq pin might not be pulled high by the RFM95? Is there a need to use DIO1 of the RFM95?

NOTE: this failure occurs sometimes on the first transmission, and other times it manages to transmit up to 3-5 packets before it fails. But I've never been able to transmit more than 3-5 packets on a single run.

[mranta]

I've been wrestling with this issue ocassionally and finally had some time to sit down and test different layouts where things fail and why.

The problem at least in my case seems to arise when using some M0 boards but not with 32u4 based ones. For example comparing schematics between Feather RFM95 32u4 vs M0 versions shows they seem to have different pullup schemes.
This led to more browsing and lo and behold I could swear I've not seen earlier the following bottom paragraph at Adafruit site :

The CS pin (# 8) does not have a pullup built in so be sure to set this pin HIGH when not using the radio!

The only place in the library at TinyLora.cpp where CS isn't explicitly set is right at the beginning in TinyLoRa::begin() right after setting pinmode for _cs, so I inserted following on current line 347 and all the problems vanished. (Setting it LOW returns the error in the topic)

digitalWrite(_cs, HIGH);

The tests were ran on preassembled Feather LoRa boards (M0 & 32u4), Adalogger 32u4 + RFM95 module, ItsyBitsy M0 + RFM95 module and the results line up with the previously mentioned.
All the boards were powered using usb in order to be able to view the serial output.

Eagerly awaiting someone else to confirm if this approach works beside my own few boards.

ps. Using the old trick connect io1 to random digital pin had no effect whether attached or not at any phase of testing.