Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
We built a new GPS receiver engine (coresemi.io)
212 points by jgarzik on May 19, 2020 | hide | past | favorite | 118 comments


This is gonna be the next step after Andrew Holme's 100% DIY receiver: http://www.aholme.co.uk/GPS/Main.htm


Black magic as far as I'm concerned


> Well, how about deliberate dilution of precision or intentionally limiting the speed the GPS chip can be used at?

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.


It seems silly in today's world where anyone can roll a custom SoC and have it spun out by any number of Fabs over the weekend, but 30 years ago custom chips were pipe-dreams for all but the most advanced tech firms. The $2 microcontroller you use to turn your lamp on has more processing power than a desktop computer from the early 80s.

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 thought SA was removed because we discovered ways around it. Specifically differential GPS(tl;dr is that if you have a known point on the ground you can take a measurement there and get the SA offset, this is widely used to compensate for atmospheric error in GPS).


Although WAAS and other similar techniques can be used to improve the accuracy there are many impracticalities of using secondary sources. The reason stated was to encourage civilian uses of the better accuracy. The other federal departments agreed there was more to be gained from civilian use than lost by making the more accurate signal than lost but limiting its use.


Actually, at the time, once other potential user groups saw how beneficial the technology could be for them (airlines, farmers, on and on) these groups threatened to send up their own GPS systems unless the government agreed to enable full accuracy. The government faced with losing control entirely or meeting the demands of industry chose two work with industry as the US legal writ did not extend to space.


SA is illegal (turned off) in 2000 by Bill Clinton.


The speed limit in the US is 1000mph, else it’s a munition.

I believe the US used to make their GPS slightly inaccurate, but this was done on the satellite side.


The speed limit in the US is 1000mph, else it’s a munition.

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.


According to Google, the F22 can do 1500 mph. Looks like civillian GPS is still good as long as you keep it under Mach 1.8 at sea level ;)

ICBMs on the other hand, reportedly go ten times the speed of an F22.


Is is really for missiles. Same reason the ITAR limits for accelerometers and gyros are relatively high (I think like 10g for acceleration). Same again for vibration tolerance. It is a barrier to entry for making a navigation system for missiles.


Neither of which would be using a civilian GPS receiver?


Well, not now they wouldn't.

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.


There's a few other restrictions as well as the 1000mph speed limit, as far as I'm aware.

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.


ITAR regulations restrict GPS for civilian use to a maximum altitude and maximum velocity, but this is solely a software limitation that is increasingly becoming less relevant.

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.


I wonder how combining 2 GPS satellites with 2 Galileo satellites would work in a realtime setting.

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.


GPS is (slowly) adding new signals [1]; L2C a non-encrypted second frequency, and L5, a non-encrypted third frequency

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 don't have to wait for the full fleet to cycle before you can use L2C or L5. L2C is already 15 years into its rollout and is widely available despite still being "pre-operational" due to it not having 100% coverage at all times.

You also missed discussing L1C, the 4th civilian signal being introduced with GPS III. This will work primarily with L5 to enhance indoor accuracy.


It's a bit looser than that -- 1000 mph _and_ above 60,000 ft, while also being unmanned.

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.


I find a bit of humor in imagining NASA rocket launches and atmospheric test vehicles being viewed, in some contexts, as a munition.


Pretty much everything with a potential dual use is classified as munitions, the U.S. Munitions List is quite long and explicit - https://www.ecfr.gov/cgi-bin/text-idx?SID=86008bdffd1fb2e79c...

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.


Russians call everything a rocket anyway. RPG-7 is a rocket, Saturn V is a rocket, Sidewinder is a rocket. They’re not confused about it, they regard all to be in the same category.

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.


> Russians call everything a rocket anyway. RPG-7 is a rocket

Bad example. РПГ is "ручной противотанковый гранатомёт", approximately "man-portable anti-tank grenade launcher". Its round, "ПГ-7" is "anti-tank grenade". Rocket-propelled grenade is a backronym.


Well, both the Atlas and Soyuz (currently used by NASA and Roskosmos) were developed primarily for the U.S. and Soviet militaries as ICBM vehicles, the Space Race was something of a PR operation.

After all, you don't really need to have an explosive payload: just dropping a heavy enough missile can be devastating.


Are you referring to Kinetic Bombardment?[0]

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.

[0] https://en.wikipedia.org/wiki/Kinetic_bombardment


According to the wikipedia article, the tungsten rods in question would be 9 tons and would deliver an explosion equivalent to that of 11.5 tons of TNT. Considering the cost of getting it into orbit, this is only a good idea when the advantages of the delivery method outweigh that cost. The advantages of "rods from God" compared to ICBMS are that they're twice as fast and have different dynamics vs early warning systems or anti-ballistic systems.

By the way, checkout small kinetic projectiles bombardment https://en.wikipedia.org/wiki/Lazy_Dog_(bomb)


Sure, tungsten rods also work. What I meant was something far less sophisticated - "we don't care what specifically is hit, as long as it impacts in the general area." See e.g. the Qassam missiles, or similarly, the North Korean space program (or "space program"?) and Japan.


> That's enough to destroy any single target, but

but that’s enough to destroy any single target! Like some bunkers.


True, but unless you have hundreds of them, I'm not sure if it's useful for MAD (i.e. replacement for nukes).

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.


I thought that limiting the GPS from the top was to complicate making cheap missiles, something that might be used by rogue states or terrorists; for MAD, you probably wouldn't choose COTS equipment.


The majority of rockets that NASA has used throughout history are just modified nuclear missiles.


I'm a software engineer at NASA and it's an annoying fact of life for us every day. There's a huge overlap in the technology, we just have different applications. In fact, a huge percentage of our airplanes are aircraft military aircraft.


Doesn't NASA also work with spy satellites?


I believe "strong" encryption is still viewed as munitions in the US, or at least it used to be.


That's been over for a long time (1996): https://en.wikipedia.org/wiki/Crypto_Wars#PC_era

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.


Another interesting class of dual-use technology are fast power switching elements. And both modern SMPSs and Class D audio amplifiers are worryingly near to what would have to be considered a “munition”.


What are the rules for munitions-class switching power supplies and Class D amps?

A CPU switches a hell of a lot faster than either of those, although with much less current.


It is an unfortunate fact that many scientific endeavors involve technology that can have dual uses.


Starting with a rock. So, essentially, the whole tech tree.


Anything's a munition if you drop it on someone's head from that height and speed.


We always have to get our altitude restrictions removed for various devices for high-altitude balloon flights.


It was required. But that was gotten rid of by the Clinton administration. See https://www.gps.gov/systems/gps/modernization/sa/ .


The thing you're thinking of is true, but there are still speed limits on commercial GPS chips to prevent their use in missile guidance systems. TFA seems to be clearly flouting that law, so, good luck to them.


If you dig into their website, they appear to be based in Singapore and Japan. I've no idea if those countries have similar laws.


They indicate plans to sell hardware on Crowdsupply which is based in the US. Presumably this is going to be FPGA-based which brings up all the fun questions of how ITAR applies to software.

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/+/...


> Presumably this is going to be FPGA-based which brings up all the fun questions of how ITAR applies to software.

I mean there's plenty of prior art with open-source crypto implementations here.


Crypto is its own category in the ITAR, one whose impact decreased over time as events made the restrictions less relevant. Most crypto is now EAR not ITAR, but treated as a special category. I'm not sure the software classification lessons are going to apply.


US law applies worldwide when it comes to this sort of stuff... You can bet if you started producing these chips and selling them to Iran, you would either be arrested and child porn found on your laptop, or have an 'accident'.


Selective Availability was something they did on the satellites (intentionally induce pseudorandom noise into the timing). The regulations on the GPS chips themselves are different.



China also has strict restrictions on GPS data, including requiring purposeful obfuscation of coordinates for their GCJ-02 geodetic datum, for national security purposes. They don't want accurate maps made.


GCJ-02 used to be a secret way to warp maps to make them less useful for military uses.

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.


GCJ-02 might have made things slightly more difficult for India; would it have ever slowed down the US by even a second? I'd be surprised if the country most damaged by that decision in practice wasn't the PRC.


It seems like they did this for SpaceChain, which I had never heard of before. I read their information, taking about combining blockchain-technology and satellites, and I'm still very confused. Other than buzzwords, what is this actual business and why is the blockchain necessary here? dApps in Space? What? Why?


attracting VC suckers of Softbank caliber


Very cool but a far cry from an actually usable open source hardware receiver. Implementing the RF front end is not at all trivial and highly dependent on the manufacturing process, which is probably why they didn't release one. There's also the issue of fabs all requiring NDA's for their PDK's (process development kit), and transistor-level netlists would probably leak some of that information. It would be great to see an open PDK at something like a 65nm or 40nm node which would really allow for open source hardware design.


