Dual-Chan Gateway with Raspberry PI3 + Dragino Hat v1.4 and Downstream messages

Hi @Batigolle
After the installation of the gateway software (sudo make install of dual_chan_pkt_fwd) I have ensured that the global_conf.json file has the correct parameters:

globalconf

I am not using an arduino setup to transmit the sensor values (as I will instead be using an identical raspberry pi with lora hat as a client or node to sent data from to my gateway), so I should be able to downlink data to the gateway directly, correct?

What determines the possibility of downstream, is the gateway software, as a sensor you can have the type you want
The downstrem message will be sent in the queue after the next transmission of the sensor

@Batigolle
So it actually has to have a sensor sending data towards the gateway for the downlink to function? How does it then know to send this data via the node? Is there any way to verify that the gateway is working from the console?

From what I understood the downlink functions to send data from the TNN ‘‘down’’ to the gateway, as opposed to the uplink of data normally (eg from a sensor connected to a lora node). Would that be correct?

yes

From what I understood and that I verified with the tests, the sequence is …

Start transmission …

  1. The Node sends the message to the Gateway
  2. the Gateway sends the message to the TTN server
  3. The TTN server, decodes the message and manages it with the chosen application
  4. If there is a Downstream message, in the queue, to be processed, it sends it to the node
    through the gateway

… End of Transmission

maybe, someone more experienced, can correct my statements if they contain errors

@Batigolle
Thank you, your help is appreciated massively! :smiley:

I have been doing some more testing (mostly trial and error) and I believe that I now sort of understand (with your explanation) how it should work.

I am trying to get the sensor node working now, but as shown in the image, I am hitting a snag due to the incorrect labelling of the pins themselves.

lmic3

Do you also posses the Dragino GPS/Lora HAT and could you tell me your version / pinout? I have the HAT v1.4

I as a sensor use Arduino ProMini AT328 + RFM95W, the pin map changes from sensor to sensor

Continuing the discussion from Dual-Chan Gateway with Raspberry PI3 + Dragino Hat v1.4 and Downstream messages:

hi @Batigolle, i was following all your step and it went just fine. But not long after i tried to stop the following program using “systemctl stop dual_chan_pkt_fwd” , i tried to reinstall it using sudo make install and this happens

2018-05-22-172238_1366x768_scrot

i keep on trying to redo the whole process but the result is still the same. Do you know how to solve the problem above? thanks in advance btw. have a nice day :slight_smile:

Hi @farizkeke
with the systemctl stop command, stop the service do not uninstall it.
The make install command should only be used the first time to install the service
I’m not very experienced in ‘linux’, search the web for ‘systemctl stop’ and you’ll find an explanation of each parameter.
To restart the service try using “systemctl restart …”

1 Like

Hello,
I have used the dual_chan_pkt_fwd for RaspI+Dragino Lora Shield v95. As it is a single channel packet forwarder i have changed the json file as it is mentioned in this thread. The gateway got connected to the TTN but it is not sending the packets to the server. You can check the attached pictures. Can anyone kindly give a solution to this problem?Untitled1!

HI Batigolle,
First of thanks for this tutorial. I have been trying to get downlink from the same gateway for days now. It feels to me like the gateway forwards the data to the node but my node somehow never receives any downlink. So, I would like to know, how your node is configured.

Hi @bauvill
as a program for the node used for the test, I used ttn-abp.ino example taken from the libreia of Matthijs Koolijman arduino-lmic-master.zip

I have not made any changes in particular, in addition to the usual changes to insert the values Insert device registration keys, NwkSkey, AppSkey and DevAddr, I added the line
I added the following line of code,
inside the setup () function,
before do_send (& sendjob);

// Let LMIC offset for +/- 10% clock error
LMIC_setClockError (MAX_CLOCK_ERROR * 10/100);

Thanks. I am on it.

Well, it seems not to work on raspberry pi running on the LMICv1.6.
The gateway logs show that my device sends in the Freq = 868.3 on Chang=0, and it relies on the same channel and frequency my node never received any. Please help this is a thesis project and I have to turn it soon. I basically have everything working but for this and it is the last step to complete the project. It seems like everybody is using Arduino as node except for me.

Hi @bauvill
on Raspberry , have you installed “/bokse001/dual_chan_pkt_fwd” ?

My project uses this software for the gateway, it’s the most important part, to use the “downstream message”

Thanks once more.
My gateway runs the forwarder software from (“/bokse001/dual_chan_pkt_fwd”) but issues at this level was : packets received at the gateway layer on a frequency such as 866.1 or any other frequency different from 868.3 were all shown in the gateway logs as packets sent on the frequency 868.3, as a result, the server routes the downlink packets to that frequency. That should be where my problem lies.
I have carried out some modification on the gateway ( setting the _STRICT_1CH = 1 instead of _STRICT_1CH =0 which was the default value).
I am still about to test it on my node.
Thanks for your support.

Hi
these are the sensor and gateway logs when I did the tests

OUTPUT SERIAL ATOM HELTEC32 con ricezione DownStream message

10101683: engineUpdate, opmode=0x908
10101731: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0
Packet queued
10161952: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
10218564: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
10244705: EV_TXCOMPLETE (includes waiting for RX windows)
bytes of payload: 0x
10244710: engineUpdate, opmode=0x900
12119710: engineUpdate, opmode=0x908
12119758: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0
Packet queued
12179979: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
12189361: Received downlink, window=RX1, port=1, ack=0
12189371: EV_TXCOMPLETE (includes waiting for RX windows)
Received
3
bytes of payload
bytes of payload: 0x000102
12189632: engineUpdate, opmode=0x800
14064632: engineUpdate, opmode=0x808
14064680: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0
Packet queued
14124902: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
14181513: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
14207650: EV_TXCOMPLETE (includes waiting for RX windows)
bytes of payload: 0x
14207655: engineUpdate, opmode=0x900

OUTPUT GATEWAY01 con ricezione Downstream message

stat update: 2018-03-27 20:46:03 GMT 5 packets received, 0 packet sent…
CE0 Packet RSSI: -36, RSSI: -104, SNR: 9, Length: 23 Message:rxpk update: {“rxpk”:[{“tmst”:4212123479,“freq”:868.3,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-36,“lsnr”:9.0,“size”:23,“data”:“QFsRASaAAwABjDJ01tnrMyOjfhbubvA=”}]}
stat update: 2018-03-27 20:46:33 GMT 6 packets received, 0 packet sent…
CE0 Packet RSSI: -47, RSSI: -97, SNR: 9, Length: 23 Message:rxpk update: {“rxpk”:[{“tmst”:4244415677,“freq”:868.3,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-47,“lsnr”:9.0,“size”:23,“data”:“QFsRASaABAAB0bMQfYyQzR9XHc114hM=”}]}
stat update: 2018-03-27 20:47:03 GMT 7 packets received, 0 packet sent…
CE0 Packet RSSI: -45, RSSI: -100, SNR: 9, Length: 23 Message:rxpk update: {“rxpk”:[{“tmst”:4276705521,“freq”:868.3,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-45,“lsnr”:9.0,“size”:23,“data”:“QFsRASaABQABBcRMhLqXGcj8QZNlTIY=”}]}
stat update: 2018-03-27 20:47:33 GMT 8 packets received, 0 packet sent…
CE0 Packet RSSI: -43, RSSI: -97, SNR: 8, Length: 23 Message:rxpk update: {“rxpk”:[{“tmst”:14027286,“freq”:868.3,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-43,“lsnr”:8.0,“size”:23,“data”:“QFsRASaABgABT7eMr79xFNcu5Yl4iE0=”}]}
Sending packet:: tmst=15027286, wait= -1507156382, strict=0, datr=SF7BW125, freq=868300000->868300000, sf=7->7, modu=LORA, powe=14, codr=4/5, ipol=1, through CE1.
PKT_PULL_RESP:: From server router.eu.staging.thethings.network.
stat update: 2018-03-27 20:48:03 GMT 9 packets received, 1 packet sent…
CE0 Packet RSSI: -43, RSSI: -97, SNR: 9, Length: 23 Message:rxpk update: {“rxpk”:[{“tmst”:45146368,“freq”:868.3,“chan”:0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-43,“lsnr”:9.0,“size”:23,“data”:“QFsRASaABwABXd/KTwbnvgAmhUtl0wY=”}]}
stat update: 2018-03-27 20:48:33 GMT 10 packets received, 1 packet sent…

Thanks for the screenshots. my gateway outputs are the same but my node seems not to be getting anything. Is your node listening/sending on one frequency or all frequencies? Do you think I should the value my receive windows??
When a node sends on the frequency 868.1 does listen to the server reply on the same frequency? I asking because I have limited my node to send on a single channel. Is it wrong?

This function does not exist in my code LMIC_setClockError (MAX_CLOCK_ERROR * 10/100);

Are you sure you are reading the log correctly? You could interpret the marked line as no packets being sent to a downlink node (that is the way I interpret it). And that is probably because the back-end never instructed the gateway to send any data.

Yes and no. The first receive window (1 second after transmit) is at the same frequency. The second window (2 seconds after transmit) is at 869.525MHz with SF9. (So you should not set your gateway to pure 1 channel as this disallows switching to the right frequency for RX2)

Something else, if your node and your gateway are too close the gateway will receive data on a channel the node is not sending on. Make sure there is at least 3 meters space between the gateway and the node. And change the code on your node and gateway to use SF7 to SF9, SF12 is rarely needed and not good while testing with hardware in close vicinity.

I would be surprised if your code will receive anything at all without that line.

@bauvill
I sent you a message with the sketch I used in the sensor for the test,
maybe he can help you.
Sorry for the comments lines in Italian :sunglasses: