Re: verifying ntp via GPS configuration?

2007-04-15 Thread Chris Cappuccio
James Hartley [EMAIL PROTECTED] wrote:
 
 Do you have any other ideas?  Thanks.

Some receivers I've tried work at 9600 instead of 4800...



Re: verifying ntp via GPS configuration?

2007-04-12 Thread Marc Balmer

James Hartley wrote:

On 4/11/07, Otto Moerbeek [EMAIL PROTECTED] wrote:

sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1

man sab gives: /dev/ttyh[0-1]

No separate callout device, it looks like.



Thanks for getting back to me.  Specifying /dev/ttyh0 (or /dev/ttyh1) gives
the same results.  I still don't see any sensor when issuing:

# sysctl hw

...nor is anything showing up in /var/log/daemon except for the following
message:

Apr 11 19:16:43 shockley savecore: no core dump

Do you have any other ideas?  Thanks.


When you use cu or tip directly on the serial line, do you see any NMEA 
0183 sentences?


- Marc



Re: verifying ntp via GPS configuration?

2007-04-12 Thread James Hartley
On 4/11/07, Marc Balmer [EMAIL PROTECTED] wrote:

 When you use cu or tip directly on the serial line, do you see any NMEA
 0183 sentences?


Thanks to both you Marc  Otto.  Your comments have helped with a number of
questions.  I'm currently questioning the power supplied to the Garmin which
I will get to tomorrow.  For now, I've gone back to my T43 laptop where I
have a USB Delorme GPS LT-20.  I can now see the sensor as well as NMEA
sentences through cu there.

Three questions.

I'm still not seeing anything appear in /var/log/daemon.  How soon should
log messages appear?

From the archives, I remember a statement made that without a pulse per
second (PPS) signal, a GPS unit would only be able to minimally coordinate
the time through ntpd.  This statement was also made in reference to a USB
unit.  Are PPS signals inherent to all GPS units but are lost through an USB
interface?  Is there something within the NMEA sentence traffic which should
tell me that I have a PPS signal?

Thanks again for your clarifications.



Re: verifying ntp via GPS configuration?

2007-04-12 Thread Marc Balmer

James Hartley wrote:

On 4/11/07, Marc Balmer [EMAIL PROTECTED] wrote:


When you use cu or tip directly on the serial line, do you see any NMEA
0183 sentences?



Thanks to both you Marc  Otto.  Your comments have helped with a number of
questions.  I'm currently questioning the power supplied to the Garmin 
which


The Garmin GPS18 LVC needs 5V power supply.  I used a free USB port to 
steal it.



I will get to tomorrow.  For now, I've gone back to my T43 laptop where I
have a USB Delorme GPS LT-20.  I can now see the sensor as well as NMEA
sentences through cu there.

Three questions.

I'm still not seeing anything appear in /var/log/daemon.  How soon should
log messages appear?

 From the archives, I remember a statement made that without a pulse per
second (PPS) signal, a GPS unit would only be able to minimally coordinate
the time through ntpd.  This statement was also made in reference to a USB
unit.  Are PPS signals inherent to all GPS units but are lost through an 
USB
interface?  Is there something within the NMEA sentence traffic which 
should

tell me that I have a PPS signal?


Not all GPS receivers have a PPS signal.  If you use -current, the time 
information is quite precise, even w/o PPS (you will be off by 100-200 
ms).  And no, you will not see in NMEA traffic if there is a PPS signal.


And one last thing:  You need to program you GPS unit to actually issue 
the PPS signal.




Thanks again for your clarifications.



You're welcome, but make sure you read the documentation of your Garmin 
unit.




verifying ntp via GPS configuration?

2007-04-11 Thread James Hartley
I have questionable ntp foo,  searching through the misc@ archives along
with reading the FAQ has only gotten me so far.  I have a Garmin 18 GPS:

http://www.amazon.com/gp/product/B000196BW6/104-8542380-5084714

...which is connected to the serial port of a Sun Ultra 10.  I am unable to
determine whether I'm stylin' or out in the weeds when it comes to
configuring ntp via GPS:

# nmeaattach cua00
# ntpd -ds 
[1] 30616
# ntp engine ready
sensor nmea0 added

...which appears fine as does ps' output:

