Skocz do zawartości
eltomek

Anemometr (wiatromierz) ultradźwiękowy na Atmedze - za mała precyzja, co zrobić?

Pomocna odpowiedź

Witam Szanownych Forumowiczów!

Po pierwsze chciałbym się przywitać jako że jestem tu nowy.

Po drugie mam nadzieję, że mój temat wpisuje się w tematykę tej grupy, pomimo, że to nie robot a stacja meteo. Zdecydowałem się tu napisać, bo macie ogromne doświadczenie w dziedzinie programowania, elektroniki i znacie rozwiązania techniczne, jakich ja jako programista nie znam. Tyle tytułem wstępu, teraz do rzeczy.

Wiem, ze w sieci jest masa artykulow o dalmierzach ultradzwiękowych na Atmegach, natomiast one nie omawiają, a w zasadzie nie dotyczy ich kwestia tak dużej precyzji, jak w przypadku mojego projektu.

Chodzi o urządzenie jak na zdjęciach:

WMT52_210x170.jpg

WS425_210x303.jpg

- 3 przetworniki ultradźwiękowe umieszczone ok 10-15cm od siebie, następnie przeprowadzane są pomiary 1-2-1, 2-3-2, 3-1-3, tylko jeden nadajnik i jeden odbiornik aktywny w danej chwili. I wszystko jasne. Tylko jak zacząłem liczyć, wyszło mi, że Atmega na 16MHz chyba tego nie obsłuży, a ponieważ nie jestem elektronikiem, może jesteście w stanie mi doradzić.

Jeszcze tytułem wstępu powiem jaki jest mój zamysł: generuję timerkiem na Atmedze8 40kHz, startuję timer 16-bitowy z inkrementacją w każdym cyklu zegara i ustawiam przerwanie zewnętrzne, które je zatrzyma i zczyta wartość licznika z rejestru. Odbiornik zbiera pik, wrzuca na wzm.operacyjny, a ten powoduje wygenerowanie zewnętrznego przerwania. W ten sposób mam zebraną ilość taktów zegara, które upłynęły od czasu zaczęcia nadawania piku do pierwszej amplitudy wzbudzającej logiczną jedynkę z odbiornika.

Obliczenia umieściłem pod adresem: https://docs.google.com/spreadsheet/ccc?key=0Ah30mlv7ga40dDFBUWhWcURPMHZ1eGpMRWw2QUstbGc#gid=0

Przy przedstawionych tam parametrach, różnica w prędkości wiatru 0.5m/s (powiedzmy, że to dokładność, która mnie interesuje) równa jest 6 pełnym cyklom zegara. Wydaje mi się, że to trochę mało, biorąc pod uwagę, że błąd 1 taktu w przód lub w tył powoduje 30% błąd pomiaru.

Mogę wziąć szybki procesor, dla ARMa 60MHz taki wiatr to już 25 cykli, ale to ma być tania i przede wszystkim oszczędna stacja pogodowa (zasilana akumulatorem z niewielkim panelem słonecznym).

Druga opcja to zwiększenie odległości pomiędzy przetwornikami. Tak, ale tracę na kompaktowości urządzenia, jeszcze mi się ptactwo dzikie będzie nadziewało na konstrukcję 🙂

Opcja trzecia: zmieniam dziedzinę czasu na coś innego mierzalnego, może napięcie? Wtedy ADC w Atmedze i mam wartość - z tym że też pytanie jak tu z precyzją.

Opcja czwarta - nie używam mikrokontrolera do zmierzenia czasu tylko układu elektronicznego? Jeśli tak to co byście polecili?

Słabo siedzę w temacie elektroniki, jestem programistą i nie znam wielu rozwiązań elektronicznych, które dla Was mogą być oczywiste do takich rozwiązań, dlatego mam prośbę o podpowiedzi w tej sprawie.

A może ma to jednak szansę zadziałać przy 16MHz?

Z góry dziękuję i pozdrawiam,
Tomek

__________

Komentarz dodany przez: Treker

Udostępnij ten post


Link to post
Share on other sites

Jeżeli dobrze zrozumiałem, to startujesz licznik w momencie wysłania PIKu a odbiornik ustawia sygnał przerwania gdy rozpozna PIK.

