[USRP-users] B200 GPS Antenna Port Current Limit

[Jan Safar via USRP-users]

Hello,

Please can you advise the maximum current that can be drawn from the GPS 
Antenna port on the B200?

I'm thinking of using an active antenna which should draw less than 30 mA and 
an amplified GPS splitter which draws 15 mA - can the B200 supply 45 mA on the 
antenna port?

Also, the page linked below says that the B200 GPSDO 'is capable of supplying a 
3V for active GPS antennas' ...
http://files.ettus.com/manual/page_gpsdo_b2x0.html

... but this page suggests the B200 requires a 5V antenna:
https://www.ettus.com/product/details/GPS-ANT-5V

Am I right in assuming that the B200 supplies 5V on the GPS Antenna port?

Thanks & regards,
Jan Safar
This communication, together with any files or attachments transmitted with it 
contains information that is confidential and may be subject to legal privilege 
and is intended solely for the use by the named recipient. If you are not the 
intended recipient you must not copy, distribute, publish or take any action in 
reliance on it. If you have received this communication in error, please notify 
the sender and securely delete it from your computer systems. Trinity House 
reserves the right to monitor all communications for lawful purposes. The 
contents of this email are protected under international copyright law. This 
email originated from the Corporation of Trinity House of Deptford Strond which 
is incorporated by Royal Charter in England and Wales. The Royal Charter number 
is RC 000622. The Registered office is Trinity House, Tower Hill, London, EC3N 
4DH.

The Corporation of Trinity House, collect and process Personal Data for the 
Lawful Purpose of fulfilling our responsibilities as the appointed General 
Lighthouse Authority for our area of responsibility under Section 193 of the 
Merchant Shipping Act 1995 (as amended).

We understand that our employees, customers and other third parties are 
entitled to know that their personal data is processed lawfully, within their 
rights, not used for any purpose unintended by them, and will not accidentally 
fall into the hands of a third party.

Our policy covering our approach to Data Protection complies with UK law 
accordingly implemented, including that required by the EU General Data 
Protection Regulation (GDPR 2016), and can be accessed via our Privacy Notice 
and Legal Notice listed on our website 
(www.trinityhouse.co.uk)

https://www.trinityhouse.co.uk/legal-notices
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] 10GB Ethernet and compatibility uhd and fpga image

[Disco Daniele via USRP-users]

Hi!
For a 5G application, I'm trying to use an X310 with a direct ethernet 
connection between board and pc with rate of 10GB.
For this purpose I'm using the NIC INTEL ETH Converged NTWK ADPTR-SR2.
Like Linux box  I'm using an UBUNTU 18.04 low latency.

To to that I

  *   Download from the Intel site the linux driver ixgbe and compiled 
following the related instructions
  *   Download the uhd_003.010.003.000-release  (31-Jan-2018)
  *   Following the instruction found here 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
 I installed uhd (make test ==> 100%)
  *   Insert a optical SFP in the port 1 of X310 (verifying on the Linux box 
that this link is at 10GB) and by mean a couple of optical fiber I pinged the 
board (ping 192.168.40.2) and the ping respond correctly
  *   I used the python script uhd_images_download to download the images in 
/usr/local/share/uhd/images
  *   I burned the fpga with the command /usr/local/bin/uhd_image_loader 
-args="type=x300,addr=192.168.40.2"
  *   Attached you can find the output of the two command "uhd_find_device" and 
"uhd_usrp_probe"

A this point running the application I obtain this message:

Creating the usrp device with: master_clock_rate=18432...
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; 
UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Setup basic communication...
Error: RuntimeError: Expected FPGA compatibility number 35, but got 33:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

"/usr/local/lib/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"/usr/local/bin/uhd_image_loader" --args="type=x300,addr=192.168.40.2"

For more information, refer to the UHD manual:

http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash


PLEASE, could you help me to select the right image to download and solve my 
issue?

Thank You
Daniele



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.
uhd_find_device: ==>

linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.HEAD-0-gef157678

--
-- UHD Device 0
--
Device Address:
type: x300
addr: 192.168.40.2
fpga: HG
name: 
serial: 3158D0A
product: X310




uhd_usrp_probe: ==>

linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.HEAD-0-gef157678

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1295.9MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1294.9MB/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: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:19:53:d3
|   |   mac-addr1: 00:80:2f:19:53:d4
|   |   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.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 3158D0A
|   |   FW Version: 5.1
|   |   FPGA Version: 33.0
|   |   RFNoC capable: Yes
|   |   
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | 

Re: [USRP-users] Hello,

[Brais Ares via USRP-users]

Thanks Sam! If I understand correctly the link that you refer to, it is
possible to obtain time and phase synchronization with B210s, so the only
issue would be to compensate phase offset which could be done by software.
Could you elaborate a little bit more? I'm probably missunderstading the
thread you link, but from it I take that MIMO implementations are possible
with B210. Also, can you provide any link for the difference between B210
and N210 that allows to use the later but not the former?

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

[USRP-users] Implementing num_samps_and_done on python

[Ivan Zahartchuk via USRP-users]

Hello. Please tell me examples of cyclic reading of data from the USRP
N210 card in the num_samps_and_done mode. And the possible change of
parameters in the intervals between reading. I'm trying to work with
on python
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Kernel Sources

[Said Uçar via USRP-users]

Hi Philip,


I write the image you provided and it booted without trouble. I set the 
KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module 
but failed at first, as expected. I given an error;


            /bin/sh: scripts/basic/fixdep: No such file or directory

Then I built all modules in kernel sources using the following commands;

            cd /usr/src/kernel

            make modules_prepare

            make modules

            make modules_install

That took some time, but at the end I can manage to build batman without 
error. However, I couldn't use the build batman-adv.ko. When I tried to 
insmod the module, I given an error;


            modprobe: ERROR: could not insert 'batman_adv': Unknown 
symbol in module, or unknown parameter (see dmesg)


And the kernel log was;

            [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)


The output of  'cat /proc/kallsyms | grep crc'  command;

            c02cd8d8 t crc32c_cra_init
            c0303250 t crc32_generic_shift
            c03032d8 T crc32_le_shift
            c03032e4 T __crc32c_le_shift
            c03032f0 T crc32_le
            c0303438 T __crc32c_le
            c0303580 T crc32_be
            c030a2f0 t crc32_validate
            c091364c t crc32c_mod_init

And I assume that crc32c module is exists? I stuck at this point, and 
googling didn't helped.



There is one more thing, I asked the kernel upgrade process to the ETTUS 
Support, they replied with the following;


            "Upgrading the kernel would require you to port our 
drivers. That probably isn't feasible."



Regarding that answer, how could you managed to build image with kernel 
4.9 for e310 devices?



Thank you again,

Best Regards,

Said U.


On 12/12/18 12:58 AM, Philip Balister wrote:

On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:

On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:

Hi Philip,


Thank you for your answer. I believe the first option is simpler than
the second. However, I'm not familiar to building and tweaking kernel.
Is there a documentation for building and tweaking kernel for E300
series? You are definitely right about the kernel version issue (batman
did most of its features after kernel 4), I would like to test older
version because it may be sufficient for us.

I don't have any docs that would help and don't know of any on the Ettus
site. I've had an idea that might help. I have a more recent build based
on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
the kernel-devsrc package to the image. That should let you build the
kernel module on the device. No warranty though. The builder is running
now and it is a long job, I'll post a link to the updated images when
they are done.

OK, the sausage machine spit out new images to try:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Use bmaptool to write to an SD card:

sudo bmaptool copy long-file-name /dev/sdX

make sure the wic and bmap files are in the same directory.

Completely untested. But the kernel dev sources should be available for
building OOT kernel modules.

Good luck,

