• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 708 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

200mS interval audio transmission drop outs

Gary Attwood
Prodigy 90 points
Other Parts Discussed in Thread: PUREPATH-WL-CMD

Hi.

I'm continuing my evaluation on the CC8531 using the CC85XXDK eval kit.

At the present time I'm testing for transmission drop outs. I have the slave board 35' from the master and experience a consistent 200mS drop out a few times per hour. (My method is transmitting a constant 1Khz sine wave and scope capturing the drop out duration).

I've moved the test set to different environments to rule out a strong interfering signal.

I'm curious and blame the Purepath system because the drop outs are consistently a 200mS duration.

I also can't believe that TI would have acquired this technology with this issue, and think that it must be a configuration issue.

Any ideas?

Gary.

  • 0
    TI__Mastermind 21125 points

    Hi Gary, 

    What you are experiencing is a audio drop-out. These will occur when there has been a audio packet lost and this can occur due to interference or due to multi-path fading issues.

    From the User Guide:
    2.3.3.5 Handling of Drop-Outs
    If the wireless link fails to transfer any even PCM16/PCME24 slices, any PCMLF slices or any SLAC slices,all output audio channels on the failing receiver node will be muted. The channels stay muted until the quality of service again is found acceptable (i.e. there have been no missing audio slices for a certain period of time, typically 2-300ms depending on sample rate). The muting and un-muting operations are done in a soft manner over valid audio samples in order to avoid abrupt transitions. It is, however, possible to disable the soft fade-out for improved audio streaming robustness corresponding to a 64 samples audio latency increase.

    There are things that can be done to improve the audio link performance, but usually associated with a 'cost':

    • Always keep the number of slaves to the lowest possible for a given application. In a multi-cast protocol, time is set aside for each possible slave for potential re-transmissions. If only 1 slave is needed, robustness will hurt if you enable more slaves to join the master
    • The lower sample rate the allows more re-tranmissions attempts for the same latency and thus is more robust to drop-outs
    • Latency is a direct trade-off vs. robustness. One are directly trading retransmission attempts for the lower latency. At the lowest settings this goes towards zero retransmission attempts
    • Number of audio channel supported. the more channels supported, the more bandwidth is needed over the air and the less robust the link will be. 
    • Direction of audio. Typically audio from master to slave is better when having uni-directional audio. For bi-directional links they are equally robust., 
    • The various streaming formats requires different band-width. SLAC is more robust than PCM16 format.
    • Target output power and CC2590 range extender. Improves range at the cost of power.
    • Audio fading can be disabled (under advanced settings) for slightly better re-transmission capabilities.
    • RF data-rate. 2 Mbit settings is less vulnerable to RF multi-paths and improves sensitivity. This will have a positive affect on range. 
    • Antenna diversity: If implemented on slaves, it will combat multi-path effects and improve the in-range performance.

    Hope this helps.
    Regards,
    Kjetil 

     

  • 0 in reply to Kjetil
    Prodigy 90 points

    Kjetil:

    Thank you very much for your reply. I will read up on the variables mentioned above and evaluate some configuration files. I'll let you know the field test results.

    Best regards,

    Gary.

  • 0 in reply to Gary Attwood
    Prodigy 250 points

    Hi Gary,

    In situations like this it is advisable to diagnose the problem.

    I have found it helpful to use PurePath Wireless Commander for this: http://www.ti.com/tool/purepath-wl-cmd

    Install the program, attach your CCDebugger and use 'Command and Monitoring' section to send PS_AUDIO_STATS and PS_RADIO_STATS to your receiver (possible for every PurePath chip configuration: autonomous, host controlled).

    I hope it helps!

    Mikelis