After you get the position, how does the OP (or anyone else) put the
location data into the Trimble GPS receiver so that it can be used in
the time solution.  This is for NTP remember.

Assuming there is some way, will the Trimble GPS receiver "remember"
the location over a power cycle?

In other words, is there a way to program a Trimble receiver to NOT do
the self-survey on power up and instead to use some survey location
you got by some other method, like possibly hiring a survey team.

If there is a why to make that work, I might even modify the NTP
driver to do it.

On Sun, May 5, 2013 at 7:01 PM,  lists@lazygranch.com wrote:

--

Chris Albertson
Redondo Beach, California

On 6 May 2013 03:21, Chris Albertson albertson.chris@gmail.com wrote:

Hi Chris!

You can input the information through the Windows application and tell it
to not self-survey.

The position as all the configuration is stored in the EPROM when one
issues a command on the Windows interface.

Sure!

You'll have to make the driver talk to the configuration / monitoring port
(port B) as the timing port (port A) does not accept commands.

I thought about sending the configuration commands to port B and get the
time from port A. The problem with this is that you can't raise the RTS pin
to request a time packet from the receiver (they call this event
something... can't remember). What I did in the end was to use two
RS422-to-RS232 converters so I can use the driver normally through port A
and then set the receiver and see the birds it is following on port B. I've
also used the PPS+ signal and connected it to the DCD pin. Just completed
this project a few minutes ago. The machine has been running for a few
minutes:

acutime# uptime; ntpq -p; ntptime
10:34PM  up 31 mins, 1 user, load averages: 0.00, 0.00, 0.00
remote          refid      st t when poll reach  delay  offset
jitter

---============
*GPS_PALISADE(0) .GPS.            0 l  12  16  377    0.000    1.073
0.031
oPPS(0)          .PPS.            0 l  10  16  377    0.000    0.077
0.007
ntp_gettime() returns code 0 (OK)
time d532ae7f.98b1edec  Mon, May  6 2013 22:34:39.596, (.596465965),
maximum error 6000 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 72.469 us, frequency 143.112 ppm, interval 256 s,
maximum error 6000 us, estimated error 1 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 496 ppm,
pps frequency 143.112 ppm, stability 0.234 ppm, jitter 0.663 us,
intervals 29, jitter exceeded 23, stability exceeded 0, errors 3.

My configuration

server 127.127.29.0 mode 3 minpoll 4 maxpoll 4 prefer

Event polling (flag2 0)

fudge 127.127.29.0 flag2 0

PPS driver capture on rising (flag2 0) and kernel PPS active (flag3 1)

server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 0 flag3 1

statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loop type day link enable
filegen clockstats file clock type day link enable

With this configuration I can stop using the PALISADE driver and configure
the Acutime to send NMEA sentences and use the PPS for better accuracy.

Regards,
Miguel

On Mon, May 6, 2013 at 3:38 PM, Miguel Barbosa Gonçalves m@mbg.pt wrote:
..

So this does not apply to the Thunderbolt?  It only has one port.  If
it worked on all PALISADE type GPSes I'd do it.

NEMA is only used to number the seconds.  It is the PPS that does the
timing.  You don't gain accuracy with NEMA.

And interresting trick is to put two or more GPS units on the same
computer.  then use NTP to compare.  You can test out what works best
and measure the differences

--

Chris Albertson
Redondo Beach, California

On 07/05/2013, at 01:20, Chris Albertson albertson.chris@gmail.com wrote:

Chris,

I know NMEA is usually only used to number seconds. Usually, the
manufacturers don't care with the accuracy of the NMEA sentences but
in theory if they were output precisely they could be used with NTP.
For I time nut I believe that would not be enough.

But did you actually read what I wrote? ;)

I said that with my configuration I can use the PALISADE or NMEA and
PPS. Actually I am using PPS on both as the PALISADE only gives me too
much jitter on my serial port.

After several hours running some interesting data:

acutime# uptime; ntpq -p; ntptime
6:32AM  up  6:20, 1 user, load averages: 0.03, 0.04, 0.01
remote          refid      st t when poll reach  delay  offset  jitter

---============
-pfsense.localdo 193.62.22.90    2 u  27  64  377    1.342    0.089  0.259
*GPS_PALISADE(0) .GPS.            0 l  13  16  377    0.000    1.057  0.053
oPPS(0)          .PPS.            0 l  12  16  377    0.000    0.009  0.004
+ntp02.oal.ul.pt 194.117.9.138    2 u  23  64  377  10.456    0.584  0.312
-ntp04.oal.ul.pt 194.117.9.137    2 u    5  64  377  10.545  -1.559  6.550
+gatekeeper1.ist 193.204.114.232  2 u  22  64  377    9.480    0.673  0.228
-gatekeeper2.ist 192.93.2.20      2 u  61  64  377  11.570  -0.353  2.329
ntp_gettime() returns code 0 (OK)
time d5331e7c.79288cbc  Tue, May  7 2013  6:32:28.473, (.473275743),
maximum error 7000 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 9.366 us, frequency 144.542 ppm, interval 256 s,
maximum error 7000 us, estimated error 1 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 496 ppm,
pps frequency 144.542 ppm, stability 0.004 ppm, jitter 2.774 us,
intervals 111, jitter exceeded 535, stability exceeded 1, errors 1.

I still need to calibrate the PPS in order to account for the 200 feet
(60 m) of cable I have between the antenna and the server.

Cheers,
Miguel

That is a good idea. I find that in my LAN I can get two stratum 1
servers (with different brands of receivers) 5 us of each other
consistently. And for NTP I believe that is good enough.

Cheers,
Miguel