CC2564C: Phone audio pops heard from headset

Hi Will,

Sorry for the delay. Often times, the pop noise are result of mismatch in PCM configurations between CC256x and the host/codec. Have you verified that the PCM configurations are correct? An easy way to test this is by using the PCM loopback mode of CC256x.

Reference : HCI_VS_Set_Pcm_Loopback_Enable(0xFE28)

You can enable the PCM loopback mode after HCI_VS_Write_Codec_Config(0xFD06) and you do not need any connection over the BT link as this is a local test for the PCM interface. When the PCM loopback mode is enabled, the data on AUDIO_IN will be looped back in the CC2564C FW to AUDIO_OUT. You can compare this data on the host to see if it is identical to what was sent to CC2564C. If you observe noise and/or corrupted data, the PCM configuration is the problem.

If the PCM loopback test passes and indicates that the PCM configuration is correct, please share the CC2564C's firmware logs in this use-case.

Logger User's Guide : http://www.ti.com/lit/pdf/swau058

Best regards,

Vihang

Hi Vihang,

We will do PCM loopback check in our factory verification, as you said that we:

1. After BT chip initialized including HCI_VS_Write_Codec_Config
2. Send HCI_VS_Set_Pcm_Loopback_Enable(0xFE28) to enable CC2564 loopback mode
3. Send data to CC2564 over AUD_IN
4. Record data from CC2564 over AUD_OUT
5. Compare input and output data

The compare result is identical, below is the waveform we measured during PCM loopback test:

I do the same test at same place again:

1. Connect CC2564 to headset Sena 20s using HFP
2. Connect SCO to Sena 20s
3. Host do not send any data on AUD_IN to CC2564

The attached is the firmware log of CC2564, can you please analyze?

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/PhonePop.7z

Hi Vihang,

Here is our PCM configuration settings for CC2564 in BT stack:

I attached the HCI log, and the #93 frame is HCI_VS_Write_CODEC_Config command:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/hci_5F00_gw_5F00_dump.7z

Please review if our PCM settings is correct, thanks.

Hi Will,

The PCM parameters above indicate that all the input and output signal edges are selected as rising edge (0x00). But the oscilloscope capture shows that the PCM data input signal to the CC2564C (out from host/codec) is also asserted on the rising edge of the PCM clock. For best result, you should output the signal (in either direction) on rising edge and sample the signal on the input (on the other device) on the falling edge. 

So, I would recommend making the following change on the CC2564C side. 

#define BLUEGO_TI_CODEC_CH1_IN_EDGE     1

#define BLUEGO_TI_CODEC_CH2_IN_EDGE     1

Since the data out from CC2564C on both channels is configured for rising edge, please make sure the input on the host/codec is configured for the falling edge. Please give it a try.

Best regards,

Vihang

Hi Vihang,

In my test, before PCM parameters changed I hear 3~5 pops per minute from headset, with your suggestion applied I still can hear 3~5 pops per minute, there is no much difference to me.

A question to confirm, since we just connect SCO link to headset but do not send data over PCM to CC2564, even CC2564 does not sample the input signal at the right timing, should the sampled data be still "silence"? 

Please let me know if you need any log to analyze.

Thanks.

Hi Vihang,

We would like to know if this issue occurs at your side, if not do you need our device to check?

Thanks.

Hi Vihang,

We have checked host PCM settings with Brad using mail, please see the attached "RE_ TI CC2564 phone pop noise.7z". Is there anything that needs to check at our side?

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/RE_5F00_-TI-CC2564-phone-pop-noise.7z

We plan to reproduce this issue with CC2564 EVB tomorrow, will update you the result. BTW, have you seen this issue on CC2564 EVB?

Thanks.

Hi Will,

This issue is not observed on the CC2564C EVM when using with a host running the TI stack. Since you might be using a different stack (and profile implementation), could you please try the same software (stack, profile and application code) with the CC2564C EVM?

Will Liao said:

if not do you need our device to check?

If you manage to reproduce the same issue on CC2564C EVM, it will be helpful for us to replicate your use-case here or debug on your device for further debug.

Best regards,

Vihang

Hi Vihang,

I use the same software to do the same test again with CC2564 EVM, all IO pins on RF Connectors of CC2564C EVM finished wire bonding to our DUT except MODULE_AUDIO_DATA_IN pin. it kept R11 mounted with 51Kohm.

The result is same as before that I still heard pops from headset, and the attachment is the air log, and sco.wav is the audio that extracted from the air log, the pops I hears is at 18s, 23s, 26s, 34s, 38s, 51s, 57s, 1m32s.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/1273.air.7z

Any ideas? Can you please share your air log with us? We would like to confirm there is no such issue on your EVM.

Thanks,

Will

Hi Vihang,

Any updates?

Thanks,

Will

Hi Will,

I ran the HFPDemo_HF example from the MSP432 Bluetopia SDK and collected the air sniffer and firmware logs during a short call. Please take a look at the attached 7z and see if you can identify the same issue that you saw with your software.

/cfs-file/__key/communityserver-discussions-components-files/538/hfpdemo_5F00_3_5F00_10.7z

Regards,
Michael

Hi Michael,

Thank you, I do not hear any pops from your air log, there is no pops issue in your test.

In your air log, SCO data is transmitted using 2-EV3 packet, this is different than our test on Sena 20s headset that is using EV3. I find out our another headset that supports 2EV3, so I do the same test again that let CC2564C EVM connect to 2-EV3 headset, and this time I do not hear any pops during 2-minutes phone call.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/2EV3.7z

It seems SCO packet types have different results, but in our test before with EV3 headset, the packet error and re-transmitted rate looks OK(<1%), still hears pop, so my questions is why packet type makes such difference? Any ideas?

Thanks,

Will

Hi Will,

I went and acquired a Sena S20 headset, but I'm not sure if I hear the same pops that you are hearing. Attached are the air logs from my testing, with the Sena S20 connected to a CC2564C:

/cfs-file/__key/communityserver-discussions-components-files/538/cc2564c_5F00_to_5F00_sena_5F00_s20.7z

I would appreciate it if you could check my logs and see if the test I'm performing matches what you're doing on your end.

I am not sure as to why the packet type results in more pops. Further testing will be required.

Have you tried connecting the Sena headset to another device and checking to see if there are pops?

Regards,

Michael

Hi Michael,

Are you do the same test at same place again but just changing DUT to Sena 20s? I heard many pops from your log and I think this is the pops issue that I am talking about. 

I recently did some tests in our chamber, trying to see if pops occurs even if no error SCO packets, here are the logs for EV3 and 2EV3:

• EV3: CC2564 connected to Sena 20s
  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/Clear_5F00_EV3.7z
• 2EV3: CC2564 connected to Marvell chipset
  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/Clear_5F00_2EV3.7z

I did not hear any pops both for EV3 and 2EV3 tests, seems in a clear RF environment, without SCO packet error, what packet type used does not matter for pops issue.

I did use iPhone7 to connect Sena 20s, but the test was done in a dirty RF environment and I also heard some pops, but seems a little bit better than CC2564C, but it hard to say in dirty RF environment I think.

Thanks,

Will

Hi Michael,

I did a comparison test between CC2564, Marvell chipset and iPhone, the headset is still the same as Sena 20s, I try to compare if the pop sound heard by headset is different between chipsets.

The test was done at the same location, and the result shows that both of these three chipsets have pops, but the pop sound heard from headset is different:

• CC2564: the pop sound is shrill and uncomfortable to the listener
• Marvell and iPhone: the frequency of pop sound is lower, and is more comfortable to the listener

We will record the pop sounds on these chipsets for you to refer, but I think you can compare CC2564 with iPhone at your side. If the pop can not be fixed completely, it is acceptable to us that the pop sound on CC2564 is similar to iPhone.

Thanks,

Will

Hi Will,

Thanks for performing your experimentation with the noise-free RF environment to see if you encountered the same issue. At the moment I do not have access to a clean RF environment, which may be why I still get pops in my logs.

I tried using my Android Pixel 3 phone with the Sena S20s, and it seems like there are still pops there as well. The retry rate was fairly low at 2%:

/cfs-file/__key/communityserver-discussions-components-files/538/pixel_5F00_3_5F00_to_5F00_sena_5F00_s20_5F00_hfp.7z

I will be using my logs to compare against the CC2564C's logs and see if there are any discrepancies and investigate and debug from there. Are you able to provide the air sniffer logs of the iPhone and Marvell chipset connected the to Sena S20s so I can also take a look and see what differences there are in the connection that could result in the pops being more noticeable on the CC2564?

Thanks,

Michael

Hi Michael,

Since Sena20s can output the SCO audio he received to audio jack, I recorded the pop sounds CC2564, Marvell and iPhone7 into wave files as below:

• Sena20s - CC2564:
• Sena 20 - iPhone7:
• Sena 20 - Marvell:

The comparison is more obvious between CC2564 and iPhone7, the pop sound of CC2564 is more noticeable than iPhone7, and it looks like the audio volume of CC2564 is much bigger than others.

For the air logs you requested, I do not have the log for iPhone, but Marvell:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/3173.Clear_5F00_2EV3.7z

Please let us know if you find out something.

Thanks,

Will

Hi Will,

Thank you very much for providing those Marvell logs as well as the audio captures.

Something that is very interesting is that it seems like the Sena S20s is actually capable to negotiating and providing 2-EV3 audio. This is not something that I observed with my Pixel 3 nor with the CC2564. In those two cases, 2-EV3 is proposed but the Sena S20s sends another eSCO_link_req message indicating that it wants to use EV3 instead. I had assumed that getting negotiated to EV3 was unavoidable, but seeing the negotiation result in 2-EV3 indicates that is not the case.

Comparing the master's initial eSCO_link_req message on the Marvell against that of the CC2564 and the Pixel, it looks like the only difference in the parameters is that the Marvell chipset sets the WeSCO to 0x04, instead of the 0x02 that the other devices set. I will look into that parameter and see if it can be adjusted on the CC2564 tomorrow. Perhaps that will allow the CC2564 to use 2-EV3 as well. If using 2-EV3 is possible, it may fix the popping noises that is observed in the CC2564 audio.

Regards,

Michael

Hi Michael,

I am so sorry that provided the wrong log, 3173.Clear_2EV3.7z is the log that CC2564 is connected to Marvell, not Sena 20s connected with Marvell.

Here is the correct log for Marvell and Sena 20s, ans it is also using EV3 for SCO packet:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/Marvell_5F00_Sena_5F00_EV3.7z

In the meantime I am studying how to capture BT log from iPhone using Apple's tool, will upload later once I have.

Thanks,

Will

Hi Michael,

I still can not get the link key for iPhone and Sena20 connection, so I can not capture air log for you. But I got the hci log from iPhone using Apple tool named PacketLogger as attached.

The file named iPhone7_Sena20.pklg inside is the original file saved by PacketLogger, it can be opened by PacketLogger only, and the another file named iPhone7_Sena20.log is exported by PacketLogger in BT snoop format and this one can be opened using BT analyzer.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/iPhone7_5F00_Sena20.7z

Thanks,

Will

Hi Will,

Looking at your iPhone air sniffer logs, it appears there is a key exchange captured in the HCI traffic. Packet 454 has what could be the link key used between the iPhone and the Sena S20.

The corrected Marvell logs show data very similar to what I've been seeing with my Pixel logs and the CC2564C logs. Basically that they both use EV3, and that the negotiation for the encoding is the same.

Now, given that you observed that the pops happen a lot more in high packet loss environments, the perhaps the packet loss concealment algorithm of the CC2564C for EV3 would explain the difference in pops heard. However, the implementation of PLC is in the firmware of the device, which would make it more difficult to adjust if that is at fault. Any change to the firmware would require a servicepack fix and extensive testing.

I will look and see if adjustments can be made there tomorrow, as today I was focused on debugging on the Sena S20s side and ensuring that there isn't a firmware update or settings change that would enable 2-EV3 or otherwise alleviate the issue. Unfortunately, it doesn't appear that there is such a method.

Regards,

Michael

Hi Michael, Thanks, I can help with the test of adjusted PLC, just let me know if you need. How about the volume, it seems the pop sound is more noticeable due to bigger volume on CC2564, do you think this thought is correct? If yes do you think it is possible that lowers down the volume ? Thanks, Will

Hi Will,

I don't think the audio volume itself is part of the issue here.

Looking at the CC2564C firmware and investigating the PLC implemetation, there is the possibility that it is not enabled for NBS connections. From what we've analyzed in the code, it appears that in order for PLC to be used, either the connection needs to be using WBS, or there must be some sampling rate conversion necessary on the connection. If that is the case, then it would make sense why the Sena S20s using EV3 results in very noticeable pops when packet loss occurs.

Now, there could be a method to enable PLC while using EV3 on the CC2564. This is a workaround where we setup the SCO connection to require sampling rate conversion on the CC2564. I am currently still investigating that workaround and will report back tomorrow on my progress as well as debug steps you can perform on your end to see if it helps with the pops.

Regards,

Michael

Hi Michael,

Thanks for your finding, let's test if it improves pop sounds. But I have some questions about PLC algorithm, after looking into this, HFP spec recommends this should be implemented on the receiving ends for WBS, then:

1. As CC2564 is the sender, why we will benefit from PLC? Or you are talking about the kind of PLC that implements on the sending ends?

2. Why it is implemented for WBS only? Can not it work for NBS?

Thanks,

Will

Hi Michael,

Any update?

Thanks,

Will

Hi Will,

PLC will benefit the receiving side. So enabling PLC on the CC2564C will help the audio that it receives. Weren't there also pops heard on the CC2564 side? Or is it only observable on the Sena S20 audio output?

PLC is currently only enabled for WBS, but there appears to be a workaround to also enable it for NBS. The way this works is we'll need to configure the CC2564 to perform some sampling rate conversion, and there are two things you need to do:

1. Enable the AVPR feature of the CC2564. You can do this by either including it as part of the servicepack that you load onto the device, or you can load the AVPR patch at runtine. That AVPR patch is needed since it contains the rate conversion/plc functionality.

2. Setup your stack to use 16KHz audio even though NBS uses 8KHz, which forces the CC2564 to perform sampling rate conversion before outputting the audio over PCM. There are two parts to doing this:

- first, ensure that the PCM interface is configured to use 16KHz audio. This can be done by adjusting the HCI_VS_Write_Codec_Config() function to use 16KHz, overriding your stack/application that will probably set it to 8KHz by default if NBS is requested.

- second, you need to setup your stack such that you'll use 16KHz as the input/output bandwidth for the SCO connection.You'll need to check and see how your stack handles the SCO connection setup. In the stack, there should be a reference to HCI_Enhanced_Setup_Synchronous_Connection(). You'll need to ensure that this command will be called by your stack even if NBS is used, and that the input/output bandwidth to PCM is 16KHz. On the bluetopia stack for example the SCO_Set_Enhanced_Transport_Parameters() API is used, but for your stack there is most likely a different mechanism used to specify those parameters.

Once the PCM audio is setup to use 16KHz, that will enable the sampling rate conversion code, and the PLC alongside it as well. If you could try that and test and see if you hear any differences that will be great. Please also let me know if you need more clarity on that workaround or have questions there.

On another note, do you observe issues with other EV3 headsets, or just with the Sena S20s? I'm wondering if other EV3 headsets would exhibit the same behavior, but I don't have any other EV3-only headsets on hand to test with.

Regards,

Michael

Hi Michael,

Thank you for the information about how to enable PLC for EV3. Since it will need quite effort to make these changes to enable PLC at our side, before starting it I would like to confirm the following things again with you, our customer are complaining the pops heard from Sena 20, not on the remote phone side, as you said that PLC will benefit the receiving side, will the output audio of Sena 20 get improvements by enabling PLC on CC2564?

For your another question "On another note, do you observe issues with other EV3 headsets, or just with the Sena S20s? I'm wondering if other EV3 headsets would exhibit the same behavior, but I don't have any other EV3-only headsets on hand to test with.". We have another Midland NextPro headset which is also using EV3 and I also hear pops from it, will you need air log for analysis.

Thanks,

Will

Hi Will,

