gnss-sdr VS gnuradio

You realise you can write software yourself to interpret the signals from GPS satellites? Here's an open-source implementation.

Something I always enjoy pointing out is that GPS signals can be decoded by anybody, the source code is available here. Needless to say, there are references and calculations based on satellites all over it.

If you're interested in running some code, there's [1] which is fairly active, but as I recall is Linux only. There is also [2] which is a Matlab (or Octave) GNSS receiver implementation; quite well documented and informative. It's meant to be a companion to the author's book [3], which itself I found quite concise and approachable.

[1] https://github.com/gnss-sdr/gnss-sdr

They like to pretend it is using towers or balloons or something else, none of them have ever coherently answered it with a viable way this could result in the GPS we can use from the device in our pocket. It also casually expands the circle of people involved in this conspiracy by thousands, to include all developers at Apple and other phone manufacturers that write/maintain the GPS components of their OS as well as contributors to open source projects like GNSS-SDR, an open-source software-defined GNSS receiver.

People also have to write the software to compute your location from these broadcasts, this means basically every company that has produced GPS receivers would have to be in on it. But there's an open source one, surprisingly nobody has raised an issue as to why it contains all this weird code that doesn't make sense if it's not coming from a satellite.

GNSS-SDR

In gr-dtv transmitter examples for Gnuradio, I see some times people use a resampler block before the RF hardware sink. Say our sampling rate is ~9.14Msps which satisfies the Nyquist criterion because our samples are complex numbers.

2.1. Thanks for that tip, I forgot that I was able to check the source code of the WBFM Receive block. As you have said, there are mostly the same. There are some differences between how values are picked. The WBFM Receive block would be a synonym of Quadrature demod => Fir Filter (decimation => Low pass filter) => FM Deemphasis. 2.3. My question there is why 10 and not 20 or 100. I understand that the idea is to reduce the sample rate asap, but what I don't understand is why those values were picked and how can I understand what would be the "correct" or "best" value. 2.4. I'm not fully understanding what you said. If I check the WB FM recieve source code the values that are supplied as the cutoff freq and transition width of the Low pass filter differ from the one of the example. The webfm would apply a sample rate / decimation / 2 - sample rate / decimation / 32 as a cutoff freq and a sample rate / decimation / 32 as a transition transition width. Calculating those values would end up in different that the ones supplied in this second example. Again, is there a rule of thumb to pick these values?.

Gaussian filter is used only on the tx side, so specifying bt in the receiver makes no sense. Take a look at gfsk mod/demod blocks implementation: https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/gfsk.py

GNU Radio

Here's the filter coefficients used for the GNU-Radio interpolator block to get you started. This is a 7th order interpolator (i.e., 8 FIR taps) with very good performance. Each "row" of the array sets the delay in steps of sample_time / 128.

From their README: “open-source software development toolkit that provides signal processing blocks to implement software radios.” https://github.com/gnuradio/gnuradio