(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.
(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:
[
attachment=13726]
Eagle BPF 160/80:
[
attachment=13727]
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):
[
attachment=13728]
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:
[
attachment=13729]
Zdaję sobie sprawę z ułomności moich pomiarów, ale lepsze to niż nic....
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.
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).
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.
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...).
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ą.