(Preprint) AAS 15-776

OBTAINING NAVIGATION OBSERVABLES FROM HIGHDEFINITION TELEVISION TOWERS

Ryan E. Handzo∗, Austin Anderson†, Jorge Cervantes‡, Jeffrey S. Parker§, DirkGrunwald¶, and George H. Born‖,

This paper considers the navigation observables that can beobtained from HDTV signalsusing the ATSC transmission standard. The ATSC transmission standard has multiple com-ponents that allow for range and Doppler navigation observables to be extracted. This paperlooks at the structure of these observables as well as the types of hardware that are neededto obtain these observations. In addition, the paper will present a comparison between sim-ulated signal data used in satellite navigation studies andreal data collected using hardwareon the ground.

INTRODUCTION

High Definition Television (HDTV) transmission towers around the world broadcast signals at very highpower: Australian towers broadcast up to 1.25 MW of effective radiated power (ERP); US and Europeantowers broadcast upwards of 1 MW ERP; and towers are known to broadcast in all parts of the world, exceptAntartica. These power levels make HDTV signals very promising navigation beacons for satellites in orbit.The high power levels of the signals alone however, are not enough the make these signals effective, or evenpromising navigation beacons. The signals must also contain features that an on-board computer can bothdetect and extract from the signal, in order to generate navigation observables for the satellite’s navigationfilters to use. HDTV signals contain both the necessary signal qualities and high broadcast ERP from thetransmission towers to be viable for use as a source of navigation observables. This paper considers the nav-igation observables that can be obtained from HDTV signals,specifically signals broadcast using the ATSCtransmission standard, and then describes the various digital signal processing (DSP) techniques and methodsneeded to extract these observables from the received signals. The signal structure, reception, processing, andtiming information that can be extracted from the signal arestudied along with the processing power requiredby a CPU to perform these operations.

DESCRIPTION OF HDTV SIGNALS

There are several difference encoding schemes used throughout the world for HDTV broadcasting. Thedifferent standards used by countries around the world are the ATSC,1 DVB-T,2 ISDB-T,3 and DTMB; Fig-ure1 shows where each of these standards are used throughout the world. For this paper the ATSC standard

∗Graduate Research Assistant, Colorado Center for Astrodynamics Research, University of Colorado - Boulder, 431 UCB, Boulder, CO80309

†Graduate Research Assistant, Research & Engineering Center for Unmanned Vehicles, University of Colorado - Boulder, 431 UCB,Boulder, CO 80309

‡Undergraduate Research Assistant, Colorado Center for Astrodynamics Research, University of Colorado - Boulder, 431UCB, Boulder,CO 80309

§Assistant Professor, Colorado Center for Astrodynamics Research, University of Colorado - Boulder, 431 UCB, Boulder,CO 80309¶Associate Professor, Department of Computer Science, University of Colorado - Boulder, 431 UCB, Boulder, CO 80309‖Director Emeritus, Colorado Center for Astrodynamics Research, University of Colorado - Boulder, 431 UCB, Boulder, CO80309

1

will be the focus due to that signals’ use in North America. While the ATSC standard is the focus of this pa-per, the DVB-T and other standards also contain many useful structure components for extracting navigationinformation. One example of this is the orthogonal frequency-division multiplexing modulation scheme usedby the DVB-T standard which helps to separate signals and pull timing information out of the signal. The useof these other standards for obtaining navigation information will be covered in later papers.

Figure 1. HDTV Signal Structures Around the World

ATSC Signals

All ATSC signals are transmitted using the same guidelines regulating the signal. These regulations beginwith all ATSC HDTV signals being transmitted using a 27 MHz clock that is then used to generate a symbolrate offs = 10.762237 MHz. This symbol rate is the frequency at which the ATSC frames are transmitted;these frames are what are going to be tracked in order to obtain tracking information. The ATSC frameconsists of 626 data segments, each of which comprises 832 symbols. The frame is then further divided into2 data fields composed of 313 data segments each, with a field synchronization segment at the beginning ofthe data field.4 The ATSC frame and data field structures can be seen in Figure2 and Figure3 respectively.

The ATSC standard uses amplitude shift key (ASK) and 8-ary vestigial sideband modulation (VSB) whichhas symbols of 3 bits of data encoded onto it. The first segmentof each data field is the field synchronizationsegment which is defined by the ATSC Standard for TransmitterSynchronization as follows,

Data Field Synchronization segment (FSS) is inserted by themodulator. The FSS carries severalpseudo-random binary sequences (PRBS) used as training signals for adaptive equalizers in re-ceivers. One of those PRBS sequences alternates in phase from FSS-to-FSS. This creates a DataFrame structure composed of two Data Fields. Because of the integer phase relationship betweenthe Data Frame and its two Data Fields, it is possible to synchronize the Data Frame structureand derive the Data Fields from the Data Frame structure.5

It should be noted that the PRBS that alternates in phase fromDFS-to-DFS is the middle set of the PRBSsequences.

The data field synchronization segment is the component of the signal used to lock onto and track the signalas it is being received. These data field synchronization segments only occur twice in every frame, with datafield synchronization segments (DSS) appearing in every data segment in a frame. The DSS is a 4-symbol,segment synchronization piece composed of a [-5, 5, 5, -5] symbol structure. This segment synchronizationsection at the beginning of each data segment does not carry any frame data, but can be detected and used ina feature detector, or as a counter between FSS.

The segment synchronization section occurs at the beginning of every segment within a frame and framesrepeat every 77.3µs. This makes the frame rate for these signals 20.6655 frames/sec, therefore, each frame in

2

Figure 2. Structure of an ATSC Frame

Figure 3. ATSC Data Field Structure

an ATSC signal is approximately 14507 km long. Another benefit of these segment synchronization sectionsis in the acquisition of the signal, since a receiver will be picking up approximately 20.66 frames/sec, therewill be 41.32 data field synchronization segments every second which provide frequent opportunities for thesystem to lock onto the signal. This allows for a short acquisition time and a strong lock to be obtained withthe signal. The long frame, along with the synchronization segments and the counters within each frame,provide opportunities to determine the phase of the signal as it is received. This phase angle informationalong the frame then provides information which allows for the cycle ambiguity to be determined. Thisinformation allows for a pseudo-range measurement to be obtained, which will be used by the filters to obtainposition estimates.

3

Signal Timing RequirementsIn order to generate the signals described above, there mustbe a strong tim-ing standard for the oscillators that create the signals. These timing standards are described in Sections 4.3and 12.1 of the ATSC Standard for Transmitter Synchronization5 and will be outlined here.

The ATSC standard recognizes how important timing is in achieving transmitter synchronization and sig-nal generation. Specifically, the ATSC standard uses timingstandards in two different aspects of signalsynchronization: ”establishing phase relationships between data frames emitted by multiple transmitters, andestablishing phase relationships between data frames emitted by single or multiple transmitters and an ex-ternal time reference.”5 Ehe ATSC defines the period of the Transport Stream bit rate, 19.39 Mb/s, as thefundamental unit of time expression in all ATSC signals, in order to specify what the timing standards needto be achieve synchronization. This leads to an ATSC defined time unit of 51.57 ns. From this time unit, theATSC goes on to require that all transmitters have a 50 ns or better peak-to-peak accuracy every second.

The ATSC standard specifically designed the system to have all transmitters in a region broadcast theirframes at the same time. This was written into the standard toprovide the following benefits:5

1. Improved channel change time between services on different frequencies in the same region.

2. Minimized disturbance during hand-off of services from asingle service provider from one region tothe next.

3. The opportunity to use ATSC mobile/pedestrian/hand-held broadcasts for geo-location by receivingdevices.

In order to achieve the desired timing for these signals, thetransmitters require an external reference pointto synchronize the oscillators. The standard defines the external reference to be the GPS clocks. ”The externaltime reference shall be the one provided by the Global Positioning System (GPS) satellite navigation systemand shall be determined with an accuracy of 50 ns peak-to-peak or better at all network locations.”5 Thisensures that the transmitters have a stable, well-defined external reference to follow and prevent drift in thesignal.

Overall, the timing requirements make the ATSC signal a strong navigation signal source. The 50 ns peak-to-peak accuracy of the signal timing means that the signal will have approximately a 15m position errorin the range observation. This error could be larger since the transmitter clock can drift during the secondbetween timing updates, but at least one observation every second will have this accuracy.

Through meetings with television broadcaster CBS - KCNC Denver, the timing setup of a HD transmissiontower is better understood. Each exciter is locked to GPS, and also has a local oscillator, for modulating thefeed onto the signal. CBS uses Harris APEX Ranger class CZ1000 exciters in the system to generate thesignal. The APEX exciters when locked to GPS drift±0.5Hz per month, and if GPS is lost, drift at±200Hzper month using a local Oven Controlled Crystal Oscillator (OCXO) setup.

ATSC Signal FeaturesWhen collecting and processing ATSC data, there are severalsignal componentsto look for to ensure your data is clean and the signal is strong. The first thing to look at is the constellation ofthe data collected. For ATSC signals, the constellation should be a square which rotates in time. An exampleof an ATSC constellation is seen in Figure4. The constellation shows both the magnitude and phase of asignal in a polar plot.

Along with the constellation, an FFT of the signal provides information on the signal that is received. AnATSC signal has a 6MHz bandwidth with a sharp ramp up and down at either end. An example of an FFT ofthe ATSC signal is seen in Figure5. From the FFT, some important information can be gathered; includingthe signal-to-noise ratio (SNR) of the received signal. Thelocation and strength of the signal’s pilot tonecan also be seen in the FFT. The pilot tone is important for theDoppler count measurement and needs to bedetectable for use as the Doppler count observable. The ATSCpilot tone has a 2 mHz resolution per FCC73.622 requirements and is generated at 10 dB above the rest of the signal to aid in finding the signal andlocking on.

4

Figure 4. ATSC IQ Constellation

Figure 5. ATSC signal FFT

