Empathy List Archives

CL

Casey L. Jones

Sat, Nov 5, 2016 2:46 AM

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.

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.

B

bownes

Sat, Nov 5, 2016 3:34 AM

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 timenuts@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.

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 <timenuts@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.

CL

Casey L. Jones

Sat, Nov 5, 2016 4:48 AM

Yes, you might need a separate dedicated chip to take in the serial input
steadily. Although you may not. Many serial ports have a small buffer to
prevent missed serial input when the operating system gets distracted with
something other than processing serial data.

Yes, you might need a separate dedicated chip to take in the serial input steadily. Although you may not. Many serial ports have a small buffer to prevent missed serial input when the operating system gets distracted with something other than processing serial data.

IP

Ilia Platone

Sat, Nov 5, 2016 5:52 AM

Hi, and thank you for these suggestions.

Currently this project becomes reality (slowly): this kind of
synchronization/grabbing is very interesting, but I need something fast
(I expect the SPAD with active quenching circuitry could output 30ns
pulses, and the quantization frequency I hope to run at is 350/450MHz
range).
Anyway, I found some FPGA code for so fast UART, not difficult to
implement, and using these kind of devices this system you propose can
be built from scratch, including a small buffer.

Can I post an LTSpice drawing for review here describing the active
quenching circuitry?

Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:

Yes, you might need a separate dedicated chip to take in the serial
input steadily. Although you may not. Many serial ports have a small
buffer to prevent missed serial input when the operating system gets
distracted with something other than processing serial data.

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.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

Hi, and thank you for these suggestions. Currently this project becomes reality (slowly): this kind of synchronization/grabbing is very interesting, but I need something fast (I expect the SPAD with active quenching circuitry could output 30ns pulses, and the quantization frequency I hope to run at is 350/450MHz range). Anyway, I found some FPGA code for so fast UART, not difficult to implement, and using these kind of devices this system you propose can be built from scratch, including a small buffer. Can I post an LTSpice drawing for review here describing the active quenching circuitry? Best Regards, Ilia On 11/05/16 04:48, Casey L. Jones wrote: > Yes, you might need a separate dedicated chip to take in the serial > input steadily. Although you may not. Many serial ports have a small > buffer to prevent missed serial input when the operating system gets > distracted with something other than processing serial data. > _______________________________________________ > 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. > -- Ilia Platone via Ferrara 54 47841 Cattolica (RN), Italy Cell +39 349 1075999

BG

Bruce Griffiths

Sat, Nov 5, 2016 6:10 AM

Ilia
Circuit diagrams are posted here from time to time, so it should be OK.
Bruce

On Saturday, 5 November 2016 7:02 PM, Ilia Platone <info@iliaplatone.com> wrote:

Hi, and thank you for these suggestions.

Currently this project becomes reality (slowly): this kind of
synchronization/grabbing is very interesting, but I need something fast
(I expect the SPAD with active quenching circuitry could output 30ns
pulses, and the quantization frequency I hope to run at is 350/450MHz
range).
Anyway, I found some FPGA code for so fast UART, not difficult to
implement, and using these kind of devices this system you propose can
be built from scratch, including a small buffer.

Can I post an LTSpice drawing for review here describing the active
quenching circuitry?

Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:

Yes, you might need a separate dedicated chip to take in the serial
input steadily. Although you may not. Many serial ports have a small
buffer to prevent missed serial input when the operating system gets
distracted with something other than processing serial data.

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.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

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.

Ilia Circuit diagrams are posted here from time to time, so it should be OK. Bruce On Saturday, 5 November 2016 7:02 PM, Ilia Platone <info@iliaplatone.com> wrote: Hi, and thank you for these suggestions. Currently this project becomes reality (slowly): this kind of synchronization/grabbing is very interesting, but I need something fast (I expect the SPAD with active quenching circuitry could output 30ns pulses, and the quantization frequency I hope to run at is 350/450MHz range). Anyway, I found some FPGA code for so fast UART, not difficult to implement, and using these kind of devices this system you propose can be built from scratch, including a small buffer. Can I post an LTSpice drawing for review here describing the active quenching circuitry? Best Regards, Ilia On 11/05/16 04:48, Casey L. Jones wrote: > Yes, you might need a separate dedicated chip to take in the serial > input steadily. Although you may not. Many serial ports have a small > buffer to prevent missed serial input when the operating system gets > distracted with something other than processing serial data. > _______________________________________________ > 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. > -- Ilia Platone via Ferrara 54 47841 Cattolica (RN), Italy Cell +39 349 1075999 _______________________________________________ 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.

IP

Ilia Platone

Sat, Nov 5, 2016 7:20 AM

