HomeMade

Ciekawi mnie w jaki sposób zrealizowałeś komunikację Arduino z programem do JT w komputerze.

Mnie bardziej interesuje implementacja nadawania JT w RPi. Nie potrzeba tu dodatkowo DDS-a, a w połączeniu z obsługą odbiornika SDR (jest program + mamy gotowe VFO) i ewentualnym programowym przełączaniem filtrów via GPIO dałoby to TRX-a. Póki co widzę jednak tylko rozwiązania dla WSPR, które swoją drogą działa mi tak, że 1mW daje nawet 1000 km, 50mW Stany, a pół wata VK/ZL...

Cześć Leszek,

nadawanie jest niezależne od aplikacji - komunikat jest podawany przez port szeregowy - ale myślę, że skoro WSJTX jest open-source i w Pythonie, to powinno dać się to połączyć - może w wolnej chwili spróbuję.

Co do RPi, to sądzę że najłatwiej byłoby zmodyfikować WsprryPi - WSPR, JT9 i JT65 to prawie to samo od strony technicznej, różni się czas trwania symbolu, odstęp w częstotliwości i ilość nadawanych symboli.

(23-05-2016 20:15)SQ3SWF napisał(a): [ -> ]Rozpisałem sobie nadawanie JT65, JT9 i WSPR z AD9850 i Arduino. Sprawa jest dość prosta (wręcz banalna), myślę że BS170 na wyjściu + dobry low pass powinny zaobfitować w QSO.

Jak ktoś jest chętny, to oczywiście kodzik mogę udostępnić.

Jeśli możesz pokazać jakieś kawałki kodu z komentarzem to ja chętnie rzucę okiem.

Uzywanie tutaj RB PI to lekki przerost formy nad trescia... tutaj transceiver mozna zrealizowac na ciut szybszym procku niz leciwy AVR... a moze i optymalnie to piszac w ASM + lekkie przetaktowanie i moze AVR by dal rade...

Tomek - tu raczej chodzi o to, że RPi może generować sygnał, samo bez żadnych dodatkowych układów, a co ważniejsze - wsjt(x) działa na nim bez problemu. O ile nadawanie JT jest względnie proste, to odbiór opiera się na fortranowej matematycznej magii pana Taylora i nie widziałem żeby ktoś napisał własną aplikację do odbioru (no dobra, ja napisałem, ale radziła sobie tylko z pojedynczym sygnałem bez szumow ).

Rysiek - pędzę właśnie z długiego weekendu w tatrach do SP3, jeśli czas pozwoli to jutro delikatnie okomentuję kod wrzucę do repozytorium na github. :-)

Bo to tylko kwestia szybkosci GPIO... Ale tak na prawde nie do konca bo przykladowo w niektorych wypadkach takie ARM-y maja GPIO wolniejsze od AVR-a (np. dlaczego STM32 wolniej miga LED-em niz AVR)...

W obecnych czasach wlasnie problemem jest to ze wybieramy albo stary procek (AVR), ja je uzywalem gdzies jako zamiennik 8051 chyba od 99r Wszystko to jest powodowane tym aby orpogramowanie tego bylo jak skladanie klockow lego (latwe i nie wymagajace myslenia), przez to rosna wymagania ze nagle do byle pierdoly bierzemy procek z taktowaniem 500MHz i wiecej

Natomiast co do pisania programu, to nie jest to trudne... trzeba checi i zaciecia i to tez jest glowny problem... Sam kiedys chcialem robic fajne DIGI do APRS... zrobiony jest soft w 90% calosc dekodowana w procku (DSP), fajne filtry cyfrowe i kupe innych funkcji (ethernet - mozliwosc pracy jako igate itp.)... zainteresowanie niemal na poziomie zera... wiec projekt lezy i czeka na lepsze czasy...

W tym watku problemem jest uzycie wbudowanego np. bootloadera w NWT i z dwie godziny przy MPLAB X aby zrobic nowy wsad dla PIC-a

Dlatego napisalem ze to troche przerost formy nad trescia (albo strzelanie z armaty do muchy), moze kogos to zmotywuje do dzialania... kupienia za 20zl jakiegos Cortexa i zrobienie tego

Natomiast co do dekodowania to tutaj znowu kwestia tego jak szybki procek, AVR nawet dla prostych filtrow FIR (spora liczba mnozen) jest zbyt wolny i trzeba by isc na kompromisy obliczeniowe (np. uzyc IIR)... wybierajac jakiegos Cortexa spokojnie juz sie wyrobimy w czasie... a biorac jakiegos Cortex M4F to juz mamy go az nadmiar...

