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