This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC85XX family firmware 1.1 and 1.2

Other Parts Discussed in Thread: CC8531, CC8521, CC8520, CC8530

Hi,

May I know when will the firmware (1.1 and 1.2) for PurePath Wireless released?

Thanks

Fred

  • Can these later releases of the firmware be loaded into a cc8520 giving it the added functionality?  Or, must the firmware be loaded into later versions of the chip to be able to use the functionality?  For example, can I load FW 1.2 into a cc8520 to achieve USB functionality, or do I have to wait for the cc8521 to be released, and then use the cc8521 with FW 1.2 to have USB functionality.  Also, I see from a photo in the CC85XXDK User's Guide that the CC85XXDK has been shipping for some time with the cc8531 chip, but a part number search on TI's website returns nothing.  Is there any guidance when further releases of the chip will be available for purchase/sampling?

    Sparkchaser

     

  • Sparkchaser,

    To try to answer you questions... You will be able to load later FW revisions into CC8520 but to use the USB functionality you must have a CC85x1 device and to use more than 2 audio channels a CC853x device must be used. You are correct we have mounted the CC8531 in the CC85xxDK since this device is capable to "do all functions". We have the silicon ready for all the devices (CC8520, CC8521, CC8530 and CC8531) but as you know, this device is highly FW dependent,  thus we will release the devices when the FW to support the functionality is ready.

    Cheers,

    Pelle

     

  • Hi Pelle,

    After reading about your CC85xx chips in July 2010, i convinced a customer to use your CC85xx chipsets for a project that requires bi-directional functionality (actually, high-quality  full-duplex mono from master to slave and slave to master).

    Can you now confirm (near end of Q1) that the FW 1.3 is still on schedule for the June 2011(near end of Q2) timeframe ?  

    Thanks!

    ted

     

  • Hi Ted,

    I can confirm that we are aiming at bi-directional firmware towards end of Q2. As you probably have seen, the point-to-multipoint (up to for slaves) firmware is already on the web since a couple of days.

     

    Best Regards,

     

    Erling

  • Hi Erling,

    We are also patiently awating the release of bi-directional firmware. It is a month on from the last update - are you still on schedule for a June release?

    Our decision to go with the CC85XX family of devices hinges on this functionality. (Plus the addition of a bi-directional data sub channel).

    Other than the lack of the two aforementioned features the system is looking really excellent - keep up the good work!

     

    Best Regards,

    Michael.

  • Hi Michael,

    I can confirm June is still the plan. We are progressing on other features as well, you will see a new release this week where we have added support for generic audio codecs/DSPs (users may, using an XML-based file format, add support for additional audio devices that are controlled by I2C and/or up to 4 GPIO pins).

    (If you do want to try out a beta of bi-directional firmware you would need to get in contact with local TI sales and set up an NDA between our companies. Or wait for the official release, June is not far away.).

    Best Regards,

    Erling

  • Erling,

    That's good to hear. We have applied for an NDA and will begin testing the Beta as soon as the paperwork is completed.

    Many thanks for the quick reply,

    Michael.

  • Dear Erling,

    Can we please confirm that you are real close to releasing 1.2 with bi-directional support ?  Inquiring minds here...

    Thanks,

    ted

     

  • Hi Ted,

    I can confirm we are very close  - so almost on time with the release. I recon it should be on the web in 10 days time.

     

    Erling

  • Thanks Erling.   Will we see the 1.2 version released this week?

    Thanks,
    ted

     

  • Me too! Me too! Inquiring minds want to know.  1.2 firmware released this week?

    Thanks,

    Mark

  • That is the target and unless our release procedure prevent us from doing so it will be available late Friday or as soon as the servers are able to push this to the web. 

    Kjetil

  • Thank you for the reply.  As you can tell, many of us will be watching for it.

  • Sorry to be a nudge, but am I missing the 1.2 release?  Did it get delayed?

  • ditto pls, thanks!!

     

  • It was released today!! ENJOY! :-)

    -Kristoffer

  • It's out now :) ENJOY!

    -Kristoffer

  • Hi Kristoffer,

    A quick query regarding slave to master audio streams in this release of the firmware. For our specific purpose we require two channels from the slave back to the master (in addition to the two from the master to the slave). As per the technical brief CC85XX when will this be implemented?

    Kind regards,

    Michael.

  • Thanks for the 1.2 firmware with bi-directional audio.  Its working very well but I do have one issue.  At some point in time, and I haven't been able to positively determine the trigger, It appears that the mono channel overloads everything and all audio goes bad.  The only way for me to clear the system is to full power down both master and slave by removing all power sources.  While looking at the configurator, I see that the output from the master is single ended line out and single ended headphone out.  Is there any way to configure it for MIC level output with MICBIAS?  If I plug a set of headphones into the master output, it works without issue.  Its only when I take the output and plug it into a MIC input that it goes bad.

    Thanks

    Mark

  • I may be slowly answering my own question.  Is there a reference for the I2C registers?  I've been studing the Audio Customization.  I may also be way off track. :)

  • Hi Mark,

    I don't understand what you are trying to do.. Can you describe it again with more details please? Sorry...

    -Kristoffer

  • I am using the system as a wire replacement for wired headsets.  The process is unplug the headset from the target system, plug the headset into the slave, plug the master into the target system.  I have 3 different headsets and 4 different target systems.  I'll state how they are behaving but I am fairly convinced that it is a mic impendance mismatch between the master and one target system.  I have tried all three headsets on all 4 target system.  All headsets cause the same issue on one of the target systems.  The mic audio works for a indeterminate period of time.  I have not narrowed down the trigger.  All the audio goes into to what I will call an overload.  Uncontrolled loud volume that is extremely garbbled.  My only reset is to remove power from both slave and master.  I'll be checking the impedance today.  From what I could see in the configurator, it appeared I could fine tune the master mono out to adjust for the impedance mismatch.  It may be easier to put in additonal components which is what I will be trying today.

    Did this help explain what I've encountered?

    Thank you.

    Mark

    P.S. this is an awesome piece of engineering and I know there is a simple resolution.  :) :) :)

  • Mark,

    What is the target system? Are you using our CC85xxDK-headset, CC85xxDK or your own HW?

    Cheers,

    -Per

  • I am using the CC85xxDK-headset.  We will need to take the discussion out of the forum for me to fully disclose target and usage.

  • I will add you as a friend here on E2E. Then we send private messages, a nice feature :-)

    Cheers,

    Per H

  • I did a lot of testing today and found that I can overdrive the audio input regularly.  It does not appear to be related toe the volume level on the input.  Its morethe content of the audio.  I read a lot about the AIC3204 and all the registers for configuring audio in and out.  Wow, I have no doubt that it can be configured to eliminate the issue that I am seeing, the question in my mind is where to start.

    Now for the newbie question...From reading the firware description, the audio input is configured for line level input.  I've thought of line level as a consistant power level that doesn't change.  All the systems that I have are more of a headphone/speaker output will variable power out.  Is it possible to configure the input to be expecting more of the headphone type of audio streams?

    BTW: the overdriving is not restricted to the 1.2 firmware, I ws able to overdrive the 1.1.1 firmware as well.

  • Hello Mark,

    I will start by saying that I have never done anything with the AIC3204, but I think I can nevertheless give you some information concerning your questions.  Taking a look at the data sheet, you are right when you say that the chip offers a wide range of configuration options.  But one thing that the chip cannot do, from what I see in Figure 1-1 of the the datasheet, is that it cannot handle an input signal which is too high.

    In Figure 1-1, the first stage of the input signal processing is a programmable gain amplifier with 0->47.5 dB of gain (which is a minimum gain of 1 V/V to a maximum of 200 V/V) whose output is then sent to either the DSP block or to the analog output drivers.  Having a minimum gain of 1 means that any signal which is too large cannot be reduced to a level which is suitable for the analog block.  This is not necessarily a design fault, this is more or less a design requirement of CMOS analog systems that the analog signals should not exceed the levels of the Analog supply or ground levels.

    According to the data sheet, if you have your input set to a common mode level of 0.9, the device is expecting an RMS input level of only 0.5 Vrms (about 0.7 VAC).  If your input signal is less than this, the AIC2304 can apply gain to the signal while it is still in its analog state using the input PGA which will allow the use of the full scale range of the ADC (if you have a digital block designed to process 16 bit data samples, might as well use all 16 bits).  But, if your input signal is greater than this, the PGA cannot apply attenuation, and signals greater than 0.7 VAC will start to be distorted, and anything greater than 0.9 VAC will be clipped.  If your headphone out is from a system powered by a single AA battery with a simple opamp output driver, then it is a pretty good bet that its output signal will never exceed 0.75VAC.  However, systems powered by 2 AA batteries (for 1.65VAC), from a computer headphone out which is most likely powered by a 3.3 VDC rail (for 1.65 VAC), or systems with class D differential output (where output VAC can be roughly 2x input voltage supply), then there is a very good chance that the headphone output will overdrive the AIC3204 analog inputs.  To configure the input to be more accepting of headphone type outputs of all sorts up to 2.5 VAC (or whatever you expect your maximum level to be), a resistor divider on the input with a signal attenuation of 2.5VAC/0.7VAC will ensure that the inputs are never over driven.  When the input signal is much lower than 0.7 VAC, then the automatic gain control (AGC) along with the input PGA can apply up to 47.5 dB of gain as necessary.

    As far as your observation that it is more the audio content than the audio level which overdrives the system, you are pretty much correct.  A single frequency with 0.7 VAC amplitude will sound quite loud, but will not overdrive the system. But a chord of 8 notes each with 0.1 VAC might not sound so loud, but could easily overdrive the system from time to time.  Each signal has its own amplitude at its own frequency, and while the apparent loudness is constant, at certain points in time, it is possible that the sum output of the 8 individual waves could have a peak amplitude greater than 0.7 VAC even though the time averaged RMS value is considerably less than 0.5 Vrms.

    This response turned out to be a lot longer than expected when I started typing, but I hope it sheds a little more light onto the subject,

    Sparkchaser

  • A big thanks to Per H. and sparkchaser.  With thier guidance and suggestions, I was able to determine that I was overloading the input of the master device.  The voltage of my system output ranged from 0 to almost 10v with spikes to 12v.  The AIC3204 did not like that.  I built a voltage divider to get the voltages down into the .9v nominal with spikes to 1.1v.  The AIC3204 is very happy with that range and it allows the AIC3204 to apply AGC to maximize the signal.  Everything is working as designed.  Great system!

  • Now we are already one step ahead, FW1.2.1 is out!

    www.ti.com/ppwc

    - Erling

  • Would like to further enquire about the USB and bi-directional function in FW1.2.

    I understand that with the new firmware, slave can send audio signal back to master. Would like to know more.

    1. Can the Slave send more than one audio channel or it is restricted to one only at this moment?
    2. If I need simple control to send back to Master, is it possible. For example, I would like to stop playing the music or change to another track, can I send simple command from Slave to Master?
    3. I reckon that I can stream music from PC to Master through USB right? And the audio will be transmitted to Slave wirelessly.

    Regards,
    Poh Leong

  • I have tested some of the demo SW from the configurator.

    1. Can the Slave send more than one audio channel or it is restricted to one only at this moment?
      It seems that only one audio channel is available from Slave to Master.
    2. If I need simple control to send back to Master, is it possible. For example, I would like to stop playing the music or change to another track, can I send simple command from Slave to Master?
      Not able to test with the demo board.
    3. I reckon that I can stream music from PC to Master through USB right? And the audio will be transmitted to Slave wirelessly.
      Can be done with the USB input bi-directional demo SW. However, I could not transmit audio back to Master from Slave. I loaded analog input/output bi-directional SW for the Slave. When I tried to use a MIC, I could hear nothing at Master side, which is connected to my laptop. Am I supposed to hear something from my laptop speakers?
  • Hi Poh,

    Sorry for the late reply, but let me comment on your questions:

    1. This is possible if you create some new application roles. Go to the application_roles folder in your install folder (default path is C:\Program Files\Texas Instruments\PurePath Wireless Configurator\application_roles). Copy m_headset_base_station.ppward and give it a new name (for example m_headset_base_station_2up.ppward). Open the file in a text editor (notice the disclaimer in the start of these files) and change the following: <name>Master/Headset base station 2UP</name>, <desc>To slave: 2 audio channels. From slave: 2 audio channel</desc>, <aif_output_count>2</aif_output_count>. Do similar with s_headset: <name>Slave/Headset 2UP</name>, <desc>From master: 2 audio channels. To master: 2 audio channel</desc> and <aif_input_count>2</aif_input_count>. Now restart the configurator and you will find the new application roles in the list. Make sure the audio streaming panel for both master and slave so that the channel mapping is correct. You should now have 2 channels in both directions. The reason these application roles are not part of the application role list is because Texas Instruments haven't had the time to test this application yet (as described in the disclaimer). Due to this the performance of modified application roles can vary. In the future more and more application roles will be added to the list.
    2. This is possible by using the HID functionality. Check out the Remote Control section in the "User Interface" panel in the configurator. HID is thoroughly described in the family user's guide: http://www.ti.com/lit/ug/swru250h/swru250h.pdf
    3. What hardware are you using? CC85XXDK or CC85XXDK-Headset? If you're using CC85XXDK-Headset this can be achieved simply by flashing the devices with the example project CC85XXDK-Headset USB Headset Demo. If you're using the CC85XXDK then you need to solder on some resistors, and modify the example project a little. You should not hear the audio from the slave on your pc speakers. Instead try to run sndrec32 and record something while talking into your mic. Replay this recording to verify that audio was sent from the slave to the master.

    -Kristoffer