Re: [time-nuts] Linux PPS clues?

[Casey L. Jones]

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.

Re: [time-nuts] Linux PPS clues?

[bownes]

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

Re: [time-nuts] Linux PPS clues?

[Casey L. Jones]

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.

Re: [time-nuts] Linux PPS clues?

[Chris Albertson]

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  wrote:

> On Thu, 20 Oct 2016 21:45:42 +
> Ilia Platone  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
___
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.

Re: [time-nuts] Linux PPS clues?

[Gary E. Miller]

Yo Chris!

On Thu, 20 Oct 2016 23:37:23 -0700
Chris Albertson  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
g...@rellim.com  Tel:+1 541 382 8588


pgp4TrD8A7tad.pgp
Description: OpenPGP digital signature
___
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.

Re: [time-nuts] Linux PPS clues?

[Gary E. Miller]

Yo Chris!

On Thu, 20 Oct 2016 23:31:46 -0700
Chris Albertson  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
g...@rellim.com  Tel:+1 541 382 8588


pgpQftaPz5GfK.pgp
Description: OpenPGP digital signature
___
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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

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"  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"  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

___
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.

Re: [time-nuts] Linux PPS clues?

[Adrian Godwin]

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"  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"  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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

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 
 wrote:
  


  On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  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

___
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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 21:45:42 +
Ilia Platone  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.

Re: [time-nuts] Linux PPS clues?

[Bruce Griffiths]

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 
 wrote:
 

 On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  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.

Re: [time-nuts] Linux PPS clues?

[Chris Albertson]

On Thu, Oct 20, 2016 at 12:02 AM, Gary E. Miller  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  MeanUnits
> 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
> g...@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
___
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.

Re: [time-nuts] Linux PPS clues?

[Chris Albertson]

On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  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.

Re: [time-nuts] Linux PPS clues?

[Paul Boven]

Hi Gabs, everyone,

On 2016-10-21 1:53:55, Gabs Ricalde wrote:

The events can be timestamped by polling the PPS and event pins and
using the cycle counter. A better approach would be to use the 100 MHz
eCAP timers. The Beaglebone has two accessible eCAP pins, the PPS goes
to one and the event goes to the other. The counters can be synchronized
so the event timestamps can be referenced to the PPS timestamps.


This is a great idea, actually. At the moment, I'm using a BBB which I 
feed 24 MHz to tclkin, generated from a rubidium oscillator. The tclkin 
is used on run one of the dmtimers in capture mode for GPS PPS, so that 
gives about 42ns resolution. Using Dan Drown's Hardware Capture Driver 
(on Github) this 24MHz is set as the system clocksource. Works really 
well, but the 42ns resolution is a bit poor (or maybe I'm a time nut).


The eCAP runs from sysclk which I think is 200MHz on the BBB, and would 
provide 5ns resolution. Unfortunately the eCAP counter seems to only get 
input signals from the master clock, so it's not easy to provide them 
with a better input clock. But using them as a start/stop setup with the 
PPS from GPS as one input, and another PPS derived from a Rb would work 
quite nicely. In fact, that division by 24e6 from the Rubidium could 
probably be done by a second dmtimer also clocked from tclkin, keeping 
the parts count low.


Does that sound feasible?

Regards, Paul Boven.






___
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.

Re: [time-nuts] Linux PPS clues?

[Hal Murray]

i...@iliaplatone.com said:
> 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. 

The first one looks like you are triggering on noise or runt pulses.  What 
does it look like if you set the trigger level much higher, say half of the 
full voltage?

One thing to try...  Switch to single shot mode.  Turn the room lights way 
down.  Your eye will remember the picture for long enough.

The simple solution is to get a digital scope.


-- 
These are my opinions.  I hate spam.



___
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.

Re: [time-nuts] Linux PPS clues?

[Scott Stobbe]

I'm not sure if you were asking for scope adive or not, but to look for the
minimum seperation (also runt pulses) you would want to set your trigger
threshold as low as possible without false triggering on noise, and set
trigger hold off to a minimum.

National Instruments has lots of litteriture on this topic which may be
helpful, timestamping events with 10's of ns of resolution. NI
Timer/counters http://sine.ni.com/nips/cds/view/p/lang/en/nid/4529

On Thursday, 20 October 2016, Ilia Platone  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"  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.

Re: [time-nuts] Linux PPS clues?

[Gabs Ricalde]

On Fri, Oct 21, 2016 at 2:12 AM, Attila Kinali  wrote:
>
> 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.
>

The TI AM335x (used in the Beaglebone) has a Programmable Realtime Unit
(PRU), a 200 MHz microcontroller separate from the ARM CPU. I have used
this to decode a 192 kHz SPDIF signal (12 Mbit/s biphase mark code). The
samples are batched in the PRU SRAM, an interrupt is triggered
periodically, then a userspace program in the ARM Linux side reads the
samples from the SRAM.

The events can be timestamped by polling the PPS and event pins and
using the cycle counter. A better approach would be to use the 100 MHz
eCAP timers. The Beaglebone has two accessible eCAP pins, the PPS goes
to one and the event goes to the other. The counters can be synchronized
so the event timestamps can be referenced to the PPS timestamps.

Some PRU resources:
- https://www.youtube.com/watch?v=plCYsbmMbmY
- Slides: 
http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf
- http://exploringbeaglebone.com/chapter13/
- The eCAP and PRU-ICSS parts of the AM335x technical reference manual
___
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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

On 10/20/16 22:08, Hal Murray wrote:

i...@iliaplatone.com said:

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 :)

I think your 100K samples per second is going to be exciting.

You can collect some data by writing some code and connecting up a signal
generator.  Start with a slow frequency to debug the software than turn it up
and see how fast you can go.

I assume it's OK if some (but not many) samples are lost.

You (or I) may be confusing the data rate.  There are two issues.  One is the
peak rate.  That sounds like your 100K above.  The other is the average.  How
many samples do you expect in a typical second?  If that is low enough, you
can solve the peak problem with enough buffering.

My straw man would be a FPGA.  The idea is to collect a batch of pulse
arrival times and DMA them into memory.  When the buffer fills up or a timer
expires, it would finish that block and switch to the next one.  You could
feed a PPS to the FPGA if you want timing linked to the outside world rather
than just relative times.

This was the very first approach. But.. err.. I'm trying to determine 
more precisely the pulse width right now, so the maximum event rate. The 
real problem is my analogue oscilloscope that seems to lose time at peak 
detection: it shows a ramp at each pulse raise.
If this can help, I attach a photo with the reading of my oscilloscope 
(2uS/div, 1V/div). not all pulses saturate, but can be detected by a 
CMOS input. It's difficult to sync because of the high entropy of this 
signal.

Let me know if you can give me any hint on how to setup the oscilloscope..



Best Regards,
Ilia.

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

Re: [time-nuts] Linux PPS clues?

[Hal Murray]

i...@iliaplatone.com said:
> 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 :) 

I think your 100K samples per second is going to be exciting.

You can collect some data by writing some code and connecting up a signal 
generator.  Start with a slow frequency to debug the software than turn it up 
and see how fast you can go.

I assume it's OK if some (but not many) samples are lost.

You (or I) may be confusing the data rate.  There are two issues.  One is the 
peak rate.  That sounds like your 100K above.  The other is the average.  How 
many samples do you expect in a typical second?  If that is low enough, you 
can solve the peak problem with enough buffering.

My straw man would be a FPGA.  The idea is to collect a batch of pulse 
arrival times and DMA them into memory.  When the buffer fills up or a timer 
expires, it would finish that block and switch to the next one.  You could 
feed a PPS to the FPGA if you want timing linked to the outside world rather 
than just relative times.

-- 
These are my opinions.  I hate spam.



___
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.

Re: [time-nuts] Linux PPS clues?

[Bruce Griffiths]

10us deadtime is somewhat excessive for average detection rates much greater 
than 1kcps (kilo counts/sec).Higher rates will tend to have the correlations 
between detectors suppressed. This will be particulalrly acute for Intensity 
correlations.Active detector (Geiger mode APD) quenching is probably advisable.
Bruce  

On Friday, 21 October 2016 10:45 AM, Ilia Platone  
wrote:
 

 

On 10/20/16 18:12, Attila Kinali wrote:
> On Thu, 20 Oct 2016 10:59:21 +0100
> "David J Taylor"  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.
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.
> 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.
yes.
> For better answers, I would need to know what kind of events these are
> and what exactly need to be done/measured.
>
>             Attila Kinali
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 :)

Best Regards,
Ilia.

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

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

On 10/20/16 18:12, Attila Kinali wrote:

On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor"  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.
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.

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.

yes.

For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.

Attila Kinali
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 :)


Best Regards,
Ilia.

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

Re: [time-nuts] Linux PPS clues?

[Bruce Griffiths]

On Thursday, October 20, 2016 08:12:12 PM Attila Kinali wrote:
> On Thu, 20 Oct 2016 10:59:21 +0100
> 
> "David J Taylor"  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
The fly in the ointment so to speak is that the events in question (photon 
arrival times) are random.
The average rate is up to around 100KHz or so but they are not uniformly 
spaced in time.

Bruce 
___
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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 20:12:12 +0200
Attila Kinali  wrote:

> 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).

On Thu, 20 Oct 2016 20:18:05 +0200
Attila Kinali  wrote:

> For 5MHz event rate, you will need specialized hardware (either
> something on the uP or an FPGA) to do the heavy lifting and provide
> a stream of badged data to the processor.


Err.. this should read "batches" resp "batched" in both mails... 
Sorry for the confusion.

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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 10:48:28 +
Ilia Platone  wrote:

> the only essential task is sampling and logging into an usb drive. the 
> timestamps must be as accurate as possible with the GPS reference clock. 
> This for an undefined number of devices.

What kind of events are they, what do you need to do with them and 
what do you want to store?


> Since this 100KHz is a starting point, I must know how fast can be the 
> event rate. Linux Clock tick on some boards should be 100ns for example, 
> giving a maximum event rate of 5MHz.

For 5MHz event rate, you will need specialized hardware (either
something on the uP or an FPGA) to do the heavy lifting and provide
a stream of badged data to the processor.


> I must only ensure if the kpps/gpsd system can have a good accuracy for 
> 5-8 hours. I own a dozen of the Glomation sbc3130s boards (100MHz / 
> 12MHz GPIO speed / NXP3130 uC). If these boards can do this work, I'd be 
> happy.

They probably can, but also probably not the way you imagine.
Running linux, they will only have enough power to pipe the data
through if you have 5Mevent/s. Even 100kevent/s will be a bit
difficult, depending on what needs to be done. If you don't run
linux on those, then they should have plenty of processing power
to do almost everything you want, unless you want 5Mevent/s.


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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor"  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


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

Re: [time-nuts] Linux PPS clues?

[Gary E. Miller]

Yo Ilia!

On Thu, 20 Oct 2016 07:52:10 +
Ilia Platone  wrote:

> I quickly read the gpsd howto and it explains what I want to do using 
> kpps on a raspberry. From there I can see a typical accuracy of 1uS,
> but the informations of the live graphs page are precise down to the
> ns: are these averaged?

Well, that is a complicated question.  The graphs are directly from the
ntpd logs.  No modification to the data except scaling.  But ntpd
itself is sort of a big PLL.  Also the way ntpd handles PPS is somewhat
complicated.  There is an algorithm for ignoring outlier pulses, and the
accepted puless are averaged in the mipoll interval before being
logged or input into the PLL

