The sequence of a scan/probe (which exchanges exactly one request and
response pair) before an acquisition (which requests another response,
then keeps re-requesting periodically) resulted in the transmission of
more requests shortly after a request was sent and before any response
started receiving at all. Which then resulted in unexpected lengths and
failed consistency checks for the receive data. This condition stuck
because rdtech-tc does not support the re-synchronization to the input
stream as rdtech-um does.
Defer transmission of requests until after receive data was seen (or
an acquisition start forces their transmission). Tested by repeatedly
running: