Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Saul,
a doppler shift is, mathematically speaking, nothing more than a
multiplication with a complex sine, so use a multiply block and a signal
source per simulated sattelite.
Now, you might want to update your doppler shift according to a
simulated sattelite’s position. I recommend having a look at PyEphem[1],
which offers you calculational routines for such things, and writing
your own python block[2] to generate the complex sine.
Greetings,
Marcus
[1] PyEphem Home Page — PyEphem home page
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
; go through tutorials 1, 2, 3
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Yes and no: the shifting is done right; however, you should make sure to
use a consistent sampling rate throughout the block.
The USRP sink interprets the samples that come into it as having a
sample rate of 5MS/s, whereas the nominal sampling rate in the signal
sources is set to 2MS/s.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Yes and no. The signal source just uses the information “sampling rate”
to calculate the length of one period in samples. Other than that,
nothing in GNU radio cares about sampling rate - that’s a real world
concept that only applies to real world devices (such as the USRP sink)
but not to the digital signal processing. You should make sure to use
the same nominal sampling rate that you used to generate the files with
the signal in. For example, if you calculated the satellite signal based
on a nominal rate of 1MS/s, and play it back at 5MS/s, everything will
be frequency scaled with a factor of five.
Greetings,
Marcus