"Elektroniczny patefon" na bazie czujnika odległości HC-SR04

[Adder]

Generalnie to wygląda tak, jakby rzeczywista częstotliwość wynosiła 100x więcej i zapisywał się tylko fragment danych nie np. z 1 sekundy, ale 1/100 sekundy. 

Przy tych 40Hz te schodki to może być nawet ruch membrany. Bredzę?

100/40=2,5

W obrazie fali 40Hz obraz fali 100Hz powinien mieścić się 2,5 raza w tym samym czasie. No i tak jest. Gubię dane? Serial?

Ale jakim cudem mógłbym robić >7kHz próbek!? Nic już zupełnie nie rozumiem. Totalnie się zakręciłem. 

Edytowano Marzec 4, 2021 przez Adder

[marek1707]

Czy jeśli kiedyś policzysz, narysujesz i sklecisz z bambusa i prześcieradeł powiedzmy nowy szybowiec, to następnego dnia z rana wleziesz na dach najwyższego budynku w okolicy i skoczysz? No chyba raczej nie, prawda? Tui jest tak samo. Kolejne kroki wykonujesz po upewnieniu się, że wszystkie poprzednie działają, że panujesz nad tym i znasz warunki brzegowe stosowania. Zanim włączysz nową płytkę musisz być pewnien, że główny zasilacz jest OK, potem że lokalne POL są sprawne, potem że ruszył oscylator procesora i sygnał RESET zakończył się poprawnie, potem że złącze debug działa i masz kontakt z programatorem, potem że najprostszy program mrugania pinem portu działa itd itp. To samo z programem. Przecieżnie chyba nie odpalasz nastukanych na pusto 10000 linii kodu z nadzieją, że wszystko ruszy i o 5 rano możesz iść spać.

Jak zatem wyglądają wyniki z oglądania nieruchomego obiektu? Jak wygląda szum tego pomiaru? Statystyka? Czy w ogóle wyniki uzyskane z pomiaru długości impulsu na wejściu ICP1 jakkolwiek odpowiadają wynikom zmierzonym w tej samej konfiguracji sprzętu i otoczenia np. z użyciem popularnej funkcji pulsein()? Oscyloskop? Od biedy tani analizator/logger cyfrowy? Czy Twoje Arduino dobrze mierzy impulsy o znanej długości? Czy ta zmierzona długość liczona w us odpowiada w miarę dokładnie dwukrotnemu czasowi przelotu dźwięku do stałej przeszkody i z powrotem? No weź nas nie załamuj. Musisz od zera przejść procedurę weryfikacji tego co zrobiłeś, od najprstszych konfiguracji i testów po coraz bardziej skomplikowane. Możesz bazować jedynie na tym co zrobiłeś wcześniej więc musisz tych wcześniejszych rzeczy być pewien na 100%. A ty mi tu piszesz o dziwnych wynikach samplowania ruchomej membrany. Swoim czasem możesz dysponować jak chcesz i nawet skakać z tego dachu bez żadnych wstępnych testów, ale mojego nie marnuj. I nie jest to krytyka (więc się nie martw), bo wiem, że to wszystko wiesz. Tłamaczę tylko, dlaczego nie dostaniesz w tej sytuacji żadnej pomocy. My wszyscy czytający te Twoje raporty jesteśmy w jeszcze gorszej sytuacji, bo obserwujemy sprawy z daleka, wiedząc jeszcze mniej niż Ty. Sam sobie pomożesz najlepiej jeśli zachowasz systematykę pracy. Zrób sobie na kartce krótki plan testów nowego sprzętu i oprogramowania, wykonaj go, zapętlaj się do wcześniejszych punktów gdy coś nie idzie po myśli (aż coś zacznie działać dokładnie tak jak miało, albo rozłożysz ręce i poprosisz o pomoc w konkretnej sprawie) i dojdziesz do końca. Wrzuć wyniki z kolejnych etapów, bo wtedy będzie się czym chwalić i wygląda to dużo poważniej niż takie dziamganie. Przecież to proste rzeczy są, wszystko masz pod kontrolą na biurku. I nie pisz po raz któryś, że masz problemy z liczeniem w zakresie podstawówki bo w końcu uwierzymy, że jednak się do tego nie nadajesz. A gdy spada zainteresowanie, w dzisiejszym świecie przestajesz istnieć...

[Adder]

Dobry wieczór!

Raportuję postępy prac

1. Program: Doszedłem do bezpiecznych 800Hz próbkowania. Osiągnąłem nawet 5000Hz, ale nie ufam wynikom. To są tysiące sampli, których analiza zajmuje czas. Pewnie wrócę do tego, ale nie teraz. 

2. Audacity: Zacząłem korzystać z Audacity. Ale, na nic mi się nie zdał w tym projekcie. Albo nie posiada potrzebnych funkcji, by przetworzyć mój sygnał, albo nie umiem tego zrobić. Wychodzą mi jakieś bzdury. Znowu, brak czasu na kopanie, czytanie... Załączam surowy plik z sygnałem o częstotliwości (jakiej?), próbkowany 500Hz. Ja w Audacity nic nie potrafię z niego wyczytać. Ciekawy jestem waszego odczytu częstotliwości sygnału.  Bo ja ten sygnał poprawnie odczytałem moim excelowym filtrem.  Kto się chce sprawdzić niech  teraz nie ogląda obrazków poniżej. ezyzip.zip

3. Wróciłem do mojego starego filtra i go trochę ulepszyłem. Poprawiłem określanie poziomu tła. 

4. Teraz zamierzam oprogramować filtr w Processing. Trochę mi to zajmie. Potem popracuję nad częstotliwością pomiarów.

A teraz porównanie wyników analizy częstotliwości:

Audacity (plik poddany normalizacji: odstęp+amplituda -5Db):

Mój filtr Ten sam plik poddany filtrowaniu (Filtr wersja 2.0): 

 

PS. Poradziłem sobie nawet z sygnałem 20Hz. HC-SR jest na tyle czuły, że pomimo kiepskiego głośnika dla sygnału 20Hz próbkowanego 500Hz pokazał mi to:

czyli ujdzie...

 

Edytowano Marzec 7, 2021 przez Adder

[Adder]

Dzień dobry!

Pytanie, które nie daje mi spokoju:

 W wyniku moich przekształceń próbek sygnału wygenerowanych przez HC-SR04 otrzymuję funkcję falową, która pozwala mi na bardzo łatwe określenie częstotliwości oryginalnego sygnału w wyniku analizy jej okresu. Na poniższym wykresie widać zapis pojedynczego okresu fali  otrzymanej w wyniku próbkowania stałego sygnału czujnikiem pracującym z częstotliwością 480Hz. Ponieważ okres otrzymanej fali = 8 próbkom, częstotliwość sygnału to 480/8=60Hz. 

Teraz, aby odtworzyć sygnał mógłbym wygenerować oscylator fali sinusoidalnej lub kwadratowej o częstotliwości 60Hz i skierować do głośnika. 

Jednak, i z tym mam problem, przebieg fali w ramach 1 okresu będzie wtedy następujący:

Co zrobić, aby otrzymać przebieg oryginalny? Czy trzeba wygenerować wiele oscylatorów i je na siebie nałożyć? Jakich? Czy tu trzeba analizy Fourriera?  

 

Edytowano Marzec 9, 2021 przez Adder

[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

[Adder]

Dobry Wieczór, 

Wiem już, co robią te moje "filtry". Redukują głębię bitową. Redukują ją do 1 bitu! To pozwala na bardzo sprawne obliczanie częstotliwości. 

To też usprawnia robienie przekształceń dla prostych fal, które można teraz robić w pamięci, albo kierować się intuicją. W ten sposób doszedłem do zasady obliczania składowych fali przedstawionej powyżej  - czyli parametrów dwóch używanych oscylatorów dla 1 bitowych próbek. Z częstotliwościami na razie jest spokój. Niestety, pojawił się kolejny problem. Wylazły skądś amplitudy i fazy. To jest z pozoru proste, ale... przy składaniu sampli pojawia się trzask wynikający z ucięcia oscylatorów w miejscu zakończenia okresu fali źródłowej i wznowienia ich kolejnego cyklu.  Albo coś źle robię, albo nadal nie rozumiem. Pewnie i to, i to. 

Niemniej jednak, jednak już dzisiaj mógłbym Wam zaprezentować Patefon bezbłędnie rozpoznający proste fale sinusoidalne o leżącej w granicach próbkowania częstotliwości. Może się sprężę i oderwę od tych trzasków jutro. Nie dają mi spokoju, bo psują mi koncepcję zwiększenia głębi bitowej. 

 

[Adder]

Dzień dobry!

Dzień Chwały nadchodzi już wielkimi krokami! 😉

Przesyłam video pokazujące jak HC-SR04 rejestruje ciszę (niestety o tej porze nie mogę buczeć głośnikiem).

Jak się należało spodziewać czujnik sam z siebie generuje identyfikowalną falę. Jednak to nic nie szkodzi. Rejestrowany sygnał się ponad nią wybija - sprawdzone. Liczba tych widocznych prążków w czasie jest wprost proporcjonalna do zarejestrowanej częstotliwości sygnału. Żeby rozpoznać częstotliwość wystarczy je zliczać w określonych odstępach czasu. Im gęściej są upakowane, tym częstotliwość sygnału większa. 

Przepraszam, że Kataryna jeszcze w takiej rozsypce. Na premierę nagrania jeszcze ją podrasuję.  

 

[Adder]

Zapis 120Hz. Widać wyraźne odkształcenia. Przyczyn zakłóceń może być wiele. Powtórzenie warunków idealnych wymaga średnio 5-10 prób. Czasami, w ogóle HC-SR04 się buntuje i nagranie trzeba powtórzyć po całkowitym resecie, albo następnego dnia...

 

[Adder]

To jest bardzo ciekawe nagranie. Sygnał 60Hz. Widać jak na początku czujnik się "męczy" z rozpoznaniem częstotliwości. Potem zaczyna bardzo ładnie czytać. Na koniec sygnał źródłowy zostaje wyciszony. Co interesujące własna fala czujnika przestała wtedy być widoczna. Uzyskany zapis ciszy stał się wolny od zakłóceń. 

 

Edytowano Marzec 11, 2021 przez Adder

[Adder]

Dzień dobry! 

Budowałem patefon, a skonstruowałem oscyloskop!

Teraz mogę mierzyć każdy pulsujący sygnał z Arduino. Jestem bardzo zadowolony 🙂 🙂 😀🤓

 

[Adder]

Dobry wieczór!

Dawno mnie tu nie było, ale zapewniam, że zaglądam codziennie. 🙂

Pracowałem nad "kataryną". Działa już naprawdę fajnie. 

Mam jednak duży problem z rejestracją wychyleń membrany. 

W chwili obecnej jestem w stanie zarejestrować dźwięk w zakresie mniej więcej 2 oktaw - trzeciej i czwartej, przy częstotliwości próbkowania 500Hz - nie ma sensu wchodzić wyżej, bo i tak ruch membrany przy wyższych dźwiękach jest zbyt słaby na dobrą rejestrację. 

Pytanie do eksperta. Jak domowym sposobem zwiększyć amplitudę wychyleń membrany głośnika bez zwiększania głośności i powierzchni membrany? Może ktoś robił taki projekt? (osiągnąłem dostępny mi max.)

[Adder]

Kataryna - stan aktualny

[Adder]

Pozdrawiam wszystkich forbotowych Forumowiczów w ostatni dzień Świąt! Życzę Wam wszystkiego najlepszego, wyłącznie udanych projektów i niegasnącej radości z rozwijania Waszych pasji!

Dla mnie jest to dzień świąteczny podwójnie, bo wreszcie udało mi się skończyć mój pierwszy poważny projekt jakim była rejestracja i odtworzenie dźwięku emitowanego przez standardowy przetwornik elektroakustyczny przy wykorzystaniu czujnika odległości HC_SR04.

Zadanie, które wydawało mi się z pozoru łatwe, z biegiem dni i tygodni przerodziło się w długi i skomplikowany proces gromadzenia wiedzy, jej przyswajania, a następnie udanych i nieudanych prób zastosowania w praktyce. Projekt, który miał trwać najwyżej tydzień, pochłonął mnie na ponad 3 miesiące, wywołując prawie obsesję i maksymalne podenerwowanie rodziny. Nakładała się na to także końska dawka sceptycyzmu i ironii serwowana mi na Forum przez doświadczonych Forumowiczów. W tym miejscu chciałem jeszcze raz podziękować Panu Markowi (marek1707), który chyba jako jedyny dostrzegał światełko w tunelu. Uzyskałem od niego duże wsparcie i trochę cierpkich uwag.  

Założenia projektu były dosyć proste. HC_SR04 jest ultradźwiękowym czujnikiem odległości, który skierowany na membranę głośnika akustycznego stosunkowo precyzyjnie dokonuje pomiarów jej wychylenia w czasie emisji dźwięku. Wychylenia te można zarejestrować, a następnie podjąć próbę odtworzenia zapisanego w ten sposób sygnału. Jak łatwo zauważyć zaangażowane są tu dwa zasadnicze procesy: cyfrowa rejestracja fizycznych drgań membrany, które mają charakter analogowy, oraz proces odwrotny, czyli przetworzenie cyfrowego zapisu na drgania membrany generujące falę dźwiękową rozchodzącą się w powietrzu. Razem: konwersja AD/DA.  Swoją drogą sama fala akustyczna powstająca w wyniku drgań ma dla tego projektu znaczenie wtórne. Pomiarów i emisji drgań można byłoby dokonywać w próżni. Sam dźwięk jest efektem ubocznym.

Reasumując, moim zadaniem było rozpoznanie i zapisanie drgań fizycznego nośnika, a następnie ich emisja w formie jak najbardziej zbliżonej do oryginalnej. 

W roli przetwornika AD wykorzystałem płytkę mikrokontrolera Arduino Uno z podłączonym do niej czujnikiem odległości. Sygnał generowany przez czujnik skierowałem bezpośrednio do portu szeregowego czytanego przez komputer PC pełniący rolę przetwornika DA.

Ze względu na specyfikę środowiska IDE Arduino wymagało to zaangażowania drugiego systemu, na który wybrałem IDE Processing w wersji 4.0, który jak mi się wydawało miał pozwolić na wygodne przetwarzanie i zapisywanie otrzymywanych danych oraz elastyczną konstrukcję interfejsu użytkownika. Przy okazji wspomnę, że z powodów, których nie potrafię jednoznacznie wyjaśnić, napotkałem po drodze na dziwne problemy z optymalnym ustawieniem szybkości transmisji danych. Ostatecznie, właściwym parametrem okazało się dopiero 230400 baudów. 

Widok instalacji czytającej sygnał i wysyłającej do PC (talia kart ma idealną grubość dla ustawienia czujnika):

W trakcie realizacji procesu rejestracji drgań na pierwszy plan wysunęło się zagadnienie częstotliwości oraz precyzji próbkowania. HC-SR04 jest urządzeniem dokładnym, ale nie dokładnym na tyle, by rejestrować drgania membrany ustawionego na maksymalną głośność głośnika średnio tonowego o średnicy ok. 10 cm przy częstotliwościach wyższych niż 160-170 Hz. Jakość próbkowania, a tym samym działanie całego systemu, były więc pierwotnie zdeterminowane przez charakterystykę źródła drgań. Im wyższa była ich amplituda tym precyzyjniej czujnik dokonywał ich odczytu. Był to bolesny mankament, z góry ograniczający zakres rejestrowanych częstotliwości. Na szczęście nie zmieniało to poprawności samej idei projektu.

Inny aspekt próbkowania jakim jest częstotliwość i regularność pomiarów rozwiązałem poprzez bezpośrednie operowanie na rejestrach mikrokontrolera w reżimie cyklicznych przerwań osiągając poziom 2000 próbek na sekundę, powyżej których czujnik odmawiał współpracy. W świetle jednak opisanych powyżej ograniczeń, związanych z amplitudą wychyleń membrany, ten aspekt przestał być krytyczny. Ostatecznie czujnik został ustawiony na częstotliwość 500 pomiarów na sekundę, co zapewniło relatywną poprawność odczytów przy istniejących ograniczeniach emitera oraz samego czujnika. 

Ostatnią istotną rzeczą przy realizacji samych pomiarów była optymalizacja odległości czujnika od membrany. W wyniku doświadczeń okazało się, że wynosi ona ok. 2 cm. 

Posiadanie zestawu odczytów czujnika umożliwiało dokonanie ich analizy w celu przetworzenia ponownie na formę analogową. To pozornie proste zadanie stało się jednak, w miarę zagłębiania się w nie, nadzwyczaj trudne. Niewinnie wyglądający ciąg liczb reprezentujących czas rejestrowany przez czujnik, był obrazem złożonego ruchu falowego. Na obraz tego ruchu składało się jedna lub więcej fal o określonej amplitudzie, częstotliwości oraz fazie. Do analizy składowych tak zapisanego drgania wykorzystuje się niebanalną matematycznie transformację Fouriera. Z chwilą wyraźnego uświadomienia sobie tego faktu stanąłem na projektowym rozdrożu. Albo czekało mnie przekształcanie fourierowskich wzorów na program, albo rzucenie wszystkiego i wyjechanie w Bieszczady, albo takie przedefiniowanie projektu, aby mieszcząc się w jego założeniach, nie robić z patefonu skomplikowanego analizatora drgań. 

Surowy sygnał odebrany z Arduino,

oraz jego zbliżenie:

Wybrałem ścieżkę przez chaszcze. Stworzyłem własną metodę analizy, która nie wchodząc w jej zawiłości, polega na przepuszczaniu zapisu drgań przez kolejne sita zmieniających się oczek amplitudy. Mam wrażenie, że Fourier zrobił podobnie, ale zgrabniej to zapisał. Zaletą mojej metody było to, że na każdym kroku programowania miałem poczucie zrozumienia tego, co robię. Z Fourierem nie do końca mi to wychodziło. Aby jeszcze bardziej ułatwić sobie zadanie postanowiłem ponadto (chwilowo) wyzbyć się problemu amplitudy oraz fazy i skoncentrować wyłącznie na częstotliwości. W tym celu dokonałem ograniczenia źródła drgań do pojedynczej fali sinusoidalnej, co jako bonus pozwoliło mi przetestować mój autorski sposób analizy w praktyce. Dzień, w którym zobaczyłem na ekranie komputera dokładną wartość częstotliwości mierzonych drgań był jednym z najprzyjemniejszych w moim życiu. Przede mną nadal stoi jeszcze zadanie zbadania bardziej złożonych fal, ale to już chyba nie z tym czujnikiem i nie szybko.

Główne etapy przetwarzania sygnału:

1)    Przesunięcie wartości

2) Normalizacja (konwersja amplitudy do poziomu 1)

3) Redukcja (jednorazowe przepuszczenie znormalizowanego sygnału przez „sito” amplitudy /nazywam go poziomem ciszy/. Badanie sygnału złożonego wymaga wielokrotnych iteracji tego procesu):

4)    Obliczenie częstotliwości na podstawie zredukowanego sygnału:

Jak wspomniałem przetwarzanie sygnału do postaci pozwalającej na jego odtworzenie odbywało się w środowisku IDE Processing ver. 4. w systemie IOS. Z perspektywy dotychczasowych doświadczeń nie polecam tego rozwiązania. Processing działający w tym systemie potrafi wygenerować różne problemy. Na przykład, przy próbie eksportu programu do pliku wykonywalnego Processing dokonał niesygnalizowanej i trudnej do szybkiej identyfikacji zmiany numerów portów (pomijając fakt, że eksport się nie udał, a plik wykonywalny nie działał poprawnie). Tego rodzaju niespodzianki naprawdę potrafią zepsuć humor, co najmniej na czas poszukiwania usterek. Przyzwyczaić się też trzeba do koncepcji odświeżanych ze standardową częstotliwością ramek. Cechę tę można wykorzystać z pożytkiem dla algorytmu, ale zapomnienie o niej może prowadzić do całej listy trudnych do identyfikacji anomalii, zwłaszcza w programach o rosnącej objętości i złożonej strukturze. Tak było w moim przypadku. Ramki kosztowały mnie godziny poprawiania kodu. Ogólnie rzecz biorąc Processing jako doskonałe narzędzie programowania procesów i struktur słabo radzi sobie z wykorzystaniem go do budowy prostych interfejsów. Kod, zwłaszcza pisany niedbale szybko staje się zagmatwany i nieelastyczny. Operowanie setkami współrzędnych relatywnie prostych obiektów, ich metodami i przekształceniami po pewnym czasie może stać się prawdziwą udręką. Rozwiązaniem może tu być stworzenie całego systemu klas i późniejsze operowanie tylko na nich. Do budowy prostego patefonu nie wydawało mi się to niezbędne. Błędne założenie.

Processing w moim projekcie przetwarzał surowy sygnał z czujnika do ciągu częstotliwości wyrażonych w hercach gotowych do odtworzenia na dowolnym głośniku przy wykorzystaniu każdego popularnego obiektu służącego do generowania oscylatora, jak np. SinOsc w Processing, czy funkcji tone() w Arduino.  Początkowo zamierzałem skierować ciąg częstotliwości z powrotem do Arduino i odtworzyć na dołączonym do niego głośniku zewnętrznym (pod ten cel powstało w programie wiele nie wykorzystanych struktur), ale perspektywa utknięcia na problemach doboru właściwego rezystora, głośnika oraz wizja plączących się kabli skłoniła mnie do skierowania sygnału po prostu na wewnętrzny głośnik komputera.

Widok interfejsu:

 

Co robi dzisiaj system, którego działanie za chwilę będziecie mogli obejrzeć? 

Rejestruje drgania membrany głośnika średnio tonowego o średnicy 10 cm w zakresie częstotliwości 30-160Hz, przetwarza go, wizualizuje a następnie odtwarza na głośnikach komputera. To jednocześnie wiele i niewiele. 

W trakcie przetwarzania dźwięku występują co najmniej dwa dziwne zjawiska, których nie potrafię ani dobrze opisać, ani tym bardziej wytłumaczyć ich istoty. Te anomalie są dla mnie zagadką. Wrócę do nich na koniec. 

