-
-
Notifications
You must be signed in to change notification settings - Fork 545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Managing the downlink RX windows #14
Comments
Well, about the first part of your comment I should say, you got it right until the part that, gateway has no way of knowing if the end-node received the data on Window 1. and the Ack could be received about the data sent on Window 1 way way later. like minutes away. The last paragraph sounds really interesting to me. Have you looked at the Semtech Packet forwarder to acquire these info? I use a Multitech Conduit which uses a different one called Basic Packet Forwarder but I assume the Conduit also has a SX1301 and a couple of SX1257s(to enable rx and tx at the same time) so it'll be in the same boat. So I am wondering if this situation could be true in our case as well. Gotta look into it a bit more. |
Regarding your first point, you're right! I overlooked this and somewhere in the process made the assumption that the two receive windows were for redundancy. Thanks for pointing this out! For reference, these snippets from the specs are mentioning this: 3.3.5 Network sending a message to an end-device 6.2.5 Join-accept message Regarding your second point, I have to validate this, but you might be right. Initially, I've only tested with the RN2483 which doesn't give any "debug" info. On an IM880A-L node, I only see incoming packets for the second rx window (in WiMOD LoRaWAN EndNode Studio). Which confirms what you're saying: I was expecting that the
Putting this logic into the Semtech Bridge domain feels wrong to me, since this queue is really in the |
I agree that implementing this on Semtech Bridge will not be easy. Some antennas might be connected through very latent networks. Sometimes it will be impossible to know this in advance (maybe right now the antenna is connected through the slow backup connection), but miscalculating the latency might lead to packet loss. I would expect the packet forwarder to have a queue of a reasonable size. After all the maximum number of packets that can be send for a given period of time is limited by the duty cycle, thus a good value for the queue size can be derived. |
First point has been fixed in 2604fc6.
It is now hard-coded to RX1. I think the best would be to switch between RX1 / RX2 based on duty-cycle management in the end. |
@gzwsc2007 just heard (on TTN Slack) that the queuing will be handled better in the next version of |
@brocaar Thanks for the update! Regarding the @Mehradzie As far as I know, at this stage custom gateway binaries are preferred over the semtech |
@gzwsc2007 yes, I do realise that now. A nice project would be to build a packet forwarder which directly forwards over MQTT, so that the LoRa Semtech Bridge isn't needed anymore 😉 Side-note: I just tagged |
emmm... can't believe how much stuff came our of this simple conversation. good thinking @gzwsc2007. i am glad we had this chat. I mean I am looking for the smallest excuse to get even more involved in this even if you think it remotely worth it :D |
@Mehradzie I am still quite skeptical about how well Semtech can improve their existing |
Hi, to know the new packet_forwarder, see commits in the experimental branch: Lora-net/packet_forwarder@0a4413a About Lora-Semtech-Bridge, it is intended to run into the gateway or in a server? My bet is for the gateway, to translete locally between UDP and MQTTT, encryption, autentication, remote management of the gateway... |
Hi, |
@nestorayuso it shouldn't matter how you run it, you can:
Semtech Bridge will subscribe to the topic(s) for each gateway it maintains a connection for, so each of the above case should work. |
Given that the next |
Hi Orne, I have moved to the latest release and I can see that Window 2 is fully removed now :( which was commented out in the couple of previous releases and I was manually enabling it back before making the project. I honestly think there is a misunderstanding here. If you've based your decision on the following two sections this might be just simply misreading the standard. (Although out understanding from it is still based on an interpretation)
This is the conclusion we came down to when this has been brought up couple of weeks ago among the team.
I'd say the writer is stressing on the precise moment of transmission rather than pointing out that only one windows is to be used.
The writer is trying to point out to the reader that the correct delay is the JOIN_ACCEPT_DELAY not the RECEIVE_DELAY. Please let me know what do you think about this :) Cheers, Mehrad |
I still think that only one receive window must be used. Some of the ism bands have duty-cycle constraints. Through the Letting the gateway transmit on both receive window would limit the capacity of the gateways. |
Yes, it is up to the network-server to use RX1 or RX2 per node, per group, per client or per application (but the network-server can't use use both RX1 and RX2 for a single node for the same uplink). But why there are two receive windows? to adapt better to use case, circumstances, duty-cycle limitations or regulations. Generally it is better to use RX1, it is more spectrum and energy efficient, if uplink uses ADR, the downlink will use ADR implicitly. Instead RX2 is stuck to slowest data rate. In EU868, RX2 benefits for the higher duty-cycle (10% in 869.525MHz, compared to 1% or 0.1%). Other benefit depending on regulation, is the possibility to use a gateway in full-duplex mode if uplink frequencies are far away from RX2 frequency (not the case in EU but possible in US). And remember Class-B and Class-C use and must use RX2. |
Totally agreed, but I am thinking rather than removing the Window 2 code completely, could we implement a compile time parameter or something to choose between the two? 😇 I honestly didn't mind having it there commented out so I could go enable it when I want to try the Window 2 functionality on the newly designed end-node. 😄 |
It was removed since the code was outdated after the |
The new packet forwarder has been released (with just-in-time scheduling)! https://github.com/Lora-net/packet_forwarder/releases/tag/v3.0.0 I think before we can use the new packet forwarder, I need to make some changes to the Semtech Bridge because of the protocol changes. I'll look into that this Friday. |
Thanks
|
Haha... didn't think the reply through my Pebble watch will end up here ⌚ 😆 |
I've implemented the new Semtech UDP protocol v2, meaning you can update your
|
That's fantastic news. Thanks heaps
|
I'm going to close this issue. For the management of rx1 / rx2, I've just opened a new issue to track the progress of this feature #69. |
Currently, the server sends scheduled downlink to both the RX1 and RX2 windows. However, it seems the correct way to do this is to only send on one particular RX window. The decision of which window to use is made by the server (if the end node does not get anything during RX1, it will wake up and listen again at RX2. However, if it gets a response at RX1, it would not wake up at RX2, so there is no need to downlink at both windows).
Before coming up with a rather complex scheme of deciding which RX window to use, I think it is OK to just hard-code the server to always use RX1.
A bit of digression: With the dumb Semtech packet forwarder, if the server tries to schedule downlink on both RX windows (which is what it's doing now), in effect only the RX2 packet will get through... The SX1301 (the concentrator chip on the gateway) only has a TX buffer of size 1. However, the packet forwarder will shove a TX packet into the 1301 even if the packet is scheduled to be sent 5 seconds later.... So if in the mean time a new downlink arrives before the previous one is sent out, the old one will just get overwritten... IMO, the packet forwarder should temporarily put the downlink packets into a queue sorted by departure time, and only shove the packet into the SX1301 if its departure time is imminent.
The text was updated successfully, but these errors were encountered: