Parametry środowiskowe takie jak temperatura, ciśnienie atmosferyczne czy wilgotność powietrza są niewątpliwie najczęściej mierzonymi wielkościami. Co roku na świecie powstaje masa domowych stacji pogodowych zdobiących okolice okien naszych domów oraz mieszkań.
Podobnie jak przy wyświetlaczu LCD, sprawdzę ile czasu zajmuje obsługa przez MCU tych popularnych czujników. Jako bazę pod bibliotekę obsługującą te układy wykorzystałem dostępne w internecie biblioteki Bosha oraz Adafruit dla Arduino.
Podziałam natomiast na popularnych, chińskich modułach. Są one bardzo tanie i mają położone potrzebne rezystory. Można też niektóre zasilić z 5 V dzięki położonemu stabilizatorowi. Pamiętaj jednak, że komunikacja nadal jest w domenie 3,3 V, choć mimo tego działa ona też na Arduino. Moją bazą badawczą będzie Nucleo64-F401RE, a czasy działania sprawdzę dla taktowania magistrali I²C 100 kHz i 400 kHz. Do dzieła!
BMP180
Pacjent o wymiarach 3,6 x 3,8 x 0,93 mm zdolny jest do pomiaru temperatury oraz ciśnienia atmosferycznego.
Temperaturę odczytujemy w rozdzielczości 16 bitowej, ale nie jest ona podana wprost. Należy ją przeliczyć według algorytmu widniejącego w nocie katalogowej. Wynik uzyskujemy z rozdzielczością 0.1 °C, przy czym dokładność pomiary przez czujnik wynosi ±0.5 °C dla temperatury pokojowej, oraz ±1 °C dla całego zakresu pomiarowego(0÷65 °C).
Informacja o mierzonym ciśnieniu zajmuje się od 16 do 19 bitów i zależy ona od wybranego trybu pomiaru, który ma istotny wpływ na czas konwersji. Podobnie jak w przypadku temperatury, należy przeliczyć według algorytmu uzyskaną wartość z czujnika. Dopiero po przeliczeniu otrzymujemy właściwą wielkość która nas interesuje. Wynik dostajemy z precyzją 0.01 hPa Dokładność bezwzględna czujnika ciśnienia to typowo ±1 hPa w całym zakresie pomiaru(300÷1100 hPa). Dokładność względna jest na poziomie ±0.12 hPa.
W nocie znajdziemy również ciekawe informacje na temat poboru prądu dla samplowania 1 HZ w zależności od wybranego trybu. Widoczny tryb Advanced res. mode nie jest dostępny tak o po prostu z poziomu np. inicjalizacji. Z tego względu nie będę go liczył jako tryb dokładność/pobór 🙂
Są to dane uśrednione. Sam “pik” przy konwersji ma “aż” 650 µA, a w stanie spoczynku czujnik zadowoli się jedynie 0.1 mikroampera. Wszystkie te wartości pozwalają na wykorzystanie tego typu czujników w urządzeniach bateryjnych. Ekstra 🙂
Resztę ciekawych informacji znajdziesz w dokumentacji. Zachęcam do poczytania – to w cale nie boli, a ile można się dowiedzieć/nauczyć.
Schemat połączenia do Nucleo F401RE oraz konfiguracji STM32CubeMX jest prosty. Wykorzystam pierwszy interfejs I²C. Na module GY-68 zamontowane już są rezystory podciągające linie I²C, więc mam je z głowy.
W pierwszej kolejności sprawdzę działanie czujnika przy prędkości taktowania zegara I²C 100 kHz. Czujnik ten obsługuję jedynie tryb wymuszonej konwersji, co wiąże się z potrzebą oczekiwania na zakończenie pomiaru. Tworząc swoją bibliotekę zauważyłem, że taki Adafruit na sztywno ustawił czasy oczekiwania na zakończenie konwersji zwykłym, chamskim delay’em. Jego wartość wynosi maksymalny, deklarowany czas konwersji zawarty w dokumentacji. Nieładnie… Ale ok… sprawdziłem ten wariant w trybie konwersji Standard.
Czas konwersji i przeliczenia temperatury według algorytmu to 5.69 ms. Konwersja ciśnienia zajmuje znacznie więcej czasu – jest w niej również wszyta konwersja temperatury, która jest potrzebna do wyliczenia ciśnienia. Po co więc mierzyć temperaturę osobno? Po pierwsze – bo czujnik to umożliwia. Po drugie – a może się kiedyś przyda sama temperatura?
Dla zegara I²C 400 kHz wygląda to zdeczko lepiej lecz nadal nie podobają mi się te długie, puste czasy oczekiwania.
A może da się szybciej? Po co wrzucać tutaj sztuczne oczekiwanie jak rejestry BMP180 umożliwiają podgląd stanu konwersji? Let’s check!
Lepiej? Pewnie, że tak! Zapamiętaj – życie jest zbyt krótkie na używania delay’a. Przeprowadziłem serię testów dla wszystkich trybów konwersji ciśnienia. Wyniki znajdują się w tabelach.
Czasy konwersji temperatury
100 kHz (delay) | 400 kHz (delay) | 100 kHz | 400 kHz | |
Wszystkie tryby | 5,69 ms | 5,14 ms | 4,31 ms | 3,47 ms |
Czasy konwersji temperatury i ciśnienia
100 kHz (delay) | 400 kHz (delay) | 100 kHz | 400 kHz | |
Ultra Low Power | 11,79 ms | 10,38 ms | 9,03 ms | 7,04 ms |
Standard | 14,76 ms | 13,35 ms | 11 ms | 9,03 ms |
Highres | 20,72 ms | 19,26 ms | 14,94 ms | 12,9 ms |
Ultrahighres | 32,6 ms | 31,18 ms | 22,82 ms | 20,75 ms |
Z miejsca wyrzuciłbym z użytku wersje ze stałym delay’em. Są one wyraźnie wolniejsze niż odpytywanie czujnika czy już zakończył konwersję. Przy rzadkich odczytach z czujnika na ogół czeka się na zakończony pomiar, więc warto skrócić ten czas o kilka milisekund. Różnice między taktowaniem 100 kHz a 400 kHz są mniej więcej stałe i wynoszą około 2 ms. Wynika z tego to, że czas konwersji nie zależy od prędkości komunikacji, ale przy tej ilości danych do transferowania coś tam da się urwać. Warto używać 400 kHz jeśli mikrokontroler oraz pozostałe układy na magistrali I²C na to pozwalają. BMP180 obsługuje maksymalnie I²C w standardzie high-speed, czyli 3.4 Mbit/s.
Wysokość n.p.m
Dokumentacja BMP180 zawiera ciekawostkę w postaci określania wysokości nad poziomem można na podstawie mierzonego ciśnienia.
Wzór ten wymaga od nas podania parametru p0 – ciśnienie panujące na poziomie morza wyrażoną w Pa. Wikipedia definiuje je jako 101325 Pa i takiej wartości użyję. Niestety obliczenia trochę się mylą i wychodzi 29 metrów p.p.m co dla Gdyni jest nieprawdą. Widzę morze z okna i jestem pewien, że jestem ponad nim 🙂 Wpisując aktualne ciśnienie podane w internetach(1018 hPa) wychodzi 10 m.n.p.m co jest bliższe prawdy. Jak widać bez aktualnej wiedzy o panującym ciśnieniu na poziomie morza, możemy sobie użyć tych wyliczeń jedynie jako ciekawostki.
Nie wykluczam tez tego, że nie potrafię korzystać z tej funkcji 😀 Może ktoś mnie oświeci?
W kolejnej części przyglądam się młodszemu bratu BMP180, czyli BMP280, a także jego rozszerzoną wersją BME280.
Jeżeli czujnik Ci się spodobał, możesz je nabyć u mnie w skepie.
Kompletny kod z tego cyklu wpisów znajduje się na moim GitHubie: link
Na koniec tego wpisu zachęcam do dyskusji w komentarzach na temat obsługi wyświetlacza BMP180 na STM32. Uważasz, że popełniłem gdzieś błąd? Masz jakiś ciekawy pomysł co można ulepszyć? Podziel się tym w komentarzu! Pamiętaj, że dyskusja ma być kulturalna i zgodna z zasadami języka polskiego.
3 komentarze
Przemek · 19/11/2024 o 17:31
Co więcej w Lotnictwie uzywamy między innymi QNH czyli cośnienia sprowadzonego do poziomu morza i Można je sobie sprawdzić w Awiacja IMGW w komunikacie METAR dla danego lotniska w okolicy, na końcu zaczyna się od “Q” to ciśnienie ustawiamy w wysokościomierzu aby uzyskać wysokość AMSL i jest to dokładniejsze niż użycie ciśnienia standardowego QNE 1013.25. No i oczywiście możemy użyć pierwszego odczytu ciśnienia na poziomie na którym jesteśmy aktualnie (QFE) po uruchomieniu czujnika jako referencji do dalszych obliczeń i na tej zasadzie wyliczać wysokosć AGL czyli naszą warstwą startową staje się ziemia pod nogami a nie poziom morza. Do lokalnych lotów na paralotni często użyteczniejsze. Właśnie robię taki wysokościomierz oparty na BMP180. 🙂
Krzysiek · 31/07/2020 o 21:30
Ja tylko w kwestii ciśnienia. 1013,25hPa to ciśnienie na średnim poziomie morza (Mean Sea Level) dla tzw atmosfery standardowej ISA. Prognoza pogody podaje wartość ciśnienia “zredukowaną” do średniego poziomu morza na podstawie wysokości punktu pomiaru, aktualnej temperatury etc. Być może średni poziom morza dla Gdyni jest niżej/wyżej niż to co widzisz za oknem a temperatura inna niż dla atmosfery standardowej (15 stC) więc stąd moja wyniknąć drobne odchylenia
Mateusz Salamon · 01/08/2020 o 16:42
Mądrego to jednak dobrze jest posłuchać 🙂 Dzięki za wyjaśnienie!