simon said: > I am (ab)using the GPIO, rather than using external DAC. Some serial port hardware has a mode that will send raw bits -- no start or stop bits, and no bit stuffing that would mangle the bit stream. With a DMA channel, you can send long strings of bits with solid timing. If you are working with IRIG, the old Mills NTP package has a driver that will decode IRIG and a hack that will send IRIG. You might get some ideas. (or might waste some time) Start at ntp.org, grab a tarball, and look for ntpd/refclock_irig.c and util/tg.c and tg2.c I doubt if anything interesting has changed in that area for a long long time. There was a long IRIG discussion on time-nuts back in 2010: https://www.febo.com/pipermail/time-nuts/2010-May/047364.html -- These are my opinions. I hate spam.

On 2024-12-15 03:14, Hal Murray via time-nuts wrote: > simon said: >> I am (ab)using the GPIO, rather than using external DAC. > > Some serial port hardware has a mode that will send raw bits -- no > start > or stop bits, and no bit stuffing that would mangle the bit stream. > With > a DMA channel, you can send long strings of bits with solid timing. I already solved that part of the puzzle - the Pico has a bunch of simple/specialized processors (the PIOs). The CPU pre-computes the bit stream and stuffs each 'frame' into a FIFO, then a PIO state machine reads out the FIFO asserting the GPIO at the correct time/precise moment(s). > > If you are working with IRIG, the old Mills NTP package has a driver > that > will decode IRIG and a hack that will send IRIG. You might get some > ideas. > (or might waste some time) Start at ntp.org, grab a tarball, and look > for ntpd/refclock_irig.c and util/tg.c and tg2.c I doubt if anything > interesting has changed in that area for a long long time. > > There was a long IRIG discussion on time-nuts back in 2010: > https://www.febo.com/pipermail/time-nuts/2010-May/047364.html Thanks for the links, I'll be doing some reading, Simon.