Philip



Philip



Best Regards,


On 12/7/18 9:48 PM, Philip Balister wrote:

On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:

Hi all,


I'm trying to build batman-adv^[1] for E310 however it required the
kernel sources since it builds /batman-adv.ko/ kernel object. I built
the batctl^[2] and alfred^[3] without problem. I searched on the
internet for kernel sources however couldn't find it. Is there a way to
build batman for e310?


So a couple of approaches to take:

1) Build the E300 linux distro locally and add recipes for the kernel
module and other parts of the software.

2) Inspect the linux kernel recipe used on the E300 and build a local
git tree, and copy the kernel config from the build area. Then build the
module against those sources.

Both are fairly straightforward, but you'll need to figure out some
OpenEmbedded stuff. All the information is a available to you.

I did peek at the kernel module to see if it would build aainst a 3.14
kernel. They do have an ifdef for kernels below 4.0, but it is clear
most work is targeted at later kernels.

Good luck!

Philip




Here is the output of 'uname -a':

     Linux ettus-e3xx-sg3 3.14.2-xilinx #1 SMP PREEMPT Thu Jan 7 14:49:20
     PST 2016 armv7l GNU/Linux


[1] = https://git.open-mesh.org/batman-adv.git

[2] = https://git.open-mesh.org/batctl.git

[3] = https://git.open-mesh.org/alfred.git


Best Regards,



___
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

Re: [USRP-users] USRP1 support: "unknown" daughterboard

[Carlos Alberto Ruiz Naranjo via USRP-users]

Hi Marcus,

I have changed the version to UHD-3.9.LTS. With *uhd_usrp_probe
--args="type=usrp1" *I haven't erros. But I don't know why the GNURadio
version hasn't changed... I have, with the previous errors :

* GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-*
*geec24d7b*

Any idea?

Thank you.

El mar., 11 dic. 2018 a las 22:42, Marcus D. Leech via USRP-users (<
usrp-users@lists.ettus.com>) escribió:

