Re: [time-nuts] nuts about position (cheap receiver)

[J Grizzard]

On 5/3/2018 9:26 AM, Mark Sims wrote:

Those results were with the "ultra rapid" orbits.  It will be interesting to 
see what they look like when the final precise orbits are available in a couple of weeks.

I also need to see how those values compare to Lady Heather's precision survey 
results.


FWIW, a dual-frequency PPP run I did late last year has the following 
uncertainties, when processed with the various IGS precision 
ephemerides, via AUSPOS:


    longitude   latitude  altitude
IGS UltraRapid 0.004m 0.003m    0.013m
IGS Rapid  0.004m 0.003m    0.012m
IGS Final  0.004m 0.003m 0.012m

The computed ECEF coordinates change by 0.003m(X) and 0.001m(Z) between 
UltraRapid and Final.


...so really not much of a difference between UltraRapid and Final, at 
least for a dual-frequency survey at my location.


*digs through old stuff*

Okay, found a single-frequency survey from mid-last-year, processed by CSRS:

    longitude   latitude  altitude
NRCan Rapid    0.103m    0.121m 0.253m
IGS Final  0.103m 0.121m 0.252m

...not much difference there, either.

Both of these were with a roof-mounted antenna and a good skyview, 
running 24 hours. The first was one measurement every 15 seconds, the 
latter one measurement per second. (I think for these purposes, one 
measurement every 15 seconds is more than sufficient and makes the files 
process *so* much faster).


-j
___
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] nuts about position

[J. Grizzard]

I think to really be confident about a position you really need the 
dual-frequency data (or that data from a nearby reference station), 
otherwise you could end up in a situation where you're consistent, but 
that consistency has a bias. IIRC, anyhow -- I'm not sure how the math 
actually works out.


Anyhow, I play around with PPP stuff on occasion, and the last run I did 
was in November using the Novatel OEM628 kit that was briefly available 
for cheap on eBay, and the included 702-GG antenna (which, conveniently, 
has calibrations available). Running a day's worth of data through 
CSRS-PPP produced sigmas (95%) of 0.004m latitude, 0.008m longitude, and 
0.024m in elevation. I've done some shorter runs since then that appear 
to fall in that same range ... I really need to do a few more full runs 
and see what kind of variance there is.


At any rate, theoretically you can get ^^^ that close, anyhow. CSRS even 
takes solid earth tides into account, though I didn't do that because I 
was never able to figure out which specific type of solid earth tide 
data I needed. I imagine there's still some issues with any given datum 
being somewhat imperfect, as far as altitude is concerned, and I don't 
really know how to correctly deal with that if exact altitude matters. 
Maybe we should all just agree to use XYZ/ECEF coordinates for 
everything and give up on this whole altitude thing altogether... ;)


(As an aside, I've been tempted to get someone to come professionally 
survey my antenna and tell me where it _actually_ is, so I could see how 
well I could actually do with my GPS kit, but I imagine it's pretty 
expensive -- anyone happen to know what getting that kind of thing done 
actually ends up costing?)


-j


On 4/25/18 8:38 AM, Tim Lister wrote:

On Wed, Apr 25, 2018 at 7:56 AM, Tom Van Baak  wrote:

List -- I had a recent query by a researcher who would like to pinpoint the 
location of his telescope(s) within 0.3 meters. Also (he must be a true 
scientist) he wants to do this on-the-cheap. He may have timing requirements as 
well, but that's another posting.

So I toss the GPS question to the group. Surely some of you have crossed the 
line from precise time to precise location?

How easy, how cheap, how possible is it to obtain 0.3 m accuracy in 3D position?

When we run our GPSDO in survey mode how accurate a position do we get after an 
hour, or even 24 or 48 hours? And here I mean accurate, not stable. Have any of 
you compared that self-reported, self-survey result against an independently 
measured professional result or known benchmark?

Do you know if cheap ublox 5/6/7/8 series receivers are capable of 1 foot 
accuracy given enough time?

If not, what improvement would -T models and RINEX-based web-service 
post-processing provide?

It that's still not close enough to 0.3 m, is one then forced to use more 
expensive multi-frequency (L1/L2) or multi-band (GPS, GLONASS, Galileo) to 
achieve this level of precision? If so, how cheaply can one do this? Or is the 
learning curve more expensive than just hiring an survey specialist to make a 
one-time cm-level measurement for you?

Something tells me 1 foot accuracy in position is possible and actually easier 
than 1 ns accuracy in time. I'm hoping some of you can help recommend 
solution(s) to the researcher's question or shed light on this interesting 
challenge.

Hi Tom, list, as another researcher who is also interested in
telescope positions (!) I have done this for personal use at home with
a ublox 6T and 53532A antenna to see what I got. I was logging in the
UBX binary format with the raw (carrier phase) measurements turned on
and then converting it to RINEX and using the NRC's CSRS-PPP online
service which is one of the few that will take single frequency L1
only data. The results based on approx. 41.5 hours of data and which
were post-processed 21 days later (so that they used the IGS Final
products rather than the Rapids or Ultra Rapids) were Sigmas(95%) of
0.105 m, 0.089 m, 0.217 m in latitude, longitude and ellipsoidal
height respectively. I was quite impressed with the results without
use of the L2 frequency to correct for the ionosphere etc.


Thanks,
/tvb


Cheers,
Tim
___
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] 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 lib

[time-nuts] GPS L2 CNAV health reporting changes

[J. Grizzard]

I got a message from the Swiftnav support folks yesterday (I have a 
piksi multi amongst my little fleet of GPSen) because they had an 
emergency firmware patch to their kit because of a change in the L2C 
signal was giving them issues. (Props to them for getting a firmware 
update out in ~12 hour, too)


After a little bit of inquiring, it looks like what happened is that 
yesterday, the L2 CNAV message started marking all of the L1 signals as 
unhealthy. If a device actually listens to this health signal 
(apparently their GPS did), suddenly most GPS satellites become unusable 
(with the only remaining ones being ones that aren't transmitting an L2C 
signal).


(According to NANU 2014039, you shouldn't be using those health 
indicators, though it does also say that the L1 health indicators would 
all indicate "healthy", so this seems to be a departure from their 
stated plan.)


Anyhow, probably doesn't affect anyone here, but I thought it was 
interesting. Sadly, I can't see what's actually being transmitted, since 
my only pieces of kit that can decode L2C are my piksi (which won't give 
me raw NAV/CNAV, and they apparently have zero interest in adding that 
functionality), and the Novatel OEM628 that I picked up off eBay last 
year ... which crashes every 20 or 30 minutes if I ask it to decode L2C. 
Argh.


(Maybe u-blox's upcoming kit will be affordable(ish) and have good raw 
CNAV output... I can hope, right?)


-j

___
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] Slightly OT: interest in a four-output, ultra-low jitter, synthesizer block?

[J. Grizzard]

Can anybody comment on the toaster oven approach?

Is it practical for things like this?  How much does a solder mask cost?  How
much other stuff do I need?  Does the solder paste need to be refrigerated
and other quirks like that?

What are the chances of a newbie getting a 44-QFN right on the first try?
If you have a toaster that you have modified to retain heat better and 
has an actual reflow controller, the toaster approach works /really/ 
well. The toaster I built follows the JEDEC-standard reflow profile 
pretty much to the letter, other than taking longer to cool down than it 
should (due to not having any sort of fan to move air). So as far as the 
solder and components are concerned, it's basically no different than a 
decent commercial reflow oven.


If you (or anyone) goes the toaster route, I really recommend getting a 
conversion kit -- I used the Controleo2 (from http://whizoo.com/) -- 
they have a v3 now with a graphical touchscreen. You want the kit 
(rather than just the controller) because a normal toaster oven just 
leaks too much heat, and won't heat up fast enough, so you need to do a 
bunch of other things to one to actually be able to hit your curves. 
(They have their whole build guide at http://whizoo.com/reflowoven, so 
you can see what you have to do. I built mine over a weekend. I believe 
their current kit comes with everything you need but the toaster (their 
previous kit required the addition of sealant, a tray, and the 
insulation blanket)).


It's basically fire-and-forget -- populate board, stick in oven, press 
'start', come back in a bit...


Stencils are pretty cheap (and fast!). I don't remember the exact price 
off the top of my head, but I did a not-small board recently (60x110mm), 
and the stencil (via OSHStencils) was less than $10, and got to me in 
two days, and they're pretty much the same stencils any assembly house 
would use.


The main problem with solder paste is that the flux degrades over time 
(and you /really/ want your flux). Refrigeration slows that down, but 
there's limits. You can, though, buy your solder paste in small 
quantities (I think a 15g syringe, which will do a pretty decent number 
of boards, is ~$15), so having it eventually go bad isn't that big a 
deal. People have reported getting ok results with years-old paste, 
though -- I suspect the results will be at least partially dependent on 
the details of your board design (how fine-pitch the footprints are, and 
such).


Odds of getting a 44-QFN right on the first try are pretty good. Neither 
the chip nor the solder paste need be perfectly aligned for things to 
work, at least if you're using a PCB with a proper soldermask. At that 
pitch, you could probably even just smear some solder paste over the 
pads, place the chip, and have success (though I still suggest a 
stencil). The biggest problem source (for me, at least) is getting /too 
much/ solder paste down (and ending up with bridge pins because there's 
just no other place for the solder to go), thus the use of a stencil...


-j
___
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] SI5328

