Re: [time-nuts] Anyone have experience with this antenna?

[Thomas Petig]

On Wed, Feb 07, 2018 at 03:07:24PM +, Poul-Henning Kamp wrote:
> 
> In message <875e4bc6-32c3-4724-afcd-086553ae5...@n1k.org>, Bob kb8tq writes:
>
> >Water wise, one might note the large piles of snow sitting on my antennas at 
> >the moment. Yes, I
> >could go knock it off, but somehow it just keeps coming back. Weird how 
> >winter works …. There
> >is no perfect solution.
>
> Somebody at BIPM told me that their antennas were heated and thermostatically
> kept at constant temperature.
This is how you (can) do it. Here a small picture and some info:
https://www.sp.se/en/index/resources/GNSS/Sidor/default.aspx

Thomas, SA6CID
___
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 Data Stream

[Thomas Petig]

Hi Marco,
What receiver? What do you mean with stream?
Besides the software of the manufacturer, the tools in RTKLIB could help
you as well.

I am not aware of NMEA sentences that contain raw data, you need to
parse the proprietary protocol of your receiver. 

Best,
   Thomas, SA6CID

On Sun, Nov 26, 2017 at 01:45:27PM +0100, Marco Cardelli wrote:
> Hi All,
> I've a question for all the group. Ho can I obtain a Rinex Data Stream from
> a GPS receiver? I need to convert NMEA data?
> 
> Thank you so much.
> Marco
> 
> *Best Regards,*
> *Marco Cardelli - IZ5IOW*
> ___
> 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] Lucent RFTG-u REF0-REF1 cable

[Thomas Petig]

Hi Jerry,
the 15 MHz is disabled by default, just bridging some pins enables the
output:
http://syncchannel.blogspot.se/2015/11/denuo-gps-hits-rev-b-dongles.html

If you want to insert some 1PPS signal to discipline it, you need some
fake some GPS messages. Dan has done some nice work here, a small ATTiny
is sufficient.

/Thomas, SA6CID


On Tue, Nov 14, 2017 at 08:30:54AM -0800, Jerry Hancock wrote:
> Bob, I thought you had to send it code, etc?  I have the two units
> with cable, etc running upstairs.  I want another one for in my office
> but the same guy only sells the REF0 and REF1 units separately now
> without the cable.  I thought about splitting the two and using this
> other GPS unit I have (it was one of the TAPR GPS Kits) to send the
> other one the 1pps.  You’re saying all you need is a plug?  I would
> need two functioning units.
> 
> Regards,
> 
> Jerry
> 
> 
> Jerry Hancock
> je...@hanler.com
> (415) 215-3779
> 
> > On Nov 14, 2017, at 8:13 AM, Bob Camp  wrote:
> > 
> > Hi
> > 
> > If you are going to get out the soldering iron, why simply make up a plug
> > to run the GPS unit stand alone?  Keep the second unit powered down 
> > as a set of spare parts….. Yes, it does depend a bit on what you are doing 
> > with them ….
> > 
> > Bob
> > 
> >> On Nov 13, 2017, at 11:50 PM, Jerry Hancock  wrote:
> >> 
> >> Anyone have a spare cable for the Lucent setup?  I guess I can make one 
> >> with some DB15 connectors but trying to skip the effort.
> >> 
> >> Thanks
> >> 
> >> Jerry
> >> ___
> >> 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] NEO-7M various modes

[Thomas Petig]

On Sat, Oct 28, 2017 at 05:27:01PM -0700, jimlux wrote:
> On 10/28/17 3:24 PM, Wayne Holder wrote:
> > uBlox has a utility called u-center
> >  that's a free
> > download.  You can use it to configure the various output options (and
> > enable and disable different messages) and a then save this config back to
> > the module as the start up default.
> >
> Downloaded it, hooked up the modules, found that they won't quite get a fix
> indoors next to the window, but if I take it outside, it will. Oddly, the
> SNR on the SVs is good enough, but there's something preventing the fix from
> happening.
>
> Maybe it's because it's a cold start, it needed to run for a while to
> acquire the almanac or something.
Could be multi-path. Line of sight is blocked and the RX is receiving
reflections, that traveled a bit longer. Thus, solving the navigation
equations fails, or sometimes even worse, gives a wrong position.
Walls, windows and water surfaces provide a multi-path signal with
rather good SNR.

/Thomas, SA6CID

>
>
>
>
>
> > Wayne
> >
> > On Sat, Oct 28, 2017 at 3:12 PM, jimlux  wrote:
> >
> > > I've got 4 NEO-7M-C modules hooked up to 7 beaglebone greens, side by
> > > side, and they're not behaving the same..
> > >
> > > I've got gpsd running, and I'm looking at the output of cgps and/or
> > > gpsmon, as well as ppstest
> > >
> > >
> > > Some emit NMEA sentences, others binary (ublox?) strings?
> > >
> > > Some get a fix and start toggling the 1pps line, others don't.
> > >
> > > Is there some command string one can send to them to put them into a known
> > > state (cold reset?) - the one that's working the best (I.e. has a fix AND
> > > toggles 1pps) seems to be putting out binary strings (when viewed with
> > > gpsmon).
> > >
> > >
> > > ___
> > > time-nuts mailing list -- time-nuts@febo.com
> > > To unsubscribe, go to https://www.febo.com/cgi-bin/m
> > > ailman/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.
>


signature.asc
Description: PGP signature
___
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] Ships fooled in GPS spoofing attack suggest Russian cyberweapon

[Thomas Petig]

Hi all,

On Mon, Aug 14, 2017 at 06:10:33PM -0400, Ron Bean wrote:
> >In a car it is even easier.  The car nav system KNOWS it must be on a
> >roadway.  The car's ground track (positional history) must be on a road.
>
> That's assuming the GPS company keeps their maps up to date (it doesn't
> matter how often you update the maps in the device if the company's maps
> don't keep up with reality). New roads appear, old ones occasionally get
> moved.
In a regular vehicle you can still look out of the window and see the
GNSS fools you.

For autonomous vehicles we have seen that even with a rather expensive
unit, that is fusing IMU with RTK, the position is not accurate enough.
We see offsets of >10 m in urban areas due to multipath[1]. Thus, I
believe, map matching with LIDAR, RADAR, Cameras, etc. is necessary to
navigate an autonomous vehicle in urban areas. This allows, as a side
effect, to detect spoofing.

On ships RADAR is standard if visibility is low, but doesn't help if
there are no obstacles above water.

Best regards,
   Thomas

[1] Fusing odometry information would help a bit.

___
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] WTB: GPSDO

[Thomas Petig]

Hi,

On Wed, Mar 22, 2017 at 05:20:31PM -0500, Chris Caudle wrote:
> On Wed, March 22, 2017 3:52 pm, Nick Sayer via time-nuts wrote:
> > My thunderbolt *insists* on being on the DC Pass port. If you put it on a
> > DC Block port (yes, something *else* is on the DC pass port and supplying
> > DC for the antenna and splitter at the time - other connected devices work
> > just fine) it's deaf.
>
> You need a DC load so that the GPS receiver thinks there is an active
> antenna attached. I think that is just a quirk of the Thunderbolts, that
> rather than just flagging an alarm and continuing to run, it gives up and
> won't even try to run.

They try to check if an active antenna is connected by measuring the DC
load. You can (not tested by me) simulate this with a Bias T and a
resistor to ground on the DC port. I think there are more receiver that
might require this. Many dedicated GPS splitters have such a DC load
'simulation' with around 200 Ohm to ground to keep the receiver happy.

Best,
   Thomas DK6KD/SA6CID

> --
> 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.
>


signature.asc
Description: Digital signature
___
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] WTB: GPSDO

[Thomas Petig]

Hi Tim,

On Tue, Mar 21, 2017 at 06:36:51PM -0700, Tim Lister wrote:
> [...]
> I have a Symmetricom 58532A GPS antenna which has a N female connector
> but my 3 current GPS receivers all have SMA female connectors. If I
> want to provide capacity for at least 4 receivers fed from the same
> antenna, I was wondering what the best option for a splitter and where
> to do the N-to-SMA conversion. I currently have a Mini-Circuits
> ZAP3PD-2 power splitter which does SMA input to 3 SMA outputs. This
> seems to work but the connected devices all complain of an Antenna
> short, which doesn't seem good. The other popular option seems to be
> the Symmetricom 58536A 1x4 splitter which would then require 3-4
> N-to-SMA cables - it looks like although this has gain, it seems to be
> more of "eliminating loss" than straight gain so would presumably not
> overpower the receivers' frontends. Or maybe there is another more
> suitable SMA splitter in the Mini Circuits confusingly extensive
> catalog ?
Your splitter looks ok, but it has DC pass through on all ports. I would
recommend to put DC-blocks on all but one. The problem is all your
receiver want to power up the antenna and deliver around 3 to 5 V supply
Voltage on the port, your splitter is short-circuit them, which is not
good, especially if the voltage does not match. (The minicircuits
datasheet for the ZA3PD-2+, I guess that is the one you meant,  says
RF+DC on all ports) The short-circuit might damage your receiver.

