Synteza SPHM DDS

[SP5FCS]

(16-08-2011 23:15)sp3nyf napisał(a):  Z własnego doświadczenia wiem, że dla mnie istotne jest, żeby przy zmianie pasma wrócić do następujących nastaw:

(częstotliwość, modulacja, numer wejścia antenowego, filtr, moc, nr VFO, krok przestrajania)

Sporo tego, a tak z ciekawości to które radio fabryczne daje takie możliwości?
Modulacja, nr. anteny, filtr, może krok OK, moc nie rozumiem po co?

W tej wersji syntezy nie ma pojęcie VFO , tym bardziej kilku VFO od tego jest RIT, SPLIT, wirtualny odbiornik i 10 pamięci na każde pasmo.

EEPROM nie nadaje się na pamięci ze względu na ograniczoną ilość zapisów, tam możemy zapisywać rzadko zmieniane nastawy konfiguracyjne czytane po włączeniu radia. Pamięci muszą być robione na RAM-ie procesora, który musi mieć podtrzymanie bateryjne.

Schemat, to tak naprawdę procesor "rozszyty" na złącza, peryferia typu DDS, BFO, rejestry na oddzielnych płytkach. Tak jest łatwiej robić prototyp.

Koledzy, pomysły są bardzo ciekawe ale budujemy nową syntezę a to już zaczyna przypominać rozbudowany komputer pokładowy do "wypasionej fabryki". Do tego dojdzie jeszcze sterowanie automatyką, modułem DSP oraz skrzynkami antenowymi i przełącznikami.

Takie elementy jak klucz CW, rejestrator cyfrowy, czy mimi logger na karcie SD należy robić na oddzielnych sterownikach jako opcjonalne moduły.

Drugi problem to czas no i ktoś to musi zrobić, nie mamy do dyspozycji biura projektowego Icom-a i tysięcy $ na opracowanie. Warto podnosić poprzeczkę aby projekt był ciekawy ale musi być również realny w wykonaniu w rozsądnym czasie.

Może znajdą się koledzy chętni pociągnąć jeden z wydzielonych cyfrowych modułów.

[SQ6ADE]

EEproma wystarczy dobrze obsługiwać - tzn nie traktować go jako RAM
i zapisywać dane przy każdym dotknięciu klawisza ( ekranu).
Po restarcie sys'a wyciągnąć dane z EE a zbuforować je w EE po wyłączeniu urządzenia lub stwierdzeniu przez uP zaniku zasilania.

EE dłużej wytrzyma niż bateryjka do podtrzymania pamięci.

Co do systemu wieloprocesorowego - przy takim "wypasionym" ekranie
wydaje się że powinien być osobny uP do jego obsługi (TFT + dotyk).
Coś w rodzaju terminala który współdziałałby z głównym uP.
Wtedy można taki "terminal" potraktować nawet jako odłączany panel
tak jak się to dzieje w fabrycznych klockach. Nawet te które nie mają
osobnego panela mają z reguły osobny uP który siedzi we froncie
TRX przy wyświetlaczu i klawiaturze.
Ilość danych wysyłana pomiędzy "terminalem" a głównym uP
może być naprawdę skromna i nie musi być jakiejś mega szybkości transferu jeśli uP "terminala" wstawi w grafikę kilka danych i odeśle do głównego uP kod naciśniętego "przycisku".
Ba - terminal taki może być uniwersalny "hardwarowo" i posłużyć
do innych zabawek.
Oczywiśie enkodery musiały by być podłączone do głównego uP.

Rzadko (lub wcale) widuje się fabryczne klocki w których jakaś jedna "stonoga" ma na głowie wszystko

(Już tak mam że odgapiam od fabryki - mądrzejsi już myśleli nad
sprawdzonymi rozwiązaniami. )

[SP9MRN]

Jak jest split i rit, to ja z xita w zasadzie nie korzystam, ale ponieważ jest w większości fabrycznych urządzeń, to może warto się nad nim zastanowić.
Ale DLA MNIE, to niepotrzebny gadget.

Jeżeli chodzi o pamięć nastaw, to przyzwyczaiłem się - ale można zmienić przyzwyczajenia - że jak zmieniam pasmo - a potem na nie wracam, to wracam do porzednich nastaw - qrg, wstęga, mod - ale jak są pamięci, to tego nie potrzebuję :-). Nie potrzebuję natomiast zapamiętywania nastaw po wyłączeniu zasilania. W takich przypadkach najchętniej używam wbudowanego w mózg random generatora :-)

Co bym chciał -
1. sekwencyjna zmiana pasma guzikami "góra-dół" - i to taką mechaniczną klasyką
2. obsługę wyższych pasm (50, 70) (bezpośrednio) i transvertera na 2m i 70cm (czyli możliwość wprogramowania częstotliwości zewnętrznej przemiany i wyświetlanie na LCD rzeczywistej QRG pracy)
No i chyba tyle.
Oczywiście to tylko mój "dream list" a nie wymagania - to co pokazujesz jest i tak wystarczająco fajne.

73
MAc
mrn

[SP3SWJ]

:-) Maciek .... to tobie wystarczy moja przeróbka DL4JAL... po co ci więcej :-)

CAT a nie wymieniłes ;-)

[SP5FCS]

Procesor ma 2-4k EEPROMU i 4-16k RAM-u wewnętrznego, dlatego to najpierw trzeba wykorzystać, nie ma sensu stawianie w tej chwili dodatkowej pamięci zewnętrznej.
Ze względu na wykorzystanie wewnętrznego generatora 32kHz do realizacji zegarka procesor i tak musi mieć podtrzymanie bateryjne dlatego nie ma problemu z pamięciami. Ważne dane konfiguracyjne radia do EEPROM-u, dane eksploatacyjne do RAM-u.

