Tomek, wciąż nie wiem czy mówisz tylko o nadawaniu czy także o odbiorze. Pierwsze jest banalne, więc zakładam że nastawiasz się na odbiór.

"najtaniej to posiedziec" - myślę że mało który programista podejmie się przepisania fortranowych czarów Taylora na C za kwotę 200pln które trzeba wydać na raspberry pi 3 - chociaż nowy dekoder w wsjt(x) ponoć miał być napisany w C, co zdecydowanie ułatwiłoby przenoszenie kodu.

Nie wiem jak Twoja znajomość dekodowania JT65/JT9, ale myślę, że więcej nakładu czasowego przypada tutaj na "końcowe" etapy, tj. mając już wyodrębione symbole: zdekodowanie reeda-solomona, oczywiście jeśli odbierzemy 100% komunikatu to nie ma z tym problemu, schody zaczynają się gdy sygnał jest bardzo słaby i część symboli zostanie zgubiona - oryginalna aplikacja radzi sobie do -26/-29dB (JT9), z własną implementacją może być ciężko zbliżyć się do tego wyniku. Łatwo mówić - trudno zrobić. I w sumie nikt jeszcze nie zrobił nieoficjalnego dekodera dla JT. (JT65-HF wykorzystuje binarki Taylora)

W przypadku NWT mowie tylko o nadawaniu, ten PIC jest za cienki by cos na nim wiecej zrobic, a i tak prze odrebna pamiec dla programu i danych trzeba by sie troche pogimnastykowac piszac to w C (aby zaraz tej pamieci nie braklo)...

Do odbierania raczej jakis ARM Cortex... aby nie trzeba bylo magii w asemblerze odstawiac i przetaktowywac jakiegos procka...

Natomiast co do slabego sygnalu to sie akurat nie boje... to jest bardzo prosta transmisja i do tego wolnozmienna z rekonstrukcja nawet szczatkow znajdujacych sie ponizej szumu nie powinno byc problemu... Z tym ze jak pisalem akurat na to w chwili obecnej nie znajde czasu... ale mysle ze za jakies max 2 miesiace jak sa chetni bedzie mozna z tym powalczyc, musze po prostu zamknac dwa komercyjne projekty ktore zjadaja mi nieal caly wolny czas... a ten co zostaje poswiecam na kilka hobbystycznych ktore prosza sie o ukonczenie juz od dluzszego czasu.. Najwiekszy u mnie problem to to ze bede musial sobie przygotowac jakikolwiek prowizoryczny uklad antenowy (a to troche zajmie), bo obecnie nie mam juz nawet sprawnej anteny na 2m/70cm nie wspominajac o KF-e na ktory nie mam nawet obecnie druta za oknem...

Natomiast to ze ktos tego jeszcze nie zrobil to zapewne brak zainteresowania ta transmisja mnie ona tez tak srednio interesuje he he, bardziej bym z ciekawosci do tego siadal... z drugiej strony sam wiem jak trundno w naszym srodowisku zorganizowac jakas ekipe ktora cos na prawde zrobi w kwestiach programowania itp, bo juz pare razy probowalem i wyszly z tego nici.. to tez jest tam zapewne jakas przyczyna... Natomiast jak cos powstaje to za zwyczaj jest to zamkniety projekt lub komercyjny...


BTW tutaj wlasnie sie trzeba skupic nad odpowiednim dekodowaniem symboli nie wiem jak to realizowales ze byl z tym problem (mam nadzieje ze nie jakimis prostymi filtrami)... Reed-Solomon to wlasnie jest niemal na koncu gdzie masz juz tylko korekcje i info o tym czy zdekodowales prawidlowo bity...

Nie potrzebujesz anteny, wygenerowanie wejściowych plików *waw to jest kwestia minut (ze stosunkiem sygnału do szumu jaki chcesz + QSB).

Trochę już nie pamiętam mechanizmu dekodowania, ale możemy spróbować. Obawiam się niestety, że źródła tego co miałem napisane poleciały mi z awarią dysku, ale przy wolnej chwili spróbuję coś napisac dla JT65. W czytaniu fortrana jestem słabiutki, więc chyba polecę metodą na styl:

1. Znajdź sygnał JT65 w spektrum - FFT z kompletnej minuty
2. wyszukanie peaku w dziedzinie częstotlisości (ton synchronizacyjny)
3. FIR z ostrymi zboczami, znalezienie początku nadawania (w dziedzinie czasu)

Przy samplowaniu 11025Hz, każdy symbol trwa 4096 próbek, więc z takich okienek można robić sobie FFT i szukać peaków, albo sprawdzać korelację. Bez ekstrapolacji wyjdzie nam szerokość (rozdzielczość) kubełka FFT równa 11025Hz / 2 / 2048 = 2.69Hz... czyli wypisz wymaluj odstęp między tonami

Jak się na to patrzy, to w sumie nie wygląda szczególnie skomplikowanie. Oczywiście potem z tymi symbolami trzeba coś zrobić. Wydaje mi się że Joe przestał używać zamkniętego (binarka) dekodera K-V i teraz "mielenie" reeda solomona jest robione w C. Muszę dobrze poczytać update'y na liście dyskusyjnej.

Ciekawe rzeczy piszecie i dobrze się czyta.
Jako źródło sygnału nie trzeba mieć anteny, a jak ktoś nie chce generować wave'a to można użyć pierwszego lepszego SDR, websdr itp których pełno w sieci

No ja jeszcze nad konkretnym sposobem dekodowania sie nie zastanawialem, jest pare mozliwosci. Najpierw jak cos bede musial sprawdzic tak PI * Drzwi zlozonosc obliczeniowa tzn. ilosc mnozen bo to najwiekszy i najbardziej czasochlonny proces dla malego procesora. Niestety w przypadku FFT jak i FIR jest tego dosc sporo...
...chyba ze dac jakiegos Cortex M4F ktory ma fajne instrukcje do robienia splotu (np. __SMLAD robiaca 2 mnozenia + dodawania w jednym cyklu)... choc bardziej sklaniam sie by upchac to na jakims Cortex M3 ktory mozna kupic taniej niz wieksze AVR-y...

No ale to mowie jak bede mial czas przetestuje w Matlabie kilka wariantow. Natomiast co do RS to jest bardzo popularny sposob kodowania i mozna znalezc wiele implementacji i opisow jak to zaimplementowac...

Natomiast zagladanie do kodu w fortanie nie ma sensu tam zapewne nikt nic nowego z przetwarzania sygnalow nie wymyslil co zostalo juz wymyslone Do detekcji takich sygnalow jest dosc sporo ciekawych metod od wspomnianego FFT, poprzez rozne metody korelacyjne itd.

Znalazłem swój kodzik do dekodowania, a w zasadzie jego zalążek, naklepane w javie, na wejście wciąga wav. Takie trochę upośledzone FFT - wykorzystałem 64 instancje algorytmu Goertzela do poszukiwania symboli. Testowego wave'a (wygenerowanego - idealny sygnał bez szumu) zdekodowało elegancko, jak będę miał chwilę zobaczę jak poradzi sobie z sygnałem na tle szumu. Wiadomość też zdekodował, ale khm, bez reeda-solomona (wykorzystał tylko oryginalne symbole, nie analizując kodu nadmiarowego)

Co do tego R-Sa to nie wiem czy czytałeś PDF Taylora na temat JT65, ale to jest dość mocno złożone obliczeniowo (przeszukiwanie) i w przypadku małego uC może być czynnikiem ograniczającym.

Nie nie czytalem tego PDF-u... po prostu RS znam z innych zastosowan. Jak mowilem siedze w DSP dosc dlugo - pisalem dekodowanie GSM/UMTS/LTE itp. glownie w profesjonalnych (komercyjnych) zastosowaniach (z tym ze na wyspecjalizowane uklady Picochip sporo wspomagajace sprzetowo)...

Natomiast co do testow to wlasnie polecam albo trial matlaba, albo octave - nie traci sie czasu na implementacje FFT, FIR czy co tam jeszcze - tylko uzywa gotowych funkcji czy tam narzedzi w stylu filter design itp.. Zaladowanie pliku wav to jedna funkcja [y,Fs] = audioread(filename), a FFT to Y = fft(X,n,dim)

Mozna w ten sposob szybko przetestowac dowolne algorytmy i zobaczyc jak sobie radza. Jak juz wszystko fajnie dziala to wtedy mozna sie brac za implementacje w jakims procesorku... a jak ktos nie chce sie bawic to w sporej czesci wypadkow mozna z tego nawet kod w C wygenerowac czy VHDL na FPGA - ale ja akurat tego nie uzywam bo czytelnosc kodu pozostawia wiele do zyczenia

Praktycznie w firmie wszystko tak robie bo inaczej to czas przygotowania projektu/produktu trwal by wieki - testujac to wszstko w C/C++ Zwlaszcza ze w firmie uzywamy na prawde cholernie skomplikowanych algorytmow... przykladowo radar 24GHz potrafiacy sledzic wiele obiektow w 3D - podajac ich predkosc, polozenie, rozmiar itp. (niedlugo sie to moze kierowca nie spodobac, bo niedlugo wejdzie na polski rynek)

Natomiast co do malych prockow - to ja wlasnie dlatego jestem przeciwnikiem wszelkich nakladek w stylu Arduino czy standard peripheral library dla STM32... teoretycznie to ulatwia (choc w przypadku bibliotek od STM wrecz przeciwnie bo ich jakosc jest tragiczna), ale niestety kosztem pochlaniania cykli procesora i zasobow. Potem wychodzi ze nagle trzeba dawac coraz wieksze procki I tak troche odbiegajac od tematu tutaj mozna zobaczyc co mozna z AVR-a wycisnac jak sie pisze kod z glowa https://www.youtube.com/watch?v=sNCqrylNY-0

Koledzy, czy uważacie, że w ramach sp-hm jest możliwe wspólne stworzenie i realizacja projektu TRX SDR (DDC)? Jaka byłaby bariera największa do przeskoczenia? W zaprogramowaniu FPGA, koszcie elementów zapewniających przyzwoite parametry, czy może coś innego - czyli do jakiego poziomu moglibyśmy realnie startować?

Najwiekszy problem to sie zebrac i cos zrobic - tak z mojego doswiadczenia

"czystego" FPGA to bym raczej nie uzywal, sa ciekawsze uklady na rynku np. polaczenie fajnego ARM + FPGA (tutaj tylko pytanie na ile straszne jest dla kogos lutowanie BGA w domu) a koszty zaprogramowania czegokolwiek sa za zwyczaj znikome (patrzac na to ile kosztuja chinskie klony programatorow).

Jak dla kogos jest straszne lutowanie takich ukladow to mozna np. uzyc taki modulik https://www.parallella.org/ mozna zrobic na tym SDR-a pracujacego do paru GHz z ladbym pasmem (np. szybkie transmisje cyfrowe) - dokladajac pare ukladow np. od Analog Devicses czy Maxima...

Zreszta pytanie jeszcze ile osob "kreci" taki DDC - bo mnie wcale, mam taki uniwersalny na USRP N200...

(04-06-2016 15:16)SP6VGX napisał(a):  Zreszta pytanie jeszcze ile osob "kreci" taki DDC - bo mnie wcale, mam taki uniwersalny na USRP N200...

Pytasz, ile osób nie nabyło jeszcze USRP N200 lub podobnego? Myślę, że jest ich wystarczająco dużo, żeby zainteresowało je na razie coś znacznie prostszego.

Chodziło mi nie o zaprogramowanie, a oprogramowanie FPGA. Jeśli całkowity koszt budowy przekraczałby cenę urządzenia fabrycznego, to nie miałoby to dużych szans na realizację. Dlatego pytałem o koszt kluczowych elementów wystarczających, a nie topowych.