Inside GNSS Media & Research

NOV-DEC 2017

Issue link: https://insidegnss.epubxp.com/i/906409

Contents of this Issue

Navigation

Page 52 of 67

www.insidegnss.com N O V E M B E R / D E C E M B E R 2 0 1 7 Inside GNSS 53 topologies a, c, d, and e of Figure 3. Figure 3.g illustrates spatial splitting of files. Here, the binary data lanes from two or more DCSs are written to sepa- rate files. ese files may be written by different computer systems. In this case, a non-zero inter-system timing offset, Δt, may exist and must be supported in the standard. Since Δt may or may not be known at time of collection, it rep- resents an example metadata parameter that may be back-annotated into the metadata file aer an initial pass of SDR data processing. Multi-lane DCSs that write each lane to a separate file may also implement temporal file splitting according to 3.f. We call this "spatial-temporal splitting", and is illustrated in Figure 3.h. Since multi-stream-multi-file data collection topologies (i.e., (g) and (h) in Figure 3) produce multiple data files applicable to a given time interval, the SDR processor must be "introduced" to the full or partial set of lanes associated with the topology. is is covered by lane selection parameters in the standard. Metadata Parameters e metadata standard enables a user to specify a wide range of properties of the binary data file. Some of these proper- ties relate to the data collection scenario itself, such as the time and location, and the type of scenario. Other properties of the dataset relate to the particular RF data that is captured as IF samples, including center frequency and band- width. Yet other details such as the IF digitization conf iguration and data packing can be specified. These are briefly summarized below. Some of the parameters are free-form text, others are integer or floating point variables, and others are enumerations. e primary classes are shown in Figure 4 . The metadata "session" class holds details such as the time, the position, the measurement campaign, and the type of scenario. e "file" class contains a path to the corresponding binary data file, time-stamp info, and a reference to the contained "lane" (described below). A "system" class contains details of the data recording equipment, such as the equipment name, the reference clock frequency, and the antenna details/ specifications. e metadata standard allows for the specification of a variety of RF bands, each "band" class includes details of the band's center frequency, intermediate frequency, bandwidth and group-delay bias. e actual format of the binary data is detailed in the "lane" class, which allows for the specification of a hierarchy of binary data packing patterns, entitled "blocks", "chunks" and "lumps". ese classes specify the arrangement of the packed IF data and optional additional data such as sensor measurements or configuration information, and further specify the arrangement of data relative to the standard word-sizes (arrays of byte, short integers, integers, long inte- gers, etc.). e arrangement of the raw IF samples within these blocks is specified by the "stream" class. is class speci- fies the associated RF band, the sample rate, the quantization, the sample for- mat (real/complex), the encoding of the binary data and the arrangement/align- ment of the samples. Together these classes contain sufficient information to unambiguously interpret the packed binary data. Normative Reference Software e primary responsibilities of the Nor- mative Reference Implementation Sub- committee are to reduce to practice the conceptual design developed through consensus by the WG into an appropri- ate set of schema (according to industry best practices) and to develop a compli- ant software library implementation. The WG was fortunate to receive vol- untary participation for this task from individuals representing established commercial GNSS SDR vendors. e WG decided to work on a pub- licly available reference soware library to be released with the standard. The goal of this effort is to promote early and widespread adoption of the standard by making it easy for vendors and research- ers to integrate standard-compliance by integrating the library into their existing soware. e scope of this effort is two- fold, to develop a metadata interpreter, and to develop a binary data converter using this metadata interpreter. e first contribution was a library that would produce standard-compliant metadata files from an appropriately- popu lated data structure, a librar y capable of reading the content of such files back to a data structure. e second contribution was in the form of a library capable of parsing and converting binary IF data based on an associated meta- data description. When combined, it is hoped that these two libraries offer suf- ficient functionality to enable adoption of the metadata standard in SDRs, or to serve as a benchmark against which implementations of the standard can be validated. FIGURE 4 Standardized Metadata Exchange f RF,0 f RF,1 f RF,N Bands at RF f 0 SDR Files Metadata SDR Data Collection System Core Metadata Classes System Band Stream Lump Chunk Lane File Session FileSet Block Source Cluster

Articles in this issue

Links on this page

view archives of Inside GNSS Media & Research - NOV-DEC 2017