Hi,
Currently I have a node with a TTGO-Tbeam working quite good. For a new project, a moving sensor, I want to send messages, when needed using a queue, but having a guaranteed delivery to the TTN-Application.
Is there a parameter in the LMIC stack for this? I cannot found it…
BR/ Erik-Jan
This may be of interest.
What happens if the device is out of range of the network? Messages are queued until the connection is back?
How often are messages generated?
Is the old message more important than the new data?
A guaranteed/confirmed uplink would require downlink from the network. This does not necessarily mean your application has recieved it from the network. Application level guarantees must occur at the application level. This would require the application to queue a response for the network to send to the device.
Can multiple message fit in a single uplink?
Maybe the application could request the missing data to fill the blanks.
Hi Jason,
I have the same question. Yes, on application level I can fix this but I would like to handle this in the communication layer if this is already implemented.
Yes a downlink is required and currently I have already a ode with a up and a downlink. Foe the new node it is essential that alle the messages arrive.
The node will be used by the fire department. A car will messure CO in the air during a fire. Based on this teams to messure the safety of the are will go to a positions where it will make sense. Currently those teams will go to locations based on computer calculations.
The frequency of the messages will depend on the CO level, when save: verry less messages, when the level of CO rise, a message should go to the dispatcher.
Nothing is guaranteed about delivery with LoRaWAN at the comms level and there is absolutely no guarantee about timescales of delivery up or down. So any confirmations at firmware / application level may take many minutes if not longer. For TTN there is a fair use policy of 10 downlinks a day.
Every time a gateway transmits an ACK or a downlink, it is unable to hear any uplinks at all, so any uplinks from devices that only in range of that gateway are lost.
If you need this data to be transmitted frequently, you should also be aware of the TTN fair use policy for uplinks and your local legal restrictions on duty cycle.
As for your application @Erikjan, I can’t begin to describe how totally inappropriate your application is, even if you are using TTI. If you are using TTN without an SLA then all bets are off.
If you don’t know the LoRaWAN MAC or this implementation of it that well, maybe you shouldn’t be using it for this application.
I’d have to assume you have a LoRaWAN gateway on LTE on each & every appliance - so you can ensure that the system works regardless of which vehicles are at scene. And then you run in to the issue of LTE coverage.
I type this as someone who builds safety critical systems for security and as a first responder who would never want LoRaWAN to be part of my safety net.
If @Erikjan wants to cut to the chase, a module like the NRF24L01 would be far more appropriate if you are trying for a proof of concept but I’m not necessarily recommending that for production.
For the purposes of enlightenment and discussion I’ll leave this topic open to discuss LoRaWAN suitability for safety critical sensing applications.
Hi Nick,
The idea at this moment is just for a proof of concept " Can this work with Lora?" Another option is that we will use mobile data . I don’t want to go over the fair use policy…
For the safety responders: They WILL get a signal in the car that the CO level will change, The advantage should be that the dispatcher will see this as well. This line is no critical path in the fighting of the incident. That’s why we would like to test lora for this. Another option is to make a ‘own’ lora network with own gateways. By the way, if we will use Lora, gateway’s will be placed for sure so how nice could it be if those can also be used by TTN?
With point to point LoRa you can use uses send and acknowledge as often as you want (within legal limits) to ensure, to a high level of certainty, that packets being sent have arrived and been acted on.
I do not see the point of even considering LoRaWAN\TTN as a ‘proof of concept’ as it very cleary cannot provide the level of reliability in the comms that you would need.
Yes, but that would be off topic for this forum. As would mobile data.
We don’t want or like mobile gateways, so that’s not going to help your case.
Hi Nick,
I never talked about mobile gateway’s. That was you’re option. When we will use Lora we will use a number of fixed gateway’s to cover the area we are in. but taking the discussion, i think we will use the already available peplink LTE connections.
I thought it should be nice having a number of gateway’s additional in use for TTN…
This doesn’t sound like an application where you want to waste time re-sending increasingly stale data.
Rather, what you want to do is replace it with fresher readings.
If you’re concerned about overall exposure, you also may want to keep some sort of trailing sum/average in the node’s MCU and send that too. And potential log it all in flash or EEPROM for download later.
But as many have said, you can’t count on TTN for safety data, and even though you say it’s not safety data, there’s a real risk people may start using it as such.