3g blocker signal | signal blocker handy steamer

By Philip Mattos, STMicroelectronics R&D Ltd. A one-chip multiconstellation GNSS receiver, now in volume production, has been tested in severe urban environments to demonstrate the benefits of multiconstellation operation in a consumer receiver. Bringing combined GPS/GLONASS from a few tens of thousands of surveying receivers to many millions of consumer units, starting with satnav personal navigation devices in 2011, followed by OEM car systems and mobile phones, significant shifts the marketplace. The confidence of millions of units in use and on offer should encourage manufacturers of frequency-specific components, such as antennas and SAW filters, to enter volume mode in terms of size and price. One-chip GPS/GLONASS receiver trials in London, Tokyo, and Texas sought to demonstrate that the inclusion of all visible GLONASS satellites in the position solution, in addition to those from GPS, produces much greater availability in urban canyons, and in areas of marginal availability, much greater accuracy. Multi-constellation receivers are needed at the consumer level to make more satellites available in urban canyon environments, where only a partial view of the sky is available and where extreme integrity is required to reject unusable signals, while continuing to operate on other signals deeply degraded by multiple reflection and attenuation. This article briefly outlines the difficulties of integrating a currently non-compatible system (GLONASS), offering an economic solution in the mass market where cost is king, but performance demands in terms of low signal, power consumption, time-to-first-fix, and availability are extreme. While the accuracy achieved is not at survey levels, we deem it sufficient to meet consumer demands even at the worst signal conditions. The aim is to provide improved indoor and urban canyon availability for mass-market GNSS by using all available satellites; in 2011, that requires GLONASS support, as the constellation availability precedes Galileo by around three years. The aim is to overcome the hardware incompatibility issues of GLONASS, that is, its frequency division multiple access (FDMA) signal rather than the code division multiple access format used by GPS, different centre frequency, and different chipping rate, all without adding significantly to the silicon cost of the receiver chipset. This then allows a total satellite constellation of about 50 to be used at present, even before two recently launched Galileo IOV satellites. It is expected that in benign conditions the additional satellites will give little benefit, as availability approaches 100 percent, and accuracy is excellent, with GPS alone. Though dominated by the ionosphere, using seven, eight, or nine satellites in the fix minimises the amount of error that feeds through to the final position. In marginal conditions, where GPS can give a position, but is using 3/4/5 satellites and those are clustered in the narrow visible part of the sky resulting in poor DOP values, the increased number of satellites benefits the accuracy greatly, due to both improved DOP and multipath-error averaging. Limited satellites mean the full multipath errors map into position and are magnified by the DOP. Adding the second constellation means more clear-view satellites for accuracy, more total satellites to minimise the errors, and the errors are less magnified by the geometry due to better DOP. In extreme conditions, where insufficient GPS satellites are seen to give a fix, the additional GLONASS satellites increase the availability to 100 percent (excluding actual tunnels). Availability is a self-enhancing positive feedback loop… if satellites are always tracked, even if rejected on a quality basis by the RAIM/fault detection and exclusion (FDE) algorithms, then they do not need to be reacquired, so become available for use earlier. If position can be maintained, then the code phases for obstructed satellites can continue to be predicted accurately, allowing instant reacquisition after obstruction, and instant use as no code pull-in time is required. Once availability is lost, the reverse applies, as wrong position means worse prediction, longer re-acquisition, and hence again less availability. The extra visible satellites are very significant for the consumer, particularly — as for example with self-assistance where the minimum constellation is five satellites, not three to four — to autonomously establish that all satellites are healthy using receiver-autonomous integrity monitoring (RAIM) methods. Self-assistance has further major benefits for GLONASS, in that no infrastructure is required, so there will be no delay waiting for GLONASS assistance servers to roll out. The GLONASS method of transmitting satellite orbits is also very suitable for the self-assistance algorithm, saving translation into and out of the Kepler format. Significance of Work Previous attempts to characterize the multi-constellation benefits in urban environments have been handicapped by the need to use professional receivers not designed for such signal conditions, and by the need to generate a separate result for each constellation or sacrifice one satellite measurement for clock control. These problems made them unrepresentative of the performance to be expected from the volume consumer device. This new implementation is significant in being a true consumer receiver for high sensitivity, fully integrated both for measurement and for computation. Thus fully realistic trials are reported for the first time. Background The tests were performed on the Teseo-II single chip GNSS receiver (STA-8088). A brief history: our 2009 product Cartesio+ already included GPS/Galileo, and the digital signal processor (DSP) design has been extended to include GLONASS also for Teseo2, the 2010 product. Test results with real signal data through FPGA implementations of the baseband started in late 2009, and with the full product chip in 2010. The architectural design showed that the silicon could be implemented with only small additional silicon area. Changes to the baseband DSP hardware and software were small and were included in the next scheduled upgrade of the chip, Teseo2. The RF chip silicon requires much greater attention, duplicating the intermediate frequency (IF) path and analog-digtal converter (ADC), with additional frequency conversion and a much wider IF filter bandwidth; however, as the RF silicon area is very small in total, even a 30 percent increase here is not a significant percentage increase on the whole chip. As the design is for an integrated single chip system (RF and baseband, from antenna to position, velocity, and timing (PVT) solution), the overall silicon area on a 65-nanometer process is very small. Commercially, it is new to include all three constellations in a single consumer chip. Technically it is new to use a pool of constellation-independent channels for GLONASS, though standard for GPS/Galileo. Achieving this flexibility has also required new techniques to manage differing RF hardware delays, different chipping rates, in addition to the coordinated universal time (UTC) offset and geoid offset problems already well known to the surveying community. It is also very unusual to go direct to a single-chip solution (RF+baseband+CPU) for such a major technology step. The confidence for this step comes from the provenance of the RF and the baseband, the RF being an extension of the STA5630 RF used with Cartesio+, and the baseband being significant but not major modifications of the GPS/Galileo DSP used inside Cartesio+. 5630/Cartesio+ were proven in volume production as separate chips before the single-chip three-constellation chip starts production. The steps forward from the previous generation of hardware are on chip RF, Galileo support, GLONASS support. While Galileo can pass down the existing GPS chain, with appropriate bandwidth changes, additional changes are required for GLONASS: see Figures 1 and 2. Figure 1. RF changes to support GLONASS. Figure 2. Baseband changes to support GLONASS.   In the RF section, the LNA, RF amp, and first mixer are shared by both paths, in order to save external costs and pins for the equipment manufacturer, and also to minimize power consumption. Then the GLONASS signal, now at around 30 MHz, is tapped off into a secondary path shown in brown, mixed down to 8 MHz and fed to a separate ADC and thus to the baseband. In the baseband, an additional pre-conditioning path is provided, again shown in brown, which converts the 8 MHz signal down to baseband, provides anti-jammer notch filters, and reduces the sample rate to the standard 16fo expected by the DSP hardware. The existing acquisition engines and tracking channels can then select whether to take the GPS/Galileo signal, or the GLONASS signal, making the allocation of channels to constellations completely flexible. Less visible but very important to the system performance is the software controlling these hardware resources, first to close tracking loops and take measurements, and secondly the Kalman filter that converts the measurements to the PVT data required by the user. This was all structurally modified to support multiple constellations, rather than simply adding GLONASS, in order that future extensions of the software to other future systems becomes an evolutionary task rather than a major re-write. The software ran on real silicon in 2010, but using signals from either simulator or static roof antennas, where accuracy and availability of GPS alone are so good that there is little room for improvement. In early 2011, prototype satnav hardware using production chips, antennas, and cases became available, making mobile field trials viable. Actual Results Results have already been seen from trials using professional receivers with independent GPS and GLONASS measurements. However, those tests were not representative of the consumer receiver because they are not high sensitivity; because the receivers require enough clean signal to operate a PLL, which is not realistic in a mobile city environment; and because they were creating two separate solutions, thus needing a continuous extra satellite to resolve inter-system time differences. A 2010 simulation of visible satellites in a typical urban canyon of downtown Milan, Italy, produced the results, every minute averaged for a full 24 hours, shown in Table 1. The average number of satellites visible rises from 4.4 with GPS alone, to 7.8 for GPS+GLONASS, with the result that there are then zero no-fix samples. With GPS alone there were 380 no-fix samples, or 26 percent of the time. Table 1. Accuracy and availability of GPS and GPS+GLONASS, averaged over 24 hours. However, availability is not itself sufficient. Having more satellites in the same small piece of sky above the urban canyon may not be sufficient, due to geometric accuracy limitations. To study this, the geometric accuracy represented by the HDOP was also collected, and shows an accuracy 2.5 times better. Previous studies suggested that in the particular cities tested, two to three additional satellites were available, but one of these was wasted on the clock solution. Using the high-sensitivity receiver, we expected four or five extra satellites and none wasted. The actual results far exceeded our expectations. Firstly, many more satellites were seen, as all previous tests and simulations had excluded reflected signals. Having many more signals, the DOP was vastly improved, and the effect of the reflections on accuracy was greatly reduced, both geometrically, and by the ability of the FDE/RAIM algorithms to maintain their stability and down-weight grossly erroneous signals rather than allow them to distort the position. The results presented here are from a fully integrated high-sensitivity receiver optimized to use signals down to very low levels, and to give a solution derived directly from all satellites in view, no matter which constellation. This produces 100 percent availability, and much improved accuracy in the harsh city environment. Availability The use of high-sensitivity receivers, not dependent on phase-locked loops (PLLs) for tracking, produces 100 percent availability in modern cities, even high-rise, due to the reflective nature of modern glass in buildings, even for GPS alone. Thus some other definition of availability is required rather than “four sats available,” such as sats tracked to a certain quality level, resulting in a manageable DOP. Even DOP is difficult to assess, as the Kalman filter gives different weights to each satellite, not considered in the DOP calculation, and also uses historic position and current velocity, in addition to instantaneous measurements, to maintain the accuracy of the fix. Figure 3 shows the availability of tracked satellites in tests in the London City financial district in May 2011. As can be seen, there are generally seven to eight GLONASS satellites and eight to nine GPS satellites, for a total of around 16 satellites. The only period of non-availability was in a true tunnel (Blackfriars Underpass) at around time 156400 seconds. In other urban canyons, around time 158500 and 161300, individual constellations came down to four satellites, but the total never fell below eight. Note this is an old city, mainly stone, so reflections are limited compared with glass/metal buildings. While outside tunnels, availability is 100 percent, this may be limited by DOP or accuracy. As can be seen in Figure 4 on another London test, the GNSS DOP remains below 1, as might be expected with 10–16 satellites, while GPS-only frequently exceeds four, with the effect that any distortions due to reflections and weak signals are greatly magnified, with several excursions over 10. Figure 4. GPS-only versus combined GPS/GLONASS dilution of precision. As the May 2011 tests had not been difficult enough to stress the GPS into requiring GNSS support, a further trial was performed in August 2011. This was in a modern high-rise section of the city, Canary Wharf, shown in Figure 5 on an aerial photograph. In addition to being high-rise, the roads are also very narrow, resulting in very difficult urban canyons. Being a modern section of the city, the buildings are generally reflective glass and metal, rather than stone, testing RAIM and FDE algorithms to the extreme. Figure 5. GPS versus GNSS, London Canary Wharf (click to enlarge.) This resulted in difficulty for the GPS-only solution, shown in green, especially in the covered section of the Docklands station, center-left, lower track. Figure 6 shows the same test data displayed on truth data taken from the ordnance survey vector map data of the roads. Figure 6. GPS versus GNSS, London Canary Wharf, on vector truth (click to enlarge.) The blue GNSS data is then extremely good, especially on the northern (eastbound) part of the loop (UK drives on the left, thus one-way loops are clockwise). Further tests were carried out by ST offices around the world. Figure 7 shows a test in Tokyo, where yellow is the previous generation of chip with no GLONASS, red was Teseo-II with GPS plus GLONASS. Figure 7. Teseo-I (GPS) versus Teseo-II (GNSS) in Tokyo test. Again, here the scenario is not sufficiently challenging to hurt the availability even of GPS alone, but the accuracy is limited. Figure 8 gives some explanation of the accuracy problems, by showing the DOP during the test. It can be seen that Teseo-II DOP was rarely above 2, but the GPS-only version was between 6 and 12 in the difficult northern part of the test, circled for illustration. Figure 8. DOP during Tokyo tests (click to enlarge.) Further Tokyo tests were performed entering the narrower urban canyons in the same test area, shown in Figure 9. Blue is GPS only, red is GPS+GLONASS, and the major improvement is obvious. Figure 9. GPS only (blue) versus GNSS (red), Tokyo. Figure 10 uses the same color scheme to illustrate tests in Dallas, this time with a competitor’s GPS receiver versus Teseo-II configured for GPS+GLONASS, again a huge benefit. Figure 10. GPS only (blue, competitor) versus GNSS (red), Dallas. Other Constellations While Teseo-II hardware supports Galileo, there are no production Galileo satellites available yet (September 2011), so the units in the field do not have Galileo software loaded. However, the Japanese QZSS system has one satellite available, transmitting legacy GPS-compatible signals, SBAS signals, and L1C BOC signals. Teseo-II can process the first two of these, and while SBAS is no benefit in the urban canyon as the problems of reflection and obstruction are local and unmonitored, the purpose of QZSS is to provide a very high-angle satellite, so that it is always available in urban canyons. Figure 11 shows a test in Taipei (Taiwan) using GPS (yellow) versus GPS plus one QZSS satellite in red, with the truth data shown in purple. Figure 11. GPS only (yellow) versus GPS+QZSS(1 sat, red), truth in purple, Taipei (click to enlarge.) Further Work The test environment will be extended to yield quantitative accuracy results for UK tests where we have the vector truth data for the roads. The hardware flexibility will be extended to support Compass and GPS-III (L1-C) signals, in addition to Galileo already supported. Acquisition and tracking of these signals have already been demonstrated using pre-captured off-air samples. In 2010, the Compass spec was not available. Thus the Teseo-II silicon design was oriented to maximum flexibility in terms of different code lengths, such as BOC or BPSK, so that by using software to configure the hardware DSP functions, the greatest chance of compatibility could be achieved. The result was only a marginal success, in that the 1561 MHz frequency of the regional Compass system can only be supported using the flexibility of the voltage-controlled oscillator and PLL, meaning that it cannot be supported at the same time as other constellations. Additionally, the code rate on the regional system is also 2 M chips/second, which is not supported, so is approximated by using alternate chips, producing serious signal loss. So the hooks for Compass are only useful for research and software development, either for a single-constellation system, or using a separate RF front end. The worldwide Compass signal, which is on a GPS/Galileo signal format in both carrier frequency and in code length and rate, will be directly compatible, but is not expected to be fully available until 2020. The city environment testing will be repeated as the Galileo constellation becomes available. With 32 channels, an 11/11/10 split (GPS/Galileo/GLONASS) may be used when all three constellations are full, but for the next few years 14/8/10 satisfies the all-in-view requirements. Conclusions The multi-constellation receiver can include GLONASS FDMA at minimal increased cost, and with its 32 channels tracking up to 22 satellites in a benign environment, even in the harshest city environment sufficient satellites are seen for 100 percent availability and acceptable accuracy. 10–16 satellites were generally seen in the urban canyon tests. The multiplicity of measurements allows RAIM and FDE algorithms to be far more effective in eliminating badly reflected signals, and also minimizes the geometric effects of remaining distortion on the signals retained. Acknowledgments 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); and Noida, India (verification and FPGA). The contribution of all these teams to both product ranges is gratefully acknowledged. Philip Mattos received a master’s degree in electronic engineering from Cambridge University, UK, a master’s in telecoms and computer science from Essex University, and an external Ph.D. for his GPS work from Bristol University. He was appointed a visiting professor at the University of Westminster. Since 1989 he has worked exclusively on GPS implementations and associated RF front ends, currently focusing on system-level integrations of GPS, on the Galileo system, and leading the STMicroelectronics team on L1C and Compass implementation, and the creation of generic hardware to handle future unknown systems.