[J. Grizzard]

There are many small volume assmebly houses available. But the problem
is that you will have setup costs in the order of at least 100-300€,
even if you go to China. So, producing lots of less than 10 is not economical,
probably should aim for 100.


I recently ran across MacroFab (https://macrofab.com/), who can do small 
orders (quantity: 1) of boards, assembled, for what seems like 
reasonable prices. I haven't actually used them, but I did run a recent 
board through their process (except for actually ordering), and they 
came out with a price of ~$170 for a board that cost me ~$100 to 
assemble myself ($35 for board, ~$65 for BoM), so that's not too bad. I 
imagine the numbers would be smaller for simpler boards (this one is ~80 
components and pretty big -- 110mm x 60mm). The price came down pretty 
quick for quantity 3 or 5 or 10, though I don't remember the specifics.


The downside being that you have to be able to upload part-placement 
info that is actually correct. Most layout programs don't seem to have 
an issue generating it, though -- I just uploaded my gerbers and my 
KiCad PCB file and it just ran with it.


FWIW, it's not that hard to do even fine-pitch SMD stuff onesself. 
There's a little bit of startup cost (you really want to build a proper 
reflow toaster), but with high quality PCBs available via OSHPark (and 
fast! My *four layer* board was ~10 days), and quality stencils 
available via OSHStencils, doing even fine-pitch SMD work at home is 
surprisingly easy. In most simple cases, you don't even need the stencils...


-j
___
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] Did anyone grab an extra Novatel GPS?

[J. Grizzard]

A couple months back, Gregory posted a heads-up that there were some 
pretty cheap Novatel dual-frequency GPSses on eBay (thanks, btw!). I 
managed to get one of these ('make an offer' for $450) and ... it's 
actually pretty nice. Not only a decent GPS, and dual-frequency, but the 
included antenna is one of the standard antennas that has a formal 
calibration done for it, and thus has accurate ATX files available 
(which is awesome for doing PPP post-processing).


In fact, they're nice enough that I really wish I'd gotten more than 
one. Sadly, the lot from the seller sold out before I was able to 
actually do much with the unit I bought, so I can't get more that way. :(


So I thought I'd ask here -- did anyone grab extras of these that they 
don't necessarily want, that they'd be willing to send my way for a 
similar price? I'd love to be able to get at least one more of these. 
It's a long shot, but can't hurt to ask, right?


Related: I'm working on a breakout board for the actual GPS board (not 
the whole SPAN-CPT, but the smaller GPS board inside) to make it easier 
to get at the serial, USB, and ethernet (yay!) functionality of the 
board. I'll post here once I actually have something that works.


-j

___
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] Fw: Skytraq / GPS Almanac

[J. Grizzard]

So Tom and I were batting this one around for a while, and think 
we mostly know what the proximal cause of the reported problems are, 
even if we don't know the specific code bug that causes the Skytraq 
failure. I have a database of recent (last year) broadcast parameters 
that made it pretty easy to spot what was going on.


Short version: The IODC ("Issue of Data, Clock") broadcast parameter is 
a 10-bit value (the lower 8 bits of which match up with the associated 
IODE ("Issue of Data, Ephemeris") value). Until recently, the IODC value 
has only contained 8-bit values, with a couple of brief minor exceptions 
(getting up to 263 for a few individual PRNs for a single almanac 
version). Starting on 2017-09-22 (at roughly 11:30UTC, give or take half 
an hour), this value began regularly (exclusively, actually) having 
values that are no longer expressible as 8-bit values. This, we are 
guessing, has triggered some latent bug in the Skytraq firmware.


I tossed up a quick graph of IODC values for each PRN for the past year 
at https://gf.lupine.org/dashboard/db/gps-temp-iodc-by-prn (pardon the 
missing data from 9/8 to 9/18, please). You can see that the values stay 
below 255 right up until the 22nd, at which point the values cross that 
threshold and just keep going up. (You can zoom out or use the arrows to 
move back in time to see that this is truly a unique event, at least as 
far back as I have data.)


