300 Hz Noise related to transmission timeslots using CC8531 + CC2590

Hi Torje,

Test the following:

• Flash the CC85XXDK with the example project: CC85XXDK-Preloaded demo.
• Use an iPhone/iPod etc and connect this to the LINE IN on the master using a jack-to-RCA cable.
• Stream to the slave.

Hi Kristoffer,

Thank you for your fast reply.

The noise is indeed still present at the slave.

The noise frequency is somewhat altered though, which I guess is due to slightly different transmission time intervals. The square pulses now appears approximately every 2.8 ms (357 Hz).

Best regards,
Torje N. Thorsen

Hi Torje,

Exactly how do you meassure this (so I can reproduce it here)?

-Kristoffer

Hi,

I have tested the PPW slave board together with two radically different analog circuits, and in both cases the noise can be measured (and heard) at the analog output.

However, the most straightforward method i have been using is as follows.

- Master side: CC85XXDK mother board + CC85XX-CC2590DK_EM flashed with CC85XXDK Preloaded Demo/Analog Input Master in free space

- Slave side: CC85XXDK mother board + CC85XX-CC2590DK_EM flashed with CC85XXDK Preloaded Demo/Analog Output Slave in free space

- Improvised measurement probe: Minimalistic amplifier circuit using the Texas Instruments LM3886 chip mounted on a piece of stripboard

The LM3886 has a separate power supply and input, and is thus isolated from the CC85XXDK slave. Depending on the distance between the LM3886 board and the slave antenna, the noise signal can be measured at the input and/or the output of the amplifier circuit.

The above mentioned method is the one I have been using to "probe" the space in the active speakers I am developing, in order to find the less noisy position to place the analog circuitry. However, I have exactly the same noise problems with my prototypes, where the analog circuits are integrated on a mother board with connectors receiveing the CC85XX-CC2590DK_EM reference design slave board. In this case, the CC85XX-CC2590DK_EM reference design slave board and the analog circuits are connected to the same ground using star ground technique. Due to space limitations in the active speakers, I cannot place the analog circuits further away from the slave antenna than approximately 17 cm.

Let me know if you need any further details (descriptions, pictures or other).

Best regards,
Torje N. Thorsen

Hello Torje,

Good on you for conducting a solid set of tests and revealing this problem.  I have been struggling with noise issues for more than 6 months now.  Refer to my posts, "CC85XXDK - Bidirectional Audio Noise, FW1.4" Dec 11, 2012 and "Configurator-Example 'Wireless Headset' Problems", Feb 18, 2013". Note to TI, Could you please answer my latest question which was posted in Feb 21, 2013 - time is running away, and I am starting to believe that the CC85XXDK causes more problems than it solves.

Refer especially to the HS1,HS2.TIFF spectrogram posted on Dec 11, 2012 which shows noise identical to yours, including harmonics, which are unacceptably intrusive.  

Several observations as a non-expert:

1.   The designer of the CC85XXDK has not optimised the input circuitry for IN2, and mic bias noise regulation on the AIC3101 chip seems poor, with the consequence that mic bias noise generated at the Slave (S) for the Example "Wireless Headset" is transmitted to the Master (M) as soon as you add demands on this configuration by adding channels or an extra slave.   When you plug a resistor (eg headset) into the mic input with mic bias on, the problem largely disappears.  When you switch mic bias off and use an external power supply (e.g. 2 x 1.5 V cells) for mic bias, the problem disappears.  By creating an input filter including a series resistor from the mic, then a 5 to 10µF cap to ground also assists, but messes up low frequency response.

2.  This has caused us to switch off mic bias AND use IN1 instead of IN2, taking further advantage of full differential mode of IN1 which IN2 is not capable of.

3.  I have been trying to achieve a 1xM to 2xS bidirectional configuration, which has been plagued with noise, especially when you add 20 to 30 dB of amplification to the 'zero' dB set in some examples such as the "Wireless Headset".  Whilst 30 dB of amplification is the extreme we would use, (and therefore would accept some noise), we will routinely have to use 10 to 20 dB, and will accept no audible noise, especially to annoying nature of the harmonics generated from the square wave you show on your CRO.

Regards,

Geoff Pickford

Hi Kristoffer,

Have you been able to reproduce the problem?

Best regards,
Torje N. Thorsen

Hi Torje, 

