new river level monitor

[Graham Eddy]

i posted some time ago about my trusty old river level monitor. i am still receiving occasional enquiries about it - yes, unfortunately that product i used is no longer available. whilst it is still working for me, i have now deployed a new river level monitor in parallel, some details below

old river level monitor

Aquagauge provided a radio receiver with serial interface and a number of sensor types with radio transmitters. a receiver could support up to 8 transmitters. the radio and serial protocols are proprietary

i wrote a weewx service that read the serial interface and inserted the data values into weewx packets. later i migrated this to a daemon that emitted the data as mqtt messages, and weewx reads the mqtt messages. this works fine; it is still in use

this river level sensor is pressure-based i.e. the probe sits on river bottom (in my case wrapped around a brick and tucked into a river bank nook) and measures the water pressure. there is a very inconvenient cable from the probe to the transmitter. the latter measures atmospheric pressure, the pressure difference is the weight of the water above the sensor thence deriving water depth. it proved to be quite accurate

the transmitter has suffered many travails, the latest being going for a swim during a flood when the bridge it was on was swept downstream. it is very robust but now failing more often and i fear one day soon not being able to rescusitate it → motivation for replacement. this product is no longer sold or supported

new river level sensor

i decided to try an ultrasound sensor i.e. the probe measures round-trip time for a signal reflected from river surface back to probe with known speed of signal. this means there is no cable needed to run into the river

my river level sensor must be a commercial off-the-shelf product, for which i am happy to write interface software. it also has to be wireless connection to RPi at least 50 meters away and be powered by long-life battery

i picked a Dragino LDDS75 Distance Detector (https://www.dragino.com/products/distance-level-sensor/item/161-ldds75.html). i mounted it under the sparkling new bridge i built over the river, higher than the old bridge. it sends quite large and complex messages via mqtt, so i wrote a daemon that plucks the salient data and re-publishes as simple message, imported into weewx. my daemon also configures a fix-point height for the sensor, so the simplified mqtt message includes a ‘level’ field as well as ‘distance’ for easy digestion

this is a LoRaWAN device so provides the long distance and battery longevity i require

radio receiver server

the new river level sensor is the first of several sensors on my new open radio network, as opposed to the closed proprietary radio network per Aquagauge, so i need a radio transceiver to talk to them. i assume familiarity with LoRaWAN (https://www.thethingsnetwork.org/docs/lorawan/architecture/)

for the local LoWRaWAN gateway, i put a RAK 2245 LoRaWAN HAT (https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2245-pihat) on an RPi 4B and installed RAK’s gateway software from their GitHub

i tried using the chirpstack LoRaWAN stack running on local server but couldn’t get it to work reliably, it seemed to work only intermittently. i think i was having trouble with not picking up the radio packet preamble but, not being a radiohead, gave it up as too much like hard work. i tried The Things Network stack (https://www.thethingsindustries.com/docs/getting-started/ttn/) and, to paraphrase steve jobs, ‘it just worked’. i am using the ’community edition’, which is a subscribed but free service. the downside is that the network server and join server run on TTN’s hardware over the internet so i lose device connectivity when internet link is down. they provide the software to run your own copy of the stack, which i plan to do in future

so, the river level sensor emits radio packets, my RPi gateway receives the packets and sends to TTN stack, the TTN stack processes and emits them as complex mqtt messages, which my dameon picks up and simplifies, then weewx digests the simplified mqtt messages. (i have chosen to put LoRaWAN gateway on a separate RPi from the weewx RPi)

the TTN stack’s mqtt broker is on their remote server. i have chosen to bridge that mqtt broker to my RPi gateway so that, from my home network’s perspective, all that LoRaWAN stuff is happening on my RPi gateway. this fits my plan to move the TTN stack to the RPi gateway in future

the RAK 2245 includes an itty bitty antenna. i get a good signal and reliable connection at 100 meters, haven’t tested further distance. LoRa supports 10 km with a decent antenna

additional sensors

the LoRaWAN gateway supports a lot of LoRa devices simultaneously, it is just a case of joining them to the radio network and processing their dat

i have also deployed a river temperature sensor (replacing the VP2 wireless temperature station crushed in a storm a year ago). i picked a multiple-probe Dragino LSN50v2-D23 Waterproof Temperature Sensor (https://www.dragino.com/products/temperature-humidity-sensor/item/193-lsn50v2-d23.html) to see how well multiplexing on single device is incorporated and, as you would expect, it is just additional fields in the mqtt messages for each probe

conclusion

reading back, it sounds more complicated than it is. i grabbed a separate RPi, stuck a bit of RAK hardware on it, installed RAK’s software, subscribed to TTN, configured my RPi into the TTN service, and i had connectivity. i wrote a daemon to make the sensor data more digestable for weewx

what i got was an open, extendable radio network that supports long distance wireless sensors, for which there are multiple vendors competing to sell you their sensors

see https://wx.geddy.au, pull up ’today’ charts

cheers

⊣GE⊢ wx.geddy.au

⊣GE⊢

[gary....@gmail.com]

Very nice.

This post gave me incentive to restart my LoRaWAN testing with some new equipment.