Finally, if the rest of the signal looks appropriate, the PRBS codes autocorrelations can be run. The ATSCsignal has both FSS and DSS synchronization segments in it which can be used for autocorrelation. Since theFSS signal is stronger then the DSS the FSS should be used for extracting timing from the signal. The FSS isdefined in theATSC Digital Television Standard Part 2:RF/Transmission System Characteristics.6

The FSS is comprised of 8 different sections. The first piece of the FSS is the 4 symbol DSS code.Following the DSS is a 511-symbol pseudo-random sequence (PN511) which is defined by Equation1, andis pre-loaded with a starting setup of 010000000.

X9 + X7 + X6 + X4 + X3 + X + 1 (1)

Following the PN511 code the FSS has three instances of a 63-symbol pseudo-random sequence (PN63),

5

with the middle PN63 sequence inverted on every other FSS. The PN63 code is defined by Equation2, andis pre-loaded with a starting setup of 100111.

X6 + X + 1 (2)

The next set components of the FSS are the VSB Mode bits. This sections is comprised of 24 symbols andshall ”signal the VSB mode for the data in the associated DataField. The values of these symbols shall bedetermined by the values of the VSB mode bits as defined in Table 5.3.”6

The following 92 symbols of the FSS are reserved for use when enhanced data transmission methodsare used. Finally, because the ATSC signal uses a cyclic prefix, the final 12 symbols of the segment shallcorrespond to the last 12 symbols of the previous segment. For every section in the FSS, a binary value of 0corresponds to a symbol of level -5 and a binary value of 1 corresponds to a symbol of level +5.

DESCRIPTION OF NAVIGATION DATA TYPES

Using HDTV signals and a space qualified software defined radio (SDR),7 two different navigation datatypes can be extracted. These navigation data types are a pseudo-range, which is a range measurement plusan unknown bias, and a Doppler count observable. This paper focuses on how the pseudo-range measurementcan be extracted from the ATSC signal, but a short overview ofthe Doppler count observable model will bedescribed briefly.

Phase Angle

The pseudo-range observable is a phase measurement of the frames that are modulated onto the carrierphase of the signal. Each data frame contains two frame synchronization segments (FSS), along with anadditional 624 data segment synchronization (DSS) sections.

In order to obtain this pseudo-range observable a convolution of the signal must be performed. A convo-lution is a process that first reverses a given signal before then shifting that same signal. The resulting signalis then multiplied with a second signal. Convolution is a method for performing autocorrelations and canbe used to pull timing information out of a signal. The mathematical definition of a convolution is found inEquation3.

y(t) = x(t) ∗ g(t) =

∫

∞

−∞

x(τ)h(t − τ)dτ (3)

A convolution will take the given signals and return a new signal that is noise at all places except for wherethe shifted signal and the signal it is being multiplied against line up. In the case of an ATSC signal thePRBS that makes up the FSS is the shifted signal while the second signal is the raw signal being receivedby the satellite. At these points, the new signal will have a peak which is seen well above the noise floorand can be detected by a computer and used to extract timing information from the raw signal. If the givenPRBS is not found within the raw signal then the resulting signal will be nothing but a uniform noise floor.When performing a convolution, the sampling rate of both theraw signal and given signal must be the sameotherwise the results will show no peaks even if the PRBS is within the signal.

By performing this autocorrelation of the known FSS PRBS codes on the signal as it is brought into thereceiver, the location of the signal within a frame is known.Since each FSS falls at specifically defined andknown intervals along the frame, when each one is seen, the exact location within each frame is known.

Once each phase measurement is taken, the filter can usea priori information, and current state informa-tion, to estimate the cycle ambiguity of the frames and, therefore, use the measurement as a range data type.This cycle ambiguity can be determined due to the length of each frame,∼14507km. This long frame lengthwill allow the filter to converge on a cycle ambiguity and further refine this estimate as more information isadded to the system.

6

The pseudo-range observable can be obtained by the receiverusing the following steps:

1. Acquire the carrier frequency

2. Autocorrelate the signal to find the FSS

3. Use the current best estimate of the state of the tower and satellite to estimate one-way light-time,integer ambiguities, etc., and convert the phase measurements into pseudo-range observations.

Doppler Count

In order to get a proper range-rate measurement for navigation purposes, a Doppler count measurementmodel will be implemented on the HDTV signal. The measurement model the Doppler count observableuses is from the Descanso textFormulation for Observed and Computed Values of Deep Space Network DataTypes for Navigation.8 The Doppler count model for HDTV signals is implemented using either the count ofthe pilot tones observed in the signal over a count time or a count of the DSS codes that can be autocorrelatedto in each data segment of the signal; which count type is usedwill depend on the SNR and ease of detectionon board a satellite. The Doppler count observable itself isdescribed in Equation4.

F1 = −C2

{

fT0+ ∆fT0

+ fT1(t2m

− t0) + fT2

[

(t2m− t0)

2 +1

12(T ′

c)2

]}

T ′

c

Tc

(4)

Where:

T ′

c

Tc

= 1 −ρ̂1e

− ρ̂1s

Tc

(5)

And where:

• ρ̂ is a precision one-way light time.

• T ′

cis the transmission interval.

• Tc is the count interval of a Doppler observable, this is measured in seconds of Station Time, ST, at thereceiving electronics.

The remaining terms are all quadratic coefficients used to describe the drift of the signal fromfT0due to

the motion of the satellite and the Earth during the Doppler count interval. The Doppler count measurementis time-tagged at time TT, defined as the middle of the Dopplercount interval for the measurement model.

GNU RADIO OVERVIEW

In order to generate a simulated ATSC signals to study as wellas control the SDRs used to collect realdata, the program GNU Radio9 is used.GNU radio is an open-source radio processing toolkit which allowsfor controlling software defined radios, performing signalprocessing, as well as providing signal simulationcapabilities. The library is supported by a large communityof developers that produce new processing mod-ules. Designs in GNU Radio can be produced by building block diagram flow graphs that compile down topython executable files.

In addition to supporting numerous, common signal processing modules, GNU Radio also includes supportfor interfacing with different physical radio peripherals. These interface modules handle the configuration ofthe radio device and the flow of in-phase and quadrature (IQ) data between the processing software and radio.

GNU Radio designs can be developed to perform a variety of processes, and are very useful in developingGUIs to visualize the processing of radio data and applications to record IQ data for post processing or

7

visualization. In addition to interfacing with data generated by a radio peripheral, GNU Radio also supportsthe generation of simulated IQ data that can be used to test and verify signal processing algorithms. Inthis work, GNU Radio was used extensively to simulate ATSC signals, visualize the processing of ATSCdata, and record raw IQ data that was used to develop the FPGA firmware. Figure6 shows an exampledata acquisition flow graph, while Figure7 shows the visualization of the ATSC spectrum using the GPUaccelerated gr-fosphor block in GNU Radio.

Figure 6. GNU Radio flow graph design for data acquisition. The source of the datais the radio peripheral and the sink is a pair of binary files.

RESULTS USING SIMULATED DATA

Using GNU Radio, an ATSC signal simulation suite was created. Figure8 shows the signal generationand visualization flow graph used for this work. This setup was then used to generate ATSC IQ data used toverify signal structure components and signal detection techniques. After sufficient data was collected fromthe GNU Radio simulator, autocorrelation tests were performed on the signal using the known FSS PRBScodes found in theATSC Digital Television Standard Part 2:RF/Transmission System Characteristics.6

Figure9shows the results of this convolution, while Table1 summarizes the peak detection’s and the timingthat these peaks provide. The results from the simulated data show the expected timing spaces between peaksand yield high SNR from the autocorrelation. The exact same timing spacing between peaks is expected for asimulated signal without any Gaussian white noise added to it. The spacing between peaks will be expectedto have minor deviations in peak time when real data is collected due to noise and delays in the signal. Thesimulated signal data processing confirmed what was expected from the signal given the signal structure andtiming requirements.

8

Figure 7. Waterfall plot of ATSC Spectrum gnerated using gr-phosphor in GNURadio. Data is centered at 527 MHz with a 10 MHz span. The characteristic pilottone is readily observed between 524 and 525 MHz.

Figure 8. GNU Radio flow graph design for simulating ATSC signals.

SDR OVERVIEW

Typically, software defined radios are composed of a radio peripheral that digitizes the spectrum and acomputer that runs the software that processes the data. Theprocessing requirements for SDR can be verydemanding. The bandwidth of unprocessed IQ data can range from 2.0 MB/s for 8-bit samples at 1 MSPSup to 200 MB/s for 16-bit samples at 50 MSPS. Most modern computer peripheral interfaces could easilyhandle the low end of that range, but the higher end of that range would require higher bandwidth interfaces,like USB 3.0, PCIe, or 10 GigE. This also has ramifications on the type of non-volatile storage used if theapplication requires uninterrupted data recording.

In addition to the challenges presented with interfacing tosuch a high data rate, there are challengesassociated with processing such a high data rate. Radio datais generated in a continuous stream. Thispresents a challenge to CPU or GPU based processors, as thesedevices process data in packets. To keepup with the high rate-streaming data, the CPU must break the stream into smaller chunks and process eachsection fast enough that the CPU does not drop any of the data.The high sampling-rate IQ data requirepowerful computers to keep up with the processing.

9

Figure 9. FSS Autocorrelation using Simulated Data

Table 1. Simulated ATSC signal autocorrelation results

Peak Detection Peak Value (dB) Time Since Last Peak (ms)

1 37.5165122 0

2 38.81232104 24.19719818

3 37.51825814 24.19719818

4 38.84550043 24.19719818

5 37.49769798 24.19719818

6 38.86524344 24.19719818

7 37.52531245 24.19719818

8 38.84442939 24.19719818

9 37.51109419 24.19719818

