LoRaWAN uplinkPayload size.

[mdede439]

I am wondering what is limiting the uplinkPayload size in the example sketches I find in this library. I was able to increase it to a maximum of 9 before I get an error (-4) when it tries the uplink. Are there other variables I need to modify from the default to allow more than 9 bytes of data per uplink. IU am using the LoRaWAN_Starter sketch and it works so well except I would like to send a few more bytes of data.

[HeadBoffin]

The limit, per LW specification, is 254 bytes subject to legal airtime restrictions. Much more than 50 bytes starts getting problematic in general. The notes.md has a link to a calculator that will show you what can be done.

Without knowing anything about your device or the regional settings it's hard to comment in detail.

[mdede439]

Thanks for your response @HeadBoffin. It looks like I don't know enough to ask the correct questions. I am using examples/LoRaWAN_ESP32 as a start for building my LoRaWAN sensor node. It is using a Version 2.0 TTGO LORA32 device that I have connected to a BME280. I modified the code to get my sensor data uploaded to TTN, but I may want another sensor or two connected so more data space would be required.

I was able to simulate my issue with just the example code. I modified config.h with my newly registered device keys and the appropriate radio;
const LoRaWANBand_t Region = US915;
const uint8_t subBand = 2; // For US915, change this to 2, otherwise leave on 0
SX1276 radio = new Module(18, 26, 23, 33);

When I increase the value in the line uint8_t uplinkPayload[10]; above 9, the uplink always fails. Is a solution around this to change some of the other parameters of the LoRa transmission?

I do know there are other Data Rate values and Spreading Factor that can affect speed of transmission, but there are none of these variables listed in the example code so I am using what ever defaults the library has coded. When I look up the transmission on my gateway I see it is using:
"bandwidth": 125000,
"spreading_factor": 10,
"coding_rate": "4/5"

Any thought and ideas would be helpful.

Mike.

[HeadBoffin]

The notes.md has a link to a calculator that will show you what can be done.

^^ This.

The LoRaWAN_Reference.ino in this main repro shows how to set the DataRate (aka SF) - but you can't just adjust it down as it reduces range. But the calculator will show you what's possible. And at SF10 you should be able to send 11 bytes BUT there are some complications with the way that LoRa is encoded that don't make it quite so simple - TL;DR: the encoding moves in steps.

How often are you trying to send, which LW Server are you using, how close is the device to the gateway? If the device is able to stand a lower SF then the LNS will adjust it after a few smaller uplinks.

Otherwise you'll have to break up your payload in to small chunks. Or get a gateway closer or move your gateway higher or a better antenna. Many options for longer range but it's not an out the box experience.

[StevenCellist]

The keyword here is "dwelltime limitations": in the US, a LoRa transmission is limited to 400ms of time-on-air per packet. Which, using the calculator, shows that you're very limited in payload size on higher spreading factors. (Hence: reduce SF if possible.)

[mdede439]

I did see the additional commands in the LoRaWAN_Reference.ino and tried them, but it did not change. I tried them again after reading your message and discovered I needed to wait for a second and further uplinks before things changed. However even if the gateway shows my uplink was SF8BW125 or SF7BW125, I still could not increase the number of bytes above 9. If that is the limit, that's fine, however from the limited amount I currently know about LW, I feel it should be more than that and I don't know where this limitation is coming from.

My project is a simple one for now, but I may want to make it more complicated in the future so that is why I am pushing the limits to see where they are and what limits I need to put on my project. I want to make a solar powered air quality sensor. Once completed it will live meters from my gateway, so range won't be a problem , but I would eventually like to deploy something like this much further away. I live in Toronto, Canada and I have a feeling there are not too many gateways set up around me so, I am relying my own gateway. My plan is to capture as much data is reasonable and is currently configured for an uplink every 5 mins.

I did see the dwelltime limitation on the calculator webpage and the setting in the reference sketch, does setting this value prevent a transmission to be sent if the code calculates the requested uplink will take longer than the dwelltime specified or does it just cut off the message after that specified time? For example, if I want to send 30 bytes of data and specify a dwelltime of 400 ms, does the radiolib library include code to calculate how long that will take and prevent the uplink if it is beyond the 400 ms? Or does the code just stop the uplink mid-transmission after that 400 ms has elapsed?

[HeadBoffin]

Rather a lot of points arising, not least the plan to work around the limitations - you should be able to send packets as per the calculator subject to using LW as invented - sending data at 5 minute intervals is fine - "testing" by hammering away is doomed to failure. Hotwiring RL by changing the parameters may yield results like a potential visit from the radio authorities - long, frequent, far reaching transmissions on the shared ISM band is likely to disrupt other users.

Masked by this activity is the possibility that the US915 band has become unglued so we need to check for any issues because out the box a device with ADR that is within a few tens of metres of a gateway should quickly drop to SF7 which would allow far greater payload sizes.

The code can't control the radio by cutting the tx off after a certain time and it would result in a partial packet that would fail the CRC check and, in general, be dropped by the gateway.

You should plan for being able to use the more usual SF's. You can split up payload types using the fPort (that's what it's for) so you can send different payload types. And you can send min, max & ave readings for a time period or even accumulate a reading a minute in to one payload.

For testing there's no reason to bother the radio spectrum - once it's setup you can use serial debug for everything else to develop the rest of your software.

[mdede439]

I appreciate the assistance in this. The fPort is something I never thought of and the Radiolib examples makes it easy to use. Thanks for that, it will make it easy to add new sensors to my device and keep everything easily separated.

The general way I learn how to do or use something is to experiment with it first to find out what I don't know. Then start reading about it and if I still don't know enough I start asking questions. The only reason why I was playing with the SF was to see what effect it had on how many bytes I could send. When I go to the airtime calculator it specifies the overhead is "at least" 12 bytes and then my payload still should be larger than the 9 bytes I was only able to get to work. I would have expected there to be a more rigid standard for these, and there may well be but all related to other factors I don't know enough about. At the end of the day with what I want to do with this device I don't need to know the protocol in that depth to get my device to work. I would prefer to let it figure out the best way to get my message to the gateway on its own and adjust the transmission speed and spreading factor all by itself.

Thanks again for all your help.

Mike

[StevenCellist]

I think there's some sort of knowledge gap here. LoRaWAN has a mechanism (as mentioned by @HeadBoffin) - ADR - which automagically optimizes the SF and Tx power based on the signal strength and quality. So that wish of yours is completely implemented and enabled by default. However, it takes a few uplinks before the LoRaWAN Netwerk Server requests the device to move over to a lower SF == higher DR.
By default, RadioLib starts off at DR0 for US915 as that is mandatory for the JoinRequest. As such, the following uplinks (also at DR0) are very limited in payload size until the LNS moves the device to a better datarate - only then you can send a larger payload.
So if your sketch has a fixed payload length, you either need fragmentation through e.g. FPort as suggested, or you must wait for ADR to kick in, or disable ADR and set a faster datarate yourself (potentially risking that the device is not heard). The best solution very much relies on your setup. RadioLib has some utility functions that make it possible for you to retrieve the maximum uplink length available, or set ADR, or set a specific datarate. Most of those are showcased in the Reference example. But anything that you can leave on default is best.

[mdede439]

Very true @StevenCellist , I have much to learn. Based on this conversation I am going to try and keep my payload as small as possible to make sure all of it gets transmitted all the time and if I need a larger payload, transmit it via another port.

Thank you everyone for your quick responses and knowledge and thank all of you who are contributing to this community to make LoRaWAN easier for the learning hobbyist.

Mike