Re: [USRP-users] Enable aliasing using USRP

[Kyeong Su Shin via USRP-users]

Hello Wahhab,

If I recall correctly, you can *not* change the bandwidth of SBX (always
40MHz), and the sampling rate of the USRP2 (always 100MS/s). What you are
actually setting by setting --rate 2e6 is the decimation ratio. The signals
will be always sampled at 100MS/s, and then decimated by the decimator
within the FPGA.

It is still possible to cause aliasing - one way is to just sample at a
fast sampling rate and then decimate by yourself. An other way would be
tinkering the digital filters used by the decimator, but I am not sure if
there are good APIs to do that. I am pretty sure that rx_samples_to_file is
not suitable for the task, though (correct me if I am wrong). That is just
an example program.

Regards,
Kyeong Su Shin

On Thu, Dec 28, 2017 at 6:29 PM, Wahhab Albazrqaoe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi John,
> Thank you for your reply.
> We would like to create aliasing. This means that we should set ADC to
> sample at speed less than Nyquist rate.
> In our setting, we target RF front end to be 50MHz and ADC speed is 2MHz.
> The question is how to do it? We use some commands (as shown in my
> previous email) but seems not working as expected, i.e. RF front end
> bandwidth is still 2MHz.
>
> Best,
>
> On Thu, Dec 28, 2017 at 9:24 PM, John Shields 
> wrote:
>
>> Hi Wahhab,
>>This is a fairly basic issue – the ‘bandwidth’ (if
>> that is really what you are really meaning) is related to the sample_rate
>> by The Nyquist  Frequency
>>
>>   https://en.wikipedia.org/wiki/
>> Nyquist_frequency
>>
>>  Kind Regards,
>>
>>   John
>>
>> *From:* Wahhab Albazrqaoe via USRP-users 
>> *Sent:* Friday, December 29, 2017 3:04 PM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* [USRP-users] Enable aliasing using USRP
>>
>> Dear All,
>> I have question about how to create aliasing using USRP.
>> Basically, I have USRP2 with SBX (with recent installations of GnuRadio
>> and UHD).
>> I would like to set the bandwidth of the RF front end to 50 MHz, and use
>> 2MHz of sampling rate (ADC speed).
>> I am using the following command:
>> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
>> --freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0
>>
>>
>>
>> Problem: it seems to me that the system (GnuRadio/USRP) observes only
>> 2MHz of RF front end bandwdith. How do I know this? Ans: I compare such
>> settings with the following settings:
>> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
>> --freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0
>>
>> The later setting seems to be actual 50 MHz of Rf front end.
>>
>> Any comments and advices on how to create aliasing using USRP are
>> appreciate.
>>
>> Best,
>> Wahhab
>>
>>
>>
>> --
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_-1409356437401843074_m_5211752623429318912_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
>
> ___
> 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

[USRP-users] Unicast messaging via GNURadio

[Mahesh Jena via USRP-users]

Hi Everyone,
I am new to the GNURadio world.

I have tested few GNURadio features and test scenarios with USRP E312 and
B210, but all the example that I found has communication over broadcast.

I wanted to know if its possible to send *unicast* or *multicast* messages
via GNURadio?
If yes, then can you please give me some example!

Thanks in advance!

Kind Regards,


*Mahesh Jena*

-- 


*DISCLAIMER*

THIS MESSAGE, TOGETHER WITH ANY ATTACHMENTS, IS CONFIDENTIAL, IS INTENDED 
ONLY FOR THE USE OF THE ADDRESSEE(S), AND MAY HAVE INFORMATION THAT IS 
COVERED BY LEGAL, PROFESSIONAL OR OTHER PRIVILEGE. ANY OPINIONS EXPRESSED, 
IMPLIED, OR PRESENTED ARE SOLELY THOSE OF THE AUTHOR AND ARE NOT THOSE OF 
PRETLIST. IF YOU ARE NOT THE INTENDED RECIPIENT, THEN PLEASE DESTROY THIS 
EMAIL AND ITS ATTACHMENTS, AND LET US KNOW AT ONCE. ANY COPYING, 
DISTRIBUTION OR USE OF THIS EMAIL, ITS ATTACHMENTS, OR ANY INFORMATION 
CONTAINED HERE IS PROHIBITED.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] GNURadio OFDM blocks not working with USRP

[Weihan Chen via USRP-users]

Hello,

I'm trying to transmit one OFDM frame from one USRP to the other one using
GNURadio. The flow graph is as follows:

TX side: vector source -> stream to tagged stream -> OFDM Transmitter ->
UHD sink
RX side: UHD source -> OFDM Receiver -> null sink

OFDM parameters: fft_len=64, cp_len=16
USRP parameters: sample rate=1Msps, freq=900M, gain=15.

The problem is that at receiver side I get many incoming packets, and none
of them is correct, while in simulation (without the USRP blocks) I get
exactly one packet. Not sure what's going wrong here. Could someone help me
with this? Thanks.

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

Re: [USRP-users] Enable aliasing using USRP

[Wahhab Albazrqaoe via USRP-users]

Hi John,
Thank you for your reply.
We would like to create aliasing. This means that we should set ADC to
sample at speed less than Nyquist rate.
In our setting, we target RF front end to be 50MHz and ADC speed is 2MHz.
The question is how to do it? We use some commands (as shown in my previous
email) but seems not working as expected, i.e. RF front end bandwidth is
still 2MHz.

Best,

On Thu, Dec 28, 2017 at 9:24 PM, John Shields 
wrote:

> Hi Wahhab,
>This is a fairly basic issue – the ‘bandwidth’ (if that
> is really what you are really meaning) is related to the sample_rate by The
> Nyquist  Frequency
>
>   https://en.wikipedia.org/wiki/
> Nyquist_frequency
>
>  Kind Regards,
>
>   John
>
> *From:* Wahhab Albazrqaoe via USRP-users 
> *Sent:* Friday, December 29, 2017 3:04 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [USRP-users] Enable aliasing using USRP
>
> Dear All,
> I have question about how to create aliasing using USRP.
> Basically, I have USRP2 with SBX (with recent installations of GnuRadio
> and UHD).
> I would like to set the bandwidth of the RF front end to 50 MHz, and use
> 2MHz of sampling rate (ADC speed).
> I am using the following command:
> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
> --freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0
>
>
>
> Problem: it seems to me that the system (GnuRadio/USRP) observes only 2MHz
> of RF front end bandwdith. How do I know this? Ans: I compare such settings
> with the following settings:
> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
> --freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0
>
> The later setting seems to be actual 50 MHz of Rf front end.
>
> Any comments and advices on how to create aliasing using USRP are
> appreciate.
>
> Best,
> Wahhab
>
>
>
> --
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_5211752623429318912_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Enable aliasing using USRP

[John Shields via USRP-users]

Hi Wahhab,
   This is a fairly basic issue – the ‘bandwidth’ (if that is 
really what you are really meaning) of signals which can be sampled and 
correctly reconstituted  is related to the sample_rate by Nyquist

 https://en.wikipedia.org/wiki/Nyquist_rate

 Kind Regards,

  John

From: Wahhab Albazrqaoe via USRP-users
Sent: Friday, December 29, 2017 3:04 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Enable aliasing using USRP

Dear All,
I have question about how to create aliasing using USRP.
Basically, I have USRP2 with SBX (with recent installations of GnuRadio and 
UHD).
I would like to set the bandwidth of the RF front end to 50 MHz, and use 2MHz 
of sampling rate (ADC speed).
I am using the following command:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0




Problem: it seems to me that the system (GnuRadio/USRP) observes only 2MHz of 
RF front end bandwdith. How do I know this? Ans: I compare such settings with 
the following settings:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 
--freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0


The later setting seems to be actual 50 MHz of Rf front end.

Any comments and advices on how to create aliasing using USRP are appreciate.


Best,
Wahhab






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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Enable aliasing using USRP

[Wahhab Albazrqaoe via USRP-users]

Dear All,
I have question about how to create aliasing using USRP.
Basically, I have USRP2 with SBX (with recent installations of GnuRadio and
UHD).
I would like to set the bandwidth of the RF front end to 50 MHz, and use
2MHz of sampling rate (ADC speed).
I am using the following command:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
--freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0



Problem: it seems to me that the system (GnuRadio/USRP) observes only 2MHz
of RF front end bandwdith. How do I know this? Ans: I compare such settings
with the following settings:
sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6
--freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0

The later setting seems to be actual 50 MHz of Rf front end.

Any comments and advices on how to create aliasing using USRP are
appreciate.

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

Re: [USRP-users] UHD not working with the B200 USB 2.0 on ARM64 platform

[Michael Don via USRP-users]

