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.

CC8530: multiple master reception from same slave pool

Part Number: CC8530

Yes, I have searched the forums and seen the posts related to this issue.

However, I am asking a question that seems unique from those.  I want several (e.g. 4) audio producer channels (slaves) to provide input to several different masters.  For example, multiple mic slaves providing the same input to several loudspeakers (masters).  NOT 4 channels to one master and 4 to another to give 8 channels to one base station possessing two master chips, BUT RATHER 4 channels simultaneously to multiple listening base stations each with one master chip.

I want to  know if I can pull this off with CC85XX technology.  It should be doable in concept.  I can see that I would need some time-slot assignment for multiple master Tx.  I don't need that - one "Master among masters" could handle all I'd need for Tx to slaves - but I want the second-tier masters to have simultaneous access to the audio content (Rx) for rendering.  I don't want to have to set up a whole other system to re-transmit from a "master speaker" to the others.  I theory, reception by one master can't prevent the other masters from hearing the same signal, right?  it's the timing that concerns me.

Also, I'm trying to avoid duplicate (or more) Tx chips in each slave source.  First, space in a mic is at premium.  Also, I'd like to have an arbitrary number of (in range) listening masters without and extra chip set inside each mic to service.  Again, only one master ever needs to Tx to mic(s) - and I don't think I even need that unless it's part of the error check protocol.

Thanks for input,

-Rick

  • Hi Rick,

    Unfortunately what you are asking for is not supported by the CC85xx devices. They only support point to point communication. Not point to multipoint.

    Cheers,
    Fredrik
  • I realized I had a follow up...

    I haven't yet delved into the demo modules' details, but it seems that the fact that point-to-multipoint CANNOT be implemented must imply that (for e.g.) in the "PurePath" link between mic (slaves) and a base station receiver (master) the communication is two-way? Now I realize this is meant to be possible - as a feature - but is it necessary? If my master could be made to ONLY receive, then it seems like more than one master could "listen in" on the conversation.

    Can anyone verify that some degree of two-communication is REQUIRED to establish any/every PurePath link?

    -Rick
  • Hi Rick,

    2-way communication between master and slave is possible, but not mandatory. It would still not allow you to transmit to multiple masters though.

    Cheers,
    Fredrik
  • Wow... now I am really confused!  As a noob to this area, can you give any (non-proprietary) reasons why?  Just for my education. 

    I mean, if one Master receives the air-borne information, and under the protocol does not have to sign back with some sort of ACK to the transmitting slave(s), then how couldn't another chip configured identically as "the" Master also receive the same radio waves?  Unless, of course, the 2nd (or, 1st + nth) Master has simply been hardwired not to process data from a network already possessing a Master.  But that just seems like an unnecessary (although I suppose irreversible) hobbling of an otherwise more flexible system.  I'm not sure how one Master could even be aware of the other(s) if they don't transmit.  Unless... the Master has some ID info that must be included in the data stream intended for it - and it alone.  Feel free to comment on my stream-of-consciousness here. :)

    What do you suppose would happen if two identically programmed Masters were placed in range of a slave?

    Thanks!  I appreciate any input as I am still learning.

    -Rick

  • Hi Rick,

    Even though the communication is one-way the packets are still ACK'ed. A master and slave device must always form a connection.

    Cheers,
    Fredrik