rwg

• ATSC 3.0's physical layer can already transmit GPS time in a way that receivers could get it back out. What BPS brings to the table is a requirement and specification for accurately and consistently filling in the physical layer preamble fields containing the time data, along with a new physical layer pipe (think "low-level data stream") that contains additional information about the transmitter and, optionally, its neighboring transmitters.

• BPS is capable of producing time fixes when the receiver only has a lock on one source. This isn't surprising at all — GPS receivers can do the same thing. But either type of receiver with only one source would see a clock offset proportional to the path delay, which it wouldn't be able to compute and back out without knowing its position.

• BPS is only designed for 2-D position fixes. While that's a reasonable design decision (the vertical position error would be massive), it also makes BPS less useful for the NAB's "indoor positioning for first responders" use case, especially in areas with multi-story buildings.

• The need to receive and process/decode multiple, most likely non-adjacent 6 MHz channels for positioning increases receiver complexity and cost.

• The NAB claims that 1 kilometer of separation between two BPS transmitters is "sufficient for useful position determination." I don't buy it, especially in the face of poor transmitter geometry.

• They note that 16 TV stations in the New York City area broadcast from One World Trade Center, so for the purposes of BPS, they're effectively one station. This kind of transmitter colocation is incredibly common, both in urban areas (ten TV stations broadcast from Sutro Tower in San Francisco) and in more rural areas (six TV stations in the Roanoke-Lynchburg DMA broadcast from towers within ~1 mile of each other on the ridgeline of Poor Mountain). Even if every ATSC TV station became an ATSC 3.0 w/ BPS transmitter, bad transmitter geometries would destroy BPS's position accuracy in lots of markets.

• What's the business case for broadcasters? BPS won't be free for broadcasters to implement, and there doesn't seem to be a path to it generating revenue except for a hand-wavy "maybe one day televisions will be able to determine their locations without Internet connections using BPS, and then broadcasters can do location-targeted advertising with those TVs!"

My uncharitable take is that BPS will never be a usable standalone PNT system. A timing system in the "rebroadcasts GPS" sense? Maybe. Standalone positioning? No way. Broadcasters implementing BPS (or ATSC 3.0 at all) without being forced to by the government? I don't see it.

http://www.aeic.alaska.edu/input/west/proj/ASRA/2007/picture...

"Helicorder" was Teledyne Geotech's brand name for their line of drum recorders, but it was so popular that "helicorder" has become a generic name for "drum recorder" in the seismological community, much like "Xerox" became synonymous with "photocopier." (If you ever look at earthquake records on-line, check for "heli" in the URL.)

A piece of paper is wrapped around the drum. A pen/stylus rests on the paper and deflects side-to-side depending on the polarity and magnitude of the input signal. A big positive voltage makes the pen move really far to one side, and a small negative voltage makes the pen move not so far to the other side. The pen is also attached to a threaded shaft that rotates, slowly moving the pen from one side of the paper to the other. The drum itself also rotates, and the rotation speed of the drum and the shaft was usually selectable — most people had recorders with small drums set to record ~24 hours of data per piece of paper, with wider drums set to record for a proportionately longer amount of time. (The higher the drum speed, the better the record quality, but then you had to change the paper more often.)

So we can record the signal onto paper, but we're missing a very important thing — time. We need to know exactly when stations saw ground motion in order to locate earthquakes and other seismic events. Enter the GPS clock (and the WWVB clock and GOES clocks before it). The GPS clock received a very accurate time signal and was configured to output a very simple timecode known as "slow code." Slow code works as such:

• At exactly the start of the 0'th second of every minute, generate a voltage pulse for some amount of time, usually 2 seconds.

• At exactly the start of the 0'th second of the 0'th minute of every hour, generate a voltage pulse for some longer amount of time, usually 4 seconds.

• At exactly the start of the 0'th second of the 0'th minute of the 0'th hour of every day, generate a voltage pulse for some even longer amount of time, usually 6 seconds.

This slow code would be added to the signal being recorded by the drum recorder, adding precisely timed "bumps" to the record. When the paper was changed on the drum every 24 hours, someone would write or stamp several pieces of information on the paper: the seismograph station's name, the date, and the time of the first time mark:

http://www.hilo.hawaii.edu/~nat_haz/earthquakes/media/SeisDE...

Note the column of time marks between the stamped dates. The narrow marks are minute marks, the slightly wider marks are hour marks, and the widest mark (five lines above the little earthquake) is the day mark.

[insert wavy flash-forward transition here]

Eventually, everything at the seismological observatory went digital, and the seismograph stations were upgraded with digitizers that had their own GPS clocks for timestamping data. The WWVB clock and GPS clock sat unused until I cleaned them up and reconfigured them to serve up time for ntpd to consume.

https://tools.ietf.org/html/draft-ietf-6lo-btle

Basically, they saw what a glorious success 6LoWPAN (IPv6 over 802.15.4) has been (</sarcasm>), realized BLE/L2CAP has a fair bit in common with 802.15.4 (focus on minimizing power consumption, low data rates, crazy small per-packet payload sizes), and decided to reuse 6LoWPAN's IPv6 header compression (RFC 6282) in this IPv6-over-BLE standard.