pgforum.pl

Cześć,

Dłubię przy projekcie taniej pikawki. W większości tego typu urządzeń generowany dźwięk jest zależny od zmiany wysokości w czasie. Problem w tym, że obliczanie wysokości na podstawie ciśnienia jest bardzo kosztowne (obliczeniowo). Wymyśliłem sobie, że dźwięk byłby generowany nie na podstawie zmian wysokości, ale na podstawie zmiany ciśnienia w czasie. Ale jak wiadomo, wielkość stopnia barycznego zmienia się wraz z wysokością. Początkowo miałem zamiar zastosować przybliżenie (np. 0-500 m - st. baryczny 8m, 500-1500m - 12m, 1500-3000m - 16m).
Ale się zastanawiam czy może nie byłoby właściwe przypisanie na stałe wielkości stopnia barycznego. Co się z tym wiążę, wraz z wysokością wario byłoby coraz bardziej czułe na zmiany wysokości, ale może to wcale nie byłaby wada? Niestety, dopiero zaczynam latać i nie mam na razie możliwości przetestować swojej gdybaniny w powietrzu. Co o tym myślicie?

Chyba lepiej byłoby odwrotnie. Duża gradacja nad gruntem, a im wyżej tym mniejsza. A przeskakiwanie z bloku do bloku nie będzie w jakiś sposób odczuwalne?

Ale nie jest tak, że im wyżej, tym noszenie staje się słabsze i co za tym idzie, lepiej byłoby gdyby wario było bardziej czułe?
A co do aproksymacji liniowej krzywej zmiany ciśnienia w funkcji wysokości, to bloków mogłoby być więcej niż trzy.

Duża czułość i zmiany dźwięków jest nam potrzebne nisko gdy szukamy noszeń i każda zmiana powietrza powinna być podpowiedzią. Wysoko to nas interesuje czy nie wpadamy z komina i czy noszenie się nie skończyło. Tam już nie potrzebna jest subtelność.

No to muszę przemyśleć zagadnienie
Dzięki

Witam.
Zerknij sobie na czujnik cisnienia BMP085, zaoszczedzisz troche mocy obliczeniowej.

R0bby pisze:Ale nie jest tak, że im wyżej, tym noszenie staje się słabsze i co za tym idzie, lepiej byłoby gdyby wario było bardziej czułe?
A co do aproksymacji liniowej krzywej zmiany ciśnienia w funkcji wysokości, to bloków mogłoby być więcej niż trzy.

Jest wręcz przeciwnie Im wyżej tym komin jest (bywa) mocniejszy aż do podstawy chmury. Wynika to z tego, że wilgotne powietrze bąbla, przemieszczając się do góry wolniej traci temperaturę niż suche powietrze wokół niego. Zatem - różnica temperatur rośnie pomimo, że obie temperatury (bąbla i powietrza wokół) spadają. Aż do osiągnięcia przez bąbel temperatury punktu rosy - wtedy wilgotność się wyrównuje (powstaje widoczna chmura).

Komin moze przyspieszac, lub zwalniac. Jest to zalezene od gradientu temepratury w danym dniu. Niekiedy tak zwalnia, ze nie da sie doleciec do podstawy (nawet szybowcem) poniewaz predkosc komina spada ponizej minimalnego opadania w krazeniu

zolty27 pisze:Witam.
Zerknij sobie na czujnik cisnienia BMP085, zaoszczedzisz troche mocy obliczeniowej.

Pracuję nad nowszą wersją tego czujnika BMP180 Bez względu na użyty czujnik barometryczny, obliczenie wysokości wymaga wykonania działań, których małe mikrokontrolery nie lubią https://pl.wikipedia.org/wiki/Wz%C3%B3r_barometryczny

R0bby pisze:Bez względu na użyty czujnik barometryczny, obliczenie wysokości wymaga wykonania działań, których małe mikrokontrolery nie lubią

Kumpel w le BipBip używa TI MSP430 i spokojnie daje radę. Tyle że nie pamiętam czy liczy wysokość, bo też nie wiem czy taka potrzeba jest. Kod bipbip'a jest dostępny open source na github'ie. Zawsze możesz podpatrzeć co tam napełczono
https://github.com/lebipbip/le-BipBip