Generalnie obecnie DSP zajmuje sie troche zawodowo, a w sumie radarami itp. i wiem ze tematy DSP za zwyczaj w PL koncza sie dla wielu po studiach, a troche szkoda - choc wlasnie takie procki jak kortex M4F czy nawet Cortex M3 daja juz jakies tanie platformy do zabawy z cyfrowa obrobka sygnalow... wiec moze cos sie w tym temacie ruszy...

Ja za projekt sie nie wezme tez z tego wzgledu ze na tapecie mam dosc rozbudowany pomysl DSP do transceivera KF... zapewne za jakis czas bedzie tutaj temat jak sie uda ogarnac wszystkie problemy... tzn. odwieczny kompromis dostepnosci czesci/ceny/uzyskanych efektow... Praktycznie w calym DSP matematyka to nie jest jakis tam wielki kosmos, wiecej czasu zajmuje dobranie odpowiednich algorytmow... ale to znowu omijam sporo prototypujac w Matlabie/Symulinku gdzie czlowiek skupia sie nad sama istota, a nie pisaniem od podstaw w C/C++/ASM byle filtru Jak rozwiazanie sie sprawdza dopiero przenosze na kod danego procesora...

W sumie odnosnie radarow to tez ostatnio wpadlem na taki pomysl ile da sie zrobic z gratow mikrofalowych jakie mam w domu w stosunku do tego co sie robi za gruba kase w firmie https://www.youtube.com/watch?v=niq1P2mCoSw - tez bedzie troche DSP i zobaczymy co uda sie wyciagnac za smiesznie niska kase... oczywiscie docelowo nie bedzie to radar CW Ale to juz raczej troche chyba odbiega od pracy na naszych pasmach - chyba ze beda zianteresowani to opublikuje wyniki na forum...

http://pastebin.com/gY08uck1

Tutaj kod, zachęcam do testowania.

Bardzo skrócona instrukcja użycia:
1. Do kompilacji potrzebna jest biblioteka JTEncode - instalujemy przez wbudowanego w środowisko Arduino "Library Managera" - początkowo sam przpeisałem proces kodowania wiadomości na język C, ale ta implementacja jest zdecydowanie lepsza.

2. Po zaprogramowaniu podajemy na port szeregowy kolejno 3 wartości:
tryb nadawania: 1 - JT65, 2 - JT9
treść wiadomości
częstotliwość - jako odstęp od "bazowej"

Muszą one być odseparowane od siebie znakiem nowej linii. Po wciśnięciu ostatniego entera rozpocznie się nadawanie, po nadaniu całości DDS wróci na częstotliwość "bazową" (dla 20m: 14076kHz).

Przykładowa komenda sterująca:
1\nSQ3SWF CQ\n1200\n - nada emisją JT65 wiadomość o treści "SQ3SWF CQ" na częstotliwości 14077,2 (14076 + 1,2).

Zachęcam do testów

Napisałem też małą aplikację w pythonie do wygodniejszego nadawania, działa pod linuxem, pod windowsem bez przeróbek nie ma szansy - kod (okropny - pisane na bardzo szybko) tutaj: http://pastebin.com/656Z5KdM - po kliknięciu guzika "enable tx" program czeka do pełnej minuty i dopiero wtedy wysyła ciąg sterujący.

Tak to wygląda u mnie: http://i.imgur.com/3OPVgmv.png

Przepraszam ja byłem z pieskiem czy bez pieska? Może mi coś umknęło ale NWT-7 jest na PICu a nie na AVR'e? Przynajmniej te wersje które znam

Karol - niestety temat skręcił trochę na boczne tory Nadawanie z NWT przeszło płynnie w nadawanie z DDSa, jak DDS to ad9850, a jak sterować, to po taniości - arduino. No to wrzuciłem kod arduinowy

A ja sadze ze najtaniej to posiedziec troche i napisac kod dla PIC-a.
Fakt PIC16 ma swoje ulomnosci i tak srednio pisze sie w C, ale sie da Trzeba sie przyzwyczaic do obslugi przerwan w jednej funkcji i sprawdzanai flag co je wywolalo itp.

Wysterowac ad9850 to tez nie problem, z reszta podobnie. Wiekszosc kodu w C nie zwiazanego z peryferiami mozna spokojnie przeniesc z kazdego procesora. Sciagajac MPLAB X i kompilator xc8 ma sie 60 dni na kompilacje z opcja optymalizacji PRO...

Jak ktos radzi sobie z AVR-rem to troche klnac na mniejsza elastycznosc poradzi sobie z tym w jeden dzien...

Wada taka ze trzeba przeprogramowywac NWT w zaleznosci od potrzeb - no ale oszczednosc na calym hardware (cos za cos).

Ja nawet jak bym znalazl czas to moge taki kod przygotowac jedynie dla NA200...
...jak bedzie zainteresowanie na ten model NWT to prosze napisac...