Transceiver wg. M0NKA

[SP9BSL]

Istnieje możliwość dopracowania pasma BPF od dołu na zakresie 1,8 MHz i od góry na zakresie 28 MHz.

Witaj,
To co napisałeś dotyczy także LPF.
Tego nie zrobisz bez dodatkowej gałęzi filtra dla 160m, poszerzenie pasma dolnego filtra spowoduje tylko że będziesz miał przy nadawaniu na 160m harmoniczne na 80m a przy odbiorze na 80m zakłócenia ze 160m... Poza tym SI570 źle pracuje na tak niskiej częstotliwości (lub wogóle nie chce, mam 2 kostki z tej samej serii i jedna chodzi a druga nie). Trzeba zmienić konstrukcję tego radia aby to miało sens. Tulipan ma więcej zakresów z osobnymi filtrami dla każdego.

[SP3OSJ]

.....

[SP9BSL]

Radio jest tak dobre jak najsłabsze jego elementy.

Dokładnie tak. I żebyś nie myślał że krytykuję Twoje wykonanie To jest po prostu problem prymitywnej konstrukcji mcHF.
Przetworniki to jedna sprawa, ale moim zdaniem ważniejsze są filtry które przed/za nimi pracują - dobry pomysł z Avali.

[SP2GNB]

Radio jest tak dobre jak najsłabsze jego elementy.

Dokładnie tak.

A dokładniej i obrazowo jakość radia jest iloczynem jakości poszczególnych podzespołów składowych. Wiem na co stać Tulipana, zwłaszcza z filtrami wg Waldka SP4JJH, wiem na co stać M0NKA. Chris popełnił radio ze wszech miar kompromisowe i jako takie należy je traktować. Arturowi SP3OSJ udało się z niego wydostać (tak uważam) wszystko co możliwe hardwerowo, a Sławkowi SP9BSL (& Co) - softwerowo.
Czekam z niecierpliwością na hardware SDR OVI40 Andreasa. Zapewne będzie to również jakiś kompromis, zobaczymy jaki głęboki...

Żeby nie być gołosłownym - Tulipan BPF 1,8 MHz:


  1_8.pdf (Rozmiar: 20.31 KB / Pobrań: 819)

Eagle BPF 160/80:


  BPF_3_5.pdf (Rozmiar: 19.5 KB / Pobrań: 813)

I na koniec ciekawostka: Eagle pracując na 1,9 MHz nie "śmieci" mocno na 3,8 MHz (-40 dBVrms), a "śmieci" zdrowo na 5,2 MHz (-20 dBVrms):


  1_8_10W.bmp (Rozmiar: 329.12 KB / Pobrań: 932)

To pasmo mało mnie interesuje, a po za tym mój dopalacz ma ostre LPF na wyjściu...
I dla porównania FFT z 7 MHz:


  7_12W.bmp (Rozmiar: 329.12 KB / Pobrań: 1,012)

Zdaję sobie sprawę z ułomności moich pomiarów, ale lepsze to niż nic....

[SP9KN]

Czy autorzy projektu wzięli pod uwagę zastosowania innego wyświetlacza?
Konkretnie chodzi mi o wyświetlacze NEXTION, które są wyposażone w własny flash, rtc,, na grafice oszczędza się sporo miejsca a i prędkość ładowania grafiki jest sporo większa. Samo podłączenie wyświetlacza odbywa się po porcie szeregowym wiec sporo PINów pozostanie wolnych.

Sławek to pytanie w zasadzie do Ciebie, co o tym myślisz? Może się nie nadaje ten wyświetlacz, ale mimo wszystko jestem ciekaw opinii.

[SP9BSL]

Przemek,
problemem nie jest wyświetlacz/pamięć ale interface. W tym przypadku zależy nam na szybkim odświeżaniu dużej ilości danych. Problemem jest maksymalna przepustowość portu SPI w STM. Dużym ułatwieniem jest funkcjonalność którą ma RA8875, mianowicie sprzętowy scrolling w dowolnym kierunku, coś co w obecnym ILI9486 nie działa prawidłowo. Po co nam to? Ano teraz dla wysłania wodospadu trzeba wysyłać każdorazowo ilość linii*szerokość, w RA8875 będziemy wysyłać 1 linię bo pozostałe będą się przesuwać o jedną pozycję w dół. Dlatego następnym wyświetlaczem który będziemy implementować jest właśnie taki jak w Tulipanie. W zasadzie rozwijać bo częściowo to już w obecnym kodzie jest. Inne wyświetlacze: jeśli ktoś znajdzie coś co działa tak jak RA i będzie o połowe tańsze to czemu nie. Obecny wyświetlacz 480x320 (ILI9486) ma najlepszy stosunek jakości do ceny (jest nawet tańszy od HY28).

[SP3OSJ]

.....

[SP9BSL]

480x320x2=307200 bajtów. STM32F4 ma 256kB RAM, F7 trochę więcej a gdzie do 800x480. Bez SDRAM nie da rady... Może w H7 ale na razie errata do niego ma 21 stron.

[SP3OSJ]

.....

[SP9BSL]

IS42S16400J to właśnie SDRAM dla frame buffera. Na upartego dało by się skonfigurować tak LUT do RGB aby zmieścić się w ~150kB dla 480x320 w trybie 8 bit, ale 800x480 już nie zmieścisz. F746 ma 320kB ram.

---

Chodzi także o to że musiałby być drugi procesor bo jak dasz SDRAM + LCD to po prostu zabraknie nóżek w procesorze dla normalnych zadań (kodeki, klawiatura itd...).