Re: [time-nuts] WWVB information

[Tom Van Baak]

I've been talking with Doug to better understand why his Spectracom WWVB 
receiver shows the green lock indicator. This receiver should not work given 
the enhanced WWVB modulation we've had since 2012. Fortunately he has chosen 
not to touch anything while we ponder this.

Meanwhile I pulled out some Spectracom gear (8164) and was able to repro his 
green lock! But the 10 MHz output is very unstable so I'm pretty sure it is not 
locking at all. Looking at the schematic the green indicator seems primitive. 
So "lock" may not really mean it has robustly locked to the carrier. More 
details to follow.

If any of you have Spectracom WWVB 816x or 817x receivers you might want to try 
them too.

/tvb

- Original Message - 
From: "Martin VE3OAT" 
To: 
Cc: "Doug Millar" 
Sent: Thursday, April 12, 2018 5:12 PM
Subject: Re: [time-nuts] WWVB information


> Hi, Doug,
> How is your 8161 doing now?  Still synced properly?  Should I bring my 
> 8164 up from the basement?  I was so disappointed when WWVB changed 
> their modulation.  Thanks for any encouragement.
> 73,
> ... MartinVE3OAT
> 
> 
> On Wed, 11 Apr 2018 16:28:41 Doug Millar wrote :
> 
> > Hi, My Spectracom 8161 comparator and 8171A clock are chugging
> > right along in sync with the proper time. I have only looked at
> > the digital LED output and it is within one second of my other
> > WWVB  clocks.  Seems like magic. It came in synch about two
> > weeks ago and stayed there. I haven't changed anything in my
> > lab or moved the units. Antenna is still the same.
> > Pictures available. Doug K6JEY
> 
> ___
> 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] TCVCXO Adjustment

[Wayne Holder]

First, thanks for all the comments and suggestions,  It's given me a lot to
think about and research.

Based on the feedback I've received, I've started to investigate using the NTP
server approach suggested by Chris Caudle.  I also found this NIST Paper
 to be very useful, as it
gave me some insight into the measurement period needed to achieve a given
accuracy in the DUT given a certain level of deviation in the reference
used.  But, I think further reading will be required before I can reduce
this approach to a plan.  I anyone knows of additional info on using NTP to
calibrate precision oscillators, I'd appreciate hearing about it.

The basic unit of measurement for Longitudinal Timecode is the video frame
rate, or approximately 30 fps, depending on the video medium in use.
Current commercial Timecode Generators make claims like having a drift
of only 1 frame over 24 hours, so that's been my target for my design.   Based
on my math, I think a drift of only 1/30th of a second in 24 hours is
perhaps +/-0.5 PPP, or so, but someone please correct me if I'm wrong.
  Another solution used with older, less accurate timecode generators is to
periodically resync (or "Jam Sync") the different timecode generators to
the master timecode generator thoughout the day but, while I'm not a video
production expert, I think think this is a less desirable solution.

Using a GPS, as suggestion by Adrian Godwin, is also an option, as the PPS
signal could be used as a calibration reference.   Cheap, consumer GPS
modules have gotten quite cheap and, based on my own experience
using various uBlox modules, some can even function fairly well indoors
under some conditions.  However, I seem to recall some discussion here some
time back about the relative reliability of the PPS signal in some
situations.  I'll have to dig back though the archives and see if I can
learn anything from those threads.

To provide some additional details on my project for those that
are interested, the current plan is to build everything into a USB Stick
form factor.  The USB connection would be used to configure internal
options (frame rate, etc.), charge the internal Li-Poly battery and
also, potentially, perform the calibration.  The time code signal would
be output from a 3.5mm phone connector, so the suggestion to connect this
to the audio input of the computer doing the calibration also makes sense,
as this would take USB latency out of the picture (assuming that the sound
interface in the PC is not just implemented via a chip on the USB bus.)

Wayne
___
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] WWVB information

[Martin VE3OAT]

Hi, Doug,
How is your 8161 doing now?  Still synced properly?  Should I bring my 
8164 up from the basement?  I was so disappointed when WWVB changed 
their modulation.  Thanks for any encouragement.

73,
... MartinVE3OAT


On Wed, 11 Apr 2018 16:28:41 Doug Millar wrote :

> Hi, My Spectracom 8161 comparator and 8171A clock are chugging
> right along in sync with the proper time. I have only looked at
> the digital LED output and it is within one second of my other
> WWVB  clocks.  Seems like magic. It came in synch about two
> weeks ago and stayed there. I haven't changed anything in my
> lab or moved the units. Antenna is still the same.
> Pictures available. Doug K6JEY

___
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] RINEX for Android

[Mark Sims]

Lady Heather will write raw data capture files from any of the devices that it 
supports.  It can also read them in as a simulation file (except for "polled" 
receivers where you have to explicitly poll the receivers for each piece of 
data you want... the polling queries are not written to the receiver data 
capture files).

Heather might not config the receiver to send some of the "advanced" messages 
you might be interested in, but it is easy to modify the code to request those.

---

> So now I just need to get some binary files out of my GPS receivers.
___
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] Dual GPSDO - any advantage?

[ziggy9+time-nuts]

FYI eBay pulled the listing and they bounced the seller. Spent 15 minutes
on the phone with eBay and they canceled the purchase with an immediate
refund.

You'll probably need to call since with no listing and no seller, it's
nigh impossible to use the normal resolution methods.

Paul

On 04/11/2018 04:14 AM, Heinz Breuer wrote:
> The seller added 100 pieces. At this moment 110 are sold.
> Auction #273145006434
>
> Well it sounds too good to be true but I ordered 4 pieces just in case that 
> it is real.
>
> With PayPal there is little risk.
> vy 73 Heinz DH2FA, KM5VT
>
> Von meinem iPhone gesendet
>
>> Am 10.04.2018 um 23:25 schrieb Richard Solomon :
>>
>> In the past I have had excellent experiences with e-Bay when it comes to
>>
>> bad sellers. If the parts never arrive, there is no question, I got a refund.
>>
>> If the parts were not as described, still no problems.
>>
>>
>> e-Bay seems to have been more on the side of the Buyer lately. A far cry
>>
>> from their early days when the Seller's word was Gospel.
>>
>>
>> 73, Dick, W1KSZ
>>
>>
>> Sent from Outlook
>> 
>> From: time-nuts  on behalf of Dr. David Kirkby 
>> 
>> Sent: Tuesday, April 10, 2018 12:24:41 PM
>> To: Discussion of precise time and frequency measurement
>> Cc: gandal...@aol.com
>> Subject: Re: [time-nuts] Dual GPSDO - any advantage?
>>
>>> On 10 April 2018 at 17:11, Clint Jay  wrote:
>>>
>>> Sad to say I think I was right, the listings have been pulled already and
>>> the seller now has zero items for sale.
>> The listing has not been pulled. Yes the seller has 0 to sell, but because
>> he has sold out of the 100. I still have the purchase in my purchase
>> history, and no messages from eBay about fraud.
>>
>>> Get those paypal refund cases logged.
>> One would need to wait until they don't arrive. Luckily they were not much.
>>
>> Then it is better to complain to eBay first. If you don't get any
>> satisfaction from eBay, then you can go to PayPal. But by going directly to
>> PayPal, you will have lost the chance to get a refund via eBay. So the
>> sensible order to try to get refunds is
>>
>> 1) eBay
>> 2) PayPal
>> 3) Chargeback on credit card.
>>
>> Never advance to stage PayPal unless you have exhaused attempts at eBay.
>> Never make a chargeback unless you have exhaused atttempts at both eBay and
>> PayPal.
>>
>> Sometimes it can be a bit of an uphill struggle to get refunds from eBay
>> for dodgy sellers, but in this case it should be fairly easy if the goods
>> don't arrive. On the off-chance they do, we have scored well.
>>
>>
>> Clint. M0UAW IO83
>>
>>
>> Dave G8WRB.
>> ___
>> 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.


___
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] TCVCXO Adjustment

[Adrian Godwin]

Why not put a GPS receiver in it ?  It won't always get a lock, but if it
gets accurate time every few weeks it can do the long-term tweaking someone
suggested in the watch thread (call in to the watch repair two weeks
apart). Except it can be done more or less EVERY two weeks.

I agree, a phone app is also a way to implement the time code generator.
But there's a lot to be said for a self-contained box for some jobs, and
the hassle of linking it to a phone or PC can be avoided for $10 on the
BOM. It doesn't even need to be a 'good' one - the TCXO is going to keep it
accurate enough over the months you can spend tracking the error.


On Thu, Apr 12, 2018 at 11:21 PM, Chris Caudle 
wrote:

> On Tue, April 10, 2018 8:12 pm, Bob kb8tq wrote:
> > Since your typical PC does not have anything in it that is accurate to
> 0.1
> > ppm, you still need something as a reference to compare things to.
> > A GPS module or a GPSDO are probably the easiest things to get ahold of.
>
> Catching up on some of the time-nuts traffic, some of the messages about
> GPS API on phones make me wonder if a phone would not be a better option
> for a typical non-time-nut user than a PC.  Setting up a GPS receiver with
> PPS output with a modern PC that does not have a RS232 port available can
> be pretty tricky (you would probably be starting with a bare circuit board
> rather than a nicely packaged GPS device for starters), so maybe a phone
> with GPS built in that lets you grab raw time data would be a better setup
> for a user with limited experience setting up time measurement systems.
>
> Or maybe a GPS Arduino shield and build a calibration system from a second
> Arduino.
> Multiple possibilities that are hard to rule out until the hard
> performance limits are defined.
>
> --
> Chris Caudle
>
>
> ___
> 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] RINEX for Android

[jimlux]

On 4/12/18 1:29 PM, Björn wrote:

Hi Jim,

Teqc is not a Windows-only program.  There are actually several ARM/Debian 
compilations. I assume some receiver protocols have been implemented with NDAs 
attached (hey Trimble...) and that might be one reason not to distribute source 
code. However if JPL would have a long term need for a specific build - Perhaps 
Unavco would consider supporting that.

https://www.unavco.org/software/data-processing/teqc/teqc.html

Teqc does translation (binary to Rinex conversion), editing of rinex and 
quality control of rinex data.

Not sure if that is something you want/need to do at your Beaglebone or what 
post processing package you intend to use.  Some post processing softwares 
might eat uBlox binary natively - all likely support rinex.

—




interesting.. there's Rpi builds which *might* work, at least it's ARM.

This is for my backyard, not for JPL, but that doesn't stop me from 
poking the JPL people and having them ask UNAVCO.


So now I just need to get some binary files out of my GPS receivers.


___
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] RINEX for Android

[Michael Wouters]

Hello Jim,

There's a Perl script here
https://github.com/openttp/openttp/blob/develop/software/gpscv/ublox/ubloxlog.pl
that's for configuring and logging a ublox NEO-8MT. The caveat is that
it uses a custom file format. However, the associated processing
software, mktimetx,
will read this and produce RINEX. You will need to produce a fake file
of time-interval counter readings though, since mktimetx folds these
into the pseudoranges
(the software is for GPS common view time-transfer). As you will see,
this is all running on a Beaglebone.

If you want to modify the script to produce native binary files, the
equivalent script for the NVS NV08C
https://github.com/openttp/openttp/blob/develop/software/gpscv/nvs/nv08log.pl
does this, so you can use it as a guide for modifying - there are just
a few lines to change.

Cheers
Michael


On Thu, Apr 12, 2018 at 8:46 PM, jimlux  wrote:
> It turns out that some of the newer Android phones support an API which
> returns raw GNSS data and that can be logged to a file in RINEX format.
> There's a few apps out there that do this although I've not tried it (my
> Samsung S6 doesn't have the right hardware).
>
> In any case, it might be interesting, if you have one of these devices, to
> let it log for a while, with the phone in a fixed place, and then post
> process the data.
>
> I ran across this when looking for software to generate RINEX files from
> data from NEO-7 GPS modules (which I'm still looking for)
>
> ___
> 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] TCVCXO Adjustment

[Chris Caudle]

On Tue, April 10, 2018 8:12 pm, Bob kb8tq wrote:
> Since your typical PC does not have anything in it that is accurate to 0.1
> ppm, you still need something as a reference to compare things to.
> A GPS module or a GPSDO are probably the easiest things to get ahold of.

Catching up on some of the time-nuts traffic, some of the messages about
GPS API on phones make me wonder if a phone would not be a better option
for a typical non-time-nut user than a PC.  Setting up a GPS receiver with
PPS output with a modern PC that does not have a RS232 port available can
be pretty tricky (you would probably be starting with a bare circuit board
rather than a nicely packaged GPS device for starters), so maybe a phone
with GPS built in that lets you grab raw time data would be a better setup
for a user with limited experience setting up time measurement systems.

Or maybe a GPS Arduino shield and build a calibration system from a second
Arduino.
Multiple possibilities that are hard to rule out until the hard
performance limits are defined.

-- 
Chris Caudle


___
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] TCVCXO Adjustment

[Chris Caudle]

On Tue, April 10, 2018 6:10 pm, Wayne Holder wrote:
> which is spec'd at a frequency tolerance or +/- 1 PPM and a frequency
> stability of 0.28 PPM and a yearly aging of +/- 1 PPM max/year which, to
> me, seems pretty impressive for a part that costs about $8.

Something like this MEMS oscillator may also be worth consideration:
https://www.sitime.com/products/super-tcxo/sit5356

That page says the device is sampling now, so I have not seen one yet, but
the datasheet claims +/- 0.1ppm over temperature, initial tolerance of
1ppm, 1 year aging of +/- 0.5ppm, and 20 year aging of +/- 1ppm.

MEMS oscillators rely on fractional frequency PLL as an intrinsic part of
the design, so if you get the right part number you just write a frequency
update via I2C, so you would  not need an external DAC.

> I've been pondering how someone building the device
> would be able to easily and reliably calibrate it.

One of the big limitations in a commercial factory environment that you do
not face with a user built or user calibrated device is that commercial
test and calibration time is a cost incrementing by the minute.  For a
user calibration procedure you can take advantage of the fact that there
are several time sources which are noisy on short time scales, but average
out to low long term error.

> I'm basing the design around the Arduino, so the device could, in theory,
> use the USB Serial connection as a way to connect to a calibration program
> running on a PC.  I have a few idea on how to attempt to do this, but this
> is new territory for me, so I'm asking for advice and/or thoughts on how
> feasible this might be.  Is this a crazy, impractical idea given that all
> the builder will probably have available to perform the calibration is a
> regular PC and an Internet connection, or is there a way to make it work?

For a time-nuts class user the answers would be different, if you really
want to assume nothing but a PC and Internet it seems like you would be
limited to averaging external (i.e. off premise, contacted over the
Internet) NTP servers for long-ish periods of time.
Since the device you described is similar to a clock in that it just
constantly outputs time information, it seems that in principle you would
just need to read the timecode output from your device, compare that to a
known reliable time source (which for a typical non-time-nut I assume
would involve NTP), and average for long enough to build up confidence in
the rate difference between the known time source and your device.  Send
down a command to your device to adjust the frequency by enough to negate
the rate difference, then send down a command to update the current device
time to jump over whatever time error accumulated.

The amount of time you want to average (I think) just depends on how noisy
you think your current time estimates are, and how much precision you want
in the estimation of the rate differences.  Noise in the current time of
the calibration PC would typically be down to variations in network
latency if using remote network time sources.  Noise in retrieving the
current time of the timecode device would be in USB latency variations if
retrieving via USB (which would be on the order of the 1ms USB frame
time). You might be able to get better data from the timecode device by
just decoding the timecode audio stream in software.

The only other option which comes to mind would be incorporating longwave
radio receivers into the time setting in some way, but that would require
differences for each geographical region, and I do not think would be any
lower noise than network time for most users on modern Internet
connections.

Important to do up front will be to define specific performance limits you
would like to hit, and minimum acceptable performance.  I don't think you
will be able to really evaluate feasibility until you put real numbers on
your goals (initial accuracy, desired rate accuracy after x number of
weeks, whether you want to always adjust rate and current time
simultaneously, or if there are cases were averaging time to detect rate
it too long so you just want to jam sync current time, temperature range
over which the device has to maintain time, etc.).

-- 
Chris Caudle


___
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] RINEX for Android

[Björn]

Hi Jim,

Teqc is not a Windows-only program.  There are actually several ARM/Debian 
compilations. I assume some receiver protocols have been implemented with NDAs 
attached (hey Trimble...) and that might be one reason not to distribute source 
code. However if JPL would have a long term need for a specific build - Perhaps 
Unavco would consider supporting that. 

https://www.unavco.org/software/data-processing/teqc/teqc.html

Teqc does translation (binary to Rinex conversion), editing of rinex and 
quality control of rinex data. 

Not sure if that is something you want/need to do at your Beaglebone or what 
post processing package you intend to use.  Some post processing softwares 
might eat uBlox binary natively - all likely support rinex.

—

Björn 

Sent from my iPhone

>> On 12 Apr 2018, at 18:51, jimlux  wrote:
>> 
>> On 4/12/18 6:57 AM, Ole Petter Rønningen wrote:
>> I think teqc.exe can read ubx-files directly
>> Ole
>>> 12. apr. 2018 kl. 12:46 skrev jimlux :
>>> 
>>> It turns out that some of the newer Android phones support an API which 
>>> returns raw GNSS data and that can be logged to a file in RINEX format. 
>>> There's a few apps out there that do this although I've not tried it (my 
>>> Samsung S6 doesn't have the right hardware).
>>> 
>>> In any case, it might be interesting, if you have one of these devices, to 
>>> let it log for a while, with the phone in a fixed place, and then post 
>>> process the data.
>>> 
>>> I ran across this when looking for software to generate RINEX files from 
>>> data from NEO-7 GPS modules (which I'm still looking for)
>>> 
>>> _
> 
> 
> I'm working in a Beaglebone environment - ARM, Debian- so the Windows tools 
> don't work.  Before I go out and write python code to push characters out the 
> serial port and get the output, I was hoping that someone had done some of 
> this before.. I can do the conversion from a binary file to RINEX somewhere 
> else.
> 
> rtklib might do the trick, but might also be overkill.  It seems that all I 
> need to do is send the right strings to the GPS and it will start spitting 
> out the right binary messages, which I then capture and post process. 
> (perhaps using rtklib's utility to do binary to RINEX).
> 
> 
> 
> ___
> 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] Holdover: Z3801A vs KS-24361

[Mark Sims]

SS is signal strength.  CN is carrier to noise ratio.   They basically indicate 
the same thing, but their scale may be different.   You can't compare the 
absolute magnitude of the values from different types  of receivers,  only do 
relative comparisons.   Other receivers can report dBc, etc.  And Trimble 
devices can report AMU (amplitude measurement units).  Some Trimble devices 
don't support dBc readings.  By switching a Tbolt between AMU and dBc, I worked 
out a table that Lady Heather uses to convert AMU to dBc to that those devices 
can display the more common dBc values.  On the Trimble devices you set the 
signal level mask in AMUs.

---

> the Satellite Status area has a header of SS on the Z3801A and C/N on  the KS
___
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] RINEX for Android

[jimlux]

On 4/12/18 6:57 AM, Ole Petter Rønningen wrote:

I think teqc.exe can read ubx-files directly

Ole


12. apr. 2018 kl. 12:46 skrev jimlux :

It turns out that some of the newer Android phones support an API which returns 
raw GNSS data and that can be logged to a file in RINEX format. There's a few 
apps out there that do this although I've not tried it (my Samsung S6 doesn't 
have the right hardware).

In any case, it might be interesting, if you have one of these devices, to let 
it log for a while, with the phone in a fixed place, and then post process the 
data.

I ran across this when looking for software to generate RINEX files from data 
from NEO-7 GPS modules (which I'm still looking for)

_



I'm working in a Beaglebone environment - ARM, Debian- so the Windows 
tools don't work.  Before I go out and write python code to push 
characters out the serial port and get the output, I was hoping that 
someone had done some of this before.. I can do the conversion from a 
binary file to RINEX somewhere else.


rtklib might do the trick, but might also be overkill.  It seems that 
all I need to do is send the right strings to the GPS and it will start 
spitting out the right binary messages, which I then capture and post 
process. (perhaps using rtklib's utility to do binary to RINEX).




___
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] Weird Stuff Warehouse shutting down

[gary]

I was at Weird Stuffabout a month ago. Picked up a heavy microscope
base. Those are the things you really don't want to buy on ebay. 

To be honest, I wasn't finding much there. My dentist is nearby, and
that was when I would check them out. How old is the stuff on their
racks? Remember Bay Networks? 

Excess Solutions is still around for now, but the pickings have been
slim. I buy NEMA or NEMA type cases there for cheap. But the place is
so deep into San Jose that it isn't worth the trip.
http://www.excesssolutions.com/

I noticed the Electronics Fleamarket has moved again:
https://www.electronicsfleamarket.com/
This is a shadow of the Foothill days. 

As far as I'm concerned, when the Livermore Ham swapmeet left Las
Positas College, the show was over. 


___
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] RINEX for Android

[Scott Newell]

At 05:46 AM 4/12/2018, jimlux wrote:

It turns out that some of the newer Android phones support an API 
which returns raw GNSS data and that can be logged to a file in 
RINEX format. There's a few apps out there that do this although 
I've not tried it (my Samsung S6 doesn't have the right hardware).


I've not had good luck with the Google GNSSLogger app on a Nexus 5X 
(which is a supported device). Lots of crashes, very little logged 
data. I think the Nexus 9 tablet was the optimal device--something 
about leaving the GPS chipset powered up, so carrier phase data 
didn't have lots of cycle slips?



I ran across this when looking for software to generate RINEX files 
from data from NEO-7 GPS modules (which I'm still looking for)


Won't rtklib do it? (I recently received a china special NEO-7N 
module from ebay, but I've yet to run the raw data through rtklib. 
It's on my todo list. The unit seems to support the undocumented raw 
output formats and logging to flash, so I'm pretty sure it's a real 
ublox device.)


--
newell  N5TNL 


___
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] RINEX for Android

[Ole Petter Rønningen]

I think teqc.exe can read ubx-files directly

Ole

> 12. apr. 2018 kl. 12:46 skrev jimlux :
> 
> It turns out that some of the newer Android phones support an API which 
> returns raw GNSS data and that can be logged to a file in RINEX format. 
> There's a few apps out there that do this although I've not tried it (my 
> Samsung S6 doesn't have the right hardware).
> 
> In any case, it might be interesting, if you have one of these devices, to 
> let it log for a while, with the phone in a fixed place, and then post 
> process the data.
> 
> I ran across this when looking for software to generate RINEX files from data 
> from NEO-7 GPS modules (which I'm still looking for)
> 
> ___
> 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] Holdover: Z3801A vs KS-24361

[Bob kb8tq]

Hi



> On Apr 12, 2018, at 1:30 AM, Hal Murray  wrote:
> 
> On that Status page, A Z3801A says:
>  Predict  2.5 us/initial 24 hrs

That sounds about right for a 3801. The prediction is something better than
a wild guess and not what one would call a solid number.


> 
> A  KS-24361 says:
>  Predict  394.1 us/initial 24 hrs

That would suggest the unit is unlocked. It should be below 10 us. Just as with
the 3801, the estimate is a bit fuzzy. You should be able to see issues in the 
data
on the Z3809/Z3810.

 A prediction of < 1 can pop up on occasion, on either unit. More typical 
estimates
are in the “couple of us” range. If you yank the antenna, it still does a 
respectable 
~5 us / 24 hrs or so either way. 

> 
> Both have been running for weeks.
> 
> Is anybody seeing similar?

no

> 
> 
> Also, the Satellite Status area has a header of SS on the Z3801A and C/N on 
> the KS.  Does anybody know the units and/or what that is actually measuring?

There are tables that translate the Motorola (and some of the other brands) 
status 
numbers into rough dbc/ Hz. I would not count on the numbers on a 20+ year old
design lining up directly with the latest and greatest modern module. 
Apparently 
the SNR calculations are a bit weird.

Bob

> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> 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] RINEX for Android

[jimlux]

It turns out that some of the newer Android phones support an API which 
returns raw GNSS data and that can be logged to a file in RINEX format. 
There's a few apps out there that do this although I've not tried it (my 
Samsung S6 doesn't have the right hardware).


In any case, it might be interesting, if you have one of these devices, 
to let it log for a while, with the phone in a fixed place, and then 
post process the data.


I ran across this when looking for software to generate RINEX files from 
data from NEO-7 GPS modules (which I'm still looking for)


___
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] Cheap jitter measurements

[Gabs Ricalde]

On Mon, Apr 9, 2018 at 3:36 AM, Tom Van Baak  wrote:
>
> My mental model of a black box computer running NTP is that I should be able 
> to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me what 
> time it was. Use a GPSDO / Rb / picDIV to generate precise pulses. Compare 
> the known time of the pulse with the time the box says it was. Repeat many 
> times, collect data, look at the statistics; just as we would for any clock.
>
> Similarly, the box should be able to give me a pulse at a known time. In this 
> case it records the time it thinks the pulse went out, and your GPSDO / Rb / 
> TIC makes the actual measurement. Again, collect data and look at the 
> statistics; just as we would for any clock.

On Wed, Apr 11, 2018 at 2:59 AM, Hal Murray  wrote:
>
> I think that should be a reasonable project.
>
> 1) Write some code to grab the time, send a pulse, grab the time.  Log that.
> 2) Use a time-stamp counter to log the time of the pulse.
> 3) Write the software to merge the two log files.
>

Hal, tvb,

I have a Linux PPS driver that does the following:
(1) Wait for the PPS rising edge
(2) Get the time
(3) Assert a GPIO output
(4) Set a timer that runs the following after 500 ms:
(5) Get the time
(6) Clear the GPIO output
(7) Get the time

The timestamps from (2) are the ones read by ntpd and it looks like this:
1523452407.99977
1523452408.4
1523452410.00021
1523452410.99977
1523452412.00028
PPS is from a u-blox LEA-6T.

(3) is the PPS echo and we will use that to measure the PPS latency.

The timestamps from (5) and (7) look like this:
1523452408.500016042 1523452408.500016467
1523452409.57535 1523452409.57955
1523452410.57246 1523452410.57666
1523452411.58362 1523452411.58782
1523452412.59269 1523452412.500010034

I don't have a TIC so I'm using the LEA-6T external interrupt for
measuring the edges from (3) and (6). The edges are timestamped with a
23 ns accuracy and reported in the TIM-TM2 (time mark) message. The
rising/falling edge values look like this:
306808.00845 306808.500016630
306809.00957 306809.58118
306810.00904 306810.57835
306811.00850 306811.58948
306812.00963 306812.500010207

The integer part is the UTC TOW.
The fractional part of the rising edge is the upper bound of the PPS latency.

Now we can subtract the (5)/(7) timestamps and the u-blox TIM-TM2
falling edge values:
1523452408 -0.00588 -0.00163
1523452409 -0.00583 -0.00163
1523452410 -0.00589 -0.00169
1523452411 -0.00586 -0.00166
1523452412 -0.00938 -0.00173

I've attached some plots:
"pps offset.png" is (2) minus round( (2) )
"before gpio clear.png" is (5) minus TIM-TM2 falling edge
"after gpio clear.png" is (7) minus TIM-TM2 falling edge
___
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] Holdover: Z3801A vs KS-24361

[Hal Murray]

On that Status page, A Z3801A says:
  Predict  2.5 us/initial 24 hrs

A  KS-24361 says:
  Predict  394.1 us/initial 24 hrs

Both have been running for weeks.

Is anybody seeing similar?


Also, the Satellite Status area has a header of SS on the Z3801A and C/N on 
the KS.  Does anybody know the units and/or what that is actually measuring?

-- 
These are my opinions.  I hate spam.



___
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] Cheap jitter measurements

[J Grizzard]

It's worth noting that you can get rid of a /lot/ of the variance on a 
modern linux box:


1) Set the CPU to run at the same speed at all times (generally "max 
performance" but which way you do it doesn't really matter)
2) Set processor masks so that no processes other than your timing code 
runs on a core of your choice. On hyperthreaded processors, make sure 
nothing is scheduled on the other 'half' of that core.

3) Set your interrupts to not be scheduled onto that core
4) Make sure your timing code fits in the L1 cache
5) When possible, make sure you don't conditionally branch. The last 
means instead of doing something like this:


while true {
  if x < y {
    continue loop
  } else {
    write to hardware
  }
}

You do something more like:

while true {
compare x to y
  conditional mov 1 to hardware register on x gt y
  conditional mov 0 to hardware register on x lte y
}

(and if possible, write to memory-mapped hardware pages, rather than 
making calls into the kernel)


This guarantees that both a) latency writing to hardware is consistent 
every loop pass (though hardware-induced jitter isn't), and b) that 
there are no branch mispredicts because there are no conditional 
branches -- conditional move instructions take a constant time to 
execute (plus or minus memory access latency).


This basically removes the entire kernel from the picture, any other 
processes from the picture, and shared CPU resources from the picture, 
except for those times that you have no choice but to access the memory 
bus and such. Otherwise, your code will just sit there on its own core 
doing its own thing and nothing will interrupt it and most sources of 
unknown jitter are removed.


(It's not perfect, but it's probably the closest you'll get on a PC 
without specialized hardware. Though I _do_ wonder what could be done 
with something like the intel i210AT chips on like the apu2 hardware, 
which can do hardware PPS out and hardware event timestamping...)


-j

On 4/11/2018 4:01 PM, Hal Murray wrote:

kb...@n1k.org said:

Except that’s not the way most timers run. The silicon needed to get a
programable  divider to work at 2.4 GHz is expensive. If you dig into the
hardware descriptions,  the clock tree feeds something much slower to the
“top end� of the typical timer in a CPU or MCU. The exception is the high
perf timers in some of the Intel chips.  There the issue is getting them to
relate to anything “outside� the chip.

I think I got started in this area back in the early DEC Alpha days.  They
had a register that counted raw clock cycles.  Simple.  I got stuck thinking
that was the obvious/clean way to do things.

Many thanks for giving me a poke to go learn more about this area.

That was back before battery operation was as interesting as it is today.  I
suspect power is more likely the critical factor.  Half the power goes into
the low order bit, so counting by 4 every 4th cycle rather than 1 every cycle
saves 3/4 of the power.



That may be what the kernel does, but it implements the result as a drop /
add to a counter.

If the source of time is a register counting CPU clock ticks, and the CPU
clock (2 or 3 GHz) is faster than the resolution of the clock (1 ns) it will
be hard to see any drop/add.  However, if the time register is significantly
slower, then the drop/add is easy to spot.  But all that is lost in the noise
of cache misses and such.

Here is a histogram from an Intel Atom running at 1.6 GHz.

First pass, using rpcc.
 cycles  Hits
 24 86932
 36904825
 48  8011
 60   122
 72 1
14411
...
So it looks like the cycle counter gets bumped by 12.  That's a strange
number.  I suspect it's tangled up with changing the clock speed to save
power.  There are conflicting interests in this area.  If you want to keep
time, you need a register than ticks at a constant rate as you change speed.
If you are doing performance analysis, you want a register than counts cycles
at whatever speed the CPU is running.  Or maybe I'm confused.

Second pass, using clock_gettime.
   nSec  Hits
698 2
768 5
769 2
838 3
908 2
977 1
978 3
   1047237102
   1048383246
   1117204072
   1118172490
   1187   275
   1188   135
   1257   263
   125847
   1326 7
   1327   216
...
The clock seems to be ticking in 70ns steps.  That doesn't match 12 clock
cycles so I assume they are using something else.

>From another system:
Second pass, using clock_gettime.
   nSec  Hits
 19 45693
 20347538
 21591129
 22 15284
 2363
 2434
 2532
...
Note that this is 50 times faster than the previous example.

I haven't figured out the kernel and