How does waveform updates on an oscilloscope work? Why do they work that way? - Page 1
Forum section: electronics / testgear

author: ballsystemlord
author_rank: Frequent Contributor
timestamp: April 17, 2023, 04:41:16 am
content: Although I tried to be an aware buying when I purchased my oscilloscope, I somehow didn't know about the implications of waveform updates per second. Dave mentioned it here:https://youtu.be/txPxo4TA0i4offset 25:30 . And so I read up on the matter on rigol's blog where they have this picture:Here's the rigol articlehttps://int.rigol.com/news/blog/DS70000BLOG.htmlAnd the relevant quote:"Since the speed of data sampling is much greater than the speed of data processing, sampling has to be stopped during data processing, which results in all waveforms during data processing to be lost because they are not collected."Doesn't this cause a problem for protocol analysis?Thanks!EDIT: Never mind the second question. I read wrongly.

author: JPortici
author_rank: Super Contributor
timestamp: April 17, 2023, 04:59:47 am
content: Quote from: ballsystemlord on April 17, 2023, 04:41:16 amNo. I mean, yes, if you can't fit the frame of interest in the acquisition.But you should really use an oscilloscope only to validate the analog part of the window. The moment the analog signal is correct you should switch to a protocol analyzer (which can usually also put data on the bus, which makes it a much more useful trigger. Imagine doing CANbus analysis of a network with only an oscilloscope).And if you're looking for protocol error conditions you should use decode triggers (and an oscilloscope that use HARDWARE protocol decoders and not decodes from screen data) in which case you won't have dead time because the scope will process/display only buffers that contains the trigger conditions

author: Someone
author_rank: Super Contributor
timestamp: April 17, 2023, 05:08:14 am
content: Quote from: ballsystemlord on April 17, 2023, 04:41:16 amDepends on the scope. Some scope + protocol decoders are run online in realtime hardware, they trigger the sampling/capture and would be blocked from triggering again until the "processing" is complete. But will not miss the first (or only) instance. Some scopes will only do the protocol analysis on captured data, slower than the data is coming in with those sorts of dead times between visibility (and chance to miss triggers). Obviously the scopes that aren't able to do realtime protocol decode are a little shy in saying that so it can be hard to tell, generally if the data sheet isn't making lots of noise about hardware protocol decode then its that slow type.

author: Fungus
author_rank: Super Contributor
timestamp: April 17, 2023, 05:23:01 am
content: Quote from: ballsystemlord on April 17, 2023, 04:41:16 amCan you miss a packet? Yes.But unless your eyes are fast enough to read all the data in real time as it decodes then it's not a problem.A modern 'scope will have enough memory to capture what came after the trigger point so you can stop the 'scope and inspect it.

author: Berni
author_rank: Super Contributor
timestamp: April 17, 2023, 06:27:00 am
content: High waveform update rate only matters for 'analog' signals.When looking for noise or glitches on a signal you want to see as much of the signal as possible. So a good modern high update rate oscilloscope might do 1000s of captures in the 1/60th of a second that it takes to update the LCD display. So to show all those waveforms the scope overlays them over each other in a transparent way. This gives them that smooth soft fuzzy look that you see on a classical CRT oscilloscope (since it is doing the same thing, drawing the waveform many many times on top of itself). In order to achieve this high update rate, the oscilloscope has to have a processing time as short as possible, so that it is capturing new signal data as much of the time as possible.When looking at digital communication this is irrelevant. There you are only interested in making one big single shot capture. So the processing time is just the time before making the single shot capture and it appearing on screen. Since humans are really really slow in comparison that doesn't matter. Modern scopes have huge sample memories, so you can really capture a lot in single shot and then scroll trough all the data.

author: Martin72
author_rank: Super Contributor
timestamp: April 17, 2023, 07:09:52 am
content: Hi,https://www.eevblog.com/forum/testgear/help-me-choosing-new-oscilloscope/msg4805312/#msg4805312Little informations about Acquisition and so on.

author: Someone
author_rank: Super Contributor
timestamp: April 17, 2023, 07:22:13 am
content: Quote from: Fungus on April 17, 2023, 05:23:01 amCatching specific or broken words/packets is the key feature of hardware decode + trigger, where none are missed. Finding that one problematic event in an embedded bus that only appears occasionally can overflow the memory capacity easily (have debugged things like this many times, not just some imaginary use case or one off special purpose).Quote from: Berni on April 17, 2023, 06:27:00 amYou haven't separated software decode vs hardware decode, one of those is significantly handicapped by the dead time.

author: pdenisowski
author_rank: Super Contributor
timestamp: April 17, 2023, 08:32:39 am
content: I made a video on this exact topic

author: pdenisowski
author_rank: Super Contributor
timestamp: April 17, 2023, 08:43:22 am
content: Quote from: Someone on April 17, 2023, 05:08:14 amYes. The hardware / software distinction also becomes increasingly important as bus speed increases: here's a screenshot of our MXO4 decoding SPI data in realtime where the frames are only ~10 microseconds apart. Guess which kind of processing we useHardware processing is also important when you want to trigger at the protocol level, e.g. if I want my scope to only capture frames that contain some bit pattern or which have errors.Blind time is much more important than most people think, and it is definitely an issue for higher speed protocol decodes as well.(Incidentally, the data in the screenshot is me repeatedly sending "pAUL" in ASCII and then x76 to a display - note that the MXO is not missing any of the frames even at > 40 Mbps)

author: pdenisowski
author_rank: Super Contributor
timestamp: April 17, 2023, 08:46:46 am
content: Quote from: ballsystemlord on April 17, 2023, 04:41:16 amI think what they mean is that samples being generated by the ADC areignored(that is, not processed). I'd be surprised if they (can) turn the ADC "off" while processing the samples from the previous acquisition

author: 2N3055
author_rank: Super Contributor
timestamp: April 17, 2023, 10:23:47 am
content: Lots of info here... Let's sift through it to see what could be relevant to OP's question.Blind time: the time scope is not registering new acquisition after previous trigger. I say registering because ADC conversions are running all the time... Most new scopes are having digital trigger engine, so ADC is running all the time, putting samples into buffer all the time. Triggering engine is processing all the time until it encounters trigger term in input data.Then for short time it stops being ready for new trigger andthatis blind time...So if you are doing protocol analysis by triggering on single communication packet, then you need to have a scope whose blind time is less then inter-packet time.But, why would you look at packets this way? If you have a burst of 100 packets in 10ms, what you will actually see on screen?Only last packet. Your super-duper fast scope is useless... You cannot see packets that change every millisecond.To overcome this you need for scope to capture all 100 of them and stop for you to be able to go through data...And you can do that two ways: by using long memory,where you capture 100ms of data and all the packets inside with zero (0) blind time inside that capture, or you can use segmented memory mode, where you capture short packets individually but capture 100s of those segments in one burst. That mode (segmented memory mode, manufacturers have different names for it) usually have very little blind time because it doesn't refresh the screen or do anything with data until it is finished with whole burst. Not a zero blind time, but really fast.And that makes scope refresh rate pretty much irrelevant to decoding. Fast scope refresh rate is sometimes useful for some other tasks. But for decoding, not really.As for decoding in software or hardware, I have scopes with both. Ones with software decodes I have are fast enough to be faster than me, i.e. the decode faster than I can read and comprehend.Fact that my Keysight can decode much faster than I can read looks cool on paper but is not really useful.. I look at the packet where data is changing all the time and all I see is blur. Like benchtop DMM set to really fast conversion, where last two digits are just flipping so fast you can't see the number...Software decoding was (is) a problem only with really slow (old or entry level) scopes, where it needs a second or two for decode to appear. If decode pops up in 100ms or faster, that is real time to a human.And if you look at a packet to see if it changes, you can see that on waveform. Software decoding is asynchronous from waveform drawing if done properly. You still see waveform change even if protocol decoder is lagging....For protocol decoding, long memory is more important than retrigger rate...

author: Someone
author_rank: Super Contributor
timestamp: April 17, 2023, 11:13:23 am
content: Quote from: 2N3055 on April 17, 2023, 10:23:47 amAs we keep saying, that you have not exploited the feature does not make it equivalent to the poorer cousin. When you know what you are looking for hardware triggers will get there quicker and easier, you often know something about the problem data/word but need to see it in context with other signals or data before/after it. Yes in some situations the software triggering will be quick enough to keep up (not a published specification) but there are real world examples where it isn't sufficient and hardware triggers are going to collect the capture faster. To take extreme examples to the other side some software decoders (and triggers in general) are nonrandom, you always get the first in a burst and the following are always caught in the blind time, they will never see the anomaly if it only occurs inside that blinded region (again coming from a real world example of that).Long memory and sifting through (hoping the relevant point is within the captured window and not the blind time) vs triggering directly on what you are looking for are not equivalent as you make out.Quote from: 2N3055 on April 17, 2023, 10:23:47 amThey are radically different tools for different situations, neither is more important than the other until you know specific details about the signals.

author: 2N3055
author_rank: Super Contributor
timestamp: April 17, 2023, 12:35:35 pm
content: Quote from: Someone on April 17, 2023, 11:13:23 amI really don't understand software and hardware TRIGGERS mentioning ... TRIGGERS are hardware (for both analog and decodes) on Siglent for instance...... Screen data decoding is software... But triggers are hardware based state machine... That works in normal and segmented mode in full speed.That is why I said that for Siglent, for instance, only on screen update rate (human readable) of actual messages is related to software speed.But triggering is hardware based digital trigger working off the ADC full sample rate..So you would have trigger on every packet, and it's waveform would be shown on screen in real time. And decoding would skip some decodes in a burst and show you only last one. Instead of unrecognizable blur and then the last one... Same difference...

author: ballsystemlord
author_rank: Frequent Contributor
timestamp: April 17, 2023, 03:31:28 pm
content: Thanks again. That answers my question.

author: Someone
author_rank: Super Contributor
timestamp: April 17, 2023, 11:08:37 pm
content: Quote from: 2N3055 on April 17, 2023, 12:35:35 pmThere are scopes out there with no hardware serial trigger, but do have software serial decode, or the serial trigger only frames the packet and does not qualify/inspect the contents. Yet this thread is a mess of people not making that key separation which answers part of the question of the OP. You can talk about your specific situation and be correct, but stop making it sound like that is true for everyone and everything because it is not.Even with hardware triggers that extract errors or specific data values/patterns, there is still dead time which can miss some events. In some situations that is important and cannot be replaced with deep memory, instead segmented memory can be the better choice, or a more powerful trigger. Long memory is not a replacement for short re-arm time.

author: 2N3055
author_rank: Super Contributor
timestamp: April 17, 2023, 11:53:59 pm
content: Quote from: Someone on April 17, 2023, 11:08:37 pmI don't know of any current production scope that has software triggers (out of mainstream brands i know off). I certainly don't know them all naturally..You seem not to understand what I want to say. Let's take example of my Keysight 3000T and Siglent SDS6000Pro H12.MSOX3000T has faster retrigger rate in normal mode, no question. But it has 4MPts of memory total while SDS6000 has 500MPts and even more in segmented mode.Which means I can capture 125 times longer capture at same sampling rate and just capture whole burst of data from sensor for instance.And for data in that capture, there is 0 blind time. Zero.With MSOX3000T I have to use segmented memory...And I have to have very short blind time not to miss packets...With sds6000 I don't have to use segmented memory most of the time. And if I do I get many more segments.. and blind time is minimal because in segmented mode it skips processing. In segmented mode difference is minimal.Segmented memory is better for sparse packets on fast protocols (short packets, long dead time). Which incidentally makes short retrigger time less critical. No missed events.For a burst of really fast packets with very little interpacket time, continuous long memory can capture tens of thousands of packets in single go. With zero blind time inside. No missed events.As for decoding speed, on scopes with hardware trigger and software decode, decoding is asynchronous to capture. If decode is too slow to decode every screen refresh,Short rearm time is (like I said) useful. If that is so important and if you feel that software decoding is slowing down retriggering ( it should not because trigger is hardware and decode processing is not included in retrigger time but in display threads), you can disable decoding, capture packets you like and then stop scope and enable decoding. It will decode it then. That is one great advantage of decoding as postprocessing. You can also grab some data and play with decoding settings until you get meaningful data. Compare that with MSOX3000T that you need to have all protocol parameters perfectly set before capture or it won't decode right and you have no other choice but to capture again...And at the end of the day, I use both Siglent, Pico and Keysight and they are all up to the task, just by using different techniques.That is one thing.Other is this: If you are looking at scope interactively with packets flying by, hundreds per second, looking at the screen will show you just a bunch of changing data and waveforms.. You will see just a blur.You need to either :1. trigger on a rare packet that happens rarely enough for you be able to see, read and comprehend messages2. Capture 100s of packet individually using segmented mode, stop and sift trough them. In which case even scopes with software decode don't do any processing and have extremely fast retrigger rates.. POI is very high on all.3. Capture very long capture that has 100s of packets inside, stop and sift trough them. In which case there is 0 retrigger time between packets and POI is 100%.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2023, 12:20:20 am
content: Quote from: 2N3055 on April 17, 2023, 11:53:59 pmQuote from: 2N3055 on April 17, 2023, 11:53:59 pmWhich immediately means you can only capture for that length maximum with 100% coverage (and slower offline search/processing). I get it, you are correct for that specific situation. No complaints. But that is almost no use at all if you are trying to pull out intermittent problems that appear in minutes or hours of time (longer than the maximum memory depth).If you can capture the entire systems operation within the memory sure, go for it and have 100% capture probability. But that is not the situation for every case.Quote from: 2N3055 on April 17, 2023, 11:53:59 pmI think you are wildly misinformed and inexperienced if you believe turning on software decodes does not slow down any scope or increase the blind time. Regardless, as I have said from the start and you keep ignoring/discounting/arguing against, it is unusual to have systems where you can capture 100% of the systems operation in memory. So to say that is a given absolute and true statement is why this keeps going around and around.To rephrase those 3 points in a more balanced and representative manner:1. capture the problem with a complex hardware trigger if possible, captures the first event and others following it with some blind time2. generic trigger with post processing/search in segmented memory, longer blind time unless the entire operation fits in memory3. capture everything in memory and search through it, blind all the time outside that captureLong memory is not 100% capture in the general case, only IF you can guarantee that the entire possible system operation and state is captured within. I could show you examples where that is a 0% capture rate every time, equally true and equally not generalised. In the general case any one of those options might be the most appropriate or have the least blind time. But the OP asked about blind time and how that related to protocol analysis, so the answers are surprise surprise nothing to do with "what happens with protocol decodes within a single capture?" or any of your 3 examples.Scopes miss everything outside their captures so its up to the user to make sure the triggering and memory settings are set for the task at hand.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2023, 08:01:14 am
content: This whole discussion appears to be ending up down a traditional rathole, equivalent to trying to use a hammer to insert a screw.Use a scope to ensure signal integrity, i.e. that the analogue waveforms will be correctly interpreted as digital signals.Then flip to the digital domain, and use a logic analyser's superior clocking, triggering and filtering to discard (i.e. don't store) the irrelevant crap.If that is insufficient, use a protocol analyser to concentrate on the messages in conversations between devices.

author: 2N3055
author_rank: Super Contributor
timestamp: April 18, 2023, 09:57:14 am
content: Quote from: Someone on April 18, 2023, 12:20:20 amWe are finally getting somewhere.. I know my English is not very good but we seem to have more trouble than usual. But getting there...First I am talking about decoding and looking at serial protocol data on scope ( that is what OP asked about). Not about general scope use. That is so wide and unpredictable and I would not generalize that in two sentences, and a reason why there are more than one type scope out there...Also OP spoke about Rigol scope that has I2C, SPI, CAN, UART protocols... Not about 10 Gbit Ethernet.So speeds are known in some general terms, and order of magnitude is known...CAN at 1MBit will have packets in 100 us range for instance..You usually cannot EVER capture whole system messages in memory. You divide and conquer.Hence you either set trigger for specific data ( address, payload, error type).Or you capture a manageable chunk (by either segmented capture or single long capture), stop (or single in a first place) and sift through data. By which you gain knowledge what is in there so you can start drilling down to specific information.And then we get to the point that if I use my scopes in segmented mode, they all are VERY fast.While Keysight has faster retrigger time than Siglents I have here in normal display mode. But in segmented mode Siglents have less than 2 µs blind time , and Pico 3406D has less than 0.6 µs and is faster then Keysight for that....And yes, on SDS6000, enabling software decode DOES NOT slow down data acquisition in normal mode. It is not me here who is talking without knowing..I know. I measured ..And in segmented mode ALL processing except trigger and memory acquisition is stopped so there can not be influence..Of course there might be scopes out there that behave like you said. I don't know. But those I have behave the way I explained.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2023, 11:57:37 am
content: Quote from: 2N3055 on April 18, 2023, 09:57:14 am1500 words on and you still try to talk about what you want to talk about. Ignoring the OPs question, and taking a long long time to add in the honest details.....Quote from: 2N3055 on April 17, 2023, 11:53:59 pmQuote from: 2N3055 on April 18, 2023, 09:57:14 amArent Picoscopes in that category of software based serial triggers? At which point the best case blind time of captures is irrelevant when talking about sustained throughput.Yes you want to talk at length about non realtime serial analysis/search. But dont make out like that is some replacement for all realtime cases, or add mountains of half-truths and misleading drivel.OP asked really clearly what is the interaction between dead time/update rate and serial decode, that has been covered quite well in a non biased and polite manner.

author: radiolistener
author_rank: Super Contributor
timestamp: April 18, 2023, 12:07:29 pm
content: Quote from: ballsystemlord on April 17, 2023, 04:41:16 amNo, protocol analysis is done at full speed on FPGA logic with no dead zone.Regarding to waveform capture, it works in that way because it requires some time for processing before show it on the screen. It requires some time for processing.Actually it doesn't matters, because signal is captured by trigger which works on FPGA logic at full speed with no dead zone. Dead zone happens between trigger events, more fast CPU and FPGA allows to minimize dead zone.Also, note that usual analog oscilloscope also has dead zone, when the ray is out of the display or in back trace state. It needs some time to return ray back on the left side, and analog oscilloscope don't display signal at this time.

author: radiolistener
author_rank: Super Contributor
timestamp: April 18, 2023, 12:18:58 pm
content: Quote from: 2N3055 on April 17, 2023, 12:35:35 pmsome cheap Chinese toys don't have FPGA to implement hardware trigger which works at full ADC speed in real-time, they just capture some long sample and then using software trigger. In that case important signal event can appears in dead zone and such software "oscilloscope" may lose such signal event in a dead zone.

