Recommended Test Equipment For Timing of Long Trigger Chain  - Page 1
Forum section: electronics / projects

author: ckruhagu
author_rank: Contributor
timestamp: May 29, 2025, 05:51:08 am
content: Hi there.For my application I have a custom unit that generates trigger pulses (5 V, 100 us width) at modest frequencies (10-500 Hz) over a long period of time (hours to days).What I need to do is assess the uniformity of the trigger pulse chain.This is relatively easy to do over a very short period of time using my Rigol oscilloscope, but the issue is that I want to know the pulse jitter to the nearest microsecond, but due to the relatively low frequency when I zoom out the scope loses timing resolution and so the precision of the jitter measurement drops off. Furthermore, I want to know the jitter across multiple oscilloscope grabs, and as far as I can tell the scope simply isn't able to do this sort of thing.So I wanted to ask the forum, if presented with this test and measurement situation, how would you do it?I'll rephrase the problem one last time: measure the jitter to the nearest us of a 10-500 Hz pulse train over hours to days of time.Any suggestions?My first thought was to capture data to the PC, but the timing precision of the USB capture hardware that I have is really limited to ms precision, it certainly can't read over USB and log a value every 1/2 us, which would be the minimum required. As a quick estimate, 1/2 us readings, double precision (8 bytes), would be a 16 MB/s data stream (approximately).So it would have to be high speed acquisition to the PC, for post analysis in software (no problem) or some kind of capture device with on board storage that can hold a 16 MB/s data stream for at least 12 hours (700 GB give or take).Any ideas? Thank you!

author: 2N3055
author_rank: Super Contributor
timestamp: May 29, 2025, 07:06:26 am
content: Quote from: ckruhagu on May 29, 2025, 05:51:08 amWhat are you exactly measuring?- width of the pulse with variable repetition (cca 100µs , repeating 10-500Hz)- trigger pulse chain ? measuring some reaction time from one point to other?- When variable repetition frequency is set, how stable it is (10-500Hz)Any of those can be easily measured with scope that has decent memory and statistics.Some scopes can even do histogram of distribution of data.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 29, 2025, 09:31:04 am
content: Quote from: ckruhagu on May 29, 2025, 05:51:08 amYou can slash the storage by sending edge+timestamp pairs, there was another recent thread where I linked to a Pi PICO solution that captured pins and timestamps.https://www.eevblog.com/forum/projects/generating-standard-pulse-from-list-of-periods-with-off-the-shelf-equipment/msg5922322/#msg5922322

author: ckruhagu
author_rank: Contributor
timestamp: May 29, 2025, 11:47:56 am
content: I want to measure trigger pulse leading edge time. This can be relative to the pulse before it, or relative to global time. Assume that the pulses are perfect square with a perfect rising edge. At these timescales (us) with good impedance matching and a strong line driver they are.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 29, 2025, 07:27:31 pm
content: The pi PICO has a standard crystal so I’d suggest you also feed in a 1pps signal from a GPS module then your PC side can use the two signal edges times to correct crystal errors and work to absolute GPS time.

author: ckruhagu
author_rank: Contributor
timestamp: May 29, 2025, 08:31:06 pm
content: Thank you for the suggestion. The problem is that microcontroller oscillator time is not stable enough over hours of wall time. You are correct that GPS time would be one way to tackle that, but I am sceptical that it can provide us timing precision.Any other ideas?

author: ckruhagu
author_rank: Contributor
timestamp: May 29, 2025, 08:32:46 pm
content: "Any of those can be easily measured with scope that has decent memory and statistics.Some scopes can even do histogram of distribution of data."Any scope can do this for the waveform captured on screen, yes.But I need the timing data across multiple waveforms. I am also after the timing data across hundreds of thousands of waveforms.Any ideas on how to capture that?

author: 2N3055
author_rank: Super Contributor
timestamp: May 29, 2025, 08:49:35 pm
content: Quote from: ckruhagu on May 29, 2025, 08:32:46 pmIt can gather statistics across hundreds of thousands of triggers.....If you have a reference pulse and one you want to compare you can do that with a scope...But honestly even after your explanation I still don't understand what signals and relations you want to measure.Your explanaitions are too vague for me to understand.

author: PlainName
author_rank: Super Contributor
timestamp: May 29, 2025, 08:59:59 pm
content: Do you need to capture every single pulse, or can you make do with a repeating sample set of pulses at some frequency and ignore the intervening ones?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 29, 2025, 09:17:15 pm
content: Quote from: ckruhagu on May 29, 2025, 08:31:06 pmThe GPS is easily better than 1us, and it gives you a calibrate every second check on your slow crystal drift.If you want 1us, that's 1ppm over 1 second, so your crystal (or whole Pi PICO module ) needs to be kept thermally stable to drift less than 1ppm/second. That's likely doable.Or you can command the GPS module to output a faster pulse, say 10Hz, which can be sampled > 10MHz by the Pi PICO2 for 1ppm, but now you can track 1ppm/100ms drifts and calibrate to 0.1ppm every second.Or, depending on GPS module, you may be able to command 12MHz out and re-wire that to drive the Pi PCIO Xtal pin for a simple GPSDO.Not all GPS modules can do 12MHz, some examples herehttps://portal.u-blox.com/s/question/0D52p0000Dvnnd6CQA/time-pulse-output-specs-at-high-frequencyor TCXO are another price point, examples at Mouser, sub $2FT2MHUPM12.0-T1ATX-H12-F-12.000MHz-F25-TThese are 12MHz, wide Vcc, ±2.5PPM -40 to +85°C 2520 that could be wired in to (significantly) upgrade the PICO osc.Or you can add a OCXO or TCXO to the Pi PICO2 - 12MHz are rare, so you need higher and divider.At this level, the GPS 1pps is more optional. What you measure will likely be far worse.A quick scan finds 48MHz ECOC-9775-48.000-DN-TR LVCMOS 3.3V +/-20ppb -40C - 85C 9.7 x 7.5 mm for under $40 - just add /4 logic.

author: elbucki
author_rank: Newbie
timestamp: May 29, 2025, 09:41:39 pm
content: I've had luck with the Picoscope 2206B and streaming the data using the Pico SDK. Every half second or so, dump the data and write a quick script to look for pulses and save the timestamps. It can stream so you won't lose any data between chunks.

author: tggzzz
author_rank: Super Contributor
timestamp: May 29, 2025, 10:17:07 pm
content: Quote from: ckruhagu on May 29, 2025, 08:31:06 pmI'm not convinced you understand how to characterise clocks. To start, there is a difference between accuracy and stability.There are many types of clock circuits used for microprocessors, with varying characteristics. If you can't find one with suitable characteristics, then use an external oscillator that meets your requirements. If you can't define your requirements, then it doesn't matter what you use.Alternatively build a circuit consisting of your clock, a long counter, a register, and any old MCU. When an input edge occurs, capture the count in the register, and inform the MCU that there is a new value to be read and processed.

author: DaJMasta
author_rank: Super Contributor
timestamp: May 30, 2025, 03:00:52 pm
content: There are probably a number of scopes that can do it fine, but it sounds like you could use a frequency counter. The high stability time base could be helpful and they're sort of built for long duration measurements.

author: ckruhagu
author_rank: Contributor
timestamp: May 30, 2025, 03:48:30 pm
content: I am sorry if I did not explain the situation to everyone's satisfaction. Please allow me to try again.The project is a university physics research project. Our budget is not unlimited. While what we are trying to do may not make sense to you, please just accept that this is what we are trying to measure. I don't think it makes any sense bogging down or distracting the discussion by explaining why we are doing this, though I'm happy to talk about it once we have found a solution.A custom generator is producing square trigger pulses (100 us wide, strong rising edge, 5V Vtop) at low repetition rate, let's just peg this at 10 Hz, or 100 ms between pulses.We are not concerned about the shape of the pulses at all, it is only the arrival time of the rising edge that matters.We want a way to measure the pulse to pulse time of every trigger pulse to the nearest us over a long period of time, e.g. 12 hours.We need to account for every single pulse, so at 10 Hz over 12 hours we have 432000 pulses, which isn't a big number. But it is possible that only a single pulse in this train falls at the wrong time (e.g. 3 us too early or late) which is why it is a challenge to measure.The problem with using a regular oscilloscope is that to see multiple pulses you have to zoom out in time, which decreases the time resolution of the waveform and resulting analysis of the pulse to pulse timing. So yes you can hit "measure" on the scope and it will give you the frequency (or time between) of the pulses shown on screen, but it is not accurate enough because when zooming out to capture 1 s of time, for example which would show 10 pulses, at that time scale the sampling time is too large to capture a reading every 1/2 us, which is needed to determine the trigger to trigger time to the nearest us. Zooming in helps with the sampling time, but we now lose pulse to pulse timing as we can only see so many pulses on screen, not to mention that the waveform to waveform behaviour is undefined, we don't know if there is a timing gap there and from testing the built in analysis tools do not do anything across multiple waveforms.So that is the main additional complication, the oscilloscope won't typically measure trigger to trigger times across multiple waveforms. This is what stops us from just zooming in and looking at a single pulse. In this configuration the scope does not tell you the trigger to trigger time, though if there was a way to get the scope to "spit out" trigger times over USB then that would also be a good option.Our current hardware is a Rigol MSO5000 series oscilloscope, but we have a Picoscope 2206A (the comment above about streaming all of the Picoscope data is well taken and we will revisit this) as well as a wide range of USB data acquisition devices. We have a small budget to buy new equipment, but it is really unclear what exactly will do what we need. We thought the oscilloscope would do it, but for the reasons outlined above, it just seems like the wrong tool for the job.All suggestions will be well received, thank you in advance.

author: 2N3055
author_rank: Super Contributor
timestamp: May 30, 2025, 05:50:36 pm
content: Quote from: ckruhagu on May 30, 2025, 03:48:30 pmThank you for very detailed explanation. I think I understand now.You have to measure interval between 100µs wide pulses that repeat some 100ms apart, over long period.You need to measureevery single oneand save a timestamp and pulse interval measured.That info needs to be presented for statistical analysisYou need something like this :https://www.febo.com/pages/TICC/

author: julian1
author_rank: Frequent Contributor
timestamp: May 30, 2025, 09:09:31 pm
content: Perhaps use a mcu peripheral timer (externally clocked), or small fpga, to log/record the pulse events against an incrementing clk count, from an external high-stability clk source (eg gpsdo)?Probably some niche market product already exists.But the effort needed to interface to it, and extract data, is likely to be about the same as developing the feature on a generic dev board.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 30, 2025, 10:22:45 pm
content: Quote from: ckruhagu on May 30, 2025, 03:48:30 pmSo you have a fixed generator, that you suspect has a flaw and does not really do 100.0000msall the time.Sometimes(rarely) it is slightly (some us) early or late. That detail is what you want to capture.If the generator is always running, and at a known fixed rate, things are much simpler.The link I gave earlier uses a Pi PICO at 62.5ns update rates, and sends 32 bit port change and 32 bit time captures from the PIO to the PICO corehttps://j-hui.com/publications/hui2023timestamp.pdfSo it is a more general and flexible solution than you need, but looks well documented, and is likely to be useful in any physics lab.Your example 3us wrong-un at 100ms is 30ppm, and a 10MHz(100ns) clock will resolve to 1ppm, every 100ms.Crystal drift will be comfortably less than 1ppm/100ms, so you can reject any slow changes to the capture and trigger only on some step change.Almost any MCU with a crystal could actually manage this, avoid ones with ceramic resonators (many ardunios)Even a 16 bit capture would be ok in this example case, for example at 20MHz, 100ms advances the lower 16 bits by 0x8480, and a 1 digit change/drift is 0.5ppmA tcxo would be better, and a OCXO even better for absolute long term precision, but your problem is not slow drift, it is errant steps timing.Someone must make a Pi PICO module with a TCXO, surely? (It seems you can directly connect 12MHz if you are ok with SMD removal & soldering)

author: PlainName
author_rank: Super Contributor
timestamp: May 30, 2025, 11:31:27 pm
content: Don't scopes have a go-nogo thing? Kind of like an eye chart. So you set up the mask for a good pair of pulses, including tolerance, and then trigger a pair falls outside of that.Keysight example:https://www.keysight.com/us/en/product/M9240MSKA/mask-limit-testing-software-m924xa-series-oscilloscopes.htmlYou don't need to record all the ones that aren't a fail.

author: Someone
author_rank: Super Contributor
timestamp: May 31, 2025, 01:11:54 am
content: Quote from: PlainName on May 30, 2025, 11:31:27 pmwill not capture 100% of the pulses. This all sounds eerily similar to a previous project/boss i worked with: “we need 100% coverage of arrival times with less than 1us of integral error” but then they added without using gps (rf denied environment) and operating for months on a tiny energy budget.I'm not familiar with any off the shelf/packaged instrumentation device which will provide what the OP is asking for without resorting to massive overkill $xx,000 solutions. Cheapest route would probably be some custom fpga or micro solution as has been throughly explored already in this thread.

author: Smokey
author_rank: Super Contributor
timestamp: May 31, 2025, 01:23:42 am
content: You want a time interval analyzer.

author: 2N3055
author_rank: Super Contributor
timestamp: May 31, 2025, 07:48:46 am
content: Quote from: Smokey on May 31, 2025, 01:23:42 amYes. A timestamping time-interval counter/analyzer.But he cannot afford Pendulum or such..Hence my answer here:Quote from: 2N3055 on May 30, 2025, 05:50:36 pm

author: ckruhagu
author_rank: Contributor
timestamp: May 31, 2025, 08:15:38 am
content: Thank you everyone for the suggestions, I feel we are now on the right track and looking at the right sort of equipment for the job."But he cannot afford Pendulum or such.."This is correctThe Febo project looks good, we'll see if we can get one and try it out.

author: Someone
author_rank: Super Contributor
timestamp: May 31, 2025, 08:29:09 am
content: Quote from: PCB.Wiz on May 30, 2025, 10:22:45 pmTo be no worse than 1us off (nearest microsecond as in the first post) the drift over time such as hours does still need to be considered and not just over the short term, unless there is some external source to discipline against.Ran up a proof of concept here and watched the ppm level wander from warm up of the instruments, likely worse on the MSO5000 the OP has. After thermal stabilisation in a good experimental physics lab it may well be acceptable but if certainty is needed then as you say an OCXO is the tool for the job. A cheap GPSDO could even be cost effective within the system.

author: voltsandjolts
author_rank: Unknown
timestamp: May 31, 2025, 09:55:49 am
content: Quote from: ckruhagu on May 31, 2025, 08:15:38 amYou could try posting in the Buy/Sell/Wanted section here.Quite often this forum pulls rabbits out of hats.

author: Smokey
author_rank: Super Contributor
timestamp: May 31, 2025, 06:50:38 pm
content: Quote from: ckruhagu on May 31, 2025, 08:15:38 amRent the equipment. Or buy something HP-like off ebay and then sell it again when you are done. It's not that much. If I was doing a legit university research experiment that I planned on publishing and I had arduinos on breadboards doing critical timing analysis, I would have a hard time taking any of it seriously.See the other thread that's going on with this type of question. Is this the university of Phoenix? Are you saying there is no one in the university EE department that you can talk to about this? Are you saying the EE department is unwilling to loan the physics department a piece of equipment that can do time interval analysis? How long do you expect your experiment to be set up and need the analyzer?

author: DaJMasta
author_rank: Super Contributor
timestamp: May 31, 2025, 08:54:43 pm
content: I haven't been checking recently, but used CNT-90 rebadges (tek FCA3000 series and fluke PM6690) have been as low as $300 or so in the US.If you want ease of setup and immediate access to statistics, i can heartily recommend a CNT-90, PM6690, or FCA3000 - statistics available on instrument, fantastic performance, high stability, and lots of connectivity for other logging or control.Older HP/Agilent 51312 and similar counters would do a good job as well, but no graphical display (and losing that great on-instrument analysis display) and likely only legacy connectivity (gpib, rs232.)

author: MarkL
author_rank: Unknown
timestamp: May 31, 2025, 10:02:11 pm
content: Another possible approach for time-interval capture is to use a logic analyzer.HP/Agilent/Keysight logic analyzers support a mode they call "transitional timing" which only records data when there is a transition on a data input. To reconstruct the original waveform, a timestamp is also recorded at the same time. This is expressly for capturing infrequent events with high timing resolution typically ranging from a few nanoseconds of resolution and a duration of hours or days, depending on the specific model. Some of the older cards can support 32M or 64M events, which would cover your needs.A logic analyzer can also capture multiple pulse inputs at the same time, which you stated as another of your requirements.One thing not provided on these systems (at least the older ones) is a reference clock input, so the timestamp would be subject to the quality of oscillator in the analyzer. One way to compensate for this is to have one of the data inputs be a high accuracy clock, which could be compared to the captured timestamp and used to adjust the offset of the timestamp (assuming slow variations) in a post-process. You could also hack the clocking circuits in the analyzer itself, but you're probably not looking for a sub-project.Specifically, I think a used Agilent 16700 series chassis with a 16752A or 16756A analyzer module would suffice, but there are plenty of other combinations of chassis and modules that would also work. I'm sure Tektronix and probably other vendors have similar offerings.

author: Someone
author_rank: Super Contributor
timestamp: June 01, 2025, 12:06:14 am
content: Quote from: DaJMasta on May 31, 2025, 08:54:43 pmAre you sure they can measure every same direction edge-edge pair? My understanding was they did not support overlapping arming and measurement.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 01, 2025, 12:47:24 am
content: Quote from: DaJMasta on May 30, 2025, 03:00:52 pmYes, given the OP has since added they only needrising edge checks, and only hundreds of reports a second, that is in the realm of a moderate counter.As you say, they are likely to be built with a better time base.In simplest form, it needs to measure Period, and report that to some host PC.If the OP has building skills, that is even doable with a handful of Logic chips and no code lines at all.(TCXO/OCXO+SN74LV8154 counter + logic parts eg HC4060, HC138, HC74, HEF4017 etc)That logic can output 4 bytes UART binary info at 3MBd on each rising edge.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 01, 2025, 12:51:37 am
content: Quote from: Someone on June 01, 2025, 12:06:14 amGood point, an important detail to check.

author: Someone
author_rank: Super Contributor
timestamp: June 01, 2025, 01:54:02 am
content: Quote from: PCB.Wiz on June 01, 2025, 12:51:37 amJust what is actually required to be collected significantly changes the requirements, in roughly increasing complexity/cost:Checking no pulse pairs arrived outside some boundsTime stamping when a pulse pair arrived outside some boundsCollecting all pulse pairs in a histogramTimestamping all pulse edgesInspecting all edge to edge timings is already hard which is where this thread started (since no? oscilloscope can do that on its own). Alongside issues of exactly what (absolute) accuracy is required in reference to what other timeframes (very common mistakes for people unfamiliar with precision timing).I've seen the problem the OP describes with scientific apparatus where thedevelopersmoneys at typewriters rely on software to do timing without realising that it its not guaranteed, but for most/all end users that is not a problem so is just hand waved away or never noticed. But for the OP they believe it is a problem, and wont discuss why or other solutions. Want something unusual and complex? oh thats going to be expensive one way or another.

author: fourfathom
author_rank: Super Contributor
timestamp: June 01, 2025, 03:28:37 am
content: Quote from: ckruhagu on May 31, 2025, 08:15:38 amYou can usually buy one from TAPR:https://tapr.org/product/tapr-ticc/, but it's currently out of stock. I think we have ordered more boards (I'm on the TAPR board of directors). I have one of the TICCs, and it definitely works as advertised.A few years ago I made my own time interval counter with event logging, having a 10ns resolution (using a 100 MHz clock, locked to an external GPSDO or OCXO reference). It does stuff the TICC doesn't, but for your needs I think the TICC would be ideal.

