WALET – czyli jak buduję sobie transceiver SDR

[SP6FRE]

Zanim o wodospadzie będzie napotkałem kolejny problem do przejścia dotyczący wizualizacji danych fft.
Najlepiej będzie jak pokażę to na filmie:

Problem z wizualizacją fft przy zmianie wstęgi

Osiągnąwszy poziom gdzie miałem do dyspozycji wszystkie dane z fft, zarówno biny dodatniej jak i ujemne, straciłem czujność i nie sprawdziłem jak wizualizacja zachowa sie podczas zmiany wstęgi. Oczywiście, pożądane jest aby taka zmiana nie wprowadzała zmiany w wizualizacji, prążek leżący poniżej częstotliwości odbioru powinien tam leżeć dalej a ten z większą częstotliwością również nie powinien zmieniać swojego miejsca na skali. Z filmu wynika, że zmiana wstęgi odwraca mi wykres lustrzanie. Nie muszę chyba dodawać, że podobne zjawisko mam w wodospadzie :-(
Mam wstępne podejrzenia co do natury tego zjawiska bo prawie na pewno związane jest ono ze sposobem w jaki powstaje odpowiednio dolna i górna wstęga. W przypadku Waleta za wstęgi odpowiedzialny jest mieszacz Tayloe tworzący sygnały I oraz Q a sama wizualizacja wymaga po prostu wbudowania do algorytmu wyświetlania reakcji na zmianę wstęgi.

cdn. lj

[SP6FRE]

FFT cd...
Jak przypuszczałem, problem z lustrzanym odbiciem wykresu fft wiąże się ze sposobem w jaki formowany jest w Walecie odbiór jednowstęgowy.

[Obrazek: https://lx-net.pl/walet/image/lsb_usb.jpg]
Rysunek pokazuje dwa sposoby jakie miałem do dyspozycji robiąc założenia dla Waleta. Sposób pierwszy to sumowanie lub odejmowanie od siebie sygnałów I oraz Q w węźle z prawej strony rysunku a sposób drugi to zmiana faz heterodyn sterujących mieszacz Tayloe.

Obie metody mają swoje wady i zalety. 
Metoda sumowania lub odejmowania sygnałów I oraz Q z pozoru wydaje się prosta i elegancka ale jeśli odbywa się w torze cyfrowym to po pierwsze dodatkowo wydłuża opóźnienie sygnału między wejściem a wyjściem części cyfrowej bo każdą próbkę z obu kanałów trzeba cyfrowo dodać lub odjąć ale po drugie, sumowanie lub odejmowanie sygnałów I oraz Q z jednej strony tłumi jedną ze wstęg ale drugą zwiększa w amplitudzie dwukrotnie co może doprowadzić do szybszej saturacji kanału cyfrowego. Sumowanie/odejmowanie sygnałów po stronie cyfrowej można byłoby przenieść do części analogowej ale z kolei wiąże się to z większym skomplikowaniem układu elektronicznego, który powinien zapewnić jednakowe warunki zarówno dla dodawania jak i odejmowania sygnałów.

W Walecie użyty został drugi z pokazanych sposobów polegający na zmianie faz sygnałów heterodyny zasilających mieszacz Tayloe. Warunkiem podstawowym działania takiego mieszacza jest przesunięcie wzajemne sygnałów heterodyn F0 i F1 tak, że F0 wyprzedza F1 o 90 stopni dla wytworzenia sygnałów I oraz Q.  Ale jeśli to F1 wyprzedza F0 o 90 stopni to sygnały I oraz Q zamieniają się miejscami na wyjściu mieszacza. Jednocześnie, w tej metodzie sygnały I oraz Q są wyłącznie sumowane w sumatorze rezystancyjnym zapewniając prostotę rozwiązania i dokładność działania.

Jak wspominałem wcześniej, tablica fft daje dla założonej dokładności analizy 255 częstotliwości wyniki w postaci:
0 - składowa stała, 1 - bin pierwszy dodatni, 2 - bin drugi dodatni, ...., 127 - ostatni bin dodatni, 128 - ostatni bin ujemny, .... 254 - drugi bin ujemny, 255 - pierwszy bin ujemny.
Zmieniając wstęgę dostajemy na wyjściu mieszacza Tayloe dane ułożone następująco:
0 - składowa stała, 1 - bin pierwszy ujemny, 2 - bin drugi ujemny, ...., 127 - ostatni bin ujemny, 128 - ostatni bin dodatni, .... 254 - drugi bin dodatni, 255 - pierwszy bin dodatni.
Efektem zmiany wstęgi jest pokazane wcześniej lustrzane odbicie sygnałów podczas ich wizualizacji.

Dlatego należy uwzględnić w algorytmie wizualizacji danych fakt zastosowania dolnej lub górnej wstęgi przez prostą podmianę wskaźników do tablicy z bin-ami co też zrobiłem.

Działanie skorygowanej procedury wizualizacji fft z uwzględnieniem odbieranej wstęgi

W wizualizacji fft pomija się bin 0 czyli składową stałą z oczywistego powodu. Jest ona z punktu widzenia operatora reagującego na sygnał o określonej częstotliwości nieistotna ale gdybyśmy na przykład chcieli dokonać analizy sygnału fft z prostownika sieciowego z jakąś filtracją to oczywiście interesowała by nas zarówno wartość prądu stałego na wyjściu (składowa stała) jak i zawartość harmonicznych po filtracji a więc biny 1,2....

W kolejnym poście pokażę jakiej metody, z dostępnych funkcji dla grafiki TFT_ESPI, użyłem do stworzenia wizualizacji fft jako wodospadu i jak to wyszło w praktyce.

cdn. lj

Github

[SP6FRE]

FFT - waterfall
Do wizualizacji danych z fft wykorzystałem jeden z elementów biblioteki TFT dla ESP32 o nazwie eSprite lub Sprite. W skrócie mówiąc ta funkcjonalność polega na utworzeniu grafiki w pamięci procesora a następnie przesłaniu jej, z dużą prędkością, do wyświetlacza. Formowanie grafiki w pamięci zapobiega efektom migotania obrazu a duża prędkość przesyłania danych z pamięci do wyświetlacza za pomocą SPI umożliwia animację obrazów. Grafika wodospadu nie potrzebuje dużych prędkości animacji ale za to wykorzystuje kolejną funkcjonalność Sprite, którą pokazałem na rysunku:

[Obrazek: https://lx-net.pl/walet/image/esprite.jpg]

Sprite to prostokątny obszar w pamięci zdefiniowany przez szerokość (width) oraz wysokość (height) - wyrażone w pixel-ach gdzie zmienne X,Y to miejsce na ekranie gdzie należy umieścić utworzona grafikę.
Waterfall to linie na ekranie pokazujące stan widma odbieranego sygnału (biny) w momencie analizy w taki sposób, że amplituda konkretnego bin-a opisana jest kolorem. "Agresywność" koloru związana jest z wielkością amplitudy bin-a tak, że słabszym binom odpowiadają ciemne barwy a silniejszym jasne: od czarnego przez granatowy, zielony, żółty, czerwony do białego.
Na rysunku pokazałem stan Sprite w momencie tworzenia nowej linii (zielona na górnym rysunku). Rzeczywisty kolor tej linii będzie zależeć od zawartości i wielkości binów z bieżącej analizy fft. Elementarna funkcja scroll pozwala na wprowadzenie tej linii do obszaru Sprite z jednoczesnym przewinięciem wszystkich istniejących linii w dół oraz usunięciem najstarszej linii wodospadu co pokazuje dolna część rysunku.
W skrócie, te wszystkie działania opisują następujące polecenia:

TFT_eSprite img = TFT_eSprite(&tft); // deklaracja grafiki img jako obiektu typu Sprite
....
#define wf_width 216  //szerokość obszaru na wodospad w pixel-ach
#define wf_height 41  //wysokośc obszaru na wodospad w pixel-ach
....
void setup(void) {
....
img.createSprite(wf_width, wf_height);  //Rezerwacja pamięci RAM na Sprite
img.fillSprite(TFT_BLACK);              //Wypełnienie obszaru Sprite kolorem czarnym
....
}

void setup(void) {
....
//te polecenia powtarzane są 4 razy na sekundę po wyliczeniu transformaty fft oraz przypisaniu koloru do każdego z binów
img.drawPixel(xn, 0, color);//kompletacja linii dla wszystkich xn w pętli
img.scroll(0, 1); // wpisanie nowej linii do obszaru Sprite
img.pushSprite(X, Y); // przesłanie grafiki img do wyświetlacza zaczynając od miejsca X,Y
....
}

Przesłanie zawartości pamięci z nową grafiką do wyświetlacza zapewnia polecenie img.pushSprite(X, Y).
Każda z linii wodospadu ma szerokość 216 pixeli co pozwala na zapisanie 2x107 binów z części dodatniej i ujemnej widma sygnału. Dwa dodatkowo pixel-e nie są zapisywane i rozdzielają na środku biny dodatnie od ujemnych. Przy szerokości analizy fft każdy bin ma ok. 94Hz a więc tworzą one łącznie pasmo ok. +- 10kHz.
Z kolei w pionie obszar Sprite ma szerokość 41 pixel-i a więc może pomieścić 41 linii jednocześnie. Ponieważ odświeżanie grafiki wodospadu dokonywane jest 4 razy w ciągu sekundy to na ekranie zmieście się ok. 41/4 = 10 sekund zapisu wodospadu czyli najniższa jego linia pokazuje stan sprzed 10 sekund.

[Obrazek: https://lx-net.pl/walet/image/fft_c02d.jpg]
Dla potrzeb wyświetlania wodospadu przygotowałem nieco inną grafikę gdzie oś X to częstotliwości widma sygnału a oś Y to czas obserwacji wodospadu w sekundach.
Wydaje się, że z punktu widzenia możliwości grafiki przyjęte założenia:  dokładność analizy (fft_size) oraz czas obserwacji wodospadu są zbliżone do optymalnych. Dla 128 binów dodatnich i ujemnych wykorzystuję po 107 dla każdego zakresu a każdy bin ma swój odpowiednik w jednym pixel-u. Gdyby dokładność fft była dwukrotnie większa to miałbym do dyspozycji 256 binów dla każdego z zakresów (czyli 512) a każdy bin miałby szerokość ok. 47Hz i nie udałoby się dopasować każdego bin-a do pixel-a przy ograniczeniu pola wizualizacji do 216 pixel-i. Dodatkowe zwiększenie dokładności fft tylko pogłębia ten problem bo podczas tworzenia grafiki zysk z tej dokładności zostałby utracony ograniczoną dokładnością wyświetlacza. Oczywiście, mając wyświetlacz np. o polu 640 pix-eli miałoby to sens.

Wizualizacja fft za pomocą bar grafu oraz wodospadu

Jak ostatecznie wygląda wodospad fft w Walecie pokazuje film z powyższego linku. Dodatkowo skomentuję obraz na ekranie po włączeniu dwóch silnych sygnałów. Pojawiają się one z lewej strony przy odbiorze LSB ale po prawej stronie widać jakby "cienie"  tych sygnałów o istotnie mniejszej intensywności. Cienie te wędrują synchronicznie za sygnałami podstawowymi stanowiąc ich lustrzane odbicie względem środka wykresu (częstotliwość 0Hz). Są to sygnały jakie "produkuje" analiza fft wynikające ze skończonej dokładności zarówno obliczeń jak i kwantyzacji oraz z dużego poziomu analizowanych sygnałów. Poziom tych "cieni" jest jednak niewielki w stosunku do sygnałów podstawowych i optymalnie, w idealnych warunkach, nie powinny być one widoczne wcale. Sygnały podstawowe mają poziom ok. S9 +20dB a ich cienie są dużo bardziej stłumione choć faktycznie są widziane przez fft.

Na Github pojawiło się już oprogramowania zawierające ostatnie rozwiązania opisane jako wersja 1.3.

cdn...  lj

Github

[SP6FRE]

Chciałbym pokazać więcej nagrań z działania obrazowania fft ale w moich warunkach antenowych, z zakłóceniami na poziomie S9 a nawet więcej na niższych pasmach jest to niemal niemożliwe. 
Niemniej, udało mi się zarejestrować kilka próbek korzystając, chyba, z dobrej propagacji na 14MHz i trwających zawodów więc było nieco więcej silniejszych stacji przebijających się przez zakłócenia. Pierwsze dwie próbki robiłem trzymając aparat w ręce stąd drgania obrazu.

Próbka 1
Próbka 2
Próbka 3
Próbka 4
Próbka 5
Próbka 6
Dwie ostatnie próbki to nieco nieudolne próby pokazania jak te same sygnały są widziane jako bar graf oraz jako wodospad. Przełączenie wizualizacji odbywa się przez dotyk pola wizualizacji i nie zawsze się udało ze względu na małą odległość między ekranem trx-a oraz kamerą aparatu, bez tych utrudnień przełączanie rysikiem a nawet palcem działa bardzo dobrze.

Rozważam wyjście z akumulatorem i z kawałkiem drutu w jakieś odosobnione miejsce gdzie spróbuję zrobić rejestrację bez zakłóceń. Wspominałem już, że któregoś dnia zabrakło w okolicy prądu na 2 godziny i okazało się, że na paśmie słychać było wyłącznie stacje krótkofalowe bez grama zakłóceń. Niestety, nie mam wpływu na moment awarii lub prac planowych choć taka supermoc od czasu do czasu by się przydała ;-)

Tymczasem, analizując opisany wcześniej efekt odwrócenia wykresu przy zmianie wstęgi wpadłem na jeszcze jeden sposób tworzenia w środowisku programowym Waleta dolnej lub górnej wstęgi.

[Obrazek: https://lx-net.pl/walet/image/lsb_usb1.jpg]
Rysunek pokazuje wcześniej opisane metody oraz na dole dodatkową metodę, którą można osiągnąć identyczny efekt. Wystarczy w tym wypadku programowe przesunięcie transformaty Hilberta z kanału Q do kanału I. Ponieważ definicja filtrów jest częścią składową cyfrowej części obróbki sygnału to nie są potrzebne żadne dodatkowe modyfikacje sygnału w domenie analogowej przez zmianę dodawania I oraz Q na ich odejmowanie lub zmiany faz heterodyn mieszacza Tayloe.

Definicja filtrów wygląda następująco:

  inFiltered.setFilter(0, new FilterChain<float, 2>({ new BiQuadDF2<float>(b_lpf24_36, a_lpf24_36), new FIR<float>(hilbert_24_81) }));
  inFiltered.setFilter(1, new FilterChain<float, 2>({ new BiQuadDF2<float>(b_lpf24_36, a_lpf24_36), new FIR<float>(coeffs_delay_81) }));

Definicja ta może być zmieniana "w locie" i w chwili obecnej służy wyłącznie do zmiany filtra LPF z 3.6kHz na 2.4kHz lub na filtr pasmowy 800Hz.

  inFiltered.setFilter(1, new FilterChain<float, 2>({ new BiQuadDF2<float>(b_lpf24_36, a_lpf24_36), new FIR<float>(hilbert_24_81) }));
  inFiltered.setFilter(0, new FilterChain<float, 2>({ new BiQuadDF2<float>(b_lpf24_36, a_lpf24_36), new FIR<float>(coeffs_delay_81) }));

Zmiana wstęgi wymagać będzie po prostu zamiany indeksów 0 na 1 i odwrotnie jak pokazałem wyżej.

Opisana manipulacja jest najprostszą z możliwych zmian prowadzących do uzyskania odpowiedniej wstęgi i otwiera nowe możliwości związane z poprawą sygnału, szczególnie dla wyższych częstotliwości o czym napiszę wkrótce.

Teraz, kiedy "odkryłem" opisaną możliwość wydaje mi się ona tak oczywista, że sam się sobie dziwię dlaczego nie zauważyłem jej od początku. Mam nadzieję, że nie zanudzam tymi swoimi odkryciami kolegów, którzy o tym wszystkim bardzo dobrze wiedzą ale piszę o tym głównie dla podobnych do mnie eksperymentatorów w dziedzinie cyfrowej obróbki sygnału aby mieli trochę łatwiej.

cdn....  lj

Github