author: 2N3055
author_rank: Super Contributor
timestamp: April 18, 2023, 01:49:53 pm
content: Quote from: Someone on April 18, 2023, 11:57:37 amThere is no software triggers in Picoscope..You have wrong information. Do better research before stating something as a fact..I've grown tired of being called dishonest by you..Everything I said is true and founded in facts. On equipment I have and use and have verified...Very unlike speculations and generalizations...I answered to OP. Adding to data that was biased and wrong, stating that hardware decoding has influence on scope retrigger time.It does not. It has influence on screen refresh of decoded strings but no influence on triggering.At least on software decoding scopes I have here. So if there are scopes out there that do have that problem it is NOT because they software decode, but because they have BAD IMPLEMENTATION of software decoding...Pdenisowsky gave some good info..Where he said that MXO4 is fast because decoding is in hardware and that it can easily capture packets that are 10µs apart.News flash, if they are only 10µs apart that is a piece of cake for 3 software decoding scopes I have here...

author: ballsystemlord
author_rank: Frequent Contributor
timestamp: April 18, 2023, 04:41:40 pm
content: Quote from: Someone on April 18, 2023, 11:57:37 amIf the OP, me, might interject for a moment.Not knowing how oscilloscopes do their protocol decoding, I asked how dead time affects triggering. The question, with respect to the analog part, has been answered in that it was pointed out that all, or almost all, scopes use HW based decode-triggers. Or so I understand from your posts.Just to be clear, decoding is necessary for triggering because a 1 and a 0 look like any other 1 and 0 until you decode what the bus is trying to transmit.It was also said,Quote from: JPorticiWhich brings us to the most advanced part of the question, which I didn't think I'd ask. Now my own scope has 16 digital channels (MSO5074 LA). I was trying to save myself a few $$$ and buy a scope that could do protocol analysis, and it can, via the web interface. So, does the scope have blind time with it's digital channels so that I can't trigger on them at certain points during the capture? IDK. I'd ask rigol, but every question I've ever asked them has gone unanswered. I've tired email and phone without result. The phone just goes to a voice mail.

author: 2N3055
author_rank: Super Contributor
timestamp: April 18, 2023, 06:27:45 pm
content: Quote from: ballsystemlord on April 18, 2023, 04:41:40 pmNo, scope decoding is separate from serial triggering. Triggering has it's own "decoder" that is used for triggering. It is a state machine that gets set by scope for trigger. After trigger scope captures certain time length (decided by timebase or manual memory setting) and then gives such captured data to analysis engine for full decode of all captured data.On Siglent scope you can easily disable on screen decoding but use serial trigger... They are separate.Reading your last paragraph I really don't understand what you mean...Scope waits for a trigger (analog, digital or serial protocol doesn't matter). After scope triggers (because trigger engine decides the conditions for trigger were fulfilled) scope grabs a certain time (as set with timebase ) of data on all enabled channels (analog and digital) and saves it into acquisition memory, notifies display engine and whatnot and resets itself for new capture and starts a new wait for next trigger. So minimum time between two triggers is captured time + this time scope needs for it to rearm trigger engine and gets ready for new trigger. This rearm time is blind time between two captures. So minimum time between two trigger events is going to be time set by timebase +blind time. Tigger event is start of capture event, it cannot happen again until scope fills the whole requested time period + rearm time...

author: pdenisowski
author_rank: Super Contributor
timestamp: April 18, 2023, 06:52:23 pm
content: Quote from: 2N3055 on April 18, 2023, 06:27:45 pmYes. People sometimes forget that the waveform update rate may also be limited by the user settings: if you have 100 ms/div and 10 divisions, the maximum waveform update rate for any oscilloscope is < 1 waveform per second -- it will take 1 full second just to perform a single acquisition

author: ballsystemlord
author_rank: Frequent Contributor
timestamp: April 18, 2023, 08:42:16 pm
content: Quote from: 2N3055 on April 18, 2023, 06:27:45 pmI meant, are the digital channels treated any differently, with respect to triggering or to waveform updates per second?

author: 2N3055
author_rank: Super Contributor
timestamp: April 18, 2023, 09:21:38 pm
content: Quote from: ballsystemlord on April 18, 2023, 08:42:16 pmDigital channels might have different number of samples in same time (sample rate) as analog channels. Analog channels might have different sample rates based on what channels are enabled or what time base is.. These things change all the time.But all analog channels and digital channels will listen to same trigger engine (whatever you set it to trigger from) and all the channels will be correlated in time, so you can compare what happened when across the channels, analog or digital.And also since sampling more data at the same time, 8bit scope with only one analog channel enabled will need to process 6x less data per second than with 4 analog channel +16 digital channel. So enabling digital channels might slow things down, but not because digital channels are treated differently but because scope has much more data to process.That parameter will change from individual scope to scope model, even for the same manufacturer.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2023, 09:55:41 pm
content: Quote from: 2N3055 on April 18, 2023, 01:49:53 pmReally? where do they advertise hardware serial triggers? where are examples or documentation of that? Why do they not correct people on their own forums who say the serial triggers are software?

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2023, 10:26:22 pm
content: Quote from: pdenisowski on April 18, 2023, 06:52:23 pmWhile datasheets like to publish the lowest achievable dead time (and highest update rates) they are always with the little * or acknowledgement that they are the best case. Often re-arm time changes with parameters like memory depth, or it has a minimum that can occur between some acquisitions but that is not guaranteed with occasional longer gaps. The re-arm time is rarely (never?) a constant.For many complex questions like these the only option is to test in the specific application, oscilloscopes being such complex and configurable devices that they cannot detail/explain every possible use case (or might not want to talk about their shortcomings).

author: tautech
author_rank: Super Contributor
timestamp: April 18, 2023, 10:37:14 pm
content: Quote from: Someone on April 18, 2023, 10:26:22 pmQuite but unless someone (not you) does the work and prepares tables of how sampling rates and mem depths are managed by the scopes acquisition process we are all just guessing.Then we also have user selectable memory depths which of course impact on rearm times...is that any surprise and user selectable sampling rates too so we must be careful to carefully compare apples with apples with instruments running in a default auto sampling/memory management configuration.Here is where user skill and knowledge come into their own for each and every use case....there are no hard and fast rules and the experienced user like this, we need to be in charge of how a scope acquisition works, not the manufacturer thinking they know best.

author: Someone
author_rank: Super Contributor
timestamp: April 18, 2023, 10:43:48 pm
content: Quote from: tautech on April 18, 2023, 10:37:14 pmAnd when you have a particular application that needs some performance measure not in the specifications, hopefully your local distributor can test it for you or loan a unit for evaluation

author: tautech
author_rank: Super Contributor
timestamp: April 19, 2023, 01:35:23 am
content: Quote from: Someone on April 18, 2023, 10:43:48 pmOf course however many need review the way they think about using a DSO and better utilise their best feature: Storage !Of course you can use a DSO just like a CRO and for those that do they are missing so much capability....and members still advise newbies to buy such outdated stuff.Really they do them no favours when they are better served to get into this century and learn how to use the modern feature set rather than some thing that just displays wiggly lines in real time.With a DSO we can overlook retrigger rates to some degree and use a slow timebase, capture the waveform/s of interest and zoom in to deeply inspect them in detail.Hardly advanced use just properly utilising a DSO's basic features.

author: Someone
author_rank: Super Contributor
timestamp: April 19, 2023, 01:50:05 am
content: Quote from: tautech on April 19, 2023, 01:35:23 amI think you are walking off (and back around on the loop) from the point of that comment. There are people on this forum who like to take a (best case and/or asterisked) specification and then try to use that as evidence of some performance related to but not actually specified. Oscilloscopes have many non specified performance and features, that can only be determined by testing.To state blankly that retirgger rates are generally not important as deep memory can do the job..... we're back at the start of that stupidity again.Both have valid uses and neither is better for all cases. They are not replacements for each other and result in radically different workflows/results for the cases that could use either.

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2023, 06:41:00 am
content: Quote from: Someone on April 18, 2023, 09:55:41 pmI don't know what and why happens on their forums, that is a question for them. I imagine they cannot police every word and correct every wrong thing ever said there...Picoscope has no serial triggers software OR hardware. It has only analog and parallel digital triggers.Triggering is triggering. Decoding is post processing like math channels and measurements. It has decoders for 30+ protocols..

author: tautech
author_rank: Super Contributor
timestamp: April 19, 2023, 07:26:40 am
content: Quote from: Someone on April 19, 2023, 01:50:05 amI didn't but instead:we can overlook retrigger rates to some degreeAnd I stand by that.You must know we each have a different DSO usage style based on previous experience or the feature set of the instrument in front of us but simply we must accept of each other, there are many ways to skin the proverbial cat and end with the same result.

author: Someone
author_rank: Super Contributor
timestamp: April 19, 2023, 11:13:02 am
content: Quote from: 2N3055 on April 19, 2023, 06:41:00 amPicoscope forum, picoscope staff member:https://www.picotech.com/support/topic40355.htmlAll done in software offline (significant blind time and no option for hardware serial trigger). Those sorts of differences were clearly expanded upon already:Quote from: Someone on April 17, 2023, 11:08:37 pmSo why are you making so much effort to try and say they are all the same? Scopes without hardware serial triggers cant perform many debugging options that hardware triggers expose, it is a key separator that you seem to be trying to discount/hide/dismiss with faulty reasoning (such as bringing up the best case blind time when the OP is asking about protocol decode).

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2023, 11:41:14 am
content: Quote from: Someone on April 19, 2023, 11:13:02 amIt is now obvious to me that it is not MY English that is the problem...I said and done none of the things you say I did. Your conclusions are your hallucinations of what my sentences mean.Read again and again until you understand.

author: radiolistener
author_rank: Super Contributor
timestamp: April 19, 2023, 11:41:26 am
content: it all depends on oscilloscope performance. If it has fast enough CPU and FPGA and software to get better update frame rate, it has less dead time interval between trigger events. But more fast hardware cost more money. So, more modern and more expensive hardware provides better results.Anyway, analog osciloscope also has dead time for trigger and it seems that modern DSO such as Siglent SDS1000X-E series can be equal or even better than analog oscilloscope.I think there is more important specification for modern DSO - this is a memory depth which can be used on a slow horizontal resolution. I think 14-28 Megapoints is the minimum for a modern low end oscilloscope. Also there is important the quality of digital phosphor algorithms used for rendering that deep memory on the screen. It's not easy to process 28 million points 30-60 times per second, it requires really fast hardware.

author: Someone
author_rank: Super Contributor
timestamp: April 19, 2023, 10:04:41 pm
content: Quote from: 2N3055 on April 19, 2023, 11:41:14 amA scope without hardware protocol triggers is exactly what is framed in the above quote. That would be things like the Picoscope andolderTektronix platforms (dunno about the current tek modelsconfirmed the current Tek platforms still have increased blind time when running serial trigger+decode).If a scope such as the Picoscope has the decodes run in software, then it is the rate of that which produces the blind time for serial analysis. Serial decode was the OPs question.This (as noted above by tggzzz) is almost identical to the many threads where people would ask about realtime update rate, then haveparticularmembers consistently misleadingly talk at length about blind time in segmented mode and say how its all the same thing. That the acquisitions can enter memory but none of that information reaches the screen/user/result, makes them part of the dead time for that analysis. You want to talk about dead time? then discuss it accurately and honestly rather than pushing your "side" as somehow universal and superior.

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2023, 10:11:53 pm
content: Where it comes to software triggering on protocols: most decent benchtop oscilloscopes starting from $350 will have hardware protocol triggering. In the end it is not difficult to implement; it comes down to triggering on a specific pattern.There are some exceptions though: The Picoscopes and AFAIK also some older Lecroy models (like the Wavepro 7k series).A much more interesting seperation between models is the amount of packets they can decode, how much the signal is decimated and minimum required samplerate versus protocol bitrate. These limits determine how effective you can use an oscilloscope's memory.Quote from: tggzzz on April 18, 2023, 08:01:14 amIn theory. But in practise you don't always know what you are looking for so it can be helpfull to capture a lot of messages on an oscilloscope, save to disk for analysis on a PC and go back to the scope to inspect the waveform for the malformed packet.

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2023, 10:20:50 pm
content: Quote from: 2N3055 on April 17, 2023, 12:35:35 pmIn some cases it is usefull to look at the decoded data in near realtime. Think about checking which bits change every now and then when reverse engineering a protocol.

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2023, 10:53:29 pm
content: Quote from: Someone on April 19, 2023, 10:04:41 pmYou keep repeating same thing WHICH is the reason for repetition..And miss the point.Let's define terms so you can finally see that we are both saying same thing in different way.First, what is "real time serial decode (analysis)?Is that when you are looking at the scope screen waiting for scope to show messages as they run over comm bus we are decoding?You can have scenario where you have thousands of packets per second and a really fast scope that will render all of those (all 1000) to the screen in real time, keeping each on screen for 1 ms... That would be obviously useless b'cause I can't read that fast.I might need to capture all of them because I wan't to reverse engineer what is going on in detail. This will needone long capturewith all of them, stop and then I have few hours of work to make sense of all that data. This is not real time.Or I'm interested only in messages sent by only one of sensors... In which case I need the scope to only TRIGGER on certain messages (set by trigger condition) and ignore all the rest. And if my sensor of interest sends data only once a second (or when I press key or something) then I leave scope running, and wait for it to catch a message and show it to the screen. This isinteractive work, this is real time,but only if message rate is slow enough for a slow human operator.3rd scenario is same as 2nd but although we are capturing only one type of data packet, there are still 10-20 a second... We are not interested in anything else, but poor human is too slow.. In this case weset trigger and capture some to segments. And again look at the data in offline mode.Scenario 1 is perfect for Picoscopes. And many of Saelae type USB analyisers.It is not good for short memory scopes.Scenario 2 is perfect for fast hardware trigger/decode scopes. But most modern hardware trigger/ software decode scopes will be fast enough to keep the pace with human.. If it is too fast for human it will be too fast for them.Scenario 3 is good for both hardware trig/decode and hardware trig/ soft decode scopes, because triggers run in hardware in both but segmented capture postpones all processing until predefined number of segments (packets) is captured, negating any blind time difference in decoding. On soft decode scope you might have a short pause after capture is done for scope to decode while hardware one will show data much faster. But neither will miss any packets..There is also marginal scenario between 2 and 3 where some people will be able to read messages faster or slower, and where some will prefer full hardware trigger/decode scope because they will be able to show things faster..

author: 2N3055
author_rank: Super Contributor
timestamp: April 19, 2023, 11:00:06 pm
content: Quote from: nctnico on April 19, 2023, 10:20:50 pmI know, I used my Keysight once to reverse engineer display protocol by sending data to screen and looking into data on the bus... It was quick work to find coordinate system and direction of data.. But to human a realtime is like twice per second... My 2 Siglents (and even a Pico on a fast PC) do that without a problem.Real difference is when you have something happening 5-10 times per second, where you can just see a clear change instead of stuttering in decode... But because of hardware trigger, you will still see realtime change in waveform..And that happens to Keysight too, as soon as you get fast enough it will just show some of the data flipping..

author: Someone
author_rank: Super Contributor
timestamp: April 19, 2023, 11:07:30 pm
content: Quote from: 2N3055 on April 19, 2023, 10:53:29 pmImmediately you have taken the same strawman trope that has been explained over and over.Modern scopes have persistence in their display, even when set to "zero" persistence, but it can be increased as desired to infinity. Even if the trace was only visible for a single display frame (typically a broadcast rate such as 30Hz,50Hz,60Hz) the eye would still retain the event by visual persistence.As nctnico mentions above, a serial trigger can focus down onto one part/transaction of a system (such as filtering on addresses of SPI) and show what states the data bits contained across many words/packets. In real time, continuously, but with possibly some missing data lost to the dead time.Quote from: 2N3055 on April 19, 2023, 10:53:29 pmSo, now it's something "very" slow (from a scope perspective). Take a scope without a hardware serial trigger and how does it find that interesting message in amongst all the others? It has a larger blind time, the problem at hand.

author: 2N3055
author_rank: Super Contributor
timestamp: April 20, 2023, 07:54:56 am
content: Quote from: Someone on April 19, 2023, 11:07:30 pmAnd again, you read what you want to see, so you can keep arguing...There is no such thing as software serial trigger. Get your terminology right. Triggering is a hardware process of starting a new cycle of capture. Anything software is not a trigger per definition. If it is software than it is search or decode. Not trigger.I don't care if someone out there abuses the word. And I don't care about toy scopes that have it all as a software in ARM. We are talking real scopes here.Picoscope (for instance) has no hardware serial triggers. It has no decoded data search either. It only has data filtering, where you can filter messages in table by filter string...I said that scopes without hardware serial trigger are not good for realtime, because, well, they cannot trigger on specific packets... It's kinda obvious.In real time screen refreshes fully with every trigger and decoded messages overwrite on top of each other...I said 1000 messages a second, every 1ms on top of each other... On same screen overwriting on top of each other... Persistence doesn't apply to decode. For decode you have Normal trigger mode that keeps last message/screen on until new trigger comes and new capture gets on screen, on top.As for missing packets in real time, if scope has hardware serial triggers, if you miss packets on the screen it won't be because trigger missed it, but because you got fast burst of 3-4 packets in 100 µs, and you will be able to see only the last one because previous 3 went by in such a hurry you didn't see them.When you blink, that is 100 ms of screen dead time....And about visual persistence: if you have something displayed for 10ms on screen and then deleted, you will see something happened but good luck reading it with comprehension.... You might as well not enable decoding at all and just look at flicker of waveform instead... You can obviously see bits flickering in waveform...

author: tggzzz
author_rank: Super Contributor
timestamp: April 20, 2023, 09:20:07 am
content: Quote from: nctnico on April 19, 2023, 10:11:53 pmWhat do you mean by "malformed packet"?If the waveform shape is malformed, then that is a signal integrity issue and a scope is theonlytool to use. Eye diagrams are extremely helpful here - but you must be able to prevent a digitising scope from interpolating between samples.If the data within the packet is malformed, then ignore the scope and capture many bits/packets in a logic analyser, protocol analyser, or printf() statements. If convenient, use a PC + application of your choice.Don't forget that if you are using a scope tointerpretan analogue waveform as a digital signal/message, it may have adifferentinterpretation to the receiving device.

author: tggzzz
author_rank: Super Contributor
timestamp: April 20, 2023, 09:22:08 am
content: Quote from: nctnico on April 19, 2023, 10:20:50 pmIf you are looking for changes in bits, then use a digital domain tool (LA, protocol analyser, printf()) to capture the bits, and a PC application to show diffs.A scope is a non-optimum tool for that, even if it can be bent to the purpose.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2023, 10:14:40 am
content: Quote from: 2N3055 on April 20, 2023, 07:54:56 amThere certainly is, various scopes slow down their acquisition rate when using serial trigger/decode. Including big $ scopes from A brands.Quote from: 2N3055 on April 20, 2023, 07:54:56 amAs tggzzz says, why use a scope if all you wanted to see was the decoded data? use something more appropriate that doesn't have dead time like a USB to XXX serial adaptor, or a protocol analyser. The scope is more appropriate for when you want to see some analog characteristics of the signalcorrelatedto the data, be that timing or collisions or coincident signals like power. All of those do show in the persistence (as does the presence or absence of 0's and 1's for each bit, which may be all the information required; confirming aligned addresses, or correct data).Quote from: 2N3055 on April 20, 2023, 07:54:56 amFinally you are actually getting to the point, the dead time can miss valid triggers. Scopes can run with segmented or waveform history modes to collect such bursts for inspection, but they are still limited by finite dead time.... which can be a different length when the serial trigger or decode is enabled.

author: 2N3055
author_rank: Super Contributor
timestamp: April 20, 2023, 10:36:34 am
content: Quote from: tggzzz on April 20, 2023, 09:22:08 amI agree but premise of the question is a scope for that use.. Not what are alternatives.I did agree with you many messages ago that you can even use analog CRT scope for SI and some sort of LA for actual decoding. How it was done for ages..When you don't want to look at lots of decoded data, digital scope with decoding isusefulbecause you can dobothat the same time. Saves time and fiddling with connections...But I don't want to look at 1000 messages on scope screen. Even super expensive scopes with HUGE 15"screens are joke compared to the screen on a PC.. So for that job, for me it is MSO Pico or a LA... occasional print to uart. For stuff I'm making I bridge Pico's trigger deficiencies by toggling a pin of µC at critical points and trigger of that. Kind of "breakpoints" for scope.....

author: pdenisowski
author_rank: Super Contributor
timestamp: April 20, 2023, 10:37:42 am
content: If you're looking at a relatively low speed protocol where the physical layer is (assumed to be) clean and reliable, then a cheap USB logic analyzer will often be good enough. I have a whole collection of these and for the most part, there isn't much difference between them.In most other cases, a scope has significant advantages for serial decodes, most of which other people have already touched on, such as hardware triggering. One of the biggest ones is the mixed signal (analog + digital) aspect.For example, if I'm trying to debug an issue on a CAN bus, I might want to only capture frames with a bad CRC or a recessive ACK bit. This requires a hardware trigger unless I want to somehow try to capture and post-process a huge number of frames (and assuming the error is frequent enough to make this practical).But having captured an errored frame, how do I determine the root cause of the error? Was the CRC incorrectly calculated by the sender? Or were bits corrupted on the bus? If I trigger on errored frames, I can then look at the analog signal(s) to see what happened during the errored frame - noise, misbehaving node, etc. This is what makes a mixed signal oscilloscope such a powerful tool: the ability to correlate events in two domains.There's a reason why pretty much every modern oscilloscope - even "hobbyist" scopes - has an MSO option, even though this option is always considerably more expensive than a $20 USB logic analyzer.Again, there are plenty of cases where that $20 USB logic analyzer is more than sufficient, but there are also plenty of cases where it isn't

author: jonpaul
author_rank: Super Contributor
timestamp: April 20, 2023, 10:40:36 am
content: Research the many fine digital Oscilloscope application notes simcem1980s..1990s fromTektronixHewlett PackardLecroyThese detail the issues of real time, sampling, ADC sampling, memory depth.See Tekwiki, W140, etcBon journéeJon

author: tggzzz
author_rank: Super Contributor
timestamp: April 20, 2023, 10:53:48 am
content: Quote from: 2N3055 on April 20, 2023, 10:36:34 amIf people are discussing bicycle's characteristics and how they can be problematic when wanting to cycle over the Alps/Rockies, I think it is useful to point out that cars are a more appropriate tool.Don't you?QuoteIf you can be certain that a tool will meet the requirements of your use case, then by all means use that tool.But if you think a tool's characteristic weaknesses might make your task difficult or impossible, don't obsessively discuss fine details of such tools. Far better to simply choose a different type of tool without the weaknesses.Not rocket science

author: 2N3055
author_rank: Super Contributor
timestamp: April 20, 2023, 11:18:32 am
content: Quote from: Someone on April 20, 2023, 10:14:40 amNo you missed the point: none of the triggers were missed. I used my very fast MSOX3104T and was monitoring trigger out. It was triggering at 100 packets per second. On screen, you could see waveform frantically flickering, but decoded string under waveform was standing still.. It didn't change. Scope didn't refresh display of DECODED data because changed too fast..Only thing that was pointing to data being non static was waveform.So in order to make sense what is happening here I either have to : segment capture some number op packets and analyse then offline (STOP mode) or capture longer single capture to get multiple packets that way, STOP and analyse online.Again I'm not talking waveform but decoded strings.Real time looking at scope decoding data in Normal RUN mode is useful only if data we are triggering on is maybe up to 5 Hz. That is as fast as I could actually catch a glimpse of something useful.Which funny enough is same for Siglent SDS6000ProH12 (6000A family) and SDS2000HD. They are slower than Keysight but fast enoughif triggers are slower than 5 per second. If you go faster than that both Siglents and Keysight start skipping decoded data in normal RUN mode. Still faster, Siglent will start loosing packets but you won't be able to see that on screen. I had to connect both Keysight and Siglent in parallel and monitor Trig Out with another scope.... But on screen, both will just have some waveform flickering and mostly static decoded data. But looking at screen both are equally useless, decoding wise. You might as well disable decoding and simply look at waveform..So if data to be decoded is slower than some speed both types of scopes will do. If data is coming fast, you need to use segmented or long capture for both... That is what I'm trying to say...

author: 2N3055
author_rank: Super Contributor
timestamp: April 20, 2023, 11:21:46 am
content: Quote from: tggzzz on April 20, 2023, 10:53:48 amI hear you , but it is called "questions and answers", not "lets' ignore questions and show them the errors of their ways.."That is more like priest work...And you and others already mentioned it competently, I had nothing to add...

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2023, 11:27:24 am
content: Quote from: 2N3055 on April 20, 2023, 11:18:32 amLosing packets/triggers to dead time is exactly what the OP was asking about and you've spent 2 pages trying to talk about anything but that. You can contrive all sorts of special cases or say the only thing important to you personally is reading the decoded values, but that is not true for everyone. There are uses for faster triggering on serial data, which the dead time affects, and is not something specified in data sheets.

author: 2N3055
author_rank: Super Contributor
timestamp: April 20, 2023, 11:52:49 am
content: Quote from: Someone on April 20, 2023, 11:27:24 amI keep talking exactly about that. But you cannot be reasoned with. What I demonstrated is that you completely don't understand anything I said....There is no packet loss if you do it right. You can contrive all kinds of special cases and excuses but that doesn't change the facts.

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2023, 03:38:05 pm
content: Quote from: tggzzz on April 20, 2023, 09:22:08 amUnfortunately you are completely wrong here. Malformed packet can have any kind of cause. When looking for a rare problem for which you can't even create a trigger condition, you will want to capture as much information as you can and an oscilloscope with decode is THE tool for that purpose.Same for getting a visual on what bits change to get a starting point on how a protocol is constructed.

author: tggzzz
author_rank: Super Contributor
timestamp: April 20, 2023, 09:35:32 pm
content: Quote from: nctnico on April 20, 2023, 03:38:05 pmI disagree in every respect, and stand by my statements.Ensure signal integrity, then flip to the digital domain.One area where that might fail is with trellis/Viterbi decoders, but a scope won't help with such cases: you need access to the decoder internal numbers.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2023, 10:16:57 pm
content: Quote from: 2N3055 on April 20, 2023, 11:52:49 amGuarantee of zero packet lossisa special case, that's you making the generalisation which is incorrect.Yes it is true for many cases where you know the specific system and what's going to occur and all these non-specified characteristics of the specific oscilloscope used. But that's a whole lot of specifics!Give us a scope and I'll quickly find a way for it to miss triggers and/or data.When debugging an unknown problem how can you be sure that the conditions for "perfect" capture exist? That's the whole point, you are looking for something which is unexpected or outside your existing assumptions. Even in routine production testing where all the parameters should be locked down and the same each time, you still want the highest chance to catch anything unexpected.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2023, 10:26:14 pm
content: Quote from: tggzzz on April 20, 2023, 09:35:32 pmSignal integrity is not always static/consistent, sure you can hit interfaces with designed pathological conditions but even they may miss some nasty bug/interaction in the shape or timing say non monotonic edges :'(The question of system completeness arises again here, is it practical to have signal integrity guaranteed for every end use/state ? Unlikely. Such tests are usually done to some level of confidence + margin but could well haveunexpectedconditions that consistently fail.There are a range of tools and they are all complementary and best suited for specific situations.

author: tggzzz
author_rank: Super Contributor
timestamp: April 20, 2023, 10:51:18 pm
content: Quote from: Someone on April 20, 2023, 10:26:14 pmSignal integrity must, by definition, include rare edge cases. Eye diagrams are a classic way of capturing that.QuoteIf you don't have signal integrity then you are building castles on sand.Yes, I realise modern software is like that, and we all see the consequences every day.QuoteIndeed.The principal purpose of abstraction and layering of systems is that when working at "higher more abstract" levels there are all sorts of "lower level" phenomena that you can ignore. If you can't apply that to design and debugging then you are in the "unfortunate" position of - for example - having to take account of transistor behaviour when designing FSMs.Thus: rigorously keep conceptual levels separate, ensure "lower levels"aresolid foundations, and use the right tool for the level. a more extreme example is the necessity of taking into account theshapeof conductors when designing circuits.

author: Someone
author_rank: Super Contributor
timestamp: April 20, 2023, 11:15:18 pm
content: Quote from: tggzzz on April 20, 2023, 10:51:18 pmI don't think it is practical to encompass every possible case before moving forward, even small systems may never explore their entire possible states. Product specifications can hide this, something can claim an extremely low bit error rate and compliance to various EMC standards without mentioning that the bit error performance is degraded under worst case EMI. Eye diagrams are only testing the conditions they observed some subset of the operation (with blind time too). I've not seen any product claim perfect signal integrity under all end use cases....You can show a product working correctly under your ideal/assumed conditions situations all day long but if the end user is having crashes/bugs under their use case they won't be happy (includes internal customers for larger teams/systems).

author: tggzzz
author_rank: Super Contributor
timestamp: April 21, 2023, 08:23:50 am
content: Quote from: Someone on April 20, 2023, 11:15:18 pmAnd there, in a nutshell, is why so many hardware and/or software products are crap and - after wasting people's life and money - end up in the bin.It is true, of course, that if your product doesn't work, then you can get it to market much more quickly.But an old "Bill and Dave" story is that when a minicomputer didn't live up to expectations, the project manager received a memo from the CEO saying "In future please ensure our products meet the specification before they are released". The manager framed the memo, hung it on his wall, and went on to enjoy a good career. You can guess which company.

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2023, 09:00:08 am
content: Quote from: tggzzz on April 20, 2023, 09:35:32 pmSorry, but with these statements are from a person that has zero real world problem finding and diagnostics skills.In the real world 100% signal integrity doesn't exist. Any communication path will be disrupted, packets will be losts, messages will become corrupted. Over time and number of products in the field, the chance this happens is 1 (100%). This is partly by external influences and partly due to software / hardware interactions (*). In a complex system (which may include third party pieces) a lot can go wrong and when starting to figure out such a problem I go through all the layers of a system and check the interaction between the layers one by one. Where it comes to protocols though, you can have both software & hardware introduced signalling problems. So just looking at a signal and saying it is OK is not enough. Not by a long shot. Because you are looking at a snapshot that covers less than 1ppb of the possible cases. If I would have followed your advice, I would have never found certain issues where software and hardware didn't work well together.* This is also why error detection & recovery is so important to get right. Detecting when a communication bus locks up and recovering from that situation are important to make robust & reliable products. For example: I have seen systems go wrong due to short communication link interruptions which where not handled properly.

author: tggzzz
author_rank: Super Contributor
timestamp: April 21, 2023, 02:23:49 pm
content: Quote from: nctnico on April 21, 2023, 09:00:08 amIf you think about it, the points in your last post do not conflict with the strategy I outlined.

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2023, 03:23:13 pm
content: They do because your strategy is flawed by making assumptions before you can be 100% sure. Making assumptions is deadly when dealing with bugs in systems that contain many parts / modules. I get the eagerness to simplify a problem by ruling out possible causes beforehand but it is counter-productive in the long run.Only a systematic approach that covers all parts/ modules and their interfaces will uncover any existing problem. Having multiple problems with similar symptoms is not uncommon; people trip over this quite a lot because they assume there is only 1 problem at play.

author: tggzzz
author_rank: Super Contributor
timestamp: April 21, 2023, 03:51:18 pm
content: Quote from: nctnico on April 21, 2023, 03:23:13 pmStrawman argument: I never suggested that.Pointless argument:testingcan never makeanything100% sure. At best testing can indicate that you haven'tyetfound a problem. That is, of course, for your strategy.QuoteStrawman argument: I never suggested that you could rule out possible causes by testing.I did, correctly, state that there's an SI problem, then there is no point proceeding further.QuoteBeen there, seen that, got the scars.Nonetheless:verify signal integrity using a scope. If insufficient, fix that before proceedingflip to digital domain and use LA/PA/printf() to debug digital signals including bits, bytes, numbers, packets, messages