Impressive Keysight 1000X series (EDUX1002G modded) SPI triggering rate

[rf-loop]

Can 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 UART and IIC (Wire), it is 1000 messages (tested with IIC 32bytes messages and 1 - 32bytes, max decode result length is messages is 1000)

3000

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.

KS 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 signal

Also, these other two images, you set KS for 500ns/div
then you set Sig 200ns/div

Just trying to show that after some packets (which happens to be 3000), SDS1104X-E stops decoding.

You can show it better if you zoom to this position where is last decoded message and start undecoded part

Now 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)

Isn'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...

Are 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.







.

[tv84]

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.

[TK]

Are you seriously asking this question.

Yes, 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?

[TK]

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?

[tv84]

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?

I would imagine that it couldn't be any different from what you are saying! 

[tautech]

TK
Read 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.

[Keysight DanielBogdanoff]

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.

[JPortici]

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.

Yup. 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 data

The 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

[tv84]

The 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

Seems the best of both worlds.

[rf-loop]

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?

Because, 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.

[rf-loop]

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.

Yup. 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 data

The 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

There 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.

[tv84]

@rf-loop, in any scenario of the decoding start position relative to the acquisition buffer, the screen should IMO start always by 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.

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 won't be any worst than what Siglent is doing in the SDS1004X-E by decoding  the first 3000 events bytes and the trigger may not even be present (in that group).     

[TK]

@rf-loop, in any scenario of the decoding start position relative to the acquisition buffer, the screen should IMO start always by 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.

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 won't be any worst than what Siglent is doing in the SDS1004X-E by decoding  the first 3000 events and the trigger may not even be present (in that group).     

I edited my post clarifying that it is 3000 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.

[tv84]

I edited my post clarifying that it is 3000 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.

OK, thanks, didn't noticed that. Nonetheless, 3000 bytes its worse than 3000 events and with so much memory available...

[rf-loop]

I edited my post clarifying that it is 3000 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.

OK, thanks, didn't noticed that. Nonetheless, 3000 bytes its worse than 3000 events and with so much memory available...

Yes 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 frames
Example 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.

It won't be any worst than what Siglent is doing in the SDS1004X-E by decoding  the first 3000 events and the trigger may not even be present (in that group). 

This 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.

[tv84]

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.

[MarkL]

...
Also, the decode is done in hardware and is not based off of on-screen data.

Does that imply another memory pool that's storing the decoded data in parallel to the display data?

If so, how big is that memory?

[thm_w]

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..

Not 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: [Select]

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.

[iMo]

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 bit
2. sample the clk/mosi/miso logic values and analyze the data - Logic Analyzers do it, you need several samples per bit
3. 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.

[TK]

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: [Select]

  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[0]++;
  if (message[0] > '7')
  message[0] = '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.

[TK]

Same capture using Peak Detect acquisition mode

[rf-loop]

Small addendum for SDS1000X-E SPI limits.

It have 3000 byte limit/signal  and one "byte" can be 8 - 32 4 - 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 decode
MOSI 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

[TK]

SDS1104X-E: Is it possible to have both decoders active (DISPLAY ON) on SPI on the same signals using the same inputs?

SPI CLK: CH1
SPI CS: CH2
SPI MOSI: CH3

I 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.

[rf-loop]

SDS1104X-E: Is it possible to have both decoders active (DISPLAY ON) on SPI on the same signals using the same inputs?

SPI CLK: CH1
SPI CS: CH2
SPI MOSI: CH3

I 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.

In 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.

[TK]

Siglent "fixed" the 3000 byte limitation on SPI decode in the new firmware by adding a message that warns the limit has been reached