CC85xx slaves

Hi Calum, 

To understand the limitations around the 4 slaves one need to understand the basic of this protocol. 
It is a multi-cast protocol where each and every slave in the network will individual acknowledge packages from the master. The overall RF bandwidth and protocol timing is limiting the number of slaves the protocol can support. The difference will be that you are trading protocol robustness / co-existence performance when adding slaves as each slave added will add to the bandwidth need which otherwise could have been used to increase the performance. User Guide section 2.4.2 gives some insight to this topic (anatomy of a timeslot).

The default and standard with regards to frequency hopping is 18 channels, each 4 MHz wide. One can statically define the channel usage during configuration time (using the PurePath Wireless Configurator, a PC tool that will generate the FW image to be programmed into the device in production) or dynamically during run-time using and external MCU through the External Host Interface (EHIF). See User Guide section  2.4.3 and 3.4.5

802.15.4 is a different standardized radio interface not supported with our wireless audio chipsets. 802.15.4 is limited to 250kbps and not useful with regards to wireless audio transmissions. 

Seems like you already are familiar with our documentation, but the key document to understand or read is the User Guide:
http://www.ti.com/lit/ug/swru250l/swru250l.pdf

Regards, 
Kjetil 

Thanks Kjetil,

What I really want is to have a master and multicast or broadcast to 16 slaves. Have all slaves looking at the same channel - is that possible? The docs don't really say how many slaves you can have in a multicast situation.

If not is it possible to have 4 slaves listen to one audio channel and have another four listen to another audio channel and so in - kind of like have 4 broadcast channels?

Cheers

Calum

Hi Calum,

  If you want to disable the handshaking and simply broadcast the streaming audio on a certain channel, then you can have as many receivers out there as you like, no limit.  But if you want some type of robust link, to monitor or ensure the receivers are actually there, then you have to implement a handshake, from as complex as the CC85xx to a simple ACK at regular intervals (or even just once).

  Give us some additional info as to what the system requirements are, what the environment is, and what the overall objective is.   I worked on a stadium broadcast system a while ago where the only requirement was to broadcast, no ACK or data integrity was required.

-Leonard

Analog Applications - ACAT Dallas

Hey Leonard,

Your stadium application sounds exacly what we have - send out at max power and just assume the receiver gets it - no ACK or feedback required.

This post - http://e2e.ti.com/support/low_power_rf/f/382/t/185420.aspx indicates that it wasn't possible.

Can you give me any documantation on how the "broadcast" works - do you have to set each recevier up to be on a particluar RF channel - is there still frequency hopping?

Any info on this would be great.

Cheers

Calum

Calum, 

The maximum number of slaves, in any mode of operation, with the CC85xx is 4. 
The CC85xx does not support broadcast.

Regards,
Kjetil 

Yes, true, with the CC85xx, but we could use a generic LPRF device. 

Here is an App Note for using the CC1101 at 900MHz, which could also be an advantage for longer range:  http://www.ti.com/litv/pdf/swra237b .  Similarly, at 2.4GHz: http://www-s.ti.com/sc/techlit/swra295 .  Not high-quality audio, though, most likely voice quality.

Leonard

Greetings Leonard,

I'm a client of Calum, and he was searching Ti for the application that I'm interested in. You made a couple of statement that are very important to me. The first of which is "broadcast the streaming audio on a certain channel". If this is possible, how many channels are available for this process? Is there a utility/command that allows you to select a certain channel, and disable the over-the-air handshake/protocol? I would appreciate your response and any data you can share from your previous project. Thank you.

Mehrdad

Hello Mehrdad,

  As I understand, this design is to stream audio to an unlimited number of devices, is that correct?   

  The CC85xx that was first proposed can support up to four receivers, in a true handshake protocol, and is available as a Dev Kit: http://www.ti.com/tool/cc85xxdk-headset .  The four receiver pairings is limited by the architecture and internal firmware of the CC85xx.

  But for an unlimited number of receivers, the CC25xx acts as a radio broadcaster, simply transmitting at a specifc carrier frequency.  The ‘channel’ I was referring to is the specific frequency within the TX spectrum of the transmitter, as an offset from the 2.4GHz center frequency, not a TX to RX pairing as a separate channel, as there is not sufficient bandwidth to switch the audio stream between different TX channels and maintain any kind of audio quality.  Therefore the CC25xx broadcasts and has no awareness of the number of receivers ‘listening’, similar to a standard AM or FM radio station.  If you want a hadshake/join with the receiver, then your protocol will have to be implemented to do this.

 Here is one Ref Design for this purpose, which can be used with CC1110 (sub-1GHz) or CC2510 (2.4GHz): http://focus.ti.com/analog/docs/litabsmultiplefilelist.tsp?literatureNumber=swra295a&docCategoryId=1&familyId=936 .  You will probably want to implement audio compression on the TX side, and the CC2510/CC2511 has an audio link Design Note: http://www.ti.com/litv/pdf/swra138 .  The CC251x has an ADC, a DAC and i2S interface, controlled by the 8051 portion of the CC251x.   And if you are doing USB audio, an App Note on i2S: http://www.ti.com/litv/pdf/swra183 .   And note that the RFUSB Libraries support USB Audio.  Reference the files on the CC2510DK webpage: http://focus.ti.com/docs/toolsw/folders/print/cc2510-cc2511dk.html .

  I know there is a lot of information here, and I think going forward, after you’ve read through this, it would be helpful to get a block diagram and design requirement for us to review.  These can go through Calum to keep any proprietary information secure, or if you are okay with posting that information here on E2E, please do so.

  Hope this has been helpful,

-Leonard

Good morning Leonard,

Thank you so much for your reply. I would like to clarify the architecture, however, due to the proprietary nature of the project I can't do it as a post. Is there a phone number I could call you at? Please feel free to send me an email to mehrdad@systems-io.com . I will be reviewing the information you have included in your post in the meantime. With much thanks,

Mehrdad