sirapacz wrote:

> w obecnych czasach urządzenia robi się na odpi...l i nie bawią się w
> sprawdzanie softu a co dopiero sensownego jego napisanie....
>
> Jeśli tak nie jest, to ja - konsument - mam zdaje się pecha.....

Z całym powyższym przesłaniem się zgadzam, ale na usprawiedliwienie
zdolnych inaczej programistów muszę powiedzieć, że zastosowanie tych
technik wcale nie jest oczywistą sprawą, a po drugie potrzeba
kilkudziesięciu MIPSów i ok. 200kiB RAMu. To nie wejdzie w Atmelka,
jakby się człowiek nie siłował. Dlatego właśnie swój odbiornik chcę
zrobić na H7, choć F7 być może też wystarczy.

Pozostaje też sprawa zafiksowania się na rozwiązaniu: jak się człowiek
uprze, że sygnał DCF trzeba odebrać i zdekodować, to będzie robił
wszystko, by zrobić stosownie czuły i niskoszumny odbiornik (w praktyce:
kupić moduł) oraz będzie odprawiał czary z mleka, by wyciągnąć
maksymalnie wiele z pojedynczych zakłóconych ramek. Dopiero jak
się zauważy, że na to można patrzeć jak na problem sequence alignment,
liczyć korelacje za pomocą dużych FFT i je uśredniać, co pozwala na
pracę z wręcz ujemnym SNR przy calkowitym braku w pełni poprawnych
ramek, to można zbudować sensowny odbiornik. Pomysł jest prosty:
skoro sygnał DCF jest całkowicie przewidywalny i można go na
setki lat w przód wygenerować off-line, to wystarczy sprawdzać,
do którego kawałka ramki pasują najbardziej, a potem zrobić analizę
skupień. Realizacja techniczna jest jednak daleka od prostej
i Engeler podsuwa użyteczne sztuczki.

Pozdrawiam, Piotr