ESP8266 NodeMCU3 Wemos i latający termometr

[MC2Systems]

Mam do opracowania "latający" możliwie precyzyjny termometr. W założeniu ma to być możliwie najmniejszych gabarytów rozwiązanie, które będzie badało temperaturę na konkretnej wysokości i w konkretnym miejscu.
Latanie czujnika rozwiążę dronem więc tu nie problem. Czujnik działał by zupełnie oddzielnie, byłby tylko podwieszany. Natomiast problemem są dane...
Przyglądam się 2 rozwiązaniom:
1. Jakiś mikrokotroler pokroju UNO z podpiętym czujnikiem temperatury i wilgotności SHT35 + GPS -  L76X. Ewentualnie jeszcze jakiś barometr. To zestaw generujący dane.
Zapis na karcie SD? Tylko czy warto? Czy patrząc jakie są/bywają problemy z zapisem i błędami, czy nie lepiej zastosować coś innego? Pomiary z uwagi na procedury i latanie w miejscu dość ruchliwym nie umożliwiają powtórzenia lotu w przypadku błędów w zapisie. Zapis będzie pewnie co sekundę lub tak często na ile pozwolą odczyty GPS/Temp/Wilgotność.

2. Zamiast UNO zastosować ESP8266 Wemos z 32MB na pokładzie. Jeśli chodzi o układ generujący dane, to właściwie nic się nie zmienia. 
Natomiast zastanawiam się czy tu lepiej było by zastosować jakiś układ GSM i wysyłać pomiary od razu na serwer, czy mając te 32MB Flash zapisywać dane w pamięci i po wylądowaniu zgrywać np. na komputer. 
Lot będzie trwał powiedzmy 20minut. W ciągu minuty będzie max 60 pomiarów. Jako dane będą możliwie precyzyjne współrzędne geograficzne, wysokość oraz temperatura, wilgotność (i ciśnienie).
Dotychczas mam już zrealizowane prototyp w postaci stacjonarnego odczytu danych z czujników i zapisu do bazy Influx i wizualizację w Grafanie bazując na ESP8266 NodeMCUv3. Ten element działa poprawnie.
Tyle że w miejscu gdzie testuję naziemny taki system, mam dostęp do WiFi, czyli dane mogę na bierząco wysyłać na serwer.  Zastosowanie modemu GSM chyba przedroży sprawę.
Pojawia się pytanie czy zastosowanie zamiast tego ESP8266 z tymi 32MB Flash wystarczy? Jak to zapisać? I jak później "zrzucać" dane po wylądowaniu? Czy to wystarczająca ilość pamięci?

Jakieś sugestie bym nie musiał wynajdywać koła od początku? 🙂

z góry dziękuję.

[ethanak]

9 godzin temu, MC2Systems napisał:

zastosować ESP8266 Wemos z 32MB na pokładzie

Skąd pomysł na 32 MB?

Policzmy:

Współrzędne - raczej nie uzyskasz lepszej dokładności, więc 2 x 4 bajty powinny wystarczyć. Ale niech będzie 2 x 8

Wysokość: Rozumiem, że dron nie lata na kilkaset kilometrów w górę i nie mierzysz wysokości z dokładnością do milimetra - więc cztery bajty to aż za dobrze

Temperatura: jeden bajt na temperaturę i drugi na wilgotność by wystarczył, ale niech będzie cztery dla równego rachunku. Mamy 16 albo 24 (jeśli się uprzesz na superdokładne współrzędne) bajty na pomiar.

Teraz mamy ilość pomiarów. Dron może latać przez 20 minut, wykonuje 60 pomiarów na minutę. 20 x 60 = 1200 - tyle maksymalnie będzie pomiarów w czasie jednego przelotu.

1200 x 24 = 28800 - czyli nawet nie 32 kilobajty...

Teraz policzmy inaczej.

