As you can see, all values corresponds with the TheThingsNetwork Console, but ttn-otaa hang on EV_JOINING.
Also the spi-scan reports correctly the Dragino GPS/Lora HAT
Anyone with some suggestions to try? Could this mean there isn’t any Lora-gateway reporting to the TTN? According to the TTN-Map there should be multiple TTN-Gateways in range on our university campus.
Using a Raspberry Pi 3 Model B with the latest Raspbian.
It depends on how this gateways you see on the map are configured. As someone mentioned above, e.g. single channel gateways wouldn’t might not work with OTAA.
Maybe just for testing you could try ABP as activation, just to ensure, that not your node is the problem.
I also ordered a Arduino module from Dragino. Lets try if this will give better results. Otherwise I’ll setup the Rpi + Dragino HAT as Single Channel gateway.
Keep you posted.
BTW, does somebody found a nice library/framework for the Dragino Rpi HAT?
I implemented Hardware Abstraction Layer (HAL) code for LMIC 1.6 targeted to Raspberry Pi for Dragino GPS/Lora HAT.
Having that done, I now can use LMIC 1.6 and this HAL to write node applications on the RPi.
Joining the TTN using OTAA works using a fully-functional Kerlink IoT Gateway(LMIC examples/join)
Sending periodic sensor values to TTN works (LMIC examples/periodic)
I plan to provide the code for the HAL on github soon.
Ok it turns out that the nearest gateway (400 meters away) has a really poor RSSI and SNR values…
I just ordered bigger antenna’s (5dBi), because I’m unsure if the low link budget is due to my setup (Dragino Rpi HAT and Dragino Arduino Shiel with the same antenna) or it’s due to the poor gateway setup at my university.
As suggested @matthijshere increasing clock error for receive windows solved all my OTAA join with LMIC (on Arduino Zero) but may apply on RPI, worth trying this fix (here 1% error more) you can con even on 2% or 3%
For users of a Dragino LoRa/GPS HAT (for Raspberry Pi) I have implemented a Hardware Abstraction Layer for the IBM LMIC 1.6 communication stack. This is similar to the solution of Ernst de Vreede, but as a difference it is based on IBM LMIC 1.6, which seems to be the most recent version of this communication stack. I tried not to touch the LMIC stack itself but only provide a HAL for RPi + LoRa HAT. I also tried not to put too much CPU load on the RPi when waiting for incoming messages.
You my friend are a legend for making it clear that it will only work with a proper gateway. I struggled for days to get nodes working with single channel gateways
Thank you very much for your Dragino LoRa/GPS HAT Hardware Abstraction Layer for the IBM LMIC library.
I’m trying to use it on my rPi 3 and Dragino HAT but I encounter some problems
I thing I have all prerequisites to run your Hello example but unfortunately it doesn’t work
# ./build/hello.out
000000000 HAL: Initializing ...
000000001 HAL: Set radio RST pin to 0x00
000000001 HAL: Wait until 000000002 ms
000000002 HAL: Set radio RST pin to 0x02
000000002 HAL: Wait until 000000007 ms
000000008 HAL: Failed. Aborting.
I’m suspecting a pin problems …
I hope, you (or someone else here ) can help me to get it work.
Hi Wklenk,
thanks for your awesome solution . I tested the code you provided and the uplink tx seems to work perfectly( I could test only the uplink since my gateway is a single channel based on the modified version of the dual_chan_pkt_fwd). However, my single channel gateway offers a function to send downstream data.
I would like to test is with your implementation of the LMIC v1.6 using the ABP activation method. The point is that I want to send downlink data to my node ( running your software) at a random time and see if the node receives the data. I wanted to modify the periodic example so that it uses the APB method to send data to my local server over my gateway. Can you please guide me on this?
Whether you use OTAA or ABP for activation does have nothing to do with sending download data. It is just the method how to “join” the network. The examples I provide use OTAA. First task would be to get them working using ABP.
You cannot send “data to your node at a random time”. With LoRa Class A devices, you can only receive data after you have sent data. But let’s say you get the “periodic” example running with ABP, e.g. sending some dummy data every 5 minutes, and you manage to send something back in the TTN backend, then it should be possible to receive data.
But I have made bad experiences with these “single channel” gateways. Are you really sure that it supports downlink messages?
Thanks for your prompt reply and also thanks for the clarifications.
The issue is that I tried your LMIC v1.6 code on my Lora Node (RPI+Dragino) and my gateway based on the same components as my node runs the dual channel packet forwarder from (https://github.com/bokse001/dual_chan_pkt_fwd).
During the test, I realized that server replies to uplinks message but my node never receives them.
Since it is a thesis project, I wanted to make sure that it is not possible to send downlink messages using the RPI+DRAGINO HAT as the gateway. I would like to have your advice on this. That is why I have the following questions:
Q1- Is it possible to have uplink and downlink message on a single channel gateway sending in both directions on the same frequency ( e.g 868.1) and also configuring the client to send then listen on the same frequency?
Note: It is obviously far from being LoRaWAN compliant
I have not been able to get this to work with the Raspberry Pi 3 B+ (esp. for the US). I have it running, but it doesn’t show up in the TTN console (never seen). I did the following:
Change config.h to have: #define CFG_us915 1
Change line 764 of lmic.c to LMIC.channelMapp[channel/16] &= ~(1<<(channel&0F));
Added in all session keys, eui’s and dev address.
Also doesn’t show up in gateway traffic, though it is running.