Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Problem with gr-ettus OFDM sync block (Sergio Cruz Perez)
2. USRP N210 uhd_usrp_probe after updating from UHD_003.006.002
to UHD_003_009_003 (Damindra Bandara)
3. Re: USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003 (Marcus D. Leech)
4. Octoclock-G GPS Lock (Topliff, Charles Alexander)
5. Re: Octoclock-G GPS Lock (Derek Kozel)
6. Re: Octoclock-G GPS Lock (Derek Kozel)
7. Re: USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003 (Damindra Bandara)
8. Re: USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003 (Marcus D. Leech)
9. Re: USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003 (Damindra Bandara)
10. USRP X310 FPGA (Ziang Gao)
11. Re: USRP X310 FPGA (Robin Coxe)
12. Re: USRP X310 FPGA (Marcus M?ller)
13. Re: USRP X310 FPGA (Marcus M?ller)
14. Re: b210 load fpga error (john liu)
15. Re: transmitting of ubx (john liu)
16. Re: Unable to get Vivado Hardware Manager to recognize the
Chipscope ILA cores in the Ettus x310 (Swanson, Craig)
17. full duplex about x310 (liu Jong)
18. Not sure how to remove tuser CHDR header control and data
from m_axis_data_tdata and s_axis_data_tdata in noc_block
(Swanson, Craig)
19. Re: full duplex about x310 (Derek Kozel)
20. Re: transmitting of ubx (Michael West)
21. Custom UHD Program terminate during set_clock_ref (Patrick Berger)
22. B210 not recognized over USB 3 in Windows 7 (????)
23. Re: B210 not recognized over USB 3 in Windows 7 (Marcus M?ller)
24. E310 NFS boot (Pablo Colodr?n)
25. ??RE: B210 not recognized over USB 3 in Windows 7 (????)
26. Re: Octoclock-G GPS Lock (Topliff, Charles Alexander)
27. Re: E310 NFS boot (Philip Balister)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Jun 2016 12:23:13 -0500
From: Sergio Cruz Perez <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] Problem with gr-ettus OFDM sync block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin,
To continue with the thread [1] started in [2]. The branches I'm using are
rfnoc-ofdm for uhd and master for gr-ettus. As I mentioned in a previous
message, I had to modify uhd_rfnoc_schmidlcox.xml and schmidlcox.xml files in
my gr-ettus and uhd local repos respectively, to include the correct registers.
I attached those files
Thanks
Sergio
[1] http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/19573[2]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/018835.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/d6c9dfe8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schmidl_test.png
Type: image/png
Size: 48873 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/d6c9dfe8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_rfnoc_schmidlcox.xml
Type: application/xml
Size: 3799 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/d6c9dfe8/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schmidlcox.xml
Type: application/xml
Size: 3082 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/d6c9dfe8/attachment-0003.xml>
------------------------------
Message: 2
Date: Tue, 7 Jun 2016 14:27:04 -0400
From: Damindra Bandara <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003
Message-ID:
<CANpceN-Ufb8Ft4k0nOzNzyAffc+gPHDykQFEW_9eNe=cybq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am a USRP N210 user for a couple of years. I was using UHD_003_006_002.
Recently I changed the version to UHD_003_009_003. When I tried to do
uhd_usrp_probe I got a message asking to modify the FPGA image as it is not
compatible. So I did uhd_image_loader with the correct FPGA version.
However, this process failed. (I have changed the image earlier, but I
never had any problems).
After that, the USRP stopped responding. I was not even able to ping the
USRP. Also, I observed that the GB ethernet LED has changed to amber
color. I tried power cycling the USRP as well as restarting the host
computer. But nothing helped.
I appreciate if I could get any assistance to get the USRP back to working.
Thank you in advance
Damindra
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/5a578a15/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 07 Jun 2016 14:31:51 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/07/2016 02:27 PM, Damindra Bandara via USRP-users wrote:
> Hi all,
>
> I am a USRP N210 user for a couple of years. I was using
> UHD_003_006_002. Recently I changed the version to UHD_003_009_003.
> When I tried to do uhd_usrp_probe I got a message asking to modify the
> FPGA image as it is not compatible. So I did uhd_image_loader with the
> correct FPGA version. However, this process failed. (I have changed
> the image earlier, but I never had any problems).
>
> After that, the USRP stopped responding. I was not even able to ping
> the USRP. Also, I observed that the GB ethernet LED has changed to
> amber color. I tried power cycling the USRP as well as restarting the
> host computer. But nothing helped.
>
> I appreciate if I could get any assistance to get the USRP back to
> working.
>
> Thank you in advance
> Damindra
>
>
See:
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
------------------------------
Message: 4
Date: Tue, 7 Jun 2016 19:17:46 +0000
From: "Topliff, Charles Alexander" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Octoclock-G GPS Lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello All,
I am having difficulty obtaining a GPS lock using the Octoclock - G. From my
understanding, the front panel GPS LOCK LED is to light up once a GPS lock is
obtained. I am using the 5V GPS antenna purchased here:
https://www.ettus.com/product/details/GPS-ANT-5V.<https://www.ettus.com/product/details/GPS-ANT-5V>
I want to ensure that I am not missing any steps in order to get a GPS lock. I
have the Octoclock powered, but it is not connected to any host computer via
ethernet. When the antenna is connected and in an area well free of any
obstructions, it still seems that the GPS LOCK LED is not lit.
Any input or suggestions are appreciated.
Thanks,
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/dee124de/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 7 Jun 2016 12:26:53 -0700
From: Derek Kozel <[email protected]>
To: "Topliff, Charles Alexander" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock-G GPS Lock
Message-ID:
<CAA+K=tuKDsU8H=2pr2gvqdp2jezsv4bg05bssacn0uppsal...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Charles,
How long has the antenna been in sight of the sky since powering on the
Octoclock? Ethernet is not required, though it would be useful to query the
gps_lock sensor.
Regards,
Derek
On Tue, Jun 7, 2016 at 12:17 PM, Topliff, Charles Alexander via USRP-users <
[email protected]> wrote:
> Hello All,
>
>
> I am having difficulty obtaining a GPS lock using the Octoclock - G. From
> my understanding, the front panel GPS LOCK LED is to light up once a GPS
> lock is obtained. I am using the 5V GPS antenna purchased here:
> https://www.ettus.com/product/details/GPS-ANT-5V.
> <https://www.ettus.com/product/details/GPS-ANT-5V> I want to ensure that
> I am not missing any steps in order to get a GPS lock. I have the Octoclock
> powered, but it is not connected to any host computer via ethernet. When
> the antenna is connected and in an area well free of any obstructions, it
> still seems that the GPS LOCK LED is not lit.
>
> Any input or suggestions are appreciated.
>
> Thanks,
> Charles
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/8c227460/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 7 Jun 2016 12:36:09 -0700
From: Derek Kozel <[email protected]>
To: "Topliff, Charles Alexander" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock-G GPS Lock
Message-ID:
<CAA+K=tv6Y0jjjeAUP0AK_ajXKqneqV=fv0yh59x_yuc31ug...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
+usrp-users list
Hello,
I have found that it can take a quarter of an hour or more unless it has
perfect, full sky view with nothing in the way. Can you leave it running
for a while and see if a lock occurs?
Thanks,
Derek
On Tue, Jun 7, 2016 at 12:31 PM, Topliff, Charles Alexander <
[email protected]> wrote:
> I gave it a few minutes, and it did not seem to resolve any lock after
> that. Does it require an extended period of time?
>
>
>
>
>
> ------------------------------
> *From:* Derek Kozel <[email protected]>
> *Sent:* Tuesday, June 7, 2016 2:26 PM
> *To:* Topliff, Charles Alexander
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Octoclock-G GPS Lock
>
> Hello Charles,
>
> How long has the antenna been in sight of the sky since powering on the
> Octoclock? Ethernet is not required, though it would be useful to query the
> gps_lock sensor.
>
> Regards,
> Derek
>
> On Tue, Jun 7, 2016 at 12:17 PM, Topliff, Charles Alexander via USRP-users
> <[email protected]> wrote:
>
>> Hello All,
>>
>>
>> I am having difficulty obtaining a GPS lock using the Octoclock - G. From
>> my understanding, the front panel GPS LOCK LED is to light up once a GPS
>> lock is obtained. I am using the 5V GPS antenna purchased here:
>> https://www.ettus.com/product/details/GPS-ANT-5V.
>> <https://www.ettus.com/product/details/GPS-ANT-5V> I want to ensure that
>> I am not missing any steps in order to get a GPS lock. I have the Octoclock
>> powered, but it is not connected to any host computer via ethernet. When
>> the antenna is connected and in an area well free of any obstructions, it
>> still seems that the GPS LOCK LED is not lit.
>>
>> Any input or suggestions are appreciated.
>>
>> Thanks,
>> Charles
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/17d0cd50/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 7 Jun 2016 15:49:45 -0400
From: Damindra Bandara <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003
Message-ID:
<canpcen9ffscof-pxjayhjz5m6gawnbe4yezs8uwqqvdjutj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thank you very much for your quick response.
I have a follow-up question. After recovering the USRP, I tried to write
the correct image to the USRP using uhd_image_loader. This failed
similarly to the earlier situation. Herewith I have attached the output. I
appreciate if I can get some help to debug this issue.
Thanks
Damindra
Searching for USRP N2XX with IP address 192.168.10.2.
Found n200_r4.
Searching for specified images.
************************************************************************************************
WARNING: This utility will be removed in an upcoming version of UHD. In the
future, use
this command:
uhd_image_loader --args="type=usrp2,addr=192.168.10.2" \
--fw-path="/usr/local/share/uhd/images/usrp_n200_fw.bin" \
--fpga-path="/usr/local/share/uhd/images/usrp_n200_r4_fpga.bin"
************************************************************************************************
Will burn the following images:
* Firmware: /usr/local/share/uhd/images/usrp_n200_fw.bin
* FPGA: /usr/local/share/uhd/images/usrp_n200_r4_fpga.bin
Querying n200_r4 for flash information.
* Flash size: 4194304
* Sector size: 65536
Erasing FPGA image.
* Successfully erased 1572864 bytes at 1572864.
Writing FPGA image (100%).
* Successfully wrote 894912 bytes.
*Verifying FPGA image (99%).Error: Image write failed.*
On Tue, Jun 7, 2016 at 2:31 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/07/2016 02:27 PM, Damindra Bandara via USRP-users wrote:
>
>> Hi all,
>>
>> I am a USRP N210 user for a couple of years. I was using UHD_003_006_002.
>> Recently I changed the version to UHD_003_009_003. When I tried to do
>> uhd_usrp_probe I got a message asking to modify the FPGA image as it is not
>> compatible. So I did uhd_image_loader with the correct FPGA version.
>> However, this process failed. (I have changed the image earlier, but I
>> never had any problems).
>>
>> After that, the USRP stopped responding. I was not even able to ping the
>> USRP. Also, I observed that the GB ethernet LED has changed to amber
>> color. I tried power cycling the USRP as well as restarting the host
>> computer. But nothing helped.
>>
>> I appreciate if I could get any assistance to get the USRP back to
>> working.
>>
>> Thank you in advance
>> Damindra
>>
>>
>> See:
>
> http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/86cdd04f/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 07 Jun 2016 16:47:46 -0400
From: "Marcus D. Leech" <[email protected]>
To: Damindra Bandara <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/07/2016 03:49 PM, Damindra Bandara wrote:
> Hi Marcus,
>
> Thank you very much for your quick response.
>
> I have a follow-up question. After recovering the USRP, I tried to
> write the correct image to the USRP using uhd_image_loader. This
> failed similarly to the earlier situation. Herewith I have attached
> the output. I appreciate if I can get some help to debug this issue.
> Thanks
> Damindra
>
> Searching for USRP N2XX with IP address 192.168.10.2.
>
> Found n200_r4.
>
> Searching for specified images.
>
> ************************************************************************************************
>
> WARNING: This utility will be removed in an upcoming version of UHD.
> In the future, use
>
> this command:
>
> uhd_image_loader --args="type=usrp2,addr=192.168.10.2" \
>
> --fw-path="/usr/local/share/uhd/images/usrp_n200_fw.bin" \
>
> --fpga-path="/usr/local/share/uhd/images/usrp_n200_r4_fpga.bin"
>
> ************************************************************************************************
>
> Will burn the following images:
>
> * Firmware: /usr/local/share/uhd/images/usrp_n200_fw.bin
>
> * FPGA: /usr/local/share/uhd/images/usrp_n200_r4_fpga.bin
>
>
> Querying n200_r4 for flash information.
>
> * Flash size: 4194304
>
> * Sector size: 65536
>
> Erasing FPGA image.
>
> * Successfully erased 1572864 bytes at 1572864.
>
> Writing FPGA image (100%).
>
> * Successfully wrote 894912 bytes.
>
> *Verifying FPGA image (99%).Error: Image write failed.*
>
>
Hmmmm, could you do the recovery *again*, and try to use
uhd_image_loader, rather than usrp_n2xx_net_burner.py (or whichever
of the usrp_n2xx_burner utils you used).
> On Tue, Jun 7, 2016 at 2:31 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 06/07/2016 02:27 PM, Damindra Bandara via USRP-users wrote:
>
> Hi all,
>
> I am a USRP N210 user for a couple of years. I was using
> UHD_003_006_002. Recently I changed the version to
> UHD_003_009_003. When I tried to do uhd_usrp_probe I got a
> message asking to modify the FPGA image as it is not
> compatible. So I did uhd_image_loader with the correct FPGA
> version. However, this process failed. (I have changed the
> image earlier, but I never had any problems).
>
> After that, the USRP stopped responding. I was not even able
> to ping the USRP. Also, I observed that the GB ethernet LED
> has changed to amber color. I tried power cycling the USRP as
> well as restarting the host computer. But nothing helped.
>
> I appreciate if I could get any assistance to get the USRP
> back to working.
>
> Thank you in advance
> Damindra
>
>
> See:
>
> http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/bfd235a5/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 7 Jun 2016 16:53:11 -0400
From: Damindra Bandara <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP N210 uhd_usrp_probe after updating from
UHD_003.006.002 to UHD_003_009_003
Message-ID:
<CANpceN_1dno=zo4jgmwa-cohafljlzd8pm2datynorqzcxo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
When I try to do uhd_find_devices , although it finds the device properly
it gives the following error.
UHD Error:
Control packet attempt 0, sequence number 69:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 0, sequence number 73:
RuntimeError: no control response, possible packet loss
Thanks
Damindra
On Tue, Jun 7, 2016 at 4:47 PM, Marcus D. Leech <[email protected]> wrote:
> On 06/07/2016 03:49 PM, Damindra Bandara wrote:
>
> Hi Marcus,
>
> Thank you very much for your quick response.
>
> I have a follow-up question. After recovering the USRP, I tried to write
> the correct image to the USRP using uhd_image_loader. This failed
> similarly to the earlier situation. Herewith I have attached the output. I
> appreciate if I can get some help to debug this issue.
> Thanks
> Damindra
>
> Searching for USRP N2XX with IP address 192.168.10.2.
>
> Found n200_r4.
>
> Searching for specified images.
>
>
> ************************************************************************************************
>
> WARNING: This utility will be removed in an upcoming version of UHD. In
> the future, use
>
> this command:
>
> uhd_image_loader --args="type=usrp2,addr=192.168.10.2" \
>
> --fw-path="/usr/local/share/uhd/images/usrp_n200_fw.bin" \
>
> --fpga-path="/usr/local/share/uhd/images/usrp_n200_r4_fpga.bin"
>
>
> ************************************************************************************************
>
> Will burn the following images:
>
> * Firmware: /usr/local/share/uhd/images/usrp_n200_fw.bin
>
> * FPGA: /usr/local/share/uhd/images/usrp_n200_r4_fpga.bin
>
>
> Querying n200_r4 for flash information.
>
> * Flash size: 4194304
>
> * Sector size: 65536
>
> Erasing FPGA image.
>
> * Successfully erased 1572864 bytes at 1572864.
>
> Writing FPGA image (100%).
>
> * Successfully wrote 894912 bytes.
>
> *Verifying FPGA image (99%).Error: Image write failed.*
>
> Hmmmm, could you do the recovery *again*, and try to use uhd_image_loader,
> rather than usrp_n2xx_net_burner.py (or whichever
> of the usrp_n2xx_burner utils you used).
>
>
> On Tue, Jun 7, 2016 at 2:31 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 06/07/2016 02:27 PM, Damindra Bandara via USRP-users wrote:
>>
>>> Hi all,
>>>
>>> I am a USRP N210 user for a couple of years. I was using
>>> UHD_003_006_002. Recently I changed the version to UHD_003_009_003. When I
>>> tried to do uhd_usrp_probe I got a message asking to modify the FPGA image
>>> as it is not compatible. So I did uhd_image_loader with the correct FPGA
>>> version. However, this process failed. (I have changed the image earlier,
>>> but I never had any problems).
>>>
>>> After that, the USRP stopped responding. I was not even able to ping the
>>> USRP. Also, I observed that the GB ethernet LED has changed to amber
>>> color. I tried power cycling the USRP as well as restarting the host
>>> computer. But nothing helped.
>>>
>>> I appreciate if I could get any assistance to get the USRP back to
>>> working.
>>>
>>> Thank you in advance
>>> Damindra
>>>
>>>
>>> See:
>>
>> http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
>
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/043d26dd/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 7 Jun 2016 19:24:13 -0400
From: Ziang Gao <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP X310 FPGA
Message-ID:
<CALmz3p1r0fmoB==2fdn3py+0pbkzpv6vqxsjawznnxsunhq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I recently got a new board USRP X310, and I'm new to FPGA development. I'm
using vivado 2015.2 and found that there are a lot choices in FPGA
XC7K410T. Could you tell me which exactly the part is using in USRP X310?
Thank you.
Best regards,
Ziang Gao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/17463c76/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 7 Jun 2016 16:44:20 -0700
From: Robin Coxe <[email protected]>
To: Ziang Gao <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] USRP X310 FPGA
Message-ID:
<cagvti8vbu+ax0z1b9iahjythlk5mo1zihrmlyxkj5x-fawv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ziang Gao. The FPGA part # on the X310 is XC7K410T-2FFG900.
-Robin
On Tue, Jun 7, 2016 at 4:24 PM, Ziang Gao via USRP-users <
[email protected]> wrote:
> Hello,
> I recently got a new board USRP X310, and I'm new to FPGA development. I'm
> using vivado 2015.2 and found that there are a lot choices in FPGA
> XC7K410T. Could you tell me which exactly the part is using in USRP X310?
> Thank you.
> Best regards,
> Ziang Gao.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/0f5593ae/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 8 Jun 2016 02:05:05 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
And if you want to develop for the X310, I'd recommend going through our
FPGA development manual:
http://files.ettus.com/manual/md_usrp3_build_instructions.html
Best regards,
Marcus
On 08.06.2016 01:44, Robin Coxe via USRP-users wrote:
> Hi Ziang Gao. The FPGA part # on the X310 is XC7K410T-2FFG900.
>
> -Robin
>
>
> On Tue, Jun 7, 2016 at 4:24 PM, Ziang Gao via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
> I recently got a new board USRP X310, and I'm new to FPGA
> development. I'm using vivado 2015.2 and found that there are a
> lot choices in FPGA XC7K410T. Could you tell me which exactly the
> part is using in USRP X310?
> Thank you.
> Best regards,
> Ziang Gao.
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/199930c0/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 8 Jun 2016 02:07:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Ok, I should have put this in the same email:
In many cases, we meet users that think they need to modify the USRP's
FPGA image, but in fact, don't have to, because what they want is
possible without any modification. You're always invited to talk about
your intended application here on usrp-users, and you'll most likely get
useful information on how to realize that.
Best regards,
Marcus
On 08.06.2016 01:44, Robin Coxe via USRP-users wrote:
> Hi Ziang Gao. The FPGA part # on the X310 is XC7K410T-2FFG900.
>
> -Robin
>
>
> On Tue, Jun 7, 2016 at 4:24 PM, Ziang Gao via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
> I recently got a new board USRP X310, and I'm new to FPGA
> development. I'm using vivado 2015.2 and found that there are a
> lot choices in FPGA XC7K410T. Could you tell me which exactly the
> part is using in USRP X310?
> Thank you.
> Best regards,
> Ziang Gao.
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/c2c45648/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 8 Jun 2016 09:31:04 +0800
From: john liu <[email protected]>
To: James Humphries <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b210 load fpga error
Message-ID:
<CAF6NnTKghB1VT0d=HiLp2XcpLuopsy3zVG+GkTuJ=8bd1rs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,James,
yes,it does help when reconnect the USB.
but we need to do that frequent.
thank you
best reagrds
John
On Mon, Jun 6, 2016 at 10:12 PM, James Humphries <[email protected]>
wrote:
> Hi John,
>
> Is the USRP connected to the computer when you boot?
>
> If you press the reset button (S700 near the USB port) are you able to
> connect to the device after reset? If you physically disconnect/reconnect
> the USB connector, does this help?
>
> Have you tried a different USB cable?
>
> Can you post the output of dmesg right after you plug the B210 into the host
> computer?
>
> -Trip
>
>
> On Sun, Jun 5, 2016 at 9:00 PM, john liu via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> we used b210,and errors output bellow:
>>
>> uhd_usrp_probe
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-gf7a15853
>>
>> -- Loading firmware image:
>> /usr/local/share/uhd/images/usrp_b200_fw.hex... done
>> -- Detected Device: B210
>> -- Loading FPGA image:
>> /usr/local/share/uhd/images/usrp_b210_fpga.bin...100%Error:
>> EnvironmentError: IOError: Failed to get FX3 status (-4: LIBUSB_ERROR_CODE
>> -4)
>>
>> We have changed the computer?but errors keep the same.
>> thank you for your help.
>>
>> best regards
>> John
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/b728ec5c/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 8 Jun 2016 10:09:11 +0800
From: john liu <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] transmitting of ubx
Message-ID:
<caf6nntl30nirpbcpyuh+a5wun_r7nx9vksy9pkbbnclb+tu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,MIcheal,
thank you for your davice.
we tried that,but it does't help.
we have an ideal that we set gain 0 when burst off and burst on we set
gain higher.i did't know that will do help?is there some like these control
block in gnuradio?the burst cycle is about 100ms.
thank you for your help
best regards
John
On Fri, Jun 3, 2016 at 5:54 AM, Michael West <[email protected]> wrote:
> Hi John,
>
> Some UHD changes were recently pushed that significantly reduced the noise
> and power consumption for UBX. Please pull the head of the maint branch
> and try it.
>
> Regards,
> Michael
>
> On Wed, Jun 1, 2016 at 7:41 PM, john liu via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> we want to transmit signal by time,so we used three
>> tags,tx_time,tx_sob and tx_eob.tx_time means start transmitting time,tx_sob
>> means the first sampling point and tx_eob means the last sampling point.
>> we used X310 with cbx120 transmitting,and another x310 with ubx
>> receiving. we can receive data discontinuous normally on receiving end.when
>> cut down transmitting program,and no signal found on receiving end .
>> when we used X310 with ubx160 transmitting,and the rest keep
>> the same.
>> we receive obvious noise all the time on receiving end.we even cut down
>> the transmitting program,and the noise could be found on receiving end
>> .then we unplug the power of transmitting usrp,and the noise disappear on
>> receiving end.
>> we used uhd3.9.4+ubuntu14.04.
>> can you give some davice?
>> thank you.
>> best regards
>> John
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/7a4cc125/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 8 Jun 2016 02:13:46 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Unable to get Vivado Hardware Manager to
recognize the Chipscope ILA cores in the Ettus x310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
No, your suggestion that I first run ?uhd_usrp_probe ?init-only? was the
solution.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, June 06, 2016 1:41 PM
To: Swanson, Craig <[email protected]>
Cc: Martin Braun <[email protected]>; Marcus M?ller
<[email protected]>; [email protected]
Subject: Re: Unable to get Vivado Hardware Manager to recognize the Chipscope
ILA cores in the Ettus x310
Hey Craig,
By default, ce_clk is hooked up to radio_clk in rfnoc_ce_auto_inst_x310.v. Did
your new image work? Are you still getting the ADC error?
Jonathon
On Mon, May 30, 2016 at 12:59 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
Thank you for your speedy reply.
1. ??According to the directions you sent me a while ago, I ran in GUI mode
such as "make GUI=1 X310_RFNOC_HGS"
2. I interrupted Vivado and created the debug cores in the synthesis step,
using your example in noc_block_moving_avg. (* dont_touch = "true", mark_debug
= "true" *)
3. I continued on with Vivado creating a bit file x300.bit
4. I used the uhd_image_loader with the x300.bit file.
5. When I ran "uhd_usrp_probe --init-only, I got a really weird result which
is telling me something is not right about the x300.bit file. Error:
RuntimeError: self_cal_adc_capture_delay: Self calibration failed. Convergence
error.?
6. I am going to run "make X310_RFNOC_HGS" and hope that the timing.xdc file
will now automatically find my ILA_0 (signals triggering off of bus_clk) and
ILA_1 (signals triggering off of ce_clk). I am expecting it to produce a
usrp_x310_rfnoc_fpga_HGS.bit file.
7. I am not sure what you mean by the radio_clk. In noc_block_moving_avg I
am guessing the radio_clk you are referring to is the ce_clk.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum
<[email protected]<mailto:[email protected]>>
Sent: Monday, May 30, 2016 1:27 AM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller;
[email protected]<mailto:[email protected]>
Subject: Re: Unable to get Vivado Hardware Manager to recognize the Chipscope
ILA cores in the Ettus x310
Craig,
Are your cores using radio_clk? If so, you need to run uhd_usrp_probe to
initialize radio_clk.
Jonathon
On Sun, May 29, 2016 at 11:39 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
Is there anything I might be doing wrong to get Chipscope to open?
1. ?I created two ILA debug cores during synthesis
2. Created a new .bit file and used uhd_image_loader to put the new x300.bit
in the x310.
3. Powered off and on the x310.
4. Connected the USB JTAG cable to the x310
5. Opened up a new target in the Hardware manager and it sees the Digilent
xc7k410t_0 but says there are no debug cores.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/d37cb1f1/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 8 Jun 2016 10:23:24 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] full duplex about x310
Message-ID:
<caeui2n2it-9cwf24d_u0a864gg1r0cowwo375myh98saem2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We used X310+CBX to send a discrete signal, and the duty cycle is about
50%?and the cycle is 100ms. we used another x310+ubx to receiving, and the
receiving signal duty ratio is 50%. But if we use the same equipment
another port (the aother RF dboard) receiving, and the duty ratio is 70%.
the system is ubuntu14.04+uhd3.9.4
we did something wrong?
thank you.
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/261e09ff/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 8 Jun 2016 02:26:00 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] Not sure how to remove tuser CHDR header control
and data from m_axis_data_tdata and s_axis_data_tdata in noc_block
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I am in the process of creating my own noc_block_Receiver.v which currently is
acting as an AGC. When I run my own Modelsim testbench I am having undesired
effects of the header requests and reply mingled in with my AGC data. I am not
sure how to make sure that none of the header information for data, flow
control, command or response be included in with what is going in or out of my
AGC noc block.
It appears that the only signals I have access to are m_axis and s_axis tdata,
tlast, tvalid, and tready. How would you suggest I go about making sure only
pure data enters and leaves the AGC when communicating with my cocotb testbench
or gnuradio-companion? I have not looked at how the moving_avg deals with this.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/9b072b1c/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 7 Jun 2016 23:08:51 -0700
From: Derek Kozel <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] full duplex about x310
Message-ID:
<CAA+K=tsU4cN1B3xYg=ju1-qzqwlt+e+9yxn9gx7l0m-s9fd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
Can you describe in more depth what your setup is? What is the second
daughterboard, what system is it installed in? How are the signals being
carried from the transmitter to the receivers? Do you run both receivers at
the same time and observe different results? What is the original signal?
Thanks,
Derek
On Tue, Jun 7, 2016 at 7:23 PM, liu Jong via USRP-users <
[email protected]> wrote:
> Dear all,
> We used X310+CBX to send a discrete signal, and the duty cycle is about
> 50%?and the cycle is 100ms. we used another x310+ubx to receiving, and the
> receiving signal duty ratio is 50%. But if we use the same equipment
> another port (the aother RF dboard) receiving, and the duty ratio is 70%.
> the system is ubuntu14.04+uhd3.9.4
> we did something wrong?
> thank you.
> best regards
> Jon
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/4b3af75e/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 7 Jun 2016 23:39:40 -0700
From: Michael West <[email protected]>
To: john liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] transmitting of ubx
Message-ID:
<cam4xkro0jihobwgsiov93kqucyzjdcozd0cvjkhwvpbuyjj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
Please provide the exact UHD commit hash (should be at the top of the
output when starting the application), the center frequency, and gain
used. Also, please describe the noise you see in more detail. If you can
provide a GnuRadio flowgraph that demonstrates the issue and pictures of
the noise, that would be ideal.
Regards,
Michael
On Tue, Jun 7, 2016 at 7:09 PM, john liu <[email protected]> wrote:
> Hi,MIcheal,
> thank you for your davice.
> we tried that,but it does't help.
> we have an ideal that we set gain 0 when burst off and burst on we set
> gain higher.i did't know that will do help?is there some like these control
> block in gnuradio?the burst cycle is about 100ms.
> thank you for your help
> best regards
> John
>
> On Fri, Jun 3, 2016 at 5:54 AM, Michael West <[email protected]>
> wrote:
>
>> Hi John,
>>
>> Some UHD changes were recently pushed that significantly reduced the
>> noise and power consumption for UBX. Please pull the head of the maint
>> branch and try it.
>>
>> Regards,
>> Michael
>>
>> On Wed, Jun 1, 2016 at 7:41 PM, john liu via USRP-users <
>> [email protected]> wrote:
>>
>>> Dear all,
>>> we want to transmit signal by time,so we used three
>>> tags,tx_time,tx_sob and tx_eob.tx_time means start transmitting time,tx_sob
>>> means the first sampling point and tx_eob means the last sampling point.
>>> we used X310 with cbx120 transmitting,and another x310 with ubx
>>> receiving. we can receive data discontinuous normally on receiving end.when
>>> cut down transmitting program,and no signal found on receiving end .
>>> when we used X310 with ubx160 transmitting,and the rest keep
>>> the same.
>>> we receive obvious noise all the time on receiving end.we even cut down
>>> the transmitting program,and the noise could be found on receiving end
>>> .then we unplug the power of transmitting usrp,and the noise disappear on
>>> receiving end.
>>> we used uhd3.9.4+ubuntu14.04.
>>> can you give some davice?
>>> thank you.
>>> best regards
>>> John
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/7d236d95/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 8 Jun 2016 09:17:11 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all
I'm trying to create my own program to communicate with an X310 USRP. Host is
Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
During the build process in Qt Creator I've no errors or warnings (libraries
are all correct linked). The device is correctly found and the initialization
with uhd::usrp::multi_usrp::make(dev_adr) works also. In the second step I
would set the mboard clocks, but there is something going bad.
This is my current code (cross-checked with rx_samples_to_file,
rx_samples_to_udp, rx_ascii_art_dft):
int USRP_SDR::Init_USRP()
{
//create a usrp device
uhd::device_addr_t dev_adr;
dev_adr.set("addr", addr);
usrp = uhd::usrp::multi_usrp::make(dev_adr);
std::cout << "Hallo1" << std::endl;
//Lock mboard clocks
usrp->set_clock_source(ref);
std::cout << "Hallo2" << std::endl;
//always select the subdevice first, the channel mapping affects the other
settings
if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
std::cout << boost::format("Using Device: %s") % usrp->get_pp_string() <<
std::endl;
//set the sample rate
if (rate <= 0.0){
std::cerr << "Please specify a valid sample rate" << std::endl;
return 0;
}
std::cout << boost::format("Setting RX Rate: %f Msps...") % (rate/1e6) <<
std::endl;
usrp->set_rx_rate(rate);
std::cout << boost::format("Actual RX Rate: %f Msps...") %
(usrp->get_rx_rate()/1e6) << std::endl << std::endl;
return 1;
}
And this is the resulting terminal output (the Hello2 is missing, and also the
rest of the initialization process):
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
Hallo1
Press <RETURN> to close this window...
Does anyone see the fault?
Best regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/3c4b50bd/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 8 Jun 2016 08:21:41 +0000
From: ???? <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 not recognized over USB 3 in Windows 7
Message-ID:
<bdac4f2dd20ba24991ebdc81b4052584bf9a8...@imail-exch02.govmail.tehila.gov.il>
Content-Type: text/plain; charset="windows-1255"
Hi,
I'm having trouble working with the B210 on computers with USB 3 ports and
Windows 7 operating system.
To be more precise, I tried working with two computers and had a slightly
different problem with each one.
On both computers I've downloaded winusb and UHD drivers from
http://files.ettus.com/binaries/.
* Computer 1: When I connect the B210 to a USB 3 port, the hardware is
detected ("Ettus Research LLC B200/B210" in device manager). However, when
running "uhd_find_devices" I get "No UHD Device Found". It should be mentioned
that when switching to a USB 2 port, the device is found.
* Computer 2: Hardware is detected and device is found, but when running an
example program like "rx_samples_to_file" the UI prints "Operating over USB 2",
although the ports is USB 3 SS.
Is there something extra required for working over USB 3 connection in Windows?
Best regards,
Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/f8f2f5c2/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 8 Jun 2016 11:34:04 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 not recognized over USB 3 in Windows 7
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Roy,
which USB host controller are you using?
We know that some work better than others, and some even don't work at
all with our absolutely normal USB3 devices.
The problem here is that UHD itself is not involved at all in the
decision whether the connection is a USB3 or USB2 connection; it just
uses libUSB / winUSB to request a device handle, and get and send USB
bulk data packets. The driver you have to install under windows is not
made by us ? it's just the generic "this is a bulk device, so just give
the USB packets to user programs" driver.
What can be an issue, however, is that for signal integrity reasons,
devices work more reliably when first connected to external power and
then to the USB port; however, I've only seen voltage drops on the USB
bus disturb running operation, not a USB3->USB2 "downgrade" so far.
Best regards,
Marcus
On 08.06.2016 10:21, ???? via USRP-users wrote:
> Hi,
>
> I'm having trouble working with the B210 on computers with USB 3 ports
> and Windows 7 operating system.
> To be more precise, I tried working with two computers and had a
> slightly different problem with each one.
> On both computers I've downloaded winusb and UHD drivers
> from http://files.ettus.com/binaries/.
>
> * Computer 1: When I connect the B210 to a USB 3 port, the hardware
> is detected ("Ettus Research LLC B200/B210" in device manager).
> However, when running "uhd_find_devices" I get "No UHD Device
> Found". It should be mentioned that when switching to a USB 2
> port, the device is found.
> * Computer 2: Hardware is detected and device is found, but when
> running an example program like "rx_samples_to_file" the UI prints
> "Operating over USB 2", although the ports is USB 3 SS.
>
> Is there something extra required for working over USB 3 connection in
> Windows?
>
> Best regards,
> Roy
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/4c21c1fc/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 8 Jun 2016 13:12:01 +0200
From: Pablo Colodr?n <[email protected]>
To: [email protected]
Subject: [USRP-users] E310 NFS boot
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
I am trying to boot an E310 device from NFS server. I am following the
instructions described in
http://files.ettus.com/manual/page_usrp_e3x0.html, section 'Booting from
a NFS root'.
First, it is interesting to point out that I believe there is an error
in the device tree blob file generation. According to what the SDK does,
the command for regenerating .dtb file should be the following:
$ dtc -I dts -O dtb -R 8 -P 0x3000 e300-devicetree.dts -o e300-devicetree.dtb
Otherwise, the .dtb file format is not recognized by uboot.
In addition to this, I believe there is a further step not described in
the instructions which would consist of setting up uboot environment for
NFS boot. In uboot, 'sdboot' is the default variable used by bootcmd.
Could you provide additional information on how to setup uboot
environment and how the 'nfsboot' variable should look like?
Thank you in advance.
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/6ecad54a/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 8 Jun 2016 12:47:36 +0000
From: ???? <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] ??RE: B210 not recognized over USB 3 in Windows
7
Message-ID:
<bdac4f2dd20ba24991ebdc81b4052584bf9a9...@imail-exch02.govmail.tehila.gov.il>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thanks for the prompt response.
The USB 3 host controller is xHCI, and the USB 2 host controller is EHCI.
Thanks,
Roy
________________________________
?: ??USRP-users ?[[email protected]]? ??? Marcus M?ller via
USRP-users ?[[email protected]]?
??????: ??? ????? 08 ???? 2016 12:34
????: [email protected]
??????: Re: [USRP-users] B210 not recognized over USB 3 in Windows 7
Hello Roy,
which USB host controller are you using?
We know that some work better than others, and some even don't work at all with
our absolutely normal USB3 devices.
The problem here is that UHD itself is not involved at all in the decision
whether the connection is a USB3 or USB2 connection; it just uses libUSB /
winUSB to request a device handle, and get and send USB bulk data packets. The
driver you have to install under windows is not made by us ? it's just the
generic "this is a bulk device, so just give the USB packets to user programs"
driver.
What can be an issue, however, is that for signal integrity reasons, devices
work more reliably when first connected to external power and then to the USB
port; however, I've only seen voltage drops on the USB bus disturb running
operation, not a USB3->USB2 "downgrade" so far.
Best regards,
Marcus
On 08.06.2016 10:21, ???? via USRP-users wrote:
Hi,
I'm having trouble working with the B210 on computers with USB 3 ports and
Windows 7 operating system.
To be more precise, I tried working with two computers and had a slightly
different problem with each one.
On both computers I've downloaded winusb and UHD drivers from
http://files.ettus.com/binaries/.
* Computer 1: When I connect the B210 to a USB 3 port, the hardware is
detected ("Ettus Research LLC B200/B210" in device manager). However, when
running "uhd_find_devices" I get "No UHD Device Found". It should be mentioned
that when switching to a USB 2 port, the device is found.
* Computer 2: Hardware is detected and device is found, but when running an
example program like "rx_samples_to_file" the UI prints "Operating over USB 2",
although the ports is USB 3 SS.
Is there something extra required for working over USB 3 connection in Windows?
Best regards,
Roy
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/c5189e42/attachment-0001.html>
------------------------------
Message: 26
Date: Wed, 8 Jun 2016 14:50:14 +0000
From: "Topliff, Charles Alexander" <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock-G GPS Lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I was able to eventually get a GPS lock after giving the octoclock some time.
It was able to establish a lock after about fifteen minutes or so.
Thanks for your help!
Charles
________________________________
From: Derek Kozel <[email protected]>
Sent: Tuesday, June 7, 2016 2:36 PM
To: Topliff, Charles Alexander; [email protected]
Subject: Re: [USRP-users] Octoclock-G GPS Lock
+usrp-users list
Hello,
I have found that it can take a quarter of an hour or more unless it has
perfect, full sky view with nothing in the way. Can you leave it running for a
while and see if a lock occurs?
Thanks,
Derek
On Tue, Jun 7, 2016 at 12:31 PM, Topliff, Charles Alexander
<[email protected]<mailto:[email protected]>> wrote:
I gave it a few minutes, and it did not seem to resolve any lock after that.
Does it require an extended period of time?
________________________________
From: Derek Kozel <[email protected]<mailto:[email protected]>>
Sent: Tuesday, June 7, 2016 2:26 PM
To: Topliff, Charles Alexander
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Octoclock-G GPS Lock
Hello Charles,
How long has the antenna been in sight of the sky since powering on the
Octoclock? Ethernet is not required, though it would be useful to query the
gps_lock sensor.
Regards,
Derek
On Tue, Jun 7, 2016 at 12:17 PM, Topliff, Charles Alexander via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello All,
I am having difficulty obtaining a GPS lock using the Octoclock - G. From my
understanding, the front panel GPS LOCK LED is to light up once a GPS lock is
obtained. I am using the 5V GPS antenna purchased here:
https://www.ettus.com/product/details/GPS-ANT-5V.<https://www.ettus.com/product/details/GPS-ANT-5V>
I want to ensure that I am not missing any steps in order to get a GPS lock. I
have the Octoclock powered, but it is not connected to any host computer via
ethernet. When the antenna is connected and in an area well free of any
obstructions, it still seems that the GPS LOCK LED is not lit.
Any input or suggestions are appreciated.
Thanks,
Charles
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/1aea6c54/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 8 Jun 2016 11:51:22 -0400
From: Philip Balister <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] E310 NFS boot
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/08/2016 07:12 AM, Pablo Colodr?n via USRP-users wrote:
> Hi,
>
> I am trying to boot an E310 device from NFS server. I am following the
> instructions described in
> http://files.ettus.com/manual/page_usrp_e3x0.html, section 'Booting from
> a NFS root'.
>
> First, it is interesting to point out that I believe there is an error
> in the device tree blob file generation. According to what the SDK does,
> the command for regenerating .dtb file should be the following:
>
> $ dtc -I dts -O dtb -R 8 -P 0x3000 e300-devicetree.dts -o
> e300-devicetree.dtb
>
> Otherwise, the .dtb file format is not recognized by uboot.
>
> In addition to this, I believe there is a further step not described in
> the instructions which would consist of setting up uboot environment for
> NFS boot. In uboot, 'sdboot' is the default variable used by bootcmd.
> Could you provide additional information on how to setup uboot
> environment and how the 'nfsboot' variable should look like?
Answering from memory ....
Look at the file uEnv.txt in the boot partition.
Philip
>
> Thank you in advance.
>
> Regards,
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 8
*****************************************
