J.F. <j...@p...onet.pl> wrote:

>>> Z dzisiejszej perspektywy spitolili, ale biorąc pod uwagę kontekst
>>> historyczny, to równie dobrze można narzekać, że lampowe radia
>>> samochodowe nie miały RDSu. A porządne kody korekcji błędów to dopiero
>>> czasy programu Apollo.
>
>>Tak, to prawda, ale czemu nikt tego nie naprawił gdy technika poszła do
>>przodu?
>
> No bo "mamy juz tysiace odbiornikow, nie mozemy zmieniac standardu".

Dlatego mówię, żeby zachować kompatybilność wsteczną. Z TV (kolor)
i radiem (stereo) się dało :)

> Poza tym czy nie poprawili ? Pojawila sie ta modulacja fazy.

Ale CRC nie dodali :(

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Chyba znalazłem przyczynę. Wina najwyraźniej leży w kodzie.
Autor używa zmiennych typu int do przechowywania informacji o czasie,
zwracanych przez funkcję millis(). Są one używane do mierzenia długości
impulsu.
Rozmiar zmiennej tego typu jest zależny od architektury. Na AVR-ach jest
to zmienna 16bitowa, podczas gdy funkcja millis() zwraca wartość
32bitową. Najwyraźniej autor testował ten kod na jakiś Arduino Due z
32bitowym MCU i wszystko działało prawidłowo, bo tam int jest zmienną
32bitową.

Przepisałem sobie tę bibliotekę na C, z myślą o PIC32. Zastosowałem
zmienne niezależne od architektury. Wygląda na to, że teraz działa to
prawidłowo - przynajmniej część odpowiedzialna za odbieranie bitów. Bo
wczoraj nie miałem już ochoty czekać do późnej nocy, żeby przetestować
odbieranie całych ramek. :)

do góry

W dniu 2018-07-24 o 09:29, Atlantis pisze:
> Chyba znalazłem przyczynę. Wina najwyraźniej leży w kodzie.
> Autor używa zmiennych typu int do przechowywania informacji o czasie,
> zwracanych przez funkcję millis(). Są one używane do mierzenia długości
> impulsu.
> Rozmiar zmiennej tego typu jest zależny od architektury. Na AVR-ach jest
> to zmienna 16bitowa, podczas gdy funkcja millis() zwraca wartość
> 32bitową. Najwyraźniej autor testował ten kod na jakiś Arduino Due z
> 32bitowym MCU i wszystko działało prawidłowo, bo tam int jest zmienną
> 32bitową.
No i to pokazuje jaki burdel jest w arduino i ile warte są tam bibloteki,
to jest fajne dla początkujących do pomrugania ledkąale do obsługi lcd
juz niezupełnie,
syn parę miesięcy temu sam uruchomił lcd-ka z jakieś tam bibloteki, teraz
się nudzi bo wakacje wrócił do tematu i już mu nie chodzi mimo że
połączenia dobre i wszystko działa bo sprawdzałem u siebie w C, ale u
niego przestało :(

>
> Przepisałem sobie tę bibliotekę na C, z myślą o PIC32. Zastosowałem
> zmienne niezależne od architektury. Wygląda na to, że teraz działa to
> prawidłowo - przynajmniej część odpowiedzialna za odbieranie bitów. Bo
> wczoraj nie miałem już ochoty czekać do późnej nocy, żeby przetestować
> odbieranie całych ramek. :)
A oglądałeś ten kod co Ci wysłałem linka?




--
Pozdr
Janusz

do góry

On 24.07.2018 11:21, Janusz wrote:

> No i to pokazuje jaki burdel jest w arduino i ile warte są tam bibloteki,
> to jest fajne dla początkujących do pomrugania ledkąale do obsługi lcd
> juz niezupełnie,

Generalnie (z jednym wyjątkiem) nigdy nie robiłem projektów na Arduino.
Uczyłem się w czasach, gdy standardem było projektowanie i lutowanie
własnej płytki, a potem pisanie kodu w C. Rozumiem, że podejście
polegające na składaniu układu z klocków ułatwia naukę, jednak budowanie
w ten sposób urządzeń zdecydowanie jest nie dla mnie.
Niemniej mam pod ręką kilka płytek Arduino, bo do tej pory idealnie
nadawały się do testowania nowych modułów.
Czasem też najłatwiej jest znaleźć jakąś bibliotekę na tę platformę.
Zwykle co prawda biblioteki napisane są w C++, ale przepisanie tego w C
specjalnie trudne nie jest.

Do tej pory nie zdarzyło mi się jednak, żeby przykład nie działał z
miejsca...


> syn parę miesięcy temu sam uruchomił lcd-ka z jakieś tam bibloteki, teraz
> się nudzi bo wakacje wrócił do tematu i już mu nie chodzi mimo że
> połączenia dobre i wszystko działa bo sprawdzałem u siebie w C, ale u
> niego przestało :(

A właśnie - mnie w Arduino czasami drażni to, że tam całkiem spore
biblioteki potrafią być napisane tak, jakby przygotowano je z myślą o
kimś, kto dopiero zaczyna się uczyć i jeszcze nie ogarnia takich
zagadnień jak callbacki albo pseudowątki.

No bo jak wytłumaczyć fakt, że całkiem spora biblioteka do obsługi
wyświetlaczy graficznych i generowania menu wymusza blokujące
wykonywanie kodu? Funkcja czeka na dane wejściowe z przycisku... Coś
takiego byłoby dopuszczalne na pececie, gdzie można sobie odpalić osobny
proces/wątek, jednak nie na mikrokontrolerze bez systemu operacyjnego...


> A oglądałeś ten kod co Ci wysłałem linka?

Rzuciłem okiem. Mam zresztą samą książkę i chyba kiedyś pobieżnie
przeglądałem ten rozdział.
Obsługa DCF77 była też chyba opisana w którejś z książek pana Kardasia,
tak jednak autor posłużył się mechanizmem input capture. W razie
niepowodzenia mam więc do czego sięgnąć. Skoro jedna już zacząłem
portować tę bibliotekę z Arduino, spróbuję doprowadzić to do końca. :)

do góry

Z tego co widzę, to autor biblioteki całkowicie świadomie napisał ją w
taki sposób, że nie nadaje się ona do ustawiania czasu "od zera". Jest
to jeden z elementów systemu korekcji błędów - jeśli czas z odebranej
ramki nie mieści się w wyznaczonych ramach albo odbiega od systemowego
RTC o więcej niż 2 minuty, to taka ramka jest odrzucana.
Dlatego za pierwszym razem zegar należy zgrubnie ustawić ręcznie (albo
pobrać czas z innego źródła). W moim przypadku nie stanowi to wielkiego
problemu, bo DCF77 ma i tak stanowić zapasowe źródło czasu, wspomagające
NTP lub GPS.

do góry

W dniu 2018-07-25 o 08:29, Atlantis pisze:
> Z tego co widzę, to autor biblioteki całkowicie świadomie napisał ją w
> taki sposób, że nie nadaje się ona do ustawiania czasu "od zera". Jest
> to jeden z elementów systemu korekcji błędów - jeśli czas z odebranej
> ramki nie mieści się w wyznaczonych ramach albo odbiega od systemowego
> RTC o więcej niż 2 minuty, to taka ramka jest odrzucana.
> Dlatego za pierwszym razem zegar należy zgrubnie ustawić ręcznie (albo
> pobrać czas z innego źródła). W moim przypadku nie stanowi to wielkiego
> problemu, bo DCF77 ma i tak stanowić zapasowe źródło czasu, wspomagające
> NTP lub GPS.

Nie pamiętam i nie chce mi się szukać formatu DCF, ale nawet jakby tam
nie było żadnych bitów kontrolnych to przecież wystarczy tak zrobić, że
jak kolejne dwie ramki różnią się zawartością o 1 minutę i wszystkie
impulsy miały długości mieszczące się w określonych ramach to można
chyba śmiało przyjąć, że prawdopodobieństwo, że odebraliśmy zakłócenia
jest bardzo bliższe zera niż jakby tam było jakieś CRC.
Ja z mojego podłączonego do zlącza RS232 odbiornika na pewno w ten
sposób ustawiałem czas.
P.G.

do góry