Ponieważ dron nie lata naokoło całej kuli ziemskiej, wystarczy zapisanie pozycji startowej oraz pozycje względne w czasie pomiaru - 2 x 2 bajty, razem cztery.

Dwa bajty wystarczą na wysokość, dwa na temperaturę/wilgotność - znów cztery, mamy razem osiem.

1200 x 8 = 9600 bajtów

A może jeszcze inaczej?

załóżmy że mierzysz pozycję z dokładnością co do metra, a dron może odlecieć na max. 2 km. Czyli pozycja to nie dwa bajty, a 2 x 12 bitów, w sumie 24 bity czyli 3 bajty.

To samo się tyczy wysokości, temperatury i wilgotności - drugie trzy bajty, razem sześć.

1200 * 6 = 7200 bajtów...

No to zobaczmy co jest małe, lekkie i potrafi w jakiś sensowny sposób zapisać te 7200 bajtów...

Może FRAM? Wystarczy 64 kbit, prawda? Albo jakiś EEPROM... na pewno tańszy...

Wniosek: nada się wszystko co jest małe i potrafi obsłużyć I2C/SPI potrzebne do komunikacji z czujnikami i pamięcią. Na upartego,  gdyby wszystko spiąć po I2C to wystarczyłby ATtiny85 🙂

 

 

[ethanak]

A teraz zderzenie z twardą rzeczywistością.

Masz zmontowany układ z ESP i czujnikiem? Podłącz go i chuchnij na czujnik. Czy na pewno dwa pomiary w odstępie sekundy pokażą prawidłową wartość (pierwszy - temperaturę i wilgotność w pomieszczeniu, drugi - temperaturę i wilgotność wydychanego powietrza)?

Nie wiem jaką bezwładność ma higrometr, ale 60 pomiarów na minutę przy przemieszczającym się dronie pokaże Ci średnią temperaturę w zupełnie innym miejscu i to sprzed jakiegoś czasu...

 

[MC2Systems]

2 godziny temu, ethanak napisał:

Skąd pomysł na 32 MB?

Bo takie mam dostępne. Mam ESP8266 NodeMCU v3 i Wemos z 32MB na pokładzie.  Kolejnym argumentem  jest to, że tutaj układ prawie gotowy. Inne trzeba by zaprojektować od podstaw. Kolejna sprawa czy uda się go tak zaprojektować by był realnie mniejszy niż ESP? Pewnie to kwestia budżetu.
Minimalizować będę później, jak sam pomysł wypali = da wymierne efekty. Póki co, chcę złożyć układ z dostępnych klocków. Kolejnym argumentem jest to, że nie wiadomo czy na pomiarze temperatury się skończy. To projekt badawczy więc profesory mają różne pomysły 😉 i nieograniczoną fantazję i motywację do uzyskiwania grantów.

 

2 godziny temu, ethanak napisał:

Współrzędne - raczej nie uzyskasz lepszej dokładności, więc 2 x 4 bajty powinny wystarczyć. Ale niech będzie 2 x 8 

Wysokość: Rozumiem, że dron nie lata na kilkaset kilometrów w górę i nie mierzysz wysokości z dokładnością do milimetra - więc cztery bajty to aż za dobrze

Temperatura: jeden bajt na temperaturę i drugi na wilgotność by wystarczył, ale niech będzie cztery dla równego rachunku. Mamy 16 albo 24 (jeśli się uprzesz na superdokładne współrzędne) bajty na pomiar.

Teraz mamy ilość pomiarów. Dron może latać przez 20 minut, wykonuje 60 pomiarów na minutę. 20 x 60 = 1200 - tyle maksymalnie będzie pomiarów w czasie jednego przelotu.

1200 x 24 = 28800 - czyli nawet nie 32 kilobajty...

