We are considering prototyping a new limited-range GPS tracking design (in the U.S.) with the Blues LoRaWAN starter kit, and so have begun researching several aspects of The Things Network. One area that is still a bit unclear is how the duty cycle, dwell time, and network/carrier rules will impact our available bandwidth and govern how often we can send our location and sensor data to Blues, and if there are any other TTN- or Blues-specific data caps or limits to contend with when using the Blues LoRa Notecards.
I have read that in the U.S there is no duty-cycle regulation, but there is a dwell time limit of 400ms. Does Blues have any practical explanation or examples to help us understand how all of this translates to usable bandwidth? I found this cool airtime calculator app, and this one as well, but they don’t seem useful unless you know the Data Rate / Spreading Factor you are using. Is the data rate fixed or variable with Blues LoRa Notecard?
Another question is how the Blues tenant is situated within The Things Stack ecosystem, as it seems there may be different limitations based on: TTS Enterprise vs Cloud vs Open Source vs Community/Sandbox.
It’s also worth noting that we operate under The Things Stack Cloud (under a commercial instance), not the Things Stack Sandbox (a free/community license). The TTN Fair Use Policy only applies to the Sandbox accounts and does not apply to our products.
I hope that helps, let me know if you need more detail on any of this!
Thanks @abucknall, those details are helpful. So to confirm our understanding so far, being in the U.S. we don’t have to worry about duty cycle, and being on the Blues tenant we wouldn’t have to worry about TTN Fair Use restrictions. So then the only restriction to be concerned with is the 400ms maximum dwell time? Is that correct?
Regarding ADR:
If the software is setting the SF and TX power automatically, how would one go about calculating dwell time and maximum payload size for an application?
In the ADR post you linked to, it explains that ADR is not recommended for mobile devices since RF conditions can be unstable. Since our application is mobile GPS-based tracking (with varying degrees of distance and obstruction), would the recommendation be to disable ADR? (and is that even possible with the Blues Lora Notecard?)
Apologies for keeping you waiting. Yes, your only concern should be the maximum dwell time.
I’m currently checking with the team what they recommend regarding calculating dwell time and max payload size as well as potentially changing ADR mode.
I’ll update again when I can provide more information.
The Notecard LoRa will manage the transmission of the data depending on if its duty cycle is restricted or not. This is tracked internally (as the Notecard knows the SF & TX settings). If the duty cycle has been exceeded, you would see a trace log (you can use the web terminal to see the trace logs), as the example below:
lora: next TX in N secs
The limitations are determined by the frequency plan I mentioned above (US_902_928_FSB_2). Dwell time is managed similarly, between the Notecard and the LoRaWAN protocol, and you would expect a longer transmission if you are restricted. The radio will manage hopping frequencies to remain compliant. Beyond experiencing longer transmission windows, you should not have to worry about managing this in your application.
Additionally, ADR mode is enabled by default, and it is not possible to change on the Notecard LoRa. We do this to avoid complexity in the firmware and across the API (given that we want the API to remain consistent across Notecard variants). From the sounds of your concerns regarding dwell time, this may not be the best solution for your application if you are expecting to transmit a lot of messages. Could Cellular perhaps be a better option?
Let me know if there’s anything else I can help with.
Thanks Alex, appreciate the extra detail. We are still in the the conceptual planning stages so we don’t yet have any requirements set in stone regarding the size or frequency of messages. For now we are simply trying to establish the upper limits of what we can achieve with Blues LoRaWAN, as we’d really like to give it a shot (cellular would not be a good fit for this project). We were hoping to be able to calculate this on our own, but the unknown element of ADR complicates that, so maybe you can help guide us.
As an example, let’s say we are looking at sending GPS coordinates, accelerometer readings, and two temperature readings, such as…
A JSON data size calculator puts this payload between 120-130 bytes (assuming whitespace is ignored). According to the airtime calculators I linked to above, that size payload is only possible given certain SF and bitrate values. But based on your last post, it sounds like the Notecard is going to calculate that and negotiate the appropriate settings for us, and we don’t have to worry about that?
Assuming that’s correct, then the only important question that remains is how often could we send that message from a Notecard that might be in motion a good percentage of the time? Is every ~30 seconds possible? If not, what frequency is more plausible, and how would you determine that? If duty cycle is not a limitation in the U.S., what is the governing factor for how frequently we could transmit that payload?
You are correct; Notecard and onboard LoRa radio will calculate the valid parameters (SF, bitrate, etc.) to be compliant with the protocol (LoRaWAN) and regional requirements.
Theoretically, you could transmit as frequently as every ~30 seconds, but that would be high usage for a mobile LoRaWAN (I assume, a battery-powered) device, so your major constraint would be likely power consumption.
You should also consider that this will increase the risk of interference and packet collisions if you were transmitting in a congested area, given the relative size of your payloads. There are a lot of factors involved here, so I wouldn’t want to definitive advice, but I think you would be pushing the LoRaWAN protocol quite hard given your constraints.
Transmitting at that frequency would traditionally be better suited to a device that maintains an open connection with the network, such as a cellular connection.
Thanks Alex, appreciate the follow up. That all makes sense, and I feel like we will actually need to transmit far less than that. As I said we were really just trying to understand the upper limits of the technology before we get started on a concept. Fortunately we will be in a natural area that is relatively uncongested, and we will have a large 12v DC power source to draw from, so those are both in our favor.