hi all,
I have a RAK7204 sensor, and I want to use minimum legal interval of sending data for my sensor based on duty cycle and use the minimum interval which is legal,
and I want to optimize the minimum interval of sending data for different locations and spreading factors that work on those locations.
RAK7204 payload is 19 bytes, and the bellow calculator determines the minimum legal interval of sending data considering (1% max duty cycle) (as I live in Europe)
https://avbentem.github.io/airtime-calculator/ttn/eu868/19
My question is if I do a test with my sensor to know what spreading factor works in different locations, and set “unconfirmed messages”, is it appropriate if I set interval of sending data exactly what is written in this calculator (for each spreading factor that works)? or may something cause my interval gets smaller in practice and break the law?
for example Can I use interval=181.0 s for sf=12 and unconfirmed message or it needs to consider a safety margin. and do I miss something in the mentioned configuration that may cause legal problem?
Thank you
Which LoRaWAN service are you using?
@nmcc
Thank you for your reply,
I use LoRaWAN MAC version 1.0.2 and LoRaWAN regional revision A using ChirpStack. if I correctly get your question.
If it’s your own backend, then try your calculation and process the logs to add up your transmission times to check your duty cycle.
BTW, this isn’t a RAK device issue - any device that you want to push the limits on the duty cycle will have the same result.
It helps when doing these sorts of tests to be able to justify the why, because if some local infrastructure is compromised by your tests, however legal they are, someone somewhere won’t be happy.
@nmcc
chirpStack is running on my raspberry pis and data is stored locally on them. is this ok in this case?
and I would be grateful if you could explain me more about what you mean by:
“try your calculation and process the logs to add up your transmission times to check your duty cycle.”
it is not accurate if I use data from that online calculator?
and another question that I encounter is “in the ETSI EN300.220 standard I saw the duty cycle 0.1% for some sub band too, but I do not know why we consider only duty cycle 1%”.
it is ok if I consider only duty cycle 1% in this optimization?
Real life and what you actually broadcast which is what the law is interested in.
Not real life, a calculator to give you some guidance, doesn’t measure what you actually broadcast which is what the law is interested in.
And no, you can’t ignore the 0.1% duty cycle band, just like you can’t ignore speed limits on side roads, you have to calculate for all bands for their duty cycle.
Or just not push the limits.
@nmcc thank you for your explanation.
as I do not know when it use * g2 (868.7 – 869.2 MHz), I do not when I should consider duty cycle 0.1% , could someone advise me in this regard?
and how I can measure what I actually broadcast (which is what the law is interested in)?
The firmware should account for it.
thank you @nmcc .
Could someone please advise me for that. I mean what I should do for that? and what I should check regarding duty cycle 0.1? and consequently set regarding that?
Not without being paid HUGE sums of money to contribute to my insurance so I’m covered for any liabilities arising.
Plus the ENORMOUS amount of money that will get you to a point where you know most of the LoRaWAN spec and can read LoRaMAC-node and the regional settings to see how it is implemented.
What you are talking about is working at expert level, at which point you’d know all this stuff anyway.