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.
Czyli chcesz mieć własną sieć LoraWAN? (Nie twierdzę, że to jest zły pomysł, ale chce się upewnić, że jesteś świadom tego, że to jest decyzja.)
"Podaje informacje o swojej pozycji" sugeruje, że chcesz żeby te urządzenia miały odbiornik GPS. Używanie owego byłoby pewnie najbardziej energożernym kawałkiem prostego czujnika (GPS potrzebuje ~4 razy więcej mocy przez cały czas utrzymywania informacji o pozycji -- a jej znajdowanie od zera trwa z minutę -- niż nadajnik Lora podczas samego nadawania -- które trwa mniej niż sekundę per wiadomość; czujniki temperatury czy pH zużywają dużo mniej). Tak samo z mobilnym internetem, tylko jeszcze bardziej.
Ciekawe pytanie to jak chcesz aktualizować software na urządzeniach pomiarowych. IIRC LoraWAN się średnio nadaje do wysyłania nietrywialnych ilości danych _do_ urządzeń (ale nie pamiętam, czy nie ma jakichś śmiesznych kruczków które można zastosować jak wiesz wszystko o swoich centrach).
> Alerty wysokiego poziomu (w tym dane antysabotażowe), streaming i inne takie (w tym aktualizacje -- dzięki za heads-up) idą przez mobile broadband.
Czemu? Czujnik->sieć w LoraWAN nie ma ograniczeń na to kiedy możesz wysłać wiadomość. Problem masz tylko jeśli (a) chcesz wysłać wiadomość _do_ czujnika bez czekania (b) chcesz dużą przepustowość.
> Ogólna zasada jest taka, żeby energożerne procesy podnosiły się tylko w razie potrzeby.
To jest dość irytujące z punktu widzenia testowania i zasilania, bo oznacza, że musisz być przygotowany na dużo większy pobór mocy i to wytestować (w szczególności: czy przy baterii naładowanej w, dajmy na to, 10%, uruchomienie czegoś takiego nie spowoduje natychmiastowego wyłączenia się całego urządzenia).
Rutynowe komunikaty z czujników i alerty niskiego poziomu idą przez LoraWAN.
Alerty wysokiego poziomu (w tym dane antysabotażowe), streaming i inne takie (w tym aktualizacje -- dzięki za heads-up) idą przez mobile broadband.
Alerty wysokiego poziomu idą też smsami, na wypadek braku zasięgu MB.
Ogólna zasada jest taka, żeby energożerne procesy podnosiły się tylko w razie potrzeby.