As such we don’t have any latency requirements.
This is not a real time application we are talking about. its merely data collection from the source and saving it in cloud.
As such we don’t have any latency requirements.
This is not a real time application we are talking about. its merely data collection from the source and saving it in cloud.
Is it collecting data from nuclear missile silos?
If not, why don’t you just share what the data looks like so we can help you.
Or even tell us what the sensors are so we can help you further.
Or is it collecting BitCoins?
We are collecting data from On-grid Solar power system which have a weather station, a inverter, 2 door contact sensors, a generator, a fuels tank, a water tank and a power meter.
The Power generated by solar panel is used for running the pump and in case the there is no power generator is being used.
Depending on the use case another option could be to use multiple nodes.
Each node could be used for transmitting a certain data type, or data may be randomly distributed over different nodes - assuming the nodes are all connected to some central controlling system (wired or via Wifi but not LoRaWAN).
Probably not a good (and complex) solution but at least possible.
It appears like you want to send all data via a single node.
Why don’t you put separate nodes on each item (e.g. weather station, contact sensors, tanks etc)?
Some of these sensors don’t change fast enough to warrant updates that frequently.
I count about 10 to 15 packed bytes if you send an uplink with the status of everything, which I’d never do - you don’t need door contacts unless they change and if the generator is not running you don’t need any telemetry from that or the fuel level.
And as much as I’m growing so very tired of teasing the details out of people that ask for help for their top secret gold bullion tracking projects, if you tell us what the byte size of each sensor, it’s maximum, it’s minimum, it’s expected normal range and how often you think you need to have it sent, you may find that LoRaWAN can do this very nicely.
Though might add a fuel tank leak detection or theft protection alarm (exception based Tx only in that case!)
Indeed the data can be made much smaller.
But beware of sending deltas, as one has to assume that many uplink packets will get lost, and under TTN filling in the gaps would only be workable based on a bulk ack/nack hours later.
Fortunately, contact states just require fitting one bit into a packet, either grouped together in their own byte or stuffed in elsewhere where a field don’t need an exact multiple of 8 bits.
Consider alternative IoT long range networks like Glass-Link https://glass-link.io that offer much higher bandwidth, kilometers of range and real-time response (latency at about 2 ms).