So if you're using > kalibrate or another program to estimate tuning error, you can make up > that error by retuning instead of reclocking. ADC and DAC will still operate with the frequency offset and this will give you a clock skew. Some mobiles are tolerant to that, but some are more picky. And this may give you strange behavior during testing.

A complete OFDM blind receiver which does not require the use of pilot symbols is used for time, frequency, phase offset and channel estimation. Cyclic redundancy check (CRC) and forward error correction (FEC) are used to detect and correct errors within a frame's preamble and postamble.

But for gross estimation, I see no flaws in your logic.

The point of this script is to quantitatively estimate the fastest hopping speed a USRP can handle. To do this, I used the Python time module and time.clock() on a Ubuntu 14.04 LTS intel corei7 computer to measure the time between hops. If the time between hops was greater then the dwell time, the script declares that the hop rate is not supported.

I've made a very rough run-down of things in http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-May/020156.html It's really just an upper-boundary estimate. In fact, the time an LO takes to retune depends on when you define it's finished doing that, ie. after which time you consider the PLL to be stable enough for operation.

Some folks have been tempted "in to sin" by making assumptions about total system gain, and using a strictly numeric approach to estimate signal levels as seen at the antenna port. Just wanted to point out that's dead-wrong and you need to calibrate with an external, known, source. > > On Fri, Feb 24, 2017 at 4:42 PM, Marcus D.

The page says the requirements for MUSIC are: the number of plane-wave signals, D is known, * the number of antenna elements, N is at least equal to D+1 and * the inputs received across the antenna array for the purpose of DoA estimation are phase-synchronous. If D = 1 then it should be possible to use the B210, correct ?

I can't give an estimate for when it'll be fixed. As a workaround, you might be able to run 'make clean' in the build directory to force generation of the corresponding IP. Thanks for bringing this up, Martin

If one monitors the message containing the estimated variance of the PPS output one may be able to circumvent such effects. Bruce

A couple weeks ago (check the archives around 26 July 2009) I posted some plots of the PPS/OSC error estimates when the receiver's position was intentionally offset from its true position. The results were rather dramatic... And the quality of the data scaled with the position error.