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.

Using CC85xx in a multiroom audio system with more than 4 receivers

I am designing a Multiroom Audio System and I need one transmitter with eight receivers. I know that CC85xx only supports 4 receivers. So, the first question is that Is there any solution for that?

A non-perfect solution that I thought it may work, was using 2 CC85xx chips as the transmitter. If I want to put both transmitters in a single board their distance need to be around 10cm. Accordingly, I performed an experiment with 2 transmitters where the distance between them was 10 cm. Each transmitter transmit audio to two receivers. This plan did not work as I has interference and the transmission range reduction was significant.

I even tried to put the transmitters on different channels as it is possible through the PurePath software. So, out of 18 available channels, I allocated the first 8 channels to TX1, then 2 channels free, and the next 8 channels for TX2. It did not help as I had again the range reduction.

In another test, I put the transmitters in a one meter distance and it solved lots of problems.

Any solution or suggestion for my problem?

  • Hi Ali, 

    Only real solution to your 'problem' is, like you have figured out, to add more CC85xx masters in the transmitter unit. What you experience with the close range issues is most likely saturation issues (one radio in Tx and the other in Rx). We quite recently introduced what we call timeslot alignment to cope with this issue. This is where masters can be daisy chained to sync up their Tx and Rx periods. Please see the user guide (search for timeslot alignment) or PurePath Wireless configurator under 'Advanced Options'.

    From the Configurators help system:

    Timeslot alignment

    When using multiple PurePath Wireless protocol masters in a base station to increase number of audio channels and/or protocol slaves supported, the difference in crystal frequency will cause the timeslot timings to drift. This causes periodically variable robustness, since at certain points in time one protocol master will perform RX while another performs TX. Even though these protocol masters do not operate at the same channel at that time, it will always have a negative impact on RF performance (ranging from short audio drop-outs to network drop-outs that last for several seconds).

    The issue can be prevented by using timeslot alignment, where wire-based synchronization (using one GIO pin per device) ensures that all (non-USB) protocol masters perform TX simultaneously and RX simultaneously. This results in stable performance and allows protocol master antennas to be located closely. Protocol masters without any network connections will randomly, at short interval, listen for other protocol masters to avoid permanent collision (since identical TX timing makes regular listen-before-talk ineffective, and two protocol masters could potentially start with the same set of active RF channels).

    One of the protocol masters functions timing master (i.e. outputs the synchronization signal), while the other protocol masters function as timing slaves (i.e. captures the synchronization signal). It does not matter which protocol master is timing master, but it is recommended to enable the timing master before or simultaneously with the timing slaves, since the initial timing adjustment normally causes network drop-out on the timing slaves. If the timing master is disabled, the timing slaves are free-running and the mechanism is ineffective.

    To be able to use timeslot alignment, the protocol masters' device configurations must be identical for all settings that affect timeslot timing:

    • Device Configuation: Network role, application role and operation.
    • Audio Streaming: Streaming format, supported sample rates and latency.
    • Radio: Maximum slave count.
    • Advanced Options: Fade out when muting, RF data rate, protocol version, timeslot period.
    If you wonder if the timeslots are aligned properly you can scope xPAEN (Radio in Tx) and xLNAEN (Radio in Rx) on the two masters with and without alignment. Without you should see that one masters Tx will drift into the others Rx and thus breaking the link. When align all edges on both masters should be in sync.
    Let me know if this solves your issue.
    Best regards,
    Kjetil 
  • Kjetil,

    Thanks for your quick response. It seems working good now. 

    One more question:

    With the simple setup that I had (two synced transmitters, namely TX1, TX2), I could not see any difference in performance of the following setups:

    1. TX1 limited to 9 channels (1 to 9); and TX2 limited to the other 9 channels (9 to 18)

    2. TX1 and TX2 are allowed to operate on all channels.

    Which configuration do you recommend? What are the pros/cons of each config?

    Please consider the following conditions:

     - around 10 in range wifi networks.

     - other PurePath networks around (worst case scenario is a building with 100 units where each unit has a pair of transmitters)

    Ali

  • Hi Ali, 

    Unless the you have the chance to do any active frequency planning (know the exact interference situation in the 2.4 GHz band) then I will always recommend using all 18 channels for both TX1 and TX2.  Our adaptive frequency hopping protocol is written so that it can detect interference from other PPW networks and this is why you see little to no difference. If you split the band between the two, then you are more vulnerable in the presence of a strong wide band interferer like WiFi. 

    Also, for you set-up I would recommend the longest possible latency in the system. This allows for more re-transmissions while keeping the audio drop-out free in heavy interference condition.

    I would also recommend testing this set-up in a realistic environment. Signal-to-noise (distance) between WiFi and the different PPW networks will influence the performance.

    Regards,
    Kjetil