[HN Gopher] Building a GPS receiver
___________________________________________________________________
Building a GPS receiver
Author : codyd51
Score : 266 points
Date : 2024-04-15 14:42 UTC (8 hours ago)
(HTM) web link (axleos.com)
(TXT) w3m dump (axleos.com)
| codyd51 wrote:
| Hi everyone!
|
| Shortly after publishing my iOS 4 jailbreak last October[1], I
| got to work on my next hobby project: a from-scratch homebrew GPS
| receiver, which can solve the user's location solely from
| billions of radio antenna samples.
|
| I took a commodity SDR (alongside the Python standard library and
| numpy) and built a signal processing pipeline that can detect and
| track GPS satellites over many minutes, drop and pick up
| satellites as they come in and out of view, and precisely
| determine the user's position and clock inaccuracy.
|
| All told, gypsum can go from a cold start to a fix on the user's
| position, and the precise time, in less than a minute of
| listening to the antenna. I went on a journey of learning how to
| detect and track satellite signals that are literally too quiet
| to hear, and I hope that some of the magic comes through in the
| posts!
|
| After implementing this myself and walking the long road of
| getting it working, I'm left completely stunned by the brilliance
| of GPS, across so many axes. I hope you enjoy the read!
|
| On a more personal note, I'll be starting a new job next week
| which isn't as amenable to publishing side projects, and
| therefore this will be my last publicly-published project for
| some time. I've had great experiences making and sharing projects
| on here, and I'm really grateful for the positive feedback that's
| been shared!
|
| [1]: https://news.ycombinator.com/item?id=37736318
| noman-land wrote:
| Really amazing piece of work. I look forward to digging into
| it. Thanks for sharing.
| michaelt wrote:
| Great project, thanks for posting it!
|
| It just so happens I've got an RTL-SDR, a GPS receiver that
| outputs raw pseudoranges, and a signal splitter that lets me
| put the signal from one antenna into two receivers.
|
| So if you like I can get the pseudoranges out of a commercial
| GPS receiver, and the raw signal from an RTL-SDR at the same
| time, which _might_ help you pinpoint your last bit of location
| inaccuracy.
|
| Would you be interested in that? Or do you consider this
| project complete?
| blobcode wrote:
| A good, decently detailed look at signal processing required. I
| also like https://ciechanow.ski/gps/, which has some fantastic
| visuals to go along with this explanation.
| klabb3 wrote:
| Wow that blog never ceases to amaze me. I was actually thinking
| about it when I read this post, that it's exactly the type of
| post Bartosz could have made. And he had! Those interactive
| graphics are unbeatable.
| AdamJacobMuller wrote:
| Cool article.
|
| Whenever I see "from scratch," I'm always curious to see how from
| scratch the author actually means so I'll admit I was a bit
| disappointed to see that the hardware was just RTL-SDR. Still,
| the protocol decoding was very interesting and the result is
| great.
|
| > GPS was launched in 1978, which was 45 years ago at time of
| writing. Five billion people are currently under 40 years old, so
| well over half the world's population has never existed in an
| environment but this.
|
| A note based on this. While GPS was around since 1978 the signal
| was intentionally degraded with a process known as "selective
| availability" until 2000. This largely rendered GPS unusable for
| many many purposes, definitely useless for road navigation, it
| had some limited utility in areas like backcountry navigation and
| was definitely useful for marine navigation.
|
| > gypsum can go from a cold start to a fix on the user's
| position, and the precise time, in less than a minute of
| listening to the antenna
|
| This is very impressive and outclasses what I see even commercial
| receivers doing today, do you have any idea how? I remember on
| road trips in the early 2000s I would have to sit on the side of
| the road and wait for the GPS receiver to get a fix (a 15-20
| minute process, when it worked) before we could leave. Or, more
| likely, my mother would just start driving with paper maps.
| rollulus wrote:
| Re: from scratch, this one won't disappoint you:
| https://web.archive.org/web/20130111175418/http://www.holmea...
| AdamJacobMuller wrote:
| He didn't make his own FPGA with sand from a beach? Weak.
| (Sarcasm, for those whose detectors are broken)
|
| That's cool, I can understand just enough about what's going
| on there to know I have absolutely no idea what's going on
| for 90% of that article. Excellent to learn from.
| magnat wrote:
| Slightly updated version:
| http://www.aholme.co.uk/GPS/Main.htm
| codyd51 wrote:
| Hi! Yes, "from scratch" is definitely always a bit of a funny
| term. I also implemented the receiver in Python, which is quite
| far from "scratch" =). What I mean by it in this context is
| that I'm taking a piece of hardware that knows nothing about
| GPS, and just has the ability to sample the EM field, and
| building up a receiver from there.
|
| Re. slow TTFF, or time-to-first-(position)-fix on older
| hardware, this essentially stems from advancements in
| processing power.
|
| Traditionally, GPS receivers would need to download the
| 'almanac' of all the satellites, which takes a minimum of 12.5
| minutes (under certain conditions) due to the GPS data
| transmission format and speed. With modern processing power,
| though, receivers (including gypsum) can just 'brute force' the
| search space to find the in-view satellites, instead of using
| the hints downloaded over the air. This is the technique
| described at the end of Part 1.
| Cyph0n wrote:
| As an EE grad, I would still consider what you did to be
| "from scratch". Yes, the RF side is complex, but for the
| purposes of GPS, it is also generic enough to abstract out.
| Nice work.
| tialaramex wrote:
| The fast TTFF on a typical modern device e.g. your phone is
| because the device has the Internet, and so it can obtain all
| the information it needs from the Internet up front, it isn't
| magically brute forcing everything needed, that's not
| practical at all.
|
| The 12.5 minutes includes a rough multi-week almanac which
| you could perhaps brute force given available compute and
| receive capability (original GPS receivers have a single
| channel receiver and minute compute capability) but they more
| importantly include the ephemerides, precise data about
| exactly where the birds are and the atmospheric conditions,
| replaced hourly by a ground station. You can't "brute force"
| these - they're parameters measured by someone with objective
| truth like "I, a massive NASA satellite ground terminal in
| Florida, am definitely not moving, therefore this GPS bird
| #14 is 0.08 metres away from where it should be, I will
| adjust the data for the next hour accordingly".
| aaronax wrote:
| Related: Satellite-based augmentation system (SBAS), of
| which Wide Area Augmentation System (WAAS) is the USA
| implementation.
|
| https://en.wikipedia.org/wiki/GNSS_augmentation
| codyd51 wrote:
| Yes, I forgot to mention downloading the orbital parameters
| over the network! Thanks for mentioning this as well.
|
| In this case, I was meaning to refer to brute-forcing the
| Doppler-shifts and PRN phases of each satellite, not the
| orbital parameters themselves. The project in the OP is
| able to get a position fix in less than a minute because,
| if the subframe timings are convenient, you can retrieve
| the necessary ephemeris parameters from the subframes in
| that span (and down to as little as 18 seconds in ideal
| conditions, if my back-of-the-napkin is right).
| makomk wrote:
| Yeah, the key reason this enables so much faster time to
| first fix is that the precise ephemeris parameters are
| transmitted much more often than the full almanac, but
| only from the satellite they apply to whereas each
| satellite broadcasts the entire almanac covering the
| whole constellation. If I'm understanding the info out
| there correctly, every transmission of the ephemeris data
| comes with only 1/25th of the almanac.
|
| Most decent modern-ish receivers tend to have pretty
| speedy aquisition time without any assistance data. For
| example, the reasonably ancient GPS running watch I use
| can usually get a GPS lock in a couple of minutes from
| cold with no internet access (in a wrist-sized device
| running on battery!), and even the two decade old
| SiRFstarIII chipset is specced to have a sub-minute cold
| start time without assistance and much shorter with -
| though I think that chipset was pretty advanced for the
| time.
| michaelt wrote:
| You don't need to brute force the almanac - why would you?
|
| But it's very much feasible to 'brute force' your initial
| signal lock by searching for all gold codes at a range of
| frequency offsets.
|
| And it doesn't take 12.5 minutes to get the ephemerides -
| the almanac is sent in paginated form which is why it takes
| so long, the ephemerides are sent more often - they repeat
| every 30 seconds, and they're enough for a navigation fix.
|
| Although 30 seconds isn't amazing, so cell phones do use
| their data connection to shortcut that wait.
| tialaramex wrote:
| > You don't need to brute force the almanac - why would
| you?
|
| I have no idea, but the claim was that you get faster fix
| with brute force when I know that's not why it's fast in
| practice.
|
| > But it's very much feasible to 'brute force' your
| initial signal lock by searching for all gold codes at a
| range of frequency offsets.
|
| I hadn't even imagined this constituting "brute force".
| Is my phone using "brute force" to find the WiFi router?
| At some point it's not really "Brute force" it's "There
| are a handful of options, try all of them" and GPS seems
| past that point especially on modern hardware.
|
| This actually reminded me of a (possibly no longer
| extant) design choice in Encrypted Client Hello - we
| don't necessarily know if the encryption was done with
| key F we gave out yesterday afternoon or key G which we
| just began using an hour ago, do we need a way to signal
| that in the connection? No, just try all valid keys. If
| you can't afford to try more than two keys, make sure you
| only roll them slowly so you won't need to.
| error503 wrote:
| > I hadn't even imagined this constituting "brute force".
| Is my phone using "brute force" to find the WiFi router?
| At some point it's not really "Brute force" it's "There
| are a handful of options, try all of them" and GPS seems
| past that point especially on modern hardware.
|
| Your phone only needs to listen to the WiFi router on one
| channel at a time in operation, and the signal parameters
| are well enough defined that they can be scanned quickly.
| A GPS receiver requires at least 4 parallel channels to
| achieve a position solution, and there are up to 32
| possible codes the satellites could be at. Scanning 6
| channels across 32 codes, and then also sweeping phase
| and doppler shift to lock them , just to 'discover' if
| there is a valid signal there takes time, and this is
| what older receivers had to do. Modern receivers tend to
| just 'brute force' this by having an entire receive
| pipeline dedicated to every possible PRN all the time,
| and possibly even correlate multiple doppler shifts
| simultaneously as well, so they effectively have 32 (or
| more) receive channels, despite only ever expecting a
| maximum of 12 birds being visible. The extra channels are
| necessary more or less exclusively to reduce acquisition
| time, so I think it's fair to call them 'brute force'.
| michaelt wrote:
| _> I hadn 't even imagined this constituting "brute
| force". Is my phone using "brute force" to find the WiFi
| router?_
|
| Early receivers were a lot less advanced than modern
| receivers - one of the key functions of the almanac is to
| help receivers _figure out what satellites they can
| expect to see_ - thus greatly reducing the range of gold
| codes and time offsets they have to check.
|
| Unlike wifi, GPS signals are below the noise floor until
| the gold code is applied to despread the signal, and the
| gold code has to be synchronized with the received signal
| to detect it.
|
| The gold codes are pseudorandom and designed to stop
| signals interfering with one another. Unless you know
| which gold code you're looking for, and find its time
| offset (accurate to about 2 chips in 1023) you can't tell
| it apart from noise.
|
| You also don't quite know the frequency you're looking
| for - partly due to the imprecision of the receiver
| clock, partly because GPS satellites move very fast and
| so can have a lot of Doppler shift (depending on where
| they are in the sky relative to the receiver of course)
|
| Back when receivers had more limited physical hardware,
| searching through ~30 different satellites, multiplied by
| ~500 different gold code offsets, multiplied by a few
| different Doppler shifts could be a slow process.
| Especially if you'd found a handful of satellites, so
| some of your receiver channels were tied up with tracking
| leaving you with fewer for searching!
|
| So ignoring the almanac and brute forcing every
| satellite, gold code offset and doppler shift is one of
| the many ways performance has increased since this stuff
| was developed in the late 1970s.
| michaelt wrote:
| _> I 'll admit I was a bit disappointed to see that the
| hardware was just RTL-SDR._
|
| Somewhat surprisingly, if you went back 15-20 years, a lot of
| what the author is doing in software here would have been done
| in hardware.
|
| GPS receivers used to market themselves by the number of
| tracking channels they had, as cheaper receivers might only
| have the hardware needed to track 6-8 satellites while a more
| expensive receiver might track 12.
|
| So this software-defined receiver actually implements quite a
| bit of what would otherwise be hardware. And of course it can
| track every satellite in view.
|
| The software-defined approach has some powerful benefits - for
| example, initial satellite acquisition involves calculating
| cross-correlation between the received signal and various gold
| codes. Being able to do this in the fourier domain lets you
| acquire signals pretty fast!
|
| If you want a hardcore DIY GPS receiver, going right down to
| the transistor level, you'd probably enjoy reading
| https://lea.hamradio.si/~s53mv/navsats/theory.html - an 1990s
| era DIY GPS receiver, complete with hand-drawn schematics,
| hand-drawn PCBs, even a hand-made antenna.
| makomk wrote:
| I think even these days, a lot of what the author is doing
| here is still generally done in hardware for power efficiency
| reasons - it's just that nowadays, the hardware looks a lot
| like the software-defined architecture used here with a
| conversion to digital at the frontend followed by hardware
| accelerators for doing cross-correlation in the fourier
| domain. Actually, this kind of approach of implementing the
| architecture an SDR-based receiver would use as specialised
| hardware seems to be pretty common in general nowadays.
| shrx wrote:
| "If you wish to make an apple pie from scratch, you must first
| invent the universe."
|
| -- Carl Sagan, Cosmos
| progbits wrote:
| I'm actually glad it uses RTL-SDR, I wasn't aware it was good
| enough to get interesting results.
|
| Ever since I've seen the project by Andrew Holme (mentioned in
| sibling comments) years ago it has been on my wish list to
| replicate, but analog/RF signals are dark magic to me.
|
| Now I feel like I can skip the hard RF frontend bit and play
| with the software by using the SDR I already have.
| epcoa wrote:
| > While GPS was around since 1978 the signal was intentionally
| degraded with a process known as "selective availability" until
| 2000. This largely rendered GPS unusable for many many
| purposes, definitely useless for road navigation
|
| https://en.wikipedia.org/wiki/Automotive_navigation_system.
| Moreover, while often not ideal in dense urban
| environments(modern receivers often struggle here anyways), by
| the late 90s differential GPS augmentation was available in
| cars as well, which was available in dense coastal population
| areas like NYC. Old auto nav systems were clunky and with
| overall shitty map data but they weren't "definitely useless"
| due to SA.
|
| EDIT: I'll concede they were pretty bad, but SA was only one
| factor. With today's computing power and higher quality maps
| you could more easily adapt to the SA position error if it were
| an issue as well.
| kube-system wrote:
| The truth here depends on the definition of "useless".
|
| Automotive GPS systems existed pre-2000. So did dead-
| reckoning systems. Did people use them at the time? Some did.
| It was an amazing technology compared to the alternative,
| which was manually navigating a paper map.
|
| But you'd often get errors large enough (50m avg) that it
| wouldn't accurately identify your location on roads close
| enough to provide accurate instructions. If you gave any of
| that tech to someone today to use, they'd think it was
| broken.
| sllabres wrote:
| As example the TravelPilot IDS/1989 first prototype from
| 1983 (see [1] if you want a picture) IIRC the system used a
| compass, a shunt for the heating wire from the rear window
| (it would alter the compass because of its magnetic field)
| and two wheel sensors measuring the rotation of the wheels.
|
| [1] https://www.bosch-
| presse.de/pressportal/de/en/navigation-sys...
| londons_explore wrote:
| > GPS was launched in 1978,
|
| I would like to point out the insanely good design of the GPS
| radio layer (the L1+L2 signals).
|
| Even 46 years on, the radio layer is fully forwards and
| backwards compatible, and a bunch of important metrics like
| time to first fix and user equivalent range errors have both
| improved by factors of 10-1000, with no incompatible change
| needed to the protocol.
|
| The total RF transmit power to provide service to the whole
| earth is less than the electricity consumption of a typical US
| house (far less than 5G or TV or AM/FM radio), and well _below_
| the noise floor. That 's possible due to clever use of stacked
| gold codes.
|
| The design has allowed frequency-sharing with competing systems
| (eg. Galileo) - you don't see mobile phone networks doing that!
|
| The actual signal sent has allowed things like carrier phase
| decoding, due to the locking of the phase between the modulated
| data and the carrier, which in turn gives far better
| pseudoranges and accuracy.
|
| Overall, the designers either had incredible forethought, or
| incredible luck, or some combination of the two.
| myself248 wrote:
| > definitely useless for road navigation
|
| I would disagree strongly with this. I took a roadtrip in 1999
| using a Delorme Earthmate Hyperformance GPS receiver, the
| RS-232 version, plugged into a Toughbook running Delorme Street
| Atlas USA, I believe it was version 6.0.
|
| It provided perfectly usable directions all the way across the
| country. It didn't do lane guidance (which I don't find
| terribly helpful anyway), but some time in advance of every
| turn, it would announce the turn, including the street name.
|
| That version even had voice recognition, so you could say
| things like "are we there yet?" and it would announce the ETA
| to both the next stop and the final destination, along with
| current location. Lots of fun!
|
| 30 meters (typical worst-case CEP under SA) is plenty accurate
| for road navigation in all but the densest areas, and even
| then, just glance at the map. Once you're out on the open road,
| it's brilliant. Rock out to some mp3's until the voice pipes up
| with the next maneuver.
| noman-land wrote:
| I really love how this article is paced in real time from the
| first person as a learning adventure. Even down to the search
| terms used and the inner monologue. This is my absolute favorite
| kind of tutorial because you're not just being taught to fish,
| you're being shown how go about sourcing the parts to built your
| own fishing machinery.
| darkhorn wrote:
| Is it possible to trick phones with a jammer in a large area to
| make it look like all phones are in a specific point on Earth.
| Only with a jammer?
| codyd51 wrote:
| GPS jamming or spoofing on a wide scale is definitely a viable
| attack! As another commenter noted well, making everyone appear
| at _exactly the same_ location would be nigh-impossible,
| though.
|
| GPS receivers will look for the 'strongest' PRN signal in the
| noise, so broadcasting louder than the (incredibly weak!) C/A
| signal is a valid way to jam or spoof GPS. It is, however,
| generally illegal for civilians.
|
| GPS receivers operating with good practice do tend to try to
| mitigate this sort of attack, by (for example) ignoring signals
| with a too-high power level. It's a bit of a cat and mouse
| game, and there are academic papers exploring each side.
|
| Lastly, GPS receivers also need to deal with interference _from
| GPS itself_! If GPS signals bounce off surfaces before reaching
| the receiver, the receiver might see two sets of GPS signals:
| one that arrived directly, and one that was scattered off a
| surface and arrives a bit later. This is called 'multipath
| interference', and part of what goes into making GPS receivers
| work well is mitigating multipath interference.
| pictureofabear wrote:
| Just to be a little clearer, jamming and spoofing are the not
| the same thing. Jamming obfuscates a signal, usually through
| noise. Spoofing impersonates the signal.
| error503 wrote:
| > making everyone appear at exactly the same location would
| be nigh-impossible, though.
|
| I don't think this is actually the case. In a spoofing
| scenario, all of the rogue signals would typically be
| generated by a single terrestrial station. The time of flight
| of all of the generated signals will be the same, so all that
| matters is the position solution reflected in the
| _transmitted_ signals, as the fundamental principle of GPS
| based on TOF is no longer in play. So I 'd think that in a
| typical spoofing scenario, all receivers thinking they're in
| more or less an identical location is what you'd expect.
|
| It might be possible in a borderline case for the receiver to
| receive some spoofed signals and some real signals
| simultaneously, in which case you'd expect weird results, but
| I think you'd definitely see a correlation around the
| position being broadcast by the spoofer.
| Rebelgecko wrote:
| Regular jamming just degrades the signal quality.
|
| You can blast out fake data, but depending on what you mean by
| "large area" and a "point", I don't think what youre suggesting
| is possible. To trick GPS receivers you end up broadcasting
| fake signals from multiple GPS satellites, so receivers in
| different areas will be processing it differently and come up
| with different coordinates.
| darkhorn wrote:
| So does this means that in recent days there wasn't GPS
| jamming but GPS satalites were broadcasting fake signals? In
| south Turkey people were appearing to be in Beirut airport.
|
| Also see this one: https://www.lloydslist.com/LL1148748/War-
| zone-GPS-jamming-se...
| Rebelgecko wrote:
| I'm having a hard time telling from the article - are the
| ships' GPSes actually reporting that they're at the
| airport? Or is the disconnect happening somewhere between
| GPS and AIS (eg they're intentionally transmitting bad
| location data- it's been common-ish in the past for ships
| to do this when doing something naughty (blockade running
| or illegal fishing) and given what's going on in the region
| I can see the value of keeping your location obscure for
| safety
| darkhorn wrote:
| On March 30 a friend of mine messaged me. He wrote me
| that his phone and his wife's phone were appearing to be
| in Beirut airport. But they were at home in Mersin,
| Turkey. On April 2 he wrote me that his phone was showing
| his location as Mersin correctly. During that period this
| map was showing GPS anomalies in Easternn Mediterranean
| Sea https://www.flightradar24.com/data/gps-jamming it
| looks like there is still anomalies.
|
| I think it was due to Israel's some kind of defense
| measure against Iran.
| error503 wrote:
| No, the fact that all of these ships show the same false
| location strongly suggests that they are being spoofed from
| a single terrestrial source; this effect is not practical
| to achieve by modifying the signals transmitted by the
| satellites, even if the US wanted to for some reason.
|
| There's a report on very similar jamming happening during
| the Syria conflict that will hopefully be enlightening as
| the methods and actors are presumably similar
| https://c4ads.org/wp-
| content/uploads/2022/05/AboveUsOnlyStar...
| pictureofabear wrote:
| You are talking about spoofing, not jamming.[1]
|
| This may be theoretically possible but is, in reality,
| practically impossible.
|
| Embedded within the GPS signal is the ephemeris data which,
| among other things, includes each satellite's location in
| space.
|
| Receivers calculate position by calculating the difference
| between the time a signal was received and the time stamp
| encoded in the signal itself.
|
| By analyzing the signals from a minimum of four satellites (one
| for each dimension in time and space), a receiver calculates
| where it is.
|
| To spoof all phones on Earth, you would need to trick each
| receiver individually. Since receivers are passive, they don't
| identify themselves, and there would be no way to target each
| individual receiver, making them think they're somewhere
| they're not.
|
| 1. Jamming is obfuscating a signal, usually by creating a lot
| of noise that makes the real signal hard to find. Spoofing is
| impersonating a signal.
| cromulent wrote:
| https://gpsjam.org/
|
| Not necessarily jamming.
| kube-system wrote:
| It's not really that simple. Most phones these days do not rely
| solely on GPS for location data. Many use a combination of
| WiFi, Bluetooth, dead reckoning, GPS, Galileo, GLONASS, QZSS,
| and BeiDou.
|
| Even if a couple of these signals are degraded, wrong, or
| missing, most phones will come up with a relatively accurate
| location using the remaining data.
| CamperBob2 wrote:
| Anyone manage to get this working with pip in Windows? After
| installing the dependencies: C:\dev\gps\gypsum-
| release>gypsum-cli.py Traceback (most recent call last):
| File "C:\dev\gps\gypsum-release\gypsum-cli.py", line 9, in
| <module> from gypsum.receiver import GpsReceiver
| File "C:\dev\gps\gypsum-release\gypsum\receiver.py", line 20, in
| <module> from gypsum.navigation_message_decoder
| import EmitSubframeEvent File "C:\dev\gps\gypsum-
| release\gypsum\navigation_message_decoder.py", line 8, in
| <module> from gypsum.navigation_message_parser import
| ( File "C:\dev\gps\gypsum-
| release\gypsum\navigation_message_parser.py", line 62
| *bits ^ SyntaxError: invalid syntax
| icegreentea2 wrote:
| I think you need python3.11 for that syntax.
| teknopaul wrote:
| Never fails to amaze me how people discover GPS as adults.
|
| Education has failed if 12 year old don't understand how it
| works.
|
| There are way more than 36 sats, & it's important that there are
| more than just uncles Sam's offering, given its age, flaws and
| deliberate political/military limitations.
|
| Great article, should be part of all kids education.
| mewpmewp2 wrote:
| I didn't understand how a car engine works at 12. Now try
| imagine GPS...
| js2 wrote:
| A documentary which interviews the principals involved in the
| creation of GPS ( _The Lonely Halls Meeting_ ) is on YouTube:
|
| https://youtu.be/Z5N4CqJLAhQ?si=lvaQZv-WG3ab_gEI
| pictureofabear wrote:
| Now do it for the encrypted signal (the P(Y)-code)!
| sizzzzlerz wrote:
| Brilliant! I have no idea what the technical background of the
| author is but for anyone to tease apart the vast, complex,
| details of the GPS universe is a massive feat. Coupled with his
| ability to craft software to both assist his analysis and to
| implement the final solution, he has created a magnificent
| project. I've been studying GPS and worked with it professionally
| for a number of years and I still don't know everything about it.
| I'm looking forward to digging into the code. Kudos to the
| author!
| tylerchr wrote:
| Super impressive. Can't agree more with the author that GPS is a
| stunningly clever engineering achievement.
|
| For those interested in the story of the development of GPS, I
| found "GPS Declassified" by Richard Easton to be an engaging
| retelling.
| d33 wrote:
| While reading Amazon reviews, I learned that they missed the
| contributions by Hedy Lamarr, a very interesting and impressive
| figure:
|
| https://en.wikipedia.org/wiki/Hedy_Lamarr
| pomian wrote:
| a great book to read, much better than you would expect,
| about Hedy Lamarr, is Richard Rhodes book: "Hedy's Folly."
| throw0101c wrote:
| Standford has/had a course that is available online on GPS/GNSS
| and a lot of the nitty-gritty details:
|
| * https://www.youtube.com/playlist?list=PLGvhNIiu1ubyEOJga50LJ...
| amluto wrote:
| > Just one problem: you won't find any SDR on the market that
| will claim to be able to sample a wave oscillating over a billion
| times a second.
|
| This was true, but not any more. You can get truly impressive
| "direct RF sampling" or "direct RF conversion" receivers that are
| more than fast enough for GPS. For example:
|
| Xilinx RFSoc:
| https://www.mouser.com/datasheet/2/903/ds889_zynq_usp_rfsoc_...
|
| A nice National Instruments article:
| https://www.ni.com/en/solutions/aerospace-defense/radar-elec...
|
| And their referenced off-the-shelf hardware:
| https://www.ni.com/en-us/shop/category/flexrio-custom-instru...
|
| One might be forgiven for being a bit puzzled as to why NI thinks
| that direct RF conversion is cost-effective but nonetheless sells
| the device for $30k :) That being said, if I were prototyping a
| system that wanted phase-coherent wideband reception around 3 GHz
| and I had a proper lab and budget, I'd buy a few of these. If I
| were to go to production, I'd either wait for costs of a homemade
| board to come down a bit or see whether a traditional heterodyne
| receiver could do the trick.
|
| Hmm. For military applications, if I were concerned about really
| advanced RF-seeking weapons pointed at me, a direct conversion
| receiver is probably great -- there won't be any leakage of the
| LO that an enemy device could try to detect.
| elevation wrote:
| > there won't be any leakage of the LO that an enemy device
| could try to detect
|
| Why would an LO be more of an issue than your sample clock?
|
| edit: missing word
| amluto wrote:
| I don't know all the details of this kind of technology, but
| I would imagine that one direct RF receiver's sample clock
| looks effectively identical to any other similar receiver's
| sample clock. So if these devices become popular, then a
| military sample clock is indistinguishable from a civilian
| sample clock. In contrast, an LO is rather application-
| specific.
| londons_explore wrote:
| For military use, where you are trying to blend in with
| civilian equipment, either the direct sampling clock, or
| the local oscillator frequency, could be randomly chosen in
| quite a wide range at bootup and still have the device
| work.
|
| In todays world with everything software reconfigurable,
| changing the sampling rate or local oscillator frequency is
| very do-able.
| AnarchismIsCool wrote:
| It's very hard to prevent the LO from leaking into the ADC
| input. Putting the filters in the right places would cause a
| lot of issues for the signal chain so a common workaround is
| trying to null it with a 180 degree out of phase LO signal.
| OmarShehata wrote:
| Amazing! I also had exactly the same experience that led me to
| research this a few years ago, realizing that:
|
| - GPS works even in airplane mode (while on a literal airplane) -
| It works without cell service, or wifi, or anything - The United
| States of America controls the GPS constellation, and they can
| (and have!) turned off GPS off certain regions at will when
| necessary (which has prompted other countries to launch their own
| GNSS constellations) - GPS satellites don't send down a location,
| they only send down time
|
| I think it's a really fun exercise to do this with data you
| receive on your phone. Your phone has a direct link to satellite.
|
| (side note: I recently learned the basic principles of star
| navigation, and while it is a completely different mechanism, it
| also relies very much on keeping accurate time, which I thought
| was a fun symmetry!)
| jeffbee wrote:
| A person would have to have a quite flawed mental model of what
| GPS is to form the belief that it would stop working without
| data service, wouldn't they?
| outworlder wrote:
| Most people have quite flawed mental models of how things
| work.
| nix0n wrote:
| There's a difference between GPS vs A-GPS (Assisted
| GPS)[0][1].
|
| Since A-GPS uses the cell tower to get the list of satellites
| in view, the GPS on some cellphones will keep working when
| cell service is lost but won't start working if cell service
| is unavailable.
|
| I think this means my Samsung doesn't actually have GPS,
| since fallback to unassisted GPS has never worked for me
| (yes, I've tried waiting far longer than 15 minutes).
|
| Maybe you can excuse a mental model that doesn't make the GPS
| vs A-GPS distinction, since A-GPS is often sold as GPS.
|
| [0]https://en.wikipedia.org/wiki/Assisted_GNSS
| [1]https://news.ycombinator.com/item?id=40042686
| AnarchismIsCool wrote:
| Mostly in the same way the average person would assume
| "Hacker News" is anything but a place for SV investment bros
| to hang out and become rabid Libertarians.
|
| Functionally on most devices losing network coverage renders
| GPS useless. I keep telling people to download OsmAnd if they
| want to be able to view maps on a plane or get home from
| their hike outside cell range. Google maps will _try_ to
| cache maps to some degree nowadays but it tends to be very
| flakey and it seems to be very easy to accidentally get it to
| drop its cache when you 're outside cell coverage.
| myself248 wrote:
| One of the interview questions where I work (we do automotive
| electronics) is "Explain how GPS works." It's directly
| relevant to the job, but it's also a neat opportunity to see
| how someone sizes up their audience, manages time and
| assumptions, etc.
|
| All those things are neat, but mostly what I've learned is
| that quite a lot of people, otherwise apparently reasonably
| smart and competent and toting a whole stack of prestigious
| degrees, have ghastly flaws in their mental model of what GPS
| is.
| jeffbee wrote:
| I personally blame the rabid Libertarians that the other
| guy mentioned. Tons of people think that what GPS does is
| sends your location to the Air Force, which is a bit
| backwards (and doesn't pencil out in terms of either energy
| balance for the mobile station or channel capacity for the
| satellites). They think this because that's how people
| casually write about it (the FBI was tracking me over GPS,
| or whatever).
| kube-system wrote:
| > - GPS works even in airplane mode (while on a literal
| airplane) - It works without cell service, or wifi, or anything
|
| Maybe this is a conception that some people have when their
| first experiences of using GPS was on a smartphone?
|
| But my first couple GPS receivers were standalone devices
| without any sort of data connection, so it seems obvious to me
| that GPS doesn't require data.
| duskwuff wrote:
| > GPS satellites don't send down a location, they only send
| down time
|
| The GPS almanac data they transmit is effectively location.
| It's not _literally_ location, but the P code isn 't literally
| time either.
|
| > and they can (and have!) turned off GPS off certain regions
| at will when necessary
|
| As I understand it, those capabilities are no longer present in
| newer (possibly all active?) GPS satellites.
| myself248 wrote:
| What the satellites are sending is effectively THEIR orbit,
| not YOUR location, I think is the point.
| magnat wrote:
| Note that GPS receiver capable (i.e. not artificially limited) of
| providing navigation data while moving 600 m/s or higher used to
| be considered munition by ITAR. The amount of legalese at updated
| ruling [1] is well beyond what I can make sense of, to the point
| I don't even know if it still applies.
|
| While we're at SDRs, ITAR is also responsible for takedown of
| passive radar GNU Radio module made by Kraken RF team.
|
| [1] https://www.space.commerce.gov/itar-controls-on-gps-gnss-
| rec...
| nomel wrote:
| > takedown of passive radar GNU Radio module made by Kraken RF
| team.
|
| https://hackaday.com/2022/11/19/open-source-passive-radar-ta...
| opello wrote:
| I did some brief searching of their Twitter feed and in
| general but couldn't find any update on this. Does anyone
| know the current state of passive radar and KrakenSDR?
|
| [1] https://www.rtl-sdr.com/sdrdue-updated-passive-radar-
| softwar...
|
| Comment thread from 2023-02-10:
|
| > We are attempting to clarify if it is legal for us
| (KrakenRF, a US company that provides a physical SDR product)
| to also provide our own open source software that is made by
| us. As that could be seen as providing a full PR system.
|
| Is the latest I found from them.
| londons_explore wrote:
| The lawyer likely advised not talking about it more
| publicly.
|
| Almost any lawyer won't present the world as black and
| white, but rather in quantities of risk - and even saying
| "we've taken the project down and it wont be coming back"
| is a risk if that attracts attention to your past
| distribution of the software and causes others to mirror it
| from archives.
| Scoundreller wrote:
| > quantities of risk
|
| Even that's asking for a lot.
|
| Qualities of risk is more likely.
| analognoise wrote:
| IIRC everything they took down was in the Git repo history.
| ck2 wrote:
| If you really want to see all the gps-like services out there and
| have android, you must play with the open-source GPStest
|
| https://github.com/barbeau/gpstest
|
| I've been fascinated for years how badly GPS does altitude (mean-
| sea-level)
|
| in the USA they had to build an augmentation system for airplanes
| for altitude (WAAS)
| NovemberWhiskey wrote:
| It's not entirely clear to me from the write-up, but it seems
| some of the problems that the author had with the "tracker" come
| from attempting to do carrier phase synchronization (with the
| Costas loop) before any kind of clock recovery.
| ruuda wrote:
| > Have you ever noticed that your Maps app still works during a
| flight?
|
| I noticed the opposite, it always fails to locate any satellites,
| even when GPS is still turned on in aeroplane mode. I'm not sure
| why.
| error503 wrote:
| You're more or less inside a Faraday cage. I find you'll
| generally get a strong lock just holding your phone near the
| window, though TTFF can be relatively slow compared to normal
| due to the lack of AGPS.
| wglb wrote:
| I've had good luck getting fixed, particularly in window seats
| holding the phone generally close to the window. It takes
| longer than on the ground outside.
| wglb wrote:
| > Have you ever noticed that your Maps app still works during a
| flight?
|
| Yes, and I use that to take pictures of features below my as we
| fly from one place to the other.
|
| If you have a iPhone, when you land, those pictures will be
| associated with the place you were when the photo was shot. This
| enables you to locate those curious features you happen to see.
___________________________________________________________________
(page generated 2024-04-15 23:00 UTC)