Videos

Transferring Data from Data Acquisition Units (DAU)

August 23, 2016 | BY: David Buckley

Loading...

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 maximise bandwidth. In this video, David Buckley talks about how data can be packaged to suit different data sources.


Video Transcript for the hearing and visually impaired

Hello, my name is David Buckley and 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 there after 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 behaviour 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 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 but 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 maximise the bandwidth. By mixing different approaches to sending synchronous and asynchronous data from your DAU, you can maximize the available telemetry bandwidth.

Author’s Biography

David Buckley

Chief Architect, Engineering

Dave Buckley is Chief Architect at Curtiss-Wright. He received his B.Sc. in Electrical and Electronic Engineering from University College Cork in 1996. Mr Buckley has extensive experience in ASIC, FPGA, hardware and system level design and architecture for a variety of different industries and applications. Since joining Curtiss-Wright in 2009 he has held several positions including Senior Hardware Designer and Principal Hardware Architect. In his current role he is responsible for managing the product roadmap and guiding the technical direction of flight test instrumentation product lines.

Share This Article

  • Share on Linkedin
  • Share on Twitter
  • Share on Facebook
  • Share on Google+
Connect With Curtiss-Wright Connect With Curtiss-Wright Connect With Curtiss-Wright
Sales

CONTACT SALES

Contact our sales team today to learn more about our products and services.

YOUR LOCATION

PRODUCT INFORMATION

Support

GET SUPPORT

Our support team can help answer your questions - contact us today.

REQUEST TYPE

SELECT BY

SELECT Topic