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 >> >> On Fri, Apr 22, 2016 at 11:56 AM, Marcus Müller >> <[email protected] <mailto:[email protected]>> wrote: >> >> Are you sure you're setting the device time correctly? 2.5ms >> offset is definitely much much worse than what to devices that >> should have the same device time should exhibit. So: >> How are you setting the device time? >> >> Best regards, >> Marcus >> >> >> On 04/21/2016 08:59 PM, Michael Skaggs wrote: >>> Aha! You were correct. I was parsing the header incorrectly. >>> However, even after parsing, and the more accurate values (now >>> accurate to 10e-6), it appears the recorded RF data sets are >>> still are offset from each other by an amount of nearly 2.5e-3 >>> seconds. Any idea why this would be? It's strange, especially >>> considering that the are synchronized to the same PPS, and I >>> think the time is with reference to the pulse. >>> >>> Michael >>> >>> On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech >>> <[email protected]> wrote: >>> >>> On 04/21/2016 11:41 AM, Michael Skaggs wrote: >>> >>> I'm trying to time/sample synchronize RF recordings with >>> two B200minis. I am using the detached Metadata File >>> Sink in GRC. Both recordings are at 30MSps and both >>> B200mini boards are synchronized to the same 1PPS signal. >>> >>> My issue is this, when I extract the data from the >>> Metadata header file, the "rx_time" value is only >>> accurate to 10e-4 seconds (0.0001s). Which, with a >>> recording at 30MSps, this will only give me a sample >>> alignment accuracy to 10e-4(s)*30(MS/s) = 30,000 samples. >>> >>> If I'm attempting to align the two recordings by samples >>> or time, this is not nearly accurate enough. Is there a >>> way that I can get more accuracy out of my metadata >>> header or a way that I can synchronize the recordings of >>> these B200minis? >>> >>> Thanks, >>> Michael >>> >>> The precision of the timestamps from UHD should have a >>> precision of whatever the master-clock is on the device--how >>> are you interpreting >>> the rx_time tag? It's two parts--a uint64 with the >>> full-seconds portion, and a double-precision float for the >>> fractional part. >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
