Spreadsheet for LoRa airtime calculation

14

I had a short discussion with @htdvisser about some constants in the air time calculations used in ttntool. He suggested @Thomas might know more, so here goes:

  1. 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?

  2. 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.

  3. 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
 }