Just chiming in from the side here. Do not have access to any boards right now so this is a theoretical approach. 
For every timeslot there is a rather abrupt Radio On/Off situation where the CC85XX+CC2590 goes from 7mA to ~60mA (peaks). This results in power / gnd pulling that can be picked up by the analog portion of the design. If this is the case, filtering prior to the ADC would not help as the problem might be due to noise on the ADC reference itself. 

Regards, 
Kjetil 

Hi Kjetil and Kristoffer,

The noise is not caused by power/gnd pulling.

When conducting the tests described above, the test probe containing the analog circuitry was electrically isolated from the CC85XX-CC2590DK_EM slave board (Separate boards, separate power supplies - no electrical or physical link between the two). This eliminates power/gnd pulling as a possible cause of the noise.

The problem simply seems to be due to radiated EM energy from the PCB antenna happening to contain a rather nasty frequency component around 300 Hz because of the 3 ms transmission time slots.

Kristoffer, have you been able to reproduce the problem?

I am currently testing a new revision of my active speaker design, where I have optimized the distance between the CC85XX-CC2590DK_EM slave board and my analog circuitry. The noise level is quite improved, but it is still present and rather annoying.

By the way, will you stick to the 3 ms time slots in future releases of the firmware, or have you by any chance planned a release with another time slot configuration ?

Regards,

Torje

Hi Torje, 

Chiming in on the timeslot question. 

Timeslot is an artifact of the configuration (optimal timeslot is calculated based on all selections that makes an impact to give best link performance) and we have no plans of changing how this is done. 

You can override the automatic timeslot period in the Advanced Options panel for your master configuration as long as the timeslot is a valid option for any given configuration. The Configuration tool will report error if you try to override with a non-working timeslot, either directly in that panel or when you try to flash the device. 

Regards,
Kjetil 

Hi Torje,

I also battled noise coupling in my design. I ended up moving the antenna and RF electronics away from the DAC and analog parts. I2S on ribbon cable to the DAC. I needed some 30cm distance to analog electronics to quiet the buzzing.

Kind regards,

Thomas  

Hi Thomas,

Thank you very much for your comment. It does not surprise me that you needed as much as 30 cm. Without shielding I need such distances too, to lower the 300 Hz noise to an acceptable level.

However, I have finally been able to cope with the noise problems by using a flexible antenna connected to the CC85XX-CC2590EM reference design based slave board with a cable instead of using the inverted F PCB antenna. This allows optimizing the antenna's position relative to the analog circuitry. I have been able to place the antenna in such a manner that the pole piece of one of my speaker drivers acts as an effective RF shielding. The rear lobe of the antenna seems to be sufficiently deviated by the pole piece to not disturb my analog circuitry. By doing so, I have actually obtained acceptable noise performance with the antenna placed some 15 cm from the DAC/amplifier.

The solution is not optimal though, as the flexible antenna's efficiency is quite lower than that of the inverted F PCB antenna, so the link robustness is somewhat lowered. Also, I am not quite sure about the possible side effects of messing up the antenna's natural near field with such a radical shielding, but the preliminary in-situ link robustness test results are encouraging. Anyway, this is the only acceptable solution in my case as long as the PPW technology is inherently noisy within the audible frequency range because of the timeslot period.

Best regards,
Torje N. Thorsen

Hello all!

I have been built and manufactured a prototype based on PurePath Headset reference design. While working with both designs (my own and Headset  kit) I have noticed the same problem: noise in around 300Hz range. Funny enough that noise is present also in the original commercially available Headset kit. Using simple hand-probe testing (touching board in different places) it can be noticed that noise is coupled to the input of audio device (IN3 of AIC3204 in this case)

A little bit about my design: it is a microphone application using CC8520 + CC2590 with inverted-F antenna, AIC3204 as audio device. There is also a connector for an external antenna. Using that noise is less present. On board there is also a microcontroller and battery-power circuit. 

Before going into much of detail I wanted to ask if there is any solution available from Texas Instruments regarding this problem?

We experienced the same problem and found that if the mic bias was turned off, the noise disappeared. We could use the mic bias if it were filtered or use an external mic bias.

Geoff

Hi Goeff,

Can you please describe a bit more specifically how did your organize the microphone bias filtering and separation?

I tried filtering the bias line to ground via a capacitor as well as taking it straight from +3.3V power feed. Non of those helped getting rid of the noise completely. Did you turn the MICBIAS off through the PurePath Configurator?

Thanks!
Mikelis 

Hi,

We first disabled the mic bias using the configurator and the noise disappears. The microphone does not work but a signal generator shows that the signal path is still active. Then we used an external circuit with a battery to provide the mic bias and fed it into the inputs to prove that the microphone was not picking up the noise. Then we used the mic bias from the EVM board (enabled by the configurator) external to the board and added a 1 kohm resistor in series followed by a 10 uF capacitor to ground, another 1 kohm resistor from the capacitor + to the microphone +, another 1 kohm resistor from the microphone to ground, and fed the microphone + and - signals to one of the phono plug type inputs, enabling that input in the configurator. Using the filtered mic bias voltage gave some noise but it was acceptably small. You cannot put the capacitor directly on the mic bias output, it needs the series resistor.

I am sorry for the sketchy description but I am doing it from memory so I hope it is clear enough. The evm board needs to have a filter fitted on the mic bias circuit.

Cheers Geoff

Dear TI people,

I wish to revive this post since i do not think TI has given it a solution. I, like others here, am experiencing noise

picked up by the microphone on each party (master/slave) and transmitted to the other party. This is the same 300Hz noise discussed before. Does TI have an official response/solution to this or should we expect this noise to be part of the Purepath technology?

As you guys know, it is simply impossible that a wireless audio system will have such an inherent audible noise.

Looking forward to hearing back from you.

Thank you,

Nir Dvash,

ActiVocal LTD

Dear Nir Dvash,

This post I am writing may be deleted by TI.  However, please do an E2E search using Pickford as the main search item and using 'noise' in "all these words".  

You will find 24 posts on this subject including references to other people with the same problem.  Your problem is well known to TI and should have been fixed by TI a long time ago.

After several years of frustrating work with the CC8530, my organisation has now dumped this device mainly due to ht following factors:

1.  very slow development of promised firmware

2.  poor responses from TI - most likely due to inadequate resources because I sensed that the persons responding were trying to help.

3.  At one stage, I was 'diverted' to a private post, maybe because I was being too blunt about TI products.  I was assured it was not this, but I am not convinced.

4.  lack of transparency of the firmware meaning that for non-straightforward designs, things go too hard because one was not in control of the firmware/software and had to design within difficult to understand parameters.  we have therefore gone back to a competitor's device where one has total control of all software.

5.  poorly designed development boards which had inadequate filtering for the mic bias line.  This in itself would not have been a major factor except that to my knowledge, TI have never acknowledged this fact and come out with a work-around.  It was therefore left to developers to find the problem and separate it out from software or device problems - one never expects to have a major bug in an EVB. Further, some of the AIC3101 EVB schematics had incorrect pin labels and incorrect or misleading coding generated by the AIC3101 EVB, which added to the problems.  Worse than this, even though I pointed all these problems out (which were acknowledged in my posts) there was no public correction to assist other users - again pointing to a lack of management resources, and perhaps a lack of consideration of developers.

In short, my team has been really disappointed in TI's handling of problems found on this forum, and believe that a major shake-up is warranted to establish transparency and fix and publicise hardware and software problems.  Even though we continue to use some of TI's more 'run of the mill' devices, it would certainly take a huge amount of convincing to get my team back to this device.

Regards,

Geoff Pickford

Hi Torje, We (Geoff Pickford and Geoff Trott) have spent some time chasing this problem and posted our conclusions which explain the source of the noise and suggest some solutions. The source is the micbias supply from the chip which is reacting to the extra current drawn by the RF transmitter. If you use an external supply to bias the microphone there will be no noise, but that requires external circuitry for the EVM board. You can use the micbias from the chip if you filter it with a 1 k resistor in series with a 10 uF capacitor.  That reduces the noise to an acceptable level when we increased the gain to make the microphone signal very loud.  The problem is that the EVM board does not have the facility for putting in such a circuit without cutting a track and just putting a capacitor across the output of the micbias supply is not recommended and does not work.  So when you make your own PCB, you can make sure that you put in the filter and the noise should not be a problem.  So the fault is in the micbias supply in the chip and it is aggravated by the EVM board not having filter facilities. TI has not acknowledged this problem in any way. That is a worry!

Hi Geoff and Geoff,

Thank you for your comments. I have tried playing with the micbias issue but still the noise is there. I am attaching the audio part of the schematics. It is true that if i disconnect the micbias, the noise is 100% gone and i can, for example, connect audio from my PC instead of the MIC and get pure audio on the other side. What does this mean?

I have tried filtering the micbias, i have tried supplying an external voltage to the mic instead of the mic bias, nothing helps, the 300Hz noise is still there.

 HELP!!

Nir.

 7612.AUDIO _ PAGE1.pdf

