Multiple ... unable to transmit with your Seeed Xiao SAMD2+RFM95W sandwich board + example sketch

[netweaver1970]

Hi, I'm using your PCB to connect all modules up, the ultimate goal is to use your Dec 2022 sketch to send data to TTN. After soldering, it seems I have a problem with transmitting cq. joining. I get these as the latest messages in my debug serial console:

FREQ=0
EV_JOINING

But nothing happened, my TTN Lorawan gateway doesn't see any messages coming in.

For clarity, my TTN gateway is a DIY RAK831+RpiZero (Charles Hallard sandwich PCB), software solution upgraded to BasicStation, and is working fine. I have also another ttgo Lora client, using the universal Lora client sketch and that one can nicely send to and receive packets from TTN, all visible in the "The Things Stack CE" console. All of this to 'prove' my existing test setup is working well.

Still, I have the problem with your TTN sketch (and possibly -root cause - with C. Pham's modified version of the LMIC 1.5 lib.).

Triggered by the "FREQ=0" in your full sensor+TTN example, I decided to go step by step through your examples and already with example 3, the Lora transmitter test, I'm getting problems.

All the same entries as this one: 18:09:42.155 -> 10dBm Packet> Hello World 1234567890* SendError,Length,23,IRQreg,100,TX_TIMEOUT.

Now I'm lost, if I can't get the 'easy' example work, then no point trying to fix the full sensor TTN one. I did try to change the device type to SX1276, and the frequency in the setup call to 868MHz, but no help. I've verified all pin assignments, they all seem correct.

Is there anything more I can do to verify things? Or do you have a solution or idea on the FREQ=0 issue? I do have an oscilloscope etc, to see/check signals if need be. I have both diodes in D2 and D4, for usage in TTN.

Thanks.

[netweaver1970]

small update, when changing both the device type and frequency, I do get 1 correct packet sent, but the rest is still not ok. I changed all serial to serial1 in the sketch, so I could get ALL debug output

After doing a soft reset of the SAMD2 module, using the 2 pads, then I don't get the same behaviour as after a fresh flash:

When doing a full power down/up cycle, I do get 1 packet transmitted correctly again.

It seems a full power recycle cleared something up (in the Lora module registers) to make it work again. For 1 packet only. Some initialization needing to be done extra before every packet transmit maybe?

[StuartsProjects]

It seems a full power recycle cleared something up (in the Lora module registers) to make it work again. For 1 packet only. Some initialization needing to be done extra before every packet transmit maybe?

With valid, working hardware, the examples should work.

For the 3_LoRa_Test_Transmitter example did you add the appropriate wiring\components to connect up DIO0 on the LoRa module to the XIAO pin A1 ?

[netweaver1970]

good news (so far), after looking through the hal and radio LMIC source code, and back tracking step-by-step, I originally ended up suspecting maybe a bad connection on the reset (or nss) line somewhere. But those were nicely soldered and connected well. Then I was checking the SPI lines and the miso soldering at the SAMD21 side looked potentially not 100%. So I reflowed all joints... Retry ... yesss! straight connection and registration + data transfer into TTN:

This was great fun, I have been digging deeper in the SX1276 HW and LMIC code than ever before :) I have learned so much, I have a feeling I'm starting to understand actually how it all fits together :D Now I just need some real use cases instead of just academic interest and passion to get it working ...

Thanks for all the examples, really nice to follow along and learn!

[StuartsProjects]

The purpose of the example programs is to provide a known working bit of code that can be used to verify that a particular hardware setup is correct. The Library code used in the 3_LoRa_Test_Transmitter is some years old and has been tested many thousands of times, the possibility that the code is faulty and needed some 'extra initialisation' is remote, if it was faulty it would not have been published.

So if the example programs do not work this is strong evidence of a hardware error.