Mostly off-topic here, but it seems like the best place to get an answer: several years ago in my lab at Georgia Tech, a technician I worked with said he had a friend who invented a device for doing celestial navigation, but that it 1) worked in the daytime somehow and 2) used digital technology so that it was more precise than a sextant / traditional celestial navigation.

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.


It's real. There are some neat patents from the mid-40's through the mid-60's from the usual crowd of aviation companies.

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).


This is the best reference I've found so far on the SR-71 system (the NAS-14V2): https://airandspace.si.edu/webimages/collections/full/NAS-14...

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.


Very cool! Can you expand on the idea that it's just a single IR photodiode? This would get rid of visible atmospheric light, but wouldn't there still be residual IR light from the sun (whatever isn't absorbed by the atmosphere) interfering with collecting the light from stars?


From the sibling comment seems like I had the right idea. The main restriction I was thinking of is what technology was used at the time. The SR 71 used film for imaging, and the CCD array was developed later on and probably wouldn't have enough sensitivity even if there was an early prototype. You'd also need an InGaS(?) detector for SWIR and I'm not sure when they first came out.

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)


Typically the FOV of the telescope is too narrow to see the sun directly, so you only have to worry about scattered light from the atmosphere (hence the IR-pass filter).

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.


They used astro-navigation as far back as the SR71, the "guidance group" system nicknamed R2D2. Cool video of a pilot talking about it here: https://youtu.be/CeBu6mRDaro?t=3180


Not just exotic aircraft! Celestial navigation was used by all kinds of long range aircraft, military and civilian, until the 1960s or so. Early jetliners (including the first models of the 747, for example) had sextant ports in the top of the fuselage; older aircraft might have "astrodomes". There's a continuous line of use from age-of-sail seafarers to jet-age aircraft. I think the military trained with sextants for air navigation until the 1990s, as a backup method for inertial and satellite.

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.


He might have been exaggerating the performance of his friend's "invention", but you can track the sun during the day, stars at night, and possibly other celestial bodies during the day with sensitive enough instruments. If you can calculate the angles between local gravity, the height of the sun, and you know what time it is, there is a lot of location information there, especially if you track changes over time and not just instantaneous.

I think all you need is two celestial bodies and local gravity to get a fix on your location.


Don't forget that the surface of the sun is not perfectly uniform: if you have a recent picture of the surface of the sun and sensitive enough instruments, you can effectively treat it as a "cluster of known celestial objects" (e.g. sunspots, solar flares) half a degree apart from each other.

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 most common celestial navigation methods is through a "noon sight" measuring the angle between the sun at its highest point in the day and the horizon. So that already works in the daytime.

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"..


There's a recent presentation on one from NASA: https://core.ac.uk/download/pdf/286393566.pdf



This is real. It's used a lot in defense applications.


For a drone to be affected by GPS speed limits it would have to be a hypersonic drone.


There are two limits: 60000ft and 1000 knots. Some manufacturers use "AND" between them, others use "OR"[1]. So you can have faster drones if you manage to stay below 60000 ft.

[1] https://ukhas.org.uk/guides:gps_modules


The US got rid of the altitude limit a few years ago, and increased the speed limit to 600 meters/sec (about a 12% increase)


Some manufacturers have imposed lower limits eg some older Garmin handhelds won’t display info at speeds over 90 mph, though they still maintained a fix. I believe it was to stop people using them in light aircraft.


That's probably because Garmin also makes avionics and flight systems, so they just segmented the market.


I have a Garmin GPS watch for jogging, and it worked fine at 700kph during a flight. Really helped my monthly average running speed.


Only if you're military or part of the government in the US, because civilian drones have a 100mph speed limit and a line of sight requirement.


Which is weird, because something traveling at 1000kts at 100ft seems scarier than something doing 1000kts at 60000ft.


Something traveling 1000kts at 60000ft can reach a target at 100ft. The legal guidance has ICBMs in mind.


A super-duper drone?


This is super cool, its nice to see this come out of the idea stage into something one will be able to buy. I find the most use for gps modules is time data, I have one outside my window that is feeding a PPS signal into a server running ntpd. Saves me from bothering internet ntpd servers.


I am curious what timing precision they are achieving. You can easily get ~10 ns with cheapish GNSS modules.