If you take a splitter without DC pass through, you will need an
additional bias-T to feed some supply voltage again.

The special GNSS splitters forward DC only from one port and provide
some 200 Ohm DC termination together with the DC-block on the other
ports to keep the receiver happy, i.e., it seems current consumption and
therefore believes the antenna is ok. Some have an amplifier to
compensate for the loss of the splitter, but it is not necessary if the
antenna delivers enough.

So the GNSS splitter is electrically, a splitter like you have, a
separate LNA in front and all but one port with a bias-T (in reverse,
this provides the DC-block and ensures the signal is not 200 Ohm
terminated) where the DC connector has 200 Ohm termination.

I personally use a NARDA 4372A-4 (10 Euros on Ebay) with three DC-blocks
from minicircuits to split the GNSS signals and a good outdoor antenna.

Best,
   Thomas, DK6KD/SA6CID


signature.asc
Description: Digital signature
___
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

[Thomas Petig]

Hi Bob,

On Sat, Feb 18, 2017 at 08:36:51AM -0500, Bob Camp wrote:
> Hi
>
> > On Feb 18, 2017, at 4:53 AM, David J Taylor  
> > wrote:
> >
> > Hi,
> >
> > I was wondering whether there is some data/information available on the
> > claimed +/- 100 ns jitter?
>
>
> I guess the previous was not complete enough.
>
> I routinely measure PPS jitter on GPS modules down well below 10 ns on a 
> 53131.
> That’s after sawtooth correction is applied. Without sawtooth correction, the 
> +/- 24
> or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
>
> The reference used is an HP 5071 with a high performance tube option.

I agree, in this setup we get this performance. I also agree that using
timers in capture mode on microprocessors will give this performance, as
you wrote before.

But as we where discussing the performance between capturing some PPS
via PCIe, serial i/o from the chipset, or some USB cable. The reference
clock is here the clock of the CPU, or OS. This clock is of course not
very precise, but the reason for capturing the PPS might be we want to
run some NTP server.

So, I thought actually of the jitter added on the way between our
accurate source (GPS rx), until we can capture our timer. How much can
this be? As far as I see we don't have a capture mode for the HPET. But,
if we have to do it in software, we get more than 100 ns jitter. I just
measured 60-80 ns for a instruction cache miss, with Intels mlc software.
Overall I would guess > 500 ns, are there measurements on this?

This then defines some lower bound of what can be archived for
synchronizing the clock off the OS. Also hardware time stamping on a
dedicated PPS card (or PTP ethernet card) does not help unless the clock
on the card is synchronized to the clock used by the OS.

So, can we do better?

Best regards,
Thomas
DK6KD
SA6CID

>

> Bob
>
> >
> > Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> > plotted, using some lines of Python, the time offset as attached. Just
> > to get an overview how it is 'worst case', i.e., user program, python,
> > etc. The 1PPS signal comes from a GPS rx.
> > Looks like a standard deviation of around 150 us.
> > y-axis:  measured pps offset from full second (computer time) in us,
> > x-axis pps pulse number.
> >
> > On the long term it looks interesting (while measuring I played with the
> > NTP server on this computer)
> > Until ca. second 1: ntpd synchronization via internet
> > Until ca. second 17000: made an additional LAN NTP server (GPS) available
> > Until the end: replaced ntpd with chrony (still using internet and local
> > servers)
> >
> > Interesting points:
> > -It looks surprisingly bad with using the normal ntpd (especially, there
> > is not really an improvement having an local GPS based server
> > available, did I do something wrong? Only the offset changes by ca. 3
> > ms.)
> > -It looks surprisingly good with chrony. But there are continuously
> > outliers of up to 4500 us, is this a result of the chrony control loop?
> > The time is wandering around with ntpd, but has less jitter.
> >
> > Conclusion:
> > Despite the 150 us stddev, the using PPS over USB gives some interesting
> > inside of what the local ntp server is actually doing. It looks to me
> > like it would be an improvement to use it when using ntpd, but not when
> > using chrony.
> >
> > Best regards,
> >  Thomas
> >  DK6KD
> >  SA6CID
> >
> > PS:
> > Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> > offset in us)
> > http://petig.eu/pps-usb.txt
> > =
> >
> > Thomas,
> >
> > I've done some tests with PPS over USB with Windows some time back, which 
> > showed that PPS?USB could be better than LAN-sync alone, but that also 
> > included a reduction of the poll interval from possibly 64 seconds for LAN 
> > sync to 16 seconds for PPS sync, which may have influenced the results.
> >
> > It would be helpful to have some units on the axes - 1 what? 
> > I'm guessing microseconds
> >
> > For comparison, here is a Raspberry Pi running NTP, with the reported 
> > offset plotted against time.
> >
> > http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
> >
> > This Raspberry Pi (running a seismic detector) is using an Ethernet 
> > connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a 
> > couple of switches to a very good stratum-1 server.  I would estimate from 
> > your graph that the jitter in offset is about 1 millisecond peak-to-peak, 
> > but it seems that I get less than that - perhaps 100 microseconds 
> > peak-to-peak with occasional excursions outside that.  This is with the 
> > latest reference version of NTP.
> >
> >remote   refid  st t when poll reach   delay   offset jitter
> > ==
> > *192.168.0.20.GPS.1 u   17   32  377   12.3510.000 0.428
> > 

