Linux PPS clues?
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
--
Malek's Law:
Any simple idea will be worded in the most complicated way.
On Thu, 20 Oct 2016 10:48:28 +0000
Ilia Platone info@iliaplatone.com 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.
On Thu, 20 Oct 2016 20:12:12 +0200
Attila Kinali attila@kinali.ch 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 attila@kinali.ch 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.
On Thursday, October 20, 2016 08:12:12 PM 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
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
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.
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
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 <info@iliaplatone.com> wrote:
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.
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.
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
On Fri, Oct 21, 2016 at 2:12 AM, Attila Kinali attila@kinali.ch 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
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 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
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.