What do you mean by "hardware decoding"? There are custom chips which do the whole GNSS business. So they are doing "hardware decoding", the chip is the hardware.

I'm not aware of how all of them are implemented internally, but my understanding is that the acquisition&tracking of signals usually happens in the digital domain. Can be wrong on that of course.

All of them I am aware of do hardware decoding of the signal and do the linear algebra to find their location in software. Speaking mostly based on the cheap ublox chips and partially open source navspark chips I've dealt with.

The problem is the signal processing part of GPS is quite computationally difficult. I think it was around 10ish years ago it even became possible to do the full real-time decoding on a laptop. At startup, you need to find the GPS signals. This means searching for all 32 possible satellite code patterns across the range of possible Doppler shifts. During testing, this was what took most of the startup (cold start) time. You need roughly 4-6 of them to get a position, so this has to be done in parallel. Once you've found the satellite it takes another 30 seconds to get the satellite position. GPS signals are very slow at 50 bits/sec.

By comparison, actually solving for location is a simple linear algebra problem with 4 unknowns (lat, long, alt, time; but in a more convenient coordinate system). You only do this a few times per second. The hardware does the higher rate signal phase estimation. For example the navspark is a single core SPARC microcontroller running at 100MHz with 200 kB of RAM. That's enough to do 50 solutions per second, though they reduced that to 10 Hz to make space for a user program too.

A ton of work goes into caching strategies to narrow down that initial search space. Modern chips will let you load in exactly which satellites to expect overhead (e.g. based on position and orbit info from cell network). There is a whole other caching strategy based on a approximate "almanac" in the GPS signal for offline devices. With all of that known before the receiver turns on, you can get a solution in a couple seconds.

> It should be a tradeoff of less battery consumption on device, and no need for large storage, at the expense of a lot more bandwidth?

Yes. I believe so.

> Would having to send all the raw samples consume more or less battery than just processing it and sending the result?

Good question. I don't know the answer to that. Maybe someone can chime in?

What would be interesting if you could send a "ping" signal to the tracker and it only start sending samples back then. After all most of the time you don't need to know where the cat is, only when it is "overdue" and the owner starts worrying.

The "chip rate" of GPS L1 C/A (the main one) is 1023 kchips/sec. So you end up with a signal that is over 1 MHz wide to encode 50 bits/sec. Nyquist-Shannon theorem says* you thus need over 1 Msamp/sec (using complex numbers), probably more like 2 Msps because of Doppler, to capture that. GPS is pretty forgiving and 4 bits/sample is plenty (2 bits is usable), but that would still be 1 MB/s of high entropy data. Note the system linked in the parent comment only records in 12 ms bursts. That captures enough info to find position offline, but only if you add in the historical orbit information that normally takes 30 sec to download off of the GPS signal. Streaming 1 MBps of data is doable, but I think would draw much more power than solving on device. Just recording to an SD card is far less.

* The Nyquist-Shannon theorem actually says the converse, but for anything you'll encounter outside the recesses of a math department, it's still the optimal solution.

I'd guess that it would take more energy to send all of the samples to a central server over an IoT network (which are optimized for infrequent, very small messages) than to calculate a position fix locally.

Maybe it might be worth it for a complete "from scratch" GPS fix (where the receiver needs to figure out where it approximately is and needs to re-download the complete GPS almanach and ephemerides), though – I have no idea how short a server-side-decodeable sample actually is!

But since we're talking about a network-connected device anyway, I'd guess that downloading the ephemerides via the IoT connection (single-digit kilobytes) would be much more economical in that case too.

Maybe as an analogy, consider local vs. cloud QR code decoding: If you can manage to send a single, shart photo of the code, the cloud might be better, but since you can't actually be sure when the camera is pointed at the code and not moving, you might need to take a minute-long video, and look for the one non-blurry frame on the cloud.

Edit: Just saw the other comment – apparently we're talking about a short video moreso than a small JPEG :)

And here's an interesting research paper on the topic: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Sending to your phone via the cell network? That will be a lot of battery usage.

Sending to your phone via radio? If the phone is in range you don't need GPS. You can use UWB or an audible beeper to find the cat.

RF part is also power hungry; the chip they use for example uses 15mA during receiving.

I'm surprised you think otherwise.

"Ordinary" antennas are completely passive, just a bit of metal. It's the maths for data recovery and trilateration (not triangulation!) that is processor heavy.