Spreadsheet for LoRa airtime calculation

[telkamp (Thomas Telkamp)]

Arjan,

Thanks for caring about these details!

@arjanvanb

LoRaWAN might have a fixed coding rate of 1? (So, CR=1.) I cannot find that in the specification. Even more: it does mention it explicitly for transmission of Class B beacons, so I doubt it’s also fixed for other operations?

It is not fixed.

As LoRaWAN includes its own header, the explicit LoRa header might not be needed? (So, H=1.) That would indeed need a fixed coding rate to start with (which otherwise would be set in the LoRa header). But it would also need some way to determine the payload length (which is in the LoRa header, but not in the LoRaWAN header). I think the LoRaWAN specification claims the LoRa header is always included though:
3.1 Uplink Messages[…]Uplink messages use the LoRa radio packet explicit mode in which the LoRa physical header (PHDR) plus a header CRC (PHDR_CRC) are included.

LoRaWAN does use the explicit header indeed.

The LoRa Modem Design Guide on which @matthijs based his nice sheet, states:
To avoid issues surrounding drift of the crystal reference oscillator due to either temperature change or motion, the low data rate optimization bit is used. Specifically for 125 kHz bandwidth and SF = 11 and 12, this adds a small overhead to increase robustness to reference frequency variations over the timescale of the LoRa packet.
Does anyone know if this is automatically enabled by the chipset or the LoRaWAN stack, for SF11 and SF12? In ttntool this is currently indeed the case:
dataRateOptimization := 0
if int(spreadingFactor) >= 11 {
dataRateOptimization = 1
}

The LoRaWAN stack handles this, for example an excerpt from the LMiC:

if ((sf == SF11 || sf == SF12) && getBw(LMIC.rps) == BW125) { mc1 |= SX1272_MC1_LOW_DATA_RATE_OPTIMIZE; }

[arjanvanb (Arjan)]

Okay, I’ve changed my copy of the sheet to auto-enable low data rate correction for SF11…12, and to also make clear that SF6 is not used in LoRaWAN. So basically LoRaWAN users only need to adjust the value for application payload to see the results.

(@matthijs, if you ever copy those changes in your sheet at the original URL then let me know, so I can delete these posts.)

[bvanderpol (Bas van der Pol)]

@matthijs @arjanvanb
First of all, thank you very much for the sheet! Very useful for indication!

I have a question about payload comment in the sheet.
‘For LoRaWAN: maximum 55 for low data rates (SF12), up to about 222 bytes for best conditions (SF7).’

In the LoRaWAN spec (7.1.6 EU863-870 Maximum payload size) DR0 - DR2 have a maximum payload of 51 bytes (absence of Fopt)
Would this be a maximum of 51 for SF12 (DR0) according to this table, or am I missing something? Could you please elaborate?

Thank you!

[arjanvanb (Arjan)]

@bvanderpol, that comment is something I added to the original sheet, and took from the FAQ.

The numbers were added to the FAQ after another discussion. But reading it again, that discussion is clear about the maximum, and indeed also mentions 55 but does not explicitly state that’s the minimum. So maybe the minimum in the FAQ is indeed wrong. (I also think the figures are slightly different for different regions? I’m not sure though.)

[hanshenrik]

Very nice sheet, incredibly helpful!

I am still not quite sure how to calculate the header and payload sizes though. I am using a Waspmote to send frames containing sensor data. The frame is converted into a hexadecimal array—which is the required format by the LoRaWAN.sendUnconfirmed(...) function—by using the following util function:

char sendableString[frame.length*2 + 1];
Utils.hex2str(frame.buffer, sendableString, frame.length);

Here’s some output from a transmission:

Frame Length: 105
Frame (STR): <=>€#012345678#0123456789#0#BAT:42#IN_TEMP:17.00#GP_TC:-26.774#GP_HUM:25.70#GP_CO:25.918#GP_CO2:304.826#
Sendable string: 3c3d3e3f062330313233343536373823303132333435363738392330234241543a343223494e5f54454d503a31372e30302347505f54433a2d32362e3737342347505f48554d3a32352e37302347505f434f3a32352e3931382347505f434f323a3330342e38323623
strlen(sendableString): 210
sizeof(sendableString): 211
ADR: 1
DataRate: 5 (= SF7BW125)
Radio frequency: 869525000
Radio spreading factor: sf12
Radio bandwidth: 125
Radio coding rate: 4/5
Radio preamble length: 8

The corresponding TheThingsNetwork data field is:

PD0+gAYjNDAzMzE1ODQwI1dNMDIwMzIyMjIjMCNCQVQ6NDIjSU5fVEVNUDoxNy4wMCNHUF9UQzotMjYuNzc0I0dQX0hVTToyNS43MCNHUF9DTzoyNS45MTgjR1BfQ08yOjMwNC44MjYj

htdvisser’s ttntool calculated the air time to be 174.3ms, which working backwards in the spreadsheet suggests a payload of 87-90 bytes (if the header is 13 bytes).

So my question is simply: how do I know my payload and header sizes without working backwards based on air time calculated?

[arjanvanb (Arjan)]

@hanshenrik

htdvisser’s ttntool calculated the air time to be 174.3ms

Note that there are some minor bugs there as mentioned above, for which I promised a pull request which I still did not create… Not sure how much that affects the result though.

@hanshenrik

how do I know my payload and header sizes

As far as I know, the headers are always 13 bytes (as explained above), and the payload is just a number of bytes too, so 105 in your example. So in matthijs’ original sheet that’s 118 in total; in my version it’s 105 and 13.

By the way: Don’t. Send. Text. Don’t. Send. Text. It will eat your maximum air time with no good reason. Also, it seems #BAT:42# is a counter value? Then note that the headers already have a counter. [see responses below]