Twoim problemem (przynajmniej tak sądzisz) jest dokładność.

AVRy mają tryb pracy licznika zwany Capture Mode, który służy do precyzyjnego pomiaru długości impulsu:

The Input Capture Register can capture the Timer/Counter value at a given external (edge triggered) event on either the Input Capture Pin (ICP1)

W ten sposób możesz mierzyć czas trwania impulsu z dokładnością do 1 cyklu zegara mikrokontrolera.

Przyjmując, że prędkość dźwięku w stojącym powietrzu przy temp. 15° to 340,5 m/s i zegarze ATmegi równym 16MHz, to w ciągu 1 cyklu zegara trwającego:

Tz = 1/16MHz = 0,0000000625 s

dźwięk pokona odległość:

odległość pokonana przez dźwięk w czasie 1 cyklu zegara = 0,0000000625 * 340,5 = 0,00002128125 m = 0,02128125 mm

Czy to nie jest wystarczająca dokładność?

Mam nadzieję, że o to chodziło.

Udostępnij ten post


Link to post
Share on other sites
Jeżeli dobrze zrozumiałem, to startujesz licznik w momencie wysłania PIKu a odbiornik ustawia sygnał przerwania gdy rozpozna PIK.

Twoim problemem (przynajmniej tak sądzisz) jest dokładność.

AVRy mają tryb pracy licznika zwany Capture Mode, który służy do precyzyjnego pomiaru długości impulsu:

The Input Capture Register can capture the Timer/Counter value at a given external (edge triggered) event on either the Input Capture Pin (ICP1)

W ten sposób możesz mierzyć czas trwania impulsu z dokładnością do 1 cyklu zegara mikrokontrolera.

Dokładnie z tego mechanizmu chcę skorzystać. Timer1 na Atmedze8 posiada właśnie tą funkcjonalność. Nie jestem jednak pewien, czy rzeczywiście od momentu ustawienia logicznej jedynki na wejście na którym mam ustawione przerwanie do zatrzymania i zebrania wartości licznika minie jeden cykl. W ogóle to mogłoby minąć i 10, ale warunkiem jest, żeby ten czas był stały. Ale to muszę już chyba empirycznie określić.

Przyjmując, że prędkość dźwięku w stojącym powietrzu przy temp. 15° to 340,5 m/s i zegarze ATmegi równym 16MHz, to w ciągu 1 cyklu zegara trwającego:

Tz = 1/16MHz = 0,0000000625 s

dźwięk pokona odległość:

odległość pokonana przez dźwięk w czasie 1 cyklu zegara = 0,0000000625 * 340,5 = 0,00002128125 m = 0,02128125 mm

Czy to nie jest wystarczająca dokładność?

Mam nadzieję, że o to chodziło.

Problemem nie jest czas drogi piku od nadajnika do odbiornika, tylko delta w przypadku gdy wiatr będzie wiał. Jeśli prędkość dźwięku bez wiatru to 340,5 m/s, to w przypadku powiewu 0,5 m/s od nadajnika do odbiornika jest to tylko 341 m/s, a więc pik będzie odebrany o 430ns szybciej niż gdyby ten wiatr nie wiał. A 430ns to bardzo krótko - tylko 6 pełnych cykli zegara. No ale może rzeczywiście to wystarczy?

Udostępnij ten post


Link to post
Share on other sites
Dokładnie z tego mechanizmu chcę skorzystać. Timer1 na Atmedze8 posiada właśnie tą funkcjonalność. Nie jestem jednak pewien, czy rzeczywiście od momentu ustawienia logicznej jedynki na wejście na którym mam ustawione przerwanie do zatrzymania i zebrania wartości licznika minie jeden cykl. W ogóle to mogłoby minąć i 10, ale warunkiem jest, żeby ten czas był stały. Ale to muszę już chyba empirycznie określić.

Tryb Capture mode zapamiętuje stan licznika w rejestrzez ICR1, w momencie wystąpienia sygnału na pinie ICP1. Kiedy go odczytasz ICR1 to już Twój problem. Opóźnienie odczytu nie wpływa na pomiar. Dlatego problem którego się obawiasz nie istnieje. Poczytaj o tym trybie w datasheet.

... to w przypadku powiewu 0,5 m/s od nadajnika do odbiornika jest to tylko 341 m/s, a więc pik będzie odebrany o 430ns szybciej niż gdyby ten wiatr nie wiał. A 430ns to bardzo krótko - tylko 6 pełnych cykli zegara. No ale może rzeczywiście to wystarczy?

Jak to policzyłeś? Rozpisz tutaj.

Udostępnij ten post


Link to post
Share on other sites

Jak miło, że na Forum pojawiają się tak ciekawe pytania. Miejmy tylko nadzieję, że Odpowiedzialne Osoby 😉 (Pozdrawiam) nie uznają tego tematu za zupełnie mijający się z tematyką i nie zadecydują o umieszczeniu wątku w ostatniej, najniższej kategorii na stronie głównej..

Przede wszystkim jeśli już chciałeś jakoś wykorzystać zasoby procesora to powinieneś, tak jak to sugeruje dondu zaprząc do pracy specjalne, dedykowane wyjścia i wejścia timerów. Jedne generują przebieg z dokładnością do jednego zegara a drugie analizują i pozycjonują w czasie zbocza sygnału wejściowego z taką samą dokładnością. Jeśli podstawą czasu dla obu (we i wy) będzie ten sam timer pracujący z maksymalną szybkością np. 16MHz to masz generator i analizator pracujący z taką właśnie bezwzględną rozdzielczością. Przerwanie już samo z siebie, z definicji ma nieoznaczoność wynikającą z braku synchronizacji z cyklem rozkazowym procesora. Jeżeli różne instrukcje wykonują się w jednym lub dwóch cyklach maszynowych (zegarach) a przerwanie zaczyna być obsługiwane po zakończeniu aktualnie wykonywanej instrukcji, to już mamy ±1 zegar. Ponadto w nietrywialnym programie są pewnie inne przerwania (jakaś komunikacja po UART, liczenie czasu rzeczywistego itp) które z uwagi na jedopoziomowy system przerwań AVRów wprowadzają daleko większe błędy w "przerwaniowym" pomiarze czasu.

Niestety jak sam słusznie zauważyłeś nawet maksymalna rozdzielczość tak zbudowanego analizatora tu nie wystarczy. Można by oczywiście zrobić pomiar, np. na prostym liczniku TTL taktowanym zegarem np. 100MHz i wtedy rozdzielczość 10ns - to już coś. Taki układ zrobiłbyś za kilkanaście złotych. Można zrobić to metodami mieszanymi, np. razem z początkiem paczki nadawanej generujesz (choćby procesorem - znikną błędy kalibracji drugiego źródła czasu) impuls wzorcowy o stałej długości takiej, by zakończył się zawsze tuż przed najszybszym impulsem odebranym. Prostą bramką odejmujesz oba impulsy (od czasu opóźnienia odejmujesz wzorcowy) i dostajesz wynik w postaci impulsu, którego długość zmienia się już nie o 1% tylko np. o 500% w całym zakresie pomiarowym. Tylko co z tego, skoro cały impuls nadal nie da się zmierzyć zegarem procesora? Tutaj możesz np. ładować kondensator. Proste źródło prądowe (lub nawet nie, wystarczy opornik - niech procesor też ma coś do policzenia) ładuje ten rozładowany wcześniej przed każdym cyklem kondensator. Im do wyższego napięcia naładuje - tym dłuższy impuls. Proste przetwarzanie czasu na napięcie, znane w elektronice "od zawsze". Potem już spokojnie mierzysz "zatrzymane" napięcie przetwornikiem procesora i przeliczasz, dalej to już matematyka.

