Also of note is Japan's Quasi-Zenith Satellite System[0], which finished placing its 4 satellites in October 2017. These provide GPS coverage from near-vertical angles over Japan at all times, giving accurate location fixes despite Tokyo's deep urban canyons. The geosync orbits designed for this are pretty cool.
Interesting to see they're using molniya orbits but for a very different purpose than the Russian telecom, military comms and broadcast satellites which most commonly use them.
It's not really that different of a purpose. You want at least one satellite visible in the sky, not on the horizon, nearly overhead. A highly elliptical geo tundra orbit gives you that overhead pass that a normal geostationary orbit can't give you. US Satellite radio (like Sirius) uses a tundra orbit with multiple satellites to cover the US and some parts of Canada and Mexico. You get max overhead time over the US with at least one satellite at all times so the connection is always good unless things on the ground interfere. Japan is doing the exact same thing as everyone else here.
As a Tokyo dweller, I'm also quite excited about the QZSS system which has a constellation of 4 satellites one of which is always in a near zenith position and provides a GPS signal even amidst the highest skyscrapers.
The thing is... One satellite isn't enough to get a position fix... You need at least 4 (or 3 if you want a very rough position fix and are happy to assume your altitude = ground level)
So effectively, this QZSS system provides 1 extra satellite over what GPS would normally have visible - which is helpful, but really just an incremental improvement.
QZSS adds one geosynchronous and three tundra orbit satellites so depending on where you are in the city, you could be seeing two or more QZSS satellites. It's not going to replace GPS but its going to help with getting a quicker location solution than not having it.
Something where you have beacons on every major intersection would be a better step for a city to introduce. The beacons would just be sending compatible messages so there is no need for additional hardware. If the roads are straight enough, you could see multiple beacons plus whatever satellite is overhead.
The geometry of those satellites matters a lot, especially when you have tall buildings in the way. Always having one more or less straight overhead is a pretty big improvement.
In a few years many GNSS (Galileo, BeiDou, GLONASS) will update (or complete) their fleet and software, according to the respective schedules. So consumer electronics that can work with all of them will increase location precision and accuracy drastically.
My work involves software testing consumer electronics with GPS and I always find it amusing when the requirement comes up that the devices should not be capable of accurately tracking position when traveling at 1200 mph.
I'm curious if Galileo will still have this limitation as I assume the purpose is not to be able to jerry rig long range missiles.
You are correct that the original intention of this (called the CoCom limit [1]) was to prevent use in ICBMs.
The specific regulation was originally implemented to prevent GPS receivers with that capability to end up in communist countries during the cold war.
However, with the proliferation of small satellites and cubesats the CoCom rules are no longer really enforced. Many commercial GPS receivers still have them, but the regulations are different now.
I would not say the cocom limits aren't enforced, any exportable GPS receiver is required to have the cocom limits and needs a special license to unlock under EAR regulations. This means that anyone building a cubesat and using a commercial receiver has had to specifically get that exception.
You are correct, I did not mean to say that there are no more regulations on export of GPS receivers. Yes you still have to obtain an EAR license for a GPS receiver capable of tracking at > 600 m/s. But the specific CoCom limits are at least relaxed since they specified that the GPS receiver will stop functioning if velocity is > 1000 knots or the altitude is computed to be above 18,000 meters. The latter part was restricting operation of high altitude balloons which is why I believe there is only a restriction on the velocity and not altitude now.
Sorry for the mixed units, but that is the actual wording from original CoCom, for reference:
600 m/s = 1342 mph
1000 knots = 1150 mph
>The latter part was restricting operation of high altitude balloons which is why I believe there is only a restriction on the velocity and not altitude now.
A group of friends and I did a ~90,000' balloon launch on the "cheap". We used a consumer handheld GPS unit that reported it's location every 10 minutes to a server we could keep an eye on. We suffered through the issue of altitude limitations as well, but it was still better than nothing. Learned a lot of stuff from that project. A big take away was using a mobile version of Google Maps when using Lat/Long coordinates is not very accurate, as it seemed to always want to put the location close to a road. When using the same coords in the desktop version of Google Maps satellite view, the Maps' pin dropped to within 3 feet of where the payload had landed. Using the mobile version, we wandered around in the wilderness for an embarrassingly long amount of time before I got fed up with it and though there must be a better way. Using the desktop location, we were able too pretty much walk up directly to the payload.
The units used around GPS has always been interesting to me. I once received an email from you a vendor of a commercial GPS unit informing us of a bug "above Mach 15". For a scenario that pretty much only happens in space, talking about Mach 15 seemed very bizarre.
The bug ended up being that they stored Doppler shift information in a signed 16-bit integer, which is fine on Earth but breaks in orbit.
Even when there were altitude and speed limits, I think CoCOm said only said it needed to be implemented as an "and" (e.g. too high and too fast), although many manufacturers implemented it as an "or" (too high or too fast).
If I understand correctly, GPS receivers are also (loosely) constrained by the Missile Technology Control Regime, a voluntary agreement between several countries not to export certain technologies applicable to missiles or UAVs.
Slightly off topic, but is there any research going on regarding how to manage all the satellites being pushed into orbit? What happens when these things start to collide with other satellites or other trash accumulating in orbit? Is there a practical limit to what we can throw up into orbit before we start to see some adverse consequences?
It's more regulation than research. The idea of a Kessler cascade (where debris collides with a satellite, causing more debris, causing more collisions) is well known, and there is a lot of work to avoid it.
This means everything from eliminating things that might be jettisoned from rockets (like the despin weights on the upper stage of the Delta II), to deorbiting rocket boosters, to designing stages and satellites to fail safely without causing debris.
One of the more interesting things is the design for SpaceX's new Starlink satellites, which will be in a low enough orbit that they will deorbit within a few years if one fails. (If not, they can boost themselves into higher orbits.)
The other thing that helps is that there are only 43,864 objects large enough to track ever launched, and Only about 18,000 of them are still up there. While that seems like alot, that's the number of people at a baseball game, spread out over an area larger than the surface of the earth. (And even larger in volume.)
The Kessler syndrome is not a concern for geo orbits for a couple of reasons. One is that there is so much more space in geo orbits that the odds of collision are even more rare. The other is that everything in Geo is more or less moving at the same speed in the same direction. Unlike LEO you don't have satellites flying with intersecting orbits.
So, I worked for six months as a subcontractor on the Raytheon GPS OCX project, but only the unclassified stuff.
We helped them take their datacenter deployments from a matter of months to a matter of hours -- using Chef. Once it's all powered and racked and stacked, we got the base OS plus the core apps and their configurations deployed very quickly. Towards the very end of the time I was there, we did a demo on a virtual datacenter that literally took just about three hours to execute from start to finish.
Definitely one of the projects that I am proudest of working on.
One of the things I heard many times while I was in Colorado was that the Lockheed guys got the easy job -- all they had to do was design and launch new birds.
The Raytheon guys said that they had gotten the hard job, because they had to handle all ground control operations for the current fleet of satellites, plus all the ground control operations for the new fleet of satellites.
And the Raytheon guys were pretty proud of that fact.
> But some of their most highly touted features will not be fully available until 2022 or later because of problems in a companion program to develop a new ground control system for the satellites, government auditors said.
1. Adds a new directional 'spot beam' that can provide a 20dB signal boost (100x power boost) in a target region several hundred kilometres in diameter.
2. A new(-ish) military signal, the 'M Code', which is present on some but not all satellites from Block II. It has a number of features including [1]:
* Secretive design.
* Much wider bandwidth than civilian C/A code, meaning wideband jamming needs more energy.
* Power distribution different to the civilian C/A code, and unlike the older P(Y) code doesn't need the receiver to acquire the C/A code first, so less impacted if someone jams the civilian C/A code.
* A more modern spread-spectrum design (from 2000 rather than 1973) that provides better noise immunity and forward error correction, and hence better jamming immunity.
* The parts of the spread-spectrum design that rely on the transmitter and receiver having a common source of pseudorandom data use more modern cryptography.
GPS signals are sufficiently low frequency that a phased array would need to be fairly large. Each antenna in the array would need to be around 5cm and you'd need quite a few of them on each axis. Totally doable but someone probably decided a dish was easier/cheaper than a big board of antennas or waveguides and associated circuitry. Phased array would be nice to have though, since if the array was large enough you could have multiple beams produced by different parts of the array and cover more/multiple areas.
The new block of GPS satellites contain a new acquisition code called M-code. It is an encrypted code from the GPS satellites that allows military receivers to still be able to perform positioning if the regular coarse acquisition (C/A) code (what we all use) is being jammed.
In the current GPS setup there is already an encrypted code (called P-code) but it often requires the GPS receiver first acquiring on the C/A code before being able to track solely on the P code. By contrast, military GPS receivers will be able to lock directly on to the M-code without any coarse acquisition.
Just broadcasting a similarly strong signal won't jam GPS family transmissions. This is because the transmission is based on a pseudorandom bit sequence. It looks like noise unless you also know what the pseudorandom sequence should be. If you do you can pick this out from any not related signal trying to jam it, until the jammers pour in so much more power that it overwhelms your receiver.
The new birds know a pseudorandom sequence that was state of the art ten years ago rather than forty years ago (times approximate). This is a shared key system. If you either break the system or know the key, you get position data or can effectively jam it. You can put several transmissions on the same bird, and give away some of the keys, voila you're a public service. Keep one or more for your military and they've got position information that can't be jammed.
Anything can be jammed, you just need enough power. Having a secret spread spectrum code helps. It's the same principle but easier to understand in the frequency hopping case. In that case, suppose you want as much jamming power as signal power, you have to spread it out across the whole band because you don't know where the next frequency hop is going to be. So if say the system uses 1/100 of the available bandwidth at any one time, now the jammer needs to be 100x as powerful to jam the whole band with the same power as the jammed system. Still, the satellite puts out a low power signal from thousands of miles away, so the jammer starts with an advantage.
Where the new block iii satellites will improve this is with a spot beam that can be directed at a particular area on earth where the jamming is expected, and locally get about 100x the power. I suspect that you'll see more directional antennas and phased arrays applied to GPS receivers as well, since the angular direction to the satellite is known, and it's difficult to put the jammer right in the path of between the receiver and the satellite.
How many satellites will be needed to be operational? What’s chips are comparable with the new bands? I know that there is currently only one phone with the Motorola chip, the Huawei P20 Pro.
How long until the satellite launches will it be operational after the tests? I couldn’t seem to find any of this information anywhere. Just basic press releases.
The only new signal (which I think isn't actually on a new band, it uses the same frequency as an existing signal) won't be online until 2020something when the new ground station software is ready. It may be a while before cell phones ship with chips that actually use the new signal. The L5 signal has been broadcast since 2010 and I think it took until this year for the first phones to ship with support for it.
Untrue. There's a newer format for NAV data -- CNAV. It's currently broadcast on the L2 and L5 bands, and does indeed include a larger week number field -- 13 bits to be exact.
[0] https://en.wikipedia.org/wiki/Quasi-Zenith_Satellite_System