This is not a bug, but a request. Currently SPI decoder demands a SCK and this uses one signal line of the oscilloscope. The other signal line can be used for a MOSI or MISO. This can work well if SCK is stable, but if it is not this confuses the SPI decoder and it miss-decodes the data! As shown on the image, where I sent two bytes i.e. 0xAA and 0xBB and they were miss-interpreted. This could be solved by adding an additional signal line CS that would make sure to ignore the unstable SCK before CS goes low (if communication is configured to use active low CS). But now we already need 3 signals for a reliable SPI decoding! And I don't like this, because most oscilloscopes come with only 2 probes! It is possible to solve this if you would design SPI decoder so that user would supply only 2 signals i.e. CS signal and MOSI/MISO signal. SCK can be inputed manually as an integer and in this way we don't need three signal lines! I hopew you implement this! With kind regards!
Created attachment 752 [details] wrongly decoded SPI
Red on black, and can the font be made even smaller please. This is still on the edge of being readable for those who zoom in insanely deep. I won't bother trying to decipher this screenshot, am afraid of getting eye cancer. Seriously: Can you provide the information how to reliably reproduce that setup? Like show the capture if you can and are allowed to, and describe the decoder setup. Is there something wrong with the output given the input that was fed into? Or is the request about "guessing" one of the not provided inputs as comment 1 suggests, while the specific input is question is essential and mandatory? Mind you that guessing is not an option for a PD, and won't be implemented given that decoders are supposed to remain reliable tools and shall not suffer from bad heuristics which still fail to get it right.
An alternative might be to use a math signal that creates a signal of a suitable frequency that you convert to a logic signal. This could then be used as a clock.
Ping. Can you tell what the request actually is? Guessing information that is not provided in the input stream is not an option for reliable operation. Assuming a specific clock signal (that is not provided) is guessing. Nobody said the frequency of such a clock signal is fixed, that's the very point of synchronous communication to have a clock signal which determines when to sample the data lines. And even if you assume a specific frequency, you still don't know its edges' position. So what you request covers very little of the protocol and assumes a lot, and still doesn't work correctly (across transfers). I'm tempted to close this request as won't fix. Just provide the essential input data if you want the decoder to work reliably. Otherwise GIGO.
Closing, due to reporter inactivity, and because there is no reliable approach to the assumed request. So there is nothing that can get implemented, users just need to provide the essential input to get the expected output. No surprise there.