Which is not available in the current API, so if you want to deduplicate you’ll need to add one for the time being…
1 Like
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.
2 Likes
Thanks for the quick response.
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 : )
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.
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?
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).
1 Like
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?
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.
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.
Hopping I’m not off-topic 
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.
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 
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
2 Likes
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,
Hello BoRRoZ,
Thank you for the reply,
Still the 8 symbols i’m talking about aren’t those of the preamble. As you see:
Time on Air = T preamble + T payload
with
Tpreamble= (NbPreamble (8) + (symbols added by radio)4,25) x Tsymbol
and
Tpayload = NbPayloadSymbol x Tsymbol
And according to LoRa calculator, the NbPayloadSymbols is calculated with this formula:
I am looking for the meaning of those 8 symbols (red circle). In the formulas of the calculator the nPayload is independant from the 8+4.25 symb of the preamble.
1 Like
In the Loramac-node project, the low data rate optimization is set not just for SF12BW125 and SF11BW125, but also for SF12BW250. Not sure where this stuff is supposed to be documented… I can’t find anything in the LoRaWAN standard. Doesn’t look like any regions actually use this setting though.
Hey everyone i just want to ask how to calculate or get packet error rate for LoRa???
search (right top corner)
i did search the is no clear discussion about it.
A post was merged into an existing topic: 8 default symbols in LoRa payload, What do they represent?