hey guys，
i am studying LoRa recently.
In sx127x Datasheet, it says the lora phy frame is consist of preamble, header, payload, and payload crc.
especially, the header is within a code rate of 4/8.
But in the calculation of Time on Air,
it says, nPayload = 8 + max(ceil((8PL-4SF+28+16CRC-20IH)/4(SF-2DE))*(CR+4),0)
how to understand the calculation of the payload?
is the 20IH means the length of the header?
but header is within a code rate of 4/8, isn’t it?
why we calculate the header and payload together within the same code rate?
I would be grateful if someone could help me.
1 Like
What is the reason for asking about the formulae ?
I have been using LoRa since circa 2014 and whilst the total time on air of a packet is of interest, there are published calculators for that, so I never had any need to use or understand the formulae in the datasheet.
Maybe could be a question for the Semtech forums ?
Because I want to calculate the transmission time of the header separately.
But I found the equation is too strange to understand.
Additionally, I find another interesting thing.
In sx1302_hal(GitHub - Lora-net/sx1302_hal: SX1302/SX1303 Hardware Abstraction Layer and Tools (packet forwarder...))
sx1302 gives two timestamps, and the precision timestamp gives a timestamp at the end of the header. (in loragw_sx1302_timestamp.h)
/**
@brief Configure the SX1302 to output legacy timestamp or precision timestamp
@note Legacy timestamp gives a timestamp latched at the end of the packet
@note Precision timestamp gives a timestamp latched at the end of the header
@note and additionally supplies metrics every N symbols troughout the payload.
@param enable_precision_ts A boolean to enable precision timestamp output.
@param max_ts_metrics The number of timestamp metrics to be returned when precision timestamp is enabled
@param nb_symbols The sampling rate of timestamp metrics
@return LGW_REG_SUCCESS if success, LGW_REG_ERROR otherwise
*/
int timestamp_counter_mode(bool ftime_enable);
but in the function “precise_timestamp_calculate”(in loragw_sx1302_timestamp.c), there is a code to shift the timestamp at the end of header to the end of preamble.
/* Coarse timestamp correction to match with GW v2 (end of header -> end of preamble) */
offset_preamble_hdr = 256 * (1 << sf) * (8 + 4 + (((sf == 5) || (sf == 6)) ? 2 : 0)) +
256 * ((1 << sf) / 4 - 1); /* 32e6 / 125e3 = 256 */
/* Take the packet frequency error in account in the offset */
offset_preamble_hdr += ((double)offset_preamble_hdr * pkt_freq_error + 0.5);
timestamp_cnt_end_of_preamble = timestamp_cnt - offset_preamble_hdr + 2138; /* 2138 is the number of 32MHz clock cycle offset b/w GW_V2 and SX1303 decimation/filtering group delay */
/* Shift the packet coarse timestamp which is used to get ref PPS counter */
timestamp_cnt = timestamp_cnt_end_of_preamble;
so, does the ‘offset_preamble_hdr’ means the transmission time of the header? and how to understand the equation? I think there must be some relation.
Suggest as Stuart said… get info “from the horses mouth” vs via limited TTN user base?
For what particular reason ?
why do you want to know the reason? I am a student and this is about my research. I would be appreciate if you can help me.
It sounded like an X Y problem so the answer might not have been to do with the actual times.
The on-air time of the header is of little practical purpose as far as TTN is concerned and I doubt anyone on this forum would have studied in detail the formulaes in the datasheet, better things to do etc.
1 Like
As @LoRaTracker says, it is of academic value to the vast majority but also consider that it’s your research project which isn’t research if we pony up the answers - we don’t do homework on here.
Confusing technical details only become clear when you look at them from different angles.
So to potentially help you move forward, I’d suggest you stop looking at the fine timestamps on the gateway - if you know LoRaWAN you’ll know that’s for geolocation & whilst it may speak somewhat to your ‘time of header’ calculations, you should concentrate your efforts on finding other air time calculators, one that is linked to so many many times on this forum and there are numerous ones on GitHub, including the one for TTS v3.
The number of header symbols is always 8 (hence the 8 at the beginning of the formula), but since the header itself has a fixed length, it means that depending on the the spreading factor some payload bytes end up in the “header symbols”, that’s why you see some bits being subtracted from the payload length in the formula (4*SF and in case of implicit header 20 more).
1 Like