The waveform produced by sounding a note on most physical instruments will often not exhibit a peak, or will not exhibit the strongest peak, on the note being sounded. Rather, most instruments will instead produce harmonic overtones and our brains fill in the gap of the pitch that’s intended to be sounded.
You can still absolutely deduce the fundamental with great accuracy via an FFT, but the approach is a bit more involved. The relevant research area here is called ‘fundamental frequency estimation’.
For an example of this, you can see this app I built that lets you give keyboard and mouse inputs via playing notes on a bass guitar, which are recognized over the microphone: https://github.com/codyd51/offkeyboard
Hi, author of axle here - thank you for the shout out! It’s been a wonderfully fun and enriching project to work on over the years. I’m now working on XNU at Apple, so won’t be working further on axle for the foreseeable future.
One potential hiccup with your one-photino-bird-universe theory (which is quite fun!): I believe I remember a scene in which the ‘birth’ of a photino bird was described. If I remember correctly, it was indeed described as a clone of its parent.
Whoa, thank you! I don't know much about RF and learned ad-hoc for this project, and it seems perfectly plausible to me that someone knowledgeable would be able to look at this and identify a root cause - I certainly didn't do anything special for clock recovery, and based on the name I would have blindly assumed that synchronising the carrier wave _would_ be tantamount to recovering the satellite clock. I haven't researched clock recovery yet, and will do so. Once again, thank you!
Thank you very much for your thoughtful offer! I won't be able to readily work on side projects after starting my new role next week, and am content to consider this project complete for the time being. However, what you've proposed does sound interesting and fun. I'm going to go ahead and shoot an email to the address listed in your profile.
I believe you are correct. My understanding is that the root P key is rotated daily, and needs to be manually uploaded to any military hardware that needs to use it.
Thank you very much! I agree, they are incredible! I really had no idea until making this project, and it makes things like cellular phones so astoundingly impressive.
Thank you for sharing this! It is sort of a vulnerable thing to write, because it reveals the shapes and bounds of my own ignorance, and the path I took to learning. I am really grateful to hear that you appreciated the approach.
I am really grateful for this nice comment, thank you! As a self taught programmer with no background in RF or EE, this project was definitely a stretch for me and involved lots of (sometimes frustrating) learning and experimentation. Looking back, I'm really glad for it, as it feels as though I've unlocked RF as a domain that I now understand a lot more tangibly and can use as a sort of tool. It reminds me of the things I love about computers themselves!
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).
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.
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.
Yes, you're absolutely correct! The design here totally suffers from unbounded memory use if you draw onto a large canvas. (Restating parts of your comment for confirmation that this is also how I think about it.)
To resolve this while maintaining the spirit of the design, I think two representations need to be kept: one for the rendered pixel data, and one 'out of band' representation (such as the textual data - you also highlighted this in your comment).
The idea is that, when the pixel buffer memory gets too large, some of it can be dropped. When it scrolls back into view again, it can be repopulated by the secondary representation. What I don't like about this is how it doesn't feel like it generalises well - you always need to be able to store the secondary representation, and have code to redraw it.
I think the concept you suggested is a really good one: just make sure everything that's drawn is its own 'encapsulated' widget with its own drawing logic, and you can ask it to render itself whenever that's convenient. I'm grateful for the input here, and think I will end up switching to this sort of approach in the future.