LoraWAN downlink problem with large packets
-
@jcaron Mmmm was a bit quick on that... It could be up to 250 bytes "if the end-device will never operate with a repeater". No idea if/how the LoRaWAN stack handles that. Try with 230 bytes to see if it goes through.
-
How do you control downlink DR used by the Gateway?
-
@bmarkus I have disabled adr in the server and freezed the data rate at the gateway.
-
@paul-thornton I am doing this for testing only in actual application it will done occasionally(also downlink payload will be far less) but as per LoRaWAN specs it should work upto 242 bytes without FOpt fields.
-
@jcaron I tried with downlink packet size 186 bytes,losses are too much(once out of around 10 transmissions it is received at node).I also tried with packet size 200 bytes here once out of around 50 transmission it is received at node.
-
@pp The longer the frame the more chances it will be corrupted by noise on the band or collisions if you have several devices around. The packet loss rate seems a bit too high, though (but I admit I never tried such long packets, they're not really the typical LoRa use case).
Do you have other devices using LoRa around? Or other users of the 868 MHz band? How far are the two devices? What kind of antennas do you use? Does it work OK for smaller packets?
-
@jcaron Uplink with same packet size is going fine so i don't think it is problem of noise or collision.Other details are-Only one device is there,no other users nearby,distance between gateway and device is around 3 meters,antenna is,which comes along with pycom accessories. Downlink with smaller packet size it is working fine.
-
@pp Did you have WiFi enabled during your tests? If yes, try to disable WiFi for the Receive timeframe.
-
@robert-hh I have disabled it,it is not making any difference.
-
@pp I wonder if there couldn't be some sort of bug in the RX code that doesn't wait long enough for the full packet to be received. In theory it should cancel the RX window timers as soon as it has detected the preamble (and possibly set another timer based on the max duration of the frame at that point, but it may wait for the full packet to do so instead.
A very quick glance at https://github.com/pycom/pycom-micropython-sigfox/blob/master/drivers/sx127x/sx1276/sx1276.c searching for
RxTimeoutTimerseems to indicate that the RX timer is indeed cancelled only once the full packet has been received, but I may be wrong on that one, I really haven't looked much further.@robert-hh I know you spent a bit of time looking at the timing of RX windows etc. at some point, did you get into that part as well?
-
@jcaron Yes, I did. But I did not look into that specific behavior.
-
I was having similar issues with Multitech gateways in combination with TheThingsNetwork's recommended packet forwarder (from kersing). Updating to the latest packet forwarder from Multitech the legacy UDP format solved the issue.
Bytes past 66 seemed to be garbage and therefore the MIC/crc would fail
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login