Linux PPS clues?
On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone info@iliaplatone.com wrote:
I need to know how much precise this system can be. How much resolution
can I obtain with a cheap receiver (maximum quantization frequency)?
Formulas are well accepted.
Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.
You should expect the system time to have error on the order of about 10
microseconds
The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error
The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.
But a lot depends on how you handle the second GPIO interrupt. the GPS
interrupt is handled inside a kernel level handler. The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks. Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process? If
the later expect worse performance. For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.
Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.
Chris Albertson
Redondo Beach, California
On Thu, Oct 20, 2016 at 12:02 AM, Gary E. Miller gem@rellim.com wrote:
I think your graph only shows 1/2 of the problem. It is the easy part
because all that code is written and likely already installed on the OP's
computer.
The other half of the problem is responding to events and getting them time
stamped with very low latency and jitter. In other words the harder job
is actually putting to use that well sync's internal clock. I think the
best way is to copy the design of the Linux PPS system. Then assume the
error in time stamp is a little larger than double your graph.
But if the event time stamp code is not so well designed the results might
to 10X worse not just 2x worse.
How about a graph, or two? See attached. From the histogram, I suspect
the
granularity is about 200 nano sec. From the offset graph you can
see how the offset jumps.
Here is the offset data on PPS v. the system clock:
Percentiles......
Min 1% 5% 50% 95% 99% Max
-21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs
Ranges......
90% 95% StdDev Mean Units
1.825 5.318 0.850 -0.006 µs
Or see a lot more live graphs here: https://pi4.rellim.com/day/
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Another issue is that the finer the timestamp quantisation step size the larger the signal of interest (Intensity correlation). The signal doesn't vanish as the timestamp quantisation step size increases however the signal decreases requiring a longer observation time to achieve a given SNR. Handwaving without calculation to inform the resultant guesses is likely to result in a required observation greater than the age of the universe. This of course is impractically long. This fundamental error was made by several investigators in the some of the first attempts to do intensity interferometry.
Brue
On Friday, 21 October 2016 7:32 PM, Chris Albertson <albertson.chris@gmail.com> wrote:
On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone info@iliaplatone.com wrote:
I need to know how much precise this system can be. How much resolution
can I obtain with a cheap receiver (maximum quantization frequency)?
Formulas are well accepted.
Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.
You should expect the system time to have error on the order of about 10
microseconds
The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error
The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.
But a lot depends on how you handle the second GPIO interrupt. the GPS
interrupt is handled inside a kernel level handler. The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks. Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process? If
the later expect worse performance. For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.
Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.
Chris Albertson
Redondo Beach, California
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.
On Thu, 20 Oct 2016 21:45:42 +0000
Ilia Platone info@iliaplatone.com wrote:
I will be interested to see what is recommended for a 100 kHz event rate.
This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000 cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy processing
with so few cycles.
I can use one of my boards, which have (checked better) 6MHz sampling
frequency on the GPIO, but the sysclock runs at 180MHz, this should be
enough except logging support bandwidth. check the NXP3130 uC which is
powering these boards: it's old but its dirty job is done perfectly.
[...]
These events are random photon arrivals (converted to 5vTTL pulses),
their rate was measured using the pulse width of the smaller detected,
which was 5~10 uS during an observation in low-light environment.
The photon arrival and pulse width were random with a minimum pulse
width of 10uS. What I want to do is measuring the photon arrival
precisely (low to high transition - interrupt I guess), consider that
the maximum rate would be 100Kcps because the photon events would
overlap if higher. If the 3130 controller can handle such rate it would
be great :)
The LPC3130 is IMHO the wrong choice. It does neither have capture/compare
timer units (ie units that can capture when an input event happend) nor
does it have interrupts on GPIO. Hence you would need to poll the pins
continuously while at the same time making sure that the USB port is
properly handled. This will give you a high uncertainty when the event
really happend.
I would definitely use a different board than this.
My advice would be to use one of the many high performance Cortex-M4 boards
I recently had a look at the LPC4330, which should be plenty fast for
this job. But really any other uC with an HS USB port and capture/compare
should do. Then run a minimimal OS on it (Nuttx comes to mind) to give
you the basic functionality you need without too much trouble. Upon each
event, store the value of the capture register in a ring buffer(1k-2k large).
Read that ring buffer in the main loop and push the data out of the USB port
in chuncks of 512byte to get maximum throughput. Use a PC to record the
data for later processing.
Attila Kinali
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
I really think that a wired correlator would be the best choice... using
an FPGA :)
Best Regards,
Ilia.
On 10/21/16 06:45, Bruce Griffiths wrote:
Another issue is that the finer the timestamp quantisation step size the larger the signal of interest (Intensity correlation). The signal doesn't vanish as the timestamp quantisation step size increases however the signal decreases requiring a longer observation time to achieve a given SNR. Handwaving without calculation to inform the resultant guesses is likely to result in a required observation greater than the age of the universe. This of course is impractically long. This fundamental error was made by several investigators in the some of the first attempts to do intensity interferometry.
Brue
On Friday, 21 October 2016 7:32 PM, Chris Albertson <albertson.chris@gmail.com> wrote:
On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone info@iliaplatone.com wrote:
I need to know how much precise this system can be. How much resolution
can I obtain with a cheap receiver (maximum quantization frequency)?
Formulas are well accepted.
Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.
You should expect the system time to have error on the order of about 10
microseconds
The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error
The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.
But a lot depends on how you handle the second GPIO interrupt. the GPS
interrupt is handled inside a kernel level handler. The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks. Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process? If
the later expect worse performance. For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.
Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.
Chris Albertson
Redondo Beach, California
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.
--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?
On 21 Oct 2016 12:23 a.m., "Ilia Platone" info@iliaplatone.com wrote:
sorry, no attachment, this mail contains two images, one is the previous
attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a
different oscilloscope setup.
Best Regards,
Ilia.
On 10/20/16 18:12, Attila Kinali wrote:
On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor" david-taylor@blueyonder.co.uk wrote:
Actually, of the 15 Raspberry Pi cards I have only one is used in a
graphics
application.
Yes, the rpi are used for all kind of stuff and there is a huge community
around them that helps with all kind of questions. Unfortunately, the
rpi is also used for all kind of stuff that it is a suboptimal choice
(to put it mildly), but people do not care or do not want to check
for alternatives. It kind of works, that's all they care about.
On the positive side they work very well with external devices for control
and measurement,
And for most of these applications a 32bit uC that uses a fraction of
the power would be the right choice. Often a clock of 1MHz would be
enough.
and have a huge amount of software and hardware support for
a vast range of devices which makes for fast and easy development.
That's the only plus side. But then, most of the code written in C
can be used on a uC just the same with little to no modification.
I will be interested to see what is recommended for a 100 kHz event rate.
This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000
cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy
processing
with so few cycles.
On the application processor 20k cylces is plenty, but you have the
complex
OS that eats up a few thousand cycles itself. Addtionally there comes
the interrupt latency that the application processors suffer from, which
is in the order of 1-10µs... So they would need a kind of (hardware)
system
to queue up the events to process them in badges. Because of this, an rpi
wouldn't work at all (bitbanging takes several µs for each operation).
Going for an uC is easier in that regard as they have very little
interrupt
latency (usually just 5-10 cycles), but then you have problems with
getting the output out of the uC as their I/O subsystems are usually
optimized to work in a stand-alone fashion.
Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an
application
processor) and use their high speed I/O.
For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.
Attila Kinali
--
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.
it's a BC546, 10k collector resistor... I thought it was fast enough,
but also think the signal is inverted, since there's passive quenching
in this circuit, so the breakdown voltage of the APD is lowering too
slowly before next photon, causing this kind of positive edge.. if you
see well there's the same slope in all the signals. I'm currently
searching for an active quenching circuit that fits into my application.
Best Regards,
Ilia.
On 10/21/16 09:53, Adrian Godwin wrote:
What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?
On 21 Oct 2016 12:23 a.m., "Ilia Platone" info@iliaplatone.com wrote:
sorry, no attachment, this mail contains two images, one is the previous
attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a
different oscilloscope setup.
Best Regards,
Ilia.
On 10/20/16 18:12, Attila Kinali wrote:
On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor" david-taylor@blueyonder.co.uk wrote:
Actually, of the 15 Raspberry Pi cards I have only one is used in a
graphics
application.
Yes, the rpi are used for all kind of stuff and there is a huge community
around them that helps with all kind of questions. Unfortunately, the
rpi is also used for all kind of stuff that it is a suboptimal choice
(to put it mildly), but people do not care or do not want to check
for alternatives. It kind of works, that's all they care about.
On the positive side they work very well with external devices for control
and measurement,
And for most of these applications a 32bit uC that uses a fraction of
the power would be the right choice. Often a clock of 1MHz would be
enough.
and have a huge amount of software and hardware support for
a vast range of devices which makes for fast and easy development.
That's the only plus side. But then, most of the code written in C
can be used on a uC just the same with little to no modification.
I will be interested to see what is recommended for a 100 kHz event rate.
This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000
cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy
processing
with so few cycles.
On the application processor 20k cylces is plenty, but you have the
complex
OS that eats up a few thousand cycles itself. Addtionally there comes
the interrupt latency that the application processors suffer from, which
is in the order of 1-10µs... So they would need a kind of (hardware)
system
to queue up the events to process them in badges. Because of this, an rpi
wouldn't work at all (bitbanging takes several µs for each operation).
Going for an uC is easier in that regard as they have very little
interrupt
latency (usually just 5-10 cycles), but then you have problems with
getting the output out of the uC as their I/O subsystems are usually
optimized to work in a stand-alone fashion.
Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an
application
processor) and use their high speed I/O.
For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.
Attila Kinali
--
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.
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
Yo Chris!
On Thu, 20 Oct 2016 23:31:46 -0700
Chris Albertson albertson.chris@gmail.com wrote:
You should expect the system time to have error on the order of about
10 microseconds
Check out the graaphs I sent earlier. On a RasPi I can get oue
standard deviation under 1 µs.
The PPS signal error comping out of events low cost GPS receiver has
error oon order of say a few tens of nano seconds, that is 100 to
1000 times less error
Depends on the vendor. Many only specify one standard deviation of
1 µs. And you should alway treat spec sheet numbers as besst case.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Chris!
On Thu, 20 Oct 2016 23:37:23 -0700
Chris Albertson albertson.chris@gmail.com wrote:
I think your graph only shows 1/2 of the problem. It is the easy part
because all that code is written and likely already installed on the
OP's computer.
Yup, of course. But my actual results do not match people's
expectations as recently stated on this list. To ground the data I am
merely providing an actual baseline for the quality of the system clock
on a RasPi 3 when GPS stabilized using the techniques documented in the
gpsd and ntpsec documentation.
The other half of the problem is responding to events and getting
them time stamped with very low latency and jitter.
Yup, of course. I have not commented on the second part of the problem.
I am enjoying the many and varied solutions being presented here. I look
forward to actual implementations and hard performance data on them.
I think the best way is to copy the design of the Linux PPS
system.
I'll reserve my judgement on 'best'. Since my data says the Linux
kernel PPS system can reach about 1 µs standard deviation on a
RasPi3 using the GPIO lines, I would expect a solution based on that
would behave similarly.
Then assume the error in time stamp is a little larger
than double your graph.
Ah, double which error? I give error calculations of one standard
deviation, 90% percentile range, and 98% percentile range. My guess
would be that any technique using the same method on the same hardware
would have a similar 98% range.
My 98% range on this RasPi3 is under 5 µs. I'll leave it to the
OP to decide if that is good enough, easy enough, etc.
You can see the live numbers here: https://pi4.rellim.com/day/
But if the event time stamp code is not so well designed the results
might to 10X worse not just 2x worse.
Once can always do things badly. :-)
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
If you are detecting events at 100Khz I think the best way is not to try
and time stamp each event. Even if only 32 bit time stamps are used you'd
have a 3.2 mega bit per second data rate for just the stamps. And the
possible error in the stamp approaches the time between samples
I think a better way might be to generate some kind of time code. It could
be just a sine wave or two or a hardware nanosecond counter. Then sample
the time code. It would be best to have a hardware device that latches the
time code, then interrupts the processor and the processor reads the latch.
100Khz is a little fast for software time stamping
On Fri, Oct 21, 2016 at 1:40 AM, Attila Kinali attila@kinali.ch wrote:
On Thu, 20 Oct 2016 21:45:42 +0000
Ilia Platone info@iliaplatone.com wrote:
I will be interested to see what is recommended for a 100 kHz event
rate.
This is actually a very tough question. 100kHz means that for each
event
there is only 10µs available for detection, processing and output.
Using
a uC that would be something in the order of 1000-2000 CPU cycles. On
an
application processor (rpi and its cusins) that would be 2000 to
20'000 cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy
processing
with so few cycles.
I can use one of my boards, which have (checked better) 6MHz sampling
frequency on the GPIO, but the sysclock runs at 180MHz, this should be
enough except logging support bandwidth. check the NXP3130 uC which is
powering these boards: it's old but its dirty job is done perfectly.
[...]
These events are random photon arrivals (converted to 5vTTL pulses),
their rate was measured using the pulse width of the smaller detected,
which was 5~10 uS during an observation in low-light environment.
The photon arrival and pulse width were random with a minimum pulse
width of 10uS. What I want to do is measuring the photon arrival
precisely (low to high transition - interrupt I guess), consider that
the maximum rate would be 100Kcps because the photon events would
overlap if higher. If the 3130 controller can handle such rate it would
be great :)
The LPC3130 is IMHO the wrong choice. It does neither have capture/compare
timer units (ie units that can capture when an input event happend) nor
does it have interrupts on GPIO. Hence you would need to poll the pins
continuously while at the same time making sure that the USB port is
properly handled. This will give you a high uncertainty when the event
really happend.
I would definitely use a different board than this.
My advice would be to use one of the many high performance Cortex-M4 boards
I recently had a look at the LPC4330, which should be plenty fast for
this job. But really any other uC with an HS USB port and capture/compare
should do. Then run a minimimal OS on it (Nuttx comes to mind) to give
you the basic functionality you need without too much trouble. Upon each
event, store the value of the capture register in a ring buffer(1k-2k
large).
Read that ring buffer in the main loop and push the data out of the USB
port
in chuncks of 512byte to get maximum throughput. Use a PC to record the
data for later processing.
Attila Kinali
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
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.
--
Chris Albertson
Redondo Beach, California