Re: [time-nuts] Looking for GPS module (Exactime ET6000/Datum 9390-6000)

[Mike Cook]

If your friends don’t have a CM3 spare, there is one on eBay item 141712522709. 
It might be worth pulling the GPS part and testing it stand alone as there have 
been numerous week number roll over problems surfacing. If that is the case for 
yours then a replacement gets you nowhere. 

> Le 16 janv. 2017 à 07:32, ziggy9+time-n...@pumpkinbrook.com a écrit :
> 
> I’ve had an intermittent problem with my ET6000/9390-6000 GPSDO where the 
> reported error (the FRQ: display on the LCD) initially is OK (low E-12’s) and 
> then creeps up to the limit (~500), and the tracking and locked LEDs go out. 
> I’ve spent some time troubleshooting this and it seems confirmed that the GPS 
> module has finally gone south. I’m asking if anyone has a similar module 
> tucked away somewhere. 
> 
> The module is basically a Trimble SveeSix-CM3 and is based on the 25040 
> board. It’s labeled 26889-81 so is a variant of the standard TSIP part. Can 
> anyone help with a replacement? Exact replacement would be ideal of course, 
> but even a standard CM3 would be useful - I’ve done other ‘conversions’ 
> before. 
> 
> Thanks
> 
> Paul
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Survey plot as art.

[Andrew Rodland]

On Sun, Jan 15, 2017 at 6:23 AM, Andrew Rodland  wrote:
> Relatedly, and just for fun, here's a video I made several years ago
> from a few days worth of constellation status data out of a cheap SiRF
> receiver. It's interesting to see how the satellite geometry changes
> over time... or maybe it's just fun to watch the pretty colors. If
> you're observant you can also get an idea for where the tall trees
> were at my old apartment and maybe my approximate latitude.
>
> The projection is stereographic from the nadir (I think), with 90°
> elevation at the center, 0° elevation at the edges, and north up. The
> "wiggles" near the edges are due to the granularity of the positions
> from the receiver (half-degree, IIRC). Points are drawn with size and
> brightness proportional to the log signal strength, and the trails
> fade out exponentially.
>

And here is the actual video:
https://www.youtube.com/watch?v=VZHK1c54YRk -- sorry about the
suspense.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Looking for GPS module (Exactime ET6000/Datum 9390-6000)

[ziggy9+time-nuts]

I’ve had an intermittent problem with my ET6000/9390-6000 GPSDO where the 
reported error (the FRQ: display on the LCD) initially is OK (low E-12’s) and 
then creeps up to the limit (~500), and the tracking and locked LEDs go out. 
I’ve spent some time troubleshooting this and it seems confirmed that the GPS 
module has finally gone south. I’m asking if anyone has a similar module tucked 
away somewhere. 

The module is basically a Trimble SveeSix-CM3 and is based on the 25040 board. 
It’s labeled 26889-81 so is a variant of the standard TSIP part. Can anyone 
help with a replacement? Exact replacement would be ideal of course, but even a 
standard CM3 would be useful - I’ve done other ‘conversions’ before. 

Thanks

Paul
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] time transfer over wifi

[Scott Stobbe]

Pretty much every wifi transceiver is adc sampled so the frames are
"timestamped", but the adc sample time may not get pushed up.

The rtt/tof for the large umbrella of localization applications, I would
imagine will be impented even farther back in the rx chain.

On Sun, Jan 15, 2017 at 11:42 AM jimlux  wrote:

> On 1/15/17 8:26 AM, Bob Camp wrote:
>
> > Hi
>
> >
>
> > Ok, that’s a pretty good paper. At least it shows data and digs into the
> details.
>
> > It also would lead one to believe that a “Time Nuts” grade sync system
> might
>
> > be a hackable sort of thing …… hmmm…..Given how highly integrated these
>
> > WiFi chip sets have become, that probably is a fantasy.
>
> >
>
>
>
> maybe, maybe not..
>
>
>
> They might have implemented the time stamping feature (like in that WiFi
>
> Arduino thing) but the details are poorly documented, and of course,
>
> everyone is different.
>
>
>
> But it's a start.
>
>
>
> and 802.11v appears to be the "standard" for how to do it in a
>
> "standards compliant" way.
>
>
>
>
>
>
>
> ___
>
> time-nuts mailing list -- time-nuts@febo.com
>
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
> and follow the instructions there.
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Linux-gpib & Agilent usb-gpib , fixed on a RaspberryPi w. kernel 4.x.x

[CFO]

Just wanted to inform you that the linux-gpib maintainer Dave Penkler.
Has fixed the problem with the Agilent 82357B GPIB USB adapter, that
have been present since the switch to kernel 4.x.x.

*** Snip ***
Turned out to be non dma compatible buffers. SVN R1654 fixes it. Please
let me know if it works for you.
thanks,
-Dave
*** Sip ***

Also: We're building a RasPi based logging platform for VoltNuts for now @
http://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/

CFO

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] time transfer over wifi

[jimlux]

On 1/15/17 8:26 AM, Bob Camp wrote:

Hi

Ok, that’s a pretty good paper. At least it shows data and digs into the 
details.
It also would lead one to believe that a “Time Nuts” grade sync system might
be a hackable sort of thing …… hmmm…..Given how highly integrated these
WiFi chip sets have become, that probably is a fantasy.



maybe, maybe not..

They might have implemented the time stamping feature (like in that WiFi 
Arduino thing) but the details are poorly documented, and of course, 
everyone is different.


But it's a start.

and 802.11v appears to be the "standard" for how to do it in a 
"standards compliant" way.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] time transfer over wifi

[Bob Camp]

Hi

Ok, that’s a pretty good paper. At least it shows data and digs into the 
details. 
It also would lead one to believe that a “Time Nuts” grade sync system might 
be a hackable sort of thing …… hmmm…..Given how highly integrated these
WiFi chip sets have become, that probably is a fantasy. 

Bob

> On Jan 15, 2017, at 11:10 AM, Scott Stobbe  wrote:
> 
> Here is a ti app note with timestamping hardware wl8 but ordinary ap's with
> no special protocol just timestamping the beacon frame.
> 
> http://www.ti.com/lit/an/swaa162a/swaa162a.pdf
> 
> On Sun, Jan 15, 2017 at 10:06 AM jimlux  wrote:
> 
>> Returning to the OP
>> 
>> "A TimeSync certification program will appear later this year, but
>> 
>> semiconductor firms will have to create new Wi-Fi chips including the
>> 
>> feature."
>> 
>> 
>> 
>> so this "new thing" will be hardware of some TBD form.
>> 
>> https://www.wi-fi.org/discover-wi-fi/wi-fi-timesync
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> But more interesting to time-nuts, I think, is how do you do it without
>> 
>> the new hardware.
>> 
>> 
>> 
>> http://www.cse.msu.edu/~glxing/docs/WizSync.pdf
>> 
>> says, in part:
>> 
>> 
>> 
>> 802.11  requires  all  APs  to  broadcast  periodic beacon frames that
>> 
>> carry important management information (e.g., supported  rates  and
>> 
>> security  settings).  The  default  beacon period is 102.4 ms, which is
>> 
>> rarely changed on production APs. ...However, as defined in 802.11,
>> 
>> whether a  beacon  frame  is  delayed  or  not,  the  subsequent  beacon
>> 
>> frame shall always  be scheduled at the undelayed  nominal beacon interval.
>> 
>> 
>> 
>> so this is the "use a 1pps, but throw out outliers" kind of strategy...
>> 
>> 
>> 
>> And there would need to be some sort of measurement of the AP's timing
>> 
>> error - they make the assumption that the timing of the beacons is
>> 
>> driven by a clock with max 25ppm error (as required by the 802.11 std),
>> 
>> although they've measured <5ppm normally
>> 
>> 
>> 
>> Ultimately, they got on the order of 0.1 0.2 ms.
>> 
>> 
>> 
>> 
>> 
>> That's a few orders of magnitude worse than "microsecond", but it's also
>> 
>> an interesting read.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> an older presentation (2006) might be useful
>> 
>> 
>> http://www.ieee802.org/1/files/public/docs2006/avb-stanton-wifi-timesync-intro-060613.pdf
>> 
>> 
>> 
>> discusses 802.11v
>> 
>> 
>> 
>> there's been a lot of stuff on time sync/distribution over 802.11 links
>> 
>> for the last decade.. maybe this CES announcement is more about "we at
>> 
>> WiFi alliance are ready to market it".   Has anyone gone through the
>> 
>> 802.11 standards list recently?  It might well be that the standard is
>> 
>> already there.
>> 
>> 
>> 
>> 802.11aa says "Amendment 2: MAC Enhancements for Robust Audio Video
>> 
>> Streaming" in the description...   although that might just be things
>> 
>> like QoS and access control-digital rights management
>> 
>> 
>> 
>> ___
>> 
>> time-nuts mailing list -- time-nuts@febo.com
>> 
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> 
>> and follow the instructions there.
>> 
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] time transfer over wifi

[Scott Stobbe]

Here is a ti app note with timestamping hardware wl8 but ordinary ap's with
no special protocol just timestamping the beacon frame.

http://www.ti.com/lit/an/swaa162a/swaa162a.pdf

On Sun, Jan 15, 2017 at 10:06 AM jimlux  wrote:

> Returning to the OP
>
> "A TimeSync certification program will appear later this year, but
>
> semiconductor firms will have to create new Wi-Fi chips including the
>
> feature."
>
>
>
> so this "new thing" will be hardware of some TBD form.
>
> https://www.wi-fi.org/discover-wi-fi/wi-fi-timesync
>
>
>
>
>
>
>
> But more interesting to time-nuts, I think, is how do you do it without
>
> the new hardware.
>
>
>
> http://www.cse.msu.edu/~glxing/docs/WizSync.pdf
>
> says, in part:
>
>
>
> 802.11  requires  all  APs  to  broadcast  periodic beacon frames that
>
> carry important management information (e.g., supported  rates  and
>
> security  settings).  The  default  beacon period is 102.4 ms, which is
>
> rarely changed on production APs. ...However, as defined in 802.11,
>
> whether a  beacon  frame  is  delayed  or  not,  the  subsequent  beacon
>
> frame shall always  be scheduled at the undelayed  nominal beacon interval.
>
>
>
> so this is the "use a 1pps, but throw out outliers" kind of strategy...
>
>
>
> And there would need to be some sort of measurement of the AP's timing
>
> error - they make the assumption that the timing of the beacons is
>
> driven by a clock with max 25ppm error (as required by the 802.11 std),
>
> although they've measured <5ppm normally
>
>
>
> Ultimately, they got on the order of 0.1 0.2 ms.
>
>
>
>
>
> That's a few orders of magnitude worse than "microsecond", but it's also
>
> an interesting read.
>
>
>
>
>
>
>
> an older presentation (2006) might be useful
>
>
> http://www.ieee802.org/1/files/public/docs2006/avb-stanton-wifi-timesync-intro-060613.pdf
>
>
>
> discusses 802.11v
>
>
>
> there's been a lot of stuff on time sync/distribution over 802.11 links
>
> for the last decade.. maybe this CES announcement is more about "we at
>
> WiFi alliance are ready to market it".   Has anyone gone through the
>
> 802.11 standards list recently?  It might well be that the standard is
>
> already there.
>
>
>
> 802.11aa says "Amendment 2: MAC Enhancements for Robust Audio Video
>
> Streaming" in the description...   although that might just be things
>
> like QoS and access control-digital rights management
>
>
>
> ___
>
> time-nuts mailing list -- time-nuts@febo.com
>
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
> and follow the instructions there.
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] time transfer over wifi

