PCM1808 Does Not Work Correctly Using I2S Unless I Shift the Result by Nine Bits. I Expected Eight. about arduino-pico

[earlephilhower]

What is the I2S input module you're using? I've seen in other posts here that there are some MEMS mikes which don't actually follow the I2S spec in terms of when they shift/when you're supposed to sample. With a name we can double check a datasheet and see if it's something simple like that.

Alternatively, there could be a 1-bit shift in the I2S input PIO program. But just thinking about this I have trouble seeing how anything would work since I2S is a signed signal and for negative you'd have the MSB as a 1....shifting that out wrong would make simple, low-amplitude signed signals look like noise. I've used a stereo mike set (the one from the GOOG AIY kit since it's got a nice header) and didn't see this in my testing (but it has been a while).

[frohro]

On the bottom of the board there is a label saying CJMCU 1808. In about week, I should have an SDR using the PCM1808 for which I have the exact schematic. Here is a link to a photo of the back, and here is a photo of the front.

[earlephilhower]

I just hooked up the MEMS mike I use and did some basic sanity with the current release and it's still OK as far as I can see. What I did notice, though, on looking at your specific chip's datasheet is that there is FMT pin (12) which can shift the output by 1 bit, which is exactly what you're seeing:

Can you confirm you're at FMT=0 mode (or that the board isn't shorting it high for you)?

[frohro]

Thanks for looking at this @earlephilhower. I did just reconfirm that FMT is indeed low, both on the input labeled on my evaluation board, and on the actual IC at pin 12. I have two different setups that I tested this on and they both are low and both behave the same way. I am happy to make more hardware measurements for you though.

[earlephilhower]

Would you be able to capture the I2S bus with pulseview so I can see how things look on the wires? If you could post the raw data (as opposed to a screenshot) that would be most helpful. It would let me confirm the timings and at least let me think through the I2S.pio program and see if we're sampling on a wrong edge or something.

[frohro]

Thanks @earlephilhower! Here is the pulseview file.
PCM1808.zip
Let me know if this is enough data. It seems like it should be. The schematic and software I have been working on is available here. Let me know if you need more measurements. This was sampling at 48 kHz. The setup code is below.

// These are things you might want to change for your situation.
const int RATE = 48000;    // Your network needs to handle this, but 96000 should also work, but misses some packets.
const int BITS_PER_SAMPLE_SENT = 32;  // 24 or 32, python can make 32 faster.
const int MCLK_MULT = 256; //

void setup1()
{                 // This runs on Core1.  It is the I2S setup.
  i2s.setDATA(2); // These are the pins for the data on the SDR-TRX
  i2s.setBCLK(0);
  i2s.setMCLK(3);
  // Note: LRCK pin is BCK pin plus 1 (1 in this case).
  i2s.setSysClk(RATE);
  i2s.setBitsPerSample(24);
  i2s.setFrequency(RATE);
  i2s.setMCLKmult(MCLK_MULT);
  i2s.setBuffers(32, 0, 0);
  i2s.begin();
  mutex_enter_blocking(&my_mutex); // This should syschornize the cores, so one doesn't fill the buffer
  // before the other is ready.
  mutex_exit(&my_mutex);
}

Thanks,
Rob

[earlephilhower]

Got it, and it looks good. Pulseview's I2S decoder sees no issue on the bitstream and I see both positive and negative values at the right bit length. Looks like the I2S input PIO program's off by one somewhere!

[earlephilhower]

@frohro it looks pretty straightforward. The I2S input program shifts one bit in every BCLK, leaving the HW to do a push of data every 24/32 bits. Since the LRCLK changes 1 cycle before the actual data, this means it was shifting in one garbage bit into the MSB before the actual data. This shift would last for all time since there's no resync. Pre-shifting in 23/31 bits should fix it, putting that 1 extra bit into the 1st returned sample and aligning everything else for all time...

Can you give #2121 a try, since you have a working app and ADC all wired up?