AEDAT File Formats

Introduction

Files generated by iniVation event-based processing software, such as DV and jAER, use the custom AEDAT (=Address Event DATa) format to store the event data and its timestamp information. Over the years, this format has evolved to address various needs, such as storing new data types more efficiently or having larger timestamp ranges.

AEDAT 4.0 is the most recent data format provided by the DV (Dynamic Vision) framework since June 2019.
AEDAT 3.1 was specified as an update to the AEDAT 3.0 format in April 2016, addressing a couple of shortcomings.
AEDAT 3.0 came out of research done with the cAER framework in 2015.
AEDAT 2.0 of the format is the most commonly found, as it was supported by jAER and used as default since 2010.
AEDAT 1.0 has been supported since the first jAER release in 2008.

Software Support

The following table summarizes what software supports which formats:

Software	AEDAT 4.0	AEDAT 4.0	AEDAT 3.1	AEDAT 3.1	AEDAT 3.0	AEDAT 3.0	AEDAT 2.0	AEDAT 2.0	AEDAT 1.0	AEDAT 1.0
	Read	Write	Read	Write	Read	Write	Read	Write	Read	Write
DV			*	*	*	*	*	*	*	*
dv-processing
jAER			(RAW format)		(RAW format)

= Conversion from earlier Aedat data formats to Aedat4 is available via DV

Common Version Header

AEDAT files have a common, human-readable header format.

A header was initially optional, but with the introduction of new format revisions, it is now considered required, else it’s impossible to parse the file correctly.

If it exists, it is the first content present in a file, and is made up of one or more header lines.

A header line begins with a ‘#’ character and ends with a CRLF (Windows line ending, ‘\r\n’).

Header lines, unless specified otherwise, are always case sensitive.

The very first header line contains information about the version of the AEDAT format employed in the rest of the file. If it is not present, version 1.0 is assumed.

The exact format of the version line is as follows:

#!AER-DATx.y\r\n

where x and y are the two version number components.

Other than the first version header line, no other header lines are required or specified in a common way across all format versions and depend completely upon the software generating them. They should only be used for informative uses and not to store critical data or metadata unless explicitly specified as such below in one of the format versions.

Formats

Network Streaming

Streaming data over the network, instead of to a file, is done with exactly the same data formats.

The only difference is that with streaming, no headers as defined above are sent, meaning receivers need software switches to understand what they are receiving and how to interpret it. In jAER, for versions 1.0 and 2.0, those can be found in the network streaming dialogues, as well as by selecting the appropriate AEChip class manually for data parsing.

Version 3.X, on the other hand, attempts to automate this by sending a 20 bytes network header that signals the presence of version 3.X data with a magic number at the start.

For stream based protocols, like TCP, this header will be sent once at the start of the stream.

For message-based network communication, for example UDP, this header will be part of each message, at the front, to ensure it can be properly parsed always.

All header fields/integers are little-endian.

The 20 bytes network header format is the following:

Bytes	Meaning	Description
0-7	64bit AEDAT 3.X magic number	Magic number signalling presence of AEDAT 3.X header and data: 0x1D378BC90B9A6658.
8-15	Sequence Number	Increasing 64 bit integer to detect missing message parts. Not used for stream protocols (TCP), set to zero.
16	Version Number	The AEDAT 3.X version number part. 0x00 for AEDAT 3.0, 0x01 for AEDAT 3.1.
17	Format Number	The numerical ID representing the used format.
18-19	Source ID	Source ID for all the events of this network stream. One network stream always carries data from only one Source ID on the sender system.

Supported Devices

The following is a list of all supported input devices and their names (as would be written in AEDAT 3.1 Source ID header lines):

Device Name	Historical Alternative Names
File
Network
DVS128	Tmpdiff128
DAVIS240A	SBret10
DAVIS240B	SBret20
DAVIS240C	SBret21, DVS240
DAVIS128	Davis128Mono, Davis128Rgb
DAVIS208	Davis208Mono, Davis208Rgbw, PixelParade, SenseDavis192, SensDavis192
DAVIS346A	Davis346AMono, Davis346ARgb
DAVIS346B	Davis346BMono, Davis346BRgb, Davis346
DAVIS346Cbsi	Davis346bsi
DAVIS640	Davis640Mono, Davis640Rgb
DAVISHet640	DavisHet640Mono, DavisHet640Rgbw, CDavis, CDavis640, Davis640Rgbw, CDavis640Rgbw
DYNAPSE	Dynap-se, DYNAPSEFX2
DVXplorer	DVXplorer Lite

These Historical Alternative Names are names which devices may have been called in the past (not including different capitalisations), these are not to be used for Source ID headers, they are only here as a reference!