Intel D2500cc(e) serial ports disfunctional?
-
When using the type 20 generic NMEA GPS driver in ntpd, yes, the pseudo-IP is related to the serial port: 127.127.20.u is the pseudo-IP, where u indicates which serial port is going to that GPS. Specifically, the u should be the same as the links you've created for /dev/gps_u_ and /dev/gpspps_u_ (see below).
I thought I'd seen that somewhere…
Can you post your /var/conf/ntpd.conf? There are lots of other things to be configured for that driver too (baud rate, enable PPS, select kernel PPS processing, set REFID etc); see here for details:
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.htmlI have that page open in another tab… :)
The pfSense code that creates the "/var/conf/ntpd.conf" seems to not have any issues, aside from possibly the assumed 0.155 value for fudge time1. In pfSense this file is actually located at /var/etc/ntpd.conf.
The current GPS related contents of that are:
tinker panic 0 # GPS Setup server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 time1 -0.2 time2 0.000 flag1 1 flag2 0 flag3 1 server 127.127.1.0 fudge 127.127.1.0 stratum 12I've been playing with fudge time1, the default is 0.155. Also this file is created by php code in /etc/inc/system.inc, so if you want changes to stick across reboots or a GUI change, edits have to be made there.
A few other suggestions (sorry if they are quite obvious already, they weren't to me):
Most were, but thanks for the reminders. I did already config the GPS to only send $GPMRC and $GPGGA sentences, lock it to 4800 baud and disabled the possible binary mode at power up. I did all that when I was trying to figure out why pfSense wasn't seeing the GPS.
- Great references for ntpd on FreeBSD:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
http://blog.doylenet.net/?p=145
Two more good references I have been using!
Yesterday I set fudge time1 to 0.0 and after many hours the result was:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== xGPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 -1000.0 0.002 LOCAL(0) .LOCL. 12 l 8h 64 0 0.000 0.000 0.000 +aquila.init7.ne 73.121.249.250 2 u 61 512 377 98.537 0.396 0.544 -b1-66er.matrix. 29.92.24.129 2 u 56 512 377 17.656 -6.042 1.196 -colossus915.ser 200.23.51.102 2 u 41 512 377 35.210 -1.291 0.427 *bodhielfman.khr 127.67.113.92 2 u 75 512 377 82.611 -0.264 0.472 +name3.glorb.com 69.25.96.13 2 u 266 512 377 86.239 0.346 0.579After much experimenting with fudge time1, the best I have seen is a setting of -0.2:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 3 16 17 0.000 -292.70 14.999 LOCAL(0) .LOCL. 12 l 66 64 2 0.000 0.000 0.002 +ntp1.Housing.Be 128.32.206.55 3 u 55 64 1 86.637 -114.93 2.824 -vcxen01.bw.phl. 66.225.61.67 3 u 54 64 1 14.099 -110.71 1.423 ns.ii1.net 128.233.150.93 2 u 53 64 1 113.823 14.860 7.927 +isaachayes.khre 204.123.2.72 2 u 52 64 1 84.021 -114.11 2.265 *167.80.55.66.ho 164.244.221.197 2 u 51 64 1 33.637 -114.87 3.645Note that there is a lowercase "o" in front of the GPS, so it seems PPS is working.
after a few hours that became:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== xGPS_NMEA(0) .GPS. 0 l 14 16 377 0.000 -200.00 0.002 LOCAL(0) .LOCL. 12 l 60m 64 0 0.000 0.000 0.000 +ntp1.Housing.Be 128.32.206.55 3 u 49 64 377 86.843 -1.506 1.314 -vcxen01.bw.phl. 66.225.61.67 3 u 59 64 377 14.587 1.191 0.860 ns.ii1.net 128.233.150.93 2 u 50 64 377 114.169 103.688 6.989 *isaachayes.khre 204.123.2.72 2 u 67 64 377 84.354 -1.870 0.796 +167.80.55.66.ho 69.25.96.13 2 u 41 64 377 34.130 -0.618 3.337What I don't understand is that fudge time1 -0.1 resulted in:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== xGPS_NMEA(0) .GPS. 0 l 15 16 1 0.000 10.204 0.002 LOCAL(0) .LOCL. 12 l 26 64 1 0.000 0.000 0.002 +ntp1.exa-networ 195.66.241.10 2 u 20 64 1 89.871 636.452 0.204 *fairy.mattnordh 200.98.196.212 2 u 17 64 1 32.094 636.389 1.331 -host2.kingrst.c 199.102.46.73 2 u 19 64 1 40.172 642.940 0.247 +time.gac.edu 147.84.59.145 2 u 17 64 1 43.270 635.315 0.136 -nbg1.shellvator 209.51.161.238 2 u 15 64 1 19.134 641.743 1.315While fudge time -0.3 resulted in:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *GPS_NMEA(0) .GPS. 0 l 2 16 3 0.000 0.018 0.002 LOCAL(0) .LOCL. 12 l 35 64 1 0.000 0.000 0.002 +mail.pionica.co 212.244.36.228 2 u 18 64 1 135.205 302.198 2.113 +a1.hotfile.com 128.4.1.1 2 u 18 64 1 50.687 299.653 1.315 +host2.kingrst.c 199.102.46.73 2 u 21 64 1 40.260 306.974 0.108 +propjet.latt.ne 204.2.134.162 3 u 18 64 1 81.650 313.278 1.272 +irc.indoforum.o 64.147.116.229 2 u 18 64 1 84.536 312.854 1.560For now I'm gonna leave it at -0.2 for awhile and see how it looks after a few hours.
- Great references for ntpd on FreeBSD:
-
I've been playing with fudge time1, the default is 0.155. Also this file is created by php code in /etc/inc/system.inc, so if you want changes to stick across reboots or a GUI change, edits have to be made there.
No! AFAIK, fudge time1 is for a known deviation of the PPS time stamp from true UTC. Remove that, and take the default of 0.0 for time1. The PPS signal is accurate to something like 10 microseconds on most GPS units, and even better on timing units.
fudge time2 is used to compensate for a known deviation of serial port NMEA sentence from true UTC. This is the one to adjust, say to adjust to fast or slow baud rates, where the sentence is in the string transmitted 1/sec, etc. But use it only if you need to.
See https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks , esp the GPS 18x LVC section, for details on this, and even a method to measure what your fudge time2 should be if you need it.
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
-
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
Took my own advice and started a thread to cover this and some other things I found looking through /etc/inc/system.inc: http://forum.pfsense.org/index.php/topic,67189.0.html
-
I've been playing with fudge time1, the default is 0.155. Also this file is created by php code in /etc/inc/system.inc, so if you want changes to stick across reboots or a GUI change, edits have to be made there.
No! AFAIK, fudge time1 is for a known deviation of the PPS time stamp from true UTC. Remove that, and take the default of 0.0 for time1. The PPS signal is accurate to something like 10 microseconds on most GPS units, and even better on timing units.
fudge time2 is used to compensate for a known deviation of serial port NMEA sentence from true UTC. This is the one to adjust, say to adjust to fast or slow baud rates, where the sentence is in the string transmitted 1/sec, etc. But use it only if you need to.
See https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks , esp the GPS 18x LVC section, for details on this, and even a method to measure what your fudge time2 should be if you need it.
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
Well, I did start the thread, but I have seen where others have had issues getting PPS working properly. So probably a good idea to make it easier to find.
You nailed it! I have the Garmin 18x LVC and also found the support.ntp.org page. So after changing the config to:
fudge time1 0.0 time2 0.500I am now seeing much better results:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 0.084 0.028 LOCAL(0) .LOCL. 12 l - 64 0 0.000 0.000 0.000 -85-234-197-5.be 193.190.230.65 2 u 61 64 377 108.194 1.016 15.468 -estatico.iloves 148.167.132.201 3 u 58 64 377 87.014 7.642 0.578 +68.11.14.81 172.24.0.53 2 u 58 64 377 70.528 -2.684 1.125 +xen1.rack911.co 209.51.161.238 2 u 58 64 377 83.841 -3.073 0.783 *mdnworldwide.co 216.218.192.202 2 u 58 64 377 75.665 -3.729 1.365Although ntpd isn't using it…. :(
-
Then again, it looks like it is. Checking the status externally at. Says it is using the GPS and is a stratum one time server:
Peers remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 11 16 377 0.000 -0.003 0.002 LOCAL(0) .LOCL. 12 l - 64 0 0.000 0.000 0.000 *85-234-197-5.be 193.190.230.65 2 u 28 64 377 124.278 -7.650 9.640 -estatico.iloves 148.167.132.201 3 u 20 64 377 86.416 7.603 0.486 +68.11.14.81 172.24.0.53 2 u 33 64 377 69.316 -2.928 15.344 +xen1.rack911.co 209.51.161.238 2 u 34 64 377 83.092 -4.407 3.442 +mdnworldwide.co 216.218.192.202 2 u 20 64 377 72.087 -1.754 2.973 Variables assID=0 status=041d leap_none, sync_uhf_clock, 1 event, event_13, version="ntpd 4.2.6p5@1.2349-o Wed Jul 24 14:36:48 UTC 2013 (1)", processor="i386", system="FreeBSD/8.3-RELEASE-p11", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.418, refid=GPS, reftime=d5ee1472.3eb9d629 Thu, Sep 26 2013 2:03:30.245, clock=d5ee147e.5c80a48e Thu, Sep 26 2013 2:03:42.361, peer=31929, tc=4, mintc=3, offset=-0.003, frequency=33.037, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001I guess now I can change the refid to PPS. 8)
-
Updating this after awhile. The external query looks pretty good:
Peers remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .PPS. 0 l 12 16 377 0.000 0.002 0.002 LOCAL(0) .LOCL. 12 l 29h 64 0 0.000 0.000 0.000 -voxl-nyc-21.ser 108.61.73.244 3 u 21 64 377 8.011 0.816 0.643 +a1.hotfile.com 128.4.1.1 2 u 46 64 377 52.236 0.251 0.701 +isaachayes.khre 204.123.2.72 2 u 22 64 377 85.382 -1.156 0.764 -ntp8.vps.net 203.117.180.36 2 u 56 64 377 262.337 5.677 10.728 +167.80.55.66.ho 164.244.221.197 2 u 62 64 377 35.570 -0.451 6.612 Variables assID=0 status=0418 leap_none, sync_uhf_clock, 1 event, event_8, version="ntpd 4.2.6p5@1.2349-o Wed Jul 24 14:36:48 UTC 2013 (1)", processor="i386", system="FreeBSD/8.3-RELEASE-p11", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.417, refid=PPS, reftime=d5f4c835.f6d3b219 Tue, Oct 1 2013 4:04:05.964, clock=d5f4c842.e7ee6a7a Tue, Oct 1 2013 4:04:18.905, peer=19123, tc=4, mintc=3, offset=0.002, frequency=33.059, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.003ntpd seems to jump around between using the GPS or an external source for the actual time, but apparently always uses PPS for when a second transition occurs.
Also of note is that I did see position info on the Status>NTP page, but lost that when I config'd ntpd to look at only the $GPGGA sentences.
-
I ran into the same problem with serial ports being completely muted on my Intel-based board. Seems that the cause is not ACPI's fault, but rather the information provided by BIOS is inaccurate, and FreeBSD misunderstands where to attach the ports.
Here I found the fix:
https://forums.freebsd.org/viewtopic.php?&t=15740"It plagues FreeBSD 8.3 and newer (ever since cio was replaced by uart, which attaches to acpi). Your solution is to disable ACPI and thus make uart attach to iso instead of acpi.
Disabling ACPI is often not feasible on modern x64 hardware. Loading it later at boot as a kernel module (which would help as well) is an overkill, especially since GENERIC FreeBSD has acpi compiled in the kernel and thus it would require you to rebuild your kernel.
Luckily you can disable ACPI only for the problematic serial console (uart) device. The device will not attach to acpi, but to isa instead. And magically the console (login with getty) will work!!
- Confirm your device is attached to acpi at the moment:
dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0- Identify the location of the device in the ACPI namespace:
sysctl -a | grep 'uart.0' dev.uart.0.%desc: 16550 or compatible dev.uart.0.%driver: uart dev.uart.0.%location: handle=\_SB_.PCI0.SBRG.UAR1 dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.uart.0.%parent: acpi0- Disable this location in ACPI:
echo 'debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1"' >> /boot/loader.conf.local- Restart and confirm your device is not attached to acpi anymore:
dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0The rest of ACPI is still active, your console works and you didn't have to rebuild the kernel! Worked for me for JNF99-525 (jnf99fl-525-lf) motherboard.
…..
Simply could not read data from sensors (GPS etc) on the onboard serial ports (cuau0 and cuau1).
This code in /boot/loader.conf.local solved my problem.
debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"For both serial ports!"
-
This works fine on 2.1.2 also, this time tested with x64.
-
This works fine on 2.1.2 also, this time tested with x64.
Thanks for this! I did not have to do this with the 2.03 / 2.1 pfSense series, but I did have to use this workaround when I updated to 2.2 Alpha. Something evidently changed (I'd go so far as to say reverted ….), going from FreeBSD 8.3 to FreeBSD 10.0.
I'll post in the 2.2 Alpha feedback forum as well.
-
Thanks guys!
Worked here on my 2.1.3 release for GPS/PPS stuff. Changed two first serial ports.
dmesg | grep uart
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0
uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0
uart3: <16550 or compatible> port 0x2e8-0x2ef irq 11 on acpi0 -
This code in /boot/loader.conf.local solved my problem.
debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"For both serial ports!"
Just a quick note that this is NOT needed anymore for 2.2-RELEASE on my Jetway NF99 motherboard. My guess is that it's not needed anymore on any other board which required this in previous pfSense versions.
Ports work out of the box. -