Hi Nir Dvash, Mikelis and Geoff2,

As I can see from Geoff Trott's comments, the mic bias seems to be a sensitive point when using the TLV320AIC3101.

However, this is not the only issue that can cause this famous 300 Hz noise.

As I explained in my initial post, the root cause of this noise seems to be the timeslots used in the PurePath protocol. As Kjetil at TI mentioned in one of his comments:
"For every timeslot there is a rather abrupt Radio On/Off situation where the CC85XX+CC2590 goes from 7mA to ~60mA (peaks). This results in power / gnd pulling that can be picked up by the analog portion of the design."

Furthermore, this abrupt radio on/off situation creates abrupt RF energy fluctuations transmitted by the antennas (master side and slave side antennas). It seems that the envelope of the timeslots gets easily demodulated by any non-linear element present in the design, such as PN-junctions picking up the radiated RF energy.

So this annoying 300 Hz noise has several ways of intruding into your audio signal:

• By conduction - power/gnd pulling and pollution being coupled to the analog circuitry through the electrical connections on the board
• By radiation - RF energy radiated by the antenna and picked up by the analog circuitry

In my case, I have a lot of 300 Hz noise, but this has nothing to do with the mic bias. I do not even use a microphone, nor the TLV320AIC3101. The noise definitely seems to be radiated by the slave antenna (and its feeding cable as well) and picked up by the analog circuits in the design.

Nir, maybe you could try to find out how the noise gets into the mic bias circuit? I would try experimenting a little bit with the antenna position if possible. As Mikelis stated in his comment, when using the external antenna the noise is less present. It may seem that the mic bias problem is of the "radiated" type rather than "conducted".