W dniu 2018-07-25 o 10:47, Piotr Gałka pisze:
> W dniu 2018-07-25 o 08:29, Atlantis pisze:
>> Z tego co widzę, to autor biblioteki całkowicie świadomie napisał ją w
>> taki sposób, że nie nadaje się ona do ustawiania czasu "od zera". Jest
>> to jeden z elementów systemu korekcji błędów - jeśli czas z odebranej
>> ramki nie mieści się w wyznaczonych ramach albo odbiega od systemowego
>> RTC o więcej niż 2 minuty, to taka ramka jest odrzucana.
>> Dlatego za pierwszym razem zegar należy zgrubnie ustawić ręcznie (albo
>> pobrać czas z innego źródła). W moim przypadku nie stanowi to wielkiego
>> problemu, bo DCF77 ma i tak stanowić zapasowe źródło czasu, wspomagające
>> NTP lub GPS.
>
> Nie pamiętam i nie chce mi się szukać formatu DCF, ale nawet jakby tam
> nie było żadnych bitów kontrolnych to przecież wystarczy tak zrobić, że
> jak kolejne dwie ramki różnią się zawartością o 1 minutę i wszystkie
> impulsy miały długości mieszczące się w określonych ramach to można
> chyba śmiało przyjąć, że prawdopodobieństwo, że odebraliśmy zakłócenia
> jest bardzo bliższe zera niż jakby tam było jakieś CRC.
> Ja z mojego podłączonego do zlącza RS232 odbiornika na pewno w ten
> sposób ustawiałem czas.
> P.G.

'bardzo' miało być zastąpione przez 'bliższe' ale zapomniało mi się
skasować :)

do góry

On Wed, 25 Jul 2018 10:47:56 +0200, Piotr Gałka wrote:

> Nie pamiętam i nie chce mi się szukać formatu DCF, ale nawet jakby tam
> nie było żadnych bitów kontrolnych to przecież wystarczy tak zrobić, że
> jak kolejne dwie ramki różnią się zawartością o 1 minutę i wszystkie
> impulsy miały długości mieszczące się w określonych ramach to można
> chyba śmiało przyjąć, że prawdopodobieństwo, że odebraliśmy zakłócenia
> jest bardzo bliższe zera niż jakby tam było jakieś CRC.

Już któryś raz czytam w tym wątku że DCF77 nie posiada CRC - a przecież
CRC tam jest, a nawet jest ich kilka. Fakt, jednobitowe, ale są. :)

Mateusz

do góry

W dniu 2018-07-25 o 10:54, Mateusz Viste pisze:
> On Wed, 25 Jul 2018 10:47:56 +0200, Piotr Gałka wrote:
>
>> Nie pamiętam i nie chce mi się szukać formatu DCF, ale nawet jakby tam
>> nie było żadnych bitów kontrolnych to przecież wystarczy tak zrobić, że
>> jak kolejne dwie ramki różnią się zawartością o 1 minutę i wszystkie
>> impulsy miały długości mieszczące się w określonych ramach to można
>> chyba śmiało przyjąć, że prawdopodobieństwo, że odebraliśmy zakłócenia
>> jest bardzo bliższe zera niż jakby tam było jakieś CRC.
>
> Już któryś raz czytam w tym wątku że DCF77 nie posiada CRC - a przecież
> CRC tam jest, a nawet jest ich kilka. Fakt, jednobitowe, ale są. :)
>

Nie napisałem, że nie ma tylko, że nawet jakby nie było.
P.G.

do góry

W dniu 2018-07-18 o 10:51, Piotr Wyderski pisze:
> Janusz wrote:
>
>> Może podaj pełny link.
>
> To jest pełny link (do katalogu kierującego do poszczególnych elementów
> projektu). Tu masz np. link do schematu:
>
> http://www.marvellconsultants.co.uk/dcf/SCHEMATIC1.p
df
>
> Co Ty masz za Internet? :->
Oni są pojebani, na komórce z Operą nie jestem w stanie pobrać plików,
jak dam agresywną kompresję danych to coś tam pobiorę ale np SCHEMATIC2.pdf
gdzie jest aktywna antena pobiera się z błędami, a jak zmniejszę "agresję"
to dostaje komunikat że dostęp jest zablokowany.

--
Pozdr
Janusz

do góry