Co do czujnika ciśnienia, on odrzucił wszystkie BMP na etapie prototypu, z powodu niewystarczającej czułości i dużej ilości szumów. Obecnie najdroższą częścią BipBipa jest tenże czujnik ciśnienia. Nie pamiętam co to dokładnie jest, ale zdaje się, że MS5607S (trzebaby w kod popatrzeć).

Pozdro i miłej zabawy

a może czujnik MS5611? coś tam dłubię zimowymi wieczorami z tym czujnikiem i atmegą, właściwie to nie spotkałem się z problemem wydajności obliczeń

Czy MS5611 czy BMP180 dla obliczeń nie ma znaczenia. Żaden z tych czujników nie podaje wysokości tylko trzeba ją obliczyć. Ms5611 faktycznie jest dokładniejszy, ale też 7 razy droższy, a chcę zrobić małą, tanią pikawkę. Jako uC planuję użyć ATTINY85. Koszt całości będzie wynosił ok. 2.5$

Z tymi obliczeniami to nie jest tak, że mikrokontroler nie da rady, bo da. Ale zabierają dużo czasu. W urządzeniach mobilnych priorytetem jest czas pracy na bateriach. Zużycie energii liniowo zależy od częstotliwości taktowania kontrolera. Ograniczając ilość obliczeń można obniżyć częstotliwość pracy, a co za tym idzie, wydłużyć czas pracy.

cathal - dzięki za link. Z przyjemnością się przyjrzę francuzowi

R0bby pisze:.......

No to troche pojechalem z tym postem, ale wczesniej nie pisales zadnych szczegolow na temat budowy varia. Osobiscie bym pominal wspolczyniik temperatury w obliczeniu wysokosci, ale robiac te obliczenia z wykorzystaniem maszyny stanow Attiny85 moze dac rade.

R0bby pisze:Czy MS5611 czy BMP180 dla obliczeń nie ma znaczenia. Żaden z tych czujników nie podaje wysokości tylko trzeba ją obliczyć. Ms5611 faktycznie jest dokładniejszy, ale też 7 razy droższy, a chcę zrobić małą, tanią pikawkę. Jako uC planuję użyć ATTINY85. Koszt całości będzie wynosił ok. 2.5$

faktycznie, nie zwróciłem uwagi na cenę BMP. Podpowiedz proszę jak rozwiązałeś elektronicznie wzmacniacz dźwięku i jakiego używasz głośnika ? ja nie jestem elektronikiem i szukam trochę po omacku

Nie używam wzmacniacza. Bezpośrednio z uC podłączam malutki przetwornik piezoelektryczny z jakiejś zabawki. O średnicy groszówki i <> 7mm wysokości. Gdybyś kupował to niektóre mają wbudowany generator (można bezpośrednio podłączyć do prądu stałego) i się nie nadają, bo mają stałą częstotliwość brzęczenia. Te bez generatora na allegro po 1-3 zł.

żeby takie piezo piszczało odpowiednio głośno dobrze jest je zasilić napięciem > 9V, im więcej tym głośniej. Jeżeli na pokładzie jest dostępne napięcie +5V to najlepiej podłączyć je pod mostek H ( http://weirdscience.eu/images/7/7985726 ... 6942e.jpeg ), który pozwoli na zmianę polaryzacji napięcia podawanego na ten brzęczyk. Ponieważ raz będzie +5V względem masy a potem -5V względem masy, to na zaciskach piezo sumarycznie wyjdzie 10V. Do uzyskiwania wyższych napięć pewnie potrzeba będzie przetwornica DC/DC

Mostkiem steruje się bardzo łatwo. Masa do masy, Vcc do Vcc a w mikrokontrolerze wystawiamy stan wysoki raz do DIR1 a raz do DIR2. ATTiny pewnie nie ma timera z generowaniem PWM ale np. w mikrokontrolerach STM32 robi się to w zasadzie bezprzerwaniowo. W rejestrach ARR i PSC ustawia się częstotliwość a w CCR ustawia się współczynnik wypełnienia, który powinien wynosić 50%. Reszta odbywa się w pełni sprzętowo bez udziału głównej części mikrokontrolera, czyli ALU (jednostka arytmetyczno logiczna)

Inna rzecz w tym, że otrzymana jakość audio pozostawia i tak dużo do życzenia. Niestety ale stare brauingery o przyjemnym dla ucha pipczeniu były w pełni analogowe. Czujnik ciśnienia był analogowy, sygnał szedł potem na kilkustopniowy, niskoszumny wzmacniacz pomiarowy a na koniec na wzmacniacz całkujący, który był co stały czas zerowany. Średnia wartość napięcia była wprost proporcjonalna do prędkości pionowej, a polaryzacja tego napięcia wyznaczała kierunek opadanie/wznoszenie. Takie coś było używane do sterowania (również analogowym generatorem) brzęczenia. Mikrokontroler zajmował się jedynie obsługą wyświetlacza i przeliczał napięcie z czujnika na wysokość. Do wariometru miał jedynie tyle, że sterowała prędkością pulsowania tonu. Teraz nikt się już w to nie bawi. Bierze się jakiś uC i cyfrowy czujnik, bo łatwo i tanio można uzyskać porządny efekt. Niestety cierpi na tym brzmienie.

Tym, którzy chcieli by budować własne wario polecam przysiąść nad projektem płytki drukowanej i porządnym odsprzęgnięciem czujnika. Ja miałem MS5611 i ta pchełka jest cholernie czuła na zakłócenia od napięcia zasilacza. Pojemność ~10nF na zasilaczu jak najbliżej samego czujnika + ewentualnie dławik 4.7uH. Czujnik oblać dookoła masą. Nie prowadzić innych ścieżek w najbliższej okolicy. Można też bawić się w przeróżne filtry dolnoprzepustowe, pamiętając jednak, że zawsze opóźniają one sygnał, przez co wskazanie waria też będzie opóźnione

Na razie testuję vario przy zasilaniu 5V, a nawet mniej, przy zasilaniu ogniwem Li-ION. W domu wydaje się całkiem głośno i żona w pokoju piętro wyżej się drze, że znowu czymś piszczę A na ile to będzie słyszalne w powietrzu, to nie wiem. Gdybym miał potrzebę podniesienia napięcia to użyłbym pompy ładunkowej - przykład takiej jest w linku leBipBip, w pliku lebipbip.c.
Mam jednak nadzieję, że głośność samego buzzera sterowanego z uC będzie wystarczająca. Nie mam zamiaru bawić się w projektowanie druku, trawienie, lutowanie - po prostu zlutuję moduł z ATTINY z modułem z BMP180 (lub MS5061). A jeszcze lutować sam czujnik to dla mnie już w ogóle abstrakcja. Mam z zębach większe plomby niż ten czujnik

Jakość dźwięku nie powala i w takiej konfiguracji cudów trudno oczekiwać. Raz że piezo brzęczyki nie są projektowane dla audiofilów, dwa że sterowany jest ordynarnym prostokątem, bez choćby filtra RC.

ATTINY posiada timer z PWM, a nawet dwa, ale są mi potrzebne w programie.

Na STM32 buduję takie ciut fajniejsze vario, ale jeszcze trochę czasu mi zajmie, zanim coś z tego będzie W stosunku do AVR, ogarnąć ten procesor to szok.

Aha. Głośność można oczywiście regulować. Albo zmieniając współczynnik wypełnienia w tym H-mostku, da się też chyba regulować wypełnieniem w tym powielaczu napięcia ale to trzeba by sprawdzić. W pisaniu kodu unikaj tylko takich rozwiązań jak to:

które trzymają mikrokontroler w jednym i tym samym miejscu. Lepiej pisać kod w oparciu o maszynę stanów i cyklicznie wywoływać jakiś handler. Na ARM może i to bez znaczenia ale jak zaczniesz na poważnie bawić się na STM32, które na dzień dobry mają zegary rzędu 72MHz i więcej, to docenisz ten fakt.

Zresztą same STM32 nie są takie straszne jak się wydają. Jest to bardzo fajny procek z ogromnymi możliwościami. Fakt, Reference Manual zajmujący ponad 1100 stron przeraża ale nie musisz wszystkiego używać od razu. Na start najważniejsze żebyś zrozumiał całą architekturę generatorów sygnału zegarowego i wewnętrznych szyn taktujących, potem jest już z górki. No i dobrze zacząć pisać obiektowo w C++ bo przynosi to kilka naprawdę fajnych rzeczy..

Niestety, na chwilę obecną nie przewiduję regulacji głośności. Tak jak wspominałeś, regulację głośności łatwo jest zrealizować w PWM. Szkopuł w tym, że źle się w tym trybie steruje częstotliwością przebiegu. Przynajmniej w AVR.

Oczywiście nie stosuję delayów i innych blokujących instrukcji - to podstawa Dlatego do generacji dźwięku potrzebuję aż dwóch timerów.

A co do samej obiektowości C++ w pisaniu programów dla uC to mam ambiwalentne odczucia. Z jednej strony ułatwiają pisanie, ale z drugiej powodują, że kod wynikowy jest mniej efektywny. Doskonale to widać gdy koduję pod Arduino dla AVR, a potem ten sam program realizuję w czystym C. Program w C zawsze będzie mniejszy i szybszy. W STM32 problem przestaje być tak istotny, bo duża wydajność uC pozwala zrekompensować nie optymalny kod. Poza tym, STM32 projektowany był chyba z założeniem obiektowego traktowania rejestrów.

Ja w zasadzie od razu zacząłem od STM32 także poza specyficznymi zastosowaniami, takimi jak DSP nie widziałem żadnej różnicy pomiędzy C a C++ Zacząłem jednak widzieć różnicę (od PC) jak w kodzie pojawiła mi się dynamiczna alokacja pamięci i operatory takie jak new i delete, czy bardziej klasycznie funkcję malloc, free i realloc. I tu ostrzeżenie, że niestety ale bez RTOS i dobrego zarządzania pamięcią nie ma co nawet myśleć o dynamicznych obiektach. Choćbyś rozciągnął stertę do granic absurdu, to bardzo szybko dostaniesz poważne wycieki pamięci a operator new będzie zwracał albo null albo jakieś losowe śmieciowe adresy nie mające odzwierciedlenia na fizycznych peryferiach. Oczywiście takie zabawy kończą się bardzo szybko wyrzuceniem niemaskowalnego przerwania HardFault i wtedy uratować może albo watchdog albo wrzucenie do handlera wywołania funkcji NVIC_SystemReset();

Czyli jak widzisz niestety odpadają zabawy chociażby z STL. Nie masz już kolejek, wektorów, stringów i innych przydatnych rzeczy, z przydatniejszych pozostaje oczywiście obiektowość i np. szablony klas/funkcji. Używanie C++ na mikrokontrolerach jest taką trochę orką. Z jednej strony masz do dyspozycji część funkcjonalności programowania obiektowego i odsuwasz się od sprzętu ale z drugiej strony musisz pamiętać, że ten sprzęt cały czas tam jest. To nie jest Java gdzie garbage collector i cudowne obiekty same wszystko zrobią Tutaj trzeba pamiętać, że nie dopisanie null terminatora zakończy się jazdą po adresach aż do wywalenia HardFault a ciągi znaków porównuje się przez strcmp a nie operator ==. Problemem jest też piekiełko wzajemnych wywłaszczeń przerwań i odpowiednie ustawienie ich priorytetów..... Aha i nie ma obsługi wyjątków także throw Reserve(); niestety nie pomoże

Rejestry w STM32 są traktowane jak każde inne i nie mają tutaj nic do obiektów Fakt, język assemblera Cortex-M3 jest przeznaczony dla assemblera Cortex-M3 a nie dla ludzi, to nie czasy 80C51 gdzie ręcznie klepało się mov, djnz, czy też mul. Rejestry pozostały jednak rejestrami i teraz są w pełni 32bitowe i jest ich 13 (tych ogólnego przeznaczenia)

Jak byś miał jakieś problemy z kodem albo sprzętem to pisz tutaj śmiało, coś poradzimy.