A relatively simple way of testing different antenna positions is to get hand of a cheap antenna with a cable attached to (such as Molex' flexible patch antennas), cut off its connector and solder the antenna cable directly to the CC85XXEM board. By doing so you can move around the antenna in order to "probe" the space surrounding your design.

Personally, I have never achieved acceptable noise performance without extensive shielding of sensitive circuitry.

If there is a problem with your mic bias filter, I think it is better if the Geoffs take a look at it, as I have never been using the TLV320AIC3101.

Good luck! You are not alone struggling with these noise problems.

Torje

Nir,

I assume from your circuit diagram that you are not using the purepath wireless EB from TI for the AIC3101. If you are able, you need to add another 1 k resistor between pin 15 and R7 of your circuit diagram and add a 10 uF capacitor from the junction of that resistor and R7 to ground to filter the micbias line.  When we used that filtered circuit with the purepath wireless EB using the same input pins as you have, it reduced the noise sufficiently for our application. If we used an external battery across your R7 and R8 (disconnected from the micbias pin), the noise was further reduced to the point that it was well below the level of the other noise picked up by the microphone and could not be identified.

I am sure that poor layout and shielding may cause pickup from the RF transmitter (but you do not have that occurring when you turn off the micbias) and if this is in the microphone itself, it would be hard to remove.  We did not have that problem with our setup.

Geoff T

Hi Guys,

Thank you for your help. I have now tried it all, and still no good (even powering the micbias from an external battery). The only, but the only thing that quiets this noise down is if i put my finger on the printed F antenna edge, but i am not sure what this all means. Anyone?

We will prevail!

Nir.

Everyone, 

Just to chime in from the TI side here. 

At a frequency of 1 / timeslot, the CC85xx goes abruptly from roughly 8mA to a much higher amount (how high depends on the output power, and the inclusion of the CC2590 and CC2591 range extender) when the Power Amplifier in the radio turns on. This will cause a pulling effect on the power and gnd planes on any board that has to be dealt with. How big of an issues this is depends very much on the total output power of the CC8520+CC259x, the higher higher output power the worse the pulling will be. By default and out of the box for our development kits the timeslot is 2.5 msec resulting in 400Hz, but depending of configuration this can be from 1 msec to 5.75 msec. 

As Torje has stated in this email, his experiments implies that this is emitted and can be picked up by any non linear component in the analog /audio path and this is a known effect (google RF immunity GSM, Bluetooth, Wifi etc). The emission from the DK and DK-HEADSET are within the limits defined for our radios according to ETSI and FCC, but this is emitted from the board at a certain distance and not necessarily true for components on-board.  

For both of the above issues, proper consideration when doing the layout is important and as I am far from a RF or Audio HW engineer I just include some things I found online. Key things to have in mind is start routing, decoupling, length of sensitive traces, antenna positioning etc:
http://www.maximintegrated.com/app-notes/index.mvp/id/3660
http://www.digikey.com/Web%20Export/Supplier%20Content/Nuvoton_816/pdf/nuvoton-an-cs002.pdf?redirected=1
http://www.intersil.com/content/dam/Intersil/documents/an12/an1299.pdf

With regards to the CC85xxDK, there seem to be an issue with the microphone input depending on impedance, biasing and gain in the AIC3101. For those who have been following PurePath since the very beginning, the CC85xxDK was released prior to microphone being enabled in the configurator tool and I assume this was simply not tested good enough when this features was enabled long after the launch of the kit. Do not know if we ever tested if there where specific pins that caused the radiated effect. 

I appreciate all of your sharing your findings and experience with other forum members. We have tried as best ot be open about these issues and helping our customers getting quality boards that are problem free. Not that it helps in a community like these, but the CC85xx is shipping in many different products (speakers, headphones, headset, gaming headsets, subwoofers, microphone, guitar cable replacement etc) for both the consumers and pro markets. 

Geoff Pickford, this is a open community and we do not delete posts not matter how critical they are to TI or our solution in specific, at least not on the PurePath Wireless section of E2E. Shame that you did not have a good experience working with this part or the team behind the CC85xx. To at least cover part of your issues:

1. Shame that you feel this way. From my view we hardly never missed any release target for our releases and for the most part we included what we intended for every release. If you where given other information that was not aligned with expectations then we're off course sorry for this. 
2. Not sure what to really say here. We are trying to have a 100% reply rate here on the E2E section, but agree that sometimes priority call can cause delays to responses and in some cases we are not capable of getting to the bottom of issues. 
3. Private posts have been used by the CC85xx team as a more direct form of support that is more effective on our end. It has never been due to criticism or blunt opinions on our devices (search the forum, you are not the first). In some cases we have diverted the discussion here to talk roadmap and upcoming features that we wanted to keep the lid on for the general board (based on your first objection, this seems also to be the case for you). 
4. Firmware running inside is not open but our documentation is open and extensive. From my work with this device there is extremely little questions asked that could not be answered by our User Guide and the configurator help system. I agree that this a different choice than some of our competitors but we have our reasons for doing it this way. If you feel that this is making it hard to design with us, then I guess a good luck and best wishes for the design using our competitor. 
5. Can not talk for the AIC EVB schematics, but consider this post as, albeit very late, acknowledgment that there are issues with the CC85xxDK board with regards to the mic input. 

Best regards, 
Kjetil

Hi Kjetil,

This is Nir. I have read in earlier posts that in some cases a wrong or not configured well audio file was the cause of the noise. Would you be so kind going over the attached file and making sure it is 100% compatibale with our audio hardware (also attached)?

Thank you very much!

Nir

5123.Nir.zip

Sorry, just wanted to stress one thing again: Connecting an audio source(iphone/PC)  instead of the mic produced pure, 100% great audio on the master side, with the current audio file and hardware. Lowering the volume to zero on the audio source proved this.

Thank you,

Nir.

Hi Nir,

This is a classical issue with wireless audio, let me speculate a bit...the fact that the only thing which improves is to put the finger on the antenna makes me think it is the electromagnetic field from the antenna inducing currents in the "analog mic path" (another source could be power supply noise). The reason why it is silent when you connect a Iphone/PC and not when connecting a microphone is difference in the impedance of the two. An iPhone/PC has somewhere between 10-70 Ohm as the output impedance whereas a condenser mic has around 10-20kohm and a small induced current + large impedance results in "audible noise voltage". What also typically happens when using a microphone is that a high gain on the input of the ADC is needed, thus the noise is also amplified. The key to reduce this is typically in the layout of the system. Suggestions that can improve the system:

• Place the antenna and the microphone far apart (the longer the better)
• Use a digital Mems microphone (I2S or PDM) much better EMI performance than analog microphones
• There are microphones designed to be used in noisy RF environments(like cellphones) use one of those.
• Make the traces between the microphone and the ADC as short as possible
• Have a solid ground plane below the analog traces.
• Split the analog and “RF” ground planes
• Minimize power supply noise with proper layout and decoupling (ideally split the power supplies and use separate LDOs to feed the RF chip and the ADC)

Hope it helps!

Hi Per,

Thank you. All of your suggestions (and this is why I am worried…) , apart from using a special microphone for RF environments have been implemented in our hardware design. Do you have any experience with such a microphone? Any specific part number you can recommend?

Nir.