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 <att...@kinali.ch> wrote: > On Thu, 20 Oct 2016 21:45:42 +0000 > Ilia Platone <i...@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 _______________________________________________ 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.