Niestety muszę Cię zmartwić - jest jeszcze gorzej niż myślisz. Otóż przetworniki ultradźwiękowe nie są prostymi urządzeniami przetwarzającymi otrzymane napięcie na ciśnienie akustyczne jak, dajmy na to (w tym samym zakresie czasów) diody LED w dziedzinie światła. Są elementami rezonansowymi a jeśli tak, to mają podobnie jak każdy ukłąd drgający swoje dobroci, tłumienia, pasma i opóźnienia. Czyli: zapodając na nadajnik falę prostokątną o częstotliwości np. 40kHz, dostajesz falę akustyczną która narasta dość powoli i tak samo wolno zanika po ustaniu pobudzenia - to jest Twój impuls sondujący. Takie coś leci przez powietrze, dodaje się do szumów otoczenia (w tym paśmie też są, szczególnie w miastach) a następnie dociera do odbiornika. Ten ma również swoją dobroć (im większą tym lepiej - bo nie łapie śmieci ale tym gorzej, bo wolniej się "rozbuja") która powoduje kolejne "wygładzenie" impulsu - trochę jak funkcje fade-in i fade-out w edycji audio, tylko tysiące razy szybciej. A na końcu stoi Twój układ decyzyjny który ma dać dwustanową odpowiedź na proste pytanie: kiedy przyszło czoło impulsu nadanego? Czy wiedząc to wszysko jest ono rzeczywiście proste? Tak naprawdę, powinno się użyć bardzo szybkiego procesora DSP albo chociaż szybkiego przetwornika A/D, spróbkować przebieg odebrany z częstotliwością np. 200kHz i przepuścić zebrane dane przez zestaw filtrów dopasowanych, funkcji analizujących kształt i detektorów energii po to, by jednoznacznie znaleźć jakiś punkt, który będzie dla różnych kształtów impulsów jednoznacznie mówił o czasie dojścia/powrotu.

W każdym razie na tak krótkiej bazie pomiarowej będziesz miał trochę zabawy - i to jest fajne 🙂 Kibicuję.

Udostępnij ten post


Link to post
Share on other sites

Temat przywróciłem na prośbę użytkowników.

Udostępnij ten post


Link to post
Share on other sites

Tak jak już pisałem na PW, ja bym do tego projektu zaprzęgnął jednak ARMa. W stm32 72MHz taktowanie, przetwornik ADC z rozdzielczością 1MSPS i wielokanałowe, rozbudowane timery na pewno pozwolą sobie poradzić lepiej niż atmega, a cena ta sama. Mógł byś na przykład synchronizować start ADC i timera i kolejne próbki pobierać do bufora mieszczącego nawet kilka okresów sygnału. Największym wyzwaniem może być odpowiednia obróbka takich wyników w czasie rzeczywistym, ale równie dobrze możesz transmitować suche dane do komputera i tam się zajmować obróbką.

A co do metody generowania sygnału to może dobrze by było dla polepszenia parametrów spróbować użyć po kolei kilku różnych częstotliwości albo sygnału typu chirp. Tego typu techniki sprawdzają się w sonarach do wykrywania łodzi podwodnych, ale tutaj może też by dały radę.

Udostępnij ten post


Link to post
Share on other sites

Tu nie jest potrzebna obróbka w czasie rzeczywistym, próbki zbierasz do bufora a potem możesz zużyć 100 razy więcej czasu na ich przetwarzanie - i tak będzie wystarczająco szybko dla tej aplikacji. Natomiast szybki przetwornik jest dużą przewagą.

Sygnały chirp stosowane są w celu podniesienia mocy w impulsie. Jeśli nie masz (lub nie chcesz budować) wzmacniacza końcowego o wystarczającej mocy, przepuszczasz przez niego taki "rozwleczony" sygnał a dopiero potem, w układzie dopasowania z liniową fazą "zagęszczasz" energię rozłożoną do tej pory w czasie do jednego krótkiego strzału. To nie jest ten przypadek bo ani nie ma problemu z mocą wyjściową, ani nie zrobisz ultradźwiękowego falowodu z fazą liniowo zależną od częstotliwości ani też przetwornik rezonansowy do tego się kompletnie nie nadaje.

Zrobiłem kilka przymiarek do układu przetwarzania czas-napięcie i na trzech tranzystorach wspartych ATmegą (wyjściami OCx i przetwornikiem A/C) można spokojnie zrobić 10-bitowy pomiar długości impulsów 1-30us. Pozostaje tylko zbudowanie układu decyzyjnego.

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Gość
Napisz odpowiedź...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


×
×
  • Utwórz nowe...