CC85XX Firmware Clarification

Hi Michael, 

To clarify, we have merged the bi-directional support into FW1.2 so that we can release both USB and bi-directional audio in the same release. It is still to early to specify what will come after the FW1.2.0 release, but the recently updated User Guide gives some indication. 

For USB we will support some of the Basic Audio Devices (HT1, HS1 & MT) as specified here:
Audio Device Class Spec for Basic Audio Devices and Adopters Agreement 

In addition we will implement a limited version of the audio device class.

We will also support a limited set of HID commands (common controls inplemented in a audio remote control). 

The details on the configurability of this is still TBD.

Not sure what more information you need on the I2S clocking arrangement. Can you be more specific?

Regards, 
Kjetil 

Thanks Kjetil.

From the previous posts, my conclusion was that a merge of the support functionality had occurred in regards to bidirectional mode and USB support in FW V1.2.  I just needed clarification.

In regards to the I2S, by my understanding with FW V1.1, the protocol master is the master of the audio clock.  This clock may be generated internally by the CC85XX or it can be sourced externally from the I2S interface.  The protocol slave(s) (of which there may be more than one) will recover this clock using a PLL.  Currently, the protocol master must be an audio consumer (sink) and the protocol slaves must be audio producers (source).  I need some clarification on the audio clock functionality in bidirectional mode.

1. The protocol master is now both an audio sink and an audio source.  Is the protocol master still the master of the audio clock so that sink and source is synchronized to the same clock?

2) Can the protocol master still use an external clock source i.e. sourced exeternally from the I2S clock?

I have another question regarding bidirectional mode:

3) In bidirectional mode, is it possible to have multiple protocol slaves?  Obviously only one of these slaves will be abl eto send audio to the master, but all of them swhould be able to receive audio from the master.  If this is possible, then can the sender be selected in real-time or only at compile time?

Thanks,

Mike

Hi again Michael. 

Thanks for the clarification. 
Nothing have changed in this regards. The protocol master in a PurePath Wireless network is always the master of the audio clock and the slave clock will be tied synchronized to this. One can still use a external clock on the master side.

One can have multiple slaves and from a protocol perspective all slaves can implement a bi-directional audio link. The master will receive audio from each slave and output accordingly to I2S (or USB). The 4 slaves / 4 mono channels limitation still stands and there are some other limiting factors preventing all thinkable combinations from working. We're still carving out which combinations we will support in the FW1.2 release.

Regards, 
Kjetil 

Thanks again Kjetil.

One last question - am I to presume that the master still needs to select which slave it is listening too at any given time?

If audio can be received from all 4 slaves simultaneously (mixed) that would be even better!

Mike

Mike, 

No need to select at the master side. It will receive all channels and output them on separate I2S channels. 
Just to clarify, a master in a PPW can be statically configured to support up to 4 channels. Each of these channels can be in any directions, but for a given configuration the setup will be fixed. What this means is that you can have a CC8530 master that can be set-up to support 4 microphones, but in this configuration it can not send any audio. Another configuration can be for a headset application where it sends two channels (headphone part)  and receives one channel (microphone part). 

Once again, the number of thinkable combination is quite large and we will not support them all due to various limitations. The exact list of 'applications' we will support will not be ready until the release of FW1.2.

Hope this clarifies. 
Kjetil 

Hello Kjetil,

Is there an inherent limitation that prevents the master from sending one audio channel while receiving 4 channels or is this just one of the "less likely" scenarios? How about sending 1 while receiving 3? Would it be possible to give a short explanation of what the limiting factors are so that users could get an idea of what scenarios might be supported in the future and those that definitely won't be (due to inherent limitations e.g. bandwidth etc)?

Thanks,

Grant

Grant, 

The first scenario you write is a no-go due to it breaching the 4 channel maximum. 
It's hard to go into the details on what is limitation as there is no straight answer. It's a mix of protocol timing, buffer/memory usage and test coverage (we like to test all variants throughly to see that everything is OK). If the latter is limitating, they might be included in later releases if we see a need from our users to support such a scenario.

The application scenarios we will cover are the more obvious ones like headset (master send to and receive one channel) and some microphone scenarios. 

What is the application that would require something like sending 1 while receiving 3?

Regards, 
Kjetil