W dniu 2014-11-13 00:02, Grzegorz Niemirowski pisze:

> Takie fluktuacje nie powinny mieć miejsca, częstotliwość nie może pływać
> z odchyleniem 10%. Może coś nie tak z sygnałem zegarowym? Używasz

Dziesięć procent? Nie mówimy o dziesięciu procentach.
Częstotliwość zegara w moim urządzeniu wynosi 12 500 000 Hz.
Częstotliwościomierz pokazuje tylko siedem cyfr, fluktuowały dwie
ostatnie. Mówimy o zmianach rzędu kilkuset Hz przy częstotliwości 12,5
MHz. Przy czym jak mówiłem - podejrzewam, że to wina miernika.


> wewnętrznego generatora RC czy kwarca? Wymieniałeś kwarc? Swoją drogą
> dobrze poszukać kwarcu, który będzie miał częstotliwość dającą się
> odpowiednio podzielić. Dlatego w handlu są kwarce o częstotliwościach w
> rodzaju 3,6864 MHz.

Używam sygnału zegarowego udostępnianego przez kontroler Ethernetu
ENC28J60. On sam jest taktowany kwarcem 25 MHz, na wyjściu zegarowym
udostępniając 12,5 MHz.


> Może trzeba by skopiować projekt i w tej kopii powoli wywalać kolejne
> rzeczy aż zostanie sam timer? Bo może coś przeszkadza, jakieś inne
> przerwanie.

Nie ma żadnych innych przerwań. Projekt wykorzystuje jeszcze Timer1, ale
w trybie licznika zewnętrznych impulsów, a wiec nie zgłasza on przerwań.
Program nie wykorzystuje nawet UART-a...

do góry

Atlantis <m...@w...pl> napisał(a):
> Dziesięć procent? Nie mówimy o dziesięciu procentach.
> Częstotliwość zegara w moim urządzeniu wynosi 12 500 000 Hz.
> Częstotliwościomierz pokazuje tylko siedem cyfr, fluktuowały dwie
> ostatnie. Mówimy o zmianach rzędu kilkuset Hz przy częstotliwości 12,5
> MHz. Przy czym jak mówiłem - podejrzewam, że to wina miernika.

Miałem na myśli pomiar machania pinem. Przez fluktuację rozumiem zmieniający
się odczyt. Chodzi o jakieś miganie niezwiązane z tym konkretnym pomiarem?

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 44 days, 5 hours, 24 minutes and 46 seconds

do góry

On Wed, 12 Nov 2014 23:57:27 +0100, Atlantis <m...@w...pl>
wrote:
> Tylko taka niedokładność nie spowoduje 80 sekund opóźnienia po
godzinie
> i 10 minutach pracy...

Dokładnie 80 czy 86.4?

--
Marek

do góry

W dniu 2014-11-12 o 23:14, J.F. pisze:
> A propos NTP - czy ktos analizowal jak to dziala i rozumie ?
>
> Bo nie rozumiem jak on sobie radzi z laczami niesymetrycznymi, gdy np
> pakiet w jedna strone idzie 0.1s, a w druga 2.1s ..
>
> Mimo tych 4 znacznikow czasu 0 - na moj gust to nie ma mozliwosci
> wykrycia o ile pakiety sa niesymetryczne.
>
> J.
>

Ja używam w swojej xmedze SMTP, jest banalnie prosty. Używam bez
korekcji czasu przelotu i to mi działa bo mam własny serwer NTP na jeden
hop, a ponieważ atmelowe RTC i tak jest w stanie tylko liczyć sekundy
więc arytmetykę na liczbach 64o bitowych uznałem za zbędną.

Z tego co jest w RFC4330:
Timestamp Name ID When Generated
----------------------------------------------------
--------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client

The roundtrip delay d and system clock offset t are defined as:

d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.

Jak dla mnie wzór na t tak pięknie się skraca, że nie ma znaczenia czy
opóźnienie jest symetryczne czy nie.
Można by to wyprowadzić zakładając, że d=d1+d2 ale przed pierwszą kawą
nie chce mi się... :-)

--
AWa.

do góry

W dniu 2014-11-13 01:12, Marek pisze:

> Dokładnie 80 czy 86.4?

Z tego co pamiętam, to było 81. Przy czym mierzone ze stoperem jako
punktem odniesienia, wiec nie jestem w stanie zagwarantować dokładności
na poziomie tej ostatniej sekundy. ;)

do góry

Poeksperymentowałem trochę i udało mi się skalibrować ten timer.
Teraz w rejestr OCR0A wpisana jest wartość 238. Zegar spieszy o jakąś
sekundę na każde 10 minut. Nie jest może to idealną sytuacją, ale w
każdym razie jest to najlepsze rozwiązanie, jakie udało mi się znaleźć
do tej pory.
Dziwi mnie tylko ta rozbieżność w stosunku do obliczeń z kalkulatora...

Wychodzi jednak na to, że z synchronizacją NTP też coś jest nie tak. Tuż
po uruchomieniu układu mam czas różniący się o kilka sekund od
rzeczywistego. Uzyskanie dokładnego pokrycia wymaga przeprowadzenia
kilku-kilkunastu ręcznie wymuszonych synchronizacje, jedna po drugiej.
Po takiej operacji czas dryfuje już normalnie. Nie jestem jednak pewien,
czy kolejne (pojedyncze, automatyczne) synchronizacje znów go nie
zafałszują.

Jakiś pomysł co do możliwej przyczyny takiego stanu rzeczy? Czyżby
funkcje obsługi NTP w bibliotece tuxgraphics posiadały jakiś błąd?

do góry

Hmm... Coś jeszcze jest na rzeczy z tą synchronizacją.
Pojedyncza, automatyczna synchronizacja (wywołana po 10 minutach dla
skompensowania tego sekundowego błędu) wprowadziła 14 sekundowe opóźnienie.

Czy kod funkcji wysyłającej request wygląda w porządku?

void client_ntp_request(uint8_t *buf,uint8_t *ntpip,uint8_t
srcport,uint8_t *dstmac)
{
uint8_t i=0;
uint16_t ck;
if (!enc28j60linkup())return;
//
while(i<6){
buf[ETH_DST_MAC +i]=dstmac[i]; // gw mac in local lan or
host mac
buf[ETH_SRC_MAC +i]=macaddr[i];
i++;
}
buf[ETH_TYPE_H_P] = ETHTYPE_IP_H_V;
buf[ETH_TYPE_L_P] = ETHTYPE_IP_L_V;
fill_buf_p(&buf[IP_P],9,iphdr);
buf[IP_ID_L_P]=ipid; ipid++;
buf[IP_TOTLEN_L_P]=0x4c;
buf[IP_PROTO_P]=IP_PROTO_UDP_V;
i=0;
while(i<4){
buf[IP_DST_P+i]=ntpip[i];
buf[IP_SRC_P+i]=ipaddr[i];
i++;
}
fill_ip_hdr_checksum(buf);
buf[UDP_DST_PORT_H_P]=0;
buf[UDP_DST_PORT_L_P]=0x7b; // ntp=123
buf[UDP_SRC_PORT_H_P]=10;
buf[UDP_SRC_PORT_L_P]=srcport; // lower 8 bit of src port
buf[UDP_LEN_H_P]=0;
buf[UDP_LEN_L_P]=56; // fixed len
// zero the checksum
buf[UDP_CHECKSUM_H_P]=0;
buf[UDP_CHECKSUM_L_P]=0;
// copy the data:
i=0;
// most fields are zero, here we zero everything and fill later
while(i<48){
buf[UDP_DATA_P+i]=0;
i++;
}
fill_buf_p(&buf[UDP_DATA_P],10,ntpreqhdr);
//
ck=checksum(&buf[IP_SRC_P], 16 + 48,1);
buf[UDP_CHECKSUM_H_P]=ck>>8;
buf[UDP_CHECKSUM_L_P]=ck& 0xff;
enc28j60PacketSend(90,buf);
}

Zastanawia mnie zmienna ntpreqhdr. Jaką funkcję ona pełni?
Bo jej deklaracja wygląda następująco:

const char ntpreqhdr[] PROGMEM ={0xe3,0,4,0xfa,0,1,0,0,0,1};

Ktoś z Was wspominał, że request powinien zawierać informację o czasie.
Tutaj nigdzie nie jestem o nią proszony...

do góry

W dniu 2014-11-13 09:26, Marek pisze:

> Jak widac niewielka zmiana wartości OC (turaj 249 lub 250) powoduje
> znaczne wachanie opóźnienia czasu.

Teraz wartość OC wynosi 238, a zegar spieszy się o jakąś sekundę na
każde dziesięć minut. Jest to najlepszy wynik, jaki udało mi się uzyskać
do tej pory. Różni się jednak wyraźnie od tego, co pokazywał kalkulator.

Nie mam pojęcia co jeszcze mógłbym pomieszać w ustawieniach timera. Tryb
CTC ustawiony, preskaler prawidłowy, zmiana OC jak widać ma wpływ na
pracę układu...

No i jak się okazuje - synchronizacja NTP także wprowadza jakiś błąd. Są
to dwie niezależne sprawy.

do góry

W dniu 2014-11-13 o 10:03, Atlantis pisze:
> Bo jej deklaracja wygląda następująco:
>
> const char ntpreqhdr[] PROGMEM ={0xe3,0,4,0xfa,0,1,0,0,0,1};

Naprawdę tak trudno zerknąć do RFC4330?
Informacja o czasie nadania pakietu jest potrzebna do korekcji czasu
przelotu pakietów UDP. Jeśli serwer NTP masz blisko a czas liczysz w
sekundach to nie jest potrzebna taka korekta (w Twoim kodzie jej nie
liczysz).

0xE3 - LI=3, VN=4, Mode=3
LI jest polem serwera, klient go nie ustawia, ale to nie ma wpływu.
VN - ok
Mode - ok
0 - Stratum = 0
4 - Poll = 4 - to ustawia tylko serwer
0xFA - Precision = 0xFA - to ustawia tylko serwer

Jakieś to dla mnie dziwne.
U mnie pakiet z zapytaniem wygląda tak (wartość, długość):

/* Client
-- 0
LI = 0, 2b
VN = 4, 3b
MODE = 3,3b
-- 1
Stratum = 0, 8b
-- 2
Poll = 0, 8b
-- 3
Precision = 0, 8b
-- 4-7
Root Delay = 0, 32b
-- 8-11
Root Dispersion = 0, 32b
-- 12-15
Reference Identifier = 0, 32b
-- 16-23
Reference Timestamp = 0, 64b
-- 24-31
Originate Timestamp = 0, 64b
-- 32-39
Receive Timestamp = 0, 64b
-- 40-43
Transmit Timestamp = Seconds, 32b
-- 44-47
Transmit Timestamp = Seconds Fraction, 32b
*/

W odpowiedzi od serwera w polu "Originate Timestamp" powinieneś mieć to
co wysłałeś w "Transmit Timestamp".
Można by też lekceważyć wszystkie odpowiedzi z LI=3.
A jak chcesz być poprawny to powinieneś też sprawdzać czy pole Stratum
nie jest równe zero i podejmować odpowiednią akcję.


--
AWa.

do góry

W dniu 2014-11-13 11:45, Andrzej W. pisze:

> W odpowiedzi od serwera w polu "Originate Timestamp" powinieneś mieć to
> co wysłałeś w "Transmit Timestamp".
> Można by też lekceważyć wszystkie odpowiedzi z LI=3.
> A jak chcesz być poprawny to powinieneś też sprawdzać czy pole Stratum
> nie jest równe zero i podejmować odpowiednią akcję.

Hmm... Czy w takim razie ta mocno uproszczona funkcja wysyłÍająca
request może być odpowiedzialna za zachowanie mojego programu? A może
jednak coś jest nie tak z funkcją odbiorczą? Może autor popełnił błąd i
zaprogramował odczytywanie pól z niewłaściwym timestampem?
Jaka pomyłka mogłaby skutkować czasem opóźnionym o kilka-kilkanaście
sekund po aktualizacji, no chyba, że serwer "zaleje się" requestami?

do góry