CC1310: PDM implementation on CC1310

Hi Viki,

The two problems described seems to be due to the microphone itself, not really to the software. That being said, here two ideas:

1- Have you tried to decrease even more the defaultFilterGain? The value held by the symbols PDMCC26XX_GAIN_12 and PDMCC26XX_GAIN_0 can be replaced by 42 (gain is -3dB) or even 21 (gain is -6dB). 

2- It seems like some noise is introduced by the microphone. To validate this, you can verify if by removing the PDM microphone and holding the data line to 0 you still have this noise. If this removes the noise, then there might be some optimization to do on the microphone (I heard about some noisy power lines, but I am not an HW expert :) ).
Filtering can also be made on the PCM data in order to remove the noise.

I hope this will help,

Kind regards,

Hi Clément,

The MIC's problem is solved. There's another one.

There was a cracking voice playing via I2S[CC1310]. But in STM32F4, the sound was normal. The customer captured the clock with a logical analyzer, he found the MCLK of CC1310 and STM32 were different--- STM32 is 2048K while CC1310 is 2047K. How to adjust the MCLK of CC1310 to output 2048K?

Hi Clément,

1. The SDK used is "simplelink_ cc13x0_ sdk_ 3_ 10_ 00_ 11"；

2. The project plan is to use two cc1310 boards, board A as the sending board. The main work includes collecting PDM data and converting it into PCM, communicating with touch chip through IIC and controlling touch button, controlling power management chip, sending audio data to another board B through RF; another board B as receiving board, whose main work is to receive RF data of board A, And send the received data to wm8978 through IIS;

3. At present, we are confronted with the following two problems, and the experiments are as follows:

Question 1:

1) .The data of PDM is collected by 8K sampling record of cc1310, and the data is converted into PCM format data. STM32 or PC can play the PCM data normally, which shows that the cc1310 code of 8K acquisition and conversion is OK;

2) The same data is played OK in STM32, but the sound played through IIS on cc1310 is cracking voice. The reason for cracking voice has been found. The reason is that the data from IIS of cc1310 is right aligned or left aligned, while the data from IIS of STM32 is standard one bit delay, that is, there will be a bit right shift;

Question 2:

1) When we change the parameter of cc1310 to 16K sampling, the sound transmitted through RF will have a weak hissing sound (real-time).

2) On STM32, the data obtained by 16K sampling is shown in Fig. 1, and that of cc1310 is shown in Fig. 2. From the figure, we can see that the 16K data collected by STM32 is very regular, while the data of cc1310 cannot find rules (the rule here refers to that the odd columns of data are all numbers of similar size, and the change is very small).

3) The voice recorded with 16K sampling on STM32 is saved to the memory of cc1310. If it is played out with cc1310, there will be no hissing sound, and the intonation and playback speed are normal (non real-time). If the 16K voice data recorded by cc1310 is played through the computer, the intonation and playback speed will become higher and faster (non real time); if the data is saved to the memory of cc1310 and played through IIS, the speed and intonation will also become faster and higher (non real time).

4) The analysis of experimental phenomena and the conclusion of conjecture are as follows: the playback rate of cc1310 does not match with the data acquisition rate, and the playback rate is higher than the acquisition rate. Leading to:

       1) During the real-time RF playback, the transmitting board can not provide enough data to the receiving board, resulting in "packet loss". The packet loss here does not refer to RF packet loss, but refers to similar packet loss phenomenon.

       2) During non-live playback, due to too little data, the playback tone and playback speed become higher and faster.       

4. Combining the two experimental results of Question 1 and Question 2, we think there are two problems:

1. cc1310's cracking problem requires that the data from IIS be moved one bit to the right;
2. cc1310 had problems with 16K sampling and could not provide enough data rate, 8K sampling was ok;
3. According to the notes in PDMCC26XX.h（C:\ti\simplelink_cc13x0_sdk_3_10_00_11\source\ti\drivers\pdm）, the second problem is probably due to some data being discarded.However, modifying the variable "pdmBufferQueueDepth" in the description does not work.

Waiting for your help.

Kind regards.

Question 1 is fixed.

Hi,

As I was out of the office for a while, may I ask you to summarize the still opened issues?

Kind regards,

Hi Clément,

      Thank you for your reply.

       The FAE of your company will come to our company for support on this Wednesday, and then I'll give you feedback if we still can't solve these problems.

       Kind regards, 

       -Maokun.Liang