CCS/LAUNCHXL-CC1312R1: How to modify the code of "rfAudio" to adapt different sample rate?

Hi Sean,

First of all, can you confirm the out of the box example (without any modification) is working as expected? (I mean the audio quality is "ok" and the transmission continuous). If this is not the case you may want to solder the jumper wires on the audio boosterpack.

If you want to increase the audio quality (i.e. the sampling rate), please be sure to use a sampling frequency supported by your codecs (both SW and HW). In addition, especially if you are using Opus, you may want to increase the bit rate of the compressed data.

To finish, the symbol rate used by the radio probably need to be increased. Please use SmartRF Studio to properly setup the radio.

Let me know if you need more assistance.

Best regards,

Hi Clément,

1. Yes, the raw demo runs normally, but the audio quality is not good when I play with 1KHz sin wave audio. Is the packet transmission interval is too long?

2. The decodc I use is TLV320AIC3254 in the "CC3200 AUDIO BOOSTERPACK", it supports all common sample rate. Is the MCLK generated by CC26XX don't match the formula MCLK=256*fs? (What do you mean of SW and HW? o_O; )

3. Can I change the compression mode in the demo? The default option is Opus, if I use the compression mode with lower compression ratio, the radio quality will be better I think.

4. I find that no matter how I change the symbol rate, the audio quality seems change nothing.

Best Regards,

Sean

Hi Sean,

1- Are you using really small and tight jumper wires? I usually solder them on the boosterpack to avoid loosing quality because of them.

2- The HW codec is the  TLV320AIC3254. The SW codec is Opus :)
If you are using the out of the box example, then MCLK is not used. MCLK is used only if the CC13X2 is defined as the I2S slave (i.e. the device is not generating the clocks)

3- Yes of course. This would require a bit of work. That being said, Opus is already one of the best solutions possible when it comes to compression ratio vs quality.

4- This means the audio quality loss is not caused by some packets lost by the radio. I would rather verify if the jumper wires could be the ones responsible for this (cf. point number 1)

Best regards,

Hi Clément,

I've soldered the pins with wires and tested again, the audio is still discontinuous as before. Now the main issue is the abnormal audio transmission :( Is it the possible reason is the interval too long?

If I rise the symbol rate(the configuration generated from SmartRF Studio), the audio quality will become more worse. But after changed array pOverrides as the raw(default) configuration, then it behaves same as I said above(discontinuous audio).

Best Regards,

Sean

Hi Sean,

1- With the soldered wires and the out of the box example, how is the audio quality for the 1KHz sin wave audio?

2- What are the code modification made to observe discontinuities in the audio?

3- Which interval do you think is too long? In the out of the box  example, the RF transmissions are done back to back, have you changed this?

4- What is the number of packets received vs the number of packet sent? Is there any significant differences when changing the radio configurations?

Bet regards,

Hi Clément,

1. Discontinuous, I can hear the audio is intermittent. The sound seems like this VVVVVV -> V V V . o_O

2. I change nothing, just the default demo.

3. Packet interval? I think. Nope~ I do not change anything.

4. The default packet count is 20.

If possible, I'd like to ask you to have a try. My hardware connection is shown in the picture below.

Best Regards,

Sean

Hi Sean,

Thank you for the picture you have provided. Despite the fact you have soldered the jumper wires, they are still too long and not enough tight. As a result the wires are acting as antennas producing a lot of bad things. I strongly recommend to fix this before going any further. Here is what my boosterpack looks like for CC1352P example (which by the way is working well for me - I have no access to CC1312R at the moment, sorry).

I hope it will help,

Kind regards,

Hi Clément,

Thanks! I've soldered them as you said. Thus, the audio quality is better, but it still discontinuous. t_t

Best Regards,

Sean

Hi Sean,

Can you please do a test with the audiohal_packetizer_echo example? The goal is to verify if the system behaves as expected if we remove the RF transmission. It would be nice if you could test the example on the two boards.

Regards,

Hi Clément,

Yes, of course. I've done a test with the example you said, the audio quality and continuity is ok.

Best Regards,

Sean

Hi Sean,

Could you please implement a counter to count the packets sent by the Tx node and the number of Rx node? There should be almost no difference.

(FYI, there should already be a counter implemented but you may need to slightly modify it)

Regards,

Hi Clément,

Yes, the number of packets of the receiver and transmitter are the same.

Best Regards,

Sean

Hi Sean,

Clément asked me to help you as he is going out of office for a while.

I just tested the default demo on my side (for CC1352P-4) and I am not hearing the same as you. I will admit there is some noise but the sound is even - no discontinuos or intermittent packets.

Ar you using apple earphones? Can you try with a different brand?

Do you have access to a logic analyser? It could be interesting to see the timing of the packets being sent.

Hi Marie,

My hardware devices are LAUNCHXL-CC1312R1 and CC3200 AUDIO BOOSTERPACK. I've already tried different frequency before but got the same result.

Do you use 1KHz sin wave signal to test the audio?

No, I'm using HUAWEI earphone.

Yes, I can. What signals should I probe? Do you mean I2S singals? I'll do a test.

The following picture is the result of signal analyzer, but I cannot make any conclusion. o-O (I play with 1KHz sine wave audio.)

In addition, could you use the same devices as mine and do a test ? :) Thanks!

Best Regards,

Sean

Hi Sean,

Can you look at the RF pins as well? Please see the User's Guide debugging chapter, section Debugging RF Output:

I don't see any irregularities in the screen shot you posted.

Hi Marie,

I just tested as you said.

The first picture is from TX side, the pin I probe is GPIO7.

And the second picture is from RX side, the pin is GPIO6.

From the document it mentions, "for an example of using DIO6 to output the LNA enable signal (logic high corresponds to an Rx) and DIO7 to output the Tx start (logic high corresponds to a Tx)."

According to this two pictures, which means that RF is working normally? So what's the next step I can do T T

Best Regards,

Sean

Hi Sean,

Did you configure the LNA signal on GPIO 6? I was hoping we could see the Rx of each individual packet.

Hi Marie,

I do have configured both GPIO6 and GPIO7 as the document recommend. But the GPIO6 of RX side stays high level, even if I power off the TX side.

Could you do a test? It's so strange. O_o

Best Regards,

Sean

Hi Sean,

Did you double check that GPIO6 is not being used by some other module?

I'm working from home office right now so I am not able to do a test. I will try to get it done by the end of the week.

Hi Marie,

Yes, I have double checked, the demo I use is "simplelink_audio_plugin_3_30_00_06\examples\rtos\CC1312R1_LAUNCHXL\easylink\rfAudio". I've blocked the initialization code of both LED and also function "GPIO_toggle".

Best wishes for whole the world people, 

Sean

Hi Sean,

The code snippet looks good.

Sorry this is taking some time, I am having some issues with my logic analyzer. 

Hi Marie,

Um, so what's the reason ToT

Or that's because of the chip's hardware error or low performance?

Best regards,

Sean

Hi Sean,

Sorry for the late answer,

I don't know why you are seeing this issue.

I am not able to reproduce.

Best Regards,
Sean

Hi Sean,

Sorry no.

What do you mean by experimental overview.

Hi Marie,

Thanks. I mean the your "rfAudio" test result.

I think I should give it up :(

Cheers,

Sean

Hi Marie,

Thanks. Do you use sin wave audio to do the test? It's a very obvious difference of audio comes from PC and DK.

Best regards,

Sean 

Hi Sean,

Yes I have done a sine wave test. I get some noise on the line but it's always the same. 

What do you mean by  "It's a very obvious difference of audio comes from PC and DK."?