Fair Use Policy - Uplink connections

End Devices (Nodes)
1

Hello,
After some reading on the forum and some other docs on TTN, I understand that a node can send uplink messages:

  • within the duty cylce rules as stated in the airtime calculator
    airtimecalc
  • within the Fair Use Policy of TTN

To make sure my understanding is correct:
If I have a node sending a payload of 13+10 bytes, it will airtime for 61,7ms with SF7/BW 125
Technically, the node will have to wait for 6.2 sec before it can send another uplink message
But as per TTN Fair Use Policy, it should wait for almost 3 mn to send another uplink message.
This 3mn is an average and my node will be able to send the subsequent uplink message after 6.2 sec, it’s just that if there are too many triggers during a 24h period of time, once I have consumed my credit of 30 sec in, let’s say 1h, then I will hit the max for this day and I will have to wait for another 24h to resume activity for this node?

I am asking because I plan to use a node (dragino LDS02 or Milesight EM300-MCS) to monitor the state of a door (is it closed quickly after being opened). My external application will trigger a scenario to check on the status and notify me if the door si still open after 5 mn.
So most of the time, the door will be closed after opening way before the 3 mn FUP time is elapsed, but it is unlikely it wil be closed within the 6.2 sec delay of the 1% duty cycle.
I don’t expect the door to be opened many times during a day.

I have two solutions:

  • monitor the status of the sensor: closed or open. But if the FUP is strictly enforced per event, then I will receive the uplink message with door status to “open” but I will not receive the uplink message with door status back to 'closed"
  • monitor the status of the alarm of the sensor: I can set a period of time after which if the status is still “open” then an uplink message is sent. But I will not receive any uplink message when the status of the door is back to “closed”. Therefore my app chekcing on the alarm status will still see the foor as “open” and will notify me un-necessarily.
    Or maybe my node can be programed so that it can send it’s status “open” or “close” on a regular interval, to be determined according to the FUP.

Thks for your confirmation of the FUP enforcement.

Valyno

2

Hey Valyno,

I’m writing this for memory without reading docs, so be sceptical and check before believing me!

The 1% duty cycle doesn’t work quite like that (6.2ms on then 6.2s off). If formally tested it would be measured over 1hr (check this) so you could happily transmit bursts of packets within a short period , like 30s within the first minute, so long as your TX then stayed quite for the next 59mins.

You should keep a timer in your firmware to monitor this. Microchip module used to do this for you and would return an error when there was no more time available.

From memory, I recall it also had to keep a timer for each channel being used, since there are different DC allowances on diff channels.

3

And ‘many’ is ?

How far is the door sensor from the nearest Gateway, i.e. do you have a high level of confidence that the sensor will always operate at SF7 ?

4

I would also recommend NOT to include the LoRaWAN transmission as part of the time-series or trigger in your application, since it’s an ALOHA network and can’t / shouldn’t be assumed to be available to you at all times.

Let the edge device contain enough smarts to manage the open / close-within-5sec logic locally, then upload the result asynchronously (and with some redundancy)

5

If you have to ask, you are probably pushing the boundaries which brings in to question the suitability of LoRaWAN for your application, particularly as @JDP states, there is no guarantee of delivery even if you are well within limits.

To expand on that, before Jac comes along, there are no uplink connections - there are uplink transmissions - the device transmits, most of the time this is picked up by a gateway that relays the packet on. There is no handshaking therefor no connection. Any number of things could stop the uplink being heard properly or being relayed on.

The FUP is a simple 30 seconds airtime a day, max 10 downlinks, although 1 a week is considered about right. How you use that is up to you.

The duty cycle is a legal constraint - as in court of law / fines sort of legal - and some devices enforce this for you.

Many times we figure out a solution to a use case, but only when we are given enough detail - perhaps if you gave us (a whole heap) more detail on what you are trying to achieve, we can find a way.

6

Hi All,
Thanks for your answers.

And ‘many’ is ?

Less than 10 times a day

How far is the door sensor from the nearest Gateway, i.e. do you have a high level of confidence that the sensor will always operate at SF7 ?

The sensor will be about 60m away from the GW.
There is no other GW in the vicinity for now, so I am pretty confident that mine will always relay the uplink (i will be plugged on a UPS).

If you have to ask, you are probably pushing the boundaries which brings in to question the suitability of LoRaWAN for your application, particularly as @JDP states, there is no guarantee of delivery even if you are well within limits.

I do not intend to push the boundaries. I know that Lorawan & TTN are not meant to operate critical security devices nor heavy traffics.
I try to figure out what is the best way to achieve my purpose it in respect of the legal & FPU rules, knowing that EnOcean & Zigbee are not a solution (short range, not much outdoor devices for doors sensors. I already tried with a EnOcean sensor, but the 60m are too long).

