I suspect the multitasking aspect of the OS will give you far more jitter than one could cope with.
> On Nov 4, 2016, at 22:46, Casey L. Jones <timen...@caseyljones.com> wrote: > > Maybe you could use something like a serial to parallel converter chip or the > serial port input of a microcontroller. You could feed in a constant string > of zeros until an event, and then feed in a one to the stream when the event > occurs. You could save the stream of ones and zeros in memory for maybe a > second, and then stamp the block with the time. Then you can have your main > CPU figure out the time of each event by knowing the bitrate and looking at > how many bits precede each one bit back to the beginning of the block. The > blocks would likely be largely zeros, and would thus compress really well if > you decide to not even bother converting the format of the blocks to a > timestamp format. The advantage of this scheme is that it could probably have > a sampling rate far higher than a timestamping process, without overstressing > even many modestly powered processors. > > Another way to synchronize your samples with GPS, at the cost of some sample > rate, is to use a two input multiplexer at your serial input and to take > every odd bit of your serial stream to be a sample of the pps output of your > GPS and every even bit to be the state of your event trigger. That way your > pps and data are interleaved in your bitstream for post processing. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.