1. we want to implement PDM collection with CC1310. we use example "pdmstream" of CC1350STK.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:
- cc1310's cracking problem requires that the data from IIS be moved one bit to the right;
- cc1310 had problems with 16K sampling and could not provide enough data rate, 8K sampling was ok.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.
