Transceiver wg. M0NKA

[SP9BSL]

(08-03-2018 13:32)SP3OSJ napisał(a):  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]

(08-03-2018 15:54)SP9BSL napisał(a):  

(08-03-2018 13:32)SP3OSJ napisał(a):  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ń: 612)

Eagle BPF 160/80:


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

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ń: 701)

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ń: 767)

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...).

[SP3OSJ]

.....

[SP9BSL]

Jeśli chcemy wymieniać procesor na większy - czemu nie. Myślę że znalazło by się miejsce dla SDRAM i innych kostek. To wymaga trochę pracy sprzętowej (najłatwiejsze) i przystosowania oprogramowania, myślę że są teraz ważniejsze zadania: Andrzej wspominał o konieczności zrobienia pakietu RF, tym bym się zajął jeśli nic odkrywczego w sensownym czasie nie zostanie wymyślone za zachodnią granicą.