[time-nuts] Lucent KS-24361 REF 0 standalone

[Thomas Petig]

Hi everyone,
I am currently trying to repeat previous work of members of this list in
convincing the REF 0, to run standalone with a given 1PPS signal from a
gps. Similar to:
https://syncchannel.blogspot.se/2015/08/standalone-operation-of-lucent-ks-24361.html

I am using a skytraq gps with 100ms, 74AC04 for inverting and level
shifting and I added the jumper wires on J5. I simulate the Oncore
messages with a python script using a usb->uart cable and triggering on
the 1PPS pulse on the CTS line. I am sending @@Ea, @@En, @@Bb, @@Ap,
@@Aw, @@Ag, @@At, @@Az, @@Bj, @@Bo with a delay of 75 ms, as suggested
in the blog above:
https://github.com/thpe/oncore/blob/master/oncore_emu.py

Surprisingly, I have a constant delay of 0.8 ms, and only a jitter of
+/-0.1 ms for the oncore messages compared to the pulse on the CTS line.

Short everything is working and if I force external 1PPS usage it locks
to it (NO GPS light goes off). Using pForth:
1 force_ext_1pps
1 force_gps_1pps

But, it does not do it on its own, since it ignores the tracking mode
for the satellites and, I guess after reading the Z3801A manual,
therefore it claims the GPS 1PPS signal as invalid. E.g., for the entry
with @@Ea:
0x02, 0x08, 0xFF, 0x82
meaning satellite 2 in mode 8 (used for positioning) it assumes mode 0.
The other values, like signal strength 0xFF and channel status 0x82 are
taken, even if I change them to something else. The mode value is
ignored no matter what it says.

In the attached files on sees that "GPS 1PPS Invalid: not tracking", and
the mode of the is 0. I forced it to use the external 1PPS signal.

So, the question what tiny detail did I miss while reading the mailing
list archive and those blogs on how to set the REF 0 up for standalone
operation just using the Oncore messages?

Does someone has dump of the communication between REF 1 and
REF 0, until the REF 0 is happy (I don't have a REF 1)?

Regards,
   Thomas
   DK6KD
   SA6CID
--- Primary Receiver Status ---
SYNCHRONIZATION . [ Outputs Valid ]
SmartClock Mode ___   Reference Outputs ___
>> Locked to GPS  TFOM 3 FFOM 0
   Recovery   1PPS TI +10.0 ns relative to GPS
   Holdover   HOLD THR 1.000 us
   Power-up   Holdover Uncertainty 
  Predict  2.0 us/initial 24 hrs

ACQUISITION  [ GPS 1PPS Valid ]
Tracking: 0    Not Tracking: 10 ___   Time 
   PRN  El  Az  PRN  El  Az   GPS  00:09:07 01 Jan 1998
   * 2  80  16   17  32   5   GPS 1PPS Invalid: not tracking
   * 4  48  32   18  48   0   ANT DLY  0 ns
   * 6  64   0Position 
   * 8  90   0MODE Hold
   *10  90   1
   *12  90   2LAT  N  23:18:06.080
   *14  90   3LON  E   8:59:34.784
   *16  90   4HGT+2.56 m  (GPS)
   *attempting to track   
HEALTH MONITOR . [ OK ]
Self Test: OKInt Pwr: OK   Oven Pwr: OK   OCXO: OK   EFC: OK   GPS Rcv: OK
TIME  0:00:15.0 DATE   1/01/1998
LAT  N  23:18:06.080
LON  E   8:59:34.784VIS SATS   10
HGT (msl)  2.56 TRACK SATS   8
HGT (gps)  2.56 RX STATUS   20
PDOP0.0

CHN  SVID  MODE   SS  STATUS
 1 2 0   25582
 2 4 0   25582
 3 6 0   25582
 4 8 0   25582
 510 0   25582
 612 0   25582
 714 0   25582
 816 0   25582
___
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.