But, bottom line, you can pretty much expect the RasPi sysclock to be
stable and accurate, to one standard deviation of better than 1 µs. 90%
of the time, to better than 2 µs.  Better than 5.5 µs for 98% of the
time.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpFo77AsTbgA.pgp
Description: OpenPGP digital signature
___
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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

the only essential task is sampling and logging into an usb drive. the 
timestamps must be as accurate as possible with the GPS reference clock. 
This for an undefined number of devices.


Since this 100KHz is a starting point, I must know how fast can be the 
event rate. Linux Clock tick on some boards should be 100ns for example, 
giving a maximum event rate of 5MHz.


I must only ensure if the kpps/gpsd system can have a good accuracy for 
5-8 hours. I own a dozen of the Glomation sbc3130s boards (100MHz / 
12MHz GPIO speed / NXP3130 uC). If these boards can do this work, I'd be 
happy.


Best regards,
Ilia.

On 10/20/16 09:59, David J Taylor wrote:

From: Attila Kinali

[]
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
[]

Attila Kinali
=

Actually, of the 15 Raspberry Pi cards I have only one is used in a 
graphics application.


On the positive side they work very well with external devices for 
control and measurement, and have a huge amount of software and 
hardware support for a vast range of devices which makes for fast and 
easy development.  On the negative side, certainly they are not the 
fastest of devices, although the current quad-core RPi3 is capable of 
handling thousands of messages per second, and having Ethernet over 
USB won't give the lowest jitter if sub-millisecond timing is important.


I will be interested to see what is recommended for a 100 kHz event rate.

Cheers,
David


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

Re: [time-nuts] Linux PPS clues?

[David J Taylor]

From: Attila Kinali

[]
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
[]

Attila Kinali
=

Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics 
application.


On the positive side they work very well with external devices for control 
and measurement, and have a huge amount of software and hardware support for 
a vast range of devices which makes for fast and easy development.  On the 
negative side, certainly they are not the fastest of devices, although the 
current quad-core RPi3 is capable of handling thousands of messages per 
second, and having Ethernet over USB won't give the lowest jitter if 
sub-millisecond timing is important.


I will be interested to see what is recommended for a 100 kHz event rate.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 08:15:03 +
Ilia Platone  wrote:

> Actually the system for timestamping is at design stage yet.
> I expect an event rate of about 100kcps, but I found little infos about 
> the bandwidth variable for the receivers.

100kHz event rate is quite a bit. You will need a relatively fast
processor to handle that. 200MHz would be probably the minimum
with a uC, I guess 400MHz with a linux based system.


> Since I don't want to fill in the list with off-topic posts, just limit 
> in time-related quests.
> There's not any problem for the board I'll use, I referenced the 
> raspberry because it's well known. 

Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O


> My questions are for the software 
> side and relative efficiency of the system.

The software side varies with the CPU and the subsystem used.
I don't know what linux offers as facility to use the timer
units. A quick glance at the code didnt reveal anything.
Worst case you would have to write a small driver (probably
100-200 lines of code) for it.

If you want, I can ask some of my friends to see what is available for
this kind of stuff.

Attila Kinali


-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

Thank you Attila :)

Actually the system for timestamping is at design stage yet.
I expect an event rate of about 100kcps, but I found little infos about 
the bandwidth variable for the receivers.


Since I don't want to fill in the list with off-topic posts, just limit 
in time-related quests.
There's not any problem for the board I'll use, I referenced the 
raspberry because it's well known. My questions are for the software 
side and relative efficiency of the system.


Best Regards,
Ilia.

On 10/20/16 08:01, Attila Kinali wrote:

On Thu, 20 Oct 2016 07:52:10 +
Ilia Platone  wrote:


I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but
the informations of the live graphs page are precise down to the ns: are
these averaged?

What do you intend for granularity? Consider that I'm a newbie in
frequency/time specific terms.

If you are still going for the synchronization of telescopes, then
you definitly don't want a rpi. Go for one of the more industrial
oriented boards (the original rpi is basically just a graphics card with
an attached arm processor as USB controller). Like the beaglebone,
or probably even better for the Vybrid based boards (Colibry family)
from Toradex (has less EMI noise than the BBB).

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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 07:52:10 +
Ilia Platone  wrote:

> I quickly read the gpsd howto and it explains what I want to do using 
> kpps on a raspberry. From there I can see a typical accuracy of 1uS, but 
> the informations of the live graphs page are precise down to the ns: are 
> these averaged?
> 
> What do you intend for granularity? Consider that I'm a newbie in 
> frequency/time specific terms.

If you are still going for the synchronization of telescopes, then
you definitly don't want a rpi. Go for one of the more industrial
oriented boards (the original rpi is basically just a graphics card with
an attached arm processor as USB controller). Like the beaglebone,
or probably even better for the Vybrid based boards (Colibry family)
from Toradex (has less EMI noise than the BBB).

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.

Re: [time-nuts] Linux PPS clues?

[Ilia Platone]

Thank you.

I quickly read the gpsd howto and it explains what I want to do using 
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but 
the informations of the live graphs page are precise down to the ns: are 
these averaged?


What do you intend for granularity? Consider that I'm a newbie in 
frequency/time specific terms.


Regards,
Ilia.



On 10/20/16 07:02, Gary E. Miller wrote:

Yo Ilia!

On Thu, 20 Oct 2016 06:15:39 +
Ilia Platone  wrote:


I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference.

You should check out the gpsd time howto, and ntpsec.

http://www.catb.org/gpsd/gpsd-time-service-howto.html

https://www.ntpsec.org


I need to know how much precise this system can be. How
much resolution can I obtain with a cheap receiver (maximum
quantization frequency)?

On average, on a RasPi 3, you can expect about


Formulas are well accepted.


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..
 Min1%  5%  50% 95% 99% Max
 -21.645-2.587  -0.834  -0.020  0.991   0.991   13.557 µs

 Ranges..   
 90%95% StdDev  MeanUnits
 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
g...@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/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.

Re: [time-nuts] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 06:15:39 +
Ilia Platone  wrote:

> I need some clues on the Linux PPS subsystem.
> I am trying to take some timestamps of events on a GPIO using an ARM 
> SBC, and noticed that the kernel linux can be interfaced to a PPS 
> signal, wanted to sync another GPIO to a GPS receiver for time 
> reference. I need to know how much precise this system can be. How much 
> resolution can I obtain with a cheap receiver (maximum quantization 
> frequency)?

Using GPIO for precision timing is the wrong approach. If you are
already using an ARM processor, it is much better to use the time/capture
unit to time events. These are counters which run usually with 50-200MHz
giving you a resolution of 5ns to 20ns. Their advantage is that you are
not limited by the interrupt latency and (mis)behaviour of the software,
but handle everything in hardware.

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.

Re: [time-nuts] Linux PPS clues?

[Gary E. Miller]

Yo Ilia!

On Thu, 20 Oct 2016 06:15:39 +
Ilia Platone  wrote:

> I am trying to take some timestamps of events on a GPIO using an ARM 
> SBC, and noticed that the kernel linux can be interfaced to a PPS 
> signal, wanted to sync another GPIO to a GPS receiver for time 
> reference.

You should check out the gpsd time howto, and ntpsec.

http://www.catb.org/gpsd/gpsd-time-service-howto.html

https://www.ntpsec.org

> I need to know how much precise this system can be. How
> much resolution can I obtain with a cheap receiver (maximum
> quantization frequency)?

On average, on a RasPi 3, you can expect about

> Formulas are well accepted.


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  MeanUnits
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
g...@rellim.com  Tel:+1 541 382 8588


pgpxhRJtHmnX_.pgp
Description: OpenPGP digital signature
___
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.