The maximum MACPayload size length (M) is given by the following table for both uplink dwell time configurations: No Limit and 400ms. It is derived from the maximum allowed transmission time at the PHY layer, taking into account a possible repeater encapsulation.
What is the “maximum allowed transmission time at the PHY layer” and how is it determined? Is this called out in documentation?
Given that in Australia there is no duty cycle limit, why is there a “maximum allowed transmission time”?
I recall a certain discussion about how we tend to accept the fate of historic development, rather than finding out how some things came to be.
If you had a look through all the different regions, you’d notice that either dutycycle or dwelltime limitations (maximum allowed transmission time) are in place for all regions. It’s one or the other.
If you wish to breach the agreed settings for your region, we are not the people to give you the thumbs up - particularly as:
We don’t live in AU
We aren’t lawyers
Most developers see random naughty transmissions all the time - sometimes to the detriment of our own legal setups - feel free to use RDF to figure out where the device is and report them to the feds.
There is absolutely no intention to break any regional settings, I just want to be able to know what the airtime limit is (if it isn’t 400 ms) and understand the reason for the payload limit chosen. I appreciate that some might accept the limits as they are, but I would like to understand the logic behind it.
The example in my previous comment of over a second for SF12 is to demonstrate that the limit appears to be much higher than 400 ms.
Sir, someone drove 200mph on the motorway. Apparently the speed limit was not 60mph! Can I pretty please get my car and license back now?
Re the other questions: I (we) don’t know, nor do I (we) have an intention to know, because we’d prefer to stick to the rules that will most definitely be safe to use. Because if you’re living on the edge of the law with a deployment of 100,000+ devices, you can get into big troubles real quick.
From what I understand, there two independent limits and the most restrictive determines the max.
First, there is the PHY layer:
It is derived from the maximum allowed transmission time at the PHY layer
Second, there is dwell time.
So look at EU863-870: there is no dwell time, but at SF12 / 125 kHz, without repeater, M is 59 octets. That is pure a PHY layer (LoRa) limitation. No dwell time. No duty cycle. And yes, these transmissions are well over a second.
Thank you for taking the time to respond to this post as well. It’s always great to hear directly from those at the heart of the operation.
Is it fair to say that the PHY limitations imposed by the standard are primarily there to prevent devices from congesting the airwaves, even if such transmissions would be legally permitted? In other words, does the LoRa Alliance consider the payload limitations a reasonable balance between payload size and airtime usage?
PHY layer is Physical layer. So LoRa modulation is limited to maximum payload sizes at higher spreading factors. This is unrelated to regions or LoRa Alliance standards.
I acknowledge that by increasing the spreading factor (SF) (reducing the data rate (DR)), the payload size must reduce to maintain a relatively consistent maximum airtime.
It is worth noting though that for the AU915 frequency plan, DR0 (SF12) to DR2 (SF10) have the same maximum payload size. For every increase in spreading factor, the airtime doubles, because the number of chips double. This means that the maximum payload at SF10 will always have a quarter of the airtime of the maximum payload at SF12.
Who defines the limits of the physical layer? Is it Semtech (the sole manufacturer of LoRa modules)?
Is the decision a technical one (the LoRa modulation simply physically cannot support a greater payload size for a given spreading factor) or a fair use one (to prevent devices clogging the airwaves whilst following them rules)? If it is the former (technical limitation), why can’t LoRa devices transmit any more?
As the limitation is defined in the physical layer, so the LoRa transceiver, it is Semtech indeed.
Again, it is a limitation in the physical layer. LoRa is a proprietary technology, so I can’t comment on the exact reasons. The (public) LoRa design guide mentions:
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.
Guessing here: maybe there’s a maximum of “low data rate optimization bits” for this to work functionally or reliably that would impose a hard limit on the number of total bits at SF12 and SF11.
Once the physical layer is there, it won’t be limited by higher level layers indeed.
I wasn’t there when these specs were defined. Besides limits of the physical layer, it could also or instead be that the same maximum payload limit for DR0, DR1 and DR2 was chosen to avoid long time-on-air to reduce congestion and chance of interference (“fair use”), supported by the argument that end-device developers would have to support the lowest possible value anyway at DR0 so they might as well use the same MACPayload for DR1 and DR2. Since the data rate is typically not in the control of the end-device developer (because of ADR), having a few steps of maximum payload sizes rather than having a different value for each data rate makes sense to keep things simpler for the end-device developer, with the added benefit of less congestion and chance of interference.
But again, it can very well be simply a limit by the physical layer. I haven’t tried, forgetting about LoRaWAN, transmitting 100 bytes at SF12 or SF11. Maybe it doesn’t work, maybe it does but not reliably enough.