We built a new GPS receiver engine
blog.coresemi.io
blog.coresemi.io
Is that a legal requirement or just done on request? I sort of chuckle whenever I hear of limitations like that being put in place as if someone that can construct an ICBM is going to be constrained by the GPS module.
By putting artificial constraints on off-the-shelf GPS technology, it forced bad actors away from off-the-shelf technology and instead forced them to roll their own. This often meant an inferior product with potential compatibility issues and significant development time and costs.
The same thing is done with export controls. It seems silly today but in 2000 they were limiting where a Playstation 2 could be exported because at the time a beowulf cluster of PS2s would have been a powerful super computer for a country like Iran.
\* Missing words...
\\ The next generation of GPS doesn't have Selective Availability, presumably because today there's 3 alternatives to GPS out side of US control.
I believe the US used to make their GPS slightly inaccurate, but this was done on the satellite side.
Please note: my apologies in advance for a comment that may be perceived as pedantic, but I just wanted to further illuminate this statement.
The U.S. regulation, which technically falls under the Export Administration Regulations (Navigation and Avionics), does not exclusively regulate GPS navigation in munitions applications; rather, it serves to regulate any airborne application where the GPS receiver is capable of resolving navigation telemetry at speeds in excess of 600 m/s. This equates to approximately 1,968.5 ft/s, or 1,342.16 MPH.
Given the speed limitation parameter of the aforementioned regulation, this regulation would not only apply to GPS receivers in munitions applications, but it would also apply to GPS receivers that are utilized in fighter aircraft, space vehicles, etc.
ICBMs on the other hand, reportedly go ten times the speed of an F22.
I fail to see what is so hard to believe that an actor _could_ use civilian parts to get military capabilities. Yes, sure the are points about performance and reliability and what not but I can't shake the feeling that at least some of those points are exaggerated or marketing speak and the re is obviously a point where these components are good enough to be dangerous.
GPS is still slightly inaccurate in its publicly available form: there's a second frequency broadcasting an encrypted signal, and with both frequencies you can better account for variations in the ionosphere.
Galileo I believe will shortly be the only system with worldwide coverage and publicly available multiple-frequency broadcast.
Although selective availability has been disabled for a very long time, even before SA was turned off it was easily possible to get a precision measurement by integrating over time as the SA error was pseudo-random. It is also possible to use things like the phase information from the non-civilian 'encrypted' signals to increase accuracy even though the data cannot be decoded. Some survey-grade receivers were doing this even before SA was disabled, and it's pretty standard now in the precision GPS world.
Your understanding of GPS is quite out of date. GPS began adding a second L2C frequency for consumer use 15 years ago, and started ramping it in 2014. They are in fact in the process of adding a third civilian signal called L5. You can get accuracy from the consumer signals <10cm while in motion today with the right receivers and antennas. L5 will make it more robust indoors and give higher accuracy with cheaper antennas.
Galileo is great, but I wouldn't be holding it up as a crown jewel of GNSS. They have had some major missteps and operational issues in the recent past.
For consumer applications, multi-GNSS receivers are really where it's at. Combining GPS + GLONASS + Galileo + BaiDou is not simply an excercise of comparing the resultant positions given by each networ, but actually being able to combine the information to produce a single faster or more reliable measurement. For instance, getting a 3d position from 2 GPS satellites + 2 Galileo satellites when ordinarily you would not even be able to get a 2d position from either network in that situation.
As far as I know, GPS and Galileo have a different timebase. If you don't know the time difference, you can be way off.
Should be pretty exciting when it becomes available. To the extent one can be excited about something that takes 20 years to be delivered.
[1] https://www.gps.gov/systems/gps/modernization/civilsignals/
You also missed discussing L1C, the 4th civilian signal being introduced with GPS III. This will work primarily with L5 to enhance indoor accuracy.
Apparently (that is, according to Wikipedia https://en.wikipedia.org/wiki/Global_Positioning_System#Rest... ) some systems implement the restriction as an "or" but the regs (https://web.archive.org/web/20080916123933/http://www.armsco... item 11 category II) don't require that.
A good example is shock absorbers designed for vehicles heavier than 30 tons. It has all kinds of civilian uses in heavy machinery, but since that's a key tech for armored vehicles, they are also on the munitions list. The same applies for rocket and jet engines above certain parameters, all kinds of space imaging technology, etc, etc.
It’s a bit political than technical that in American English guided rocket weapons are always called “missiles“. Same reason as J in NASA JPL stands for _jet_ though they don’t normally do turbine jets.
So calling non-military rockets as munitions could be, I think, potentially more straightforward.
Bad example. РПГ is "ручной противотанковый гранатомёт", approximately "man-portable anti-tank grenade launcher". Its round, "ПГ-7" is "anti-tank grenade". Rocket-propelled grenade is a backronym.
After all, you don't really need to have an explosive payload: just dropping a heavy enough missile can be devastating.
Since kinetic energy increases with the square of velocity, if you can create a payload that can travel at hypersonic speeds (like a tungsten rod) without burning up then the amount of kinetic energy is in the tens of millions of joules. That's enough to destroy any single target, but doesn't have nearly the same destructive power as a nuke, which releases trillions of joules of energy.
By the way, checkout small kinetic projectiles bombardment https://en.wikipedia.org/wiki/Lazy_Dog_(bomb)
but that’s enough to destroy any single target! Like some bunkers.
I suppose if you made the tungsten rods heavy enough and made made them travel fast enough you could get kinetic energy on par with small nukes, but the problem is it's highly directional (i.e. most of the energy is released underground and absorbed by the earth), unlike a nuke which can release all of its energy at once in an airburst 100 feet above a city.
It would be useful as a PGM in the arsenal, but probably not enough for MAD in an arms race. I could be wrong, though.
There's still some verbiage around commercial products and embargoed countries, but realistically, North Korea and Iran have access to OpenSSL, so it hardly matters.
A CPU switches a hell of a lot faster than either of those, although with much less current.
Would adding a speed restriction in their VHDL that could be trivially bypassed by patching out one line of code satisfy ITAR requirements?
AOSP has this sort of code in it (search for ITAR_SPEED_LIMIT): https://android.googlesource.com/platform/frameworks/base/+/...
I mean there's plenty of prior art with open-source crypto implementations here.
Now, the GCJ-02 is so well reverse engineered it's practically useless, and just introduces bugs in mapping software when different coordinate systems are used.
The technician was prone to a bit of exaggeration, so I'm not 100% sure that this is real, but I'd love to find out more if so.
This is probably the best one: https://patents.google.com/patent/US3165632?oq=%22star+track...
The core technologies are IR filter (to increase contrast) + an optical modulator + a synchronous detector (lock-in amplifier).
There are a bunch of variations (mostly, I think, to avoid patent infringement). The basic idea is to have a sensor offset from the optical axis of a telescope (and revolving around the OA--or, more commonly, to rotate the OA about the sensor). The telescope is focused at infinity.
Then modulate the entire field in various clever ways (to avoid the gradient of the sky brightness from affecting the measurement), and detect the total field brightness with a PMT (nowdays you'd use a CMOS sensor or photodiode).
They typically include a servo to point the telescope OA at the star (conveniently, this also tells you how the star is oriented relative to the body axis of whatever the tracker is mounted on).
That's some kind of flight/operational manual for the astroinertial navigation system (ANS), pretty detailed. Quite amazing that it's been declassified - you can see the link is from the Smithsonian Air and Space Museum. It also discusses details of how missions are loaded and planned with respect to the ANS. It also says that it has planet avoidance information, which gives you some idea of how sensitive it is (obviously the Sun and Moon are avoided).
I've not found any indication of what wavelength was used, but I would imagine the detector is a single infrared photodiode. By blocking visible atmospheric light (scattered), you can see the stars behind. Stars are point sources for all practical purposes, so you can have as large a magnification as you like without resolving them. What that means is if you have an large-aperture telescope, you'll still collect all the light from a star even if your field of view is tiny. Hence why this uses a scanning telescope to sweep around the sky.
Given the technology of the day, it's unlikely they had a multi-pixel detector (maybe a very low res array). So one approach you could use for this is two photodiodes looking slightly apart - by subtracting the signal of one from the other you might be able to correct for local atmospheric light (if the field of view is narrow enough that you don't expect two stars in the same field). Essentially a real-time dark frame. I have no idea how it actually works in practice though. I'm sure nowadays this can be done with a single wide angle camera.
It also seems like it has some strong initial conditions based on e.g. where the aircraft took off as well as references from the onboard IMU, aircraft attitude, etc. And if I read it right, the pilots can also indicate when they've reached waypoints to calibrate the system.
For this application you want as sensitive as you can get, since you want to detect minute differences in background intensity. That points to a big ole photodiode.
Hence why I suggested that they use an off axis sensor to do online dark subtraction. Locally if there was no star, the diodes should give you the same intensity. If a star enters the field of view of one, but not the other, then you have a detection. It's more complicated than that apparently, but the idea is sound.
From the patent it actually looks like they use some kind of optical chopper and a single diode. A chopper is a disc with slits cut out, in the fold of view. If there's a star that doesn't fill the field of view, the chopper will give you a periodic signal as it rotates. If the sky is empty then you'll get roughly the same signal all the way round. (from a quick skim)
Referencing the link from my other comment, the nutator and optical modulator referenced in the patent combine to remove the residual sky background and apply FM modulation to the star aligned with the telescope OA.
By measuring the phase and depth of the FM modulation, you get the angle and distance of offset between the star and OA.
The main difference being that star sights were taken manually, with an instrument and an eyeball, instead of automatically like the SR71.
Of course satellites did and still do use star trackers. The Apollo astronauts took star sights too, presumably for orientation rather than position.
I think all you need is two celestial bodies and local gravity to get a fix on your location.
Also the moon is sometimes visible during the day, and since the topography of the moon stays constant over time that trick will work with the moon (with craters etc) even without a recent picture.
One of the main reasons to practice celestial navigation is to have a backup in case electronic systems fail (all that salt water and all..) So I'm not so sure about using a "digital system"..
for example in pdf: https://processors.wiki.ti.com/images/f/f1/TI_GPS_PPS_Timing...
Jitter can be tracked and filtered in PPS signals. The related parameter, wander, is interesting to me. Phase noise above 10 Hz is jitter. Phase noise below 10 Hz is wander.
Why?
¯\_(ツ)_/¯
Allen variation is the typical metric for wander.
I found this note from Keysight, is this is a good place to start?
http://literature.cdn.keysight.com/litweb/pdf/5988-6254EN.pd...
If you want to become a time-nut, then check out time-nuts[0]. They know their stuff and will be the most valuable resource on topics related to GPS timing: wander, allen deviation, and jitter of various sources (quartz oscillator vs rubidium, etc.)
I will say that the big test and measurement (T&M) players (Keysight, Tektronix, Rhode&Schwartz) have been the main drivers of T&M research. It's a strange field where academic work and commercial interests line up, so all of the academics work for commercial companies. They'll happily share their results and preferred approaches (except for the secret parts) in white papers and app notes. I don't think there is a good centralized repository of such documents, so it may require some hunting. Knowing keywords might be helpful. If you're mainly interested in jitter then hot things to search for are "jitter", "jitter decomposition", "TIE", "wander", and "dual-Dirac" (just off the top of my head, I'm sure the rabbit hole goes deeper if you start digging into more recent work).
I was in T&M for 7 years. I'm not currently but likely will be in the future. This[1] is the bible I learned on. It's $120 new and not too easy to find free (most of the people who would find it interesting can afford it, ie not in curriculum). Most of my learning was through osmosis over the first few years, then I taught myself the rest. I only used the book as a reference after the first year, but I wouldn't say I knew it all until maybe 5 years in (I was a student at the time too). When I flipped through it towards the end of my time I found it was a good teaching source. I suffer from the curse of knowledge, but I think if you have EE chops then this book will make perfect sense and even help build the intuition necessary to be a good test engineer.
The book is all practical T&M techniques for high-speed SERDES, so wander is outside of the scope of the book. There are other bits in the book besides jitter too (lots of tasty stuff on encodings and impedance).
0. http://www.leapsecond.com/time-nuts.htm
1. https://books.google.com/books/about/An_Engineer_s_Guide_to_...
Back in the day when "selective availability" was turned on they added "brown noise" with strong low frequency components that would defeat attempts to use temporal averaging to approve GPS accuracy.
I remember setting a receiver up outside and looking at the tracks go in circles like a spirograph.
As a scientist, open hardware is the best. I'm just not sure whether or not CoreSemi might have put its foot in something bigger than they know.
However, as I look around trying to find something I can just drop into my car and pull the data from (SD card? USB port?) later on, I haven't seen all of the RTK goodness trickle down yet into something relatively brain-dead and simple to use for my rather small case. I am definitely seeing kits and modules, and some stuff built into high-end drones, but it hasn't seemed to make its way down to my level yet and I am a little curious as to why (or if I am just not looking in the right place for the right thing).
Found a local NTRIP caster (within 10 km, lucky I am in range of a public RTK2go one) and the Reach uses the mobile hotspot on my phone to connect to the caster. After a couple seconds to minutes, it settles down to a 10-12 mm accurate fix in lat, lon, alt, and is kinematic so it maintains the accuracy as I am flying the drone around. It records the whole thing internally, or you can have various output modes like standard NMEA over serial, or bluetooth to your phone.
Also, I have used it to record data internally then post-process it for PPK using the county's publically-available RINEX files [2] and Emlid's RTKLIB fork [3].
[1] https://emlid.com/reach/ [2] https://geodesy.noaa.gov/CORS/standard1.shtml [3] https://docs.emlid.com/reach/common/tutorials/gps-post-proce...
Or can you get multi-frequency receivers for that little these days?
For a practical application, let's say you wanted to lay out crops for a small hobby farm. This can make getting your base station set up, because you might not care as much about absolute location, which would require finding a surveyed benchmark. Instead you put your base exactly on the corner of your plot, and after setting up a local grid system you can now exactly layout your farm according to your plan. You simply walk around with the rover unit and can get real time cm accurate "coordinates."
However, GPS signals are essentially just the location of the satellite with a time stamp. There's nothing to prevent the signed signal from being re-broadcast a short time later to mess with location data. The Russians have (allegedly) been doing this in the Black, Baltic, and Berants seas the past few years.