Search This Blog

Wednesday, January 15, 2014

Why The World Needs OpenStreetMap

As reported by the Guardian: Every time I tell someone about OpenStreetMap, they inevitably ask "Why not use Google Maps?" From a practical standpoint, it's a reasonable question, but ultimately this is not just a matter of practicality, but of what kind of society we want to live in. I discussed this topic in a 2008 talk on OpenStreetMap I gave at the first MappingDC meeting. Here are many of same concepts, but expanded.

In the 1800s, people were struggling with time, not how much of it they had, but what time it was. Clocks existed, but every town had its own time, "local time", which was synchronized by town clocks or, more often than not, church bells. Railway time, then eventually Greenwich mean time, supplanted all local time, and most people today don't think about time as anything but universal. This was accomplished in the US by adoption first of the railroads, and then by universities and large businesses.

Geography is big business
The modern daytime dilemma is geography, and everyone is looking to be the definitive source. Google spends $1bn annually maintaining their maps, and that does not include the $1.5bn Google spent buying the navigation company Waze. Google is far from the only company trying to own everywhere, as Nokia purchased Navteq and TomTom and Tele Atlas try to merge. All of these companies want to become the definitive source of what's on the ground.

That's because what's on the ground has become big business. With GPS' in every car, and a smartphone in every pocket, the market for telling you where you are and where to go has become fierce.

With all these companies, why do we need a project like OpenStreetMap? The answer is simply that as a society, no one company should have a monopoly on place, just as no one company had a monopoly on time in the 1800s. Place is a shared resource, and when you give all that power to a single entity, you are giving them the power not only to tell you about your location, but to shape it. In summary, there are three concerns: who decides what gets shown on the map, who decides where you are and where you should go, and personal privacy.

Decision time
Who decides what gets displayed on a Google Map? The answer is, of course, that Google does. I heard this concern in a meeting with a local government in 2009: they were concerned about using Google Maps on their website because Google makes choices about which businesses to display. The people in the meeting were right to be concerned about this issue, as a government needs to remain impartial; by outsourcing their maps, they would hand the control over to a third party.

It seems inevitable that Google will monetise geographic searches, with either premium results, or priority ordering, if it hasn't done so already (is it a coincidence than when I search for "breakfast" near my home, the first result is "SUBWAY® Restaurants"?).

Of course Google is not the only map provider; it's just one example. The point is that when you use any map provider, you are handing them the controls - letting them determine what features get emphasised, or what features may not be displayed at all.

A road sign warning HGV drivers not to follow Satellite Navigation instructions.
A road sign warning HGV drivers not to follow Satellite Navigation instructions. Photograph: Christopher Thomond
Location, location
The second concern is about location. Who defines where a neighborhood is, or whether or not you should go? This issue was brought up by the American Civil Liberties Union (ACLU) when a map provider was providing routing (driving/biking/walking instructions) and used what it determined to be "safe" or "dangerous" neighborhoods as part of its algorithm. This raises the question of who determines what makes a neighborhood "safe" or not – or whether safe is merely a code-word for something more sinister.

Right now, Flickr collects neighborhood information based on photographs which it exposes through an API. It uses this information to suggest tags for your photograph. But it would be possible to use neighborhood boundaries in a more subtle way in order to affect anything from traffic patterns to real estate prices, because when a map provider becomes large enough, it becomes the source of "truth".

Lastly, these map providers have an incentive to collect information about you in ways that you may not agree with. Both Google and Apple collect your location information when you use their services. They can use this information to improve their map accuracy, but Google has already announced that is going to use this information to track the correlation between searches and where you go. With more than 500 million Android phones in use, this is an enormous amount of information collected on the individual level about people's habits, whether they're taking a casual stroll, commuting to work, going to their doctor, or maybe attending a protest.

Certainly we can't ignore the societal implication of so much data in the hands of a single entity, no matter how benevolent it claims to be. Companies like Foursquare use gamification to overlay what is essentially a large scale data collection process, and even Google has gotten into the game of gamification with Ingress, a game which overlays an artificial world onto this one and encourages users to collect routing data and photo mapping as part of effort to either fight off, or encourage, an alien invasion.

Finding the solution
Now that we have identified the problems, we can examine how OpenStreetMap solves each of them.

In terms of map content, OpenStreetMap is both neutral and transparent. OpenStreetMap is a wiki-like map that anyone in the world can edit. If a store is missing from the map, it can be added in by a store owner or even a customer. In terms of display (rendering), each person or company who creates a map is free to render it how they like, but the main map on OpenStreetMap.org uses FLOSS (Free/Libre Open Source Software) rendering software and a liberally licensed stylesheet which anyone can build on.

In other words, anyone who cares can always create their own maps based on the same data.

Similarly, while the most popular routing programs for OpenStreetMap are FLOSS, even if a company chooses another software stack, a user is always free to use their own routing software; it would be easy to compare routing results based on the same data to find anomalies.

And lastly, with OpenStreetMap data a user is free to download some, or all of the map offline. This means that it's possible to use OpenStreetMap data to navigate without giving your location away to anyone at all.

OpenStreetMap respects communities and respects people. If you're not already contributing to OSM, consider helping out. If you're already a contributor: thank you.

US Senate Calls For Information About GPS Data Use

As reported by The HillSen. Al Franken (D-Minn.) is pressing Ford over recent statements about the way the auto manufacturer uses drivers' data.
Last week, Ford's executive vice president for global marketing and sales Jim Farley said that GPS units in the vehicles allow Ford to “know everyone who breaks the law" but that the automaker does not share that data.
The claim came on the heels of a report from the Government Accountability Office (GAO) that found some car companies have "unclear" privacy policies that could confuse customers. The report also found that all companies the GAO looked at both collect and share location data.
"This would strongly suggest that Ford does, in fact, share its customers’ location data in some form," Franken wrote in a letter to chief executive Alan Mulally on Monday.
Farley has since retracted his statements but that has not quelled Franken's concerns.
He wrote that companies operating car-based GPS still provide "too little transparency" about the way information about their driving patterns is used. "American drivers deserve better – and Mr. Farley’s latest statements underscore this problem."
“It’s troubling to see confusing and contradictory comments from Ford about something as sensitive as their customers’ location data—just days after the GAO report," he added in a statement.
The GAO surveyed 10 vehicle manufacturers, device companies and app developers for its report.
After the report came out, Franken said that it had encouraged him to reintroduce his location privacy bill from 2012. The Location Privacy Protection Act passed through the Senate Judiciary Committee but never received a floor vote.

Enhanced Differential Loran Maritime Trials in The Netherlands Declared Successful

As reported by Inside GNSSThe Dutch Pilots Corporation and Reelektronika announced today (January 7, 2013) the successful development and test of an Enhanced Differential Loran (eDLoran) backup to GNSS in The Netherlands.  

Trials at sea and in the Rotterdam Europort harbor area met the requirement for absolute accuracies in the five-meter range, according to Durk van Willigen, CEO of Reelektronika, and Wim van Buuren, Loodswezen’s information & communications technology (ICT) and innovation manager and board member.

The cooperating organizations have implemented a complete test system, which includes an eDLoran reference station and the eDLoran receiver for the pilots. This small and lightweight receiver can operate in tandem wirelessly with the standard software of the pilot’s GPS-RTK equipment. Differential eLoran data are available in real-time via the mobile telephone network. No modifications of the existing Loran transmitters was required.
For this joint project, the Dutch Pilots’ Corporation made facilities available on board their pilot station vessel Polaris and for the location of an eDLoran reference station. Reelektronika performed the research on eDLoran, and developed the equipment for the pilots and the low-cost reference station.
The position corrections (Additional Secondary Factors, ASF) database will automatically be expanded and refined by any new trip the pilots make, using GPS-RTK and Loran data they collect during maritime operations.
The effects on eLoran transmissions of any new industrial installations and buildings in the harbor area are thus adaptively incorporated into the database. This nearly continuously upgrading of the eLoran ASF database does not require any special measuring equipment or procedures, according to the organizations.

Tuesday, January 14, 2014

L.A. County's GPS Ankle Bracelets for Criminals Don't Work Very Well

Electronic MonitoringAs reported by the Reporter NewsOne in every four GPS devices used to track serious criminals released in Los Angeles County has proved to be faulty, according to a Probation Department audit — allowing violent felons to roam undetected for days or, in some cases, weeks.  

The problems included batteries that wouldn't hold a charge and defective electronics that generated excessive false alarms. One felon, county officials said, had to have his GPS monitor replaced 11 times over a year; for five days during the 45-day audit period, his whereabouts were unknown.

“If you have faulty technology, that is a recipe for disaster,” said Reaver Bingham, deputy chief of the department.
The findings come as nearly every California county is adopting some form of electronic monitoring to contend with tens of thousands of state inmates being released to their supervision, a result of the effort to reduce prison overcrowding.
Mandated for use on high-risk sex offenders by the 2006 passage of Jessica’s Law, GPS tracking has been promoted by both lawmakers and state law enforcement officials as a safe and cost-effective alternative to prison or jail. However, a Los Angeles Times investigation this year showed that California corrections officials were aware of widespread, serious problems in their program. Citing an “imminent danger” to the public, the state in 2011 replaced the GPS monitors on half of the paroled sex offenders.
menscentraljail.jpgLos Angeles County began depending on electronic monitoring heavily in 2011, putting GPS devices on its highest-risk felons — repeat sex offenders, domestic abusers who had violated restraining orders, and violent gang members.
Typically strapped onto a subject’s ankle, the devices were supposed to collect a location point every minute and send that data to a central computer every 10 minutes. GPS monitors also are designed to alert authorities if wearers tamper with them, try to flee or stray too close to a school or other forbidden area.
By law, Los Angeles County must conduct monthly reviews and yearly evaluations of its program contractor. But, officials said, they did not review Sentinel Offender Services’ work until problems surfaced elsewhere.
In June, Orange County discovered multiple failures in Sentinel’s GPS and home detention systems, prompting the county to cancel its contract. That triggered a Los Angeles County audit.
From Aug. 1 through Sept. 11, Los Angeles County had 23 high-risk sex offenders on GPS monitors, along with 196 felons who had finished their prison terms and been released into the county’s care.
Probation department officials say they do not know how long Sentinel’s devices had been failing, or how many probationers went untracked.
The audit showed that one probationer wore a tracker that Sentinel knew to be faulty for 45 days. Another told investigators that his GPS device had to be replaced four times in the month after he was released from prison. And a Sentinel employee, whose name was redacted from the report, told an auditor that a third felon’s monitor apparently had not worked since the day it was strapped on.
In several cases, probationers were released without GPS devices because the company had run out of working equipment, documents show. In three other instances, Sentinel on its own decided to stop tracking the locations of some offenders — and did not resume monitoring one felon until contacted repeatedly by his probation officer.
Under its contract, Sentinel is required to document each time a device worn by an offender experiences a false alarm or fails to work, as well as record all other interactions with probationers. County investigators checking the system found those records for only three of 139 offenders before July, and no notes on 87 offenders after that date. Those missing files might have alerted county officials earlier to the problems within its GPS program.
In a detailed written response to the audit, sent to the county Nov. 27, Sentinel contended that the majority of the problems were caused by untrained probation officers and felons who had failed to follow directions.
The county employees mistook dead batteries for malfunctioning equipment, the company said; problems also developed when homeless probationers followed “inconsistent” patterns in recharging their trackers, thus shortening the battery life. A probation official noted that a large proportion of those the county tracks by GPS are transients and have uncertain access to electrical outlets.
Sentinel’s chief business development officer, Mark Contestabile, also complained that his firm had “sought direction” from L.A. County on fixing the problems, but had not gotten a response for four months. Even so, he said, the company in late October began holding training sessions for county probation officers, and started replacing all of the GPS devices with newer models.

DoT Disses DoD’s GPS Chops

As reported by GPS WorldThe departing Deputy Secretary of Transportation, John Porcari, wrote a letter in the closing days of 2013 opposing the U.S. Air Force’s announced plans to begin broadcasting Civil Navigation (CNAV) message-populated L2C and L5 signals as early as April 2014. 

Military personnel are incensed over what they see as Porcari’s impugning, when not ignoring, the Air Force 35-year track record of broadcasting the gold standard of global navigation satellite signals — something in which Transportation has zero experience.

Porcari alludes in his December 27 letter to “non-standard engineering tools” and “non-standard operations” that he believes would come into play for early CNAV broadcast. “These have the potential to inject human error, which may result in unacceptable GPS constellation operation.”
What Porcari means by “non-standard” he does not specify, although he confesses to unease as “the ability to monitor these signals, [without which] the system will not know if the L2C and LS signals are within specification. Given these risks, DOT is concerned that the CNAV messages could provide hazardously misleading information, impacting GPS safety-of-life, protection of property, and economic security applications.” The full text of the Porcari letter is available here.
In addition to questioning Air Force 2 SOPS ability to broadcast an accurate, compliant signal containing CNAV, the letter appears to ignore — or be ignorant of — the 17 official U.S. government/military monitoring sites for GPS distributed around the world, not to mention thousands of other monitoring sites run by government agencies such as the Jet Propulsion Laboratory, the National Aeronautics and Space Administration, and the National Geospatial-Intelligence Agency, and by many universities such as Stanford, Ohio State, Cal Tech, Massachusetts Institute of Technology, and many other international institutions around the world. Many of these sites collaborate under the rubric of the International GNSS Service.
Finally, two private corporations monitor and correct all GPS signals both from space and on the ground: John Deere and Trimble Navigation. Both companies run commercial, automated GPS signal monitoring systems that that report any glitch, change, power fluctuation, or anomaly in the navigation message for all GPS signals with an average two-second notification time.
“This letter is so much BS,” fumed one source who wished to remain anonymous, “coming from an agency that is in arrears in its GPS payments to the tune of more than $70 million and has no clue how to represent the global GPS user. GPS is a ubiquitous system, not just a tool for the DOT and the Federal Aviation Administration. GPS needs to implement these signals for all users and as a modernization program that was promised to be in place years ago.”
Porcari is leaving for the private sector.

Monday, January 13, 2014

A Month of Surveillance by GPS Is up to 6,875 Times Cheaper Than Using People

As reported by Business WeekWhen the U.S. Supreme Court said two years ago that hooking a GPS device onto someone’s car to track his movements for a month is unconstitutional, the FBI acknowledged that it had about 3,000 such devices installed around the country. Presumably, the agency would have to go back to trailing these people in unmarked cars. A paper published by two prominent privacy researchers on Thursday in the Yale Law Journal puts some numbers behind the obvious conclusion that doing so would be nearly impossible.

Kevin Bankston, policy director of the New America Foundation’s Open Technology Institute, and Ashkan Soltani, an independent researcher, quantified the per-hour costs of following someone around using various techniques. In order to do the work of those 3,000 GPS devices, the FBI would have to devote every single one of its special agents to surveillance 24 hours a day, and then go out and hire an additional 1,215.
The point of this thought exercise is to solve a question that privacy scholars have been mulling since the Supreme Court said in the 2012 United States v. Jones case that GPS surveillance amounted to a violation of the Fourth Amendment. It’s legal for the police to follow a suspect’s movements in public, but at some point automated surveillance fundamentally changes the equation. A previous Supreme Court ruling has established that putting a beeper on someone’s car, which allows two people to do the work of five people, is legal. You’ve crossed the line once you’ve put a GPS tracker on a car. But where, exactly, is that line?
Bankston and Soltani boil the question down to cost. First, they calculate the per-hour cost of various ways you could track someone’s movement for 28 days. Here are their numbers:
• Assigning a single FBI agent to do it on foot: $50/hr
• Giving that guy a car: $105/hr.
• Having five agents form a “surveillance box” around a suspect: $250/hr
• Giving all those guys cars: $275/hr.
• Giving a single agent a car and attaching a beeper to the suspect’s car: $105/hr
• Using a device called a “stingray” that serves as a simulated cell phone tower, tracking a suspect’s phone: $105/hr
• [Somewhere in here is the line. Ready?]
• Hooking a GPS device into the car’s electrical system: $0.36/hr
• Asking the cell-phone carrier to track his movements: between $0.04/hr and $1.19/hr, depending on the network.
They then come up with an equation that would allow for beeper surveillance, but not GPS surveillance (since that’s what the Supreme Court had ruled.) Here’s their rule of thumb: “If the new tracking technique is an order of magnitude less expensive than the previous technique, the technique violates expectations of privacy and runs afoul of the Fourth Amendment.”
In the future, a judge contemplating whether some new surveillance technology required a warrant could consider this cost equation. The only problem is that GPS tracking seems quaint in the post-Snowden world. Not only does the marginal cost of tracking someone approach zero with mass surveillance, the values are essentially undefined once law enforcement is scanning the population at large, rather than setting a target. Any of the National Security Agency’s surveillance techniques exposed over the last six months would clearly raise the red flag, says Bankston. “Basically, the government has to fish with a pole rather than a net,” he says.

Friday, January 10, 2014

Quad-Constellation Receiver: GPS, GLONASS, Galileo, BeiDou

The implementation changes and first live tests of BeiDou and
Galileo on Teseo-3 GNSS chips developed in 2013 are covered,
bringing it to a four-constellation machine.  By 2020, we expect to
have four global constellations all on the same band, giving us
more than 100 satellites - under clear sky, as many as 30 or 40
simultaneously: Philip G. Mattos and Fabio Pisoni
As reported by GPS World: Multi-constellation GNSS first became widely available in 2010/2011, but only as two constellations, GPS+GLONASS. Although receivers at that time may have supported Galileo, there were no usable satellites. BeiDou was a name only, as without a spec (an interface control document, or ICD), no receivers could be built.

However, the hardware development time of receivers had been effectively shortened: the Galileo ICD had been available for years, BeiDou codes had been reverse-engineered by Grace Gao and colleagues at Stanford, and at the end of 2011 they were confirmed by the so-called test ICD, which allowed signal testing without yet releasing message characteristics or content.

The last weeks of 2012 saw two great leaps forward for GNSS. Galileo IOV3 and 4 started transmitting at the beginning of December, bringing the constellation to four and making positioning possible for about two hours a day. At the end of December, the Chinese issued the BeiDou ICD, allowing the final steps of message decode and ephemeris calculation to be added to systems that had been tracking BeiDou for many months, and thus supporting positioning. The Teseo-2 receiver from STMicroelectronics has been available for some years, so apart from software development, it was just waiting for Galileo satellites; however, for BeiDou it needed hardware support in the form of an additional RF front end. Additionally, while it could support all four constellations, it could not support BeiDou and GPS/Galileo at the same time, as without the BeiDou ICD the spreading codes had to be software-generated and used from a memory-based code generator, thus blocking the GPS/Galileo part of the machine.

The Teseo-3 receiver appeared late in 2013, returning to the optimum single-chip form factor: RF integrated with digital silicon and flash memory in the same package, enabling simultaneous use of BeiDou and GPS/Galileo signals. Multi-constellation in 2012 was GPS+GLONASS, which brought huge benefits in urban canyons with up to 20 visible satellites in an open sky. Now, for two hours a day in Europe while the Galileo IOVs are visible, we can run three constellations, and in the China region, GPS/BeiDou/Galileo is the preferred choice.

This article covers the first tracking of four Galileo satellites on December 4, 2012, first positioning with Galileo, and first positioning with BeiDou in January 2013. It will cover static and road tests of each constellation individually and together as a single positioning solution. Road tests in the United States/Europe will combine GPS/GLONASS/Galileo, while tests in the China region will combine GPS/Galileo/BeiDou. Results will be discussed from a technical point of view, while the market future of multi-constellation hardware will also be considered.

In the 2010–2020 timeframe, GLONASS and BeiDou (1602 MHz FDMA and 1561 MHz respectively) cost extra silicon in both RF and digital hardware, and cause marginal extra jamming vulnerability due to the 50 MHz bandwidth of the front end. The extra silicon also causes extra power consumption.

