This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PCM4201EVM: Signed or unsigned data and extra bit

Part Number: PCM4201EVM
Other Parts Discussed in Thread: TPS63700

Dear Team, 

First of all, the EVM kit is working like charm since the beginning first time that I've plugged in to a decoder. No technical problems so far on that aspect.
The overall quality of the board and components is astounding so, the cost is totally justified. Congratulations! 

Now, let's go to the doubts:

1. I'm integrating this ADC as part of a bigger solution. I want to send the serial  data (not SPDIF) to a MCU to process it and route the audio.
The MCU is a Cortex M4 (32bit) but with a hardware i2s interface and I'm using plain C.    

I've seen that the i2s specification sends the data signed as two's complement with the MSB (most significant bit) first.
So, from here I extract 2 doubts, if the word-length is 24bit and it's signed, do you add an additional bit to indicate the sign of the number? Or it's integrated into the 24 bit word. 
Here's a scope example with a "1" on the MSB and I see that rises half clock cycle sooner than WordSelect clock, is that normal? Please, see the attached image. 



Given this case, may I treat this data as unsigned integer as the word itself contains the sign information? 

2. I think that I'll need to treat the data as the device (my MCU) maps the memory as 32 bit blocks. 
0 to 23 is the data and 24 to 31 is sing extended. 
I understand that I can get rid of those extra 8 bits when I send them to another interface in order to reduce the bandwidth needed, am I correct?

Thanks for your time and attention. 
Best regards,

Pablo. 

  • Hi Pablo,

    Two's complement is inherently a signed binary representation so this is contained in the data word already and there are no extra bits for this.

    It does look a bit odd that your data output rises a half clock cycle earlier than the FSYNC, but this could potentially be toggling from noise on the right channel. Also note that the output of this device is not I2S, it supports Left-Justified or DSP-mode output and this means the data is not offset from the FSYNC edge. Your MCU needs to support this mode to properly interpret the data.

    You are correct that our device only outputs 24-bit data, so the additional 8 bits your MCU stores are not needed. 

    Best,

    Zak

  • Hello Zak,

    Thanks for the info about the data words. This will save a 25% of the bandwidth than using 32bit words with 2 byte of zeros :).
    Is good to know that I can ignore the extra byte. On the other hand I have to deal with the program to do so.

    About the MCU, yes, I can choose between I2S and left or right aligned so I shouldn't have problems with that. Thanks to comment the point.

    And, bout the right channel, this ADC is mono and the differential input is fed from a line driver (THAT), so it doesn't make so much sense that I have noise from the right channel. I should not have any problem with that as far as the WS clock is the event that the decoder expects to start receiving the serial bits, am I right? 

    Thanks a lot for the quick response. 
    Best regards, 

    Pablo. 

  • Hey Pablo,

    You are absolutely right, you are using the mono version of the device so there is no possibility of interference from other channels. I am still a bit surprised that the data output rise a half cycle earlier than the WS, is it possible this is a delay in the measurement setup? It looks to me like BCLK and DOUT are synchronized as they should be, but the WS is a half cycle delayed in the capture. This doesn't make much sense to me because the FSYNC pulse should initiate the data transfer. Is this impacting your measurement results at all?

  • Hi Zak, 

    For your peace of mind, no problem at all with the half cycle. 

    1. As the ADC is mono, the right channel info contained in that frame will not be ever considered in any setup.

    2.  If you confirm that the first bit is synced to FSYNC, again no problem at all, I'm receiving the info PERFECTLY at MCU. 

    3.  You saved me several hours in testing and crashing things (included mirrors and wooden doors). The response was fast and mostly accurate. 

    By the way, all the power section is using TI components tps63700 evaluation and the pair of ultra low noise LOD's from a 5V positive power suppply.
    The sound is SUPERB... I hope you don't discontinue this ADC ever...

    So, now thanks for your valuable help and most of all, your time. 
    Kindest regards, 
    Pablo.