Have a node just sit there listening, waiting

Hi, Noob first post.
I’m aware of the need for very low duty cycle. I have a bunch of sensors gathering data. When certain thresholds are reached I want Node Red (or whatever) to make a decision & then send an alert to a single LoRa device that just sits there (with big batteries) waiting to be told to turn a device on. I want a near-instant response from this device. I understand this might need to be a class C device, which might be unsupported. Is it only Class C that can do that? After all - I only want to listen, so not eating up any bandwidth.
Many thanks.
Simon

imho only class C - devices listen to downlinks all the time. With enough capacity of the battery this should be possible.
But you can’t guarantee an immediate response because it’s possible that the node doesn’t receive the command to transmit it’s values. If it’s safety relevant I would not use LoRaWAN for this application.

2 Likes

Thanks. Not safety relevant, but I don’t want to miss it! I was hoping I could send an acknowledgement back to the listener, ideally within the LoRaWAN protocol, but if it doesn’t allow this I could do so at the application layer

imho only Confirmed Uplinks (from node to gateway) are possible, the confirmation is sent from the gateway to the node. But you should use them very seldom.
Also the downlinks (from the gateway to the node, to request the data) should be maximum 10 per day.

1 Like

You can send confirmed downlinks. So you will be able to know if your node received the downlink.

Let’s repeat that you can send 10 downlinks per day.

2 Likes

Yes

Define “near-instant” and what % of non-response can you stand?

How many times a day is this threshold going to be reached that requires this guaranteed speedy interaction?

Perhaps if you told us what it is (many do like to keep things secret for no real benefit), we can suggest a scheme that may well work for you.

1 Like

Near-instant is a few seconds. Maybe 3 times per week, but could be on the same day (but unlikely)

In that case, Class C would seem to be a good fit.

Not that you answered the % of non-response you can stand. Or if you can stand a few more seconds, possibly a small number of minutes, to get the response.

I’m not sure if this would help much (the application was not revealed), but what if the node transmitted an incrementing count instead of a simple ‘it’s happened’ flag. In this way if a transmission is lost, the counter can be used to detect something was lost/dropped.

…also note that with any radio-based connection there is no guarantee at all that communication is possible. It could happen that some strange radio interference (remember that LoRa happens on an open frequency band) disables all data traffic. In this case you could detect such a condition by using alive messages, but that’s all. I’m speaking from my own experience here. Even LoRa modulation is not totally invulnerable.

As was already stated, it all depends on the concrete constraints of your application.