As an alternative, FPGAs can be used to lower the CPU data-rate requirements by pre-processing the data.FPGAs can be designed to process data in a stream, allowing even low-cost chips to significantly reduce thedata bandwidth presented to a CPU. CPUs are very useful because they are extremely flexible and many toolsand software libraries exist to accelerate development times. FPGAs on the other hand, tend to have fixedperformance, and have a limited number of tools and firmware libraries to use in development. Moreover,FPGAs require designers to use hardware description languages that physically describe the connections andconfigurations of logic circuits. Designers must also be cognizant of the limited resources available on theFPGA and design their circuits to meet timing requirements.The payoff, of course, is a massive reduction indata rate. The solution used in this work was to mix both FPGAsand CPUs to leverage the strengths of eachand reduce the overall system size, weight, power, and cost.

10

SDR HARDWARE

For this work, several different SDR hardware systems were used. These included different radio periph-erals as well as different proccesing systems.

Radio Peripherals: Hack RF

The HackRF One from Great Scott Gadgets, was used extensively to capture data for post-processing. Thisdevice can tune from 1 MHz to 6 GHz, outputs 8-bit samples, andcan sample up to 20 MSPS. The radio datais formatted internally using a CPLD and passed to a processor over USB 2.0.10

Radio Peripherals: AD9361

The AD9361 is a radio-frequency-integrated-circuit (RFIC) produced by Analog Devices. The radio con-version chains and digitizers are all fully integrated intoa single chip. This allows the device to be small,light, and draw little power making it an ideal candidate forembedded or size, weight, and power constrainedapplications. This radio can tune from 70 MHz to 6 GHz, outputs 12-bit samples, and supports up to 56 MHzof instantaneous bandwidth on two full duplex channels.11 For this work, the FMCOMMS3 board was usedto break out the functionality of this radio peripheral.

Processors: Laptops

Modern laptops tend to have both the CPU power and support forhigh-rate interfaces required to run thehigh-bandwidth radio processing. Moreover, they tend to have easy acces to all the software libraries andrepositores required to run the latest versions of GNU Radio. Much of the data acquisition and processing forthis body of work was done using laptops for their ease of use.Their primary drawback is their size and cost.While it is perfectly fine to run a radio processing application on a laptop in a lab, it would be impractical touse that same laptop on an unmanned aircraft or a satellite.

Processors: Single Board Computers

Single board computers (SBCs) have continued to fall in costwhile increasing in performance in recentyears. While the Raspberry Pi was somewhat under powered to run radio processing applications, newembedded computers in the same form factor have been released recently that are more than capable ofrunning GNU Radio. One of these boards that has been used for this work is the SolidRun HummingBoardshown in figure10.

Figure 10. SolidRun Hummingboard SBC.

This SBC features a 1 GHz quad core CPU with 1 GB of RAM. More importantly, it supports USB 2.0,PCIe 2.0, and SATA II.12 The capable CPU and support for high-bandwidth interfaces makes the SBC an

11

ideal candidate for wideband data acquisition. When coupled to the HackRF and a 128 GB mSATA solidstate hard drive, the HummingBoard can record up to 57 minutes of IQ data sampled at 20 MSPS.

Processors: Zedboard

The final processor used in this body of work was the Zedboard.This development board is based on theXilinx Zynq processor. The Zynq is unique in that it incorporates a dual core ARM CPU and FPGA fabricon the same chip. The CPU and FPGA fabric are connected via an AXI based data bus. The Zynq featuresAXI high performance (HP) connections as well as AXI generalpurpose (GP) connections.13 The AXI HPconnection supports wide-bandwidth transfers and would typically be used for moving unprocessed IQ data.The AXI GP connection is much slower and is used for setting orreading registers. The ARM CPU runsat 667 MHz by default but can support rates up to 1 GHz. The Zedboard supports USB 2.0 and gigabitEthernet, but uses MicroSD cards for non-volatile storage which limits its ability to store IQ data. For thiswork, the Zedboard is coupled with the FMCOMMS3 card over an FPGA mezzanine card (FMC) connector.The Zedboard and FMCOMMS3 card is pictured in figure11.

Figure 11. Zedboard (green PCB) and FMCOMMS3 (blue PCB).

RESULTS USING REAL DATA AND POST PROCESSING

Using an omni-directional antenna, the HackRF SDR, and the GNU Radio flow diagram seen in Figure6ATSC IQ data was collected from the CBS-Denver transmissiontower centered at 599MHz. This data wasthen post-processed using the same techniques as the simulated ATSC signal data. The resulting autocorre-lation results can be seen in Figure12 and are summarized in Table2. The autocorrelation peaks detectedusing the real data have a similar SNR to the simulated signalresults but have an absolute peak height ap-proximately 10dB lower on average. The high SNR found in the data allow for peak detection’s to still occurautonomously. The noise floor of the collected data is not as consistent as the simulated signal results aswould be expected given the noise that is introduced in the system when the signal is generating, transmit-ting, propagating through the air and being received. Even with the noise floor shifting over time with thesignal, the SNR of the autocorrelation peaks remains consistent and moves with the noise floor.

The timing between autocorrelation peaks in the collected data is not exactly the same between every peak.There is a 71.43 ns variation between the largest and smallest peak separation in the processed data. This canbe explained with system noise, signal noise, and atmospheric delay of the signal while it travels. A variationof 71.43ns would result in 21.414 m noise in the pseudo-rangemeasurement.

