LoRa network server tx queue : can it be flushed?
- This topic has 8 replies, 3 voices, and was last updated 8 years, 6 months ago by
Jason Reiss.
-
AuthorPosts
-
January 7, 2016 at 10:53 am #10914
Brian Wyld
ParticipantHi,
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 #10951Brian Wyld
ParticipantI 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 #10954Jason Reiss
KeymasterYes that will work for now. I plan on added a way to flush the queue as well.
January 8, 2016 at 8:20 am #10958Brian Wyld
ParticipantOk, 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 #10986Brian Wyld
ParticipantHi 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 #10996Jason Reiss
KeymasterYes, 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 #11012Brian Wyld
ParticipantHi,
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 #14789Paul Chilton
ParticipantHi,
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 8 years, 6 months ago by
Paul Chilton.
September 15, 2016 at 3:59 pm #14792Jason Reiss
Keymaster -
This reply was modified 8 years, 6 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.