There could also be FPGA constraints that make the clock architecture on the E320 necessary.
Sent from my iPhone > On Jun 6, 2022, at 7:57 PM, David Raeman <[email protected]> > wrote: > > Hi Jon, I did some poking around in the code, and I don't believe the E320 > supports that feature. On B2xx radios, if you don't specify an explicit > master clock rate it has logic to determine an ideal rate based on the > sampling rate, and it exposes an auto_tick_rate property to toggle that > behavior from the application. Conversely, on the E320 radio if you don't > specify an explicit master clock rate it always uses a fixed value of 16 MHz, > and the implementation has no logic that I see to perform the dynamic tick > rate calculations. > > Since the B2xx and E320 radios are both based on the AD9361 RFIC, > theoretically I think the logic could be placed somewhere such that the E320 > and B2xx radios could both provide the feature. However, the implementations > are pretty diverged - the E320 is based on the newer MPM code architecture > and the B2xx is not. > > Short story is the E320 doesn't seem to support this, but I think it's just a > matter of missing bits in the software. > > Best, > -David > > >> -----Original Message----- >> From: Jon Beniston <[email protected]> >> Sent: Monday, June 6, 2022 6:46 PM >> To: 'Marcus D. Leech' <[email protected]>; usrp- >> [email protected] >> Subject: [USRP-users] Re: E320 Automatic master clock >> >> Hi Marcus, >> >>>> If I just try to re-make the device, I get an exception. Eg: >>>> >>>> m_dev = uhd::usrp::multi_usrp::make(device_args); >>>> m_dev->set_master_clock_rate(61.44e6); >>>> // How to restart a session here? >>>> m_dev = uhd::usrp::multi_usrp::make(device_args); >>>> >>>> ... >> >>> However, there is a set_master_clock_rate() API call: >>> >>> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a >> 99 >>> 254abfa5259b70a020e667eee619b9 >> >> Yes, that's what I'm calling above. >> >>> What the consequences are for changing this within a session >>> is necessarily device dependent. If I were going to do this, I'd tear down >> the streamers, set the >>> master_clock to the new rate, and then re-create the streamers. >> >> The problem is, that method doesn't appear to support an "automatic" rate, >> unless I'm missing something. >> >> Thanks, >> Jon >> >> >> >> _______________________________________________ >> USRP-users mailing list -- [email protected] To unsubscribe send an >> email to [email protected] _______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
