TTIG does not connect to TTN using Lora module sx1276 (and M5Atom Matrix/Micropython)

Recently I read about a very nice [blog entry]
( by LeMaRiva to program a [M5Atom Matrix] ( as a Lora node to the TTN using Micropython and a LoRa module SX1276. Building the system as described I want to use it with my TTIG 868 gateway.

Unfortunately I do not get it working. Nothing is seen on the TTN console, neither in the gateway traffic nor in the device data traffic. The problem seems te be the gateway TTIG. So, I’m looking for suggestions.

Some analyses done thusfar:

  • The device (Atom Matrix/ESP32 PICO)) is registered on TTN for ABP mode. The three required keys for ABP are implemented into the micropython code.

  • A Lora module SX1276 with Lora chip sx1276 (868 MHz for EU), is SPI-connected with the M5Atom Matrix and is working correctly. I do get the SX version from the lora chip. The hardware connections are as described in the blog entry.

  • Micropython (v1.12) and the sx127x driver of LeMaRiva is used, and he has the connection to TTN working. Only difference with me is, that I’m using TTIG. I’m talking to the author and he is so kind to look into the problem too. Because I’m using another gateway, TTIG 868, I’ll ask this forum also for help or suggestions.

  • The TTIG connects correctly with TTN using my another microcontroller, a Lopy4 in OTAA activation mode. The sx127x software driver only operates in ABP activation mode.

  • My TTIG has no debug possibilities. I’ve read how it can be enabled by opening the case and add some wires (Tx-connection) or a SMD-resistor (R86, for USB debugging), but I’m hesitating to do this. My TTIG is the only gateway in the neighbourhood to connect to TTN.

  • I’ve tried today to use Arduino TinyLora (Adafruit) and MCCI LoRaWan LMIC Library, but ran into too many (software)problems.

Some questions:

  1. Does the TTIG handles ABP activation method, like it does the OTAA? I assume it does, but I want to be sure.

  2. How can I check the TTIG receives or process the sx1276-data without one of the Debug interfaces?

  3. How can I check the connection between TTIG and TTN, even when nothing is received on TTN? (neither gateway traffic nor device data traffic)

  4. Does anyone has, or knowns about, a working TTN connection in micropython with the Lora chip sx1276?

  5. Any other suggestions?

Any suggestion or help is appreciated.
Thanks, Peter
van der Post

Some answers:

  1. Yes, TTIG is a fully LoRaWAN compliant gateway. If forwards all LoRaWAN traffic to the backend which handles both ABP and OTAA nodes. A gateway just forwards data and does not ‘handle’ nodes. The same can’t be said about the LG02 used in the tutorials…
  2. If a valid (no crc errors) LoRaWAN packet is received it will be forwarded to TTN and be visible in the gateway traffic in the TTN console. (Keep the traffic tab open for debugging as it does not show historical data)
  3. You can’t without a working node, there are multiple steps that might fail. However if your gateway works for one node it will work for another node as well.

5. Do the frequencies of your new node (hardware and software) match the frequencies used by your gateway? Is there at least 5m distance between the node and the gateway?

Is the code written for the sx1276? A quick look doesn’t show any provisions to differentiate between sx1272 and sx1276 where other libraries do differentiate. Sx127x does not make it clear which chip is supported.

@JacKersing: Thanks for your answers and suggestions. That gives confidence and narrows the problem, I’ll hope.

Related to answer 5: I’ve have to dig into it. Because the article shows it’s working, I assumed the sx127x driver is (also) targeting the sx1276 chip/Loramodule. I bought exact the same Lora module. I’ll ask the author.

What do you mean with: “Is there at least 5m distance between the node and the gateway?” The Atom/sx1276 lora module are within 5 meters of the TTIG, but also the other mentioned LoPy4. Both Lopy4 and Atom are placed next to each other on my table (about 30 cm, both are in development). The Lopy4 is working as expected (gateway and device traffic in TTN console). My guess was to do that on purpose “the closer to the gateway the better transmission”. Does that matter? And, do both nodes interfere each other?

While looking around the web, I also saw another micropython lora/SX1276-driver. I gonna look at that one too, although there was a remark “Transmission does not yet work,”(?). Whatever that means. Unfortunately I do understand too little of the details in the driver (and datasheet). Pfff.
I’ll keep doing trial-and-error and digging. Peter

The first check I always make when testing a new borad\Lora combo, is to see if its actually transmitting.

No need for an expensive spectrum analyser to check that, a cheap (about £8) Realtek SDR and the SDRSharp software (free) does the job very nicely.

And too close makes a transmission that overloads the receiver circuits resulting in garbled data. That is why you need to keep a minimum distance (and 5 meters is recommended) between a node and a gateway. One node working close up is no guarantee another works as well as it depends on transmitter settings, RF circuitry of the node and antenna.

Have you checked the last commits on that repo? The note that transmit isn’t working is part of it. So I wouldn’t bother as there haven’t been any updates after that commit in 2017.

Have you ever actually seen garbled data?

What I’ve seen are additional signal reports on adjacent channels with weak RSSI as well as a strong one on the correct channel. Very naive network software can be confused by this but it’s fairly simply solved by de-duping on the raw packet and SF, but not the frequency, then picking the frequency of the strongest signal when contemplating a downlink. And that becomes an issue at the downlink stage, not that of even getting uplinks.

Perhaps not even getting any valid packets can indeed result from being very close, but it’s not something I’ve seen in the course of a lot of less-than-a-meter testing.

I’ve seen plenty of frames with crc errors with nodes too close to a gateway. That’s garbled data for me. So yes, I have.

1 Like

Interesting, I can’t recall that having happened much, will have to make a point to explicitly look for it - and yes, I know hardware CRC error packets aren’t normally submitted over the backhaul, but would be in the packet forwarder logs and stats counts.

(And I assume you mean packets on the correct frequency - bleedover to adjacent channels being garbled wouldn’t be surprising at all)

Yes, just a single packet received by the gateway at that time and at the same frequency reported by gateways some distance away.
I noticed those while working on the MP forwarder so it might have been because I was focusing on packet forwarder logging (comparing it to other gateway logging) that I noticed that.

Yes, I just saw that too. Besides that, the whole stuff does not compile according to the known issues. I don’t even try it. Thanks for mention it. Peter