Down packet failed to transmit

Home › Forums › Conduit: AEP Model › Down packet failed to transmit

Tagged: , , ,

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • June 25, 2018 at 12:00 pm #23993
    jessica perez
    Participant

    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

    June 25, 2018 at 12:10 pm #23994
    Jason Reiss
    Keymaster

    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

    June 26, 2018 at 5:34 pm #24008
    jessica perez
    Participant

    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

    June 27, 2018 at 6:52 am #24013
    Jason Reiss
    Keymaster

    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.

    June 27, 2018 at 11:53 am #24014
    jessica perez
    Participant

    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

    June 27, 2018 at 12:10 pm #24015
    Jason Reiss
    Keymaster

    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.

    June 27, 2018 at 12:44 pm #24016
    jessica perez
    Participant

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

    June 27, 2018 at 1:02 pm #24017
    Jason Reiss
    Keymaster

    # 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.

    June 29, 2018 at 11:50 am #25561
    jessica perez
    Participant

    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?

    June 29, 2018 at 12:12 pm #25564
    Jason Reiss
    Keymaster

    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
Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.