[time-nuts] Linux PPS clues?
albertson.chris at gmail.com
Fri Oct 21 22:31:33 EDT 2016
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
> > > This is actually a very tough question. 100kHz means that for each
> > > there is only 10µs available for detection, processing and output.
> > > a uC that would be something in the order of 1000-2000 CPU cycles. On
> > > 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
> > > 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
> Read that ring buffer in the main loop and push the data out of the USB
> 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/
> and follow the instructions there.
Redondo Beach, California
More information about the time-nuts