author: joseangel
author_rank: Contributor
timestamp: June 01, 2025, 07:25:03 am
content: Quote from: ckruhagu on May 30, 2025, 03:48:30 pmMy daily work is also related to Physics, designing electronics for high speed gamma detectors. The problem you state is quite common in the field, on different time scales. I guess you have abstracted the detector as a sort of "signal generator" (maybe I am wrong)I am currently improving a similar design to attain 10 ps RMS jitter in the measurement (I am now stuck around 20-30 ps RMS). Sorry, back to the question.Considering your context (Physics department), I assume you have at least some design capabilities (basic custom PCB). Otherwise, I strongly recommend you purchase "low cost" Time Interval Analyzer (TIA). Almost anything recommended by others in this thread will cover pretty well your requirements.The DIY approach? My 5 cents on the topic,Design a very simple circuit/PCB with power and signal connectors. This PCB must have:A) A microcontroller with Timestamping capabilities (many available, choose sth easy to program, Arduino-like, i.e. RPi Pico or Teensy 4.1),B) A good 10 MHz TCXO clock reference and,C) 50 ohm termination, digital buffer/comparator... the minimal stuff to appropriate receive your signal, convert into digital pulses and route to the microcontroller capture pin.The Teensy 4.1 may be quite nice for your project, as it has "timestamp" capabilities, see the GPT (General Purpose Timer) and specially if you ever need to send the timestamps via Ethernet (I like it much more for this sort of experiments than USB). Using the GPT peripheral you only have to route 2 pins: the master clock to GPT2_CLK and the signal of interest to GPT2_CAPTURE1. The GPT configuration can be a little bit complicated but overall the Teensy 4.1 is a nice fit for this project specially if you decide on using Ethernet. Otherwise, you can mostly use any other microcontroller... Hint: when crafting your proto PCB, plan it as a base/motherboard for your specifics, but otherwise you can choose a commercial microcontroller board to connect on top of it. Adafruit, Sparkfun, PJRC are all good starting points for selecting one!https://www.pjrc.com/store/teensy41.html

author: ckruhagu
author_rank: Contributor
timestamp: June 02, 2025, 06:16:19 am
content: Thank you again to everyone for your helpful comments and suggestions.There have been a few questions raised as to why and how and what we are doing.We are a commercial entity collaborating with a research lab to develop some novel IP regarding pulsed lasers. We have developed custom code that optimises firing of the laser to maximise energy output relative to another process in the experiment (can't disclose this, sorry) and have noticed that this occasionally misbehaves and gives substandard results. Is the issue with our algorithm triggering at the wrong time? Some glitch in the trigger circuit? Or is it a problem with the laser where (for whatever reason) it is not following the modelled behaviour? We don't know.The first port of call is to check all of the trigger timing. We are well aware of the importance of trigger timing in physics experiments and there is a wide family of devices to provide synchronisation between equipment, some of it at incredibly fast time-scales. Due to the nature of our project this equipment is not applicable to us, as the entire point of our system is to provide a non-regular trigger that is following a separate physical process that we are optimising against. This is why we need to track the timing on all of the trigger pulses so we can understand why one of them is generated too early or late. One way to do this is to feed known modelled signals into the algorithm which should then give stable known output, which during the test should be a regular 10 Hz trigger signal which can be checked.The key thing we have learnt from this thread is that we need a "timing interval analyser" and that now we are looking at the right equipment, we can see there is a wide range of models to choose from.Can we go talk to the electronics experts on campus? Yes we can, but it takes time and is not always productive since it is a shared resource.Can we rustle up money in the budget for high end kit? Yes, but not really, because that takes budget away from other efforts. While we can spend AUD$10k on this one piece of hardware if it is deemed to be absolutely necessary, because it is not a core part of the experiment and is only being used for "a check" on the system, until we know more, at this time we can't spend big money on it.Someone else suggested renting, and that is indeed an excellent option for us in this position, we are already looking into it.There was also a suggestion that we buy and then sell. This doesn't happen very often in our world for quite a few reasons. For purely commercial applications there is a time cost associated with selling off second hand equipment. For purely academic projects, there are often restrictions placed on what can and can't be done with grant money, and selling off equipment purchased with grant money is either frowned upon or outright prohibited by the uni or the grant. Yes, old equipment is frequently sold off, and you'll see it on eBay all the time, but this is mostly done en mass to clear lab space and happens well after the grant has expired and the research completed. You'll also find that universities rarely sell off old kit piece by piece, they much prefer it to be all cleared out by a 3rd party, receive a token payment well below market value, and then that 3rd party will be the one cleaning up, refurbishing in some cases, and then selling off the kit. Of course I am generalising based on our experience, and no doubt you can find counter examples. Because we are so busy with our projects we certainly don't have the time to be dealing with cost recovery by selling equipment.I hope the extra information is appreciated, and does not simply raise more questions than I have hoped to answer.

author: ckruhagu
author_rank: Contributor
timestamp: June 02, 2025, 06:21:49 am
content: PS: The suggestions to roll our own logic or timing controller are much appreciated. Because our timing requirements are quite modest (us is nothing really) it should be possible to have some joy making our own equipment. We are experienced enough to appreciate that once you need better timing accuracy and precision then it gets complicated and needs the right parts, a clever design, and lots of testing to ensure the device performs as expected. For this application we are unlikely to have the time and enthusiasm to build something that does what we need, but we will keep it in mind as an option.In case anyone is wondering, we are considering this model from Aim TTi.https://www.aimtti.com/product-category/frequency-counters/aim-tf900seriesWe've asked the manufacturer about the software and whether it can perform gapless analysis and output the intervals between triggers continuously, but they have not yet responded. Does anyone have any experience with these units and care to comment on them?

author: 2N3055
author_rank: Super Contributor
timestamp: June 02, 2025, 09:30:07 am
content: Quote from: ckruhagu on June 02, 2025, 06:21:49 amI have it.Short version? It cannot do what you need.

author: ckruhagu
author_rank: Contributor
timestamp: June 02, 2025, 11:27:21 am
content: Thank you.Dare I ask about the long version?The specs look like it will do the job, but I suspect the weakness is the software and output over USB. Our experience with consumer grade (and some enterprise) test equipment is that it's the weak spot.

author: 2N3055
author_rank: Super Contributor
timestamp: June 02, 2025, 12:03:43 pm
content: Quote from: ckruhagu on June 02, 2025, 11:27:21 amIt has a mode that can send measurements to the USB virtual serial port continuously, but they are not timestamped, and they are not sent after every interval measurement but at same rate as screen refreshes.So fastest every 0.3 seconds.It is useful for long term monitoring of some frequency but not for what you explained.

author: Someone
author_rank: Super Contributor
timestamp: June 02, 2025, 11:09:56 pm
content: Quote from: ckruhagu on June 02, 2025, 06:16:19 amDo that first. Completely explain the problems you are seeing and let an "expert" suggest ways to solve it.You have not motivated the need to capture and record every single event. Someone (such as your local expert) knowledgable in the use of an oscilloscope may well show you ways to diagnose the problem without needing to 100% capture everything.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 03, 2025, 02:59:07 am
content: Quote from: ckruhagu on June 02, 2025, 06:21:49 amYou admit the timing is not onerous, then imagine it becomes harder ?The heavy lifting can be done with 3 key parts, plus some CMOS logic, and resolves about 20x better than your required LSB.Example:Here we use a SN74LV8154 to do 32 bit counting and capture, and a FT240X to burst send every edge to the host.Very simple and deterministic on the capture side.A suggested timebase is DigikeySIT5503AB-WW-33E0-10.000000X5 ppbSiTime 196 In Stock 1 : ~$88 - not bad for that precision, and without the power of an oven.3 or 4 glue parts manage the edge sync/trigger and burst counting, and you can double the 10MHz for 50ns timestamps.Closest edge to edge re-trigger+send timing on this is ~ 800ns, but of course the FS-USB cannot sustain that transfer, a few edges could be managed up to the FIFO.There are larger package HS-USB parts that could sustain that parallel load, the FT2232H for example could support 2 pathwaysThat retrigger rate is far above the OP's 100ms edge rate.Addit: Given the scan and trigger work is done, if building this I'd be inclined to add a second SN74LV8154 thatcaptures on the other edge.A pulse width report can then be had almost for free, down to 50ns.The scanner can then dump 8 bytes of capture.Checking indicates FT240X modules are a bit rarer than FT2232H ones, and SO16 parts are not large, so a FT2232H-module daughter card with two channels looks a good fit.

author: ckruhagu
author_rank: Contributor
timestamp: June 03, 2025, 12:52:13 pm
content: "You have not motivated the need to capture and record every single event"What is your problem?We do have to capture every single event, and there are lots of reasons for that, but why on earth do I need to justify that to you?

author: ckruhagu
author_rank: Contributor
timestamp: June 03, 2025, 12:55:31 pm
content: "You admit the timing is not onerous, then imagine it becomes harder ?"Anyone can spit out a block level design for a device, as you have done here.To take that block level design and turn it into a fully functional device that works perfectly and does everything you expect it to, is completely non-trivial and can easily expand into a larger project than the initial issue we are trying to address.Because of the nature of the timing glitches we are looking to detect, we won't know the difference between a fault with our system or a fault with our measurement device.That is why people pay the big bucks for test equipment, and that is why I am wary of rolling our own - exactly because we have the ability to do it means we also know enough to be wary of doing so.

author: ckruhagu
author_rank: Contributor
timestamp: June 03, 2025, 12:57:31 pm
content: Thank you very much for this.The tech support guy got back to me with the exact same information. As you say, perfectly reasonable for long term monitoring of a frequency, but can't output a gapless capture of all events.I like AIM TTi kit, but it looks like this one is not for us. We'll keep looking.

author: tggzzz
author_rank: Super Contributor
timestamp: June 03, 2025, 01:24:50 pm
content: Quote from: ckruhagu on June 03, 2025, 12:57:31 pmThank who and for what?Hint: use the "quote" button at the top right of every message. Makes it easy for readers.

author: 2N3055
author_rank: Super Contributor
timestamp: June 03, 2025, 02:45:04 pm
content: Quote from: tggzzz on June 03, 2025, 01:24:50 pmIt was me for information on AimTTi TF930 counter...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 03, 2025, 10:21:33 pm
content: Quote from: ckruhagu on June 03, 2025, 12:55:31 pmThat's precisely why KISS is important, it has a very simple task, so it is easy to verify to does that task.Quote from: ckruhagu on June 03, 2025, 12:55:31 pmThat's true of any system. The appeal of a simple, KISS approach is you can build multiples of these, and run multiple sanity checks.Quote from: ckruhagu on June 03, 2025, 12:55:31 pmYet you already find those 'big buck' boxes need multiple questions to even see if they might work?

author: Someone
author_rank: Super Contributor
timestamp: June 03, 2025, 10:34:00 pm
content: Quote from: PCB.Wiz on June 03, 2025, 10:21:33 pmIf they had money they'd just call around the "fully supported" brands and have an applications engineer deliver them a working solution. Instead we've got the classic yelling about how they know what they are doing but need us to answer extremely specific questions that make no sense to us... so they can save some money/time.

author: ckruhagu
author_rank: Contributor
timestamp: June 04, 2025, 03:22:57 am
content: Don't worry mate, I won't waste my time, or yours, posting to this forum ever again.Your attitude just stinks. Why do you even hang around on here?

author: joseangel
author_rank: Contributor
timestamp: June 04, 2025, 07:41:17 am
content: Quote from: ckruhagu on June 04, 2025, 03:22:57 amLet's be polite, please.You asked for information and received plenty.There's no need to continue arguing.

author: tggzzz
author_rank: Super Contributor
timestamp: June 04, 2025, 08:40:20 am
content: Quote from: ckruhagu on June 04, 2025, 03:22:57 amIt is polite to follow the local etiquette, e.g. using the "quote" button to indicate the context of your statement.It was also more difficult than desirable for people here to elicit the information necessary to help you. Sometimes it felt like extracting teeth!

author: PlainName
author_rank: Super Contributor
timestamp: June 04, 2025, 12:55:30 pm
content: Often, one doesn't know what detail would be relevant and useful and what just obscures things. If something is missing, one can always ask for expansion. And/or say what would help.There is also a tendency to forensically argue some aspect (here, for instance, DIY vs OTS), because. Surely it's enough for the chap to say he doesn't want to make it. There doesn't have to be a compelling reason that satisfies someone elses ego; he just prefers not to go down that route. That's not disrespecting anyone, so pisstaking responses are inappropriate (but seem to be the norm for this kind of thing).