Down packet failed to transmit

[jessica perez]

Hello, so currently I have set up a multitech conduit to be serve as the lora gateway and packet forwarder. On the other side, I have a raspberry pi 3 setup as the lora server and lora-app-server. Our company has our own server that we did for our water management system. We have an mdot along with a ti board in which they both communicate and send commands up to our system for turning on valves. So far it is able to join and send uplinks up to the server, and unconfirmed downlinks.

The issue right now is that it seems like it is failing to transmit. So for example, if i do at+sendb=07ffffffff, it will send a payload of flow to report which looks like this on the server side
06-25 04:57:31 PM
{“EUI-64″:”008000000000b265″,”FLW”:{“0”:4294967295}}

but when it comes down, on my lora-packet-fwd logs i get this warning

Note: LoRa packet
lgw_receive:1423: FIFO content: 1 73 2 5 12
lgw_receive:1438: [0 17]
Note: LoRa packet
INFO: [up] PUSH_ACK received in 22 ms
INFO: [down] PULL_RESP received 🙂
INFO: [down] a packet will be sent on timestamp value 1291066820
lgw_send:1687: DEBUG: Tx pow_index 11, rf_power 20
e7.93.33.4c.f4.17.e8.b.0.9a.12.12.0.8.0.0.60.9a.a.52.1.a0.4.0.1.a6.72.b1.8d.6c.d1.25.b0.46.end
WARNING: [down] packet was scheduled but failed to TX
lgw_receive:1423: FIFO content: 1 95 2 5 12
lgw_receive:1438: [1 17]
Note: LoRa packet
INFO: [up] PUSH_ACK received in 11 ms
lgw_receive:1423: FIFO content: 1 b7 2 5 12
lgw_receive:1438: [3 17]
Note: LoRa packet
INFO: [up] PUSH_ACK received in 18 ms
INFO: [down] PULL_ACK received in 2 ms
lgw_receive:1423: FIFO content: 1 d9 2 5 12
lgw_receive:1438: [5 17]
Note: LoRa packet
INFO: [up] PUSH_ACK received in 3 ms
lgw_receive:1423: FIFO content: 1 fb 2 5 12

I am not sure why it is failing to transmit, how can i go about to fix this issue. Any help will be appreciated

[Jason Reiss]

Do you have a USB 1.0 card?

# mts-io-sysfs show lora/*

With the basic_pkt_fwd-usb packet forwarder for the 1.0 cards.
When a packet is sent the forwarder for transmit it will expect it to be transmitted within 200 ms of being queued. The message you have posted will be displayed but does not always mean the packet is not transmitted. But if another downlink is scheduled it can bump the current packet from the TX buffer.

http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora/lora-packet-forwarder-usb/lora-packet-forwarder-add-queue.patch?h=3

Adjusting how early packets are sent to the forwarder from the network server can have an affect on behavior.

Otherwise there is an updated packet forwarder and MTAC-LORA-1.5 SPI card the queuing mechanism has changed to use the JIT queue provided by the original packet forwarder implementation.
https://github.com/Lora-net/packet_forwarder

[jessica perez]

I apologize for late response, so I ended up upgrading the packet-forwarder to latest version Lora Packet Forwarder USB 1.4.1-r11. I tried looking for info on this latest patch but no luck. Does this have the latest patch for the queue or do i need to manually configure it with the link you gave me?
Second, how will that patch work if my conduit is not linux based bc this link you mentioned http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/lora/lora-packet-forwarder-usb/lora-packet-forwarder-add-queue.patch?h=3 is for the linux based only? Or can it work with aep?

And as far as the other https://github.com/Lora-net/packet_forwarder you mentioned it is for MTAC-LORA-1.5 SPI? mine is not spi and is a MTAC-LORA-1.0

[Jason Reiss]

The patch is already included in the USB packet forwarder for AEP and mLinux.

If you are able to join and receive ACK’s from the network server the the downlinks are working. What is the issue you are seeing besides this warning message?

I suggest updating to an MTAC-LORA-1.5 card. The SPI version uses much less CPU on the Conduit and the accompanying packet forwarder code has a better JIT queue with feedback to the network server.

[jessica perez]

Besides the warning message, it might just be within our own water management system, but when I try to turn a valve on, it will turn on, but only for a minute then it will go off. Then 3-4 minutes later, it will go on again, and then it will shut down. So I figured based on the logs from the packet forwarder, it is most likely dropping packets and in the code if it loses contact with the server then the valves will shut off. It cannot be range issue because our system has worked before with the conduit set up as the network server and using node red.

From the lora server, i am getting uplinks and downlinks so at this point I am not sure what else could be a potential issue besides probably upgrading the lora card

[Jason Reiss]

How much lead time is given for the UDP packet to reach the packet forwarder?
Adjusting how early packets are sent to the forwarder from the network server can have an affect on behavior.

I can’t recall if the failed to tx error is printed when the packet is too late to transmit.

[jessica perez]

Not sure if im looking at the right one, but from the lora server, the downlink data delay is set to 100ms

[Jason Reiss]

# Get downlink data delay.
#
# This is the time that LoRa Server waits between forwarding data to the
# application-server and reading data from the queue. A higher value
# means that the application-server has more time to schedule a downlink
# queue item which can be processed within the same uplink / downlink
# transaction.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
get_downlink_data_delay=”100ms”

You could try 500ms or 750ms, this should make the packet be sent to the packet forwarder later. Not certain that it will make difference.

[jessica perez]

Yea it did not help, been testing it for a while. So I think we have decided to upgrade to a 1.5 SPI card instead. One more question(thank you btw for all your help much appreciated), if I were to upgrade to this card, it comes with the packet forwarder that implements the JIT queue system or I would have to install it manually?

[Jason Reiss]

There are separate packet forwarders already installed for the USB vs SPI model.

The system will detect and run the correct version, all that will need to be done is install the new card.

[Author]

Posts