3 ms·

> Obviously that trick does not work if you want to know where the animal is live, it can only tell you where it has been once you have processed the data. why

> Obviously that trick does not work if you want to know where the animal is live, it can only tell you where it has been once you have processed the data. why can't you just forward those radio samples back, and process that on the receiver end (your phone), vs processing on device and sending back the location? 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? Would having to send all the raw samples consume more or less battery than just processing it and sending the result?

krisoft 3y ago
> 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.
- dhosek 3y ago
  One of the things I found initially surprising (but less so when I thought about it), was that when I switched from wired headphones to bluetooth, I got longer battery life from my phone. Apparently, there’s less energy involved in sending a radio signal than in driving a speaker.
iracigt 3y ago
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.
lxgr 3y ago
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/2016/02/SenSys147-co-gps.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
lozenge 3y ago
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.

krisoft 3y ago

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

dhosek 3y ago
One of the things I found initially surprising (but less so when I thought about it), was that when I switched from wired headphones to bluetooth, I got longer battery life from my phone. Apparently, there’s less energy involved in sending a radio signal than in driving a speaker.

iracigt 3y ago

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.

lxgr 3y ago

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/2016/02/SenSys147-co-gps.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

lozenge 3y ago

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.