Po tym przydługim wstępie, w końcu finał: Na początek zapis i odtworzenie przez system pojedynczej fali sinusoidalnej o stałej częstotliwości 50Hz.Być może jest to pierwszy zapis dźwięku czujnikiem HC-SR04 w historii cywilizacji. Trudno mi to ocenić. Cytując znanego autora zapytanego, co ostatnio czytał, mógłbym odpowiedzieć: „Nie wiem, nie czytam książek. Ja je piszę”. 

 

Krótki komentarz. Fala tworzona jest w mobilnej aplikacji „Frequency Generator” na Androida, komunikującej się za pośrednictwem bluetooth z głośnikiem. Widać jak silne wychylenia membrany powoduje częstotliwość 50Hz! Następnie rozpoczynany i kończony jest zapis dźwięku za pomocą przycisków na płytce Arduino. Przechodzę do interfejsu i wybieram odtwarzanie spowolnione – służyło mi ono głównie do analizy sygnału. Taktowane jest szybkością odświeżania ramek – w tym przypadku 200 ftp. Na koniec wybieram odtwarzanie dźwięku z prędkością rzeczywistą. Wyświetlanie interfejsu ulega wtedy zawieszeniu. Ramki się nie odświeżają. Odtwarzania z prędkością rzeczywistą nie da się zatrzymać. Trzeba byłoby je oprogramować w przerwaniach. 

Jak widać patefon poprawnie zapisał i odtworzył sygnał o częstotliwości 50Hz. Występujące zakłócenia nie mają istotnego znaczenia. Ich charakter jest przypadkowy. Wynikają z aktualnych warunków w jakich dokonywany jest zapis: ruchy powietrza wokół głośnika, drgania stołu, głośność odtwarzania, dźwięki tła itp. 

Trzask występujący na końcu zapisu jest wywołany przez błąd algorytmu. Zidentyfikowałem go, ale już nie chciało mi się go naprawiać, bo przyzwyczaiłem się do niego jako sygnału końca nagrania. 

Poniżej, wideo samego interfejsu i możliwości jakie daje w zakresie analizy nagrania. Widać na nim, że zakłócenia jakie wystąpiły powodują kilkukrotnie zmianę częstotliwości z 50 na 46 Hz. Spowolniony dźwięk odtwarzany jest w pętli. Przy pewnej staranności możliwe jest uzyskanie zupełnie „czystego” nagrania, praktycznie bez zakłóceń. Jednak celowo zamieszczam to, bo oddaje dobrze klimat pracy nad patefonem:

Teraz crème-de-la-crème projektu, czyli nagranie pojedynczej fali sinusoidalnej o zmiennej częstotliwości w zakresie 30-170Hz i z powrotem (tony ok. B0-F3). To pozwala już zagrać prostą melodię, postanowiłem jednak oszczędzić sobie i Wam moich popisów instrumentalnych:

Jak już wcześniej wspominałem w nagraniach występują dwie anomalie. Na poniższym nagraniu widać je doskonale:

1)    Deszcz spadających cegieł. Są to rozległe zakłócenia występujące przy każdej próbie. Pomimo, że mają one charakter przypadkowy i występują w różnym nasileniu, ich ogólny wygląd jest bardzo podobny. Obejmują ograniczone zakresy częstotliwości, najczęściej symetrycznie. Podejrzewam, że ich źródłem są niesterylne warunki nagrania. Nie mam jednak pewności. To by było za proste…

2)    Skokowe zmiany częstotliwości. Jest to dużo poważniejszy problem. Im wyższa zarejestrowana częstotliwość, tym krok jej zmiany ma większą wartość. Przy sygnale wzrastającym i opadającym powstaje zawsze charakterystyczny „dach pagody”. Myślę, że ten efekt jest wierzchołkiem głębszego problemu. Może transformacja Addera obarczona jest jakąś pierwotną wadą? (tutaj obstawiałbym 80%, że tak) Ach! Jakże chciałbym porozmawiać z Fourierem! Może jest to jakieś zjawisko fizyczne, które mi umyka? Może to banalne, laickie błędy programistyczne, których nie potrafię zidentyfikować? 

Im głębiej w las, tym więcej drzew. Ciemność. Ciemność, widzę….

 

 

Edytowano Kwiecień 5, 2021 przez Adder

[opp34]

Chylę czoła przed autorem, że doprowadziłeś projekt do końca, że nie przerwałeś po napotkaniu pierwszych trudności. Czytając opis, powiedziałbym, że ten projekt jest dobrym przykładem, że rzeczywistość jest znacznie bardziej złożona niż się ją prezentuje. Doceniam, że opisałeś nieprawidłowe założenia, popełnione błędy i inne potknięcia – szczególnie, że powszechne jest prezentowanie się jako perfekcyjnych, unikatowych, nieskalanych żadną porażką.  

Wspomniałeś, że to Twój pierwszy poważny projekt. Przypomniało mi się, jak jednego dnia znalazłem opis innego Pierwszego Projektu, w którym autor sterował poziomem w trzech dużych zbiornikach przy pomocy profesjonalnych pomp i stworzył szafę sterowniczą z uporządkowanymi trasami kablowymi. W odpowiedzi jakiś człowiek odpisał, że w jego przypadku pierwszym projektem było sterowanie pojedynczą diodą…

 

[Adder]

@opp34 Dziękuję za miłe słowa. Dla mnie największą wartością tego projektu był walor poznawczy. Ilość wiedzy przyswojonej przy jego realizacji mnie samego wprowadziła w zdumienie. Projekt jest również zaprzeczeniem powtarzanej początkującym rady, z którą się często spotykałem, aby nie brać się za "budowanie katedry". Uważam, że właśnie warto to robić. Mam przeczucie, że w wielu przypadkach przygoda z programowaniem zaczyna się od sterowania lampką, a kończy na... sterowaniu lampką. Po szkole jaką dał mi patefon moja perspektywa patrzenia na projekty informatyczne totalnie się zmieniła. A co najważniejsze dalej mi się chce, bo po drodze odkryłem tyle interesujących ścieżek...

Myślę, że teraz jeszcze przez chwilę poeksperymentuję z czujnikiem laserowym. Może odpowie na niektóre moje dylematy. Popracuję też z plikami dźwiękowymi pod kątem ich analizy. Wciągnęło mnie to.  Chciałbym też zrobić ładny projekt w Processingu. Mam pomysł na interesującą strukturę, której jak mi się wydaje po przejrzeniu projektów w OpenProcessing, jeszcze nikt nie prezentował. Podszkolę się w operowaniu klasami. 

[Adder]

A. I napiszę coś w Pythonie. 🙂