
Homemade GPS Receiver - elemeno
http://www.holmea.demon.co.uk/GPS/Main.htm#
======
joosters
That page is amazing. I'm astounded that someone can build a GPS receiver from
scratch, not to mention writing the code that interprets the GPS signals. The
difficulty is mind-boggling!

There's some wonderful quotes in the page that just hint at the complexity
involved:

"Originally, by not transforming satellite positions from earth-centred-earth-
fixed (ECEF) to earth-centred-inertial (ECI) coordinates, I was effectively
ignoring Earth's rotation during the 60 to 80 ms that signals were in flight."

"The above solutions were generated without compensating for ionospheric
propagation delays using parameters in page 18 of subframe 4 which should be
applied because this is a single frequency receiver. Ionospheric refraction
increases path lengths between users and satellites."

!

~~~
Luc
This is immensely impressive.

What strikes me is that the math and all the corrections would not be all that
alien to a sextant user from 100 years ago. To determine position using a
sextant you also start with an estimated position and an accurate clock. You
compensate for drift during your measurements, for dip and refraction, you
solve the equations for several celestial bodies etc.

~~~
toufka
Except for one thing. GPS computation is one of the few things we deal with in
daily life that actually requires relativistic compensation to be accurate.
The satellites are moving so quickly (relative to the receiver) and experience
such less gravity, that the rate of time passing for them is measurably
different than the rate of time passing for the receiver. Enough so that if
you did not compensate for the difference in the rate of time-passage you'd
actually be quite off in your location measurement.

Some back-of-the-envelope numbers (and precision calculation) here:
[http://physics.stackexchange.com/questions/1061/why-does-
gps...](http://physics.stackexchange.com/questions/1061/why-does-gps-depend-
on-relativity)

~~~
grguy
And where are those corrections taken into account in this page?

~~~
rwg
Some of the relativistic error (time dilation) is taken care of on the
satellites themselves by tweaking the 10.23 MHz frequency generators to run at
10.22999999543 MHz.

The author actually mentions a third source of relativistic error without
saying it's relativistic error: the Sagnac effect. ("Originally, by not
transforming satellite positions from earth-centred-earth-fixed (ECEF) to
earth-centred-inertial (ECI) coordinates, I was effectively ignoring Earth's
rotation during the 60 to 80 ms that signals were in flight.")

See also:

[http://en.wikipedia.org/wiki/Error_analysis_for_the_Global_P...](http://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System#Special_and_general_relativity)

~~~
Florin_Andrei
The Sagnac skew would still occur in a non-relativistic universe. All that's
needed is a finite speed for light.

However, yes, relativity further complicates it.

~~~
mikeash
It's interesting to consider that GPS as a concept simply wouldn't work at all
if the speed of light were infinite.

~~~
hobbes
I think you'll find a whole lot more wouldn't work if the speed of light were
infinite. Life, for example.

"Were there an infinite value for the speed of light, light itself would not
exist at all."

[http://www.scientificamerican.com/article.cfm?id=why-isnt-
th...](http://www.scientificamerican.com/article.cfm?id=why-isnt-the-speed-of-
lig)

~~~
Florin_Andrei
These paragraphs are very deep, and quite revelatory as to the nature of
relativity and the Universe itself:

 _The speed of light is strange in that it has the same value independent of
the relative velocity between the source and the observer. This fact is an
experimental one that can only make sense if relative motion changes the
relationship between space and time intervals to keep the distance covered by
light per unit time the same for all observers._

 _The fact that space and time must get mixed up to keep the speed of light
constant implies that, in some sense, space and time must be the same, despite
our habit of measuring space in meters and time in seconds. But if time and
space are similar to the extent that they can be converted one into the other,
then one needs some quantity to convert the units--namely, something measured
in meters per second that can be used to multiply seconds of time to get
meters of space. That something, the universal conversion factor, is the speed
of light. The reason that it is limited is simply the fact that a finite
amount of space is equivalent to a finite amount of time._

------
cnvogel
I have to join in to say that this page (which exists since some time, only
has recently be updated) is really impressive, and a very good educational
material for everyone wanting to really understand the workings of GPS.

Nevertheless it's not the only attempt, bug a very good one, at "open source
GPS" projects. There's at least <http://www.gnss-sdr.org/> which is a more
software-centric approach being able to work with different receiver
frontends. And I've just found another FPGA project at
<http://www.witchnav.cz/>.

Naturally the software-only solution will burn a lot of CPU in the
correlators, so I'd expect a software solution to require a multi-GHz machine,
whereas the GPS receiveres with FPGA (such as the one linked to) works easily
on a pretty low-performing Raspberry-Pi.

~~~
Florin_Andrei
There is some sort of international agreement, originally intended to prevent
the use of off-the-shelf GPS components in building cheap missiles. The
agreement prevents all GPS receivers from providing data when their altitude
is higher than some number (10 km I think), and their speed is above some
number (hundreds of km/h IIRC).

Some GPS vendors read the above in terms of an OR function, instead of an AND
function. In other words, their receivers stop functioning above that altitude
no matter what the speed is.

That prevents some off-the-shelf GPS receivers from being used to build
stratospheric balloons, since these things can climb all the way to 30 km
altitude, or more. Other GPS receivers are built on an AND function, and work
well with strato balloons. Sometimes it's a bit tricky to tell if a given
receiver is an AND or an OR.

I assume, if you build a DIY GPS receiver, you can even ignore any such
limitation altogether, right? That might well be illegal where I live, I'm not
sure, and I have no intention to build such a thing anyway. I'm just asking in
principle.

EDIT: This is the COCOM limit:

 _In GPS technology, the phrasing "COCOM Limits" is also used to refer to a
limit placed to GPS tracking devices that should disable tracking when the
device realizes itself to be moving faster than 1,000 knots (1,900 km/h; 1,200
mph) at an altitude higher than 60,000 feet (18,000 m).[2] This was intended
to avoid the use of GPS in intercontinental ballistic missile-like
applications._

<http://en.wikipedia.org/wiki/CoCom>

~~~
cnvogel
You can certainly ignore both limits in your homemade-receivers, but if you
ever want to ride faster than 1900km/h you will have to account for an
increased doppler shift (I hope I'll not help any terrorists by explaining
that ;-) ), and even though I (in the end) realized that this is not as
dramatic as thought at first, just let me write down some calculations:

Doppler shift is the change of the percieved frequency when either source or
receiver move towards another, or away from another. Canonical example: Sound
of a emergency vehicle's horn when passing by.

Normally you never see the satellites ride directly towards you (or away from
you) but the path is pretty orthogonal to your line-of-sight. So you only
account for a fraction of the 14'000 km/h speed of the GPS satellites to cause
frequency shifts of the signal. (Max. example listed on the homepade-GPS page
is ±5 KHz of doppler, which is relatively 3.3×10^−6 of the GPS frequency, even
though the GPS satellite rides at 1.8×10^−5 the speed of light).

If you'd fly with 1900 km/s (1.8×10^−6 of the speed of light) directly towards
the GPS bird, this movement will increase the frequency you receive by
1.8×10^−6 × 1,5 GHz = 2.7 kHz. So please increase your doppler search range
from ±5 KHz to ±8 KHz to be able to successfully steer your homemade cruise
missiles at that the COCOM limit speed, increase more if faster. This will
slow down your time-to-first-fix, obviously.

The other limit of 10km is easier to ignore, though. It would only become
relevant once you can no longer exclude some solutions to the formulae that
lie outside of the GPS satellite's orbit (imagine four coplanar GPS birds used
for calculation). And in practice proabably it's sane to assume a position
that is not wider than 100km from the earth's surface, again, if you don't
plan to ride your DIY receiver to the ISS, or maybe even geostationary orbit.

------
michaelt
Here's another chap who designed his own GPS+GLONASS receiver back around
1992: <http://lea.hamradio.si/~s53mv/navsats/theory.html>

The best bit is that all the diagrams, schematics and PCB layouts are hand-
drawn.

------
mherdeg
Hmm. I don't see any mention of whether this design complies with the COCOM
Limits, an agreement that GPS devices should disable themselves when at an
altitude above 60,000 feet and a speed faster than 1,000 knots.

~~~
raverbashing
Probably not

Which is funny, because to know you're higher/faster than allowed you need to
calculate that from GPS data

In practice, not sure how this is achieved, but for speed this may even be a
limitation of the circuit (for example, if you can't compensate for the
doppler effect at that speed or has to add some other processing - still, the
doppler effect should be small)

1000 knots is still +/- 1.5 Mach (at sea level) so Concorde and fighter jets
should use a special GPS (but this is very fast)

~~~
vonmoltke
> Which is funny, because to know you're higher/faster than allowed you need
> to calculate that from GPS data

Actually, no. All military aircraft have inertial navigation packages that,
among other values, provide altitude above the elipsoid, position, and
velocity vector. When available, these systems are fixed periodically to GPS-
based measurements.

~~~
raverbashing
Yes, but GPS modules can't expect to have this information input into them.
See <http://en.wikipedia.org/wiki/CoCom>

You're right from the point of view of the aircraft/missile, where several
pieces of information are put together (GPS, barometric, inertial, etc) for
navigation purposes.

~~~
vonmoltke
Right, minor brain fart. I was thinking at the systems level, but the
requirement is for the module to cut itself out, not have an external system
do it.

------
kyle_martin1
I'm a software developer gone electrical/computer engineer and this is still a
very high-level overview. You need to understand many advance physics topics
like RF, antennas design, extremely complicated DSP algorithms, hardware
architecture and design for the FPGA, etc. The breadth and deep understanding
of very hard topics is VERY different than most web developers/people on here
that write toy utilities programs then post a link to Github..

------
wglb
Interesting resubmission. Originally submitted >500 days ago, but today's
submission simply put a # at the end of the URL, and thus avoided duplicate
detection.

Not that I mind--this is one of the more awesome articles submitted to HN or
really anywhere.

~~~
js2
Perhaps the resubmission is due to the May 2013 update on the page.

~~~
wglb
Oh, likely, but the duplicate detection is based on URL matching, not on
newness of content. See the other submission at
<https://news.ycombinator.com/item?id=5717674> and note that the referenced
URL does not have the # at the end that this one does.

~~~
jessaustin
How about this one:

<https://news.ycombinator.com/item?id=5699429>

Whatever. I'm glad people are looking at this because it is incredible.

EDIT: I do wonder, however, that the link from _3 days ago_ only has one
point, which is what it had as soon as it was created. Presumably elemeno
appended the "#" before he submitted the link, because if he had just
submitted the link then the 3-day-ago link would have at least two points. Is
automatically adding the hash a thing that people do? Is reposting non-hashed
links from several days before with added hashes a thing that people do?

I guess since this version of the link has been upvoted 201 times, elemeno
actually has provided a valuable service to HN.

~~~
elemeno
The three days ago one didn't come up when I first put the URL in, though the
500+ days ago one did. Quite possibly I was simply lucky in that I posted near
the start of the UK work day, thus making it likely to get noticed by people
in Europe and then the US, also quite possibly there's a bit of extra magic in
how HN deals with dupes and how quickly it forgets about submissions that get
no love.

~~~
jessaustin
Very weird! The really old one didn't come up for me. It came up for you, but
the 3-day-old one didn't. I would speculate that we're seeing the CAP Theorem
in action, except I know I've read that HN is hosted on a single box.

------
raverbashing
This is really amazing

I had no idea it was this complex. Well, in a way it is simpler than I
imagined (since he's using an antenna with an amplifier), and the FI amplifier
is "simpler" as well.

The most interesting parts for me is the demodulation, and the code phrases
search using FFT.

No wonder you need a FPGA to do the heavy lifting.

------
j_m_b
One of the best posts here in days! Posts like this is why I read hacker news!

------
retube
It blows my mind that all that complexity is baked into your smartphone

~~~
wglb
The interesting thing is that smartphones throw cellular tower triangulation
into the mix to speed the fix, so in a sense, they are more complex.

~~~
mikeash
The main thing that speeds the fix is the fact that they download the
satellite positions over the data network. Satellite positions are embedded in
the GPS signal, but they are transmitted very slowly. That is, I believe, the
50bps NAV signal he discusses on that page. It takes about 30 seconds to
download it all over the GPS signal, while it can take <1s to grab it from
your local cell tower. This is also the big reason why "warm starts" of
standalone GPS receivers that have only been off for an hour or two are so
much faster: the position data is good for a few hours, but after that it has
to be downloaded again.

So cell phone GPS receivers have everything needed for standalone GPS, _and_
position assistance from other sources as you mention, _and_ the ability to
load satellite position data from other sources. All this on a chip that
probably costs less than $10 in bulk.

------
felixr
Another great project in the area of DIY GPS is <http://gnss-sdr.org/project>
It implements a GNSS/GPS receiver using software defined radio (SDR). They
also support the RTL2832U based SDR (<http://www.rtlsdr.org/>), which is a
cheap way to get started.

------
hcarvalhoalves
This is one of those times one regrets going to IT instead of EE. I can make
sense of 10% of it.

------
fvox13
Sure, he designed it, but I don't think those nice printed PCBs are
"homemade". I'd be more impressed if it were through-hole construction. Still,
it's pretty cool.

~~~
joezydeco
Doubtful you can get an FPGA of that class in a thru-hole package. The dude
was smart to shop out the PCB instead of spending weeks trying screen and
drill his own.

~~~
throwaway1979
Good point. Any idea what ballpark speed one would need?

~~~
tcas
Speed of the FPGA? FPGAs are given speed grades, but the actual design
dictates the max speed. Different logic sections, depending on pipelining,
size, which pins they are connected to can run at different speeds. You might
have an overall max speed/critical path of say 50mhz, but you might be able to
safely run a small section of the design at 200mhz.

~~~
asynchronous13
But, you can make your calculations massively parallel on an FPGA. So the
clock speed does not compare at all to a typical processor.

