Weather Station Hardware > Barani Design Weather Stations and Accessories

Update interval is too restrictive.

<< < (3/3)

Julius:

--- Quote from: johnd on August 23, 2020, 04:59:34 AM ---
--- Quote from: Jorginho on August 22, 2020, 04:34:02 PM ---I wonder if I am correct about the maximum of 5 times/hour data transmission and I also am interested how others feel about all of this.
--- End quote ---
I'm no expert but AIUI, that sort of limitation is correct.
--- End quote ---
For LoRaWAN and TheThingsNetwork, which is used for barani IoT devices now, there's not a limitation beyond TTNs fair use policy. And there really is no technical limit as long as you stay under an average of 1 packet uplinked to TTN every 30 seconds per device. So, say you have 4 devices (wind, rain, helix, soil), you can theoretically have update intervals every 2 minutes from each device. LoRaWAN does not limit anything, by the way, just technically it suffers from collissions/delays if one gateway goes beyond hundreds of devices, but who has that? The trouble is with the localized routers the gateways have to use. For the EU there's currently only ttn-router-eu, and luckily many are switching to other systems, like SigFox, so I doubt that it will be overloaded anytime soon.

I think Barani picked 10 minute intervals because it is according to the WMO spec to do so. For the MeteoHelix each 10 minute interval outputs a minimum, maximum and average of the entire 10 minutes (for all values it measures). Contrary to what people then think, it does NOT *miss* any maximum or minimum event within each 10 minute interval. So, to be clear; It doesn't take measurements in 10 minute intervals, it just spits out *all* collected measurement data from each 10 minutes that went by, up to the last second of those 10 minutes.
This is a mistake often made; It's not "designed slower than Davis". To explain this; When it sends out data at 12h12m10s, it tells you what it measured at 12h12h09s still, for example, but without that timestamp. Calculating the average value of the last 10 minutes happens in fractions of millisecs.

johnd:
I don't think there's any real disagreement about the capabilities of LoraWAN. Here's what TTN say about data rates for instance:

Sending data from a Node to your Application (uplink)

We want you to create products that are as efficient as possible. This will get the most out of your battery, and doesn’t require you to buy many gateways. If you follow these recommendations, you’ll definitely build an amazing product!


* Payload should be as small as possible. This means that you should not send JSON or plain (ASCII) text, but instead encode your data as binary data. This is made really easy with the Cayenne Low Power Payload format which is fully supported by The Things Network.
* Interval between messages should be in the range of several minutes, so be smart with your data. You could for example transmit a min|avg|max every 5 minutes, or you could only transmit when you sensor value changed more than a certain threshold or have it triggered by motion or another event.
* Data Rate should be as fast as possible to minimize your airtime. SF7BW125 is usually a good place to start, as it consumes the least power and airtime. If you need more range, you can slowly increase until you have enough. You can also enable adaptive data rate (ADR), the network will then be able to automatically optimize your data rate.
Of course it also depends how far your node might be from the gateway, spreading factor etc, so probably best to plan for worst case = low data rate.

Bottom line is that LoRa is not for real-time eg wind or rain data, but all weather data that can summarised succinctly in small packets eg every 10mins is fine.

Julius:

--- Quote from: johnd on November 17, 2020, 06:41:42 AM ---Bottom line is that LoRa is not for real-time eg wind or rain data, but all weather data that can summarised succinctly in small packets eg every 10mins is fine.

--- End quote ---
That's just not true. I have devices that transfer sensor data over LoRaWAN at ~100m distance from the gateway router. These are packets of around 20 bytes per event. They flash through the router to TTN within milliseconds, and show up on a website a few ms later, which you can F5 to load the most recent data. So, honestly, if you think a delay of 1 second would not be considered "real time" enough, fine, I think it's fast enough.

https://www.rfid-wiot-search.com/istanbul-airport-relies-on-lorawan-for-real-time-monitoring

And, they use LoRaWAN for real-time temperature regulation in datacenters too:
https://www.researchgate.net/publication/333009598_A_LoRaWAN_Wireless_Sensor_Network_for_Data_Center_Temperature_Monitoring

Julius:
That's not to say the output interval is indeed quite long.
I really don't know why the 60 samples of 10 secs are only transmitted by the MeteoHelix Pro every 10 minutes.
It does not look like the hardware (or the solar powered battery) could not easily handle doing the same every 150 seconds for example, or at the very least every 5 minutes.
This is a firmware choice made for a reason, but I'm not sure what that would be.. Anyone?

Navigation

[0] Message Index

[*] Previous page

Go to full version