USER   PID %CPU %MEM   VSZ   RSS TT   STAT STARTED   TIME COMMAND
...
root 16741  0.0  0.0   32080 ??  Is11:50PM0:00.00 nmeaattach
cua00
root 30616  0.0  0.2   536  1240 p0  I 11:50PM0:00.06 ntpd:
[priv] (ntpd)
_ntp 12162  0.0  0.2   536  1136 p0  I 11:50PM0:00.03 ntpd: ntp
engine (ntpd)
...

However, searching for the associated sensor didn't generate any warm 
fuzzies:

# sysctl hw
hw.machine=sparc64
hw.model=SUNW,UltraSPARC-IIi @ 440 MHz, version 0 FPU
hw.ncpu=1
hw.byteorder=4321
hw.physmem=536870912
hw.usermem=536403968
hw.pagesize=8192
hw.disknames=wd0,cd0
hw.diskcount=2
hw.vendor=Sun
hw.product=Ultra 5/10 UPA/PCI
#

...and the only message emitted to stdout/stderr is:

# no reply received in time, skipping initial time setting

Looking at /var/log/daemon only shows:

Apr 10 22:36:42 shockley ntpd[21535]: ntp engine ready
Apr 10 22:36:43 shockley savecore: no core dump

Can anyone help educate an ntp neophyte?

Thanks.



Re: verifying ntp via GPS configuration?

2007-04-11 Thread Otto Moerbeek
On Wed, 11 Apr 2007, James Hartley wrote:

 I have questionable ntp foo,  searching through the misc@ archives along
 with reading the FAQ has only gotten me so far.  I have a Garmin 18 GPS:
 
 http://www.amazon.com/gp/product/B000196BW6/104-8542380-5084714
 
 ...which is connected to the serial port of a Sun Ultra 10.  I am unable to
 determine whether I'm stylin' or out in the weeds when it comes to
 configuring ntp via GPS:
 
 # nmeaattach cua00
 # ntpd -ds 
 [1] 30616
 # ntp engine ready
 sensor nmea0 added

Very likely you Sun uses different serial ports than cua00. Check your
dmesg to see which driver is uses, then use the driver man page to
determine the /dev node to use.

-Otto

 
 ...which appears fine as does ps' output:
 
 USER   PID %CPU %MEM   VSZ   RSS TT   STAT STARTED   TIME COMMAND
 ...
 root 16741  0.0  0.0   32080 ??  Is11:50PM0:00.00 nmeaattach
 cua00
 root 30616  0.0  0.2   536  1240 p0  I 11:50PM0:00.06 ntpd:
 [priv] (ntpd)
 _ntp 12162  0.0  0.2   536  1136 p0  I 11:50PM0:00.03 ntpd: ntp
 engine (ntpd)
 ...
 
 However, searching for the associated sensor didn't generate any warm 
 fuzzies:
 
 # sysctl hw
 hw.machine=sparc64
 hw.model=SUNW,UltraSPARC-IIi @ 440 MHz, version 0 FPU
 hw.ncpu=1
 hw.byteorder=4321
 hw.physmem=536870912
 hw.usermem=536403968
 hw.pagesize=8192
 hw.disknames=wd0,cd0
 hw.diskcount=2
 hw.vendor=Sun
 hw.product=Ultra 5/10 UPA/PCI
 #
 
 ...and the only message emitted to stdout/stderr is:
 
 # no reply received in time, skipping initial time setting
 
 Looking at /var/log/daemon only shows:
 
 Apr 10 22:36:42 shockley ntpd[21535]: ntp engine ready
 Apr 10 22:36:43 shockley savecore: no core dump
 
 Can anyone help educate an ntp neophyte?
 
 Thanks.



Re: verifying ntp via GPS configuration?

2007-04-11 Thread Otto Moerbeek
On Wed, 11 Apr 2007, James Hartley wrote:

 On 4/11/07, Otto Moerbeek [EMAIL PROTECTED] wrote:
  
  Very likely you Sun uses different serial ports than cua00. Check your
  dmesg to see which driver is uses, then use the driver man page to
  determine the /dev node to use.
  
 
 I'm must be blind for I'm not seeing anything.  dmesg below:

sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1

man sab gives: /dev/ttyh[0-1] 

No separate callout device, it looks like.

-Otto

 
 console is keyboard/display
 Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
 Copyright (c) 1995-2006 OpenBSD. All rights reserved.
 http://www.OpenBSD.org
 
 OpenBSD 4.0 (GENERIC) #953: Sun Sep 17 00:56:22 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
 total memory = 536870912
 avail memory = 479698944
 using 3276 buffers containing 26836992 bytes of memory
 bootpath: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0/[EMAIL 
 PROTECTED],0
 mainbus0 (root): Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 440MHz)
 cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 440 MHz, version 0 FPU
 cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 2048K external
 (64 b/l)
 psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
 psycho0: bus range 0-2, PCI bus 0
 psycho0: dvma map c000-dfff, iotdb 26a8000-2728000
 pci0 at psycho0
 ppb0 at pci0 dev 1 function 1 Sun Simba PCI-PCI rev 0x13
 pci1 at ppb0 bus 1
 ebus0 at pci1 dev 1 function 0 Sun PCIO Ebus2 rev 0x01
 auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
 72c000-72c003, 72f000-72f003
 power0 at ebus0 addr 724000-724003 ipl 37
 SUNW,pll at ebus0 addr 504000-504002 not configured
 sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
 sabtty0 at sab0 port 0
 sabtty1 at sab0 port 1
 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41: layout 33
 wskbd0 at comkbd0: console keyboard
 com0 at ebus0 addr 3062f8-3062ff ipl 42: mouse: ns16550a, 16 byte fifo
 lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 70-7f ipl 34:
 polled
 fdthree at ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39
 not configured
 clock1 at ebus0 addr 0-1fff: mk48t59
 flashprom at ebus0 addr 0-f not configured
 audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f,
 722000-722003 ipl 35 ipl 36: nva
 ddrs 0
 audio0 at audioce0
 hme0 at pci1 dev 1 function 1 Sun HME rev 0x01: ivec 0x7e1, address
 08:00:20:c1:66:b7
 nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
 vgafb0 at pci1 dev 2 function 0 ATI Mach64 GP rev 0x5c
 wsdisplay0 at vgafb0: console (std, sun emulation), using wskbd0
 pciide0 at pci1 dev 3 function 0 CMD Technology PCI0646 rev 0x03: DMA,
 channel 0 configured to nat
 ive-PCI, channel 1 configured to native-PCI
 pciide0: using ivec 0x7e0 for native-PCI interrupt
 wd0 at pciide0 channel 0 drive 0: ST3160023A
 wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
 wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
 atapiscsi0 at pciide0 channel 1 drive 0
 scsibus0 at atapiscsi0: 2 targets
 cd0 at scsibus0 targ 0 lun 0: PLEXTOR, DVDR PX-716A, 1.08 SCSI0 5/cdrom
 removable
 cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
 ppb1 at pci0 dev 1 function 0 Sun Simba PCI-PCI rev 0x13
 pci2 at ppb1 bus 2
 ohci0 at pci2 dev 1 function 0 NEC USB rev 0x43: ivec 0x7d0, version 1.0
 usb0 at ohci0: USB revision 1.0
 uhub0 at usb0
 uhub0: NEC OHCI root hub, rev 1.00/1.00, addr 1
 uhub0: 3 ports with 3 removable, self powered
 ohci1 at pci2 dev 1 function 1 NEC USB rev 0x43: ivec 0x7d1, version 1.0
 usb1 at ohci1: USB revision 1.0
 uhub1 at usb1
 uhub1: NEC OHCI root hub, rev 1.00/1.00, addr 1
 uhub1: 2 ports with 2 removable, self powered
 ehci0 at pci2 dev 1 function 2 NEC USB rev 0x04: ivec 0x7d2
 usb2 at ehci0: USB revision 2.0
 uhub2 at usb2
 uhub2: NEC EHCI root hub, rev 2.00/1.00, addr 1
 uhub2: 5 ports with 5 removable, self powered
 pcons at mainbus0 not configured
 No counter-timer -- using %tick at 440MHz as system clock.
 root on wd0a
 rootdev=0xc00 rrootdev=0x1a00 rawdev=0x1a02
 syncing disks...



Re: verifying ntp via GPS configuration?

2007-04-11 Thread James Hartley
On 4/11/07, Otto Moerbeek [EMAIL PROTECTED] wrote:

 Very likely you Sun uses different serial ports than cua00. Check your
 dmesg to see which driver is uses, then use the driver man page to
 determine the /dev node to use.


I'm must be blind for I'm not seeing anything.  dmesg below:

