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

[SP6FRE]

Wczoraj, między godziną 16 a 18 miałem chwilę mobilizacji i wybrałem się "w teren" aby sprawdzić jak działa odbiornik i wodospad w nieco lepszych warunkach niż w moim domu.

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

Nagrania podzieliłem na te dotyczące CW i te zarejestrowane emisją SSB - większość z nich to nagrania na 3.5MHz.

Emisja CW:
Rejestracja CW - 1
Rejestracja CW - 2
Rejestracja CW - 3
Rejestracja CW - 4
Rejestracja CW - 5
Rejestracja CW - 6
Emisja SSB:
Rejestracja SSB - 1
Rejestracja SSB - 2
Rejestracja SSB - 3
Rejestracja SSB - 4

Urządzenie było zasilane z akumulatora 12V a antena to "LW ad hoc" czyli ok. 30m drutu zawieszonego na drzewach i krzewach na wysokości ok. 1.5m w odległości ok. 200m od najbliższych bloków. 
Byłem mile zaskoczony aktywnością stacji na 3.5MHz bo w warunkach domowych nie udaje mi się odebrać żadnej stacji z tego pasma właśnie ze względu na poziom zakłóceń.

Na kilku nagraniach widać w jakich warunkach robione były nagrania - po prostu klęczałem na trawie trzymając między nogami urządzenie. 
Jedną ręką przestrajałem odbiornik  a w drugiej ręce trzymałem aparat. W tych warunkach od czasu do czasu musiałem regulować odległość telefonu kiedy tracił ostrość oraz pocelować po ciemku palcem na ekran kiedy chciałem wykonać jakieś przełączenie.
Rejestrację zacząłem kiedy jeszcze było jako tako jasno a kończyłem w całkowitych ciemnościach co można rozpoznać z jednej strony po widocznej lub niewidocznej atrapie oraz po nasyceniu kolorów. Im ciemniej tym większy kontrast i mniej kolorów widocznych na ekranie.

Stacje słyszalne na nagraniach "widać" w wodospadzie z lewej strony zera częstotliwości jeśli odbierana była dolna wstęga czyli na 3.5MHz i 7MHz oraz powyżej zera dla pasma 14MHz.

Na nagraniach udało mi się nagrać, po kilka sekund, kilka polskich stacji. Mam nadzieję, że nagrani koledzy nie sprzeciwią się tej rejestracji ale w każdej chwili mogę te nagrania usunąć.

Próbując odsłuchu proszę o cierpliwość. Najdłuższe nagranie ma chyba 40MB. Nagrania źródłowe z telefonu mają pojemność około 10 krotnie większą. Dla potrzeb prezentacji wykonuję konwersję ze zmniejszeniem rozdzielczości do akceptowalnego poziomu za pomocą ffmpeg i własnych skryptów.

cdn... lj

Github

[SP6FRE]

Pisałem już o tym w #32, że układ formowania heterodyny dla mieszacza Tayloe nie jest idealny. Dla przypomnienia, zauważyłem, że dla częstotliwości ok. 22MHz w generowaniu sygnałów heterodyny powstaje "dziura", która następnie zanika dla wyższych częstotliwości.

[Obrazek: https://lx-net.pl/walet/image/het_tayloe.jpg]
Układ formuje na wyjściach Q (5 i 9) przerzutników D sygnały o dwukrotnie mniejszej częstotliwości niż zegar Clk podawany na wejścia bramek XOR (5/U11B i 9/U11C).  Dodatkowo, sygnały te są przesunięte względem siebie o 90 stopni a o tym, który z sygnałów wyprzedza drugi decyduje poziom logiczny na wejściu 12 bramki U11D. Sygnał ten jest uzależniony od wyboru wstęgi przyciskiem Up/Dn na ekranie lub automatycznie dobierany w zależności od częstotliwości pracy ale generalnie poniżej 10MHz działa dolna wstęga a powyżej górna.

[Obrazek: https://lx-net.pl/walet/image/digi02sch.jpg]  [Obrazek: https://lx-net.pl/walet/image/digi02gra.jpg]
Zrobiłem cyfrową symulację tego układu za pomocą Qucs i widać jak dla sygnału rodzaju wstęgi sw (S2) sygnały hetrodyn o1 i o2 zamieniają się miejscami w połowie wykresu zachowując jednocześnie częstotliwość dwukrotnie mniejszą niż sygnał zegara cl(S4).
Oczywiście symulacja ta jest pewnym założeniem dla idealnych elementów  z nierealnymi czasami analizy rzędu 2ns dla zegara czyli dla częstotliwości 500MHz.

W rzeczywistym układzie mamy do czynienia z co najwyżej częstotliwością 30MHz czyli z zegarem o okresie ok. 33ns a raczej z półokresem rzędu ok. 16.75ns bo układy reagują zarówno na narastające jak i opadające zbocza.

Analizując wykres wodospadu fft dla każdego z pasm stwierdziłem, że do 21MHz sygnał np. generatora pojawia się po prawidłowej stronie zera wykresu ale dla pasm 25 i 28MHz jest odwrócony co tłumaczy chyba dziwne zachowanie heterodyn z postu #32. Prawdopodobnie, czasy propagacji oraz poziomy narastania i opadania sygnałów powodują, że do ok. 22MHz układ działa poprawnie ale powyżej tej częstotliwości następuje niepożądana inwersja sygnałów heterodyn.
Jest to prawdopodobne bo przeciętne czasy propagacji bramek oraz przerzutników wynoszą ok 5-6ns ale jak się ma pecha to i 10-12ns więc w ciągu dwóch elementów: bramka/przerzutnik czasy propagacji mogą wynosić od ok. 10ns do 24ns a więc stają się porównywalne z okresem zegara powodując prawdopodobnie obserwowaną "dziurę" w działaniu..

Dlatego pożądane jest aby zamiast układów z serii AC zastosować tu układy typu ACT a więc 74ACT86 oraz 74ACT74. Układy te mają nieco mniejsze czasy propagacji a dodatkowo mają niższe poziomy wyzwalania niż seria AC co korzystnie wpłynie na współpracę z generatorem si5351 zasilanym z napięcia 3.3V.

Niestety, nie mam analizatora stanów logicznych aby zarejestrować opisane zjawisko dokładniej i nie mam również układu 74ACT86 a tylko 74ACT74 oraz 74ACT04 (sześciokrotny inwerter) co posłużyło mi do wykonania kolejnej symulacji.

[Obrazek: https://lx-net.pl/walet/image/digi03sch.jpg]  [Obrazek: https://lx-net.pl/walet/image/digi03gra.jpg]
W tym układzie działają dwa przerzutniki typu D (74ACT74) oraz jeden inwerter (74ACT04) co powoduje, że ilość elementów jest minimalna. Układy pracują z mniejszymi czasami propagacji niż poprzednio ale nie ma możliwości zmiany sygnałów heterodyny miejscami więc nie można w tym układzie zmieniać wstęgi.
Ale ponieważ, jak opisałem to wcześniej, pojawiła się trzecia, programowa możliwość zmiany wstęgi za pomocą umiejscowienia filtra Hilberta w torze sygnału I lub Q - w części cyfrowej - to można takie rozwiązanie zastosować mimo ograniczenia.
Po niezbędnej modyfikacji oprogramowania zmontowałem pokazany wyżej układ i okazało się, że całość pracuje poprawnie (co do rodzaju wstęgi) do częstotliwości 30MHz.

Niestety, dla częstotliwości powyżej 15MHz zauważalne jest pogorszenie tłumienia niepożądanej wstęgi bardzo wyraźne już dla pasma 25 i 28MHz. To niestety wynika z właściwości wszystkich elementów biorących udział w przemianie od generatora si5351, przez mieszacz fst3253 na układach bramek i przerzutników kończąc.

Teraz, kiedy wstęgę daje się uzyskać w sposób programowy spróbuję wrócić do zarzuconej koncepcji zasilania mieszaczy heterodynami wprost z układu si5351. Pisałem o tym wcześniej, że z pierwszych prób nie byłem zadowolony bo zachowanie różnicy faz 90 stopni między dwoma sygnałami z si5351 wymaga resetu pętli PLL tego układu dla każdej zmiany częstotliwości co objawiało się u mnie stukami podczas przestrajania. Postaram się poświęcić tej sprawie nieco więcej czasu i w razie potrzeby skontaktuję się z autorem biblioteki Etherkit obsługującej generator si5351 aby wyjaśnić ewentualne wątpliwości. W każdym razie wydaje się, że im mniej elementów w torze formowania heterodyn tym lepiej dla parametrów urządzenia.

Postaram się wkrótce zamieścić na Github kolejną wersję oprogramowania nie wymagającą zmiany wstęgi w sposób sprzętowy.

cdn... lj.

Github