Downlinks working ?

[Di-Ny]

Hi,
Your package is a lifesaver as very few thing work on OrangePi out of the box. But it seems that there is no downlinks receives. I don't know if it receives Ack either. Can you confirm ?
Kind regrdas, Nicolas

[zhgzhg]

Hello, @nicolasdauy ,
At the current moment downlink packets are not supported. ACKs are received and used, but right now only for uplink packets.

There are plans to implement the downlink functionality, but I don't know when that's going to happen. (Currently I am trying to enhance some details of the receiving process at the hardware level and maybe after that I'll be able to start working on the downlinks.)

[Di-Ny]

Ok, well I am looking forward to try this functionality when it will be out :) Thanks for your work. I don't know how far this is related to your project, but I found https://github.com/bokse001/dual_chan_pkt_fwd/tree/dual_chan_pkt_fwd_up_down which implements downlink, but it is not working for the Orange Pi. Kind regards, Nico -

[Di-Ny]

Hi, I see that you updated the description 👍 Is it ok for testing ?
Does the downlink support means it will be able to connect with OTAA too ?
I am planning on a testing with a class-C device and chirpstack application on an OPi PC.

[zhgzhg]

Hi @Di-Ny , I am still validating the changes (hence didn't update this ticket), but you are welcome to give them a try :)

[Di-Ny]

So I could give a try on the latest commit. On the server side it seems to work, it receives the data, and the dowlinks with a success! At that point it seems promising :)
Just to report that for now I haven't been able to receive on the device yet. I am still investigating on the parameters for it happens. I tried 2 configurations with an heltec AB02S:

• ABP, channel mask on the single 868.1MHz, ADR Off, Ack requested. It receives some of the messages but no Ack. At that point I am not sure if the issue is related to the device or the timing issues.
• OTAA, channel mask on the single 868.1MHz. It is stuck on the joining process, the server's JoinAccept is not received by the device, but I think that it is sent by the GW.

If I understand the single channel gateway I should focus only on RX1 right ? There is no RX2 on the 869.525MHz.

[zhgzhg]

Timing issues could be the most likely reason for not receiving downlinks. Currently I am investigating how much of them may be caused by the forwarder.
Regarding RX2 / RX1 - during transmission the application is using the RF parameters supplied by the server (incl. frequency, SF, BW), so it should be able to emit on different frequencies too. When the transmission ends, the forwarder switches back to receiving with the parameters from the config.json.

[Di-Ny]

Ok now it works, sometimes :)
I am testing with an Heltec Capsule different configurations:

• OTAA : confirmed message. The Join process works, but I do no more receive the messages afterwards. Like something is no more working after the downlink part.

• ABP : unconfirmed messages works. But confirmed messages throw an error:

(Wed Dec 15 10:47:04 2021) Received UPlink packet:  
 RSSI:                  -58.0 dBm
 SNR:                   6.500000 dB
 Frequency error:       -2491.416504 Hz
 Data:                  23 bytes

(Wed Dec 15 10:47:06 2021) Received DOWNlink packet:
...
(Wed Dec 15 10:47:06 2021) Invalid time scheduled: 1639561626 (31993583 internal ts micros); local ts 1639561626, internal ts(micros) 31362213!

I think my Chirpstack server is responsible for scheduling the downlink.

Maybe this is a CPU priority issue. Is there any way to increase yet the priority? For now it consumes only 10-14% of CPU load, I could go up to 20-25% no problem.
Also do you think moving from a Sx1276 to a SX1262 will improve this?

[zhgzhg]

The "sometimes" is totally expected, because it's just a single transceiver, and hence I doubt switching to SX1262 will make any difference. What's interesting though is the OTAA's "no more receive the messages afterwards", which should not happen. If the node is transmitting immediately after joining there's some change for the uplink to be missed by the gateway, but the next transmissions should have been captured. I'll have to investigate...

Regarding the "Invalid time scheduled messages" - so far I've seen 2 major reasons for them - either the Chirpstack / TTN server is scheduling with delay (so far I've seen it only on TTNv3 for EU_433), or the packet forwarder didn't process them in time.
The former case can be tweaked a bit on the server side by adjusting the transmission delays. This may help fixing the confirmed messages. Also turning off any downlink message buffering/accumulation options on the server side is a good idea, because this project is capable of buffering the data on its own.

For the latter reason, which is common, the mitigation options are limited. The packet forwarder's execution priority is already real-time, just a smidgen below the maximum allowed in order to not interfere with the OS' tasks. (In root mode tools like htop or the nice command can change the priority of the process as well - the more negative the number, the higher the priority).

Increasing the CPU utilisation by patching the code may help a little, but that's not guaranteed,

Another possible tweak with a very minuscule effect, would be increasing the spi_speed_hz in the config.json. I wouldn't go much higher than 32 MHz, because the communication with the LoRa chip becomes very iffy. A 16 MHz is a good trade-off.