Hi Michael,
just a heads up – that bug was fixed, and the fix was integrated
into the "maint" branch of GNU Radio [1]. And since Johnathan merged
maint into master yesterday, it's in master, too :)
Best regards,
Marcus
[1] https://github.com/gnuradio/gnuradio/pull/800
On 04/25/2016 04:31 PM, Marcus Müller
wrote:
Hi Michael,
I think I see a bug in gr-uhd there!
So point is that the python code generated by this is (example):
[...]
##################################################
# Blocks
##################################################
self.uhd_usrp_sink_0 = uhd.usrp_sink(
",".join(("", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_sink_0.set_time_source("external", 0)
self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_sink_0.set_samp_rate(4e6)
self.uhd_usrp_sink_0.set_center_freq(1.5e9, 0)
[...]
Now, what GRC generates here means that you first set your time,
then you set your sampling rate – and on B2xx, that might have the
side effect of changing your master clock rate. The MCR is the
speed at which the internal time counter is incremented.
You can avoid that auto-MCR behaviour by explicitely setting the
master clock rate first – could you add "master_clock_rate=30e3"
to your device Address or device Arguments?
Best regards,
Marcus
On 04/25/2016 04:09 PM, Michael
Skaggs wrote:
Hey Marcus,
In GRC, I have a USRP Source block with "Sync" set to
"Unknown PPS" and "Timing Source" set to "External". I
assumed the device would be setting time based on the
external PPS using these parameters. The synchronize(S0) LED
goes solid (after about half a second of recording, maybe
less) and the other LED (S1) is blinking with the PPS.
Thanks,
Michael
|