Audio Fallback

The Audio Fallback Module allows applications to dynamically reduce the audio packet size to increase output power settings in response to a degrading link. Without fallback, if the link degrades beyond a certain point, audio packets will be lost. With fallback enabled, we can avoid dropping packets by dynamically enabling a processing stage which reduces the packet size. With smaller packets, higher transmit power settings can be used. Therefore, the effective range of the system is increased, at the cost of a lower quality audio stream. Smaller packets also reduce airtime and that could allow an application to increase the amount of CCA retries, resulting in more packets getting through.

If an application desires to force a certain fallback state (e.g. The user requires high reliability through an app.), it can do so using the sac_fallback_set_manual_mode function to disable the automatic mode switching. The fallback mode can be selected using the sac_fallback_set_fallback_flag or the sac_fallback_clear_fallback_flag functions.

The table below shows an example of a configuration for an arbitrary stereo audio application:

Table 38: Example Alternate Link Settings Used by Fallback Mode

Parameter

Level 1, Uncompressed

Level 2, Compressed

Payload size

64

22

Pulse Count

1

2

Pulse Width

7

4

Pulse Gain

0

0

CCA Try Count

2

3

The RF power transmitted by a SPARK UWB radio is determined by three settings: Pulse Count, Pulse Width and Pulse Gain (which is really an attenuation control). The table shows how the power settings and CCA Try Count are influenced by payload size. In normal mode, the settings for uncompressed data are used, whereas in fallback mode, the settings for compressed data are used.

A payload size of 64 bytes requires that the power settings be set to (1, 7, 0) and the airtime allows for 2 CCA retries.

A reduced payload size of 22 bytes allows us to increase the power settings to (2, 4, 0) and allows for 3 CCA reties due to shorter airtime. The link will benefit from higher range with the increased power settings.

The Wireless Core will automatically switch between the 2 setting configurations based on the payload size received from the Audio Core.

Fallback ON Trigger

Fallback ON is triggered by a rise in the transmitter’s TX queue load or a rise of the number of CCA retry count.

A normal TX queue load is either 0 or 1. When the queue level increases to 2, it indicates that the queue is accumulating packets. This happens when the link is weakening and retransmissions are occurring, slowing down the normal flow. The sampled TX queue load is stored in a circular array and averaged. The array size is set to 3 by default. The load values are multiplied by a factor of 10, so that a finer average can be determined over the averaging period.

The detection of link quality at the transmitter is determined as follows:

  • TX queue load values are multiplied by 10.

  • A rolling average of the last 3 sampled TX queue loads is calculated every time the array is updated.

  • If the rolling average becomes greater than a predetermined threshold, then Fallback ON is triggered.

At startup, the processor must wait for the sampling array to fill before performing the link quality algorithm.

The following table shows an example of link quality evaluation for a Trigger Threshold set to 13.

Table 39: Example TX Queue Load Threshold for Fallback ON Trigger

TX Queue Loads

Running Average

Threshold

Fallback State

(10, 0, 20)

10

13

OFF

(10, 20, 10)

13.3

13

ON

A threshold value of 13 works well for unidirectional links where the timeslots are contiguous. In bidirectional links where there is a time gap between transmissions, a value of 23 could be used. The final value can be fine-tuned on a per-application basis.

The CCA retry count is also averaged and can be used to trigger the fallback mode when it is over a configurable threshold for a continuous period. The period required can be configured using the cca_bad_time_sec parameter. The threshold is a percentage of the maximum number of retries configured using the cca_try_count_threshold_perc parameter.

The system should be pessimistic at start up to optimize the chances of successful communication when the system is brought up in a poor link environment. As such, fallback state should initially be ON until the Fallback OFF state is triggered.

Fallback OFF Trigger

Fallback OFF trigger is based on 2 metrics: the receiver’s Link Margin and the transmitter’s CCA retries.

Link margin values and CCA retry counts are obtained from the Wireless Core using the swc_connection_get_fallback_info() function, which returns the following:

typedef struct swc_fallback_info {
    /*! Link margin value. */
    uint8_t link_margin;
    /*! CCA fail count value. */
    uint32_t cca_fail_count;
    /*! Number of times all CCA attempts failed. */
    uint32_t cca_tx_fail_count;
    /*! Total number of tx dropped packets. */
    uint32_t tx_pkt_dropped;
    /*! Total number of CCA events. */
    uint32_t cca_event_count;
} swc_fallback_info_t;

typedef struct swc_fallback_info {
    /*! Link margin value. */
    uint8_t link_margin;
    /*! CCA fail count value. */
    uint32_t cca_fail_count;
    /*! Number of times all CCA attempts failed. */
    uint32_t cca_tx_fail_count;
    /*! Total number of tx dropped packets. */
    uint32_t tx_pkt_dropped;
    /*! Total number of CCA events. */
    uint32_t cca_event_count;
} swc_fallback_info_t;

The receiver device must return its link margin value to the transmitter device using the auto-reply mechanism. Although this value is stored as a 16-bit variable, it can be sent using only 1 unsigned byte if the programmer makes sure to saturate the link margin at 255. The link margin threshold used to turn OFF fallback is much lower than 255.

The link margin values are averaged and must be above a predefined threshold for a continuous period to consider it good. The period required can be configured.

The CCA retry count is also averaged and must be below a configurable threshold for a continuous period to be considered good. The period required can be configured using the cca_good_time_sec parameter. The threshold is a percentage of the maximum number of retries configured using the cca_try_count_threshold_perc parameter.

When both the link margin status and CCA have passed the period criteria, indicating good wireless conditions, the Fallback OFF trigger is activated.

Audio Processing Gate Functions

Processing stage gate functions are used in both the Coordinator and Node devices. The Coordinator will use sac_fallback_gate_is_fallback_on and sac_fallback_gate_is_fallback_off gate functions that will return the fallback module state and also update the flag in the audio header to indicate when the packet is in fallback mode. The node will use sac_fallback_gate_fallback_on_detect and sac_fallback_gate_fallback_off_detect functions that will return the fallback state of the flag in the audio header of the received packet and also update the fallback module state. The on and off variants of the gates are to be used with mutually exclusive processing stages based on the fallback state.

Example 1: An application using audio compression as a fallback mechanism.

In this example, the Coordinator would have two processing stages, each having their own gate function. The first processing stage performs audio compression when fallback mode is ON using the sac_fallback_gate_is_fallback_on gate. The second processing stage performs audio compression only on the last sample when fallback mode is OFF using the sac_fallback_gate_is_fallback_off gate. This implementation is used to keep the compression algorithm state up to date. This ensures a seamless switch between compressed and uncompressed modes.

In the Node, the gate function sac_fallback_gate_fallback_on_detect for the decompression processing stage ensures that only packets that have been compressed will be decompressed.

Example 2: A 48 kHz 24 bits application using audio packing to 16 bits as a fallback mechanism.

In this example, the Coordinator would have two processing stages, each having their own gate function. The first processing stage performs audio packing from 32 bits aligned audio to 16 bits aligned audio when fallback mode is ON using the sac_fallback_gate_is_fallback_on gate. The second processing stage performs audio packing from 32 bits aligned audio to 24 bits aligned audio when fallback mode is OFF using the sac_fallback_gate_is_fallback_off gate.

In the Node, there would also be two processing stages, each having their own gate function. The first processing stage performs audio unpacking from 16 bits aligned audio to 32 bits aligned audio when fallback mode is ON using the sac_fallback_gate_fallback_on_detect gate. The second processing stage performs audio unpacking from 24 bits aligned audio to 32 bits aligned audio when fallback mode is OFF using the sac_fallback_gate_fallback_off_detect gate.