To forum używa plików cookies
To forum wykorzystuje pliki cookies do przechowywania informacji o Twoim logowaniu, jeśli jesteś zarejestrowany, oraz informacji o Twojej ostatniej wizycie, jeśli nie jesteś zalogowany. Pliki cookies to niewielkie pliki tekstowe zapisywane na Twoim komputerze; cookies ustawiane przez to forum mogą być używane wyłącznie na tej stronie i nie stanowią zagrożenia dla bezpieczeństwa. Cookies na tym forum śledzą również, które tematy zostały przez Ciebie przeczytane oraz kiedy miało to miejsce. Prosimy o potwierdzenie, czy akceptujesz, czy odrzucasz zapisywanie tych plików cookies.

Niezależnie od wyboru w Twojej przeglądarce zostanie zapisany plik cookie, aby zapobiec ponownemu zadawaniu tego pytania. W każdej chwili będziesz mógł zmienić ustawienia cookies, korzystając z linku w stopce strony.

Ocena wątku:
  • 1 głosów - średnia: 5
  • 1
  • 2
  • 3
  • 4
  • 5
WALET – czyli jak buduję sobie transceiver SDR
#59
FFT - cd....
Zanim podam co się dzieje w temacie fft opiszę przykrą niespodziankę jaka mnie spotkała ponad tydzień temu podczas kolejnej próby z fft. Dla kolejnej wersji programu kompilator pokazał błąd biblioteki Etherkit odpowiedzialnej za sterowanie generatorem Si5351. I choć kiedyś sam zgłębiłem temat a nawet udało mi się zrobić w python-ie odpowiednią bibliotekę do sterowania tym generatorem to perspektywa napisania programu w C do zrobienia czegoś co mi już działało podniosła mi ciśnienie :-(
Po wielu beznadziejnych próbach naprawy sytuacji przypomniałem sobie, że Arduino zgłaszało update oprogramowania  i prawdopodobnie za którymś otwarciem programu ten update zatwierdziłem a jedyną zmianą jaka wtedy dała się zauważyć to właśnie update biblioteki Etherkit. Faktycznie, skontaktowałem się z autorem (Jason Mildrum), który dość szybko potwierdził błąd biblioteki Etherkit 2.3.0. Obecnie, poprawiona biblioteka ma wersję 2.4.0 ale na wszelki wypadek mam prawidłowo działającą kopię bo a nuż w kolejnej wersji coś się sypnie?
Błąd polegał na niemożności sterowania układem Si5351 liniami I2C z innego kanału niż kanał 0. Walet używa obu kanałów I2C z czego kanał 0 obsługuje kodeki i nie ma wyprowadzeń na zewnątrz a kanał 1 obsługuje wszystkie peryferia - w tym generator Si5351 więc utrata sterowania z poziomu kanału 1 była krytyczna.

Uwaga: każdorazowy update biblioteki EtherKit nadpisuje pliki si5351.cpp oraz si5351.h a w szczególności ten ostatni plik, do prawidłowego działania Walet-a na CW w paśmie 3.5MHz wymaga korekty stałej PLL_VCO_MIN , która z definicji ma wartość 600MHz i nie pozwala na bezpośrednie generowanie częstotliwości mniejszych niż ok. 6MHz.
[Obrazek: https://lx-net.pl/walet/image/ethkit.jpg]
Stałą tą należy zmniejszyć do 400MHz co obniża działanie generatora do ok. 3.3MHz i zapewnia jeszcze stabilne działanie generatora.

Ale wracając do FFT, ostatni stan oprogramowania wykorzystywał wbudowane w Arduino Audio Tools biblioteki FFT (np. RealFFT, KissFFT). Niestety, są one zorientowane na zastosowania typowo audio a więc analizują zawartość próbki sygnału nie wgłębiając się w źródło ich wytworzenia co jest wystarczające do pokazania na przykład bar grafu spektrum muzyki.

[Obrazek: https://lx-net.pl/walet/image/rfft01.jpg]
Rysunek pokazuje przetwarzanie cyfrowe sygnału za mieszaczem Tayloe, który wydziela sygnały I oraz Q. Sygnały te są zamieniane na postać cyfrową a dalej przetwarzanie odbywa się za pomocą strumieni I2S. Kluczowe znaczenie ma tu moduł MultiOutput z pakietu Arduino Audio Tools, który duplikuje dane z wejścia z czego jedna kopia to formowanie sygnału jednowstęgowego a druga służy do wykonania transformaty fft oraz obrazowania zawartości odbieranego sygnału na przykład w postaci prążków częstotliwości na wykresie. Ale wspomniane transformaty fft są typu real i pobierają dane do analizy z jednego kanału I lub Q więc obrazowanie nie jest w stanie rozróżnić czy prążek znajduje się wyżej od częstotliwości odbioru czy niżej od niej. W analizowanym kanale I lub Q znajduje się pełne spektrum częstotliwości w zakresie +- Fp/2 = fN gdzie Fp to częstotliwość próbowania a fN to tzw. częstotliwość Nyquist-a. Dlatego też prążki F1 i F2 leżące po obu stronach częstotliwości odbioru - F0 pokażą gdzie leżą dopiero podczas przestrajania bo będą się poruszać w przeciwnych kierunkach co pokazałem na poprzednich filmach.
Rozwiązaniem tego stanu jest tzw. complex fft a więc taka manipulacja danymi, która wykorzystuje do obliczeń zarówno kanał I jak i kanał Q ponieważ dopiero informacja z obu kanałów umożliwia pełna analizę częstotliwościowo fazową.

[Obrazek: https://lx-net.pl/walet/image/cfft01.jpg]
Jak widać, tu transformata fft korzysta z obu kanałów danych co pozwala na ich umiejscowienie w stosunku do częstotliwości odbioru. Sensowne jest więc teraz wykonanie wykresu częstotliwości na skali zawierającej zakres od -fN do fN z zerem pośrodku - odpowiadającym na częstotliwość odbioru.

Nieco więcej szczegółów na temat samej transformaty fft oraz jej rozwiązania w formie complex napiszę w kolejnym poście a na razie zachęcam do obejrzenia krótkiego filmu pokazującego bieżący stan tej części programu. Przyszykuję też do publikacji na Github ostatnią wersję programu źródłowego oraz pliki binarne.

Obrazowanie widma odbieranego sygnału za pomocą complex fft

Dla prawidłowego działania obrazowania wykonałem nowe tło gdzie środek skali na osi X to częstotliwość odbioru a granice osi X to -fN (F0 - 10kHz) oraz +fN (F0 + 10kHz).

cdn. lj

Github
Cytuj


Wiadomości w tym wątku
RE: WALET – czyli jak buduję sobie transceiver SDR - przez SP6FRE - 21-10-2026, 20:31

Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości