I am doing "prior art" research to find out what are reliable and open constructions of sensors (and controlling/recording) platforms used in citizen monitoring of environment.
Due to recent events in Poland, priority topic is river monitoring: water temperature, pH, conductivity, dissolved oxygen, turbidity, ORP (oxidation reduction potential), water level (sonar?).
Also, typical weather station sensors recommendations will be appreciated.
If you know about an active group dealing with river environment monitoring, please drop a link here – I will be happy to learn from them.
At this stage, I do not intend to start any deep R&D. I need to learn about good (best!) practices and appropriate hardware, so we can deploy a network of early warning checkpoints as soon and as cheaply as possible.
@timorl Yes.
So, the story is that during Covid I wanted to be able to learn the temperature of a small lake ~5km away without cycling there each time. I asked around at work, and the conclusion was that (a) LoraWAN as the reporting protocol makes most sense (i.e. will allow for a multi-year operating time from a single cheapish battery) (b) The Things Network is a reasonable way of using some community-provided receivers to relay those reports to the Internet. Notably it was strictly better than:
- mobile (_much_ higher energy consumption),
- Lora to a receiver of mine (which would need to be in ~line of sight),
- WiFi (energy consumption + range),
- BT 5.0 (no community-provided network of relays).
I ended up using https://www.dragino.com/products/lora-lorawan-end-node/item/155-lsn50-v2.html (a version with a temperature sensor provided). That device has a couple (3?) ADCs. You can connect w/e you want to them and it comes in a box with a waterproof (the box is IP68) cable gland. Default firmware is reasonable, and is open source.
Downsides:
- people who have designed The Things Network do not understand how to design distributed systems and have taken design choices that unforcedly make interfacing with it annoying,
- the standard feedback loops ("allow the relay to tell you how to adjust your bitrate, if you don't hear back from any relay for long enough decrease it") seem to be broken in situations when the constraining factor is not attenuation but collisions[1] and also are divorced from the choice of sampling rate,
- (not a downside, but missed opportunity) the data transmitted _by that device's default firmware_ is just one sample at a time; it would make much more sense to transmit stuff like most recent sample + averages over last {hour,day,...} to get more useful data in face of packet loss.
My particular setup fell into disrepair when I stopped having a need to use it, and at some point packet loss skyrocketed. I suspect that a relay in the vicinity disappeared, but due to annoyances around a long-ongoing migration in The Things Network I couldn't tell (all the relevant relays were using The Old Thing, so The New Thing didn't report their identity apart from saying that this packet was received by The Old Thing... did I mention that I was annoyed by TTN?).
[1] using lower bitrate gives you a larger SNR, but also makes your transmission longer; thus, if the transmissions are not getting through due to collisions you should _increase_ bitrate.
