I think so too, even though the output format is similar to analog. When 8 channels are chosen, then each bit of one byte represents one of the channels. For 16 channels, a sample is stored in a word representing all 16 digital channels.
Anyway, in the meantime I was playing around with the decoding which is a bit tricky as mentioned elsewhere in the forum. So far I only checked the SPI protocol but I am slowly coming to the conclusion that the decoding function has been put together rather quick and dirty. While decoding of slow signals generally works, it will eventually collapse depending on various parameters:
- decoding screen position with respect to SPI signals horizontally shifts and eventually loses the decoding value completely: this depends mostly on memory depth but sometimes also whether the analog channels are on/off - very weird
- decoding screen position is ok but decoding fails depending on memory depth and also depending on clock speed of the SPI signals which is really weird as the signals are captured just fine. For example, a 10 Mhz SPI signal will decode correctly if the memory <7M. As I said, it is only the decoding that is malfunctioning, the waveforms are perfectly sampled
- similar behavior when in auto depth mode: It happens a bit less because the auto function doesn't allow large memory when the sampling rate is getting low which is bizarre in the first place...
It looks like the decoding routine loses correlation/sync between the clock and data signals when the memory gets larger. I used a 10MHz SPI sequence of x0, x1, x2 ... xFF and it is correctly decoded until the memory is set to 7M or reaches 2.8M in auto mode, then the decoding starts to output: x0, x3, x4, x7, x8, xB which would match a 1 bit left shift as my SPI signal retains the logic state of the last transmitted bit. How correct decoding could be dependent on the memory size is more than puzzling to me. How can software fail on this? When it works the scope does a pretty good job displaying the data it in real time so maybe they use some faulty compression algorithm that gets out of sync.
So if you analyzed SPI data that is clocked under 1MHz, you might not have seen these problems.