Hi George, many thanks for your test and suggestions. In the next release I will show more details on the correction factor. I will also improve its determination as suggested. (Initially, the program was programmed to use the top 1 synch, but it was not useful during tests when I wanted to see the result of each synch). The shown Tacc is equal to the round trip time (RTT) divided by 2. The time error is computed as the difference between the time of the request +RTT/2 and the server time. Therefore, in your example it would be indeed 1.8 s. The mean Tacc from my location is of about 80 ms. Unfortunately, one of the main problems with mobile phones is the network latency. I partially solved this problem engaging the network with a short data transfer during which I perform the time synchronization. Without this trick the situation would be even worse, with RTTs even larger than 0.5 s. I introduced the item "exit" in the menu since I decided to capture the "back" key as input for the stopwatch. This menu item should terminate the application. It would be interesting if someone could test the time deviation with respect to a reference clock. Regards, Simone > >Very Nice! > >1) I love the way I can press up volume, down volume, or back button and get >3 different time indicators so later I know which one was which. One can >use this to help remember which event is which - for example press the vol >up button when the sat is closest to a known and planned-for bright star and >the vol down button when the sat is closest to an unknown fainter star. >2) I love that I can jump into timing an event, then later sync up several >times until I get a higher accuracy. Each time I sync all the times adjust >slightly to the latest syncing. >3) Unfortunately the highest accuracy I was able to get with about 30 >attempts was "Tacc < 90ms". This is according to the program (not tested >against something more accurate). >4) It would be nice to display the correction factor you are using. The >correction factor for my phone was about 1 second. >5) It would be nice to be able to take an average of the top 3 sync events >or the top 1 sync event and not update the times displayed unless the latest >sync event had a "Tacc" better than any previous ones. >6) I assume Tacc is the same as the round trip network time. Do you use >this information in the syncing? In other words if the phone says it is 1.0 >seconds after the hour and the NTP server says it is 3.0 seconds after the >hour and the round trip delay was 0.4 seconds, do you use a correction >factor of 2.0 seconds or a correction factor of 1.8 seconds? (this assumes >the .4 sec delay was equal on both paths or .2 seconds each way). >7) The "exit application" doesn't seem to work but I'm not sure what its >purpose is anyway. I would just get rid of it. > >- George Roberts >http://gr5.org > >_______________________________________________ >Seesat-l mailing list >http://mailman.satobs.org/mailman/listinfo/seesat-l > _______________________________________________ Seesat-l mailing list http://mailman.satobs.org/mailman/listinfo/seesat-l
This archive was generated by hypermail 2b29 : Tue Sep 03 2013 - 08:21:12 UTC