[jimlux]

Returning to the OP
"A TimeSync certification program will appear later this year, but 
semiconductor firms will have to create new Wi-Fi chips including the 
feature."


so this "new thing" will be hardware of some TBD form.
https://www.wi-fi.org/discover-wi-fi/wi-fi-timesync



But more interesting to time-nuts, I think, is how do you do it without 
the new hardware.


http://www.cse.msu.edu/~glxing/docs/WizSync.pdf
says, in part:

802.11  requires  all  APs  to  broadcast  periodic beacon frames that 
carry important management information (e.g., supported  rates  and 
security  settings).  The  default  beacon period is 102.4 ms, which is 
rarely changed on production APs. ...However, as defined in 802.11, 
whether a  beacon  frame  is  delayed  or  not,  the  subsequent  beacon 
frame shall always  be scheduled at the undelayed  nominal beacon interval.


so this is the "use a 1pps, but throw out outliers" kind of strategy...

And there would need to be some sort of measurement of the AP's timing 
error - they make the assumption that the timing of the beacons is 
driven by a clock with max 25ppm error (as required by the 802.11 std), 
although they've measured <5ppm normally


Ultimately, they got on the order of 0.1 0.2 ms.


That's a few orders of magnitude worse than "microsecond", but it's also 
an interesting read.




an older presentation (2006) might be useful
http://www.ieee802.org/1/files/public/docs2006/avb-stanton-wifi-timesync-intro-060613.pdf

discusses 802.11v

there's been a lot of stuff on time sync/distribution over 802.11 links 
for the last decade.. maybe this CES announcement is more about "we at 
WiFi alliance are ready to market it".   Has anyone gone through the 
802.11 standards list recently?  It might well be that the standard is 
already there.


802.11aa says "Amendment 2: MAC Enhancements for Robust Audio Video 
Streaming" in the description...   although that might just be things 
like QoS and access control-digital rights management


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Björn Gabrielsson]

Hi Bob,

Below are some efforts to reduce buffering in both routers and non router
network stacks including wifi. They are focusing on reducing latency -
maybe some is relevant for you.

https://www.bufferbloat.net/projects/make-wifi-fast/wiki/
https://wiki.openwrt.org/doc/howto/sqm
https://www.bufferbloat.net/projects/bloat/wiki/Windows_Tips/

--

Björn


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

The push behind this is whole house audio. These guys want to be able to set up 
WiFi
speakers / mic's all through a home and get proper audio imaging in each room. 
They likely
also want to use it to figure out which mic you are talking to using time of 
arrival. They very 
much want to do this in real environments (300 WiFi nets in the building). 
Since they want to
roll it out that way, it’s got to be cheap and fairly robust. They need their 
gizmo to work with 
the infrastructure you already have.

Bob

> On Jan 15, 2017, at 9:35 AM, jimlux  wrote:
> 
> On 1/15/17 6:27 AM, Bob Camp wrote:
>> Hi
>> 
>> 
>> Again, this is why the interest in “how the heck did they accomplish it?
>> With the claim of microsecond level performance, they must have run
>> into all these issues.
> 
> or is it "with these two specific WiFi adapters in this specific environment, 
> we were able to achieve microsecond level performance, and who knows if it's 
> generalizable"
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[jimlux]

On 1/15/17 6:27 AM, Bob Camp wrote:

Hi


Again, this is why the interest in “how the heck did they accomplish it?
With the claim of microsecond level performance, they must have run
into all these issues.


or is it "with these two specific WiFi adapters in this specific 
environment, we were able to achieve microsecond level performance, and 
who knows if it's generalizable"




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi

I’d be surprised if a laptop running on wall power and doing a variety of low 
level
traffic every second is throttling the chip set. It *is* doing something weird 
and 
that certainly is one candidate. I’m not quite as concerned with the *why* the 
bumps 
occur (though I am curious). I’m more interested in the fact that they are 
really
enormous (compared to other delays). How they do microsecond timing with them
in the mix is the big question. 

Bob

> On Jan 15, 2017, at 8:33 AM, Tim Shoppa  wrote:
> 
> Bob, I think you are pushing me in this direction, but it was my conclusion
> before this discussion even began.
> 
> Most consumer WiFi devices will quiesce the WiFi chipset between major
> consumer-initiated usages for battery savings, so it's not surprising to
> see a good amount of random variation in ping times when done from a laptop.
> 
> Some apps that try to do timing over internet do a "wake-up call" of the
> interface first, and then do the timing. I don't know if this was ever
> added to ntpd but I work with all sorts of UDP applications that have to do
> application-level things like wake-up calls or application-layer keepalives
> to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
> dropped).
> 
> Tim N3QE
> 
> 
> 
> On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> 
>>> On Jan 14, 2017, at 1:38 PM, Chris Albertson 
>> wrote:
>>> 
>>> On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp  wrote:
>>> 
 Hi
 
 Ok, what I see is that every few hours, I get a “rogue delay” on a
>> single
 ping. How
 would NTP help me spot a single transit with a 250 ms round trip and
 identify the
 time it occured? Keep in mind that NTP is going to throttle back to a
>> very
 low level
 of “chat” quite quickly…..
 
>>> 
>>> I don't understand about NTP throttling back? Yes it quickly figure out
>> the
>>> best poll interval to each of the configure reference clocks but that is
>> a
>>> good thing.
>> 
>> Not a good thing if you want to check the link at least once a second and
>> keep
>> doing so for days and days. If the objective is to profile the timing
>> stability of
>> the WiFi link *and* catch all the stupid things that happen … you need a
>> lot
>> of data. There are things that happen at widely spaced intervals. Is a
>> ping the
>> best thing to use? Certainly not. There just aren’t a lot of other
>> candidates.
>> Indeed there can be such a thing as “to much data”, there is an ADEV thread
>> going along about that.
>> 
>> Bob
>> 
>>> You like those poll intervals to be as long as possible
>>> 
>>> It will tell you the TIME an event occurred with good accuracy.  Record
>> the
>>> ping delay and the ping's time of day in the file.  Then if you want to
>>> compare files between different logs made on different computers you can
>>> know that all the time stamps are comparable.  I assume you want to know
>>> the cause so you'd have to look at logs from other devices on your
>> network
>>> 
>>> Question: do something happen every hour to cause this or is that
>> something
>>> happening say every 13 seconds and sets in phase with the ping interval
>>> every hour?
>>> 
>>> Audio over wifi depends on "buffering".  The data are sent in packets or
>>> batches.  The device that actually plays the audio will keep as much as a
>>> few seconds of data and request more when the buffer gets about 1/2
>> empty.
>>> So delays over wifi are not important.   The re-timing is done on the
>>> receiving end, likely using a cheap crystal.
>>> 
>>> Audio over USB, HDMI to fiber TOSLINK is packetized as well and buffered
>>> and re-clocked at the receiving end.  The difference is the size of the
>>> buffer.  If it is packetized then it must be buffered and rechecked, no
>> way
>>> out of that.
>>> 
>>> So yes it is "giant buffers".  The data sent does contain the format, how
>>> many channels, the sample rate and so forth
>> 
>> … but If you are playing the sound out of multiple speakers scattered
>> around the
>> room *and* their only link is WiFi, time sync does matter. That’s what
>> started this
>> thread in the first place. Milisecond sync isn’t good enough in this case.
>> You need
>> microsecond level sync.
>> 
>> Bob
>> 
>>> 
 
 While this *is* getting far more into my WiFi (which I had no real
 intention of doing) it
 does apply to timing and running audio over WiFi as well. The basic
 transport as it
 runs up through the various layers is *not* very good time wise. There
>> is
 indeed a
 real need for some sort of overlay to take care of that issue. I’d still
 love to know if
 this magic protocol is simply giant buffers and some sort of tagging or
>> if
 they do
 something more interesting.
 
 Bob
> On Jan 14, 2017, at 12:32 AM, Chris Albertson <
>> albertson.ch...@gmail.com>
 wrote:
> 
> On Fri, Jan 13, 

Re: [time-nuts] wifi with time sync

[Bob Camp]

Hi


Again, this is why the interest in “how the heck did they accomplish it?
With the claim of microsecond level performance, they must have run
into all these issues. 



Just a note: any time I want to do anything that matters, I put it on 5 GHz.
There are still issues, but not quite as many. The data I presented is 
from a 5 GHz link. There’s also data over the same time period showing
LAN pings all running below 1 ms for the same 24 hour period. The random
delay bumps are WiFi specific. 

Bob

> On Jan 15, 2017, at 12:51 AM, Bill Hawkins  wrote:
> 
> 
> I haven't read the entire thread, but this may be relevant. If not, you
> know where to find the delete key.
> 
> I live in a life care community - one of 450 people in 300 apartments on
> 3 floors. When I moved in a year ago, I could get Internet from the
> house cable, and they provided the modem. I bought wired and wireless
> 802.11n dual band routers for two apartments, a two bedroom for us and
> an alcove for my shop. There was plenty of noise from other such
> routers, but no problem within an apartment. I couldn't use a wireless
> keyboard, though. The cursor wandered around with the noise.
> 
> Last month, a company experienced in wiring hotels for wireless put DSL
> to RJ-45 and 11n wireless access points in each apartment on the second
> floor, adding 100 transmitters to the mix. DSL with existing phone
> wiring was far cheaper than running new cable. The intent was to provide
> universal public Wi-Fi for the children of the residents.
> 
> They might as well have installed 100 jammers. There were complaints of
> unusable cordless phones (most in the 2.4 GHz range) and lost Wi-Fi
> connections that simply reverted to the default IP address range and
> failed to reconnect.
> 
> I got a home copy (this is my home) of InSSIDer software and surveyed
> the halls at 2.4 GHz with a Windows 7 laptop (you need a larger screen
> to see the signal distribution) I could see 10 to 20 of the new access
> points, as well as the occasional excursion to -10 dbm (top of scale) as
> nearby routers and printers kicked in. Great stuff.
> 
> There are environments where time sync with Wi-Fi hasn't got a chance.
> 
> Jim Lux was looking for a COTS solution to time sync, and this might
> work in a controlled environment.
> 
> Don't even think about consumer radio clocks that sync from unknown
> Wi-Fi environments.
> 
> Bill Hawkins (John Hawkins son)
> bill.i...@pobox.com
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] wifi with time sync

[Tim Shoppa]

Bob, I think you are pushing me in this direction, but it was my conclusion
before this discussion even began.

Most consumer WiFi devices will quiesce the WiFi chipset between major
consumer-initiated usages for battery savings, so it's not surprising to
see a good amount of random variation in ping times when done from a laptop.

Some apps that try to do timing over internet do a "wake-up call" of the
interface first, and then do the timing. I don't know if this was ever
added to ntpd but I work with all sorts of UDP applications that have to do
application-level things like wake-up calls or application-layer keepalives
to bring VPN tunnels "Back to life" (otherwise the first UDP packets are
dropped).

Tim N3QE



On Sat, Jan 14, 2017 at 2:02 PM, Bob Camp  wrote:

> Hi
>
>
> > On Jan 14, 2017, at 1:38 PM, Chris Albertson 
> wrote:
> >
> > On Sat, Jan 14, 2017 at 7:46 AM, Bob Camp  wrote:
> >
> >> Hi
> >>
> >> Ok, what I see is that every few hours, I get a “rogue delay” on a
> single
> >> ping. How
> >> would NTP help me spot a single transit with a 250 ms round trip and
> >> identify the
> >> time it occured? Keep in mind that NTP is going to throttle back to a
> very
> >> low level
> >> of “chat” quite quickly…..
> >>
> >
> > I don't understand about NTP throttling back? Yes it quickly figure out
> the
> > best poll interval to each of the configure reference clocks but that is
> a
> > good thing.
>
> Not a good thing if you want to check the link at least once a second and
> keep
> doing so for days and days. If the objective is to profile the timing
> stability of
> the WiFi link *and* catch all the stupid things that happen … you need a
> lot
> of data. There are things that happen at widely spaced intervals. Is a
> ping the
> best thing to use? Certainly not. There just aren’t a lot of other
> candidates.
> Indeed there can be such a thing as “to much data”, there is an ADEV thread
> going along about that.
>
> Bob
>
> > You like those poll intervals to be as long as possible
> >
> > It will tell you the TIME an event occurred with good accuracy.  Record
> the
> > ping delay and the ping's time of day in the file.  Then if you want to
> > compare files between different logs made on different computers you can
> > know that all the time stamps are comparable.  I assume you want to know
> > the cause so you'd have to look at logs from other devices on your
> network
> >
> > Question: do something happen every hour to cause this or is that
> something
> > happening say every 13 seconds and sets in phase with the ping interval
> > every hour?
> >
> > Audio over wifi depends on "buffering".  The data are sent in packets or
> > batches.  The device that actually plays the audio will keep as much as a
> > few seconds of data and request more when the buffer gets about 1/2
> empty.
> >  So delays over wifi are not important.   The re-timing is done on the
> > receiving end, likely using a cheap crystal.
> >
> > Audio over USB, HDMI to fiber TOSLINK is packetized as well and buffered
> > and re-clocked at the receiving end.  The difference is the size of the
> > buffer.  If it is packetized then it must be buffered and rechecked, no
> way
> > out of that.
> >
> > So yes it is "giant buffers".  The data sent does contain the format, how
> > many channels, the sample rate and so forth
>
> … but If you are playing the sound out of multiple speakers scattered
> around the
> room *and* their only link is WiFi, time sync does matter. That’s what
> started this
> thread in the first place. Milisecond sync isn’t good enough in this case.
> You need
> microsecond level sync.
>
> Bob
>
> >
> >>
> >> While this *is* getting far more into my WiFi (which I had no real
> >> intention of doing) it
> >> does apply to timing and running audio over WiFi as well. The basic
> >> transport as it
> >> runs up through the various layers is *not* very good time wise. There
> is
> >> indeed a
> >> real need for some sort of overlay to take care of that issue. I’d still
> >> love to know if
> >> this magic protocol is simply giant buffers and some sort of tagging or
> if
> >> they do
> >> something more interesting.
> >>
> >> Bob
> >>> On Jan 14, 2017, at 12:32 AM, Chris Albertson <
> albertson.ch...@gmail.com>
> >> wrote:
> >>>
> >>> On Fri, Jan 13, 2017 at 1:11 PM, Bob Camp  wrote:
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Survey plot as art.

[Andrew Rodland]

On Sat, Jan 7, 2017 at 12:54 PM, Peter Reilley  wrote:
>
> This is the survey from my Trimble NTBW50AA.   It looks like some bacteria
> floating around.

Relatedly, and just for fun, here's a video I made several years ago
from a few days worth of constellation status data out of a cheap SiRF
receiver. It's interesting to see how the satellite geometry changes
over time... or maybe it's just fun to watch the pretty colors. If
you're observant you can also get an idea for where the tall trees
were at my old apartment and maybe my approximate latitude.

The projection is stereographic from the nadir (I think), with 90°
elevation at the center, 0° elevation at the edges, and north up. The
"wiggles" near the edges are due to the granularity of the positions
from the receiver (half-degree, IIRC). Points are drawn with size and
brightness proportional to the log signal strength, and the trails
fade out exponentially.

Andrew
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.