FPGA FIRMWARE DESIGN

The core digital signal processing (DSP) modules of the automatic ATSC detection firmware were codedin VHDL. The design was broken down into its component DSP functions. Each function was developed

12

Figure 12. FSS Autocorrelation using Collected Data

Table 2. Collected ATSC signal autocorrelation results

Peak Detection Peak Value (dB) Time Since Last Peak (ms)

1 25.05364306 0

2 25.28780891 24.19714286

3 25.44994281 24.19707143

4 28.15646413 24.19707143

5 28.01537728 24.19714286

6 29.46657492 24.19707143

7 26.72599264 24.19714286

8 26.75829577 24.19707143

9 24.0126005 24.19714286

10 27.42005453 24.19707143

11 27.66556821 24.19707143

into separate VHDL modules to maximize the design’s re-usability, portability, and modularity. Each moduleis highly parameterized and reconfigurable. The DSP firmwareis connected to the radio peripheral usingfirmware provided by Analog Devices. The configuration and control of the firmware is handled over theAXI GP connection. The results of the detection were also communicated over the the AXI GP connection.

13

DSP Design

The DSP firmware is composed of two major building blocks: thecomplex autocorrelator and movingaverage detector. The autocorrelator takes in the IQ data and applies the complex ATSC frame-sync sequence.The output of the autocorrelation is converted to magnitudesquared and passed to the detector. The detectorcalculates a moving average of the magnitude squared outputand scales this to set a detection level. Finitestate machine logic is used to flag a detection and save its associated time and power.

DSP Design: Autocorrelator

The autocorrelator is designed based on previous work out ofthe CU cyber physical systems lab.14 Thisdesign uses the sign of the data and correlation sequence to approximate an autocorrelation. By using justthe sign bits, the autocorrelator does not require any multipliers to run. The drawback is that the correlationsequence needs to be well approximated by its sign alone. As the ATSC sequence is based on Gold codes, itis in fact well approximated by its sign alone. A comparison of full, complex multiplier autocorrelation andsign-based autocorrelation for the ATSC sequence is shown in figure13.

Figure 13. Autocorrelation results calculated in post processing. Data recorded overthe air at 6 MSPS. Red shows sign only result while blue is the full complex multipli-cation result. Both show similar signal to noise ratio.

The autocorrelator is parameterized to take generic data widths in and can be compiled for sequences oflengths equal to a power of two. New filter coefficients are loaded simply by playing in data and a datavalid signal for n clock cycles where n is the length of the sequence. For this design, the ATSC frame syncsequence was found to last for 464 clock cycles (at 6 MSPS). Anautocorrelator of length 512 was designedand the frame sync was padded with zeros to fill out the extra length. As a complex autocorrelation is beingperformed, four filters are instantiated one for each combination of I and Q. The resulting I and Q outputis calculated by summing the appropriate filter outputs. Thecomplex output of the autocorrelators are thenconverted to magnitude squared by simply squaring the I value and the Q value and summing the results.

DSP Design: Moving Average Detector

The detector is based on a moving average filter. This moving average calculates a running approximationfor the mean of the autocorrelation output. This mean is thenscaled with a multiplication to set a detectionlevel. This detection scheme is similar to a constant false alarm rate (CFAR) detector as it is calculating a

14

running level to detect on. In contrast to a true CFAR detector, no guard cells are used in this implementation.The moving average filter is built using a block RAM (BRAM) module to minimize logic gate usage. The coreis constrained to compiling for power of two length moving averages. This is done to maximize the efficiencyof the BRAM utilization, minimize the complexity of memory addressing, and allows a logical right shift tobe used to normalize the accumulation term. The core has beenparameterized to take in arbitrary data widthsand power of two window sizes. The output of this filter is scaled by a multiplier and fed into a detectionfinite-state-machine (FSM). This FSM compares the autocorrelator outputs and detection levels looking forpeaks. The FSM is designed to mitigate multiple triggers by ignoring successive detection’s for a period oftime after the first peak is observed. When a new detection is found, the FSM logic latches the current FPGAtime (implemented using a simple, 32-bit counter running at6 MSPS) and the maximum magnitude-squaredpower value observed in the most recent detection period. That maximum value is reset for the next periodand once the user specified hold-off time has been met, the FSMallows for new detection’s.

Supporting Firmware Design

The detector settings and autocorrelator coefficients are configured using the AXI GP bus. This bus runsat 100 MHz with bursty transmissions. As the design runs at 6 MSPS, clock domain crossing firmware wasdeveloped to bridge the gap for register level access. This firmware simply clock new values through a seriesof registers on the input clock side and a series of registerson the output clock side. As the autocorrelatorscontain 512 coefficients, a dual port BRAM and FSM control were implemented to handle their configuration.The user loads the BRAM on the AXI clock domain. When the BRAM is fully loaded, the FSM reads thedata out of the other port clocked on the DSP clock domain.

When a new detection is made, the DSP firmware writes a flag register on the AXI bus along with thetime and power information associated with the detection. These also go through clock-crossing firmware tomitigate meta-stability or race conditions.

Software Design

The Zynq’s ARM runs a Linux-based operating system. Currently it runs the Linaro distribution providedby Analog Devices with their FMCOMMS3 card. The radio configuration is currently handled manuallyusing the provided AD9361 driver developed by Analog Devices. This driver uses the industrial I/O (IIO)device drivers to interface with the radio. The AXI GP ports are interfaced to the operating system using thegeneric user-space I/O (UIO) driver. This driver presents device files for the user to interact with. Currently, ac program is used to memory map the UIO devices and interact with them to configure the firmware settingsand take data. The configuration happens first in a serial manner. To take data back from the FPGA, thesoftware continuously poles the detection flag register. When the flag goes high, the software reads theassociated power and time registers, then writes a zero to the flag register to clear it. New data is appended toan array and eventually written to a binary file for post processing.

FPGA Detection Results

Currently, the firmware is designed to clock at 6 MSPS. This isthe minimum bandwidth required for theATSC sequence. It gives a timing resolution of 167 ns. As the DSP modules were designed to be modular,the design could be quickly re-compiled to over-clock at 12 or 24 MSPS which would improve the timingresolution at the cost of higher resource draw. Currently, the design uses approximately 9 percent of theavailable logic gates, one multiplier, and one BRAM. The resource draw is shown in figure14.

Data was taken over the air in the cyber-physical systems labat CU Boulder using the Zedboard. A JTAGdebugger was used to capture internal debug data. Figure15shows an autocorrelation output and associateddetection level observed when tuned to 617 MHz.

Multiple detections were examined at 617 MHz using a varietyof scaling values for the moving averagedetector. Figure16 shows the calculated peak spacing in milliseconds for 1024 detections as a function ofdetection number. The moving average level was scaled by a factor of 15 for these detections.

15

Figure 14. FPGA resource utilization table for Zedboard Zynq. Only one multiplieris used, but three are instantiated. Two were implemented ingates by the design toolsfor this run.

Figure 15. FPGA autocorrelator and moving average detectoroutput. A correlationpeak is clearly observed.

Many detections were observed near the expected value of 24.2 milliseconds. False detections were alsoobserved. Additionally, detections were observed at 2x and3x the expected value. These can be attributed tomissing a detection in the pulse train, but observing the subsequent detection. Figure17shows the histogramof those same peak spacing detections.

It is evident that the false alarm rate is much lower than it may appear to be in the raw detection spacingplot. The scaling value of the moving average detector was varied to observe its impact on false alarm rates.A low scaling value of 12x is shown in figure18, while figure19shows the results for a high scaling value of20.

The scaling factor of 12x results in very few missed detections, but many false alarms observed in a clusterbelow the 24.2 millisecond expected value. In contrast, thescaling factor of 20x results in no false alarms, butmany missed detections as made evident by the far higher portion of spacing’s observed at an integer multipleof the expected spacing. The trade-off between probabilityof detection and false alarm rate is expected.

16

Figure 16. Peak spacing detection’s in milliseconds plotted as a function of detectionnumber. The expected value of 24.2 milliseconds is observedalong with false detec-tion’s and missed detection’s.

Figure 17. Histogram of the peak spacing detection’s using a15x detection scalingfactor. 100 bins were used to generate the histogram. The expected value and integerfactors of the expected value are readily observed with somefalse alarms presentbelow the expected 24.2 miliseconds.

False alarms can be eliminated by applying a filter in software that disqualifies spacing detection’s that falloutside an upper and lower bound. The effects of missed detections can similarly be mitigated by applying afilter with bounds at integer multiples of the expected valueand re-scaling them appropriately. The results ofapplying these filtering techniques to the 20x scaling case is shown in figure20.

Applying this filtering qualifies 1015 of the 1024 detections. The mean of the set was found to be 24.1971

17

Figure 18. Histogram of the peak spacing detection’s using a12x detection scalingfactor. 100 bins were used to generate the histogram. Many false alarms are observ-able.

Figure 19. Histogram of the peak spacing detection’s using a20x detection scalingfactor. 100 bins were used to generate the histogram. No false alarms are detected,but many detection’s were missed.

ms with a standard deviation of 67.9 ns.

CONCLUSIONS

The timing information extracted from the simulated ATSC correlates with what is expected from theATSC A/53 standard.6 This timing information was also found to agree with the collected data to within71.43 ns at maximum deviation. Both of these results yield pseudo-range navigation observables with as

18

Figure 20. Detection history of the peak spacing using a 20x detection scaling factor.The data was filtered in software to reject spacing measurements that deviate from aninteger multiply of the expected.

much as 21.414m of noise. In order to obtain these timing measurements from the signal, the satellite’s on-board CPU needs to be able to either process this data at a rateof 17.2MB/s, which is the signal rate seen onthe AD9361, or save the data at this rate to its hard-drive forpost-processing on the ground.

The FPGA design is able to greatly reduce the computational load on the ARM CPU. Assuming a prob-ability of detection of 1 and false alarm rate of zero, the FPGA will supply new detections to the processorat a rate of 41.32 Hz. The power and time-stamps passed to the processor are 32-bits each making the totaldata rate that the processor needs to handle 331 Bytes/s. This is 0.0019244% of the data that the processorpreviously needed to handle, which is a reduction in data rate of 17.199669 MB/s and 5 orders of magnitudein processing power.

Further the FPGA design is shown to have the ability to extract timing information of the same accuracy aspost-processing the collected data. Table3 summarizes the results of these studies. Maintaining equivalenttiming accuracy while significantly reducing CPU load on-board a satellite is of great importance. Due tothe limited size, weight and power (SWaP) available for instruments on-board a satellite, along with, thelimited and valuable CPU time, makes the processing power savings seen with the FPGA much more vital toa satellite using navigation observables from HDTV signals.

Table 3. Summary of the timing extracted from a raw signal using different ATSC autocorrelationmethods

Data Type Average Timing Between Peaks (ms) Deviations (ns)

Simulated ATSC Signals 24.1972 0

Post-Processed ATSC Signals 24.1971 71.43 (Max Deviation)

FPGA Processed ATSC Signals 24.1971 67.9 (Std Deviation)

HDTV signals can be used for autonomous satellite navigation, augmenting existing satellite navigationmethods, or as a back-up navigation system for a satellite, all for a low CPU cost. The CPU savings, com-bined with the flexibility a SDR provides for scanning wide frequency ranges, and adapting to local radioenvironments on the fly, allows HDTV signals to be a promisingsource for future satellite navigation observ-

19

ables.

ACKNOWLEDGMENTS

The authors would like to acknowledge CU-Boulder professors Dennis Akos, Penina Axelrad, Eugene Liu,and Peter Mathys for their guidance and assistance with thisproject.

The authors would also like to acknowledge KCNC CBS-Denver,specifically John Baich, the Director ofBO&E, and Paul Deeth, the transmitter supervisor, for providing access to the CBS transmission station andgiving a detailed overview of the transmission specifics forHDTV broadcasting.

REFERENCES

[1] Advanced Television Systems Committee, 1776 K Street, N.W., Suite 200, Washington, D.C. 20006,A/53: ATSC Digital Television Standard, Parts 1 - 6, 2007, 2007. Doc. A/53.

[2] European Telecommunications Standards Institute, 650Route des Lucioles, F-06921 Sophia AntipolisCedex - FRANCE,Digital Video Broadcasting (DVB); Framing structure, channel coding and modula-tion for digital terrestrial television, 2009. ETSI EN 300 744 V1.6.1 (2009-01).

[3] Association of Radio Industries and Businesses,Portable OFDM Digital Transmission System For Tele-vision Program Contribution, 2005. ARIB STD-B33 Version 1.1-E1.

[4] M. Rabinowitz and J. J. S. Jr., “A New Positioning System Using Television Synchronization Signals,”IEEE Transactions on Broadcasting, Vol. 51, March 2005, pp. 51–61.

[5] Advanced Television Systems Committee, 1776 K Street, N.W., Suite 200, Washington, D.C. 20006,ATSC Standard for Transmitter Synchronization, April 2011. Doc. A/110:2011.

[6] Advanced Television Systems Committee, 1776 K Street, N.W., Suite 200, Washington, D.C. 20006,ATSC Digital Television Standard Part 2:RF/Transmission System Characteristics, December 15 2011.Doc. A/53 Part 2:2011.

[7] J. Hamkins and M. K. Simon,Autonomous Software-Defined Radio Receivers for Deep SpaceAppli-cations. Deep Space Communications and Navigation Systems Center of Excellence, Jet PropulsionLaboratory, California Institute of Technology, 2006.

[8] T. D. Moyer,Formulation for Observed and Computed Values of Deep Space Network Data Types forNavigation. Deep Space Communications and Navigation Systems Center of Excellence, Jet PropulsionLaboratory, California Institute of Technology, JPL Publication 00-7 ed., October 2000.

[9] “GNU Radio Manual and C++ API Reference Documentation,”07-20 2015.https://gnuradio.org/doc/doxygen/.

[10] “Great Scott Gadgets - HackRF One,” https://greatscottgadgets.com/hackrf/.[11] “AD9361 — datasheet and product info 2 x 2 RF Agile Transceiver — Analog Devices,”

07-20 2015. http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html#product-overview.

[12] “Hummingboard - Powerful Linux Single Board Computer,” 07-20 2015. https://www.solid-run.com/products/hummingboard/.

[13] “Zynq-7000 All Programmable SoC,” 07-20 2015. http://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html.

[14] A. Dutta, D. Saha, D. Grunwald, and D. Sicker, “Practical implementation of blind synchronizationin NC-OFDM based cognitive radio networks,”Proceedings of the 2010 ACM workshop on Cognitiveradio networks - CoRoNet ’10, 2010, p. 1. http://portal.acm.org/citation.cfm?doid=1859955.1859957,10.1145/1859955.1859957.

20