After 2020, GLONASS is expected to have the L1OC signal operational, CDMA on the GPS/Galileo frequency, and BeiDou is expected both to have expanded worldwide, and also to have the B3 signal fully operational, again on 1575 MHz. At that point we will have four global constellations all on the same band, giving us more than 100 satellites. With a clear sky, the user might expect to see more than 30, sometimes 40, satellites simultaneously.

Besides the performance benefits in terms of urban canyon availability and accuracy, this allows the receiver to be greatly simplified. While code generators will require great flexibility to generate any of the code families at will, the actual signal path will be greatly simplified: just one path in both RF (analog) and baseband (digital) processing, including all the notch filters, derotation, and so on. And this will greatly reduce the power consumption.

Will the market want to take the benefit in power consumption and silicon area, or will it prefer to reuse those resources by becoming dual-frequency, adding also the lower-L-band signals, initially L5/E5, but possibly also L2/L3/L6 ? The current view is that the consumer receiver will go no further than L5/E5, but that the hooks will be built-in to allow the same silicon to be used in professional receivers also, or in L2C implementations to take advantage of the earlier availability of a full constellation of GPS-L2C rather than GPS-L5.

This article presents both technical results of field trials of the quad-constellation receiver, and also the forward looking view of how receivers will grow through multi-frequency and shrink through the growing signal commonalities over this decade.

History

Galileo was put into the ST GPS/GNSS receiver hardware from 2006 to 2008, with a new RF and an FPGA-based baseband under the EU-funded GR-PosTer project. While a production baseband (Cartesio-plus) followed in high volume from 2009, in real life it was still plain GPS due to the absence of Galileo satellites.

The changed characteristics in Galileo that drove hardware upgrades are shown in Figure 1. The binary offset carrier BOC(1,1) modulation stretches the bandwidth, affecting the RF, while both the BOC and the memory codes affect the baseband silicon in the code-generator area.
Figure 1. Changes for Galileo.
Figure 1. Changes for Galileo.

Next was the return to strength of the GLONASS constellation, meaning receivers were actually needed before Galileo. However the different center frequency (1602 MHz), and the multi-channel nature of the FDMA meant more major changes to the hardware. As shown in Figure 2 in orange, a second mixer was added, with second IF path and A/D converter.
Figure 2. Teseo-2 RF hardware changes for GLONASS.
Figure 2. Teseo-2 RF hardware changes for GLONASS.

Figure 3. Teseo-2 and Teseo-3 baseband changes for GLONASS.
Figure 3. Teseo-2 and Teseo-3 baseband changes for GLONASS.

The baseband changes added a second pre-processing chain and configured all the acquisition channels and tracking channels to flexibly select either input chain. Less visible, the code-generators were modified to support 511 chip codes and 511kchips/sec rates.

Teseo-2 appeared with GPS/GLONASS support in 2010, and demonstrated the benefit of GNSS in urban canyons, as shown by the dilution of precision (DOP) plot for central London in Figure 4. The GPS-only receiver (in red) has frequent DOP excursions beyond limits, resulting either in bad accuracy or even interrupted fix availability. In contrast, the GNSS version (in blue) has a DOP generally below 1, with a single maximum of 1.4, and thus 100 percent availability. Tracking 16 satellites, even if many are via non-line-of-sight (NLOS) reflected paths, allows sophisticated elimination of distorted measurements but still continuous, and hence accurate, positioning.
Figure 4. DOP/accuracy benefits of GNSS.
Figure 4. DOP/accuracy benefits of GNSS.

BeiDou

Like Galileo, BeiDou is a story of chapters. Chapter 1 was no ICD, and running on a demo dual-RF architecture as per the schematic shown in Figure 5. Chapter 2 was the same hardware with the test ICD, so all satellites, but still no positioning. Chapter 3 was the full ICD giving positioning in January 2013 (Figure 6), then running on the real Teseo-3 silicon in September 2013, shown in Figure 7.
Figure 5. Demo Teseo-2 dual RF implementation of BeiDou.
Figure 5. Demo Teseo-2 dual RF implementation of BeiDou.

Figure 6. Beidou positioning results.
Figure 6. Beidou positioning results.

