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.
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
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 fo
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 bette
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
expec
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 eve
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
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 previou
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 v
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
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. Han
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 w
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
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 goe
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 l
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 o
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
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
Yes, and it can be quite easy to do. A friend whipped one out in day. Has
16 inputs (used to be 8 inputs) and time stamps any selected edge transition
and queues up the time stamp counter/channel values which get written into a
bigger RAM buffer queue which gets periodically dumped out via
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 m
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 proba
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
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 co
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
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 t
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, th
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 a
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 b
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 Kina
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 relativel
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.
Th
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?
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
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 receiv
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
Hi all,
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
36 matches
Mail list logo
