Hi,
I put up together a small UI for this board:
https://libstock.mikroe.com/projects/vi ... nalyzer-ui
It is not able to display the protocol, only the measured signals as they are. Judging by it capabilities, this board would require a direct connection from click's SPI, I2C or UART buses to the onboard PIC's peripherals (18F26K42), to properly decode the protocols. In its current state, it is left to the UI to decode the signals, by simulating the PIC's peripherals. But, this implies data sinchronization and state initialization. I could 'write' such peripherals in the UI app, but they would be useless if the acquired data would be only a snapshot somewhere in the middle of a signal. Imagine the two I2C signals in the middle of a transmission, without the start condition. Or, the SPI signals without the CS line going low. If the UI peripherals would receive such data, they would be undecodable. This is why the protocol analysis has to be done in hardware. Probably, for I2C, this would be a bit more difficult, because the onboard PIC should not act as a I2C device, only as a "protocol listener".
The onboard PIC has PPS, so the mentioned peripherals can be enabled on the appropriate click pins. It just needs a newer firmare to enable all these.
Anyway, I proposed a firmware upgrade, to have oscilloscope-like trigger. This would be a good step towards enabling a state intialization of the simulated peripherals. See
viewtopic.php?f=44&t=78194
Another limitation of the onboard PIC is the small amount of RAM, 4KB. This greatly limits the number of acquired samples, so this is another reason to decode the data in hardware.
As for another low-cost protocol decoder, you can have a look at PICKit Serial Analyzer, from Microchip:
https://www.microchip.com/Developmentto ... s/DV164122.