Figure 7. Teseo 3 development board.
Figure 7. Teseo 3 development board.

The Teseo-3 has an on-chip RF section capable of GPS, Galileo, GLONASS and BeiDou, so no external RF is needed.

The clear green space around the Teseo-3 chip in the photo and the four mounting holes are for the bolt-down socket used to hold chips during testing, while the chip shown is soldered directly to the board. Figure 8A shows the development board tracking eight BeiDou satellites visible from Taiwan.

However, the silicon is not designed to be single-constellation; it is designed to use all the satellites in the sky. Figure 8b shows another test using GPS and BeiDou satellites simultaneously.
Figure 8A. Beidou.
Figure 8A. Beidou.

Figure 8b. GPS+Beidou.
Figure 8b. GPS+Beidou.

A mobile demo on the Teseo-3 model is shown running GPS plus BeiDou in Figure 9, a road test in Taipei. Satellites (SV) up to 32 are GPS, those over 140 are BeiDou, in the status window shown: total 13 satellites in a high-rise city area, though many are non-LOS.
Figure 9. GPS + Beidou roadtrack in Taipei.
Figure 9. GPS + Beidou roadtrack in Taipei.

Extending the hardware to add BeiDou, which is on 1561 MHz and thus a third center frequency, meant adding another path through the IF stages of the on-chip radio. After the first mixer, GPS is at 4 MHz, and GLONASS at about 30 MHz, but BeiDou is at minus 10 MHz. While the IF strip in general is real, rather than complex (IQ), the output of the mixer and input to the first filter stage is complex, and thus can discriminate between positive frequencies (from the upper sideband) and negative ones (from the lower sideband), and this is normally used to give good image rejection. In the case of BeiDou, the filter input is modified to take the lower sideband, that is, negative frequencies, and a second mixer is not required; the IF filter is tuned to 10 MHz. The new blocks for BeiDou are shown in green in Figure 10. The baseband has no new blocks, but the code generator has been modified to generate the BeiDou codes (and, in fact, made flexible to generate many other code types and lengths). Two forms of Teseo-3 baseband are envisaged, the first being for low-cost, low-current continues to have two input paths, so must choose between GLONASS and BeiDou as required. A future high-end model may have an extra input processing path to allow use of BeiDou and GLONASS simultaneously.
Figure 10. Teseo-3 RF changes for Beidou shown in green.
Figure 10. Teseo-3 RF changes for Beidou shown in green.

Galileo Again

Maintaining the chronological sequence, Galileo gets a second chapter in three steps. In December 2012, it was possible for the first time to track four IOV satellites simultaneously, though not to position due to the absence of valid orbit data. In March 2012, it was possible for the first time to demonstrate live positioning, and this was done using Teseo-2 simultaneously by ESA at ESTEC and STMicro in Naples and Milan, our software development centres.

The demos were repeated in public for the press on July 24, 2013, at Fucino, Italy’s satellite earth station, with ESA/EC using the test user receiver (TUR) from Septentrio, and ST running simultaneous tests at its Italian labs. Figure 11 and Figure 12 show the position results for the data and pilot channels respectively, with independent LMS fixes. In real life, the fixes would be from a Kalman filter, and would be from a combined E1-B/E1-C channel, to take advantage of the better tracking on the pilot.
Figure 11. Galileo positioning, E1-B.
Figure 11. Galileo positioning, E1-B.

Figure 12. Galileo positioning, E1-C.
Figure 12. Galileo positioning, E1-C.

Good accuracy is not expected from Galileo at this stage. The four satellites, while orbited to give good common visibility, do not also give a good DOP; the full set of ground monitoring stations is not yet implemented and cannot be well calibrated with such a small constellation. Finally, the ionospheric correction data is not yet available. Despite these problems, the residuals on the solutions, against a known fixed position for the rooftop antenna, are very respectable, shown in Figure 13.
Figure 13.  Galileo residuals, L1-B.
Figure 13. Galileo residuals, L1-B.