No to łopatologicznie mi wyliczyłeś... dzięki. Sporo to upraszcza. Ja niestety póki co jestem jeszcze na etapie rozumowania działaniami na plikach. A wiadomo że zapis do pliku w danym systemie plików jednak sporo dodaje danych które nie koniecznie są użyteczne.

2 godziny temu, ethanak napisał:

Teraz policzmy inaczej.

Ponieważ dron nie lata naokoło całej kuli ziemskiej, wystarczy zapisanie pozycji startowej oraz pozycje względne w czasie pomiaru - 2 x 2 bajty, razem cztery.

To rozwiązanie z przyczyn związanych z założeniami projektu, nie wchodzi w rachubę. Każdy pomiar ma być maksymalnie dokładnym, obarczonym minimalnym błędem, a przede wszystkim niezależnym od innych pomiarów i kompletnym. Oczywiście nikt tu nie mówi jeszcze o tym jaka to dokładność i jaka wielkość błędu. To pewnie będzie później, gdy dokładność pomiaru w terenie będzie mijała się z oczekiwaniami.

2 godziny temu, ethanak napisał:

załóżmy że mierzysz pozycję z dokładnością co do metra, a dron może odlecieć na max. 2 km. Czyli pozycja to nie dwa bajty, a 2 x 12 bitów, w sumie 24 bity czyli 3 bajty.

To samo się tyczy wysokości, temperatury i wilgotności - drugie trzy bajty, razem sześć.

1200 * 6 = 7200 bajtów...

No to zobaczmy co jest małe, lekkie i potrafi w jakiś sensowny sposób zapisać te 7200 bajtów...

Może FRAM? Wystarczy 64 kbit, prawda? Albo jakiś EEPROM... na pewno tańszy...

Wniosek: nada się wszystko co jest małe i potrafi obsłużyć I2C/SPI potrzebne do komunikacji z czujnikami i pamięcią. Na upartego,  gdyby wszystko spiąć po I2C to wystarczyłby ATtiny85 🙂

No świetnie, jeszcze trzeba by dorzucić coś o czym zapomniałem, czyli precyzyjny znacznik czasu, bo dane mają być korelowane ze wskazaniami heliografu.
Pytanie tylko czy zastosowanie choćby ATtiny85 czy innego małego układu faktycznie sporo obniży masę i objętość, czy jest to warte zachodu. Bo trzeba jeszcze doliczyć zasilanie (pewnie jakiś Li-Pol, stąd kierowałem się na układy z 3,3V). I kolejne pytanie związane z małymi układami, czy wyciągnięcie danych z takiego maleństwa będzie do zrealizowania dla użytkownika który zna się na klimacie i chmurkach a nie na informatyce czy elektronice?
Te 32MB dają jednak troszkę większe możliwości uczynienia układu bardziej "ludzkim"...

2 godziny temu, ethanak napisał:

A teraz zderzenie z twardą rzeczywistością.
Masz zmontowany układ z ESP i czujnikiem? Podłącz go i chuchnij na czujnik. Czy na pewno dwa pomiary w odstępie sekundy pokażą prawidłową wartość (pierwszy - temperaturę i wilgotność w pomieszczeniu, drugi - temperaturę i wilgotność wydychanego powietrza)?

Tutaj trzeba będzie wykazać jakie są ograniczenia związane z bezwładnością pomiaru.  Do tego dobrać prędkość lotu i dokładność pomiaru, który chce się uzyskać. Stąd właśnie wybór padł na układ SHT35 bo ma najbardziej obiecujące parametry. Do tego jeszcze trzeba będzie zapewne czujnik odpowiednio obudować, by zniwelować wpływ promieni słonecznych na pomiar. Uwzględnić wpływ wiatru na rzetelność pomiaru itp. No sporo jest tych problemów do rozważenia. Ale właśnie po to ten wątek utworzyłem, by inni mogli zwrócić uwagę na to co mogę przeoczyć. Co kilka głów to nie jedna.  Mam to (nie)szczęście być trochę w środowisku IT i trochę w środowisku klimatologów. Trudno "pożenić" działania 0/1 z czymś bliżej nieopisanym jak parametry klimatu 😉. A szersze spojrzenie wielu oczu na potencjalne problemy pomoże znaleźć jakąś w miarę dobrą ścieżkę do celu, unikając po drodze być może oczywistych błędów.
Reasumując:
- ESP8266 - wydaje się mieć wystarczająco pamięci by poza zbieraniem danych, móc je jeszcze w sposób możliwie najprostszy dla laika pobrać.
- wykorzystanie mniejszych układów wydaje się że nie koniecznie poprawi efekt końcowy (masa, objętość i rzetelność pomiaru), bo poza układem trzeba jeszcze zapewnić parametry zasilania itd...

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

