I can’t understand what’s difference between using https://www.thethingsnetwork.org/airtime-calculator :
and using https://www.semtech.com/design-support/lora-calculator :
Adding 13 bytes to the payload lengths as i read in some Topics leads to Time on Air: 51.45 ms and not 56.6 as in TTN calculator. This is also 56.7ms in the end device live time.
Someone could explain ?
Thanks
Uplinks have CRC enabled, so it should be ON.
13 bytes is protocol overhead.
Ok it works fine now.
Where can i find the 13 bits protocol overhead specifications ? I can’t find this in LoRaWAN® Specification v1.1
Thanks
Bytes, not bits.
1 Like
Yes sorry for the mistake but i can’t find the 13 bytes overhead in any LoRaWAN specifications. Any idea ?
It’s so fundamental to the way that LoRaWAN works it is all over the first few sections of the specification so you’ll need to read ALL of sections 1 to 4 at the least.
Once you end up in section 4 you can find the juice: MHDR, FHDR and MIC. But don’t skip to the good part at once. (It’s more the horrendous part, the rest is lighter read.)
1 Like
I read sections 1 to 4 in what I consider a careful manner. However, I haven’t seen anything mentioning adding 13 bytes to the payload. Maybe I didn’t understand what I should be looking for… If I ask the question it is because I need help to understand this. Otherwise I would consider that these 13 bytes are there without knowing where they come from. Thanks a lot for your help.
Section 4 specifies the layout of a LoRaWAN message. Can you tell us the size (in bytes) of the following parts of the message?
- MHDR
- FHDR
- FPort (optional, usually present)
- MIC
To be fair to the OP I dont recall seeing the number (13) explicitly called out in the specs (1.0.3 or 1.1) - I really need to go back and re-read/check! Rather as Nick suggests it literally is
As in you need to look at the embedded structure of the message and infer the count from the individual sections called out! (Edit: as I now see called out by Steve), so not obvious. If someone doesnt want to get into the spec details but wants to know where/why you need to add 13 when doing the calculation its a matter of trust and advice and input from ‘those in the know’ who have probably been around the blocks a few times and just ‘know’ its (usually) 13 (though must confess 1st time I looked as this - like a decade back now (<=1.0.2) - I think some of the variable/option elements - region specific, fcnt, and especially MAC commands etc.) led me to conclude it was ‘approx’ 13 with scope for maybe 15, which threw me!) A point called out by the pop out info included in the oft prefered/referenced ‘avbentem’ calculator!
- MHDR → 1
- FHDR → 7
- FPort (optional, usually present) → 1
- MIC → 4
So 13 bytes to add to the Payload length in the semtech calculator whereas i don’t have to do this in the TTN one.
I knew I didn’t really know what I was looking for. I did not imagine that the semtech calculator tool did not integrate this part of the specification while that of ttn did.
Sorry for the mistake but i don’t like when i don’t understand someting!
Thanks all for the help
1 Like
TTN is all LoRaWAN, and nothing but LoRaWAN, where naturally Semtech are somewhat protocol agnostic with LoRa pure and simple, LoRaWAN, Sidewalk, Helium/LongFi and a million of private/proprietary implementations to support with a more generic, but naturally more felixible tool for its wider customer base to use…
See also
https://avbentem.github.io/airtime-calculator/ttn/eu868/8
Which is something of a go to for many Forumites 
Sometimes you make more progress if you can just accept something and let it go - otherwise you’ll be drilling down in to the detail so far that nothing will get done. No harm in coming back to it later when you’ve lived the environment for a while - at which point the MHDR and FHDR and MIC etc aren’t totally alien when you encounter them.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.