Pan J.F. napisał:

>>>> Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
>>>> dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
>>>> w swoich komputerach. Jago zawartość nie zmienia się często, co
>>>> oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
>>>> lokalny zegar pracuje stabilnie.
>>> Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
>>> bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
>>> kolejnej synchronizacji, zmienic dosc istotnie.
>> Ale w jakim systemie?
>
> Linux. Tez ten ntp drift ogladalem, ale chyba w innym pliku/patrzylem
> na aktualne dane.

A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu. Więc
ntp używało się w obrębie własnej sieci, żeby przynajmniej w niej
komputery tak samo cykały. A to już wymagało wskazania lokalnego
serwera i opisania tego w konfigach. Domyślna instalacja tego nie
mogła mieć.

>> Czas w DOS/Windows faktycznie w praktyce zależy wyłącznie od
>> hardware. W porządnych systemach używających ntpd jest już
>> inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
>> wyznaczony parametr. Tak maszynka, która sobie kilka dni
>> pochodziła w sieci, nawet po odcięciu od niej zachowuje się
>> o wiele lepiej od komputera z Windows.
>
> Od komputera z Windows zapewne. Tym niemniej ten wymagany
> wspolczynnik korekcji sie zmienial dosc istotnie.

Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej. Ale kalibracja
tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
urządzeniu.

>> Jeśli oczywiście ma ona system plików z możliwością nieulotnego
>> zapisu (flash przynajmniej).
>
> Masz na mysli odtworzenie zawartosci ntp.drift i uzycie do nowego
> startu komputera ?

Tak, to w praktyce tak właśnie wygląda.

> No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
> komputer zimny i sie dopiero nagrzewa ...

Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
to przy syncronizacji. A po niej robi się zapis system --> RTC.
Sprytna metoda, która pozwala zachować lepszy czas w systemach
bez połączenia z siecią.

--
Jarek

do góry

On 23/03/2016 11:47, AlexY wrote:
> J.F. pisze:
> [..]
>> Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc od BTS,
>> gdyz system wymagal precyzyjnego timingu (takiego 500m).
>> Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
>> tylko do aktualnie uzywanego, jednego BTS.
>> A nam trzeba 3 lub wiecej.
>
> Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA który
> jest bezpośrednio powiązany z odległością od niego.

Dodatkowo chyba każda sieć ma zaimplementowane 3GPP TS 03.71 dzieki
czemu operator moze na zywo odczytywac ten parametr poprzez połączenie
wykonane bez wiedzy własciciela telefonu a nawet odczytywać pozycję GPSa
wbudowanego w telefon. O ile pamietam, moze go nawet włączyć jeśli jest
wyłączony przez użytkownika.

c.

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>>>> Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
>>>>> dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
>>>> Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
>>>> bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
>>>> kolejnej synchronizacji, zmienic dosc istotnie.
>>> Ale w jakim systemie?
>
>> Linux. Tez ten ntp drift ogladalem, ale chyba w innym
>> pliku/patrzylem
>> na aktualne dane.

>A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
>I wcale nie było łatwo o publicznie dostępny serwer czasu.

Skoro wymyslili NTP, to chyba bylo latwo :-)

Juz nie pamietam dokladnie jak to robilem, ale zainteresowala mnie
stabilnosc wewnetrznego kwarcu.
Wiec synchronizowalem z jakim zewnetrznym serwerem NTP, i patrzylem
jak sie zmienia wyliczony dryft.

No i wychodzilo tak sobie.

>>> Zegar systemowy jest skorygowany przez doświadczalnie
>>> wyznaczony parametr. Tak maszynka, która sobie kilka dni
>>> pochodziła w sieci, nawet po odcięciu od niej zachowuje się
>>> o wiele lepiej od komputera z Windows.
>> Od komputera z Windows zapewne. Tym niemniej ten wymagany
>> wspolczynnik korekcji sie zmienial dosc istotnie.
>Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
>kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
>To się trzaska jedno po drugim na linii produkcyjnej.

Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.

Co prawda na reku mam zegarek Casio, ktory jest pierunsko dokladny,
ale inne casio juz takie nie sa.
A kwarc tam chyba inny (tuning fork) niz w procesorze.
Moze teraz sa lepsze kwarce, ale do komputera to sie zasadniczo nikt
nie przejmuje - najtanszy jest najlepszy :-)
Tak czy inaczej - zapamietalem sobie, ze stabilne te kwarce nie byly.

>Ale kalibracja
>tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
>pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
>urządzeniu.

Tak nawiasem mowiac, jak patrze na ten zegarek, ktory potrafi miec
sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
programowej w zegarku.
Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
obliczyc o ile i zapamietac poprawke.
Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?

>> No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
>> komputer zimny i sie dopiero nagrzewa ...

>Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
>przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
>w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
>z rtc przy starcie (zero z definicji) i po określonych odcinkach
>czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.

Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi stabilnosc
niezbyt dobra.

>Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
>to przy syncronizacji. A po niej robi się zapis system --> RTC.

Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
Tylko - czy tak sie robi ?
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift, nie
znalazlem - on chyba RTC nie obsluguje ?

Dodatkowa trudnosc - w pececie ten zegar ma sekundowa rozdzielczosc.
Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
"moment" zmiany.

J.

do góry

Użytkownik "cezar" napisał w wiadomości grup
dyskusyjnych:ncu1ku$399$...@s...org...
On 23/03/2016 11:47, AlexY wrote:
> J.F. pisze:
>>> Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc
>>> od BTS,
>>> gdyz system wymagal precyzyjnego timingu (takiego 500m).
>>> Ale cos mi chodzi po glowie, ze telefon to chyba znal w
>>> odniesieniu
>>> tylko do aktualnie uzywanego, jednego BTS.
>>> A nam trzeba 3 lub wiecej.
>> Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA
>> który
>> jest bezpośrednio powiązany z odległością od niego.

O ile pamietam stare zabawy z netmonitorem, to bylo jakos inaczej
jednak.
Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
tylko przy rozmowie.
Albo to po prostu netmonitor byl ulomny na tych telefonach.

No ale z Javy IMO i tak nie bylo do tych danych dostepu.

>Dodatkowo chyba każda sieć ma zaimplementowane 3GPP TS 03.71 dzieki
>czemu operator moze na zywo odczytywac ten parametr poprzez
>połączenie wykonane bez wiedzy własciciela telefonu

Przede wszystkim to TA jest, a przynajmniej bylo w GSM, zadawane przez
siec.
Wiec siec dobrze wie ktore, siec moze przelaczyc na innego BTS czy
moze nawet moze bez przelaczania ustalic.

>a nawet odczytywać pozycję GPSa wbudowanego w telefon. O ile
>pamietam, moze go nawet włączyć jeśli jest wyłączony przez
>użytkownika.

W nowoczesnych to wcale bym sie nie zdziwil.
Ale ja sprawdzalem na telefonie jeszcze bez GPS :-)

J.

do góry

Pan J.F. napisał:

>>>>> Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
>>>>> bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
>>>>> kolejnej synchronizacji, zmienic dosc istotnie.
>>>> Ale w jakim systemie?
>>> Linux. Tez ten ntp drift ogladalem, ale chyba w innym
>>> pliku/patrzylem na aktualne dane.
>> A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
>> I wcale nie było łatwo o publicznie dostępny serwer czasu.
>
> Skoro wymyslili NTP, to chyba bylo latwo :-)

Jedno nie implikuje drugiego. Protokół wymyślono dawno, publiczne
serwery pojawiły się dużo później.

> Juz nie pamietam dokladnie jak to robilem, ale zainteresowala
> mnie stabilnosc wewnetrznego kwarcu.
> Wiec synchronizowalem z jakim zewnetrznym serwerem NTP,
> i patrzylem jak sie zmienia wyliczony dryft.
>
> No i wychodzilo tak sobie.

Ale co wychodziło tak sobie? Komputer zsynchronizowany z serwerem
tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
zbyt częste.

>> Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
>> kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
>> To się trzaska jedno po drugim na linii produkcyjnej.
>
> Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
> Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.

A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
zrobić to precyzyjnie według wyliczeń, to będzie stabilny.

> Tak nawiasem mowiac, jak patrze na ten zegarek, ktory potrafi miec
> sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
> programowej w zegarku.
> Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
> obliczyc o ile i zapamietac poprawke.
> Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?

Mogli tak zrobić, to przypomina idee NTP, było na czym się wzorować.

>> Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
>> przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
>> w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
>> z rtc przy starcie (zero z definicji) i po określonych odcinkach
>> czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
>
> Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi stabilnosc
> niezbyt dobra.

Nie mierzyłem, to nie będe się spierał. W praktyce problem synchronizacji
czasu uważam za rozwiązany.

>> Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
>> to przy syncronizacji. A po niej robi się zapis system --> RTC.
>
> Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
> o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
> Tylko - czy tak sie robi ?

Widziałem takie rozwiązanie. Można sprawdzać na przykład co godzinę
i *nie* korygować RTC. Czas wyłączenia znany jest od razu po uruchomieniu
-- różnica między czasem bieżącym a czasem ostatnirgo zapisu pliku
z odchyłką.

> Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
> nie znalazlem - on chyba RTC nie obsluguje ?

Z RTC nie ma nic wpólnego. Z *przesunięciem* czasowym też nie. To jest
stan wirtualnego trymera, czyli korekta *częstotliwości*, tak w skrócie.

> Dodatkowa trudnosc - w pececie ten zegar ma sekundowa rozdzielczosc.
> Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
> "moment" zmiany.

A skąd, mikrosekundowa dokładność dostępna jest nawet dla programu
sleep (który śpi z taką dokładnością). Programy związane z ntp też
podają dokładną różnicę czasu.

--
Jarek

do góry

W dniu 23.03.2016 o 10:12, Jarosław Sokołowski pisze:

> Co poradzimy, że w Microsofcie mają na ten temat inne zdanie? W Windows
> jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
> i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
> Przynajmniej tak było, gdy ostatni raz widziałem ten system. A to wcale
> nie tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
> musi być skokowe cofanie czasu.
>

Nie wiem czy to przypadek, ale ja zawsze trafiałem na późniący się zegar
na płycie głównej! Kiedyś mnie to dziwiło, ale może tak t ma być!

--
Cezary Grądys
c...@w...onet.pl

do góry

Pan Czarek Grądys napisał:

>> Co poradzimy, że w Microsofcie mają na ten temat inne zdanie? W Windows
>> jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
>> i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
>> Przynajmniej tak było, gdy ostatni raz widziałem ten system. A to wcale
>> nie tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
>> musi być skokowe cofanie czasu.
>
> Nie wiem czy to przypadek, ale ja zawsze trafiałem na późniący się zegar
> na płycie głównej! Kiedyś mnie to dziwiło, ale może tak t ma być!

Od dawna nie miałem do czynienia z niezsynchronizowanym zegarem komputera.
Tej prawidłowości nie odkryłem, co nie znaczy, ze jej nie ma. Sprytne.
Część problemów z załamaniem czasoprzestrzeni taka spóźnialska strategia
może eliminować, ale nie wszystkie. Sam zegar systemowy może się śpieszyć,
więc przy korektach (z serwera lub ręcznych) będzie cofnięcie. Chyba że
zegara systemowego też to dotyczy. Ale tu już jestem niemal pewny, że przy
synchronizacji okresowej widywałem poprawki w jedną i w drugą stronę.

--
Jarek

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>>> Linux. Tez ten ntp drift ogladalem, ale chyba w innym
>>>> pliku/patrzylem na aktualne dane.
>>> A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
>>> I wcale nie było łatwo o publicznie dostępny serwer czasu.
>
>> Skoro wymyslili NTP, to chyba bylo latwo :-)

>Jedno nie implikuje drugiego. Protokół wymyślono dawno, publiczne
>serwery pojawiły się dużo później.

Watpie. Skoro wymyslono protokol, to i serwer musial byc, do
przetestowania :-)

W kazdym badz razie z serwerem nie mialem klopotow.

>> Juz nie pamietam dokladnie jak to robilem, ale zainteresowala
>> mnie stabilnosc wewnetrznego kwarcu.
>> Wiec synchronizowalem z jakim zewnetrznym serwerem NTP,
>> i patrzylem jak sie zmienia wyliczony dryft.
>
>> No i wychodzilo tak sobie.

>Ale co wychodziło tak sobie? Komputer zsynchronizowany z serwerem
>tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
>zbyt częste.

Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.

>>> Jak wspomniałem, zmienia się rzadko. W miare łatwo jest
>>> wyprodukwać
>>> kwarc wysokiej jakości, o dobrej stabilności, w tym
>>> temperaturowej.
>>> To się trzaska jedno po drugim na linii produkcyjnej.
>> Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
>> Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.
>A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
>zrobić to precyzyjnie według wyliczeń, to będzie stabilny.

O grubosc mi chodzi.
Jak sp* kat ciecia na poczatku, to bedzie niestabilny,
jak sp* potem grubosc - to bedzie niedokladny, ale stabilny - o ile
najpierw dobrze wycieto.

No chyba ze gdzies przy szlifowaniu sie bardziej docisnie z jednej
strony, skos sie zrobi - i wyjdzie tak, jakbys na poczatku krzywo
wycial.

>>> Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
>>> przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
>>> w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
>>> z rtc przy starcie (zero z definicji) i po określonych odcinkach
>>> czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
>
>> Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi
>> stabilnosc
>> niezbyt dobra.

>Nie mierzyłem, to nie będe się spierał. W praktyce problem
>synchronizacji
>czasu uważam za rozwiązany.

W komputerze z linuxem, z czestym dostepem do internetu i rzadko
wylaczanym.
A my tu o zegarku bez dostepu :-)

>> Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
>> nie znalazlem - on chyba RTC nie obsluguje ?

>Z RTC nie ma nic wpólnego. Z *przesunięciem* czasowym też nie. To
>jest
>stan wirtualnego trymera, czyli korekta *częstotliwości*, tak w
>skrócie.

Czyli do RTC trzeba osobny program :-)

>> Dodatkowa trudnosc - w pececie ten zegar ma sekundowa
>> rozdzielczosc.
>> Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
>> "moment" zmiany.
>A skąd, mikrosekundowa dokładność dostępna jest nawet dla programu
>sleep (który śpi z taką dokładnością). Programy związane z ntp też
>podają dokładną różnicę czasu.

RTC w pececie nie ma takiej rozdzielczosci !
Stad, aby sprawdzic jego dryft, trzeba go odczytac wiele razy az
zmieni sekunde, wtedy odczytac dokladny czas systemowy, i mamy
wzglednie dokladnie zmierzony czas w RTC.
Im czesciej odczytujemy, tym dokladniejszy pomiar, ale tez procesor
bardziej zajety przez te srednio pol sekundy.
Nawet wielordzeniowy moze byc przyblokowany, bo dostep do rejestrow
RTC dlugo trwa, przynajmniej kiedys tak bylo.

No i ja sie bawilem chyba jeszcze gdy "microsecond timer" nie byl
dostepny, kernel sam sobie sobie go organizowal, i co przerwanie
dodawal wlasnie tych 10000us do zmiennej timera. Czyli niby
"microsecond" a naprawde 10ms ..

A tak swoja droga ... to jak sobie teraz radza ?
Jest sprzetowy "time stamp counter", z rozdzielczoscia nawet jakby
lepsza niz nanosekunda, ale napedza go zegar systemowy.
Jak sie chce skorzystac i przeliczyc na UTC, to trzeba dosc ambitnie
przeliczac, z ryzykiem cofania czasu .

J.

do góry

Hello J.F.,

Wednesday, March 23, 2016, 2:32:10 PM, you wrote:

>>>> Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc
>>>> od BTS,
>>>> gdyz system wymagal precyzyjnego timingu (takiego 500m).
>>>> Ale cos mi chodzi po glowie, ze telefon to chyba znal w
>>>> odniesieniu
>>>> tylko do aktualnie uzywanego, jednego BTS.
>>>> A nam trzeba 3 lub wiecej.
>>> Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA
>>> który
>>> jest bezpośrednio powiązany z odległością od niego.
> O ile pamietam stare zabawy z netmonitorem, to bylo jakos inaczej
> jednak.

Znaczy jak?

> Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
> tylko przy rozmowie.

Nie.

> Albo to po prostu netmonitor byl ulomny na tych telefonach.

Ano.

> No ale z Javy IMO i tak nie bylo do tych danych dostepu.

Bo nie ma potrzeby. Dane o lokalizacji są obrabiane przez serwer a nie
przeglądarkę.

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Użytkownik "RoMan Mandziejewicz" napisał w wiadomości
Hello J.F.,
>>>> Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA
>>>> który jest bezpośrednio powiązany z odległością od niego.
>> O ile pamietam stare zabawy z netmonitorem, to bylo jakos inaczej
>> jednak.

>Znaczy jak?

>> Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
>> tylko przy rozmowie.

>Nie.

>> Albo to po prostu netmonitor byl ulomny na tych telefonach.
>Ano.

Byc moze.
Z drugiej strony - jak nie ma rozmowy, to telefon tylko z rzadka cos
transmituje, wiec jak ustalic TA ?

Moze i to "rzadko" wystarczy ...

>> No ale z Javy IMO i tak nie bylo do tych danych dostepu.
>Bo nie ma potrzeby. Dane o lokalizacji są obrabiane przez serwer a
>nie
>przeglądarkę.

Ale jakie dane ?
Zrozum sytuacje - stary telefon, SE K550, zaden tam smartfon, ale
jednak "z Java" (J2ME).
Instaluje program od googla - i on ustala pozycje.
Wyslac do serwera mogl tylko to, co jest udostepnione Javie - a w MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.

Byc moze telefon to robil za pomoca JSR179, producent implementujac
funkcje udostepnil potrzebne dane, przeslal na serwer, odebral
odpowiedz, wystawil pozycje aplikacji.
Ale ... dzialalo bez polaczenia internetowego. Hm, a moze nie ...
wszak zeby google pokazal mapy, to trzeba miec polaczenie.

Wyglada mi na to, ze to jednak operator wyznaczal i udostepnial
pozycje.

A wtedy dziwi mnie, ze tak latwo zrezygnowal z naleznych oplat :-)

J.

do góry