24 minuty temu, MC2Systems napisał:

To rozwiązanie z przyczyn związanych z założeniami projektu, nie wchodzi w rachubę. Każdy pomiar ma być maksymalnie dokładnym, obarczonym minimalnym błędem, a przede wszystkim niezależnym od innych pomiarów i kompletnym

Nie bardzo rozumiem o co Ci chodzi z tym "nie wchodzi w rachubę".

Pierwszy pomiar zapisuje dokładne położenie (co znaczy "dokładne"? Co do metra? Centymetra? Milimetra? Zakładam że lepszej dokładności niż metr nie uzyskasz). Następne pomiary to offset od pierwszego (a nawet przy częstych pomiarach po prostu różnica między bieżącym a poprzednim, wtedy 8 bitów wystarczy). Przy 12 bitach (11 bitów liczby + znak) i dokładności metr masz maksymalną odległość w czasie jednego przelotu 2047 metrów w każdą stronę. Przy 8 bitach i zapisach różnicowych co sekundę przy dokładności  metra maksymalna prędkość drona to ok. 450 km/h... Nie do przyjęcia jest dokładność metra czy maksymalny dystans? Czy może masz szybszego drona?

28 minut temu, MC2Systems napisał:

No świetnie, jeszcze trzeba by dorzucić coś o czym zapomniałem,

No to fajnie że sobie przypomniałeś...

29 minut temu, MC2Systems napisał:

czyli precyzyjny znacznik czasu,

I znów pytanie co znaczy "precyzyjny". Dokładność do sekundy, milisekundy czy mikrosekundy? Bo niżej raczej nie zejdziesz...

30 minut temu, MC2Systems napisał:

czy wyciągnięcie danych z takiego maleństwa będzie do zrealizowania dla użytkownika który zna się na klimacie i chmurkach a nie na informatyce czy elektronice?

A czemu niby miałby się znać? Podpina czujnik do kompa i odpowiednia aplikacja (którą oczywiście musisz dołączyć) wyciąga dane z ustrojstwa i wrzuca do pliku. Myślisz że taki meteorolog ma choćby blade pojęcie jak działa którekolwiek elektroniczne urządzenie którego używa? Jak umie podłączyć kabelek USB bez pomylenia końców to powinno wystarczyć.

[MC2Systems]

1 godzinę temu, ethanak napisał:

Nie bardzo rozumiem o co Ci chodzi z tym "nie wchodzi w rachubę".

Pierwszy pomiar zapisuje dokładne położenie (co znaczy "dokładne"? Co do metra? Centymetra? Milimetra? Zakładam że lepszej dokładności niż metr nie uzyskasz). Następne pomiary to offset od pierwszego (a nawet przy częstych pomiarach po prostu różnica między bieżącym a poprzednim, wtedy 8 bitów wystarczy).

No właśnie chodzi o to że nie może być zapisu względnego, czyli czy to informacji o offsecie itp.
Dla każdego punktu musimy mieć pełne dane: czyli pełne współrzędne, czas, temperaturę i inne elementy. Dane będą przetwarzane przez różne programy i nie może być tutaj możliwości przekłamań. Taki wymóg "odgórny" niestety.

