Is the purpose of the FLUSH state to push data through the AD9361 at the end of the receive or transmit subframes? How long does it take?
The FLUSH state is meant to guard against glitches that could occur as a device (either baseband processor or AD9361) transitions it's I/O from one state (e.g. input) to another (e.g. output).
Using a transmit (Tx) subframe as an example, before a Tx subframe starts, any data sent by the baseband processor (BBP) is zeros. During the subframe, valid data is sent by the baseband processor to the AD9361. After the last valid data sample, the BBP sends zeros. Knowing the latency from baseband to antenna, the BBP would have put the last valid data bit for a particular subframe on the bus before the end of the Tx subframe. After the last data bit, the BBP holds the system still in the Tx state because the end of the subframe has not occurred. When it does occur, the BBP moves the ENSM to the Alert state. When the next Tx subframe starts, the filters would be filled by zeros so the next subframe of Tx data/signals flowing through the transceiver is valid.
The flushing function automatically occurs when the AD9361 moves from an active state such as Tx, Rx, or FDD to the Alert State. It is not meant to funnel valid data through the filters. If the I/O port glitches at the end of a Tx subframe when the I/O buses are turning around, bad data would get "stuck" in the FIR filters after the ENSM is told to leave the Tx state. The flushing function is meant to clear out this bad data. For that reason, the flushing function moves data out of the FIR at a very high rate, knowing that the data should not be propagated to the Tx output port. The process always takes 384 ADC clock cycles, both for Rx and for Tx flush.
Retrieving data ...