LoRa module stopped working and can't get it to work again

TTN Network and Services The Things Stack v3
1

Hello
I look for help in this case. I have 4 LoRa modules from Adafruit.
RFM9X
And 3 teensy4.1 and 2 teensy 3.2 to test with.
I have tried all modules with the teensy’s and some combination of modules and teensy’s to be sure that it is not a teensy or a module with hardware failure. I know they have worked because a half year earlier they have worked together with my gateway. Now, when I look at the live messages of my gateway nothing happens. No join request or anything. I know that the gateway is working, as it pick up the message of foreign LoRa modules which are in reach.

I ended also up with direct soldering the LoRa module to the teensy and took the standard OTTA program from the examples and adjusted only the pin numbering in the pinmap constant of the program. Still nothing happens. I checked countless times the wiring with my multimeter and it all seems to be good.

I think the chances are almost zero that every module and every teensy have hardware failures. I even soldered a new LoRa module which just was in the original package and never used defore.
I currently use this library “mcci-catena/MCCI LoRaWAN LMIC library @ ^4.1.1”

Do anyone have a tip what I could check or change to get it back to work again?

2

Since you have multiple Teensies and LoRa modules try one of the point to point LoRa libraries. These libraries will have real simple transmit and receive examples, so you can prove if each combination of microcontroller and LoRa module is working.

3

Did you check the batteries?

4

Thank you two for the ideas.

Power is okay as I run the modules directly from my PC to be able to upload codes and see what’s going on on the serial monitor. Therefore power is comming from the PC USB connection.

I tried the Rx and Tx Testprogram from the arduino side. This is interesting. One side is never getting the reply from the Rx module. Also the same when I swap modules or when I swap the Rx and Tx to test the other way around.

Program is from the arduino website, as I did not have figured out how to set the pins in the program which comes from the radioheads library example folder.

Then I think I have to figure out where there’s the problem.

Arduino LoRa TX Test!
LoRa radio init OK!
Set Freq to: 868.00
Sending to rf95_server
Sending Hello World #0
Sending...
Waiting for packet to complete...
Waiting for reply...
No reply, is there a listener around?

Arduino LoRa RX Test!
LoRa radio init OK!
Set Freq to: 868.00
Received: 
48 65 6C 6C 6F 20 57 6F 72 6C 64 20 23 30 0 20
20 20 20 0 
Got: Hello World #0
RSSI: -65
Sent a reply
5

What came across my mind is:
The LoRa modules receive the “Hello world message” and then send back an answer, that the Tx from one side is confirmed as working and the Rx on the other side is confirmed also as working. Then I have swapped the programs to flip the Rx and Tx side and the result is exactly the same. That would mean Rx and Tx are working on both sides.

6

Hello

This is very weird.
It works suddenly but I can’t reproduce why it had not worked before.
I have played with two things around. 1st is the Library version “MCCI LoRaWAN LMIC library @ ^4.1.0” which was okay the last time it worked. And 2nd I played around with the upload method.
Since I work with VSC instead of the arduino IDE, I use in the platformio.ini this code

[...]
extra_scripts = upload_with_tycmd.py
upload_protocol = custom
build_flags =
     -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
     -D CFG_eu868=1
     -D CFG_sx1276_radio=1

and another upload method

extra_scripts = upload_with_tycmd.py
upload_protocol = custom
upload_flags = --board <tag>
build_flags =
     -D USB_MIDI
     -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
     -D CFG_eu868=1
     -D CFG_sx1276_radio=1

and the upload_with_tycmd.py:

from socket import NI_NUMERICHOST

Import("env")
env.Replace(
    UPLOADER="/Applications/TyCommander.app/Contents/MacOS/tycmd",
    UPLOADCMD="$UPLOADER upload $SOURCE -B 9304870-Teensy"
)

I don’t know what exactly lead to success. I have tried to reconstruct the error by change again the library version and the upload method, but now every constellation works perfectly.

Console (sensible data changed to xx):

Starting
Packet queued
28377: EV_JOINING
440332: EV_TXSTART
761396: EV_JOINED
netid: 19
devaddr: xxxxxxxx
AppSKey: xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
NwkSKey: xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
7

Short question. Can I mark somehow that this topic is solved?
Did nod see any option for this. Or should I just leave it, as it is?

8

TTN is 13 …

Yes, click the … icon and then you can click the tick box, if you think you have it as a solution, which you don’t, because …

… is not a solution, it’s sheer luck.

The topic will automagically close by itself, even if it doesn’t, you can leave it be.

9

Have many thanks @descartes

May I ask for a hint, where I can change the netid?
I just have found the table which lists the different id’s but not how to set them.
I have found on the end device general settings → join settings a “Home net ID” which I have changed to 00 00 13 but seems to be have no effect. Maybe I mix up something here. Need to check this when migraine have settled down.

10

Sounds like dodgy wiring or connections, which was changed, and which you need to fix.

You reported the problem was there with all sorts of different combinatations, so I would suggest the problem is not ‘solved’ just because, for now, it has gone away.

So what did you change from one setup not working and then working?

11

Hello

I have finally found the issue.
In the platformio.ini was a space at the beginning, in the “build_flags =”
It seems that the space character was enough for the build flag to be ignored.
Here I have the diff between the working and not working version.
Greenshot 2022-08-29 06.13.10

12

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.