If the pops are heard at the Sena S20 side, then it would be its PLC that would need adjustment, and not the CC2564 side, assuming that this is still a PLC issue. I was under the impression that the pops were on both directions. If you can confirm that they are only occurring on the Sena side, in effect the CC2564 is on the audio TX side of these pops only, that would be great. Given your goal of using the CC2564 as an audio bridge having the PLC be in effect would be useful still, but for the purposes of debugging just the Sena S20 pops it may be prudent to examine other debug options if the pops are only heard on the S20 side.

For the Midland NextPro headset, does it have effectively the same behavior as the Sena S20? As in the NextPro will have pops with other devices such as iPhones, but the pops won't be as noticeable as with the CC2564? The logs for that device would be useful for me to look through as well as a comparison so if you could provide that to me that would be appreciated.

Regards,
Michael

Hi Michael, We do agree the pop is an issue from Sena, but it is hard to explain this to our customer since they compared this with iPhone and felt iPhone is much better, but I will not say iPhone has no pop issue but the pop sound is less noticeable than CC2564. Currently we have not paid much attention to the pop issue at CC2564 side, as you know that CC2564 is just an audio bridge, the pop may be eliminated by the PLC of phone side so we have not got complaints about this. Can we focus on Sena pop first? Do you have any ideas or progress about the difference of pop sound between CC2564, iPhone and Marvell? I will do the same comparison again using Minland headset, and update you the results and air logs. Thanks, Will

Hi Will,

Ok, understood. Focusing on the Sena pop first makes sense since it's the most pressing issue at this point.

I am still checking to see why the pops are 'louder' when from the CC2564 when compared to the other devices. I was checking to see if it was some retransmission timing issue, but that doesn't really appear to be the case as far as I can tell. I am still looking at other potential causes of the issue.

Regards,

Michael

Hi Michael,

Have you found out anything that can share with us? This issue has been ranked as top priority issue by our customer and we have been working for months, they now want to know whether this issue can be fixed or not, or at least explain the possible solutions to them.

BTW, I compared the pop issue with another headset - Cardo PACKTALK, but the result is different than Sena, the pop sounds I think are both noticeable on CC2564 and iPhone, but the number of pops is much less on iPhone than CC2564, will you need the air log?

Thanks,

Will

Hi Will,

I am currently still testing and debugging, checking various options which appear to be different between the CC2564 compared to other devices such as the Marvell device. For instance, I noticed that the AFH channel map on the CC2564 I had setup was much more restrictive compared to the Marvell logs that you provided. However, we still have 20+ channels available on the CC2564 and increasing that number doesn't appear to have any change in the behavior of the device.

Any more logs that you can provide would be useful. A log of the CC2564 + the Cardo device would be useful if you think that the iPhone vs CC2564 results are significantly different. This would better validate that the issue is on the CC2564 side.

Something which would be helpful too is if you could capture the audio out of the Sena + the Marvell air sniffer logs and have the captures be of the same session. By having the audio pops sync up with the BT data, I can examine with more clarity which packets might be causing the pops to occur. With that, I can compare against the same sort of setup on my end, where I can line up the pops with the BT packets from the CC2564, and see what might be different in those pop-causing packets.

Regards,

Michael

Hi Michael,

Do you mean that you wonder a log for the headset whose pop sound is totally different than Sena, like better with CC2564 but worse with iPhone?

I collected the logs for Sena + Marvell case as you requested, to make the analysis easier for you I start recording the Sena audio output and connecting Marvell SCO link to Sena at the same time, so I assume the timing for SCO packets in the attached air log is aligned with the attached Sena output wav.

• https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/Marvell_5F00_to_5F00_Sena.7z

Just to clarify again about the volume adjustment, since we are focusing on the pop heard from Sena side, do you think it is not helpful for the pop sound that lowers down the audio sent by CC2564?

Thanks,

Will

Hi Michael,

Any update?

Thanks,

Will

Hi Will,

Thank you for providing the audio + packet data synced capture file. I captured my own set of audio + packet data:

/cfs-file/__key/communityserver-discussions-components-files/538/1803.CC2564_5F00_to_5F00_sena.7z

/cfs-file/__key/communityserver-discussions-components-files/538/3157.cc2564c_5F00_sena_5F00_linked.wav

Looking at the data from both the Marvell and CC2564, the pops clearly occur when there are bursts of retransmissions due to packets being corrupt or lost. I am still investigating what difference there is in the retransmits between the CC2564 and the Marvell device.

Listening to the audio outputs, the CC2564 does sound a bit louder, but that could be due to my recording setup being different from yours. Listening to your previous recordings of the CC2564 the volume outside of the pops seems to be about the same. Thus I am thinking that the pops being louder/more noticeable is not related to the CC2564 outputting louder audio.

While I continue investigating on my side, feel free to take a look at my packet capture as well as see if you can spot any irregularities in the operation of the CC2564.

Regards,

Michael

Hi Will,

I wanted to give you an update on the debug I've been doing.

In addition to the retransmission data I'm looking at, I also took a look at volume control/gain and seeing if those settings help at all.

On the Sena S20S, the click wheel controls the audio volume playback on the Sena side. Turning the click wheel clockwise increases the volume, and turning it counterclockwise decreases the volume. By continuously rotating the wheel, you will eventually reach the max/min setting at which point the S20 will alert you with a beep.

Testing with my CC2564, if I turn this click wheel counter-clockwise on the Sena to reduce the volume, i can reduce it to the point where the pops are no longer audible. Of course, this may also reduce the volume to the point where the BT audio data is also inaudible. With my current CC2564 setup I am unable to play real audio data to assess the degree of audio reduction necessary and see if the volume would need to be reduced too much.

In your tests Will, did you use the volume control wheel at all? Are you able to see if adjusting the volume locally would be able to resolve the situation on the S20S? I wonder if for some reason by default the EV3 audio setup of the CC2564 results in louder audio than the other devices you were testing. Are you able to send actual audio data through your test setup, to see if the pops can be reduced through this local volume control while keeping the audio volume to an acceptable level?

Regards,

Michael

Hi Michael,

We have also noticed that the local volume control on Sena 20 will affect the pop sound, just like you said the pop sound becomes small if we reduce the volume of Sena 20. But the issue we are facing is that when the local volume of Sena 20 is at the level that actual audio can be heard properly, but the pop sound is audible as well, this is the reason why our customer is worried about.

Thanks,

Will

Hi Will,

I see, loudness of the pops from the CC2564C side is such that the volume adjustment on the Sena S20s side will not be able to eliminate the issue.

I'm still looking at the retransmission data, and seeing in particular if there are power optimizations on the CC2564 that interfere with the retransmissions, and will inform you later this week on my status there.

Regards,

Michael

Hi Michel,

Have you found out something that can share with us?

Thanks,

Will

Hi Will,

I have been looking at those retransmissions, and seeing what modifications can be done to the stack or firmware to modify the retransmit behavior.

Looking at the firmware logs that I collect from the CC2564C during the eCO connection setup, it looks like in the HCI_accept_synchronous_connection_request call, the retransmission effort is set to 0x01, which is to optimize the retransmit behavior for low power consumption. Instructing the firmware to optimize for audio quality instead may improve the behavior that we see, and i am currently performing the needed modifications on the stack to set that retransmit behavior to optimize for quality. I'll let you know what my testing there shows and give further instructions there if it helps alleviate the issue on my end.

Regards,

Michael

Hi Michael,

I checked our hci log, the retransmission effort that our BT stack set is 0x02 as the picture below:

Looks like retransmission effort with 0x01 and 0x02 have same pop behavior right?

Thanks,

Will

Hi Michael,

I forgot to attach our hci log, please refer the attached.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/0825.hci_5F00_gw_5F00_dump.7z

Thanks,

Will

Hi Michael,

FYI, we tested with retransmission effort with 0x00, 0x01 and 0x02, and the volume of pop sound heard from Sena20 is almost the same to us.

Thanks,

Will

Hi Will,

Thanks for providing the logs. The retransmission effort that your stack sets is indeed 0x02, unlike the 0x01 that the TI Bluetopia stack uses. Thanks for performing that test and reporting its result. Given the results seen the issue doesn't seem to be affected by the retransmission effort.

