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:
Does the TTIG handles ABP activation method, like it does the OTAA? I assume it does, but I want to be sure.
How can I check the TTIG receives or process the sx1276-data without one of the Debug interfaces?
How can I check the connection between TTIG and TTN, even when nothing is received on TTN? (neither gateway traffic nor device data traffic)
Does anyone has, or knowns about, a working TTN connection in micropython with the Lora chip sx1276?
Any other suggestions?
Any suggestion or help is appreciated.
Thanks, Peter
van der Post
(Netherlands)
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ā¦
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)
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.
For
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
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.
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.
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