Attached to this mail there are three files: the APD.asc LTSpice4
simulation schematics, a model for the AD8561 comparator, a model for
the VN2210 mosfet transistor, and a model for the BF959 bipolar transistor.

Please note that the APD model included into the schematics may have
errors: I took it from an LTSpice demo and adapted on the APDs I have,
some Marktech MTAPD, and observations made with them.

Unfortunately the boards have been ordered, but components shortening or
value editing can be done. (the real value of the capacitor of the psu
is 47uF, for faster rendering I dropped it to a lower value.

Best Regards,
Ilia.

On 11/05/16 06:10, Bruce Griffiths wrote:

Ilia
Circuit diagrams are posted here from time to time, so it should be OK.
Bruce

  On Saturday, 5 November 2016 7:02 PM, Ilia Platone <info@iliaplatone.com> wrote:

Hi, and thank you for these suggestions.

Currently this project becomes reality (slowly): this kind of
synchronization/grabbing is very interesting, but I need something fast
(I expect the SPAD with active quenching circuitry could output 30ns
pulses, and the quantization frequency I hope to run at is 350/450MHz
range).
Anyway, I found some FPGA code for so fast UART, not difficult to
implement, and using these kind of devices this system you propose can
be built from scratch, including a small buffer.

Can I post an LTSpice drawing for review here describing the active
quenching circuitry?

Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:

Yes, you might need a separate dedicated chip to take in the serial
input steadily. Although you may not. Many serial ports have a small
buffer to prevent missed serial input when the operating system gets
distracted with something other than processing serial data.

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.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

Attached to this mail there are three files: the APD.asc LTSpice4 simulation schematics, a model for the AD8561 comparator, a model for the VN2210 mosfet transistor, and a model for the BF959 bipolar transistor. Please note that the APD model included into the schematics may have errors: I took it from an LTSpice demo and adapted on the APDs I have, some Marktech MTAPD, and observations made with them. Unfortunately the boards have been ordered, but components shortening or value editing can be done. (the real value of the capacitor of the psu is 47uF, for faster rendering I dropped it to a lower value. Best Regards, Ilia. On 11/05/16 06:10, Bruce Griffiths wrote: > Ilia > Circuit diagrams are posted here from time to time, so it should be OK. > Bruce > > On Saturday, 5 November 2016 7:02 PM, Ilia Platone <info@iliaplatone.com> wrote: > > > Hi, and thank you for these suggestions. > > Currently this project becomes reality (slowly): this kind of > synchronization/grabbing is very interesting, but I need something fast > (I expect the SPAD with active quenching circuitry could output 30ns > pulses, and the quantization frequency I hope to run at is 350/450MHz > range). > Anyway, I found some FPGA code for so fast UART, not difficult to > implement, and using these kind of devices this system you propose can > be built from scratch, including a small buffer. > > Can I post an LTSpice drawing for review here describing the active > quenching circuitry? > > Best Regards, > Ilia > > On 11/05/16 04:48, Casey L. Jones wrote: >> Yes, you might need a separate dedicated chip to take in the serial >> input steadily. Although you may not. Many serial ports have a small >> buffer to prevent missed serial input when the operating system gets >> distracted with something other than processing serial data. >> _______________________________________________ >> 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. >> -- Ilia Platone via Ferrara 54 47841 Cattolica (RN), Italy Cell +39 349 1075999

IP

Ilia Platone

Tue, Nov 22, 2016 5:30 PM

Hi,
Do a SPI bus do this job correctly? I'd have the clock on one line and
the pulses logged on a second line. Like CLK for clock pulses and
MOSI/MISO for serial logging of pulses. I'd avoid I2C because of
addressing packets.

Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:

Yes, you might need a separate dedicated chip to take in the serial
input steadily. Although you may not. Many serial ports have a small
buffer to prevent missed serial input when the operating system gets
distracted with something other than processing serial data.

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.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

Hi, Do a SPI bus do this job correctly? I'd have the clock on one line and the pulses logged on a second line. Like CLK for clock pulses and MOSI/MISO for serial logging of pulses. I'd avoid I2C because of addressing packets. Best Regards, Ilia On 11/05/16 04:48, Casey L. Jones wrote: > Yes, you might need a separate dedicated chip to take in the serial > input steadily. Although you may not. Many serial ports have a small > buffer to prevent missed serial input when the operating system gets > distracted with something other than processing serial data. > _______________________________________________ > 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. > -- Ilia Platone via Ferrara 54 47841 Cattolica (RN), Italy Cell +39 349 1075999

time-nuts@lists.febo.com

Re: [time-nuts] Linux PPS clues?