Lot raczej będzie wolny, choć powierzchnia spora. Prędkość będzie uzależniona od bezwładności pomiaru no i dokładności pokrycia terenu. Ale to raczej będzie doświadczalnie dobrane, bo też na obecną chwilę nie wiadomo jakich zmian temperatury się spodziewać. Czy będzie to np. 0.5st co 10m czy co 100 itp.

Co do precyzji znacznika czasu to raczej to co jest w stanie dostarczyć GPS. Ale z pewnością nie poniżej milisekundy. 

1 godzinę temu, ethanak napisał:

A czemu niby miałby się znać? Podpina czujnik do kompa i odpowiednia aplikacja (którą oczywiście musisz dołączyć) wyciąga dane z ustrojstwa i wrzuca do pliku. Myślisz że taki meteorolog ma choćby blade pojęcie jak działa którekolwiek elektroniczne urządzenie którego używa? Jak umie podłączyć kabelek USB bez pomylenia końców to powinno wystarczyć.

Czemu miałby się znać? Bo praca jako meteorolog (patrząc od strony choćby instytucji IMGW) wymaga zdecydowanie więcej niż znajomości meteorologii 🙂 Mowa tu nie o zwykłym "klikaczu" na państwowej posadce, ale pracowniku naukowym który bada zjawiska a nie tylko je rejestruje.
Ale nawet zakładając, że orientuje się w temacie, to może to być dla niego skomplikowane. Stąd pomysł by zastosować ESP8266 z większą pamięcią bo tam mogę(?) umieścić mały serwer www z którego po podpięciu przez WiFi może pobrać plik z pomiarami. Takie coś to i profesor nauk nieścisłych ogarnie 😉

[ethanak]

2 minuty temu, MC2Systems napisał:

No właśnie chodzi o to że nie może być zapisu względnego, czyli czy to informacji o offsecie itp.
Dla każdego punktu musimy mieć pełne dane: czyli pełne współrzędne, czas, temperaturę i inne elementy. Dane będą przetwarzane przez różne programy i nie może być tutaj możliwości przekłamań. Taki wymóg "odgórny" niestety.

A co to konia obchodzi jak dane są wewnętrznie zapisywane w urządzeniu? Przecież na wyjściu dostajesz dokładnie to samo, co byś dostał zapisując bez potrzeby kilobajty identycznych rekordów. Na wyjściu dostajesz np. śliczny plik CSV. A jeśli boisz się przekłamań wewnątrz urządzenia (bo np. EEPROM sam się przeprogramował albo promieniowanie kosmiczne uszkodziło jakiś bajt) - do tego stosuje się zupełnie inne mechanizmy kontroli spójności danych (które dla świętego spokoju możesz zaimplementować).

8 minut temu, MC2Systems napisał:

Bo praca jako meteorolog (patrząc od strony choćby instytucji IMGW) wymaga zdecydowanie więcej niż znajomości meteorologii 🙂 Mowa tu nie o zwykłym "klikaczu" na państwowej posadce, ale pracowniku naukowym który bada zjawiska a nie tylko je rejestruje.

A co to ma wspólnego z przechowywaniem danych na urządzeniu? Pytanie kontrolne: ilu reżyserów dźwięku zna algorytm Fraunhofera? O kompozytorach nie wspomnę...

W sumie 1H czy będziesz miał serwer WWW wbudowany w ESP (gdzie ESP musi połączyć się z WiFi pana profesora, ciekawe jak, bo pan profesor wcale nie musi być przywiązany do jednego routera) i pan profesor po wpisaniu iluś tam magicznych cyferek z meteorologią nie mających nic wspólnego (np. 192.168.167.166) będzie mógł ściągnąć sobie plik - czy wtyknie to całe ustrojstwo do gniazdka USB i będzie święcie przekonany że to jakiś pendrajw...