I've figured it out.  It turns out that the B200 wasn't getting enough
power from the USB 2.0 port I was using on the Tegra.  When I plugged in
external power, it worked!

On Thu, Dec 28, 2017 at 6:30 PM, Philip Balister 
wrote:

> Try strace uhd_usrp_probe
>
> and see if you can see which system call returns -EPERM. Yes this is a
> hail mary operation.
>
> Philip
>
> On 12/28/2017 01:13 PM, Michael Don via USRP-users wrote:
> > I'm still getting the same error with the USB 2.0 for the B200 on my
> tegra
> > system.
> >
> > Using lsusb I can see the B200 listed as:
> >
> > Bus 001 Device 031: ID 2500:0020
> >
> > I can then find /dev/bus/usb/001/031 and verify that it has the correct
> > permissions:
> >
> > crw-rw-rw- 1 root flirimaging 189, 30 Dec 28 18:04 031
> >
> > Just to test things out, I've even changed the permissions, reloaded the
> > udev rules, and noted that the permissions change back.
> >
> > So in spite of verifying the B200 permissions, I still get the same error
> > listed in my original email.  Does anyone have any other suggestions?
> >
> > -Mike
> >
> >
> > On Fri, Dec 22, 2017 at 3:13 PM, Michael Don  wrote:
> >
> >> Marcus,
> >>
> >> Yes, "sudo udevadm control --reload-rules" is included in the "Setup
> Udev for USB" instructions.  I also tried replugging in the unit.  I'll try
> debugging some more and let you know if I come up with anything.
> >>
> >> Philip - thanks for letting me know about the acceleration, once I get
> things working I may ask you more about it.
> >>
> >> -Mike
> >>
> >>
> >> On Tue, Dec 19, 2017 at 7:58 PM, Philip Balister via USRP-users <
> >> usrp-users@lists.ettus.com> wrote:
> >>
> >>> On 12/19/2017 06:44 PM, Marcus D. Leech via USRP-users wrote:
>  On 12/19/2017 05:09 PM, Michael Don via USRP-users wrote:
> >
> > I've build and installed UHD 3.10.1.1 on a Tegra TX2 (ARM64
> > platform).  The USB 3.0 is working, but I'm getting errors with the
> > USB 2.0 on a USRP B200.
> >>>
> >>> I know UHD works on several aarch64 platforms. I do carry a patch in
> >>> meta-sdr that enables neon acceleration for the uhd type convertors.
> >>>
> >>> Philip
> >>>
> >
> > uhd_find_devices works, but uhd_usrp_probe, and the uhd application
> > examples give the error below.  Note that I've tried running with
> > sudo, and have followed the instructions "Setup Udev for USB" about
> > the uhd-usrp.rules file.  Any advice?
> >
> > Thanks, -Mike
> >
> >
> > linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > UHD_003.010.001.001-0-unknown
> >
> > -- Detected Device: B200
> > -- Operating over USB 2.
> > -- Initialize CODEC control...
> >
> > UHD Error:
> > An unexpected exception was caught in a task loop.
> > The task loop will now exit, things may not work.
> > EnvironmentError: IOError: usb rx8 transfer status:
> > LIBUSB_TRANSFER_ERROR
> > -- Detected bad USB state; resetting.
> >
> > UHD Error:
> > USB open failed: insufficient permissions.
> > See the application notes for your device.
> > Error: AssertionError: libusb_open(_dev->get(), &_handle) == 0
> >   in
> > libusb_device_handle_impl::libusb_device_handle_impl(uhd::
> >>> transport::libusb::device::sptr)
> >
> >   at
> > /home/nvidia/Documents/USB3/uhd-release_003_010_001_001/host
> >>> /lib/transport/libusb1_base.cpp:261
> >
> >
> >
> >
> 
>  Did you:
> 
>  sudo udevadm control --reload-rules
> 
>  After installing the usrp rules file?
> 
>  Did you unplug/replug, after updating the rules?  The rules are only
>  *triggered* when a USB device event happens, so if it's still plugged
> in
>  when you change
>    the rules, nothing will happen until you re-plug.
> 
> 
> 
> 
>  ___
>  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
> >>>
> >>
> >>
> >
> >
> >
> > ___
> > 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

Re: [USRP-users] USRP TwinRX Error UHD

[Marcus D. Leech via USRP-users]

On 12/28/2017 11:52 AM, ALEJANDRO BLANCO PIZARRO wrote:

Yeah, sure, The output is:

