Transferring data from a data acquisition unit can be done in different ways to match the kind of data that you are acquiring in order to maximize bandwidth. In this video, David Buckley talks about how data can be packaged to suit different data sources.
Video Transcript
Hello, my name is David Buckley. Today, I’m going to talk about data transfer out of a data acquisition unit (DAU). Similar to data sources, there are two types of data transfers that will come out of your DAU. There is synchronous which is a pre-configured transfer that repeats periodically similar to IRIG 106 ch.4 PCM. Your bandwidth is divided into maybe major frames and minor frames and that bandwidth is filled with a particular set of parameters and repeats periodically over and over again.
The other type of data transfer is asynchronous and this kind of transfer only happens occasionally – you only send the data when you gather it – you don’t repeat the same pattern over and over again. When you receive a certain amount of data, you will send it.
If we focus on the synchronous data transfers first and take IRIG 106 ch.4 as an example, a minor frame will very often include a timestamp which allows you to tell when each one of the parameters in the minor frame was sampled. The first parameter in the frame – let’s call it parameter 1, sample 1 (P1S1) – is eventually repeated, let’s call it parameter 1, sample 2 (P1S2). The timestamp refers to the time of P1S1 and it will be possible to extrapolate the timestamp of P1S2 based on the timestamp of P1S1 and the sample rate of the parameter.
This works very nicely if you have a synchronous source of data. If we take an example that the start of a minor frame will happen a little after the generation of P1S1 and then at nice equal periods thereafter, so the data can be placed in the correct location in the minor frame without any problems.
However, if you have an asynchronous source of data, you may find that your data comes in at unusual times, either too close together between sample rates or too far apart. So, you can never be sure when exactly your sample occurred and if two samples of data are really just the same event sampled twice, for example. In other words, you can get glitches in the data and unusual behavior being sent from your DAU.
You can account for this by applying a timestamp to each sample of data, so you know exactly when it occurred and a flag to tell you if something happened between samples. So, you can attach enough metadata down your PCM link to tell you exactly when each of the asynchronous samples occurred. But this adds considerable data overhead – for a 16-bit parameter, you may need to send multiple words and this is very inefficient in an application where telemetry bandwidth is limited.
The other option is to wait and gather up several asynchronous parameters together, timestamp each one and send it down in an asynchronous packet. This kind of packet works very well in the Ethernet world, as this is how the Ethernet protocol works. It doesn’t work quite as well in the IRIG 106 world.
What you find in modern flight test data acquisition is that a lot of parameters that are sent to recorders i.e. ones that don’t have to go via a telemetry link will use asynchronous Ethernet packets to maximize the bandwidth. By mixing different approaches to sending synchronous and asynchronous data from your DAU, you can maximize the available telemetry bandwidth.