[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 <attila at kinali.ch> wrote:

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