sudo uhd_usrp_probe --args "type=x310"
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.002.000-release


Error: LookupError: KeyError: No devices found for ->
Device Address:
type: x310


I must apologize, I should have said "type=x300".

But your subsequent uhd_usrp_probe output (note, that sudo should not be 
required for any of this) shows that the version of UHD you have recognizes

  the card

My guess is that your srsLTE environment is linked against a different, 
older, version of UHD which doesn't have TwinRX support. Note also that 
a full

  LTE stack will not work with a receive-only card like the TwinRX.




I am not pretty sure that the command is correct. So, I am going to 
show you the output of sudo uhd_usrp_probe too:


linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.002.000-release


-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO: LC_XO, 
Firmware Rev 0.929a

-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.7MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
  _
 /
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 7
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:21:e4:65
|   |   mac-addr1: 00:80:2f:21:e4:66
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.50.2
|   |   subnet3: 255.255.255.0
|   |   serial: 30AAD25
|   |   FW Version: 5.1
|   |   FPGA Version: 33.0
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, 
gps_servo, ref_locked

|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: TwinRX v1.1 (0x0093)
|   |   |   Serial: 3129E7C
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: TwinRX RX0
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: II
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 1
|   |   |   |   Name: TwinRX RX1
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: QQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   RX Dboard: B
|   |   |   ID: TwinRX v1.1 (0x0093)
|   |   |   Serial: 31293DD
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: TwinRX RX0
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: II
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 1
|   |   |   |   Name: TwinRX RX1
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: QQ
|   |   |   |   Uses LO offset: No
|   |   | ___

Re: [USRP-users] UHD not working with the B200 USB 2.0 on ARM64 platform

[Philip Balister via USRP-users]

Try strace uhd_usrp_probe

and see if you can see which system call returns -EPERM. Yes this is a
hail mary operation.

Philip

On 12/28/2017 01:13 PM, Michael Don via USRP-users wrote:
> I'm still getting the same error with the USB 2.0 for the B200 on my tegra
> system.
> 
> Using lsusb I can see the B200 listed as:
> 
> Bus 001 Device 031: ID 2500:0020
> 
> I can then find /dev/bus/usb/001/031 and verify that it has the correct
> permissions:
> 
> crw-rw-rw- 1 root flirimaging 189, 30 Dec 28 18:04 031
> 
> Just to test things out, I've even changed the permissions, reloaded the
> udev rules, and noted that the permissions change back.
> 
> So in spite of verifying the B200 permissions, I still get the same error
> listed in my original email.  Does anyone have any other suggestions?
> 
> -Mike
> 
> 
> On Fri, Dec 22, 2017 at 3:13 PM, Michael Don  wrote:
> 
>> Marcus,
>>
>> Yes, "sudo udevadm control --reload-rules" is included in the "Setup Udev 
>> for USB" instructions.  I also tried replugging in the unit.  I'll try 
>> debugging some more and let you know if I come up with anything.
>>
>> Philip - thanks for letting me know about the acceleration, once I get 
>> things working I may ask you more about it.
>>
>> -Mike
>>
>>
>> On Tue, Dec 19, 2017 at 7:58 PM, Philip Balister via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 12/19/2017 06:44 PM, Marcus D. Leech via USRP-users wrote:
 On 12/19/2017 05:09 PM, Michael Don via USRP-users wrote:
>
> I've build and installed UHD 3.10.1.1 on a Tegra TX2 (ARM64
> platform).  The USB 3.0 is working, but I'm getting errors with the
> USB 2.0 on a USRP B200.
>>>
>>> I know UHD works on several aarch64 platforms. I do carry a patch in
>>> meta-sdr that enables neon acceleration for the uhd type convertors.
>>>
>>> Philip
>>>
>
> uhd_find_devices works, but uhd_usrp_probe, and the uhd application
> examples give the error below.  Note that I've tried running with
> sudo, and have followed the instructions "Setup Udev for USB" about
> the uhd-usrp.rules file.  Any advice?
>
> Thanks, -Mike
>
>
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-0-unknown
>
> -- Detected Device: B200
> -- Operating over USB 2.
> -- Initialize CODEC control...
>
> UHD Error:
> An unexpected exception was caught in a task loop.
> The task loop will now exit, things may not work.
> EnvironmentError: IOError: usb rx8 transfer status:
> LIBUSB_TRANSFER_ERROR
> -- Detected bad USB state; resetting.
>
> UHD Error:
> USB open failed: insufficient permissions.
> See the application notes for your device.
> Error: AssertionError: libusb_open(_dev->get(), &_handle) == 0
>   in
> libusb_device_handle_impl::libusb_device_handle_impl(uhd::
>>> transport::libusb::device::sptr)
>
>   at
> /home/nvidia/Documents/USB3/uhd-release_003_010_001_001/host
>>> /lib/transport/libusb1_base.cpp:261
>
>
>
>

 Did you:

 sudo udevadm control --reload-rules

 After installing the usrp rules file?

 Did you unplug/replug, after updating the rules?  The rules are only
 *triggered* when a USB device event happens, so if it's still plugged in
 when you change
   the rules, nothing will happen until you re-plug.




 ___
 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
>>>
>>
>>
> 
> 
> 
> ___
> 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

Re: [USRP-users] UHD not working with the B200 USB 2.0 on ARM64 platform

[Michael Don via USRP-users]

I'm still getting the same error with the USB 2.0 for the B200 on my tegra
system.

Using lsusb I can see the B200 listed as:

Bus 001 Device 031: ID 2500:0020

I can then find /dev/bus/usb/001/031 and verify that it has the correct
permissions:

crw-rw-rw- 1 root flirimaging 189, 30 Dec 28 18:04 031

Just to test things out, I've even changed the permissions, reloaded the
udev rules, and noted that the permissions change back.

So in spite of verifying the B200 permissions, I still get the same error
listed in my original email.  Does anyone have any other suggestions?

-Mike


On Fri, Dec 22, 2017 at 3:13 PM, Michael Don  wrote:

> Marcus,
>
> Yes, "sudo udevadm control --reload-rules" is included in the "Setup Udev for 
> USB" instructions.  I also tried replugging in the unit.  I'll try debugging 
> some more and let you know if I come up with anything.
>
> Philip - thanks for letting me know about the acceleration, once I get things 
> working I may ask you more about it.
>
> -Mike
>
>
> On Tue, Dec 19, 2017 at 7:58 PM, Philip Balister via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 12/19/2017 06:44 PM, Marcus D. Leech via USRP-users wrote:
>> > On 12/19/2017 05:09 PM, Michael Don via USRP-users wrote:
>> >>
>> >> I've build and installed UHD 3.10.1.1 on a Tegra TX2 (ARM64
>> >> platform).  The USB 3.0 is working, but I'm getting errors with the
>> >> USB 2.0 on a USRP B200.
>>
>> I know UHD works on several aarch64 platforms. I do carry a patch in
>> meta-sdr that enables neon acceleration for the uhd type convertors.
>>
>> Philip
>>
>> >>
>> >> uhd_find_devices works, but uhd_usrp_probe, and the uhd application
>> >> examples give the error below.  Note that I've tried running with
>> >> sudo, and have followed the instructions "Setup Udev for USB" about
>> >> the uhd-usrp.rules file.  Any advice?
>> >>
>> >> Thanks, -Mike
>> >>
>> >>
>> >> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> >> UHD_003.010.001.001-0-unknown
>> >>
>> >> -- Detected Device: B200
>> >> -- Operating over USB 2.
>> >> -- Initialize CODEC control...
>> >>
>> >> UHD Error:
>> >> An unexpected exception was caught in a task loop.
>> >> The task loop will now exit, things may not work.
>> >> EnvironmentError: IOError: usb rx8 transfer status:
>> >> LIBUSB_TRANSFER_ERROR
>> >> -- Detected bad USB state; resetting.
>> >>
>> >> UHD Error:
>> >> USB open failed: insufficient permissions.
>> >> See the application notes for your device.
>> >> Error: AssertionError: libusb_open(_dev->get(), &_handle) == 0
>> >>   in
>> >> libusb_device_handle_impl::libusb_device_handle_impl(uhd::
>> transport::libusb::device::sptr)
>> >>
>> >>   at
>> >> /home/nvidia/Documents/USB3/uhd-release_003_010_001_001/host
>> /lib/transport/libusb1_base.cpp:261
>> >>
>> >>
>> >>
>> >>
>> >
>> > Did you:
>> >
>> > sudo udevadm control --reload-rules
>> >
>> > After installing the usrp rules file?
>> >
>> > Did you unplug/replug, after updating the rules?  The rules are only
>> > *triggered* when a USB device event happens, so if it's still plugged in
>> > when you change
>> >   the rules, nothing will happen until you re-plug.
>> >
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP TwinRX Error UHD

[Nate Temple via USRP-users]

Hi Alejandro,

The TwinRX does not support a 184.32e6 Master Clock Rate which is required for 
srsLTE. The TwinRX DBs also will not work with srsLTE as they do not have any 
TX channels.

Regards,
Nate Temple



> On Dec 28, 2017, at 8:52 AM, ALEJANDRO BLANCO PIZARRO via USRP-users 
>  wrote:
> 
> Yeah, sure, The output is:
> 
> sudo uhd_usrp_probe --args "type=x310"
> linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_003.010.002.000-release
> 
> Error: LookupError: KeyError: No devices found for ->
> Device Address:
> type: x310
> 
> 
> I am not pretty sure that the command is correct. So, I am going to show you 
> the output of sudo uhd_usrp_probe too: 
> 
> linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_003.010.002.000-release
> 
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware Rev 
> 0.929a
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.7MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>   _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 7
> |   |   revision_compat: 7
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:21:e4:65
> |   |   mac-addr1: 00:80:2f:21:e4:66
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.50.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30AAD25
> |   |   FW Version: 5.1
> |   |   FPGA Version: 33.0
> |   |   RFNoC capable: Yes
> |   |   
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
> ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: TwinRX v1.1 (0x0093)
> |   |   |   Serial: 3129E7C
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: TwinRX RX0
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: II
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 1
> |   |   |   |   Name: TwinRX RX1
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: QQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: TwinRX v1.1 (0x0093)
> |   |   |   Serial: 31293DD
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: TwinRX RX0
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: II
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 1
> |   |   |   |   Name: TwinRX RX1
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connec

Re: [USRP-users] USRP TwinRX Error UHD

[ALEJANDRO BLANCO PIZARRO via USRP-users]

Yeah, sure, The output is:

sudo uhd_usrp_probe --args "type=x310"
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.002.000-release

Error: LookupError: KeyError: No devices found for ->
Device Address:
type: x310


I am not pretty sure that the command is correct. So, I am going to show
you the output of sudo uhd_usrp_probe too:

linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.002.000-release

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
Rev 0.929a
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.7MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
  _
 /
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 7
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:21:e4:65
|   |   mac-addr1: 00:80:2f:21:e4:66
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.50.2
|   |   subnet3: 255.255.255.0
|   |   serial: 30AAD25
|   |   FW Version: 5.1
|   |   FPGA Version: 33.0
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo,
ref_locked
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: TwinRX v1.1 (0x0093)
|   |   |   Serial: 3129E7C
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: TwinRX RX0
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: II
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 1
|   |   |   |   Name: TwinRX RX1
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: QQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   RX Dboard: B
|   |   |   ID: TwinRX v1.1 (0x0093)
|   |   |   Serial: 31293DD
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: TwinRX RX0
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: II
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 1
|   |   |   |   Name: TwinRX RX1
|   |   |   |   Antennas: RX1, RX2
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
|   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
|   |   |   |   Connection Type: QQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: B
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: Unknown (0x0092)
|   |   |   Serial: 312928F
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |

Re: [USRP-users] USRP TwinRX Error UHD

[Marcus D. Leech via USRP-users]

On 12/28/2017 10:10 AM, ALEJANDRO BLANCO PIZARRO via USRP-users wrote:

Dear Marcus,

Thanks for the response. The UHD version is UHD_003.010.002.000-release.

So, this version is the correct one?

Best regards,
Alejandro


Could you show us the output of:

uhd_usrp_probe --args "type=x310"



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

Re: [USRP-users] General USRP Architecture question

[Marcus Müller via USRP-users]

Dear Jose,

what Jeff says is right.

As background info:

the diagram you're referring to depicts a USRP2 or N2xx.
The 40 MHz low pass filter is a *baseband filter*. It's part of one of
the 40 MHz-bandwidth daughterboard (WBX,SBX,CBX). You could draw a
vertical line between these filters and the DAC and ADC. Left of that
vertical line is the daughterboard, right of that the motherboard.


On Tue, 2017-12-19 at 01:32 -0800, Jose Ruvalcaba via USRP-users wrote:
> Hello,
> 
> I was looking at the USRP bandwidths and Sample Rate page and noticed
> that there is a schematic of the RF frontend of the USRP. I noticed
> that underneath the Low pass filter of this schematic there is a
> value of 40 MHz. Could someone tell me what this value is?
> 
> The page I looked at was 
> https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates
> 
> Thanks,
> Jose Ruvalcaba
> ___
> 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

Re: [USRP-users] USRP TwinRX Error UHD

[ALEJANDRO BLANCO PIZARRO via USRP-users]

Dear Marcus,

Thanks for the response. The UHD version is UHD_003.010.002.000-release.

So, this version is the correct one?

Best regards,
Alejandro

2017-12-28 15:54 GMT+01:00 Marcus Müller :

> Dear Alejandro,
>
> my guess is that you use an old version of UHD. Which version are you
> using?
>
> Best regards,
> Marcus
>
> On Thu, 2017-12-21 at 18:28 +0100, ALEJANDRO BLANCO PIZARRO via USRP-
> users wrote:
> > Dear community,
> >
> > I am trying to capture IQ samples with a USRP x310 with 2 twinRXs
> > using the srsLTE(c program). I have an UHD error:
> >
> > UHD Error:
> > 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.
> > RuntimeError: TwinRX not supported on this motherboard
> >
> > This errors occurs when the funcion is executed:
> > uhd_usrp_make(&handler->usrp, args) using with this args:
> > type=x300,master_clock_rate=184.32e6. This function is within this
> > library . Anyone knows how is the correct way to configure a
> > usrp with 2 TwinRX?
> >
> > Besides, the TwinRXs are well recognized by the pc using
> > uhd_usrp_probe (it is possible to use uhd_fft for all ports).
> >
> > Let me know if further information is needed to solve this issue.
> >
> > Best regards,
> > Alejandro
> >
> > ___
> > 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

Re: [USRP-users] USRP Timed command in GR (stream TX and command port RX) simulaneous

[Marcus Müller via USRP-users]

Hi Claude, 

there's only one FIFO per radio.

"Tags" is a GNU Radio concept. GNU Radio's USRP blocks take these tags
and messgaes, and issue UHD tune_request.
So, yes, in the end, there's only one way to tune, and that goes
through a FIFO.

Best regards,
Marcus
 
On Thu, 2017-12-21 at 11:35 +0100, LEMENAGER Claude via USRP-users
wrote:
> Hello,
> As no answer received, and after an (not in depth) analysis of
> USRP_SINK, USRP_SOURCE, I found:
> -   Dsp_freq and lo_freq message were associated with
> POLICY_MANUAL on the other parameter  (then, when a dsp_treq message
> is issued, a full tuning of analog board is performed)
> -   On the TX part when a tx_freq tag is issued with a tx_sob tag
> and a tx_time tag at the first sample of a sample set, the tx_freq is
> performed immediately without respect of the buffering, resulting in
> a tune before the asked time.
> Just two questions:
> Is there just one FIFO (TX and RX in the same) for timed commands or
> two FIFOs (allowing no fine control of the time between commands to
> RX and TX)?
> RX tuning is performed through messages as TX tuning can be done
> through tags. Does implementation (when timing is required) goes
> through the FIFO(s) to perform the operation?
>  
> Regards,
> Claude
> ==
> Hello,
>  
> I  try to send frequency radio tuning commands to TX (USRP_SINK) and
> RX (USRP_SOURCE) in the same Gnu Radio companion design using the
> same usrp (N210 or X310 for TX and RX.
> The USRP_SINK block is feed by a stream which has tags tx_eob and
> tx_sob associated with tx_time and tx_freq tags (are tx_lo_freq and
> tx_dsp_freq usable)?.
> The URSP_SOURCE receives “command” message with time and dsp_freq,
> lo_freq keys and pmt values.
> The time key of the USRP_SOURCE message has a value delayed
> (adjustable ) with respect of tx_time tagged in the stream of
> USRP_SINK.
> I can check that, without RX command, TX is OK (external scope and
> specrum analyzer)
> That’s not the case when I issue the commands to RX, even when I
> sleep the delay to send the message and L characters appear (late
> command error seen by UHD, more delayè more L).
> Remembering that the FIFO of timed command of is common for the board
> (no TX or RX specific FIFO) the question is :
> how to avoid discrepancy in the time between TX stream (or PDU-tagged 
> stream Block) and RX commands? (I think my RX command arrives in the
> FIFO before the tx_sob/tx_freq tag)
>  
> is it possible to put a tx_freq tag with a tx_eob tag on a stream (is
> then the lo prepositioned?)?
>  
> Excuse me is somebody asked about the same problem before (I don’t
> find tracks about that).
>  
> Can anybody help?
>  
> Thanks for support
>  
> Claude Leménager
>  
> ___
> 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

Re: [USRP-users] USRP TwinRX Error UHD

[Marcus Müller via USRP-users]

Dear Alejandro,

my guess is that you use an old version of UHD. Which version are you
using?

Best regards,
Marcus

On Thu, 2017-12-21 at 18:28 +0100, ALEJANDRO BLANCO PIZARRO via USRP-
users wrote:
> Dear community,
> 
> I am trying to capture IQ samples with a USRP x310 with 2 twinRXs
> using the srsLTE(c program). I have an UHD error:
> 
> UHD Error:
> 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.
> RuntimeError: TwinRX not supported on this motherboard
> 
> This errors occurs when the funcion is executed:
> uhd_usrp_make(&handler->usrp, args) using with this args:
> type=x300,master_clock_rate=184.32e6. This function is within this
> library . Anyone knows how is the correct way to configure a
> usrp with 2 TwinRX?
> 
> Besides, the TwinRXs are well recognized by the pc using
> uhd_usrp_probe (it is possible to use uhd_fft for all ports).
> 
> Let me know if further information is needed to solve this issue.
> 
> Best regards,
> Alejandro
> 
> ___
> 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

Re: [USRP-users] DC USRP N210

[Marcus Müller via USRP-users]

Hi Ivan,

what's your sampling rate, what is the bandwidth of the signal you're
interested in?

Best regards,
Marcus

On Fri, 2017-12-22 at 14:10 +0200, Ivan Zahartchuk via USRP-users
wrote:
> 
> Hello. Please tell me how to remove the constant component in the
> USRP N210 SBX.
> I was recommended to set lo_offset so that the frequency was outside
> the viewed band. but at the same time the spectrum is very distorted.
> 
> ___
> 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

Re: [USRP-users] Get NMEA data from usrp in gnuradio

[Marcus Müller via USRP-users]

Yes:

https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html#a41
9f5d60d9ca48d162c4001f79511c85

Compare the get_mboard_sensor method that's wrapping through GNU Radio
SWIGging UHD's own method:

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a2d
3c327bcb83fd274e05e3ca95d1ac95

which is, for example, used in
 
https://github.com/EttusResearch/uhd/blob/maint/host/utils/query_gpsdo_
sensors.cpp 

Best regards,
Marcus
 
On Tue, 2017-12-26 at 20:56 +, Snehasish Kar via USRP-users wrote:
> Hello 
> 
> Is there any way to get nmea data from GPSDO in gnuradio.
> 
> BR
> Snehasish 
> 
> ___
> 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

[USRP-users] updated version of rfnoc block poly-phase channelizer

[Anselm Karl via USRP-users]

Hi all,

I have rebuild my poly-phase channelizer block based on the the current uhd
version.

Find it on https://github.com/e33b1711/rfnoc-ppchan.

It is a RFNoC OOT-Module. Simulation, building and installation like
described in the RFNoC Getting Started Guide.

Feel free to use it and to write me.

BR,

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

Re: [USRP-users] If I can change the DDR3L by myself

[Robin Coxe via USRP-users]

Hi Hu.  Before you start desoldering chips from the circuit board, could
you be more specific about how your E312 "didn't work"?   It may be
possible to resurrect your E312 by means of less extreme measures.

What were you trying to do with it?  Did it boot?  If not, could you
connect to the device over the UART and post the log messages from the
startup sequence?

-Robin




On Thu, Dec 28, 2017 at 3:06 AM, Hu Chaoran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> My usrp e312  didn't work and I think it was because of the chip DDR3L
> stop working. I want to replace a new one by myself. but I can only find
> DDR3 with speed of 933MHz, maybe the speed is different  with the old one.
> I don't know if it is ok to change it. and when I change it, if I need to
> change the software of the system at the same time?
>
> Thank u very much.
>
>
> Regards.
>
> -Hu.
>
> ___
> 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

[USRP-users] If I can change the DDR3L by myself

[Hu Chaoran via USRP-users]

Hello,

My usrp e312  didn't work and I think it was because of the chip DDR3L stop 
working. I want to replace a new one by myself. but I can only find  DDR3 with 
speed of 933MHz, maybe the speed is different  with the old one. I don't know 
if it is ok to change it. and when I change it, if I need to change the 
software of the system at the same time?

Thank u very much.


Regards.

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