Currently, I am performing testing to see if the issue is tied to the use of EV3 audio by the CC2564, or if the issue is tied to the interoperability with the BT chip used by the Sena headset. I should have some testing data with some other devices I can test with by the end of the week to see if the issue follows the use of EV3, or if it may be related to the BT device used by the S20s.

Regards,

Michael

Hi Will,

I have been doing some testing with the CC2564 connected to other devices I have, and so far I do not hear the same EV3 popping issues. However, as I am still checking my test setup, the result is not conclusive as I need to verify across more devices and check my logs to ensure that I replicate the conditions of the Sena S20S headset.

I wonder if the S20S and the other headsets you tested with such as the Cardo PACKTALK use the same BT chipset? That may explain why the popping issue would appear with certain headsets, but not when two cc2564 devices are connected to each other. Of course, if there was an issue with the audio connection to a certain BT chip we will look into that and see what can be done to resolve interoperability issues, but knowing if that may be the cause would be useful to direct our debug effort.

Regards,

Michael

Hi Michael,

I did the pop test on TI CC2564 EVM with all the headsets I can find, and the following is the result:

Number of pops:

• Minland(EV3) > Sena20s(EV3) > Cardo(EV3) > BikeComm(2-EV3) = Sena30k(2-EV3) > Sena10s(2-EV3) 

Volume of pops:

• Minland(EV3) = Sena20s(EV3) = Cardo(EV3) > BikeComm(2-EV3) = Sena30k(2-EV3) > Sena10s(2-EV3)

Since this test is done in my office with serious external RF interference, the result may not be accurate enough but just for reference.

Here is the air logs:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/AllHeadsets.7z

BTW, I found out that all of these headset are using Qualcomm chipset.

Thanks,

Will

Hi Will,

Thank you for your efforts in collecting the test data. So while we can definitely tell that using EV3 makes the pop worse, as all of the headsets were using a Qualcomm chipset we can't make any conclusion on whether there is an interop issue with a specific Qualcomm chipset, or if it is due to usign EV3 audio in general. I am still collecting more hardware to test across on my end, though maybe you have what we need already. For the marvell device you were using, would you be able to use it as an HFP client and see if the pops occur on the analog audio output? That will give some additional insight beyond testing more Qualcomm-based headsets.

Also for the logs that you provided, what program did you use to generate those BTT files? They do not appear to be formatted the same as the .cfa files we generally use.

Regards,

Michael

Hi Michael,

These BTT files are generated by another kind of BT sniffer named Ellisys, we borrowed this sniffer from the supplier for two weeks on testing purpose. To open them, please use Ellisys Bluetooth Analyzer Software which can be found in http://www.reeper.com.tw/software.html.

Thanks,

Will

Hi Michael,

After having some discussion with our team, we would like to confirm the following few things with you:

1. Do you think the Sena20 pop is an IOP issue between TI CC2564 and Sena BT hardware?
2. If it is an IOP issue, do you think there is something that TI can do to fix or improve?

Thanks,

Will

Hi Michael,

As per your request, I did the same test at same location again with our Garmin head unit which is using Marvell hardware, i.e., TI CC2564C & Marvell hardware.

Before discussing the test result, I would like to let you know that TI CC2564C is always the ACL Master role in all the previous tests I have done due to our setting, and this time the pop test using CC2564C/Marvell has different results between ACL roles:

TI CC2564 is Maser and Marvell is Slave (the role is same as previous tests with Sena 20):

• I still hear pops in CC2564 TX direction from the air log, it seems to me, there is no much differences than Sena 20
• Air log:https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/GarminMarvellSlave.7z

TI CC2564 is Slave and Marvell is Master:

• I do not hear any pops in CC2564 TX direction from the air log for 5 minutes
• Air log:https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/GarminMarvellMaster.7z

According the above test result, I try to do the same test again with Sena 20, but this time I would like to let Sena 20 be ACL Master to see if pop still occurs, but although the connection is initiated by Sena 20, CC2564 still gets back the Master role after role switch. I checked our stack setting and HCI log, I do not think that our stack sends this role switch request. Anyway, I can not get the test done to compare the result. Can you please check the role switch request is sent from who? Is there a way to disable it?

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/Sena20MasterFail.7z

Thanks,

Will