Re: [time-nuts] GPIB on HP5382B counter
I'm out of practice with C, but shouldn't viScanf(vi, %t, buf); be viScanf(vi, %t, buf); [I'm not a language wizard.] It looks OK to me. Arrays are passed by pointer. buf is the same as buf[0] The compiler should complain if it is wrong. A quick google found examples without the . For production code I'd want to tell viScanf the max length. -- These are my opinions, not necessarily my employer's. 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] GPIB on HP5382B counter
Hal Murray wrote: I'm out of practice with C, but shouldn't viScanf(vi, %t, buf); be viScanf(vi, %t, buf); [I'm not a language wizard.] It looks OK to me. Arrays are passed by pointer. buf is the same as buf[0] The compiler should complain if it is wrong. A quick google found examples without the . Indeed: http://zone.ni.com/devzone/cda/tut/p/id/4727 Cheers, Magnus ___ 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] CF-28 Laptop GPS Driver?
I think SiSoft Sandra will tell you the device id (assuming its PCI or more recent), and then you should be able to search for the device ID to find the drivers. I assume you've already tried the Panasonic Web Site for drivers? Dave -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of bro...@pacific.net Sent: 24 October 2009 06:07 To: time-nuts@febo.com Subject: [time-nuts] CF-28 Laptop GPS Driver? Hi: I've got a well used Panasonic CF-28S (Mk 3) Toughbook laptop computer that has an embedded GPS receiver but it came with the commercial version of WIN XP Pro. http://www.prc68.com/I/CF28Toughbook.shtml Is there a driver for this GPS receiver that's marked: Ref No. CN-GX0100A, s/n: 10128, Label: YEFM011059 ? Have Fun, Brooke Clarke ___ 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] GPIB on HP5382B counter
If buf is defined as an array (eg. char buf[100];) its name is a constant that points to the start of the array. You can write it either as buf, or buf. -Chuck Harris Brent Gordon wrote: I'm out of practice with C, but shouldn't viScanf(vi, %t, buf); be viScanf(vi, %t, buf); Brent ___ 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] LPRO101 Lamp Exciter Frequency
Date: Sat, 24 Oct 2009 09:35:03 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] LPRO101 Lamp Exciter Frequency To: Discussion of precise time and frequency measurement time-nuts@febo.com Message-ID: 4ae21377.7070...@xtra.co.nz Content-Type: text/plain; charset=ISO-8859-1 Roberto Barrios wrote: Hi all, I've got an LPRO101 that refuses to lock and you sure will be of great help. These devices are quite cheap but I'm trying to learn in the repair process. I've followed PE1FBO's repair guide and everything noted there seems ok. I could not find a single suspect component. These are some notes I've taken on the unit after a 20 minutes warmup: - Power input current during warmup is 1.2A and 0.4A after it. - 10Mhz out swings between 10.000191 and 9.999875, taking 40s to go up and 60s to go down in freq. - Lamp voltage is a steady 6.7V. - The lamp glows a few seconds after powering the unit. Placing a pickup look over the PCB, the analyzer shows peaks all over the place up to 2.5Ghz (it's limit), so the thing is alive. There is one unexpected thing I found... The frequency of the RF power going into the lamp is 157.3Mhz, very stable. From the repair guide, it should be 70Mhz. I checked it with everything on hand (scope, counter, spec. analyzer) and there is no doubt about it. A clean sine of about 16V peak to peak, at 157.3Mhz can be found at the output (source) of the BF160 MOSFET. Could this unexpectedly high exciter frequency cause the inability to lock or should I look somewhere else? The deviation from the expected 70Mhz seems too big to me, but should I tweak the oscillator tuning capacitor (C901) to try to lower the frequency? The oscillator is a Clapp oscillator and the (0.6-4.5pF) series tuning cap has a large influence on the frequency. Unless the coil has shorted turns or another component has gone open circuit its seems likely that the oscillator has been mistuned. Thank you all, Roberto EB4EQA Bruce Hi Bruce, Thank you for taking the time to look at this and answer my message. Thank you for pointing to the oscillator type, thanks to that, I've made some calculations. I've measured the inductace of the coil and it turns out to be 460nH. Given the capacitor values, doing the math, the oscillator is tunable from about 129Mhz to 310Mhz by adjusting capacitor C901. I've found that there is about 157pF where the 82pF capacitor is, but that has very little effect on tuning range. I've tried adjusting C901 and the lower I can get is 125Mhz, as expected. Could the correct frequency be in that range, and not 70Mhz If you confirm it should be 70Mhz, I'll add some capacitance to 901 to get the oscillator down again to 70Mhz. About 90pF should do. Could this actually be the problem in the unit (the lamp glows...) Thank you best regards, Roberto, EB4EQA _ ___ 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] GPIB on HP5382B counter
If buf is defined as an array (eg. char buf[100];) its name is a constant that points to the start of the array. You can write it either as buf, or buf. Not quite. You need buf[0] buf is a pointer to the array. (first element) buf is a pointer to that pointer. buf[0] is a pointer to the first element of the array. -- These are my opinions, not necessarily my employer's. 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] LPRO101 Lamp Exciter Frequency
I think you are reading the second harmonic. I would recall that: - the LPRO loses lock if the lamp gets too hot. This is indicated by a color more close to red than to pink (which is normal). This could happen if the temperature control circuit has some fault. I would suggest cheching the voltage at the base of Q703: it should drop to about 5V from the initial 11V after warm-up. If the voltage remains around 11, then R721 61.9K (bottom of PCB) could be interrupted. Onboard it should read 14K if good, 18K if broken. - the lamp could glow even if the lamp assy is cold, and the LPRO doesn't lock. This is easily checked touching the lamp assembly after one minute of power-on, you should burn your finger. If you don't burn your finger, then check the heating circuit, particularily the small 100K resistors on the bottom pcb near the lamp assy. Be aware: once again I would remind that the LPRO doesn't lock if the cover is off and there is some light coming from an incandescent light or any light that has ripples or pulses. Antonio I8IOV Date: Sat, 24 Oct 2009 09:35:03 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] LPRO101 Lamp Exciter Frequency To: Discussion of precise time and frequency measurement time-nuts@febo.com Message-ID: 4ae21377.7070...@xtra.co.nz Content-Type: text/plain; charset=ISO-8859-1 Roberto Barrios wrote: Hi all, I've got an LPRO101 that refuses to lock and you sure will be of great help. These devices are quite cheap but I'm trying to learn in the repair process. I've followed PE1FBO's repair guide and everything noted there seems ok. I could not find a single suspect component. These are some notes I've taken on the unit after a 20 minutes warmup: - Power input current during warmup is 1.2A and 0.4A after it. - 10Mhz out swings between 10.000191 and 9.999875, taking 40s to go up and 60s to go down in freq. - Lamp voltage is a steady 6.7V. - The lamp glows a few seconds after powering the unit. Placing a pickup look over the PCB, the analyzer shows peaks all over the place up to 2.5Ghz (it's limit), so the thing is alive. There is one unexpected thing I found... The frequency of the RF power going into the lamp is 157.3Mhz, very stable. From the repair guide, it should be 70Mhz. I checked it with everything on hand (scope, counter, spec. analyzer) and there is no doubt about it. A clean sine of about 16V peak to peak, at 157.3Mhz can be found at the output (source) of the BF160 MOSFET. Could this unexpectedly high exciter frequency cause the inability to lock or should I look somewhere else? The deviation from the expected 70Mhz seems too big to me, but should I tweak the oscillator tuning capacitor (C901) to try to lower the frequency? The oscillator is a Clapp oscillator and the (0.6-4.5pF) series tuning cap has a large influence on the frequency. Unless the coil has shorted turns or another component has gone open circuit its seems likely that the oscillator has been mistuned. Thank you all, Roberto EB4EQA Bruce Hi Bruce, Thank you for taking the time to look at this and answer my message. Thank you for pointing to the oscillator type, thanks to that, I've made some calculations. I've measured the inductace of the coil and it turns out to be 460nH. Given the capacitor values, doing the math, the oscillator is tunable from about 129Mhz to 310Mhz by adjusting capacitor C901. I've found that there is about 157pF where the 82pF capacitor is, but that has very little effect on tuning range. I've tried adjusting C901 and the lower I can get is 125Mhz, as expected. Could the correct frequency be in that range, and not 70Mhz If you confirm it should be 70Mhz, I'll add some capacitance to 901 to get the oscillator down again to 70Mhz. About 90pF should do. Could this actually be the problem in the unit (the lamp glows...) Thank you best regards, Roberto, EB4EQA _ ___ 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] GPIB on HP5382B counter
Not quite. You need buf[0]
buf is a pointer to the array. (first element)
buf is a pointer to that pointer.
buf[0] is a pointer to the first element of the array.
Hal, try the following with your C compiler...
#include stdio.h
void main ()
{
char buf[100] = { 3,1,4,1,5 };
printf(0x%.8lX\n, buf);
printf(0x%.8lX\n, buf);
printf(0x%.8lX\n, buf[0]);
printf(0x%.8lX\n, buf[0]);
}
And see if your results and intuition agree.
0x0012FF1C
0x0012FF1C
0x0003
0x0012FF1C
/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] GPIB on HP5382B counter
Hal Murray wrote:
If buf is defined as an array (eg. char buf[100];) its name is a
constant that points to the start of the array. You can write it
either as buf, or buf.
Not quite. You need buf[0]
buf is a pointer to the array. (first element)
buf is a pointer to that pointer.
buf[0] is a pointer to the first element of the array.
Not quite.
Piece of example code:
#include stdio.h
int main()
{
int buf[100];
printf(%p %p %p\n, buf, buf, buf[0]);
return 0;
}
Prints
0xbf933224 0xbf933224 0xbf933224
So they are the same in this context. That's how it works. I could
detail it in booring details if needed.
Cheers,
Magnus
___
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] GPIB on HP5382B counter
At 04:46 PM 10/24/2009, Tom Van Baak wrote... Not quite. You need buf[0] buf is a pointer to the array. (first element) buf is a pointer to that pointer. buf[0] is a pointer to the first element of the array. Hal, try the following with your C compiler... BASIC is _so_ much easier. :-) ___ 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] LPRO101 Lamp Exciter Frequency
Roberto Barrios wrote: Date: Sat, 24 Oct 2009 09:35:03 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] LPRO101 Lamp Exciter Frequency To: Discussion of precise time and frequency measurement time-nuts@febo.com Message-ID: 4ae21377.7070...@xtra.co.nz Content-Type: text/plain; charset=ISO-8859-1 Roberto Barrios wrote: Hi all, I've got an LPRO101 that refuses to lock and you sure will be of great help. These devices are quite cheap but I'm trying to learn in the repair process. I've followed PE1FBO's repair guide and everything noted there seems ok. I could not find a single suspect component. These are some notes I've taken on the unit after a 20 minutes warmup: - Power input current during warmup is 1.2A and 0.4A after it. - 10Mhz out swings between 10.000191 and 9.999875, taking 40s to go up and 60s to go down in freq. - Lamp voltage is a steady 6.7V. - The lamp glows a few seconds after powering the unit. Placing a pickup look over the PCB, the analyzer shows peaks all over the place up to 2.5Ghz (it's limit), so the thing is alive. There is one unexpected thing I found... The frequency of the RF power going into the lamp is 157.3Mhz, very stable. From the repair guide, it should be 70Mhz. I checked it with everything on hand (scope, counter, spec. analyzer) and there is no doubt about it. A clean sine of about 16V peak to peak, at 157.3Mhz can be found at the output (source) of the BF160 MOSFET. Could this unexpectedly high exciter frequency cause the inability to lock or should I look somewhere else? The deviation from the expected 70Mhz seems too big to me, but should I tweak the oscillator tuning capacitor (C901) to try to lower the frequency? The oscillator is a Clapp oscillator and the (0.6-4.5pF) series tuning cap has a large influence on the frequency. Unless the coil has shorted turns or another component has gone open circuit its seems likely that the oscillator has been mistuned. Thank you all, Roberto EB4EQA Bruce Hi Bruce, Thank you for taking the time to look at this and answer my message. Thank you for pointing to the oscillator type, thanks to that, I've made some calculations. I've measured the inductace of the coil and it turns out to be 460nH. Given the capacitor values, doing the math, the oscillator is tunable from about 129Mhz to 310Mhz by adjusting capacitor C901. I've found that there is about 157pF where the 82pF capacitor is, but that has very little effect on tuning range. I've tried adjusting C901 and the lower I can get is 125Mhz, as expected. Could the correct frequency be in that range, and not 70Mhz If you confirm it should be 70Mhz, I'll add some capacitance to 901 to get the oscillator down again to 70Mhz. About 90pF should do. Could this actually be the problem in the unit (the lamp glows...) Thank you best regards, Roberto, EB4EQA Roberto Your lamp exciter differs from the one attached. Unless a fixed capacitor is faulty you shouldn't need to change it. In principle it doesn't matter too much what the lamp excitation frequency is as long as the coupling coil is suitably proportioned. If the oscillator operates at a frequency other than the design value the coupling to the lamp may be reduced. It would appear that the design frequency differs from that in the repair manual (unless the coil is faulty). The fact that the 10MHz oscillator frequency ramps up and down suggests that there is something wrong with the frequency lock circuit. Try looking at the photocell signal processing chain. Is the microwave signal actually being modulated? Bruce inline: RblampExciter3.png___ 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] GPIB on HP5382B counter
t...@leapsecond.com said: Hal, try the following with your C compiler... ... mag...@rubidium.dyndns.org said: Not quite. ... Argh/blush. Sigh. Thanks for the correction, and apologies for cluttering up the list with bogus info. I fished out my old copy of Andrew Koenig's C Traps and Pitfalls. Chapter 2 starts with Pointers and Arrays. It's Copyrighted 1989. Does anybody know of a other books that cover similar material? It's a very good book and I like the style. I'm just looking for additional info, a second opinion/viewpoint. Sometimes saying the same thing in a different way will click. -- These are my opinions, not necessarily my employer's. 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] GPS from a window seat
Group, Completed circumnavigation of the world via Singapore with a hand-held Garmin 60 CSx GPS receiver. Set it to record at 6 minute intervals, and marked waypoints. Used about 6% of track space with 4 GB micro SD card. Had no trouble with aircraft interference. Talked to the Captain after a 4 hour flight from MSP to LAX. He said he had no problems, and thinks GPS receivers are quite safe. He worries about active transmitters, like cell phones and wireless laptops. Had no trouble getting a lock at altitude and speed. Didn't have a window seat in the A380 from Singapore to London. About 2/3 of the way through, over the Ukraine, I found a window I could stand by. Took about 2 minutes to lock. Last lock was in Singapore. Had no trouble with getting 20 foot accuracy with the receiver in a jacket pocket near the window. Can get 10 foot accuracy when stationary. Could go to 40 feet in some satellite configurations. Close enough for recording a trip. There was some discussion of hand held devices being crippled for aviation, so that aviation units could be sold for more money. The 60 CSx will not display GPS altitude. It only uses a barometric sensor, which gives you cabin pressure. OTOH, the compass display uses GPS if you are moving, and magnetic when you are standing still. No problem for a map of the course. Cabin pressure will tell you when you have landed or leaped into the sky. Very impressed with the performance of the receiver and antenna in that device. Newer units don't have an antenna stub, so they may not have the response of the 60 CSx. Also useful for setting your watch. But you can get several inexpensive watches and preset them for the cities that you will visit. As you are landing, change to another watch. Saw an oil executive do that in the Concorde in '83, with expensive watches. That was my experience. YMMV. Bill Hawkins ___ 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] LPRO101 Lamp Exciter Frequency
Roberto Barrios wrote: Date: Sun, 25 Oct 2009 10:24:38 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] LPRO101 Lamp Exciter Frequency To: Discussion of precise time and frequency measurement Message-ID: 4ae37096.5030...@xtra.co.nz Content-Type: text/plain; charset=iso-8859-1 Roberto Barrios wrote: Date: Sat, 24 Oct 2009 09:35:03 +1300 From: Bruce Griffiths bruce.griffi...@xtra.co.nz Subject: Re: [time-nuts] LPRO101 Lamp Exciter Frequency To: Discussion of precise time and frequency measurement time-nuts@febo.com Message-ID: 4ae21377.7070...@xtra.co.nz Content-Type: text/plain; charset=ISO-8859-1 Roberto Barrios wrote: Hi all, I've got an LPRO101 that refuses to lock and you sure will be of great help. These devices are quite cheap but I'm trying to learn in the repair process. I've followed PE1FBO's repair guide and everything noted there seems ok. I could not find a single suspect component. These are some notes I've taken on the unit after a 20 minutes warmup: - Power input current during warmup is 1.2A and 0.4A after it. - 10Mhz out swings between 10.000191 and 9.999875, taking 40s to go up and 60s to go down in freq. - Lamp voltage is a steady 6.7V. - The lamp glows a few seconds after powering the unit. Placing a pickup look over the PCB, the analyzer shows peaks all over the place up to 2.5Ghz (it's limit), so the thing is alive. There is one unexpected thing I found... The frequency of the RF power going into the lamp is 157.3Mhz, very stable. From the repair guide, it should be 70Mhz. I checked it with everything on hand (scope, counter, spec. analyzer) and there is no doubt about it. A clean sine of about 16V peak to peak, at 157.3Mhz can be found at the output (source) of the BF160 MOSFET. Could this unexpectedly high exciter frequency cause the inability to lock or should I look somewhere else? The deviation from the expected 70Mhz seems too big to me, but should I tweak the oscillator tuning capacitor (C901) to try to lower the frequency? The oscillator is a Clapp oscillator and the (0.6-4.5pF) series tuning cap has a large influence on the frequency. Unless the coil has shorted turns or another component has gone open circuit its seems likely that the oscillator has been mistuned. Thank you all, Roberto EB4EQA Bruce Hi Bruce, Thank you for taking the time to look at this and answer my message. Thank you for pointing to the oscillator type, thanks to that, I've made some calculations. I've measured the inductace of the coil and it turns out to be 460nH. Given the capacitor values, doing the math, the oscillator is tunable from about 129Mhz to 310Mhz by adjusting capacitor C901. I've found that there is about 157pF where the 82pF capacitor is, but that has very little effect on tuning range. I've tried adjusting C901 and the lower I can get is 125Mhz, as expected. Could the correct frequency be in that range, and not 70Mhz If you confirm it should be 70Mhz, I'll add some capacitance to 901 to get the oscillator down again to 70Mhz. About 90pF should do. Could this actually be the problem in the unit (the lamp glows...) Thank you best regards, Roberto, EB4EQA Roberto Your lamp exciter differs from the one attached. Unless a fixed capacitor is faulty you shouldn't need to change it. In principle it doesn't matter too much what the lamp excitation frequency is as long as the coupling coil is suitably proportioned. If the oscillator operates at a frequency other than the design value the coupling to the lamp may be reduced. It would appear that the design frequency differs from that in the repair manual (unless the coil is faulty). The fact that the 10MHz oscillator frequency ramps up and down suggests that there is something wrong with the frequency lock circuit. Try looking at the photocell signal processing chain. Is the microwave signal actually being modulated? Bruce -- next part -- A non-text attachment was scrubbed... Name: RblampExciter3.png Type: image/png Size: 22923 bytes Desc: not available URL: http://www.febo.com/pipermail/time-nuts/attachments/20091025/982d5b41/attachment.png Roberto Hi Bruce, Antonio, Bruce, you are right, there should be no need to modify the original design. The attached schematic is the one I have printed and it faithfully represents the actual circuit in the LPRO I have. C14 is actually 82pF (I took it out to measure it), but capacitance from E3 to ground is 157pF. The added capacitance must come from the line going to R13. I can keep unsoldering components until I uncover where that added capacitance comes from but looking at the Clapp oscillator formula, it should'n make a big difference in the oscillating frequency. How did you measure
[time-nuts] OpenBSD / ntpd / gpsd / PPS problems
I'm trying to construct a stratum-1 NTP server, using a Garmin 18x LVC GPS unit (with the PPS line wired to the serial port's carrier pin), running on an OpenBSD system (current release, 4.6). It's not working for me (yet), and I could use some advice from anyone who has actually managed to get this running. I've read that the PPS signal can be handled in a stock OpenBSD 4.6 system, using gpsd to process and merge the NMEA and PPS data, and interfacing the gpsd output to ntpd (the official implementation from ntp.org -- *not* the OpenBSD project's own OpenNTPD) via shared memory. (See http://linux.die.net/man/8/gpsd for an example of this claim.) First, I installed and configured the latest ntpd (version 4.2.5p236 release candidate). I then installed gpsd 2.38 (the OpenBSD package). The GPS was detected (based on output from cgps), but ntpd didn't see any data from either of the two shared-memory segments. I removed OpenBSD's gpsd package and built/installed gpsd 2.39 from sources. The GPS was detected, and this time, the raw NMEA time stamps was seen by ntpd (in the first of the two shared-memory segments). But the PPS-corrected data (second shared-memory segment) was still nowhere to be seen. Despite the claim (see above) that gpsd uses OpenBSD's NMEA line discipline to export PPS time stamps, I can't find any substantiation for this in the gpsd source code. I tried enabling the NMEA line discipline manually on the GPS's serial port (via the ldattach command), but this made gpsd totally unable to read anything from the GPS at all. I know the PPS signal itself is working because I've successfully tested this setup using FreeBSD 7.2 (custom kernel with PPS_SYNC compiled in). The main reason why I want to get an OpenBSD-based system to work is that OpenBSD is allegedly able to handle the PPS signal without needing to build a custom kernel (as would be required for FreeBSD or Linux). Any suggestions welcome. Rich Wales / ri...@richw.org ___ 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] OpenBSD / ntpd / gpsd / PPS problems
On Sat, Oct 24, 2009 at 8:52 PM, Rich Wales ri...@richw.org wrote: Despite the claim (see above) that gpsd uses OpenBSD's NMEA line discipline to export PPS time stamps, I can't find any substantiation for this in the gpsd source code. I tried enabling the NMEA line discipline manually on the GPS's serial port (via the ldattach command), but this made gpsd totally unable to read anything from the GPS at all. I removed the special-casing that would cause gpsd to activate the nmea(4) line discipline. The way I'm now doing this is to get ldattach to relay through a pty, and gpsd can read that pty. you can do something like this in /etc/rc.local: gpsd -n $(ldattach -t dcd nmea cua01) CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ 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] OpenBSD / ntpd / gpsd / PPS problems
Chris Kuethe wrote: I removed the special-casing that would cause gpsd to activate the nmea(4) line discipline. The way I'm now doing this is to get ldattach to relay through a pty, and gpsd can read that pty. you can do something like this in /etc/rc.local: gpsd -n $(ldattach -t dcd nmea cua01) I assume you also used the -p flag to ldattach, right? I tried the following: gpsd -n `ldattach -p -s 19200 -t dcd nmea /dev/tty00` (my GPS is on /dev/tty00) -- but about one second after ldattach did its setup, it died with the following error in the logs: eof during read from device: Undefined error: 0 and cgps never shows any data from the GPS. Rich Wales ri...@richw.org ___ 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] OpenBSD / ntpd / gpsd / PPS problems
Hmf. Try this patch to ldattach
Index: ldattach.c
===
RCS file: /cvs/src/sbin/ldattach/ldattach.c,v
retrieving revision 1.12
diff -N -u -p ldattach.c
--- ldattach.c 6 May 2009 18:21:23 - 1.12
+++ ldattach.c 25 Oct 2009 04:40:56 -
@@ -99,9 +99,12 @@ relay(int device, int pty)
exit(1);
}
if (nread == 0) {
+#if 0
syslog(LOG_ERR, eof during read from %s: %m,
n ? pty : device);
exit(1);
+#endif
+ usleep(1);
}
atomicio(vwrite, pfd[1 - n].fd, buf, nread);
}
On Sat, Oct 24, 2009 at 9:34 PM, Rich Wales ri...@richw.org wrote:
Chris Kuethe wrote:
I removed the special-casing that would cause gpsd to activate the nmea(4)
line discipline. The way I'm now doing this is to get ldattach to relay
through a pty, and gpsd can read that pty. you can do something like this
in /etc/rc.local: gpsd -n $(ldattach -t dcd nmea cua01)
I assume you also used the -p flag to ldattach, right?
I tried the following:
gpsd -n `ldattach -p -s 19200 -t dcd nmea /dev/tty00`
(my GPS is on /dev/tty00)
-- but about one second after ldattach did its setup, it died with the
following error in the logs:
eof during read from device: Undefined error: 0
and cgps never shows any data from the GPS.
Rich Wales
ri...@richw.org
___
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.
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
___
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] OpenBSD / ntpd / gpsd / PPS problems
Despite the claim (see above) that gpsd uses OpenBSD's NMEA line discipline to export PPS time stamps, I can't find any substantiation for this in the gpsd source code. I tried enabling the NMEA line discipline manually on the GPS's serial port (via the ldattach command), but this made gpsd totally unable to read anything from the GPS at all. I'm not sure what line discipline means. I think what gpsd is doing is just watching the carrier line and grabbing the time when it changes. I took a quick look at some old source code, and I see things like this: if defined(PPS_ENABLE) defined(TIOCMIWAIT) (There might be other code that uses the kernel time-stamping stuff, but I didn't see it.) If that's the case, then there is nothing special about OpenBSD. You might have an easier time getting things going on an OS that you are more familiar with. -- These are my opinions, not necessarily my employer's. 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.
