Impressive Keysight 1000X series (EDUX1002G modded) SPI triggering rate - Page 1
Forum section: electronics / testgear

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 11:35:08 am
content: I recently ran a test comparing the SPI triggering and decoding speed of Keysight EDUX1002G (modded to DSOX1102G) and Siglent SDS1104X-EThe details of the test was posted in a different thread:https://www.eevblog.com/forum/testgear/everyday-bench-scope-a-3-way-race-edux1002a-gds-1054b-sds1202x-e/msg2412507/#msg2412507Summary of test: STM32 nucleo board running @ 180MHz. 45MHz SPI clock. The test outputs 50,000 full cycles of 8 frames from 1 byte to 8 bytes. When a button is pressed, it sends a frame with 1 byte with value 0x3F. Normally one of the 8 frames has byte value 0x37 in the same position.Conclusion: Keysight was able to trigger 50,000 times per second when triggering on byte value 0x37. Siglent SDS1104X-E triggered 3,000 times. The difference is due to the fact that the Keysight is doing Serial triggering and decoding in the ASIC and the Siglent implemented it in software after the memory was sampled.In initial tests, I used a GWInstek GDS1054B and Micsig TO1104 with similar results to the Siglent SDS1104X-E, all of them have serial triggering and decoding implemented in software.

author: 2N3055
author_rank: Super Contributor
timestamp: May 15, 2019, 11:55:38 am
content: It would be interesting to see MSO5000 and RTB2000 doing this.What code and Nucleo board you use?I would like to try this on 3000T to see if mask is faster..

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 12:22:48 pm
content: I am using STM32F446 nucleo board. I am using STM32CUBEMX and AC6 SystemWorkbench (Free IDE).You need to disable LD2 (on board LED) to be able to enable SPI1 to run at maximum of 45MHz.I am getting an MSO5074 next week for the purpose of running the same test.

author: JPortici
author_rank: Super Contributor
timestamp: May 15, 2019, 01:04:13 pm
content: I may try with the SDS5034X.the 5034X has serial triggering done in the FPGA, decoding in software (I actually prefer this, i want to be able to add decoder AFTER. Also, if your decoder-in-asic picks up garbage because of wrong settings, or not high enough samplerate you have to throw away the acquision..) i believed the SDS1000X-E worked the same

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: May 15, 2019, 01:22:20 pm
content: Hello,Is it possible to share your System Workbench project ?I have severals Nucleo F446 and it will be nice to test on my own scope : )Thank you

author: rf-loop
author_rank: Super Contributor
timestamp: May 15, 2019, 01:52:13 pm
content: Quote from: TK on May 15, 2019, 11:35:08 amKeysight is really lot of more fast to trig serial. This is natural due to very different design.Of course also slow software system have still one advantage. It can decode offline. So or so, KS is lot of more fast and thats it.But still I need ask did you all for get best speed using Siglent.Why I ask:I have not system what I can use for this speed of SPI or any other serial trigger and/or decode.So for this I can not say "anything".But if look Siglent maximum wfm/s speed. It is also limiting factor.If it freerun as fast as it can...1 channel on.Display mode dotsDelay 050ns/divNo measurementsTrigger Normal, edgeSignal square (tested with 5MHz and 20MHz)average is roughly 118kwfm/sburst speed roughly 128kwfm/s (between TFT refreshs, there is extra blind time every TFT refresh (40ms period) roughly 3.5ms)1 channel on.Display mode Vextors (Sinc or x)Delay 050ns/divNo measurementsTrigger Normal, edgeSignal square (tested with 5MHz and 20MHz)average is roughly 20kwfm/sburst speed roughly 22kwfm/s (between TFT refreshs, there is extra blind time every TFT refresh (40ms period) roughly 3.5ms)And now, same but 4 channels on. As need be with full SPI.All 4 channels on.Display mode dotsDelay 050ns/divNo measurementsTrigger Normal, edgeSignal square (tested with 5MHz and 20MHz)average is roughly 10.5kwfm/sburst speed roughly 11.4kwfm/s (between TFT refreshs, there is extra blind time every TFT refresh (40ms period) roughly 3.5ms)All 4 channels on.Display mode vectors (Sinc on (x is bit faster ))Delay 050ns/divNo measurementsTrigger Normal, edgeSignal square (tested with 5MHz and 20MHz)average is roughly4kwfm/sburst speed roughly 4.5kwfm/s (between TFT refreshs, there is extra blind time every TFT refresh (40ms period) roughly 3.5ms)As can see even if decode or serial trigger do not affect this make limit, so even if Siglent works hard for make decode faster and tso also serial trigger it can not go very fast due to limits of maximum wfm/s except if they do not make very extremely radical changes.But perhaps if need maximize Siglent speed as it is now, it is good to use display mode dots or least linear interpolation what also (in some cases) may give tiny amount more speed. But dots mode give much more. (If dots mode is selected no matter if there is Sinc or x selected)Normally for digital pulse streams linear interpolation is ok, specially when signal is fast related to samplerate so it do not generate "fake" overshoots. (gibbs ears)I have no idea how much these different settings may affect for high speed serial trigger and decoding speed.(Btw, decoding affect also maximum wfm/s speed. When it capture between TFT refresh not so much but Decode need more time between TFT refresh. (exmple as told in this test, it was around 3.5ms and if I just only turn decode on with some random settings and without serial signals etc, just only push Decode function on. Every TFT period this blind time cap (some processing) rise to around 20ms. What of course drop also average wfm/s speed.(segmented acquisition do not have at all this processing time during acquisition but after sequence, then display processing time is - long - because it overlay all segments to TFT (before start next sequence if repeating is selected) also trig rearm is faster. Least with normal signals, example just with previous test (50ns/div and total 45526 segments) all channels on, 20MHz signal independent of display modes, etc... 320ksegment/s (kwfm)and then one channel in use 487ksegment/s)

author: tv84
author_rank: Super Contributor
timestamp: May 15, 2019, 02:04:48 pm
content: @TK,Could you test with different SPI speeds to see when you get the 50,000 cycles in Siglent and the others?BTW, I think the test you've done is extremely relevant and I find it very strange how, even doing things in software, the Siglent is only able to do 3.000 captures.One thing is HW vs SW, the other is realtime vs post processing...

author: rf-loop
author_rank: Super Contributor
timestamp: May 15, 2019, 02:42:05 pm
content: Quote from: tv84 on May 15, 2019, 02:04:48 pmAs I told in previous message.Even with normal edge trigger 4000 captures/second (aka 4kwfm/s)(4 channels on, 50ns/div, display vectors, interpolation Sinc aka Sin(x)/x)Even when it can maximum average 118kwfm/s with same 50ns/div and one channel on, what is most fast for wfm/s speed and other settings so that maximum can reach but more channels on and not speed optimal settings speed is very different. This is not alone serial trigger/decode thing.(sequence acquisition is then totally different and there it is nearly 10 times faster than KS but this is totally other case.)

author: tv84
author_rank: Super Contributor
timestamp: May 15, 2019, 02:54:52 pm
content: Quote from: rf-loop on May 15, 2019, 02:42:05 pmI can't understand completely what you are trying to say... sorry. But I assume it's not easy to predict the value so some other measures/speed tests would be great.Nonetheless, with all the factors the you seem to be indicating, I find the test a very real scenario and a great demo of performance/architecture.

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 03:07:39 pm
content: Quote from: tv84 on May 15, 2019, 02:04:48 pmDuring the test I tried 1MHz and some other SPI speed and the result was similar, I will test later again but I doubt the SDS1104X-E will get any higher than 3,000 trigger updates per second.

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 03:09:35 pm
content: Quote from: jemangedeslolos on May 15, 2019, 01:22:20 pmI tried to clean it and compress, but it is still larger than the max 1MB allowed by the forum. I will also change the frame output to be different to "Siglent" as it is not relevant to Siglent only anymore, and will find a way to share the project.

author: rf-loop
author_rank: Super Contributor
timestamp: May 15, 2019, 03:29:20 pm
content: Quote from: TK on May 15, 2019, 03:07:39 pmYes, very possible.But still I ask, did you use dots or vectors display because it is just there around in borderline affecting or not affecting with this t/div (50ns/div in your image) and all or 3 channels on. (and then if also decode is on, it drops more due to longer blind time cap, once in every TFT refresh 40ms period. I do not mean between acquisitions blind time what is other but independent thing in scope processing)Even without serial trig and/or decode maximum wfm/s speed is as told previously.But as you can see maximum is different depending also display etc settings.With serial trigger of course it can not be faster than with normal edge trigger or without signal auto free run.So, with this 3000/s result. With dots or vectors mode? If vectors mode was it Sinc or x?

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 03:40:34 pm
content: Quote from: rf-loop on May 15, 2019, 03:29:20 pmOn both scopes I used vector mode. I remember trying decode on/off and the result was similar on the Siglent. I will test dots mode later

author: tv84
author_rank: Super Contributor
timestamp: May 15, 2019, 03:50:29 pm
content: BTW, why all others stick at the 3.000 mark?Their characteristics are not so similar...This is indeed very interesting/intriguing...I'm trying to decide on what equipment to buy and now you've thrown this cold water bucket....

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 04:04:03 pm
content: Quote from: tv84 on May 15, 2019, 03:50:29 pmI am sorry, on the Micsig it is around 340... Probably I stopped measuring all of them when I was getting between 300 and 1-3K and I continued pushing the limit with the SDS1104X-E and Keysight and forgot about the others.

author: TK
author_rank: Super Contributor
timestamp: May 15, 2019, 11:38:48 pm
content: Another interesting capture. Keysight triggers correctly on 0x37 and decodes the SPI frame (0x37 0x45 0x45 0x56 0x42 0x4C 0x4F 0x4F = "7EEVBLOG"), even when the waveform is very distorted, almost beyond recognition due to having only 1Mpts sample memory. It was captured with timebase @ 1ms, acquisition: 50MSa/sSiglent SDS1104X-E capture at 1ms timebase, 500MSa/s, 7Mpts sample memory. Waveform looks OK, but cannot decode... it runs out of decode memory

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: May 16, 2019, 04:50:31 am
content: Quote from: TK on May 15, 2019, 11:38:48 pmThat's pretty interesting, I suspect it has something to do with the way the trigger system works. It's *possible* that the trigger's signal path does some edge cleanup with comparitors to get a good trigger, even if the capture is undersampled. I know that internally the ADCs sample at full rate all the time regardless of the time/div, so that could be it too. It would be interesting to see this same capture in peak detect mode and see what the bus looks like.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 05:00:08 am
content: QuoteCan you open Siglent decode list when it is running (or both stop and running) (image where is 1ms/div) and tell how many messages it have totally decoded, as you can see in image left bottom there is decoded (MOSI) and light blue mostly tell, without errors. First over 1.5ms from beginning of acquisition.It have many times told that Siglent have limits in decode result. I have not measured it using SPI but with UARTandCORR/ETA: it is 3000 for both simultaneous decodersand IIC (Wire), it is 1000 messages (tested with IIC 32bytes messages and 1 - 32bytes, max decode result length is messages is 1000)Then open also KS decode list when it is running (or both, run and stop) (image where is 1ms/div) and tell how many messages it have really decoded in decode list. And what mean this bottom decode display (S1) color change and gap around 1ms from left. And why it show 350kHz.Also, these other two images, you set KS for 500ns/divthen you set Sig 200ns/divAlso you explain that signal is crap... as can see in KS 500ns/div iomage. Yes it is. Compare this signal with Siglent 200ns/div display. Signal is not so crap.If you compare, is it better that you keep even bottom basics same.On the KS screen I think you do not even see this "waveform" what its trigger and decode system see. (due to its very extremely different circuits - is it analog side pathway trigger system? and is it so that same analog side pathway is used for hardware decoding circuits what also mean of course that it can not at all decode offline. When sofware system as Siglent, can do. Example decode from wfm history buffer collected from normal run or from segmented memory (what is nearly 10 times faster than KS) But positive thing is live (run time) speed what software decode (Siglent) can not)

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: May 16, 2019, 05:51:03 am
content: Trying to avoid a rep war here, sorry everyone! Regarding online/offline decoding, the Keysight InfiniiVision scopes decode whatever's on screen nearly instantaneously with the ASIC as discussed above. Even changing the time/div setting on a capture will cause the scope to re-decode the screen. This is part of the speed, it only processes what you can see & analyze and ignores what's off screen.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 07:42:05 am
content: Quote from: Keysight DanielBogdanoff on May 16, 2019, 05:51:03 amNo rep war at all. Just for this I also make question to TK. Because some things he show looks bit weird. If you do not recognize these things, sorry.And also it is well recognized KS is amazing fast.But then other thing, Daniel..I have heard many times (not tested myself) that KS can not offline decode.This is now good place correct this "rumor" if it is true or not.So, turn normal acquisition on. Trigger (example) edge.So that this capture include, (example) simple UART signal (so that also most users can test it without needing nearly anything)After then, stop scope and even if want disconnect signals.Now there is acquisition - UART data stream.Turn on Decode.Now it is decoding offline (as I think what is offline). Just from memory without any live signal decoded until scope is stopped and after then asked fore decode it.Also it can test using segments. Capture segments (without decoding or even wqithout serial trig)After then look segments and start decode what is there.Can it do it or not. Simple question yes or no.If yes then we need shoot down all these wrong claims and rumors.I have used Hewlett-Packard test instruments made over tens of years. I have (mostly) deeply respected things what they promise and how all have manufactured.. Today marketing materials and salespersons words looks bit different.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 08:12:06 am
content: Quote from: TK on May 15, 2019, 11:38:48 pmI believe it is not decoded from this waveform what you see on screen. There in display you see waveform what is produced and displayed using after ADC decimated samples. This useless junk wfm can not be what Decode process use if all you told about test signal is ok. It is somewhat easy to deduce. (and it can clearly also see if you look same signal in Siglent display. (I believe signal is same)What is real input to Decode processing or serial trigger circuit in KS. Least it is not decimated sample stream. Is it using analog side pathway - comparator principle? I really do not know anymore...

author: TK
author_rank: Super Contributor
timestamp: May 16, 2019, 11:02:22 am
content: Quote from: rf-loop on May 16, 2019, 05:00:08 am3000BytesQuote from: rf-loop on May 16, 2019, 05:00:08 amKS 1000X does not have decode list. I think it shows 350KHz because it is trying to measure on CH1 that has a distorted waveform and it is not counting the actual 45MHz SPI clock signalQuote from: rf-loop on May 16, 2019, 05:00:08 amJust trying to show that after some packets (which happens to be 3000), SDS1104X-E stops decoding.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 11:47:31 am
content: Quote from: TK on May 16, 2019, 11:02:22 amYou can show it better if you zoom to this position where is last decoded message and start undecoded partNow it looks weird (specially alone this 200ns image because there was not any decoded packet and it looks like .. oh Siglent can not decode at all but then you show KS what have decoded. Nearly like some biased intrument owner except that I do not believe this is case at all.But how you get decode result out from this image where KS t/div is 1ms.Also you did not answer this question about KS bottom image decode display question. How many messages it decode in this image?If there is not decode list with time position and data how you look decoding result at all with this setting. I mean, what is purpose of Decode if result is unavailable.If it is unavailable (difficult to believe that it can decode but can not show result - it do not feel weird if it is some unknown junk but front panel label read Keysight (aka raped Hewlett-Packard) or if it need more exercise how to use these very different machines for get out decode result. As we also know different vehicles driving need different handling.Ok. So with SPI it have limit 3000, more than with IIC what have limit 1000. (32000 bytes)

author: TK
author_rank: Super Contributor
timestamp: May 16, 2019, 12:28:47 pm
content: Quote from: rf-loop on May 16, 2019, 11:47:31 amIsn't SDS1104X-E decoding after the capture? Then why when capturing at 1ms timebase, it decodes 3000 packets, then when I change the timebase to where it triggered, it doesn't decode what is being shown in the screen? Wasn't it supposed to decode whatever is in shown as waveform in the screen? It is a bug or doesn't make any sense to me.The color change in the KS decode information when showing at 1ms timebase is a visual effect. You can move wherever in the 1ms capture and change timebase to 200us or whatever and it will show the correct decoded information, without need to do another capture.So I am not sure which scope is doing post decode and which not...

author: iMo
author_rank: Super Contributor
timestamp: May 16, 2019, 12:49:13 pm
content: Capturing SPI is easy. Rising clock edge takes the data. 45MHz SPI could be decoded by $1 CPLD (or a 10cent 74HC shift reg). No special processing is needed. It could be the KS is simply reading SPI data that way, while the others mess with an analysis of the sampled waveforms.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 02:09:46 pm
content: Quote from: TK on May 16, 2019, 12:28:47 pmAre you seriously asking this question.Is it now best that we stop and start lessons about how oscilloscope work.But if really need it, I can tell it is long road. Least I'm too old for it.But, I hope this help even tiny bit.Oscilloscope have been running with timebase 1ms/div and there is now whole memory full of ADC samples. There is data before trigger and after trigger. (I hope I do not need start explain also how it works with pretrigger part and post trigger part when it is running, perhaps waiting trigger and so on.)But then you stop scope. Acquisition stops.And at this point we think there is one full acquisition in memory, in this case 7M.As you can also see in image decoding starts from beginning of memory what is FAR before trigger position. There is nearly 3.5M samples before trigger.Decoding starts from beginning of memory, around 7ms before trigger position.Due to decode result length limit 3000msg (what I have not confirmed) there is so many messages (your speed and scope speed) that limit is full well before 2ms after beginning of memory.Scope is now in this situation stopped, 3000msg decoded there in beginning of memory.Then you have turned t/div know for zoom in. And where this your zoom happen if think place in memory. It happen just around center of memory where is still signal but where is not decoded result because max limit is reached far before this position in memory. (now, example if you slow down your SPI example 1:7 and keep this 1ms/div then decode message limit 3000 is reached far after center of memory and if you in this case again zoom just center of memory you can also see there is decode result. Of course. But also, with your original setup, if you zoom to this area where is decoded you see it. In stop mode you can zoom in and out with full window and move also what part of memory you want look (horizontal move, with Position knob or navigate.)I think, most of times with these kind of cheap scopes are typically used in practice, these message length / amount limits are not reached in common typical cases.But then, this KS. It works very different. Of course if it decode runtime with hardware decoder and then you stop scope and zoom in. You zoom also this decode result. But, as example, in this case, what you see after zooming if you look signal, it is not even useful at all but still you see perfect decode. How it correlate to signal. Well, as can see is is nearly same if this signal is not visible because it is not what is decoded (I can not confirm this but I believe)Because KS decode is fast it do not matter anything and if there is enough memory ther do not limit decode result length and also it perhaps do not slow acquisition.But, Siglent (and many others) need after acquisition analyze this signal from stored ADC data after it is first stored. I think if do not cut amount of maximum decode result length (not ADC data length) it may lead situations where it goes really really slow. (In Siglent, there is well enough memory for much longer max limit so it is not memory question. I believe it is time question and just some kind of compromize when think normal common using cases - who knows)But Im surpriced KS can decode but it do not have decode result table where can see and what full length table can save example for later analyze to USB flash in .CSV format..

author: tv84
author_rank: Super Contributor
timestamp: May 16, 2019, 03:15:48 pm
content: So, if I understood correctly, what's the advantage of the KS? A correct event counter?If I can't analyze the events being counted... or can't relate them to actual wave captures...If that's the case, I prefer Siglent's way.Nonetheless, shouldn't be so hard to implement a algo that decided the number or captures based on the actual restrictions of the signal instead of always setting it to 3000.

author: TK
author_rank: Super Contributor
timestamp: May 16, 2019, 08:16:51 pm
content: Quote from: rf-loop on May 16, 2019, 02:09:46 pmYes, I am seriously asking this question, because something doesn't add up. I read in this forum that KS has only 1Mpts memory, that is not enough and you cannot do a long capture (10ms in this case) and see any meaningful result. And that Siglent has 14Mpts (or 7 Mpts when more channels are enabled), it can capture tons of information and I can decode after the capture, without doing a recapture, etc etc... but In my test, I can sample 10ms with the KS, zoom anywhere within the 10ms capture and see a valid decoded information. On the Siglent, I can capture 10ms, but I can only see decoding on the first 3000 bytes (not even frames), it triggers in the middle of the 10ms and I zoom in and I don't see any SPI decoded information. That is I am asking, because If siglent decodes after the capture, why it is not showing when I zoom at the middle of the 10ms capture?

author: TK
author_rank: Super Contributor
timestamp: May 16, 2019, 08:29:46 pm
content: I am triggering on byte 0x37, and when I capture 10ms, scope stops with the trigger mark at 5ms, so I see 5ms pre-trigger and 5ms post-trigger. It triggered correctly on 0x37, but when I zoom why I do not see the decoded information, because Siglent decided to decode only 3000 bytes at the beginning of the first 5ms. Why not show at least 1500 bytes pre-trigger from 5ms back, and 1500 bytes post-trigger from 5ms ahead?

author: tv84
author_rank: Super Contributor
timestamp: May 16, 2019, 08:33:44 pm
content: Quote from: TK on May 16, 2019, 08:29:46 pmI would imagine that it couldn't be any different from what you are saying!

author: tautech
author_rank: Super Contributor
timestamp: May 16, 2019, 08:49:48 pm
content: TKRead rf-loops post again as it makes perfect sense to me and is a good lesson for all of us to understand.Then open the decode list for the Siglent and examine the last byte timing correlation WRT the trigger position (0s).As there is no list in the KS we do not know where/which the decoded byte belongs.....I think I have this right.Therefore we can surmise all of the KS memory is instead centered of the 0s trigger position.

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: May 16, 2019, 08:56:02 pm
content: I did some digging on this, and the InfiniiVision scopes don't decode on previously-captured waveforms. For example if you capture/stop/single, THEN turn on decode it won't decode. If you have decode turned on when you capture it'll work fine. R&D says this is a trade off you have to make when doing hardware decode instead of software decode. If you really wanted it, you could use Infiniium offline + serial decode options but it would be cost prohibitive in many situations.Also, the decode is done in hardware and is not based off of on-screen data.

author: JPortici
author_rank: Super Contributor
timestamp: May 16, 2019, 09:05:27 pm
content: Quote from: Keysight DanielBogdanoff on May 16, 2019, 08:56:02 pmYup. And i also bet that the decoder is ALWAYS running at full samplerate or anyway at a higher samplerate, which is why it can decode on what appears to be heavily undersampled data.This is the very same problem i had with the RTB2000/RTM3000. It's all fine until you see you didn't set the thresholds properly, or your samplerate is too low...And hardware decoder means that is probably heavily optimized, which can lead to some issues: It didn't take too much effort to break the I2C decoder on the RTB2000. I was running at the non-standard clock rate of 800kHz, but i needed far higher samplerate than i would have expected. The SDS5000X showed the correct dataThe new siglent and i want to say also lecroy? use a hybrid approach: Trigger in hardware, decoding in software. Trigger on condition, then decode and find out the context later.. It will lead to a higher blind time, but in practice i find it to be an acceptable compromise

author: tv84
author_rank: Super Contributor
timestamp: May 16, 2019, 09:14:28 pm
content: Quote from: JPortici on May 16, 2019, 09:05:27 pmSeems the best of both worlds.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 09:20:24 pm
content: Quote from: TK on May 16, 2019, 08:29:46 pmBecause, after captured one whole memory length it start decode and it start decoding from beginning of acquisition until limit is reached. Your trigger is positioned to middle of memory length. Limit is reached before this pointg. Now if you zoom in here in trigger position there is no decoded results.Of course if system designer want do, he can do it so that first it look where is your trigger or zooming center point and then position center of decode result to this point. How it then display every decoded message or byte right time position related to original trigger position. I think it may only produce confusion or make system bit complex if you think all possible sitiation how serial data stream can be. It can be also so that there is random/semi random time between transmissions.I think it is most wise to keep these just there in memory where they have been when captured and time position to trigger what is true when captured to memory - for avoid confusions.But then, if not need keep trigger position in center of memory (this is only default) why do not set trig position what is more suitable for user. There is even setting for force trigger position to fixed position or to fixed delay (default) mode. You can set it to left side of screen and force it keep this position even if you then change t/div in run or stop mode as "zoom".(related to this trigger position (fixed position mode) there is bug or bad design when use window zoom. Even if trigger position is fixed to other position (fixed position, not fixed delay) on the screen, zoomed bottom window delay is still based to center of display, not based to trigger position.Also if you turn decode list on, it can display full decode result also in stop mode and/(or) if you are zoomed in and looking position where is not decoded result, decode list show whole decode result with time stamps related to trigger / center (but only 7 row at once and what user can scroll or select using virtual panel).Oscilloscope is mainly for YT analyzing and it need keep captured things as perfectly as possible with time relation to trigger. If decoded things are are all before trigger they need also keep there and not move before user think they are more nice in other time position. If there is decoded signals before or after trigger they need keep original capture time positions - related to trigger. Also screen clearly show where they are, so it is not difficult to move and look them after is familiar with scope handling and controlling (and this is important, different machines need different handling and it take time before it is stored in human muscle memory)All parts of signal (decoded or not) need keep just tightly right original time positions related to trigger. Other ways we loose whole idea about oscilloscope as YT analyzing tool. Things must not move just for make user more happy. If user is not happy about what time things are related to trigger perhaps some other tool is better than oscilloscope.

author: rf-loop
author_rank: Super Contributor
timestamp: May 16, 2019, 09:47:24 pm
content: Quote from: JPortici on May 16, 2019, 09:05:27 pmThere is also one, imho, severe disadvantage (of course lot of advantages also)It can show decode result on the scope screen and also analog captured signal but... in worst case captured and displayed signal can be totally different what is decoded. (it can also see in some TK's images) Decoder - trigger are not looking same signal what is produced from ADC data and displayed.It is bit same with normal trigger what use conventional analog side pathway system. Trigger comparators looking signal is more or less different (in some possible cases lot of) what is displayed signal after ADC. (also this may have advantages and disadvantages)With digital side trigger engine ADC data to trigger and to display is perfectly same.And when decode is done from this data signal on display is exactly same what is also used for decode.But, naturally, with cheap systems (no enough brute force for processing) it reduce speed. Some times we do not need these super speeds. There is perhaps many things what also are important. Just heard that this KS do not have decode list what can save for documentation or for later/further analysis. In this 1ms/div TK's image if scope is running it can fast trig and decode but it can not show any decode result, until stopped and/or zoomed in it can show tiny part "something".. I say "something" because displayed signal can be different what is decoded.

author: tv84
author_rank: Super Contributor
timestamp: May 17, 2019, 09:28:57 am
content: @rf-loop, in any scenario of the decoding start position relative to the acquisition buffer, the screen should IMO startalwaysby showing the decoding on the trigger position. If you configure that position to the center, left, right, etc, the initial image should always start in the position of the trigger.Quote from: rf-loop on May 16, 2019, 09:47:24 pmIt won't be any worst than what Siglent is doing in the SDS1004X-E by decoding the first 3000eventsbytes and the trigger may not even be present (in that group).

author: TK
author_rank: Super Contributor
timestamp: May 17, 2019, 10:26:54 am
content: Quote from: tv84 on May 17, 2019, 09:28:57 amI edited my post clarifying that it is3000 Bytes. I couldn't find a way for SDS1104X-E to list packets or frames instead of bytes on SPI decode list... MOSI (or MISO) shows bytes in the list. The SPI packets are framed by ~CS and range from 1 to 8 bytes, but it is not shown by SDS1104X-E... I might be missing something but I am sure I checked all the options in the menu.

author: tv84
author_rank: Super Contributor
timestamp: May 17, 2019, 10:54:33 am
content: Quote from: TK on May 17, 2019, 10:26:54 amOK, thanks, didn't noticed that. Nonetheless, 3000 bytes its worse than 3000 events and with so much memory available...

author: rf-loop
author_rank: Super Contributor
timestamp: May 17, 2019, 01:03:54 pm
content: Quote from: tv84 on May 17, 2019, 10:54:33 amYes it is bit low. But other side is our enemy, refresh time. So it is compromize between many things. But still it is low.Example with IIC it have limit 1000. But every message, event, how we name it, can have example 32 bytes. So this limit is 1000 pcs max 32 byte messages.I have never tested SPI and I'm now bit surpricced it do not handle these as framesExample with IIC there is even possible to select "long" data window to list, what show selected list row long data (list row itself have not room for long data).But then we need, I think, handle also this.QuoteThis is but more complex thing because oscilloscope need work some way, But users do so many different things with scope that if make one satisfied then other is unsatisfied, until there is some configuration table where user can define how he want it works.Perhaps whole this (last guoted) thing is better handle in some other place using many different approach directions and landing angles.It need remember that trigger can be what ever trig and it is not forced to married with serial decode at all. Perhaps I get some signal from system, pulse or what ever what I want produce trig and then I want see what happen in system after trig but also before trig. Of course it can be serial data etc what produce trig but it canm also be many other things. When trigger happen, what ever it is, it is important to keep all captured data tightly at these time positions related to trigger what have been case when acquisition happen. This must nearly never break.But why user want position trigger to center of acquisition memory. It is fully in user hand and he can set trigger position how he need and want. So, if user know how to use oscilloscope he can set it as he need. No need follow factory defaults at all.If user want trigger is beginning of acquisition memory then he need himself set it to beginning of acquisition memory. No other one do it for him, also oscilloscope do not think he set it or move things to more near or around trigger because user forget to set it as he need. Of course scope can guess what is important for user and "he" know what user is doing? My opinion is that I am Master and scope is Slave until it is more wise than I. But how I know it is more wise than I. Perhaps I need ask scope.If I select horizontal for 1ms/div and need trigger is start of memory why not move it to this point. User know what he newed - mostly - or if user do not know what he need perhaps then need first think what need and then, after then, do it.If set trigger to left side of screen (7div left from center) it is then just beginning of memory. With Siglent user know when scope is running memory begin exactly left border and end right border of screen signal area. No overlap. So it is also easy.When trigger is in wanted position user can also FIX it to this position (fix to display position is functinally same as fix ti capture memory position (because display signal area x is exactly length of current memory length when scope is run mode or not zoomed). So, that if example stop scope and zoom in this trigger position is fixed and more zoom his display range is more and more near trigger position. (factory default is that trigger position is fixed delay related to display center. And if this default is in use and user have moved trigger off from center. After then if he change time base (in run mode or stopped for zoom this trigger position move on display but he zoom more and more in and position is center of memory.In this case what what TK show stopped 1ms/div and then zoom in to 200ns/div. If he have set trigger to example beginning of memory and changed in Utility menu "reference pos" for "Horizontal Fixed Pos".(!) Now wit this setup if he stop scope same way and there in beginning of memory is this decoded part. Then he zoom in using t/div -- after enough zoom in, he do not see undecoded part of signal. He dive inside decoded part.With poor language this is pain to try explain and leads esy to misunderstanding.Also with this system perhaps user need first unlearn some of other scope handling habits and later his muscle memory start follow new habits and then less problems.But now there is "one" bad thing. Perhaps some programmer in Siglent have not enough knowledge and experience about doing works with scopes in real world. It can not explain other way how they have implemented oscilloscope windowed zoom. Or then it is accidental bug. Before they correct it it may confuse users very badly, specially after users start using more this trigger fixed position set up. When user meet this what happen he may think whole feature is useless crap. If understand this error, with it can live but still it is confusing and really not nice. Problem is how they position zoomed area in upper window and how they handle displayed trigger position delay / zoomed window delay. This is perhaps one reason why users now do not use this scope with some advanced settings or mode of operation.Of course all can design different, UI logic can be different, all can be different. But it need remember, there is thousands of different needs, different cases what we do with scope and so on. Including also that trigger can come from Grandmother's Cuckoo Clock in Ch 2 and signal is perhaps CH1 UART and CH 3 from motor speed and 4 from seismograph. So, why one want when stop scope and then zoom in, then it jumps to decoded part of memory - why it did not jump to seismograph position where happen something because just for me it is more important, even when I have turned decode also on. Repeating: User is Master and scope need stay as Sub. Now and yesterday, tomorrow is fully unknown.

author: tv84
author_rank: Super Contributor
timestamp: May 17, 2019, 01:41:04 pm
content: I understand the complexity and the need to please different quadrants.But, IMO, the best way to deal with this is the one JPortici hinted the SDS5000X is using.

author: MarkL
author_rank: Unknown
timestamp: May 17, 2019, 03:20:27 pm
content: Quote from: Keysight DanielBogdanoff on May 16, 2019, 08:56:02 pmDoes that imply another memory pool that's storing the decoded data in parallel to the display data?If so, how big is that memory?

author: thm_w
author_rank: Super Contributor
timestamp: May 17, 2019, 06:27:09 pm
content: Quote from: 2N3055 on May 15, 2019, 11:55:38 amNot sure about OPs method, but if I use a logic analyzer on MSO5071 trigger output:- 1k mem depth then I get 1,000 triggers in a time of 24.3ms or 41,000 per second. There is a short "blind" period of 5ms (17%)- With the zone trigger in place, I get 102,000 triggers in 1s with a blind period of 4.8ms (0.5%). Which I don't really understand, why is it triggering this much? It seems to be caused by turning zone trigger on.If I send ~50,000 14 byte packets per second (40MHz SPI clock), then use SPI trigger and zone trigger on this different value, the scope updates about once every second or two. Seems like its capturing almost all of the data.This is the sort of work I would use a logic analyzer to do (as mentioned). Not saying an oscilloscope should never or can never do it, just that its more effort to implement well in hardware than doing the software analysis on a PC (Sigrok is amazing).Code:while (1){HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, led);led = !led;for (i = 0; i < 50000; i++){HAL_SPI_Transmit_DMA(&hspi2, buff, 14);}HAL_SPI_Transmit_DMA(&hspi2, buff2, 14);while (HAL_SPI_GetState(&hspi2) == HAL_SPI_STATE_BUSY){}}edit: I am using channel 1 and channel 2 to input to the scope. Haven't tried the actual LA inputs yet.

author: iMo
author_rank: Super Contributor
timestamp: May 17, 2019, 07:20:42 pm
content: There are 3 ways to capture/decode SPI:1. sample the clk/mosi/miso analog waveforms with 3 ADCs (3 channels) and analyze the data - some o'scopes do it, you need several samples per bit2. sample the clk/mosi/miso logic values and analyze the data - Logic Analyzers do it, you need several samples per bit3. you write SPI's mosi/miso data into a shift register with the clock's edge, like any simple SPI device does, you get a bit every clk edge.With 1MSample memory you get 1MB of SPI data with the 3rd way (or more when using RLE) and the data in the memory are already decoded. With 1st and 2nd you have to analyze the samples and you get much less SPI data out of the 1MSample mem, of course.

author: TK
author_rank: Super Contributor
timestamp: May 17, 2019, 10:11:03 pm
content: This is what my STM32 board is generating:Frame 1: "0"Frame 2: "1E"Frame 3: "2EE"Frame 4: "3EEV"Frame 5: "4EEVB"Frame 6: "5EEVBL"Frame 7: "6EEVBLO"Frame 8: "7EEVBLOG"with 45MHz SPI clock in a continuous loop with the micro running @ 180MHz. I measured 50,000 Frame 1 to Frame 8 per second.Code:while (1){if (sendff) {HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, RESET);HAL_SPI_Transmit(&hspi1, ff, 1, 10);HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, SET);sendff = 0;} else {HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, RESET);HAL_SPI_Transmit(&hspi1, message, (uint16_t)(i%8)+1, 100);HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, SET);i++;//HAL_Delay(1);message++;if (message > '7')message = '0';}/* USER CODE END WHILE *//* USER CODE BEGIN 3 */}I am using blocking SPI transmit on the STM32 to have a more consistent timing, and the first part where I check for "sendff" is that I am sending 0x3F instead of the regular frame when a button is pressed on the STM32 and see if the scope can capture this random event while it is decoding SPI and triggering on byte value 0x37.

author: TK
author_rank: Super Contributor
timestamp: May 19, 2019, 12:52:24 pm
content: Same capture using Peak Detect acquisition mode

author: rf-loop
author_rank: Super Contributor
timestamp: May 19, 2019, 03:20:25 pm
content: Small addendum for SDS1000X-E SPI limits.It have 3000 byte limit/signal and one "byte" can be8 - 324 - 32bit (or example 4x 8bit bytes but it can not decode these separately as "framed" by CS but it decode these as 32 bit and bytes need separate with eyes. (or using some software when analyze saved decode list).If there is simultaneously running Decode 1 and 2 it can decodeMOSI 1, 3000 4-32 bit "bytes"MISO 1, 3000 4-32 bit "bytes" Decoder 1 List in this case 6000 rows what each include 8 - 32 bit "byte".MOSI 2, 3000 4-32 bit "bytes"MISO 2, 3000 4-32 bit "bytes" Decoder 2 List in this case 6000 rows what each include 8 - 32 bit "byte".It can show only 1 decode List, Decoder 1 or 2. Not both Lists simultaneously.With only 4 analog channels (I have not MSO ption)I can only test this limit so that I connect same ( 1pcs MOSI) to MOSI and MISO to both decoders and same CS to both decoders and same Clock to bot decoders (because only what need is confirm these limits)Image 4 pcs 8 bit in one CS period decoded as 32bit(used 4MHz clock SPI, ATmega32u4 board)Other image just 8bit bytes and no CS

author: TK
author_rank: Super Contributor
timestamp: May 19, 2019, 05:25:34 pm
content: SDS1104X-E: Is it possible to have both decoders active (DISPLAY ON) on SPI on the same signals using the same inputs?SPI CLK: CH1SPI CS: CH2SPI MOSI: CH3I don't see any activity on decoder 2. I tried feeding UART signal on CH4 and decoder 2 set to UART and it shows both protocols, but no decoder 2 information if both are set to SPI.

author: rf-loop
author_rank: Super Contributor
timestamp: May 19, 2019, 09:05:14 pm
content: Quote from: TK on May 19, 2019, 05:25:34 pmIn my previous images.Both decoders active, both decoders connected to same inputs.(Of course with only 4 analog channels 2 independent SPI decoders nearly useless)Before they work, both decoders inputs need configure separately even when they use same inputs. (levels etc) I have tested it also so that same inputs but Decoder1 use 32bit data and decoder2 use 8bit data.Previously I told data length can be 8 - 32bit. It was mistake. Right is 4 - 32bit.

author: TK
author_rank: Super Contributor
timestamp: May 24, 2019, 01:47:57 pm
content: Siglent "fixed" the 3000 byte limitation on SPI decode in the new firmware by adding a message that warns the limit has been reached

author: tv84
author_rank: Super Contributor
timestamp: May 24, 2019, 02:31:44 pm
content: Quote from: TK on May 24, 2019, 01:47:57 pmNice fix!!At least they can't be accused of fooling the customer...

author: TK
author_rank: Super Contributor
timestamp: May 30, 2019, 07:51:33 pm
content: I gave the Rigol MSO5074 one more chance... I had to sell my EDUX1002G)I ran the same SPI test @ 45MHz test:The Rigol MSO5074 can trigger 2,000 times per second (byte 0x37) (VS 50,000 on the EDUX1002G)And it cannot detect random byte 0x3F (using MASK TEST) while triggering on byte 0x37EDIT: I was able to get 50,000 triggers per second on the Rigol MSO5074 by setting memory depth to auto (it uses 1Kpts). And I also was able to catch the random byte 0x3F on the Rigol 100% of the time while triggering 50,000 times on 0x37 by using infinite persistence and also 25% using zone triggering.