[USRP-users] B210 - how to use second TX/RX frontend?

2018-08-19 Thread Ralph A. Schmid, dk5ras via USRP-users
Hi,

I am using an USRP B210, and it appears somehow it is deaf at higher
frequencies, 1.8 GHz and above. 

Is there a possibility to use the second MIMO frontend single, by some
device string? I tried a lot combinations, with no success,. so maybe this
even is not possible? Would help me decide if really there is smth. wrong,
as the second frontend was unused and unconnected all the time.

Thanks a lot, and with best regards

Ralph.




--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
+49-911-21650056
ra...@schmid.xxx
http://www.bclog.de/





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] B210 - how to use second TX/RX frontend?

2018-08-19 Thread Ron Economos via USRP-users

Use A:B in the Subdev Spec.

Ron

On 08/19/2018 07:03 AM, Ralph A. Schmid, dk5ras via USRP-users wrote:

Hi,

I am using an USRP B210, and it appears somehow it is deaf at higher
frequencies, 1.8 GHz and above.

Is there a possibility to use the second MIMO frontend single, by some
device string? I tried a lot combinations, with no success,. so maybe this
even is not possible? Would help me decide if really there is smth. wrong,
as the second frontend was unused and unconnected all the time.

Thanks a lot, and with best regards

Ralph.




--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
+49-911-21650056
ra...@schmid.xxx
http://www.bclog.de/



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] uhd_usrp_probe Daughterboard Manager (DBMGR) error.

2018-08-19 Thread Marcus Müller via USRP-users
Hi Bob,

I'm not ruling out we actually are dealing with a software bug here; I
remember that exact dict from somewhere else, but I can't find it
anymore :( We might cooperate to figure this one out, however!

Since this looks like a UHD built from git, we have a lot of options. 

first of all, try 

export UHD_LOG_LEVEL=0 ### 0 is the most verbose mode, "trace"
uhd_usrp_probe

if that doesn't give you a line like
"RFX tune: R=%d, BS=%d, P=%d, B=%d, A=%d, DIV2=%d"
we'll have to look deeper.

Run your source build's CMake step again with 

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DUHD_LOG_MIN_LEVEL=0
  -your_OTHER_cmake_OPTIONS ..

build and install the new shiny UHD. You should be getting the above
debug line. My hypothesis is that P=0. Is that right?

Best regards,
Marcus

On Sat, 2018-08-18 at 18:16 -0700, Bob Conley via USRP-users wrote:
> I realize these are old USRP-1s with 2 RFX900 daughterboards (DBs)
> but I would like to keep them running and appreciate any help.  It
> may also point to more current issues as outlined below.
> 
> As in the following cases the uhd_usrp_probe command returns the
> correct DB ID but fails to return the name and operational parameters
> for the DB. See: transcript below.
> 
> If I replace the RFX900 with the BasicRX DB, as Riccardo did in the
> second thread below, the probe command returns the expected results
> with all parameters populated and the USRP functions perfectly.
> 
> As stated above, this error is similar to the apparently unresolved
> errors encountered in the January 2018 thread "[X300] UBX-40 v1
> compatibility issues." and the May 2017 "Daugther Board Manager Error
> - USRP2 - N210"
> see:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-Janu
> ary/055334.html
> and
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-May/
> 052779.html
> 
> I have a fresh install of the tool set on Ubuntu 16.04.3.
> conley@Ubuntu-16-4-3Dell:~/rfnoc$ uhd_config_info --version
> UHD 4.0.0.rfnoc-devel-702-geec24d7b
> 
> I also ran the uhd_images_downloader which included the usrp-1 code.
> The error is repeatable on other similarly configured USRP-1s and on
> another development PC.
> 
> Again, any help is greatly appreciated.
> 
> 
> Transcript
> _
> conley@Ubuntu-16-4-3Dell:~/workarea-uhd/uhd/host/utils$
> uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.HEAD-0-g5b236772
> [INFO] [USRP1] Opening a USRP1 device...
> [INFO] [FX2] Loading FPGA image:
> /usr/local/share/uhd/images/usrp1_fpga.rbf...
> [INFO] [FX2] FPGA image loaded
> [INFO] [USRP1] Using FPGA clock rate of 64.00MHz...
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> LookupError: KeyError: key "0" not found in dict(i,
> N14adf4360_regs_t17prescaler_value_tE)
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> LookupError: KeyError: key "0" not found in dict(i,
> N14adf4360_regs_t17prescaler_value_tE)
>   _
>  /
> |   Device: USRP1 Device
> | _
> |/
> |   |   Mboard: USRP1
> |   |   serial: 4d76b228
> |   |   
> |   |   Time sources:  none
> |   |   Clock sources: internal
> |   |   Sensors: 
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: RFX900 (0x0025)
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 0
> |   |   |   |   Antennas: 
> |   |   |   |   Sensors: 
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ad9522
> |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: RFX900 (0x0025)
> |   |   | _
> |   |   

Re: [USRP-users] give lo offset to uhd_tune_request_t

2018-08-19 Thread Marcus D. Leech via USRP-users

On 08/19/2018 02:35 AM, Hojoon Yang via USRP-users wrote:


Hi,

Who should I send it to figure this out? Any recommendation?

Thanks

I'm hoping that one of the UHD devs will chime in.  It may be the case 
that you have to manually compute the necessary values in a
  tune_request structure, including DSP policy and RF policy.  On the 
C++ side, that is done for you when you pass in a lo_offset argument.




---Original Message---
From: "Marcus D. Leech via USRP-users" 
To: usrp-users@lists.ettus.com
Sent date: 2018-08-17 03:39:21 GMT +0900 (Asia/Seoul)
Subject: Re: [USRP-users] give lo offset to uhd_tune_request_t
On 08/16/2018 01:38 PM, Hojoon Yang via USRP-users wrote:


Hi, all

I want to give *lo offset* for tune_request.

In C++, I'm able to set the lo_offset for tune_request, i.e.
uhd::tune_request_t tune_request(target_freq, lo_offset)


In C, How can I achieve this using uhd_tune_request_t?

uhd_tune_request_t tune_request = {

.target_freq = target_freq,

.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,

.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO

};

Thanks.



Indeed, I can't quite figure this out myself, despite spending
some time with the C part of the codebase.   I think the function
templates are
  automatically generated during build time from the C++ headers.

Perhaps someone in R&D can comment on how this is done for C++
methods that are overloaded with respect to argument types.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com