[USRP-users] MIMO bug?

Marcus D. Leech mleech at ripnet.com
Mon Dec 29 20:46:48 EST 2014


On 12/29/2014 08:36 PM, Dan Sego wrote:
> It turns out that after specifically mapping both N200 daughter boards 
> with set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:0"), 0) and 
> ("A:0"),1), the global settings only work for set_rx_rate. The gain 
> commands and the antenna selection ("TX/RX") and frequency (tuning) 
> had to be made explicitly to each channel.
>
> What I was seeing was leakage on the slave (which tracked the slave 
> device when I switched master/slave).
>
> cheers, and Happy New Year! Dan
The only thing that *has* to be common among the devices is the sample 
rate.  Even in MIMO mode (which is a bit of a misnomer, because
   it can be used for things other than MIMO, where coherent clocks are 
required for other reasons).

You *must* configure each daughterboard separately, even if you intend 
to use the same frequency and gain settings.


>
> On Mon, Dec 29, 2014 at 1:57 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     On 12/29/2014 04:54 PM, Dan Sego wrote:
>>     Thank you for the reply, I hope your holiday was a good one.
>>
>>     I should have noted that I do query the motherboards for gain
>>     after the code has completed sampling. Results echo the
>>     initial read back after gains are set.
>>
>>     As to the GR, no I haven't. Looked at that approach originally
>>     and passed as the learning curve looked longer than C++, and I
>>     didn't know C++.......
>>
>>     I had considered the gain question but the only control is on the
>>     HMC472 attenuator and 6 dB (coarse) and 3.5 dB (fine) in the ADC
>>     (if I have the correct model number - ADS62P45 and family and
>>     which is not a user control state I suspect). So at 10 dB gain
>>     attempted (21.5 dB attenuation) on the master,slave attenuator
>>     and ADC defaulting at/to 0 dB gain combines to yield ~20 dB of
>>     channel offset (slave relative to master and this presumes that
>>     the ADC gains are both set in the master). Otherwise, it looks
>>     like fixed gain in the remainder of the cascade (the ADA493X and
>>     differential driver for the ADC, MGA82563), have I missed something?
>>
>>     The fact that it is always the slave suggests a driver to me.
>>
>>     I haven't yet run over a range of gain settings in MIMO. I'll try
>>     that and report back. I'll also try an older UHD release.
>>
>>     Cheers, and thanks again. Dan
>     There's a variable attenuator in the WBX RX chain, independent of
>     the motherboard.
>
>     Putting a simple thing together in GRC would be five minutes work,
>     just to confirm sanity:
>
>     UHD-source-with-2-channels------>2 FFT sinks.
>
>
>
>>
>>     On Mon, Dec 29, 2014 at 1:05 PM, Marcus D. Leech via USRP-users
>>     <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>>
>>     wrote:
>>
>>         On 12/29/2014 12:09 PM, Dan Sego via USRP-users wrote:
>>>         Good morning to the list.
>>>
>>>         I have 2 N200 r4 units with WBX daughter cards operating
>>>         with the following Win32; Microsoft Visual C++ version 10.0;
>>>         Boost_105400; UHD_003.008.000-release. One unit has an
>>>         internal GPSDO.
>>>
>>>         In MIMO operation (via the MIMO cable). The slave unit
>>>         experiences an unexplained 25 dB of attenuation relative to
>>>         the master. This change does not follow the hardware: that
>>>         is it tracks the slave.
>>>
>>>         I am using US HDTV as probing signal: tuning to 575 MHz with
>>>         fc32 formatted data sampled as 12.5 MCSPS per unit. The code
>>>         operated successfully performing data capture to file
>>>         (though does have the windows prompt upon completion to
>>>         terminate). An example run screen capture is pasted below:
>>>         the collection operation involves continuous sampling saving
>>>         contiguous packets (28) and skipping 50 for a approximate
>>>         burst sampling rate of 25 Hz.
>>>
>>>         Win32; Microsoft Visual C++ version 10.0; Boost_105400;
>>>         UHD_003.008.000-release
>>>
>>>         -- Opening a USRP2/N-Series device...
>>>         -- Current recv frame size: 1472 bytes
>>>         -- Current send frame size: 1472 bytes
>>>         -- Creating WSA UDP transport for 192.168.10.3:49156
>>>         <http://192.168.10.3:49156>
>>>         -- Creating WSA UDP transport for 192.168.10.3:49158
>>>         <http://192.168.10.3:49158>
>>>         -- Creating WSA UDP transport for 192.168.10.3:49157
>>>         <http://192.168.10.3:49157>
>>>         -- Creating WSA UDP transport for 192.168.10.3:49159
>>>         <http://192.168.10.3:49159>
>>>         -- Detecting internal GPSDO.... Found an internal GPSDO
>>>         -- Creating WSA UDP transport for 192.168.10.2:49156
>>>         <http://192.168.10.2:49156>
>>>         -- Creating WSA UDP transport for 192.168.10.2:49158
>>>         <http://192.168.10.2:49158>
>>>         -- Creating WSA UDP transport for 192.168.10.2:49157
>>>         <http://192.168.10.2:49157>
>>>         -- Creating WSA UDP transport for 192.168.10.2:49159
>>>         <http://192.168.10.2:49159>
>>>         -- Setting references to the internal GPSDO
>>>         -- Initializing time to the internal GPSDO
>>>         Using Devices: Multi USRP:
>>>           Device: USRP2 / N-Series Device
>>>           Mboard 0: N200r4
>>>           Mboard 1: N200r4
>>>           RX Channel: 0
>>>             RX DSP: 0
>>>             RX Dboard: A
>>>             RX Subdev: WBXv3 RX+GDB
>>>           RX Channel: 1
>>>             RX DSP: 0
>>>             RX Dboard: A
>>>             RX Subdev: WBXv3 RX+GDB
>>>           TX Channel: 0
>>>             TX DSP: 0
>>>             TX Dboard: A
>>>             TX Subdev: WBXv3 TX+GDB
>>>           TX Channel: 1
>>>             TX DSP: 0
>>>             TX Dboard: A
>>>             TX Subdev: WBXv3 TX+GDB
>>>
>>>         Actual RX Rate Master: 12.500000 Msps...
>>>
>>>         Actual RX Rate Slave: 12.500000 Msps...
>>>
>>>         Actual Gain Master: 10.000000 dB...
>>>
>>>         Actual Gain Slave: 10.000000 dB...
>>>
>>>         GPS lock status: locked
>>>         GPS epoch time: 1419183071 seconds
>>>         -- Successfully tuned to 575.000000 MHz
>>>         -- 
>>>         -- Successfully tuned to 575.000000 MHz
>>>         -- 
>>>         Checking LO Lock Master LO: locked...
>>>         Checking LO Lock Slave LO: locked...
>>>         Checking MIMO Lock MIMO: locked...
>>>
>>>         sample time first packet2.3000003
>>>
>>>         full seconds2.3000003
>>>
>>>
>>>         sample time first packet2.34068534
>>>
>>>         full seconds2.34068534
>>>
>>>
>>>         Done!
>>>
>>>         I have measured the channel signals of the units
>>>         individually and configured for MIMO. Examples of the
>>>         individual measurements (power spectra and mean noise power
>>>         and total signal power are summarized in slide 1 attached.
>>>         All runs were made at 10 dB of gain. Both units were
>>>         individually exercised from 0 to 30 dB of gain to have
>>>         side-by-side responses (indeed one unit is 5 dB less
>>>         sensitive which track over gain and both have distinctive
>>>         and repeatable gain responses using identical log periodic
>>>         antennas and matched length coax).
>>>
>>>         Slide 2 has the MIMO results in both possible configurations.
>>>
>>>         Has anyone encountered this? Any suggestions?
>>>          regards, Dan Sego
>>>
>>>
>>>         _______________________________________________
>>>         USRP-users mailing list
>>>         USRP-users at lists.ettus.com  <mailto:USRP-users at lists.ettus.com>
>>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>         The only thing I can think of is that the slave gain isn't
>>         being set, despite the messages shown to the contrary.
>>
>>         Have you tried a GR flow-graph to experiment with this case?
>>
>>
>>
>>         -- 
>>         Marcus Leech
>>         Principal Investigator
>>         Shirleys Bay Radio Astronomy Consortium
>>         http://www.sbrac.org
>>
>>
>>         _______________________________________________
>>         USRP-users mailing list
>>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>     -- 
>     Marcus Leech
>     Principal Investigator
>     Shirleys Bay Radio Astronomy Consortium
>     http://www.sbrac.org
>
>


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141229/6cbe8d49/attachment-0002.html>


More information about the USRP-users mailing list