> On 12/11/2018 04:36 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote:
> > Hello,
> >
> > I have found a USRP1 and I am playing with it. I have this error:
> >
> > carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1"
> > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> > UHD_4.0.0.rfnoc-devel-702-geec24d7b
> > [INFO] [USRP1] Opening a USRP1 device...
> > [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.
> > AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6
> >   in double dbsrx::set_lo_freq(double)
> >   at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305
> >
> > _
> >  /
> > |   Device: USRP1 Device
> > | _
> > |/
> > |   |   Mboard: USRP1
> > |   |   serial: 479b9db3
> > |   |
> > |   |   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: DBSRX (0x0002)
> > |   |   | _
> > |   |   |/
> > |   |   |   |   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
> > |   |   | _
> > |   |   |/
> > |   |   |   |   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: B
> > |   |   |   |   Name: ad9522
> > |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> > |   | _
> > |   |/
> > |   |   |   TX DSP: 0
> > |   |   |
> > |   |   |   Freq range: -44.000 to 44.000 MHz
> > |   | _
> > |   |/
> > |   |   |   TX DSP: 1
> > |   |   |
> > |   |   |   Freq range: -44.000 to 44.000 MHz
> > |   | _
> > |   |/
> > |   |   |   TX Dboard: A
> > |   |   | _
> > |   |   |/
> > |   |   |   |   TX 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
> > |   |   | _
> > |   |   |/
> > |   |   |   |   TX Codec: A
> > |   |   |   |   Name: ad9522
> > |   |   |   |   Gain range pga: -20.0 to 0.0 step 0.1 dB
> > |   | _
> > |   |/
> > |   |   |   TX Dboard: B
> > |   |   | _
> > |   |   |/
> > |   |   |   |   TX Frontend: 0
> > |   |   |   |   Name: Unknown (0x) - 0
> > |   |   |   | 

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
> Hi Philip,
> 
> 
> I write the image you provided and it booted without trouble. I set the
> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
> but failed at first, as expected. I given an error;
> 
>             /bin/sh: scripts/basic/fixdep: No such file or directory
> 
> Then I built all modules in kernel sources using the following commands;
> 
>             cd /usr/src/kernel
> 
>             make modules_prepare
> 
>             make modules
> 
>             make modules_install
> 
> That took some time, but at the end I can manage to build batman without
> error. However, I couldn't use the build batman-adv.ko. When I tried to
> insmod the module, I given an error;
> 
>             modprobe: ERROR: could not insert 'batman_adv': Unknown
> symbol in module, or unknown parameter (see dmesg)
> 
> And the kernel log was;
> 
>             [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)

I think there is another kernel option needed:

https://cateee.net/lkddb/web-lkddb/LIBCRC32C.html

I'll make the change and kick off the sausage machine. Unfortunately it
is set to do a clean build (to avoid a certain class of failures) so the
build takes along time to create all the images and sdks, then another
few hours to upload. Doing incremental builds locally would save you a
lot of time:

I think the README here will walk you through the process:

https://github.com/balister/sdr-build/tree/rocko-e300

I'll let you know when the upload is done.

> 
> 
> The output of  'cat /proc/kallsyms | grep crc'  command;
> 
>             c02cd8d8 t crc32c_cra_init
>             c0303250 t crc32_generic_shift
>             c03032d8 T crc32_le_shift
>             c03032e4 T __crc32c_le_shift
>             c03032f0 T crc32_le
>             c0303438 T __crc32c_le
>             c0303580 T crc32_be
>             c030a2f0 t crc32_validate
>             c091364c t crc32c_mod_init
> 
> And I assume that crc32c module is exists? I stuck at this point, and
> googling didn't helped.
> 
> 
> There is one more thing, I asked the kernel upgrade process to the ETTUS
> Support, they replied with the following;
> 
>             "Upgrading the kernel would require you to port our drivers.
> That probably isn't feasible."

Um, clearly that isn't an accurate statement. I've seen it done a few
times, and Kurt Kiefer published his work which I built on to make these
images.

Philip


> 
> 
> Regarding that answer, how could you managed to build image with kernel
> 4.9 for e310 devices?
> 
> 
> Thank you again,
> 
> Best Regards,
> 
> Said U.
> 
> 
> On 12/12/18 12:58 AM, Philip Balister wrote:
>> On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:
>>> On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
 Hi Philip,


 Thank you for your answer. I believe the first option is simpler than
 the second. However, I'm not familiar to building and tweaking kernel.
 Is there a documentation for building and tweaking kernel for E300
 series? You are definitely right about the kernel version issue (batman
 did most of its features after kernel 4), I would like to test older
 version because it may be sufficient for us.
>>> I don't have any docs that would help and don't know of any on the Ettus
>>> site. I've had an idea that might help. I have a more recent build based
>>> on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
>>> the kernel-devsrc package to the image. That should let you build the
>>> kernel module on the device. No warranty though. The builder is running
>>> now and it is a long job, I'll post a link to the updated images when
>>> they are done.
>> OK, the sausage machine spit out new images to try:
>>
>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>
>> Use bmaptool to write to an SD card:
>>
>> sudo bmaptool copy long-file-name /dev/sdX
>>
>> make sure the wic and bmap files are in the same directory.
>>
>> Completely untested. But the kernel dev sources should be available for
>> building OOT kernel modules.
>>
>> Good luck,
>>
>> Philip
>>
>>
>>> Philip
>>>

 Best Regards,


 On 12/7/18 9:48 PM, Philip Balister wrote:
> On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
>> Hi all,
>>
>>
>> I'm trying to build batman-adv^[1] for E310 however it required the
>> kernel sources since it builds /batman-adv.ko/ kernel object. I built
>> the batctl^[2] and alfred^[3] without problem. I searched on the
>> internet for kernel sources however couldn't find it. Is there a
>> way to
>> build batman for e310?
>>
> So a couple of approaches to take:
>
> 1) Build the E300 linux distro locally and add recipes for the kernel
> module and other parts of the software.
>
> 2) Inspect the linux kernel recipe used on the E300 and build a local
> git tree, and copy the kernel confi