Values up to 1023 are completely legitimate, but since we haven't really 
seen many over 255 (and never across the entire constellation), some 
latent bug could have easily been sitting around unknown for all these 
years.


IS-GPS-200H (20.3.4.4) specifies:

   The IODE is an 8 bit number equal to the 8 LSBs of the 10 bit IODC
   of the same data set. [...] The range of IODC will be as given in
   Table 20-XI for Block II/IIA SVs and Table 20-XII for Block
   IIR/IIR-M/IIF and GPS III SVs.

...and table 20-XI specifies:

   IODC values for blocks with 2- or 4-hour transmission intervals (at
   least the first 14 days after upload) /(these are the normal almanac
   uploads used -j)/ shall be any numbers in the range 0 to 1023
   excluding those values of IODC that correspond to IODE values in the
   range 240-255, subject to the constraints on re-transmission given
   in paragraph 20.3.4.4

...so it's possible that there's some bug in the firmware where they're 
doing "if IODE == IODC" rather than "if IODE == (IODC&0xff)", which 
would give the correct result for 99.9% of past almanacs, but not any 
more. Or it's possible they're stuffing IODC into an 8-bit variable and 
getting seemingly-repeat values out of it or something. I dunno the 
exact bug, but it seems pretty obvious that's where it is.


Always interesting when a completely valid value -- but different from 
the norm -- can uncover odd bugs like this.


(...this little adventure has also reminded Tom and I that one of us 
really needs to get around to our respective projects to record the raw 
GPS datastream full-time. I really need to build myself a little carrier 
for the still-sealed ublox chips I have so I can work on grabbing the 
raw frames from that... sigh. Too many projects, not enough time [sic])


-j

On 9/26/17 3:20 PM, Tom Van Baak wrote:

An interesting note from Said, below...
I've sent a couple of queries out to GPS professionals.
Feel free to comment if you have concrete information that would help.
Also, if during the past week any of you were logging almanacs or continuously 
recording the 50 bps raw data from any GPS/SV, please let me know.

Thanks,
/tvb


___
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] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards

[J. Grizzard]

I really recommend the PC Engines apu2c hardware. Just a touch over $100,
schematics available, hardware serial port, GPIO, 1588-capable PHY, CPU
crystal accessible if you want to try a clockblock-type hack, great
support, and just decent all around.

There's also test pads for the PHY that could be used to do PPS directly
to that for PTP purposes, but I haven't quite yet figured out exactly
how to set that up. But the pads are there!

(hint: Order direct from manufacturer, not via a US distributor. You'll
save money and the shipping is still really quite fast.)

-j

On Tue, Feb 14, 2017 at 05:26:16PM -0500, Scott Stobbe wrote:
> Something like this would make a great NTP server.
> https://www.digikey.com/products/en?keywords=P0286-ND
> 
> Too bad they didn't include a PTP 1588 capable PHY...
> 
> On Tue, Feb 14, 2017 at 12:33 PM, Chris Albertson  > wrote:
> 
> > Here is a something that could work.  It has a real serial port and you
> > could add more ethernet controllers, uses very little power and cost only
> > $60.
> > www.newegg.com/
> >  > N82E16813157497&cm_re=j1900-_-13-157-497-_-Product>
> >
> > There are other boards like this that use the same J1900 CPU.   I'm
> > thinking about using this as th machine tool (milling machine) controller.
> >
> > On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp  wrote:
> >
> > > Hi
> > >
> > > A direct port might be a +/- 100 ns sort of thing most of the time and a
> > > +/-10 us
> > > thing every so often under some OS???s. Most desktop operating systems are
> > > not
> > > designed to prioritize random pin interrupts. A dirt cheap MCU coded with
> > > a few
> > > (hundred) lines of assembly code may be a better option than a typical
> > > desktop.
> > > Complicating this further is the degree to which some OS???s can be
> > directly
> > > or
> > > indirectly optimized. Install *this* package and it all goes nuts.
> > Install
> > > that package
> > >  and not much happens ???.
> > >
> > > Bob
> > >
> > > > On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin  > >
> > > wrote:
> > > >
> > > > Hi, generally speaking, what are the performance differences between
> > the
> > > following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> > > offering RS-232---essentially UARTs interfaced more-or-less directly to
> > the
> > > PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
> > > have an IRIG input or even an onboard GNSS receiver).
> > > >
> > > > Thanks in advance,
> > > > Ruslan
> > > > ___
> > > > 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.
> > >
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > ___
> > 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.