Hello,
I would like to add analyzer for TDM (extension to I2S).
- Do I need to add both High Level Analyzer Extension and Digital Measurement Extension?
- Does Digital Measurement Extension support process on multiple channels?
Thanks in advance.
BR
@hao.chen Thanks for writing in!
A High Level Analyzer (HLA) extension sits on top of an existing Low Level Analyzer (LLA) such as our existing I2S LLA, and can act as a way to provide an extra layer of decoding. For example, an HLA could translate raw I2S data into a more readable form, and can also combine a sequence of decoded messages into a single message (just a few examples).
As such, an HLA could certainly be developed for our I2S analyzer to perform an extra layer of translation. However, the data format you have shared in your image doesn’t look like it conforms to the 2-channel standard that our existing I2S analyzer follows.
As an example, our existing I2S analyzer decodes data as follows:
- FRAME level dictates the channel (either ch1 or ch2)
- Each CLK rising edge denotes a single bit for the particular channel
- The I2S settings can provide some variation, including Data polarity, number of bits, CLK polarity, etc.
Having said that, our native SPI analyzer might actually be the best place to start! I’ve provided a quick example image below utilizing demo data.
The SPI Enable line could act as your FS line (since it seems to be acting as an Enable line anyways). All clock pulses while the Enable line is high will be ignored. Data will only be decoded while the Enable line is low. You could then set the SPI analyzer to decode in x-bit chunks based on your requiements.
Could this work out as a solution for you? Feel free to share a copy of your .sal capture file if you’ve already taken a capture of your TDM data using our logic analyzer. I’d be happy to play around with it to see if this solution could work.
I am also looking into analyzing some TDM data. Unfortunately SPI is not really an option here, as the sync clock is covering part of the data, so “spi enable” would be a wrong path to take. additionally, TDM is not really such a fixed standard as IIS, but just sort of a hack to send more than 2 channels over an IIS interface, and thus there are some differences in for instance the duty cycle of the sync clock, and also all the other usual I2S quirks.
What we really need is actually a way to either
- Extend the existing low level I2S analyzer with additional channels and a variable size of the word strobe/sync clock (I don’t think we can directly do this by building on top of the existing IIS/PCM analyzer?)
- Get/make a new low level analyzer that has these options available, tailored for TDM (I guess this falls upon you at saleae, as the src for the analyzer DLL’s are not available to my knowledge?)
- Get the abaility to define fully customized low level analyzers
A couple of quick references to explain some basics around the IIS-like TDM protocol(s):
https://www.analog.com/media/en/technical-documentation/technical-articles/ms-2275.pdf
I’ve been playing a bit around with the different settings, and in my case where I have 4 channels, and a frame sync which is low during channel 1, and high during the remaining, I can actually get something readable by setting “FRAME Signal Transitions” to “twice every 4 words” - it’s just doesn’t understand that there are actually 4 channels
And just now, I realized that it should in fact be possible to make a low level analyzer with the SDK - I will see if I can find the time to learn how to do so.
And in fact, the I2S analyzer source is also available, so maybe a fork and some small modifications may do the trick
@esmadsen Ah yes, we do provide the ability to modify our existing analyzers! This seems like the best route to take given your requirements. For anyone that runs across this forum post, here’s the Analyzer SDK below, along with the source code for all of our pre-installed analyzers:
I have just shared a TDM low level analyzer with the community.
1 Like
So awesome! Exactly what I needed!