Re: [USRP-users] Hello,

[Ian Buckley via USRP-users]

Brais, 
Sam sent you a little bit the wrong direction there, the B200mini has the PLL 
phase noise issue that precludes use in a MIMO system.
The B210 can be fully time and frequency locked to an external 10MHz reference 
and PPS.
What is slightly tricky about using multiple B210’s in a MIMO configuration is 
that the internal frequency synthesizers will have a residual phase ambiguity 
after they have been configured, and this must be characterized and compensated 
for after any retune.

Watch this to gain insight into the issues involved: 
https://www.analog.com/en/education/education-library/webcasts/developing-multiple-input-multiple-output.html
-Ian

> On Dec 12, 2018, at 2:30 AM, Brais Ares via USRP-users 
>  wrote:
> 
> Thanks Sam! If I understand correctly the link that you refer to, it is 
> possible to obtain time and phase synchronization with B210s, so the only 
> issue would be to compensate phase offset which could be done by software. 
> Could you elaborate a little bit more? I'm probably missunderstading the 
> thread you link, but from it I take that MIMO implementations are possible 
> with B210. Also, can you provide any link for the difference between B210 and 
> N210 that allows to use the later but not the former?
> 
> Regards,
> Brais.
> 
> ___
> 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] USRP1 support: "unknown" daughterboard

[Robin Coxe via USRP-users]

You may have multiple versions of GNU Radio and/or UHD libraries still 
installed on your PC.  Try navigating to the wherever you installed them (e.g., 
/usr/local/lib) and deleting the ones you don’t want by hand.



Robin Coxe | Chief R&D Program Manager, SDR | Santa Clara, CA | 408.610.6363


From: USRP-users  on behalf of Carlos 
Alberto Ruiz Naranjo via USRP-users 
Sent: Wednesday, December 12, 2018 4:17 AM
To: patchvonbr...@gmail.com
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] USRP1 support: "unknown" daughterboard

Hi Marcus,

I have changed the version to UHD-3.9.LTS. With uhd_usrp_probe 
--args="type=usrp1" I haven't erros. But I don't know why the GNURadio version 
hasn't changed... I have, with the previous errors :

GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-geec24d7b

Any idea?

Thank you.

El mar., 11 dic. 2018 a las 22:42, Marcus D. Leech via USRP-users 
(mailto:usrp-users@lists.ettus.com>>) escribió:
On 12/11/2018 04:36 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote:
> Hello,
>
> I have found a USRP1 and I am playing with it. I have this error:
>
> carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [INFO] [USRP1] Opening a USRP1 device...
> [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.
> AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6
>   in double dbsrx::set_lo_freq(double)
>   at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305
>
> _
>  /
> |   Device: USRP1 Device
> | _
> |/
> |   |   Mboard: USRP1
> |   |   serial: 479b9db3
> |   |
> |   |   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: DBSRX (0x0002)
> |   |   | _
> |   |   |/
> |   |   |   |   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
> |   |   | _
> |   |   |/
> |   |   |   |   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: B
> |   |   |   |   Name: ad9522
> |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: -44.000 to 44.000 MHz
> |   | _
> |   |/
> |   |   |   TX DSP: 1
> |   |   |
> |   |   |   Freq range: -44.000 to 44.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   | _
> |   |   |/
> |   |   |   |   TX 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
> |   |   | _
> |   |   |/
> |   |   |   |   TX Codec: A
> |   |   |   |   Name: ad9522
> |

Re: [USRP-users] 10GB Ethernet and compatibility uhd and fpga image

[Marcus D. Leech via USRP-users]

On 12/12/2018 04:48 AM, Disco Daniele via USRP-users wrote:


Hi!

For a 5G application, I’m trying to use an X310 with a direct ethernet 
connection between board and pc with rate of 10GB.


For this purpose I’m using the NIC INTEL ETH Converged NTWK ADPTR-SR2.

Like Linux box  I’m using an UBUNTU 18.04 low latency.

To to that I

  * Download from the Intel site the linux driver ixgbe and compiled
following the related instructions
  * Download the uhd_003.010.003.000-release (31-Jan-2018)
  * Following the instruction found here

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux


I installed uhd (make test è100%)
  * Insert a optical SFP in the port 1 of X310 (verifying on the Linux
box that this link is at 10GB) and by mean a couple of optical
fiber I pinged the board (ping 192.168.40.2) and the ping respond
correctly
  * I used the python script uhd_images_download to download the
images in /usr/local/share/uhd/images
  * I burned the fpga with the command /usr/local/bin/uhd_image_loader
–args=”type=x300,addr=192.168.40.2”
  * Attached you can find the output of the two command
“uhd_find_device” and “uhd_usrp_probe”

A this point running the application I obtain this message:

Creating the usrp device with: master_clock_rate=18432...

[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; 
UHD_3.11.0.HEAD-0-ga1b5c4ae


[INFO] [X300] X300 initialization sequence...

[INFO] [X300] Determining maximum frame size...

[INFO] [X300] Maximum frame size: 8000 bytes.

[INFO] [X300] Setup basic communication...

Error: RuntimeError: Expected FPGA compatibility number 35, but got 33:

The FPGA image on your device is not compatible with this host code build.

Download the appropriate FPGA images for this version of UHD.

Please run:

"/usr/local/lib/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your

USRP X3xx device using the image loader utility. Use this command:

"/usr/local/bin/uhd_image_loader" --args="type=x300,addr=192.168.40.2"

For more information, refer to the UHD manual:

http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash

PLEASE, could you help me to select the right image to download and 
solve my issue?


Thank You

Daniele


You almost certainly now have a "mixed" system installation with bits of 
both UHD 3.11 series and the 3.10 you downloaded--note the

  header on the uhd_usrp_probe output.

So the images downloader was downloading for the release it was linked 
against, but you're running a "probe" command that is one

  release ahead, and it thus expects a newer FPGA image.

I suggest removing both of your UHD instances, and starting again.


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

Re: [USRP-users] B200 GPS Antenna Port Current Limit

[Marcus D. Leech via USRP-users]

On 12/12/2018 04:00 AM, Jan Safar via USRP-users wrote:


Hello,

Please can you advise the maximum current that can be drawn from the 
GPS Antenna port on the B200?


I’m thinking of using an active antenna which should draw less than 30 
mA and an amplified GPS splitter which draws 15 mA – can the B200 
supply 45 mA on the antenna port?


Also, the page linked below says that the B200 GPSDO ‘is capable of 
supplying a 3V for active GPS antennas’ …


http://files.ettus.com/manual/page_gpsdo_b2x0.html

… but this page suggests the B200 requires a 5V antenna:

https://www.ettus.com/product/details/GPS-ANT-5V

Am I right in assuming that the B200 supplies 5V on the GPS Antenna port?


Most GPS 5V antennas will be perfectly happy with 3.3V, and I THINK 
that's the case here.


The GPSDO module for the B2xx is one of these, from Jackson Labs:

http://www.jackson-labs.com/index.php/products/lc_xo


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

Re: [USRP-users] Question B210 installation of C++ driver under Visual Studio 2017

[Brock Collins via USRP-users]

Where in the process is it failing? Are you able to generate the project files 
with CMake or is the issue coming up during the build in Visual Studio?

Regards,

Brock


From: USRP-users  On Behalf Of Bernd Witzel 
via USRP-users
Sent: Tuesday, December 11, 2018 1:11 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Question B210 installation of C++ driver under Visual 
Studio 2017

Hello

I have a problem to install the C++ driver. I use as an reference
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows
Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on 
Windows - Ettus Knowledge 
Base
Abstract. This Application Note provides a step-by-step guide for building, 
installing, and updating the open-source toolchain, specifically UHD and GNU 
Radio, for the USRP from source code on Windows.
kb.ettus.com

I am using Visual C++ 2017. What versions of boost, LibUSB Python Mako, Doxygen 
and NSIS I have to use ? I used the CMake version 32bit. Everything under 
windows 10.
I tried without success now many combinations.

Thank you
Bernd

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

Re: [USRP-users] B200 GPS Antenna Port Current Limit

[Jan Safar via USRP-users]

Thank you, Marcus - that looks promising.

Best regards,
Jan

From: USRP-users  On Behalf Of Marcus D. 
Leech via USRP-users
Sent: 12 December 2018 18:49
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B200 GPS Antenna Port Current Limit

On 12/12/2018 04:00 AM, Jan Safar via USRP-users wrote:
Hello,

Please can you advise the maximum current that can be drawn from the GPS 
Antenna port on the B200?

I'm thinking of using an active antenna which should draw less than 30 mA and 
an amplified GPS splitter which draws 15 mA - can the B200 supply 45 mA on the 
antenna port?

Also, the page linked below says that the B200 GPSDO 'is capable of supplying a 
3V for active GPS antennas' ...
http://files.ettus.com/manual/page_gpsdo_b2x0.html

... but this page suggests the B200 requires a 5V antenna:
https://www.ettus.com/product/details/GPS-ANT-5V

Am I right in assuming that the B200 supplies 5V on the GPS Antenna port?


Most GPS 5V antennas will be perfectly happy with 3.3V, and I THINK that's the 
case here.

The GPSDO module for the B2xx is one of these, from Jackson Labs:

http://www.jackson-labs.com/index.php/products/lc_xo
This communication, together with any files or attachments transmitted with it 
contains information that is confidential and may be subject to legal privilege 
and is intended solely for the use by the named recipient. If you are not the 
intended recipient you must not copy, distribute, publish or take any action in 
reliance on it. If you have received this communication in error, please notify 
the sender and securely delete it from your computer systems. Trinity House 
reserves the right to monitor all communications for lawful purposes. The 
contents of this email are protected under international copyright law. This 
email originated from the Corporation of Trinity House of Deptford Strond which 
is incorporated by Royal Charter in England and Wales. The Royal Charter number 
is RC 000622. The Registered office is Trinity House, Tower Hill, London, EC3N 
4DH.

The Corporation of Trinity House, collect and process Personal Data for the 
Lawful Purpose of fulfilling our responsibilities as the appointed General 
Lighthouse Authority for our area of responsibility under Section 193 of the 
Merchant Shipping Act 1995 (as amended).

We understand that our employees, customers and other third parties are 
entitled to know that their personal data is processed lawfully, within their 
rights, not used for any purpose unintended by them, and will not accidentally 
fall into the hands of a third party.

Our policy covering our approach to Data Protection complies with UK law 
accordingly implemented, including that required by the EU General Data 
Protection Regulation (GDPR 2016), and can be accessed via our Privacy Notice 
and Legal Notice listed on our website 
(www.trinityhouse.co.uk)

https://www.trinityhouse.co.uk/legal-notices
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

OK Dropbox updated:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Thanks for testing.

Philip

On 12/12/2018 07:16 AM, Philip Balister via USRP-users wrote:
> On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
>> Hi Philip,
>>
>>
>> I write the image you provided and it booted without trouble. I set the
>> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
>> but failed at first, as expected. I given an error;
>>
>>             /bin/sh: scripts/basic/fixdep: No such file or directory
>>
>> Then I built all modules in kernel sources using the following commands;
>>
>>             cd /usr/src/kernel
>>
>>             make modules_prepare
>>
>>             make modules
>>
>>             make modules_install
>>
>> That took some time, but at the end I can manage to build batman without
>> error. However, I couldn't use the build batman-adv.ko. When I tried to
>> insmod the module, I given an error;
>>
>>             modprobe: ERROR: could not insert 'batman_adv': Unknown
>> symbol in module, or unknown parameter (see dmesg)
>>
>> And the kernel log was;
>>
>>             [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)
> 
> I think there is another kernel option needed:
> 
> https://cateee.net/lkddb/web-lkddb/LIBCRC32C.html
> 
> I'll make the change and kick off the sausage machine. Unfortunately it
> is set to do a clean build (to avoid a certain class of failures) so the
> build takes along time to create all the images and sdks, then another
> few hours to upload. Doing incremental builds locally would save you a
> lot of time:
> 
> I think the README here will walk you through the process:
> 
> https://github.com/balister/sdr-build/tree/rocko-e300
> 
> I'll let you know when the upload is done.
> 
>>
>>
>> The output of  'cat /proc/kallsyms | grep crc'  command;
>>
>>             c02cd8d8 t crc32c_cra_init
>>             c0303250 t crc32_generic_shift
>>             c03032d8 T crc32_le_shift
>>             c03032e4 T __crc32c_le_shift
>>             c03032f0 T crc32_le
>>             c0303438 T __crc32c_le
>>             c0303580 T crc32_be
>>             c030a2f0 t crc32_validate
>>             c091364c t crc32c_mod_init
>>
>> And I assume that crc32c module is exists? I stuck at this point, and
>> googling didn't helped.
>>
>>
>> There is one more thing, I asked the kernel upgrade process to the ETTUS
>> Support, they replied with the following;
>>
>>             "Upgrading the kernel would require you to port our drivers.
>> That probably isn't feasible."
> 
> Um, clearly that isn't an accurate statement. I've seen it done a few
> times, and Kurt Kiefer published his work which I built on to make these
> images.
> 
> Philip
> 
> 
>>
>>
>> Regarding that answer, how could you managed to build image with kernel
>> 4.9 for e310 devices?
>>
>>
>> Thank you again,
>>
>> Best Regards,
>>
>> Said U.
>>
>>
>> On 12/12/18 12:58 AM, Philip Balister wrote:
>>> On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:
 On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
> Hi Philip,
>
>
> Thank you for your answer. I believe the first option is simpler than
> the second. However, I'm not familiar to building and tweaking kernel.
> Is there a documentation for building and tweaking kernel for E300
> series? You are definitely right about the kernel version issue (batman
> did most of its features after kernel 4), I would like to test older
> version because it may be sufficient for us.
 I don't have any docs that would help and don't know of any on the Ettus
 site. I've had an idea that might help. I have a more recent build based
 on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
 the kernel-devsrc package to the image. That should let you build the
 kernel module on the device. No warranty though. The builder is running
 now and it is a long job, I'll post a link to the updated images when
 they are done.
>>> OK, the sausage machine spit out new images to try:
>>>
>>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>>
>>> Use bmaptool to write to an SD card:
>>>
>>> sudo bmaptool copy long-file-name /dev/sdX
>>>
>>> make sure the wic and bmap files are in the same directory.
>>>
>>> Completely untested. But the kernel dev sources should be available for
>>> building OOT kernel modules.
>>>
>>> Good luck,
>>>
>>> Philip
>>>
>>>
 Philip

>
> Best Regards,
>
>
> On 12/7/18 9:48 PM, Philip Balister wrote:
>> On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
>>> Hi all,
>>>
>>>
>>> I'm trying to build batman-adv^[1] for E310 however it required the
>>> kernel sources since it builds /batman-adv.ko/ kernel object. I built
>>> the batctl^[2] and alfred^[3] without problem. I searched on the
>>> internet for kernel sources however couldn't find it. Is there a
>>> way to