The common mode value is unimportant, representing only an offset in the receiver clock, and 10 meters is about 30 nanoseconds. The accuracy indicator is the spread between satellites, which is very respectable for a code-only receiver without full iono correction, especially around 640 on the TOW scale, where it is less than 2 meters. The rapid and major variation on the green data around t=400 is considered to be multipath, as the roof antenna is not ideally positioned with respect to other machinery and equipment also installed on the roof.

QZSS and GPS-III/L1C

Teseo-2 has supported the legacy (C/A code) signal on QZSS for some time, but Teseo-3 has been upgraded to handle the GPS-III/L1-C signal, waiting for modernized GPS. This signal is already available on the QZSS satellite, allowing tests with real signals. Significant changes were required in the baseband hardware, as the spreading code is a Weill code, whose generation complexity is such that it is generated once when the satellite is selected, then replayed real time from memory. Additionally it is long, in two domains. It is 10230 chips — that is, long to store but also long in time, with a 10-millisecond epoch. On Teseo-3, the legacy C/A code is used to determine code-phase and frequency before handing over to the Weill code for tracking.

Using a long-range crystal ball and looking far into the future, a model of the future Teseo-4 DSP hardware is available, with 64 correlation taps per satellite. Running this on the captured QZSS L1-C signal gives the correlation response shown in Figure 14. Having multiple taps removes all ambiguity from the BOC signal, simultaneously removing data transitions, which can alternatively be pre-stripped using the known pilot secondary code (which on GPS III is 5 dB stronger than the data signal). The resultant plot represents 2,000 epochs, each of 10 milliseconds, plotted in blue, with integrated result for the full 20 seconds shown in the black dashed line. Assuming vehicle dynamics is taken out using carrier Doppler, this allows extremely precise measurement of the code phase, or analysis of any multipath in order to remove it. This RF data was captured on a benign site with a static antenna, so it shows little distortion.
Figure 14. L1-C tracking on QZSS satellite.
Figure 14. L1-C tracking on QZSS satellite.

Figure 15. Dual RF implementation of dual-band front end.
Figure 15. Dual RF implementation of dual-band front end.

The Future

Having already built in extreme flexibility to the code generators to support all known signals and generalized likely future ones, the main step for the future is to support multiple frequencies, starting with adding L5 and/or L2, but as before, ensuring that enough flexibility is built in to allow any rational user/customer choice. It is not viable for us to make silicon for low-volume combinations, nor to divide the overall market over different chips. Thus our mainstream chip must also support the lower volume options.

We cannot, however, impose silicon area or power consumption penalties on the high-volume customer, or he will not buy our product.

Thus, our solution to multi-frequency is to make an RF that can support either band switchably, with the high band integrated on the volume single-chip GNSS. Customers who also need the low band can then add a second RF of identical design externally, connected to the expansion port on the baseband, which has always existed for diagnostic purposes, and was how BeiDou was demonstrated on T2. By being an RF of identical design to the internal one, it incurs no extra design effort, and would probably be produced anyway as a test chip during the development of the integrated single-chip version. Without this approach, the low volume of sales of a dual-band radio, or a low-band radio, would never repay its development costs.

Conclusions

All four constellations have been demonstrated with live satellite signals on Teseo-2, a high-volume production chip for several years, and on Teseo-3 including use in combinations as a single multi-constellation positioning solution. With the advent of Teseo-3, with optimized BeiDou processing and hardware support for GPS-3/L1C, a long-term single-chip solution is offered.

For the future, dual-frequency solutions are in the pipeline, allowing full advantage of carrier phase, and research into moving precise point positioning and real-time kinematic into the automotive market for fields such as advanced driver-assistance systems.

Acknowledgments

Teseo III design and development is supported by the  European Commission HIMALAYA FP-7 project.

This article is based on a technical paper first presented at ION-GNSS+ 2013 in Nashville, Tennessee.

ST GPS products, chipsets and software, baseband and RF are developed by a distributed team in: Bristol, UK (system R&D, software R&D; Milan, Italy (Silicon implementation, algorithm modelling and verification); Naples, Italy (software implementation and validation); Catania, Sicily, Italy (Galileo software, RF design and production); Noida, India (verification and FPGA). The contribution of all these teams is gratefully acknowledged.