Thank you! Your post has made my choices clear, UART-c might be it! A previous poster said there'd be no difference in jitter using any of the 4 COM ports and this was reassuring. I will start studying the pinouts to confirm the pin numbers while I wait for the null-modem cable to arrive.
Another question, would connecting PPS, Tx/Rx to the GPIO pins on UART-c make U-blox's Windows u-Center software see this as attached to a physical serial port? If not, how would I present the GPS to Windows via serial? I'd like to test updating the firmware and it appears to not work via a mini-pci to WWAN 3G USB adapter. Others have reported: "After Emeryth published the pinout, I also started to experiment with this board. I found out that you can update the firmware using the LEA-5 firmware version 6.02 from the u-blox web site. The module also works very well with the patched firmware version EXT_G50_602_LEA-5H.bdbfccefb9dbd8395dec7adece53c1f9.bin. This version enables the output of raw data for use with rtklib for real-time kinematic and precision positioning. You can then use the standard drivers from the u-blox web site for Windows. They provide a virtual COM port. Please note that updating the firmware just worked using the physical serial port of the Mini-PCIe card, it did not work using the USB adapter." -----Original Message----- From: time-nuts [mailto:[email protected]] On Behalf Of Paul Sent: Tuesday, August 16, 2016 2:27 AM To: Discussion of precise time and frequency measurement <[email protected]> Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd On Mon, Aug 15, 2016 at 5:35 AM, STR . <[email protected]> wrote: > Pardon my ignorance, I'm not sure what COM port the PPS is tied to or > what you mean. I think there's some confusion. Normally the PPS input to Linux (I'm not sure about FreeBSD) is tied to the DCD pin in a serial port. The PPS code is connected to the interrupt from the DCD. It can be tied to another pin (DSR or CTS I forget), a parallel port or a GPIO pin (a la RaspberryPi or BeagleBone). Anything other than DCD normally requires a specific kernel build. The APU2c has an I/O part connected via an LPC bus. It's essentially 4 UARTS. UART-a is connected to a DE-9 connector via a level shifter. All signals are present. UART-b is brought to J3 unshifted. Even though J3 has five pins only transmit, receive and ground are connected. UARTs "c" and "d" are brought to J17 either as 18 GPIO signals or 2x8 RS-232 signals (the latter requires non-standard bios code to set up the chip). So if we imagine that you want to use the DCD pin on UART-c you'd configure the GPIO pins as serial and connect to pin 9 on J17. Be advised that the specifics in the previous may be wrong so check the schematic. Now if you want to read the correct time as a sentence from the GPS you'd connect the Tx/Rx pins on your module to the corresponding pins on a 3V3 serial port. Continuing to use UART-c that would be pins 7 and 8 on J17. Now regarding jitter. Pascal suggests that the jitter involved in using his take on the LPC connected super i/o part might be too high. As noted someone said that was the case with the APU1. While I wouldn't be surprised if that were still true with the APU2 you might find the time "good enough". Trust but verify. Finally, these boxes are intended to be routers (hence the three network interfaces) not time-servers and unless you're irrevocably wedded to the miniPCIe in APU2 route there are probably better choices for time servers. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