[kersing (Jac Kersing)]

@arjanvanb

Then note that the headers already have a counter.

Which is not available in the current API, so if you want to deduplicate you’ll need to add one for the time being…

[telkamp (Thomas Telkamp)]

@kersing

Which is not available in the current API, so if you want to deduplicate you’ll need to add one for the time being…

It is available in the data_raw field, but I agree it takes more effort to fish it out

Thew new backend will make it easily available, as well as the port.

[hanshenrik]

Thanks for the quick response.

@"arjanvanb

By the way: Don’t. Send. Text. It will eat your maximum air time with no good reason.

I guess one alternative would be to just send the values as csv (and not label them), and have a fixed, known position for each value. However, this somewhat restricts the flexibility of the system, e.g. allowing different devices to measure different things, and still be able to parse the values on the other side. When you say don’t use text, is this what you mean? (I read the post, but didn’t really see where you talk about text vs. something else)

[quote="arjanvanb, post:20, topic:1190]
Also, it seems #BAT:42# is a counter value?[/quote]
BAT:42 indicates the battery level of the device : )

[arjanvanb (Arjan)]

@hanshenrik

I guess one alternative would be to just send the values as csv (and not label them), and have a fixed, known position for each value.

No, that would still imply you’re sending numbers as characters, and are adding separators that are not useful.

But, stupid, I gave you the wrong link… See Best practices to limit application payloads: numbers can be sent much more efficient than that. As for devices measuring different things: just keep track of the node’s ids, or use the LoRaWAN “port” like explained in the new link as well.

[thaskippy]

So basically LoRaWAN users only need to adjust the value for application payload to see the results.

I’m confused now. Do I or do I not put 13 as the LoRaWAN header size? Since the sheet starts out with a header size of 1, but this thread mentions multiple times the LoRaWAN header size is 13 bytes.

Currently I’m entering the below configurations to determine the amount of packets I can send on TTN with the max payload of 51 bytes on the lowest datarate of SF12. Is that correct or should LoRaWAN header size be 1?

[arjanvanb (Arjan)]

The 13 bytes is correct. (So for a 51 bytes payload the LoRa packet would be 51 + 13 = 64 bytes.) I don’t know what happened, my copy of the sheet indeed showed just 1 when I opened it a minute ago. Thanks for letting me know; I changed it to 13 again (and added some conditional formatting in case it’s not 13).

[Sakshama_Ghoslya]

Hello @matthijs & @Thomas
According to your spreadsheet:
Total bytes = 13 payload + 13 LoRaWAN header = 26 bytes
Total bits = 268 = 208 bits
After encoding = 2085/4 = 260 bits
As SF = 9, so,
Output Payload symbols should be => 260/9 = 28.89 ~ 29 LoRa symbols

But according to your spreadsheet it is 28.
Is my calculation correct?

[arjanvanb (Arjan)]

@Sakshama_Ghoslya

Total bytes = 13 payload + 13 LoRaWAN header = 26 bytes

As an aside: Matthijs’ original version expects the total number of bytes to be in the input. So, for 13 bytes of data you should enter 26, for which the spreadsheet will give you 38 symbols. That’s much higher than your manual calculation.

The formulas in the Semtech document are much more complex than your own calculations.

[nsornin]

Dear all.
As a contribution to this discussion let me share another spreadsheet that has been validated against exact measured Time on air. Can be found at http://www.scoop.it/t/the-french-wireless-connection/p/4056972126/2015/12/17/loramac-life-calculator. I cannot upload it here but the one at the link matches the “official” Semtech’s one. The spreadsheet also allows to estimate (very crude model) the total battery capacity used by the network connection over the life of a device.

[Sylvain_M]

Hopping I’m not off-topic

@arjanvanb

LoRaWAN might have a fixed coding rate of 1? (So, CR=1.) I cannot find that in the specification. Even more: it does mention it explicitly for transmission of Class B beacons, so I doubt it’s also fixed for other operations?

Beware that disabling the Forward Error Correction code comes with a significant penalty when it comes to sensitivity/range. The trade-of, a small increase in data-rate vs a significant loss in sensitivity, is not worth it, except in very special cases like class B beacon when it was done on purpose for specific reasons.

Always use a 4/5 (in “nice” environments) or 4/6 (in environments with bursted interferes) redundancy for data transmission.

[CHAPINONG (Kasper S)]

Hi,
i don’t understand why you, in the “payloadSymbNb” equation write “… 20*(1-Header) …”.

in the Semtech LoRa design guide (page 7), the equation for Payload symbol number is:

but in you’r spreadsheet’s you write it like:

That doesn’t make any sense to me, when i use the first formula, with no header (H = 1) i get payloadSymbNb=23, and with header (H = 0) i get 28… thats also what i would expect.

Why do you do as you do, have i missed something ?!?

Thanks

[robg66]

Took a little time but I get why.
If you look add page 7 it says:
H = 0 when the header is enabled and H = 1 when no header is present.

In spreadsheet in column B9:
“=if(C9=“yes”,1,0)”
Yes == 1.
This is the opposite of what Semtech Describes.
1-H simply inverts 1 to 0 (just as Semtech wants).

if you would change the value of B9 to
“=if(C9=“yes”,0,1)”
Then you can use the same formula as Semtech.

I hope you can follow it

[assia_b]

hello matthijs

Thank you for the spreadsheet, it does explain better the LoRa symbol / bit conversion.

I would like to ask you about the 8 mandatory symbols in the payloadnb symbol. I searched everywhere to explain their utility, since it’s not representing the preamble length. A payload has at least 8 symbols, what are those representing?

Thank you,

[BoRRoZ]

LoRa: Symbol Generation