2
\$\begingroup\$

I am looking for a 20 us wide TTL signal to be ingested into my device so that I can sync my OS to a PPS (pulse per second) with chrony.

I'm currently looking at all the ways to have the signal enter my computer. One of them is GPIB. From searching online, the only adapters/converters for GPIB seem to be USB and RS-232.

Is there any way to convert TTL to GPIB? I know I can convert TTL to USB and 232, but is there any way to cut out the middle steps since I imagine that'll cause delays, degradation, and would probably be better to just to have TTL to USB/232 (which I already found ways).

I even tried finding a way to convert it but I'm not sure how the handshaking and management buses would work (would I even need that)?

From looking online (including here), USB appears to be a bad choice due to the "stack", being slow (due to everything sharing a bus?) and such but I still dont understand why. It seems like itd be fine but apparently not. Currently nothing in my system uses GPIB. I just figured no stone should go unturned.

\$\endgroup\$
14
  • 1
    \$\begingroup\$ GPIB is not a good choice. To pick a better one you'll need to describe what the TTL signal represents and what you want to do with it. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 12:47
  • 1
    \$\begingroup\$ This sounds a lot like an XY problem. GPIB does not sound like a terribly good solution these days, perhaps unless other legacy things in your system already use it. What does this TTL signal carry? Is it some form of UART, some sync signal, what is it? This wildly affects what the solution can be. It can range from a cheap raspberry pi-like device or a microcontroller "ingesting" stuff over its GPIO every once in a while and messaging your whatever over the network, to proper thousand dollar industrial GPIO cards. \$\endgroup\$
    – Richard the Spacecat
    Commented Sep 4, 2020 at 13:12
  • 2
    \$\begingroup\$ Realistically you should research what the standard solutions are for the open source package you want to run, on the hardware you want to run it on. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 13:30
  • 3
    \$\begingroup\$ There's quite a bit of misunderstanding embedded there. The point of an interrupt is that you capture an event. While serial data streams are slower, you would not be reading one in the critical timing, rather you'd be using a status line to capture that an event has occurred as fast as the kernel is able to deal with that. And then you should probably read the time message from the GPS via the serial port at its more leisurely pace before the next pulse occurs a second later, so that you know which second the pulse corresponds to. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 13:35
  • 1
    \$\begingroup\$ A locally interfaced serial port's hardware should support status line interrupts, and a Linux kernel should be able to use them. It may, however, take some careful Kernel configuration to do better then 10 uS... desktop PC operating systems aren't really designed for fine timing. If you were measuring something other than the behavior of the PC itself it would be tempting to recommend an entirely external solution with an MCU or fixed logic, but it sounds like it's the PC itself ypou want to measure. It's possible that your ultimate quest here is not very realistic. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 14:59

1 Answer 1

Reset to default
2
\$\begingroup\$

Assuming (by the comments) that you actually want to build some NTP server with a 1PPS input, you should perhaps look into a Raspberry Pi with the rpi_gpio_ntpd installed. (Also available here.)

This lets you synchronize the timebase of the RPi to an external source connected via one of the GPIO pins, (AFAIK) directly using GPIO interrupts, which sounds about as good as you can get.

Someone has also built this with a GPS receiver, and they do have some real-world data on the rather good level of accuracy you can get with this inexpensive setup.

The only problem left to solve would be level conversion from TTL to 3.3V CMOS input the RPi would accept, but this sounds trivial enough.

Another option would be the use of the Precision Time Protocol (if your NTP server supports this, which isn't unlikely), which uses hardware timestamping in network cards and switches to figure out the latency between two endpoints.

This means your network cards and the switch in-between (if present) would have to support this. Do check if your network cards support this, many do not. However those that do support PTP can be still affordable (like those based on i210-T1).

But this is a standard off-the-shelf solution that is likely to work.

\$\endgroup\$
6
  • \$\begingroup\$ So I have an NTP server with a 1 PPS output already. I just need a way to get my device to ingest it. The 1 PPS is a 50 ohm TTL signal which unfortunately cant directly plug into any of my devices. I want the NTP to be the master timing device. From my device's inputs (USB, 232, GPIB, expresscard34), I need to figure out a way to convert the PPS to those formats. I know for the first two I can use a MAX232 or FTDI chip, but GPIB seems to have the best/lowest latency but hardest conversion. \$\endgroup\$
    – bchang32
    Commented Sep 4, 2020 at 14:42
  • 1
    \$\begingroup\$ No, GPIB is not going to have the lowest latency, probably the opposite actually. To put it another way, whatever interface is tying the GPIB host chip to the processor, you won't do better than using that interface directly. Even if you were going to use existing GPIB hardware, rather than actually speaking GPIB what you'd want to do is just drive SRQ signal and craft a driver which instead of implementing GPIB simply configured the host chip to report that as an interrupt, just as you would with a serial port modem status line. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 15:09
  • \$\begingroup\$ In that case, all your remaining options are the RS232 (perhaps the interrupts are handled fast enough? Can one get interrupts off the control lines changing?), PCIe/ExpressCard (You'll likely have to make a custom device for this with an FPGA + software to handle your interrupts. Which sounds like an absolute ton of work, but with some luck it could work?), or perhaps the network (You already have an NTP server. Does it support PTP as well? \$\endgroup\$
    – Richard the Spacecat
    Commented Sep 4, 2020 at 15:15
  • 1
    \$\begingroup\$ @bchang32 - the reality is that this question isn't answerable without knowing the internal topology of this computer and its interfaces. Anything such as USB which is polled is not going to be truly low latency, for that you need either a direct hardware input (an "interrupt") to the processor itself, or else to trigger a capture event in a hardware timer which can itself be read by the processor with known latency. \$\endgroup\$
    – Chris Stratton
    Commented Sep 4, 2020 at 15:20
  • 1
    \$\begingroup\$ I have a Raspberry Pi 3 Model B+ and a GPS module with PPS output. The problem is that Raspberry's oscillator is very low quality. The frequency goes up and down. Chrony tries to compensate this but as a conclusion I would say that this was a waste of time and money. \$\endgroup\$
    – JPX
    Commented Nov 15, 2022 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.