Re: [time-nuts] Linux PPS clues?
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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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 for maybe a > second, and then stamp the block with the time. Then you can have your main > CPU figure out the time of each event by knowing the bitrate and looking at > how many bits precede each one bit back to the beginning of the block. The > blocks would likely be largely zeros, and would thus compress really well if > you decide to not even bother converting the format of the blocks to a > timestamp format. The advantage of this scheme is that it could probably have > a sampling rate far higher than a timestamping process, without overstressing > even many modestly powered processors. > > Another way to synchronize your samples with GPS, at the cost of some sample > rate, is to use a two input multiplexer at your serial input and to take > every odd bit of your serial stream to be a sample of the pps output of your > GPS and every even bit to be the state of your event trigger. That way your > pps and data are interleaved in your bitstream for post processing. > ___ > 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 for maybe a second, and then stamp the block with the time. Then you can have your main CPU figure out the time of each event by knowing the bitrate and looking at how many bits precede each one bit back to the beginning of the block. The blocks would likely be largely zeros, and would thus compress really well if you decide to not even bother converting the format of the blocks to a timestamp format. The advantage of this scheme is that it could probably have a sampling rate far higher than a timestamping process, without overstressing even many modestly powered processors. Another way to synchronize your samples with GPS, at the cost of some sample rate, is to use a two input multiplexer at your serial input and to take every odd bit of your serial stream to be a sample of the pps output of your GPS and every even bit to be the state of your event trigger. That way your pps and data are interleaved in your bitstream for post processing. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 wrote: > 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 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.
Re: [time-nuts] Linux PPS clues?
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 expectations as recently stated on this list. To ground the data I am merely providing an actual baseline for the quality of the system clock on a RasPi 3 when GPS stabilized using the techniques documented in the gpsd and ntpsec documentation. > The other half of the problem is responding to events and getting > them time stamped with very low latency and jitter. Yup, of course. I have not commented on the second part of the problem. I am enjoying the many and varied solutions being presented here. I look forward to actual implementations and hard performance data on them. > I think the best way is to copy the design of the Linux PPS > system. I'll reserve my judgement on 'best'. Since my data says the Linux kernel PPS system can reach about 1 µs standard deviation on a RasPi3 using the GPIO lines, I would expect a solution based on that would behave similarly. > Then assume the error in time stamp is a little larger > than double your graph. Ah, double which error? I give error calculations of one standard deviation, 90% percentile range, and 98% percentile range. My guess would be that any technique using the same method on the same hardware would have a similar 98% range. My 98% range on this RasPi3 is under 5 µs. I'll leave it to the OP to decide if that is good enough, easy enough, etc. You can see the live numbers here: https://pi4.rellim.com/day/ > But if the event time stamp code is not so well designed the results > might to 10X worse not just 2x worse. Once can always do things badly. :-) RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgp4TrD8A7tad.pgp Description: OpenPGP digital signature ___ 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.
Re: [time-nuts] Linux PPS clues?
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 events low cost GPS receiver has > error oon order of say a few tens of nano seconds, that is 100 to > 1000 times less error Depends on the vendor. Many only specify one standard deviation of 1 µs. And you should alway treat spec sheet numbers as besst case. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpQftaPz5GfK.pgp Description: OpenPGP digital signature ___ 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.
Re: [time-nuts] Linux PPS clues?
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's the same slope in all the signals. I'm currently searching for an active quenching circuit that fits into my application. Best Regards, Ilia. On 10/21/16 09:53, Adrian Godwin wrote: 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 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" 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 ___ 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. ___ 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. -- 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.
Re: [time-nuts] Linux PPS clues?
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 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" 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 > > > ___ > 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. > ___ 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.
Re: [time-nuts] Linux PPS clues?
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 vanish as the timestamp quantisation step size increases however the signal decreases requiring a longer observation time to achieve a given SNR. Handwaving without calculation to inform the resultant guesses is likely to result in a required observation greater than the age of the universe. This of course is impractically long. This fundamental error was made by several investigators in the some of the first attempts to do intensity interferometry. Brue On Friday, 21 October 2016 7:32 PM, Chris Albertson wrote: 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 smaller then the resolution that the linux kernel can work in. You should expect the system time to have error on the order of about 10 microseconds The PPS signal error comping out of events low cost GPS receiver has error oon order of say a few tens of nano seconds, that is 100 to 1000 times less error The major source of error is not GPS , but is the interrupt latency uncertainty. But this is not bad at all, you can expect roughly a 10 microsecond uncertainly in the time stamps more or less. But a lot depends on how you handle the second GPIO interrupt. the GPS interrupt is handled inside a kernel level handler. The handler snap shots the system clock and stores it in RAM, then sets a flag that the user space process checks.Does your GPIO interrupt have a kernel level driver to snapshot the system clock ir is this happening in a user space process? If the later expect worse performance.For best performance copy and paste the Linux PPS code and then re-build the Linux kernel with your new driver. Getting event time stamps much better then this requires some purpose built hardware outside of the computer. 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. ___ 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. -- 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.
Re: [time-nuts] Linux PPS clues?
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 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.
Re: [time-nuts] Linux PPS clues?
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. Handwaving without calculation to inform the resultant guesses is likely to result in a required observation greater than the age of the universe. This of course is impractically long. This fundamental error was made by several investigators in the some of the first attempts to do intensity interferometry. Brue On Friday, 21 October 2016 7:32 PM, Chris Albertson wrote: 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 smaller then the resolution that the linux kernel can work in. You should expect the system time to have error on the order of about 10 microseconds The PPS signal error comping out of events low cost GPS receiver has error oon order of say a few tens of nano seconds, that is 100 to 1000 times less error The major source of error is not GPS , but is the interrupt latency uncertainty. But this is not bad at all, you can expect roughly a 10 microsecond uncertainly in the time stamps more or less. But a lot depends on how you handle the second GPIO interrupt. the GPS interrupt is handled inside a kernel level handler. The handler snap shots the system clock and stores it in RAM, then sets a flag that the user space process checks. Does your GPIO interrupt have a kernel level driver to snapshot the system clock ir is this happening in a user space process? If the later expect worse performance. For best performance copy and paste the Linux PPS code and then re-build the Linux kernel with your new driver. Getting event time stamps much better then this requires some purpose built hardware outside of the computer. 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 with very low latency and jitter. In other words the harder job is actually putting to use that well sync's internal clock.I think the best way is to copy the design of the Linux PPS system.Then assume the error in time stamp is a little larger than double your graph. But if the event time stamp code is not so well designed the results might to 10X worse not just 2x worse. > How about a graph, or two? See attached. From the histogram, I suspect > the > granularity is about 200 nano sec. From the offset graph you can > see how the offset jumps. > > Here is the offset data on PPS v. the system clock: > Percentiles.. > Min 1% 5% 50% 95% 99% Max > -21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs > > Ranges.. > 90% 95% StdDev MeanUnits > 1.825 5.318 0.850 -0.006 µs > > Or see a lot more live graphs here: https://pi4.rellim.com/day/ > > > RGDS > GARY > > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/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.
Re: [time-nuts] Linux PPS clues?
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 smaller then the resolution that the linux kernel can work in. You should expect the system time to have error on the order of about 10 microseconds The PPS signal error comping out of events low cost GPS receiver has error oon order of say a few tens of nano seconds, that is 100 to 1000 times less error The major source of error is not GPS , but is the interrupt latency uncertainty. But this is not bad at all, you can expect roughly a 10 microsecond uncertainly in the time stamps more or less. But a lot depends on how you handle the second GPIO interrupt. the GPS interrupt is handled inside a kernel level handler. The handler snap shots the system clock and stores it in RAM, then sets a flag that the user space process checks.Does your GPIO interrupt have a kernel level driver to snapshot the system clock ir is this happening in a user space process? If the later expect worse performance.For best performance copy and paste the Linux PPS code and then re-build the Linux kernel with your new driver. Getting event time stamps much better then this requires some purpose built hardware outside of the computer. 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.
Re: [time-nuts] Linux PPS clues?
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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 like if you set the trigger level much higher, say half of the full voltage? One thing to try... Switch to single shot mode. Turn the room lights way down. Your eye will remember the picture for long enough. The simple solution is to get a digital scope. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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" 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 > > ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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 ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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 :) I think your 100K samples per second is going to be exciting. You can collect some data by writing some code and connecting up a signal generator. Start with a slow frequency to debug the software than turn it up and see how fast you can go. I assume it's OK if some (but not many) samples are lost. You (or I) may be confusing the data rate. There are two issues. One is the peak rate. That sounds like your 100K above. The other is the average. How many samples do you expect in a typical second? If that is low enough, you can solve the peak problem with enough buffering. My straw man would be a FPGA. The idea is to collect a batch of pulse arrival times and DMA them into memory. When the buffer fills up or a timer expires, it would finish that block and switch to the next one. You could feed a PPS to the FPGA if you want timing linked to the outside world rather than just relative times. This was the very first approach. But.. err.. I'm trying to determine more precisely the pulse width right now, so the maximum event rate. The real problem is my analogue oscilloscope that seems to lose time at peak detection: it shows a ramp at each pulse raise. If this can help, I attach a photo with the reading of my oscilloscope (2uS/div, 1V/div). not all pulses saturate, but can be detected by a CMOS input. It's difficult to sync because of the high entropy of this signal. Let me know if you can give me any hint on how to setup the oscilloscope.. 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.
[time-nuts] Linux PPS clues?
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 USB. The master counter runs at 100 Mhz (used to be 80 MHz) so the time stamps have 10 ns resolution (all that was needed for his application).The later version also decoded a GPS time stamp input for absolute timing. Alas, again, it was developed for a paying customer so he can't share the exact design... I've been trying to get him to sell a commercial version... it's a really slick and handy device. > My straw man would be a FPGA. The idea is to collect a batch of pulse arrival times and DMA them into memory. When the buffer fills up or a timer expires, it would finish that block and switch to the next one. You could feed a PPS to the FPGA if you want timing linked to the outside world rather than just relative times. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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 :) I think your 100K samples per second is going to be exciting. You can collect some data by writing some code and connecting up a signal generator. Start with a slow frequency to debug the software than turn it up and see how fast you can go. I assume it's OK if some (but not many) samples are lost. You (or I) may be confusing the data rate. There are two issues. One is the peak rate. That sounds like your 100K above. The other is the average. How many samples do you expect in a typical second? If that is low enough, you can solve the peak problem with enough buffering. My straw man would be a FPGA. The idea is to collect a batch of pulse arrival times and DMA them into memory. When the buffer fills up or a timer expires, it would finish that block and switch to the next one. You could feed a PPS to the FPGA if you want timing linked to the outside world rather than just relative times. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 wrote: 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 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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.
Re: [time-nuts] Linux PPS clues?
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 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 ___ 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.
Re: [time-nuts] Linux PPS clues?
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 Kinali 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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, 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. ___ 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.
Re: [time-nuts] Linux PPS clues?
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 averaged? Well, that is a complicated question. The graphs are directly from the ntpd logs. No modification to the data except scaling. But ntpd itself is sort of a big PLL. Also the way ntpd handles PPS is somewhat complicated. There is an algorithm for ignoring outlier pulses, and the accepted puless are averaged in the mipoll interval before being logged or input into the PLL But, bottom line, you can pretty much expect the RasPi sysclock to be stable and accurate, to one standard deviation of better than 1 µs. 90% of the time, to better than 2 µs. Better than 5.5 µs for 98% of the time. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpFo77AsTbgA.pgp Description: OpenPGP digital signature ___ 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.
Re: [time-nuts] Linux PPS clues?
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 boards should be 100ns for example, giving a maximum event rate of 5MHz. 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. Best regards, Ilia. On 10/20/16 09:59, David J Taylor wrote: 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 Kinali = Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics application. On the positive side they work very well with external devices for control and measurement, and have a huge amount of software and hardware support for a vast range of devices which makes for fast and easy development. On the negative side, certainly they are not the fastest of devices, although the current quad-core RPi3 is capable of handling thousands of messages per second, and having Ethernet over USB won't give the lowest jitter if sub-millisecond timing is important. I will be interested to see what is recommended for a 100 kHz event rate. Cheers, David -- 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.
Re: [time-nuts] Linux PPS clues?
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 Kinali = Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics application. On the positive side they work very well with external devices for control and measurement, and have a huge amount of software and hardware support for a vast range of devices which makes for fast and easy development. On the negative side, certainly they are not the fastest of devices, although the current quad-core RPi3 is capable of handling thousands of messages per second, and having Ethernet over USB won't give the lowest jitter if sub-millisecond timing is important. I will be interested to see what is recommended for a 100 kHz event rate. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ 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.
Re: [time-nuts] Linux PPS clues?
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 relatively fast processor to handle that. 200MHz would be probably the minimum with a uC, I guess 400MHz with a linux based system. > Since I don't want to fill in the list with off-topic posts, just limit > in time-related quests. > There's not any problem for the board I'll use, I referenced the > raspberry because it's well known. 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 > My questions are for the software > side and relative efficiency of the system. The software side varies with the CPU and the subsystem used. I don't know what linux offers as facility to use the timer units. A quick glance at the code didnt reveal anything. Worst case you would have to write a small driver (probably 100-200 lines of code) for it. If you want, I can ask some of my friends to see what is available for this kind of stuff. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ 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.
Re: [time-nuts] Linux PPS clues?
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. There's not any problem for the board I'll use, I referenced the raspberry because it's well known. My questions are for the software side and relative efficiency of the system. Best Regards, Ilia. On 10/20/16 08:01, Attila Kinali wrote: 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? What do you intend for granularity? Consider that I'm a newbie in frequency/time specific terms. If you are still going for the synchronization of telescopes, then you definitly don't want a rpi. Go for one of the more industrial oriented boards (the original rpi is basically just a graphics card with an attached arm processor as USB controller). Like the beaglebone, or probably even better for the Vybrid based boards (Colibry family) from Toradex (has less EMI noise than the BBB). Attila Kinali -- 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.
Re: [time-nuts] Linux PPS clues?
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? > > What do you intend for granularity? Consider that I'm a newbie in > frequency/time specific terms. If you are still going for the synchronization of telescopes, then you definitly don't want a rpi. Go for one of the more industrial oriented boards (the original rpi is basically just a graphics card with an attached arm processor as USB controller). Like the beaglebone, or probably even better for the Vybrid based boards (Colibry family) from Toradex (has less EMI noise than the BBB). 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.
Re: [time-nuts] Linux PPS clues?
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 I'm a newbie in frequency/time specific terms. Regards, Ilia. On 10/20/16 07:02, Gary E. Miller wrote: 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 check out the gpsd time howto, and ntpsec. http://www.catb.org/gpsd/gpsd-time-service-howto.html https://www.ntpsec.org I need to know how much precise this system can be. How much resolution can I obtain with a cheap receiver (maximum quantization frequency)? On average, on a RasPi 3, you can expect about Formulas are well accepted. How about a graph, or two? See attached. From the histogram, I suspect the granularity is about 200 nano sec. From the offset graph you can see how the offset jumps. Here is the offset data on PPS v. the system clock: Percentiles.. Min1% 5% 50% 95% 99% Max -21.645-2.587 -0.834 -0.020 0.991 0.991 13.557 µs Ranges.. 90%95% StdDev MeanUnits 1.825 5.318 0.850 -0.006 µs Or see a lot more live graphs here: https://pi4.rellim.com/day/ RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 ___ 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. -- 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.
Re: [time-nuts] Linux PPS clues?
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 receiver for time > reference. I need to know how much precise this system can be. How much > resolution can I obtain with a cheap receiver (maximum quantization > frequency)? Using GPIO for precision timing is the wrong approach. If you are already using an ARM processor, it is much better to use the time/capture unit to time events. These are counters which run usually with 50-200MHz giving you a resolution of 5ns to 20ns. Their advantage is that you are not limited by the interrupt latency and (mis)behaviour of the software, but handle everything in hardware. 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.
Re: [time-nuts] Linux PPS clues?
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 check out the gpsd time howto, and ntpsec. http://www.catb.org/gpsd/gpsd-time-service-howto.html https://www.ntpsec.org > I need to know how much precise this system can be. How > much resolution can I obtain with a cheap receiver (maximum > quantization frequency)? On average, on a RasPi 3, you can expect about > Formulas are well accepted. How about a graph, or two? See attached. From the histogram, I suspect the granularity is about 200 nano sec. From the offset graph you can see how the offset jumps. Here is the offset data on PPS v. the system clock: Percentiles.. Min 1% 5% 50% 95% 99% Max -21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs Ranges.. 90% 95% StdDev MeanUnits 1.825 5.318 0.850 -0.006 µs Or see a lot more live graphs here: https://pi4.rellim.com/day/ RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpxhRJtHmnX_.pgp Description: OpenPGP digital signature ___ 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.
[time-nuts] Linux PPS clues?
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 this system can be. How much resolution can I obtain with a cheap receiver (maximum quantization frequency)? Formulas are well accepted. Thanks, Ilia. ___ 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.