My business case is pretty simple: I have a street gate that is not closing itself automatically. So we have to trigger the closing with the remote after our passage.
Sometimes, we forget to close behind us.
Therefore I would like to receive a notification when the gate remains open after a certain amount of time (around 5mn). I plan to buy a Milesight sensor for this need.

I do not plan to use downlink messages, except for the set-up of my node. Once it is configured, I don’t see the need to use downlinks anymore.

I think that Lorawan is a good solution for my need, provided that I can, if need be, send two uplink message in a row below 3 mn.
I also want to monitor a door, which is not open that often but for which the closing time is below the theoretical threshold of 3 mn. I already have a Dragino node (indoor) with which I am practicing before I buy the more costly Milesight sensor if I can achieve what I need.

I hope that my explanations are making sense.

Thks again for your time!
V

7

There’s little reason at all to use LoRaWAN for that.

First the range is short enough that many other radio schemes will probably work - 2.4 GHz FSK for example.

But even if you want to use 800 or 900 MHz LoRa as the radio scheme, you’re not really operating in a network but have a single point to point need. Dispensing with LoRaWAN’s very high protocol overhead would cut down on your airtime substantially - really, you need to send 1 bit of information, plus whatever it takes to have confidence that it’s from you.

Therefore I would like to receive a notification when the gate remains open after a certain amount of time (around 5mn).

A simple solution would be a timer that begins when the gate opens, and transmits if it’s still open after five minutes. At that point the timer could reset and transmit again in another five minutes, maybe eventually backing off to some longer intervals.

Even when you add the other device at the door, you’re still not really at a LoRaWAN type application, as what you are describing is still a very small number of nodes in a small area with no interaction with other things.

More generally though where all of the comments seem to be going is towards a conclusion that to do this right you’re going to need custom software on the node that implements a behavior tuned to the need, and not just the out-of-box behavior of someone’s off-the-shelf sensor.

8

@cslorabox:
I should have mentioned in the first place that I am not an engineer at all (I am an HR person…).
I am just a tech enthusiast doing a bit of home automation with a Jeedom box.

First the range is short enough that many other radio schemes will probably work - 2.4 GHz FSK for example.

I do not know the 2.4 GHz FSK. I can have a look.
I agree with the fact that Lorawan is certainly overkill for what I need. But the “home” solutions like Zigbee, EnOcean or Zwave did not have the solution to my problem (not that I found though).

And I need a solution that can integrate in the Jeedom world. As I have not the skills to develop a plugin myself, I need to rely on the protocols supported by Jeedom and the existing plugins.

Lorawan & TTN are supported by Jeedom. What I need is to collect the raw data from the node, and then from Jeedom, I can design scenarii with these data (i.e timers, notifications and even some other actions from other devices not Lora specific).
The door sensors have some capabilities on their own, like timer and regular uplink updates on top of sending the status upon action, so I have the possibility to either take the status itself (opened/closed) or to collect the status sent from the timer on the node itself.
I am trying to figure out what is the less airtime consuming.

At this stage, I have already bought the lora gateway which is in operation, and I have a sensor for testing.
If it turns out that the Lorawan solution is really not a good option, I guess I will re-sell the gateway and will try to find another option.

Thks for your comments!
V

9

So what you have is a software problem, particularly a node software problem.

And you’re not in a position to do work on node software…

10

The 2.4Ghz SX1280 LoRa devices give you the option of the same sort of high speed transfers as a typical 2.4Ghz FSK device such as the NRF24s can manage, but with the option (that NRF24s do not have) of going slow speed and long distance, circa 90km LOS. The LoRa devices will do FSK if you insist.

There is a LoRaWAN implementation for the SX1280;

11

A beginner trying to work with rarely used 2.4 GHz LoRaWAN is likely to hit lots of frustration and find little support - that’s still very much a “niche” kind of sub-field of LoRaWAN

The reason for 2.4 GHz would be to be able to use dirt cheap FSK radios that are often fine at the kinds of ranges mentioned, and take advantage of the much more frequent transmission that’s typically legal at FSK data rates and 2.4 GHz spectral allocations.

12

If the gw is so close then so is the Wifi network. An Esp8266 would suffice and allow more data to be sent, more often, possibly using mqtt.

1 Like
13

Sounds unneccesarily complicated, automating a process with RF-based solution to notify a human (s)he has to manually press a remote control button to close a gate which has remained open for a certain amount of time (because someone forgot to close it).

My suggestion would be to automatically close the gate after some inactivity timeout and remove the human factor (directly control the gate instead of notifying a human to close it).