Help with Serial GPS Configuration
-
I'm running pfSense 2.4.0-RELEASE and I am experiencing an odd issue with Serial GPS. Motherboard is a SuperMicro X8STi-F.
I have connected a uBlox NEO-M8N through TTL <-> RS232 converters to an internal serial COM header, with a PPS signal on the DCD line, and configured it with a baud of 9600.
- When I connect it to a Windows machine and open the port with PuTTY, I get the expected serial output (at least over the RX/TX lines)
$GNZDA,110020.00,05,12,2017,00,00*78 $PUBX,00,110020.00,4511.69187,N,09307.15935,W,276.630,G3,9.1,8.6,0.355,53.36,0.106,,2.27,2.28,2.44,8,0,0*44 $GNRMC,110021.00,A,4511.69178,N,09307.15935,W,0.524,,051217,,,A,V*00 $GNVTG,,T,,M,0.524,N,0.970,K,A*30 $GNGGA,110021.00,4511.69178,N,09307.15935,W,1,08,2.27,307.7,M,-31.1,M,,*77 $GNGSA,A,3,12,02,24,25,,,,,,,,,3.22,2.27,2.28,1*0D $GNGSA,A,3,78,81,88,79,,,,,,,,,3.22,2.27,2.28,2*06 $GPGSV,4,1,14,02,70,255,26,03,00,030,,05,17,185,15,06,70,047,17,0*69 $GPGSV,4,2,14,09,05,089,,12,59,287,35,17,25,099,,19,44,091,12,0*6D $GPGSV,4,3,14,23,06,058,21,24,10,241,14,25,25,315,35,29,02,289,,0*60 $GPGSV,4,4,14,48,25,230,,51,36,200,,0*69 $GLGSV,3,1,11,65,35,115,13,66,02,163,,71,04,013,,72,33,054,,0*7B $GLGSV,3,2,11,77,03,194,,78,35,232,31,79,41,290,29,80,06,344,22,0*79 $GLGSV,3,3,11,81,34,289,27,87,30,068,,88,63,006,20,0*42 $GNGLL,4511.69178,N,09307.15935,W,110021.00,A,A*60 $GNZDA,110021.00,05,12,2017,00,00*79 $PUBX,00,110021.00,4511.69178,N,09307.15935,W,276.623,G3,9.3,8.7,0.970,53.36,0.120,,2.27,2.28,2.44,8,0,0*4D $PUBX,04,110021.00,051217,212420.99,1978,18,716692,196.598,21*17 $GNRMC,110022.00,A,4511.69166,N,09307.15928,W,0.715,,051217,,,A,V*00 $GNVTG,,T,,M,0.715,N,1.324,K,A*3A-
When I open the uBlox uCenter application on windows, connected on an internal COM header, it works properly (at least the RX/TX lines)
-
When I use a tool to display the DCD line in Windows, it works as expected (1s signal, 10% duty cycle)
-
When I look at the signal levels over an oscilloscope they look right (0v - 5v on the uBlox side, +10v to -10v on the RS232 side)
-
When I configure the Serial GPS output to be through a USB to TTL converter (becomes /dev/ttyU0) straight to the uBlox, ntpd recognizes the signal and starts using it, but I get a large number of 'badformat' messages:
[2.4.0-RELEASE][admin@pfSense.lan]/root: ntpq -c cv associd=0 status=00f2 15 events, clk_bad_format, device="NMEA GPS Clock", timecode="$GNRMC,112428.00,A,4511.68928,N,09307.15503,W,0.344,,051217,,,A,V*0A", poll=3, noreply=0, badformat=52, baddata=0, fudgetime2=400.000, stratum=0, refid=GPS, flags=7I can then see the output via `cat /dev/cuaU0' as it looks in windows.
-
I get the same output with the external serial port, /dev/cuau0, but ntpd won't sync or use it.
-
I can't get any output out of the internal serial port, /dev/cuau1, and ntpd won't sync or use it.
Any ideas why it would work over a USB to TTL converter, and show output over then external serial port, but not over the internal RS232 header and ntpd will only use it over USB?
-
Check this out: https://forum.pfsense.org/index.php?topic=93999.0
I've ran into this several times. FreeBSD handles serial ports strange in many cases, it looks to me as if it would be some kind of "misunderstanding" between motherboard implementations and FreeBSD approach on how to access the serial ports. For basic things like serial console etc. it should work fine, but more advanced usage often turns out to be a wrong ACPI approach from FreeBSD.
And avoid using USB-Serial adapters with GPS/PPS. USB introduces serious latency and jitter - making your NTP server imprecise.
-
That's likely my very issue, but I'm having some issues following the steps there.
I tried first disabling ACPI on the three serial ports:
/boot/loader.conf.local
debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2 \_SB_.PCI0.SBRG.UAR3"However, I still got acpi loading on them:
[2.4.0-RELEASE][root@yourpfsense.local]/root: sysctl -a | grep uart 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=0 dev.uart.0.%parent: acpi0 dev.uart.1.%desc: 16550 or compatible dev.uart.1.%driver: uart dev.uart.1.%location: handle=\_SB_.PCI0.SBRG.UAR2 dev.uart.1.%pnpinfo: _HID=PNP0501 _UID=1 dev.uart.1.%parent: acpi0 dev.uart.2.%desc: 16550 or compatible dev.uart.2.%driver: uart dev.uart.2.%location: handle=\_SB_.PCI0.SBRG.UAR3 dev.uart.2.%pnpinfo: _HID=PNP0501 _UID=2 dev.uart.2.%parent: acpi0I then tried disabling ACPI entirely through
hint.acpi.0.disabled=”1″in loader.conf.local, and then disabled ACPI in the BIOS.Now I am unable to get it booting again, even with the ACPI BIOS settings restored and trying to turn on ACPI in the boot option.
Is there a way I can edit loader.conf.local without booting pfSense? It either kernel panics or hangs on boot.
-
Did you follow correctly the steps described in my link above, especially step2? Are the names 100% correct? Maybe you could post here the outputs of the commands.
You'd be faster by reinstalling the whole thing from scratch and try again from the beginning.
-
AHA!!!
It turns out that SuperMicro Internal COM ports have a different pinout than the standard - which is why it worked perfect on my windows machine (an ASUS motherboard), but didn't on the SuperMicro. Praise be to the Oscilloscope!
Standard COM Header Pinout:
SuperMicro COM Header Pinout:
Agreed on the full reinstall. I am seeing that ACPI might be best left disabled in a server environment, in this case it's a 1U rackmount server. Would it be better to reinstall with ACPI disabled in the BIOS?
-
Disabling ACPI is not a good idea since it mostly leaves the firmware in charge instead of the OS. Best is to have the firmware do nothing of the sort, black box software is bad in all cases.
-
@johnkeates:
Disabling ACPI is not a good idea since it mostly leaves the firmware in charge instead of the OS.
Thanks. I was able to get it up and running again by clearing the CMOS and reconfiguring the BIOS. I left APCI enabled.
Did you follow correctly the steps described in my link above, especially step2? Are the names 100% correct? Maybe you could post here the outputs of the commands.
I did follow them, the statements are in loader.conf.local and are listed correctly, but I still get acpi drivers. Is it possible that acpi isn't in debug mode to listen to the debug statements?
I'll post up the results shortly.
-
It looks like it did finally take, but this is ~5 restarts after I added it to /boot/loader.conf.local and I was getting acpi as the parent one restart ago. Also, interestingly, the 'fake' serial port from IPMI isn't present (was UAR3 / cuau2).
Thanks, mate!
Enter an option: 8 [2.4.0-RELEASE][admin@pfSense.lan]/root: cat /boot/loader.conf.local # Disable ACPI Entirely #hint.acpi.0.disabled="1" # Disable ACPI for Serial Ports debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2 \_SB_.PCI0.SBRG.UAR3" [2.4.0-RELEASE][admin@pfSense.lan]/root: dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 uart1: <16550 or compatible> at port 0x2f8 irq 3 on isa0 [2.4.0-RELEASE][admin@pfSense.lan]/root: sysctl -a | grep uart device uart_ns8250 device uart kern.console: ttyv0,/uart,ucom,ttyv0, debug.uart_force_poll: 0 debug.uart_poll_freq: 50 dev.uart.1.pps_mode: 2 dev.uart.1.%parent: isa0 dev.uart.1.%pnpinfo: dev.uart.1.%location: dev.uart.1.%driver: uart dev.uart.1.%desc: 16550 or compatible dev.uart.0.pps_mode: 2 dev.uart.0.%parent: isa0 dev.uart.0.%pnpinfo: dev.uart.0.%location: dev.uart.0.%driver: uart dev.uart.0.%desc: 16550 or compatible dev.uart.%parent: -
AHA!!!
Yep, ran into that too, it was the next thing I would have recommended to check against, however, this applies only to internal headers, external D-SUB connectors are everywhere the same. If you say you had partial success with USB, then after the ACPI trick you should have noticed success on the rear D-SUB too. And only after that, try the internal header… 8)
This is not SuperMicro-specific, this dates from the 1990's, there were always two flavours of interal header pinout: IBM/DTK WIRING SCHEME and EVEREX/ASUS WIRING SCHEME.
It's only a question of which manufacturer adopts which standard, nothing more.SERIAL MOTHERBOARD CABLE 10 PIN DIL TO DB-9 (IBM/DTK WIRING SCHEME) This is the ribbon cable from the MB serial connector to the DB-9/DB-25 COM connector DIL DB-9 DB-25 1 -------------- 1 DCD __________ 8 6 -------------- 2 RX ___________ 3 2 -------------- 3 TX ___________ 2 7 -------------- 4 DTR __________ 20 3 -------------- 5 GND __________ 7 8 -------------- 6 DSR __________ 6 4 -------------- 7 RTS __________ 4 9 -------------- 8 CTS __________ 5 5 -------------- 9 RI ___________ 22 10 ------------- 10 N/C OR KEY SERIAL MOTHERBOARD CABLE 10 PIN DIL TO DB-9 (EVEREX/ASUS WIRING SCHEME) This is the ribbon cable from the MB serial connector to the DB-9/DB-25 COM connector DIL DB-9 DB-25 1 -------------- 1 DCD __________ 8 2 -------------- 2 RX __________ 3 3 -------------- 3 TX __________ 2 4 -------------- 4 DTR __________ 20 5 -------------- 5 GND __________ 7 6 -------------- 6 DSR __________ 6 7 -------------- 7 RTS __________ 4 8 -------------- 8 CTS __________ 5 9 -------------- 9 RI __________ 22 10 ------------- 10 N/C OR KEY