Pomysł kilku procesorów jest fajny ale rosną koszty i układ mocno się komplikuje np. karta SD może być wykorzystana do programowania sterownika nowym softem, przy kilku procesorach jest już problem.

Wszystkie pomysły i propozycje są cenne jednak ze względu na realizację podzieliłbym je na "takie na już" i "takie na przyszłość". Ważne jest aby powstała w pełni funkcjonalna wersja "beta" gotowa do testów w radiu.

[SP3SWJ]

Adam - jak słusznie napisałeś - z wielu wielu wyminionych funkcji trzeba wybrać fe funkcje "na już" :-) ale warto pamiętać o możliwych technicznie funkcjach by płytki sprzętowo przygotować na ich późniejsze oprogramowanie.

ADE - Panel zewnętrzny - to problem mechanicznego wykonania radia - lepiej po prost zrobić dobrą implementację CAT zgodną np popularnym Yaesu FT897 - a w przyszłości dorobić panel który będzie po RS232 mógł sterować Husarem - albo nawet dowolnym Yaesu.

Jeśli np dawać FT232 - to lepiej dac FF2232 - czyli podwójny USB w jednej obudowie - i podpiąc do dwóch UARTów - lub jednego zostawić nawet na złączkach. ( drugi RS może sie przydać do funkcji rotora - a układem wykonawczym rotora może byc częśc procesorowa od eATU na RS485 )

.... By nie przeginać z wymyślaniem - niezbędne minimum to to co dałem w przeróbce DL4JAL (zresztą nie jest to żadnym odkrywczym wynalazkiem - podobnie jest w radiach fabrycznych ) ...

[SP9MRN]

(17-08-2011 10:42)SP3SWJ napisał(a):  :-) Maciek .... to tobie wystarczy moja przeróbka DL4JAL... po co ci więcej :-)

CAT a nie wymieniłes ;-)

Oj Magik, reszta - Caty, bajery to Adam już przewidział, ja tylko piszę o tym, czego nie zauważyłem.

Na przykład nie cierpię klawiatur :-) wolę kilka konkretnie przypisanych guzików, a rozwiązanie z (np) Pilgrima jest dla mnie "nieprzyjazne" szczególnie w kontekście małej obudowy.
Wolałbym "up-down" niż 3x4

MAc

[SP3SWJ]

dlatego prawie wszystko będziesz mógł załatwić z dotykowego LCD :-) ... ale dużego :-) byś nie musiał wykałaczką i lupą obsługiwać :-)


Maciej - ta klawiatura linkowana powyżej ( i program ) był tak napisany że "obowiązkiem" było dać tylko cztery klawisze... później można było sobie dodać wg uznania kolejne klawisze z "czarnymi" funkcjami - wg potrzeb i miejsca jak komu pasuje... a jak ktoś miał ochotę dawał full kiborda... albo dorabiał z tyłu złącze do podpinania full kiborda - tylko jak miał na to ochotę.


Roumiem potrzebę uniwersalności... fajnie jeśli nie wymaga ona żadnego skomplikowanego konfigurowania. Ale inny będa chceli pełen numeric kibord + dedykowany klawisz do każdej funkcji.... ten przy gałce VFO a inny przy gałce RIT. Jeden Rita obsłuży z gałki VFO - inny chce dedykowaną gałkę...Inny chce impulsatory z wciskaną gałką... inny odwrotnie... a z kolei inny chce kręcony przełącznik pasm - bo tak lubi... i weź tu Panie pogódź wszystkich.....

[SP5FCS]

Jarek, oczywiście da się tak zrobić aby każdy miał tak jak lubi czyli inaczej i po swojemu. Stawiamy drugi procesor Xmega64, który obsługuje tylko "gałkologię", kilka enkoderów, klawiaturę, klawisze funkcyjne, wszystko co kto sobie wymyśli. Wyniki testowania zapisuje w tablicy zmiennych i zgłasza przerwanie do procesora głównego. Główny procek pobiera dane poprzez SPI z procesora od klawiszy i jest mu to zupełnie obojętne czy enkoder to dwa klawisze, potencjometr czy prawdziwy enkoder.

Jest tylko mały problem, pomysły łatwo przychodzą do głowy tylko chętnych do ich realizacji nie widać (tzn. widać na horyzoncie, dwa lata maszerujemy w kierunku horyzontu ale ciągle nam do niego daleko).

[SP3SWJ]

To jednak lepiej to zrobić jednak na CAT - tylko jeden wysiłek na jeden interfejs - i tak potrzebny - bo nie wyobrażam sobie radia tego typu bez CAT.

CAT pracujący wewnętrznie z 115kbpsów bedzie wystarczająco szybki do takich manipulatotrów - i i interfejs otwarty standardowy i każdy może sobie zrobić/ użyć panel jaki mu sie spodoba - a nawet jak niebawem pokażą się programy na Androida - to CAT zgodny z popularnym radiem jest jak najbrardziej na miejscu... Może jestem w błędzie - ale CAT do FT897 jest wystarczająco dobrze udokumentowany i dzięki "półbinarnej" konstrukcji jest nawet szybki. A resztę brakujących funkcji będzie można dodać na własnych "komendach" zgodnych z protokołem.

Pomysł z SPI jest fajny... ale jest "zamknięty" - i nie trzeba będize didawac kolejnej funkcjonalności do testowania.

Trzeba się starać wymyślać sposoby które będą "wielozadaniowe".

Tak mi się przypomniało że FT897 ma nawet dwa porty CAT i obydwa działają równolegle i niezależnie... śmiesznie jak steruje się radiem z dwóch różnych programów....