console is keyboard/display
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 4.0 (GENERIC) #953: Sun Sep 17 00:56:22 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 536870912
avail memory = 479698944
using 3276 buffers containing 26836992 bytes of memory
bootpath: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0/[EMAIL 
PROTECTED],0
mainbus0 (root): Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 440MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 440 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 2048K external
(64 b/l)
psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
psycho0: bus range 0-2, PCI bus 0
psycho0: dvma map c000-dfff, iotdb 26a8000-2728000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 Sun Simba PCI-PCI rev 0x13
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 Sun PCIO Ebus2 rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003
power0 at ebus0 addr 724000-724003 ipl 37
SUNW,pll at ebus0 addr 504000-504002 not configured
sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1
comkbd0 at ebus0 addr 3083f8-3083ff ipl 41: layout 33
wskbd0 at comkbd0: console keyboard
com0 at ebus0 addr 3062f8-3062ff ipl 42: mouse: ns16550a, 16 byte fifo
lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 70-7f ipl 34:
polled
fdthree at ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39
not configured
clock1 at ebus0 addr 0-1fff: mk48t59
flashprom at ebus0 addr 0-f not configured
audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f,
722000-722003 ipl 35 ipl 36: nva
ddrs 0
audio0 at audioce0
hme0 at pci1 dev 1 function 1 Sun HME rev 0x01: ivec 0x7e1, address
08:00:20:c1:66:b7
nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
vgafb0 at pci1 dev 2 function 0 ATI Mach64 GP rev 0x5c
wsdisplay0 at vgafb0: console (std, sun emulation), using wskbd0
pciide0 at pci1 dev 3 function 0 CMD Technology PCI0646 rev 0x03: DMA,
channel 0 configured to nat
ive-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7e0 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: ST3160023A
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: PLEXTOR, DVDR PX-716A, 1.08 SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
ppb1 at pci0 dev 1 function 0 Sun Simba PCI-PCI rev 0x13
pci2 at ppb1 bus 2
ohci0 at pci2 dev 1 function 0 NEC USB rev 0x43: ivec 0x7d0, version 1.0
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci2 dev 1 function 1 NEC USB rev 0x43: ivec 0x7d1, version 1.0
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0 at pci2 dev 1 function 2 NEC USB rev 0x04: ivec 0x7d2
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: NEC EHCI root hub, rev 2.00/1.00, addr 1
uhub2: 5 ports with 5 removable, self powered
pcons at mainbus0 not configured
No counter-timer -- using %tick at 440MHz as system clock.
root on wd0a
rootdev=0xc00 rrootdev=0x1a00 rawdev=0x1a02
syncing disks...



Re: verifying ntp via GPS configuration?

2007-04-11 Thread James Hartley
On 4/11/07, Otto Moerbeek [EMAIL PROTECTED] wrote:

 sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
 sabtty0 at sab0 port 0
 sabtty1 at sab0 port 1

 man sab gives: /dev/ttyh[0-1]

 No separate callout device, it looks like.


Thanks for getting back to me.  Specifying /dev/ttyh0 (or /dev/ttyh1) gives
the same results.  I still don't see any sensor when issuing:

# sysctl hw

...nor is anything showing up in /var/log/daemon except for the following
message:

Apr 11 19:16:43 shockley savecore: no core dump

Do you have any other ideas?  Thanks.



Re: verifying ntp via GPS configuration?

2007-04-11 Thread Otto Moerbeek
On Wed, 11 Apr 2007, James Hartley wrote:

 On 4/11/07, Otto Moerbeek [EMAIL PROTECTED] wrote:
  
  sab0 at ebus0 addr 40-40007f ipl 43: rev 3.2
  sabtty0 at sab0 port 0
  sabtty1 at sab0 port 1
  
  man sab gives: /dev/ttyh[0-1]
  
  No separate callout device, it looks like.
 
 
 Thanks for getting back to me.  Specifying /dev/ttyh0 (or /dev/ttyh1) gives
 the same results.  I still don't see any sensor when issuing:
 
 # sysctl hw
 
 ...nor is anything showing up in /var/log/daemon except for the following
 message:
 
 Apr 11 19:16:43 shockley savecore: no core dump
 
 Do you have any other ideas?  Thanks.

With cu -l /dev/ttyh? -s 4800 you should be able to see the output of
the GPS. If that doesn't happen, check your cabling and the settings
of your GPS. Until you see NMEA output lines, nmeaattach won't work either.

-Otto