Live data from Hacker News

We built a new GPS receiver engine

blog.coresemi.io

61–70 of 122 posts

Re: We built a new GPS receiver engine

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

Re: We built a new GPS receiver engine

#62

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.

Re: We built a new GPS receiver engine

#63
post #47
post #29

Earlier quoted context omitted.

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

Re: We built a new GPS receiver engine

#64
post #11

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)

Re: We built a new GPS receiver engine

#65
post #63
post #47

Earlier quoted context omitted.

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

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

Re: We built a new GPS receiver engine

#66
post #23

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…

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

Re: We built a new GPS receiver engine

#67
post #6

Earlier quoted context omitted.

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.

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 broad…

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

Re: We built a new GPS receiver engine

#68
post #6

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

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.

Re: We built a new GPS receiver engine

#69
post #61

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 exagger…

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

Re: We built a new GPS receiver engine

#70

Earlier quoted context omitted.

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 broad…

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.

Post reply on HN