LoRa network server tx queue : can it be flushed?

Home › Forums › General › LoRa network server tx queue : can it be flushed?

Tagged: 

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • January 7, 2016 at 10:53 am #10914
    Brian Wyld
    Participant

    Hi,

    Having some issues with the LoRa operation, which seem to mean my application generated response packet is not being transmitted in either RX1 or RX2 slots…
    Result: the response is placed in the queue for that device and then tx’d the next time it sends up a packet.

    However, my application is such that if I don’t get the response immediately, its no use queuing it! and the queued message then stops the response to the next packet being sent!

    Can I set a flag or something in the json when requesting a packet send to specify the flush of the output queue?

    thanks

    Brian

    January 8, 2016 at 7:56 am #10951
    Brian Wyld
    Participant

    I see in the lora-network-server config field called “nodeQueueSize” which is set to 16. Is this the queue for the downlink messages waiting for the node?
    If I set it to 1 will that mean that only the most recent downlink message will be kept?
    Can I set a flag in the downlink json (like for the port, ack etc) to flush or control this queue?

    thanks

    Brian

    January 8, 2016 at 8:06 am #10954
    Jason Reiss
    Keymaster

    Yes that will work for now. I plan on added a way to flush the queue as well.

    January 8, 2016 at 8:20 am #10958
    Brian Wyld
    Participant

    Ok, thanks Jason. I’ll give that a go.
    For the future, having a “queueFlush”:true attribute in the downlink data message to force flush of the existing queue would do the job for me…

    thanks

    Brian

    January 8, 2016 at 10:54 am #10986
    Brian Wyld
    Participant

    Hi Jason,

    This seems to be ok. However, I note (using tcpdump on the ports 1780-1786) that on occasion the lora-network-server gets a downlink packet from my application ‘in-time’ to send it to the pkt-forwarder for transmission in RX1/RX2, but that it doesn’t send it on to the pkt-forwarder (no UDP packet on port 1782)… and that it can take another couple of uplink packets before it decides to send it to the radio…

    What could be the reason for this? Is the gateway also held to limited channel usage, or is there something else? Any logs that I can look at to see why the downlink packet doesn’t get sent?

    thanks

    Brian

    January 8, 2016 at 12:14 pm #10996
    Jason Reiss
    Keymaster

    Yes, the network server must follow the ETSI duty-cycle limitations per transmitter. We will be working on the ability to add second AC-LORA card.

    January 11, 2016 at 9:06 am #11012
    Brian Wyld
    Participant

    Hi,

    In fact I’m not sure that its really the duty cycle being exceeded. I understand that a gateway is allowed up to 10% utilisation on the RX2, but often the data doesn’t get send until the 3rd uplink packet!

    How can we debug this?

    thanks

    Brian
    PS. our lora-network-server is version 0.0.7, I’ll try updating it also.
    PPS. I’d really like it if the ‘timestamp’ attribute as send up by the network-server was just copied from the ‘time’ attribute in the pkt-forwrder json : this give a ms precision value and closer to the actual radio reception time! Any chance of this?

    September 15, 2016 at 3:57 pm #14789
    Paul Chilton
    Participant

    Hi,

    Was this ever solved, I’m having what I think to be the same issues using mdot and AEP conduit. (http://www.multitech.net/developer/forums/topic/mdot-and-aep-reply-lag-or-offset/#post-14788)

    Thanks,

    Paul

    • This reply was modified 7 years, 7 months ago by Paul Chilton.
    September 15, 2016 at 3:59 pm #14792
    Jason Reiss
    Keymaster

    http://www.multitech.net/developer/software/lora/lora-network-server/mqtt-messages/

  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.