10 ns is the quoted accuracy, but it’s not easy to verify that and it is very easy to mess up something at that timescale. If something is cheap, I’d be willing to bet their PPS output is not going to be 10 ns accurate. Most applications won’t tell the difference between 10 us and 10 ns accurate, but when you need it, you’ll know it.


The jitter can be a really important parameter.

for example in pdf: https://processors.wiki.ti.com/images/f/f1/TI_GPS_PPS_Timing...


My masters thesis is on jitter measurement techniques in 25 Gbps baseband signals :)

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.


Fascinating! Do you know of any good textbooks or application notes that go into jitter measurement techniques?

I found this note from Keysight, is this is a good place to start?

http://literature.cdn.keysight.com/litweb/pdf/5988-6254EN.pd...


That note is interesting, but a bit dense and most of it is standard specific implementation details that aren't too important without first understanding why the standards were written the way they were. That question isn't usually well documented, so a bottom-up understanding of the testing is valuable imo.

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_...


Thanks so much! Time-nuts looks like a gem. I was starting to learn about serdes, so more the reason to check out [1].


I know lots of applications that could take advantage of 10 picosecond accuracy, if only it was feasible without spending hundreds of thousands of dollars.


You can get multiple devices and compare the output. Doesn't give you absolute accuracy of course. But you can set one as "master" and diff to that.


I dunno.

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.


Selective availability is off since almost 2 decades.


That's how long ago it was.


Yes. But what does location accuracy have in common with PPS accuracy besides that you need a fix?


Everything! :D GPS measures the time difference between multiple satellites that broadcast their location and time. You need very accurate timing information to have accurate location. Timing error that manifests itself in PPS would also manifest itself in location data.


Thoughts on how this sort of thing, even though CoreSemi is Singapore/Japan-based, might fall afoul of US ITAR restrictions?

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.


Most commercial/civilian GPS equipment is not controlled under ITAR anymore, the EAR is more relevant here.


Affordable differential GPS would be a nice application... it just requires a fast way of synchronization between two devices (CW in the ISM band would probably work, for example).


RTK gps is better and quite affordable now. Look it up, you can use two receivers costing maybe $15 each for it.


I've just started looking into RTK GPS. My state has a Trimble network that I might use. My application is, weirdly, something a lot like the waypoints of old Garmin GPS handhelds for hikers, only more accurate. I need to be able to lay down a series of points as I drive (perhaps around 30 mph or so) to map out a street network.

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).


Well, $265 (+antenna $60), but I purchased an Emlid Reach M+ [1] for drone RTK experiments, and it has been pretty simple to use... comes with a really nice UI on the device and internal storage in the unit. Also their website has good documentation, which is helpful since there is a lot to learn about how to do RTK.

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...


Surely that little only gets you single-frequency receivers? So you'd be waiting around for 10 minutes to resolve ambiguities every time you got near a tree, bridge or building?

Or can you get multi-frequency receivers for that little these days?


Do you happen to know a good introduction to how one would use it? I've looked at tools around it a few times, but always didn't find the point where it made "click" on how to actually do anything with them.



Thank you!


Take a look at rtklib.com for software and instructions on https://wiki.openstreetmap.org/wiki/RTKLIB. There are quite a few u-blox receivers that work, also receivers from other brands. If you want to try dual frequency for improved accuracy, u-blox launched an affordable dual frequency chip in 2019.


You set up the base station over a known point, and now your rover unit can give you cm level accuracy when it's within range of the base station (UHF radio range generally).

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."


Which receivers?


Do any of these systems offer a way to cryptographically prove that a signal was received at a specific place and time?


I don't think (American) GPS currently supports that for the civilian signals, though IIRC Galileo does and there are plans for the American version to support it in the future.

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.


Don't believe it's yet publicly available for Galileo, but yes, it's meant to be going live soon. (And note that the authenticated stream is a paid for service.)


That's not something you can cryptographically prove, unless you have an extremely loose definition of "cryptographically", like "some computer with an SGX private key said so".


Is that even possible, and what would be a use-case for that?


github links in article don't seem to work, but this does:

https://github.com/CoreSemi?tab=repositories


They messed up the HTML and made two links there: "https://github.com/coresemi/gnss-" incorrectly links to https://github.com/c, while "baseband" correctly links to https://github.com/coresemi/gnss-baseband.


Great, maybe now we'll finally get $10 Chinese RTK modules


FTR, Here is document about design of a Bluetooth GNSS receiver.[0]

[0] https://github.com/lpechacek/u-blox-gnss-receiver




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: