LAUNCHXL-CC1352P: The problem of noise slowly getting louder and disappearing suddenly

Hi,

First of all, have you only changed the sampling rate or  you have change other parameters?

Have you verified if the issue appears even if you remove the RF transmission? I mean, if you setup the example audiohal_packetizer_echo with the exact same parameters, do you experience the noise too?

Last element, have you checked if the noise could be caused by some sorts of saturation. I mean, if you decrease the audio level of the input, do you still have the noise appearing?

Kind regards,

Hi Clément,

1、Attached is my modified code.  smartrf_settings.c is set by "1 Mbps, 2-GFSK, 350 kHz deviation (868 MHz)" or "200 kbps, 2-GFSK, 100 kHz deviation, 868 MHz".

2、If the RF transmission is deleted, there will be no problem.Testing using  audiohal_packetizer_echo.

3、Reduce the volume, do not improve the problem.

Hi Clément,

      We found that 16K sampling rate will also have this problem, but it will take a long time. This problem occurs most frequently at 48K sampling rate.

      We suspect that the problem is related to the size of this parameter --AUDIOHAL_DEFAULT_BUF_DEPTH.We'll do the experiment later.

Reduce this value to 1, and the noise generated is very similar to the noise in the recording we provided. Increase this value to 25, and the noise will still appear.Changing the value of MAX_FRAME_QUEUE still has no effect

Hi,

To be sure to well understand, do you mean the issue is coming from the value of AUDIOHAL_DEFAULT_BUF_DEPTH or not?

Regards,

I can only provide experimental results, but I can't judge.

Hi  expert，

      Is there anything I can do to help solve the problem？I found that this problem is periodic. At 48K sampling rate and "#define AUDIOHAL_DEFAULT_BUF_DEPTH  2", the normal sound lasts about 4 minutes 47 seconds or 4 minutes 52 seconds, and the noise lasts about 1 minute 28 seconds. The duration of each time is not exactly the same.

      The corresponding situation of 32K sampling rate is shown in the attachment.

Duration of noise and duration of normal audio.xlsx

Hi,

Thank you for all the energy you spent investigating on this issue.

You mentioned before the issue was due to the RF transmission. So I think you should verify if at one point some data maybe missed in the audio transmission.

To do so I would keep a record of the number of bytes expected to be sent and see if after a specific time a bit could be "forgotten".

Best regards,

Hi,

Have you managed to identify the source of the noise?

Do you have more details to share?

Best regards,

Resetting any  board，tx or rx，can make noise disappear.I only have two boards in my hand. I am wondering if I can use one board as the transmitter and multiple boards as the receiver. There may be some interesting phenomena.

Good  night!

Hi  Clément，

    We had a similar problem a few months ago.At that time, we used cc1310 to transmit uncompressed data.At that time, we tried to compare the data of the sender with that of the receiver, and the conclusion is that the data on both sides are consistent.My colleagues told me that it was probably caused by the clock shift of IIS. but I have not confirmed it.

- Maokun.Liang

Hi,

Maokun.Liang said:

I am wondering if I can use one board as the transmitter and multiple boards as the receiver.

Yes, this is completely possible :)

Regards,

Hi  Clément,

      Will you do this experiment next？

Hi Maokun.Liang,

Could be interesting at least :)
An other element easy to verify is the quality of the I2S data on the Tx side. You can do this by copying the I2S data on the output. This can be done in software or basically adding a jumper wire between the ADIn and ADout pins of the audio booster pack.

That being said, I have worked on your issue and I think I managed to reproduce it (the sound is not exactly the same as your).
Like you I see the problem appearing and disappearing by resetting the device. I also managed to make the problem appearing or disappearing by touching the antennas. Apparently the data before sending is ok (I tested this by adding the jumper I mentioned before).

Regards,

Hi  Clément,

      I recalled the experiment with cc1310.The codec chip we used at that time was wm8978.There will be the same problem.

- Maokun.Liang

Hi  Clément,

      This may not be a correct experimental conclusion, because I didn't know at the time that the problem was cyclical. Maybe the data I get is in the normal phase, not in the noise phase.

      Thank you very much for your help.

- Maokun.Liang

Hi,

May I ask which CC1352P launchpad you are using? Which frequency do you use to transmit the audio data over the air?

Regards,

Hi Clément,

     smartrf_settings.c is set by "1 Mbps, 2-GFSK, 350 kHz deviation (868 MHz)" or "200 kbps, 2-GFSK, 100 kHz deviation, 868 MHz".

     launchpad is CC1352p2.

Hi,

And how do you power up your boards? Are they connected to the computer or are you using a power bank?

Regards,

They are connected to the computer through usb cables.

Hi,

I'll try it now.

Hi Clément,

      You are right! The noise does not appear on CC1312R.

Kind regards,

- Maokun.Liang

Hi,

     Bad luck,this problem still appear on cc1312R after a long time.And in later tests, it can still appear quickly.

The normal sound lasts for about 13 minutes and the noise lasts for about 2 minutes and 40 seconds.48k sample rate.

Hi,

We talk before about the value of AUDIOHAL_DEFAULT_BUF_DEPTH. Which value are you using now? Do you see any better behavior for an higher value of AUDIOHAL_DEFAULT_BUF_DEPTH?

Regards,

Now ,AUDIOHAL_DEFAULT_BUF_DEPTH is 4.No any better behavior for an higher value of AUDIOHAL_DEFAULT_BUF_DEPTH.But 1 is bad.

Note that I use MSBC instead of opus. In the attachment code mentioned earlier, five bytes are added to the related array.

Hi,

Have you run some tests using two receivers instead of one? In that case does the audio quality change at the same time on both receivers?

Best regards,

Hi Clément,

      These days, I was busy adding PDM code to my project , so I didn't follow up on this matter.According to your previous experiments, it has been proved that there is no problem with the transmitter.The problem is in the receiver.In the receiver, RF, IIS clock and decompression need to be checked.

      What I want to do but have not done is to write the decompressed data of the receiver into the decoding chip through IIS, and print the data through the serial port to make WAV files.If there is no problem with the sound of wav file, it is basically confirmed that it is the clock problem of IIS.

“Have you run some tests using two receivers instead of one? In that case does the audio quality change at the same time on both receivers?”

Sorry, I didn't.

Hi,

Ok, ok, could be a good direction. Thank you for the update.[EDIT - this will be tested when using two receivers] I don't know if this has been suggested before, but would you mind testing another launchpad?

One more idea is to try to disable-enable the AudioHAL on the Rx board when the issue occurs. This should kind of reset the I2S module. Maybe it would be enough to remove the noise (at least it would give us new hints).

Best regards,

Maokun.Liang said:

Sorry, I didn't.

No worry, you're fine. Let me know when you have the results :)

Kind regards,

Hi Clément，

      1，I have testing cc1312,cc1352,cc1310.All have this phenomenon.

      2,  A few months ago, I tried to reset the RF through software to eliminate the noise,and the noise can be eliminated. But,because we can't judge whether there is noise through the software, we reset the RF by timer, and the result is that the sound will be stuck periodically.

Hi,

I think I have identified the source of the issue.

The I2S clock are obtained by dividing the 48-MHz clock. The 48-MHz clock is obtained from a crystal oscillator. However, two crystals oscillators have tiny differences in their actual frequency (this is why the accuracy of the crystal is specified when you pick it).
As a result, on the Tx side you sample the music at 44.099.999 Hz while on the Rx side you play it at 44.100.001 Hz. As a result you get cyclically some noise that suddenly disappear when you exactly have lost or win one sample).

The bad news:

• you are guaranteed to experience this issue
• the issue will appear more or less quickly depending on the difference of the actual frequency of each crystal oscillator
• I do not have yet a perfect workaround for you

The good news:

• the CC13x0/CC26x0 and CC13x2/CC26x2 have a way to address this problem. If you look into the Technical Reference Manual of the device, in the I2S module you will find the "sample stamp generator". This feature can be leveraged to sole the issue (but I do not 100% know how - I need to dive into this)
• if you use a crystal oscillator with a better accuracy, the phenomena will appear less often (draw back the phenomena will last longer each time)
• periodically reset the I2S modules is a possible way to handle the problem. For example you could do some silence detection and reset the I2S module in that case.

Best regards,

Hi Clément,

Nice to write you! I'm Michael Chen, work together with Maokun.Liang in the same company.

I prefer to the method of 1st good news:

• the CC13x0/CC26x0 and CC13x2/CC26x2 have a way to address this problem. If you look into the Technical Reference Manual of the device, in the I2S module you will find the "sample stamp generator". This feature can be leveraged to sole the issue (but I do not 100% know how - I need to dive into this)

If you have any result, Pls let me know. BTW, Have you do the  test as Maokun said:

"What I want to do but have not done is to write the decompressed data of the receiver into the decoding chip through IIS, and print the data through the serial port to make WAV files.If there is no problem with the sound of wav file, it is basically confirmed that it is the clock problem of IIS."

Thankyou!

BR

Michael Chen

Hi Clément

Nice to write you!

I'm Michael Chen, work together with Maokun in the same company.

I prefer the method of 1st good news:

• the CC13x0/CC26x0 and CC13x2/CC26x2 have a way to address this problem. If you look into the Technical Reference Manual of the device, in the I2S module you will find the "sample stamp generator". This feature can be leveraged to sole the issue (but I do not 100% know how - I need to dive into this)

If you have any result, Pls let me know.

BTW, Have you done the test as Maokun said:

" What I want to do but have not done is to write the decompressed data of the receiver into the decoding chip through IIS, and print the data through the serial port to make WAV files.If there is no problem with the sound of wav file, it is basically confirmed that it is the clock problem of IIS."

Thankyou!

BR

Michael Chen

Hi Clément，

      I'm very glad to hear from you.

     Adding this coed  "HWREG(I2S0_BASE + I2S_O_IRQFLAGS)|0x08;" to the project may be able to implement your 1st solution.But I've tried this method, and the noise will still appear.

      I'm sick at home these days.Michael Chen will follow up on this issue instead of me.If I feel in good physical condition, I will participate in the discussion.

Hi,

     I still have some questions.

     According to your frequency data, the time of misplacing a clock should be    

     (1÷44,100)÷((1÷44,099.999)−(1÷44,100.001))÷60

     =367499.99999999981 minutes.

(or(1÷44,100÷16)÷((1÷44,099.999÷16)−(1÷44,100.001÷16))÷60=367499.99999999981 minutes)

     But the time we observed was about 7 minutes.

     If it is 7 minutes, the calculated data should be as follows

     ((1÷44,100)÷((1÷44,099.999)−(1÷44,200.001)))÷60

     =7.3665193359 minutes.

     This means that a frequency difference of 0.002 Hz will not cause noise in such a short period of time. Unless the frequency difference is greater than 200 Hz.

     Therefore, either my calculation formula is not correct, or the problem is not in the frequency difference of 0.002 Hz.

Part Number: LAUNCHXL-CC1352P

Hello expert，

      I heard that the problem has been solved. Can you tell me when your new software will be released？