LoraWAN downlink problem with large packets

[PP]

Hi,
My lora node receives the downlink packet with payload size 66 bytes but when i m sending the downlink packet with payload size 240 bytes it is not being received at lora node. To test this,in application code after every uplink packet I am publishing a downlink packet.
LoRaWAN data rate is DR5(region-EU868)

Other observations-

1. In both the cases I am able to see the downlink frames in "LIVE LORAWAN FRAMES" section corresponding to lora device(I assume it means it has been transmitted from server side)
2. In "LIVE DEVICE DATA" section i am getting following "error" packet after every uplink packet(in both cases)-
   applicationID:"1"
   applicationName:"App"
   devEUI:"aaaaaaaaaaaaaaaa"
   deviceName:"App"
   error:"invalid data type: 4"
   type:"CODEC"

Setup details-
I am using Lopy4 as my LoRaWAN node as well as nano gateway.
Lopy4 firmware(lora node)-"release='1.20.0.rc4'"
lopy4 firmware nanogateway-"release='1.18.0'"

lora server details(lora-app-server,loraserver and lora-gateway-bridge are installed on same machine)-
lora-app-server version -2.4.1
loraserver version-2.4.1
lora-gateway-bridge version-=2.6.2

Can anybody please tell me,what is the the problem?

[jcaron]

@pp Per the LoRaWAN spec, the maximum payload size is 230 bytes at DR5 (and much smaller at slower data rates).

Note also that a 230-byte packet at DR5 will take 379 ms to transmit. On most sub-bands in the EU868 region, that means you're not allowed to send more than 95 packets per hour on that sub-band (that's amount 1.5 packets per minute).

[Paul Thornton]

@pp said in LoraWAN downlink problem with large packets:

size 240 bytes

That's far to large. You'll run out of radio time trying to transmit that in one go.

[jcaron]

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

[bmarkus]

How do you control downlink DR used by the Gateway?

[PP]

@bmarkus I have disabled adr in the server and freezed the data rate at the gateway.

[PP]

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

[PP]

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

[jcaron]

@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?

[PP]

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

[robert-hh]

@pp Did you have WiFi enabled during your tests? If yes, try to disable WiFi for the Receive timeframe.

[PP]

@robert-hh I have disabled it,it is not making any difference.

[jcaron]

@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 RxTimeoutTimer seems 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?

[robert-hh]

@jcaron Yes, I did. But I did not look into that specific behavior.

[virtualguy]

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