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. Transmit time variability (devin kelly)
2. Re: Transmit time variability (Marcus D. Leech)
3. Re: "deaf" WBX daughterboard (Keith)
4. Re: AssertionError: accum_timeout <_timeout (Swanson, Craig)
5. Re: "deaf" WBX daughterboard (Marcus D. Leech)
6. Re: AssertionError: accum_timeout <_timeout (James Humphries)
7. Re: AssertionError: accum_timeout <_timeout (Richard Bell)
8. Re: Transmit time variability (devin kelly)
9. Re: Transmit time variability (Marcus M?ller)
10. Re: Transmit time variability (devin kelly)
11. Re: AssertionError: accum_timeout <_timeout (Martin Braun)
12. Re: get_rx_sensor exceptions (Kevin McGuire)
13. Re: get_rx_sensor exceptions (Kevin McGuire)
14. Compiling E310 device driver issue (Jonathon Cheah)
15. Timed Commands with RFNoC Radios (Sam Carey)
16. (no subject) (Xingjian Chen)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Apr 2016 11:59:50 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Transmit time variability
Message-ID:
<caanlyuzhdip-y2qh0c1gweyk-bhfzx0-cv9dey6cjcxpt1q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've built a GR flowgraph the transmits a packet 100ms after each PPS. I
measure when the USRP starts transmitting and there's always some delay, so
the transmission starts a little bit after 100 ms after the PPS. (I set my
scope to trigger 100 ms after the PPS). Once I find one burst on my scope
I see that all the packet bursts start within a ~20 ns window of each
other, which works well for me.
My problem is that each time I start my flowgraph there's a different delay
after the PPS + 100 ms. For example, one time I'll start my flowgraph and
the measured transmit time will be PPS + 100.12, the next time I start my
flowgraph the measured transmit time will be PPS + 100.2 ms.
Why do I get this random delay that's different for each execution of
flowgraph and what can I do about it?
For what it's worth the GR tags that go into my USRP block are always
consistent (tx_time and packet_len) and I don't change anything from run to
run in my flowgraph.
I'm using UHD 3.9.3 with an X310 that has a GPSDO. My clock and time
source are both set to use the GPSDO, the clock is set to sync with the PC
time. I think it's more likely the issue is with the UHD or FPGA than GNU
Radio, but I could be wrong.
Thanks For any help,
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/9d31af12/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 15 Apr 2016 12:28:35 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Transmit time variability
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/15/2016 11:59 AM, devin kelly via USRP-users wrote:
> Hello,
>
> I've built a GR flowgraph the transmits a packet 100ms after each
> PPS. I measure when the USRP starts transmitting and there's always
> some delay, so the transmission starts a little bit after 100 ms after
> the PPS. (I set my scope to trigger 100 ms after the PPS). Once I
> find one burst on my scope I see that all the packet bursts start
> within a ~20 ns window of each other, which works well for me.
>
> My problem is that each time I start my flowgraph there's a different
> delay after the PPS + 100 ms. For example, one time I'll start my
> flowgraph and the measured transmit time will be PPS + 100.12, the
> next time I start my flowgraph the measured transmit time will be PPS
> + 100.2 ms.
>
> Why do I get this random delay that's different for each execution of
> flowgraph and what can I do about it?
>
> For what it's worth the GR tags that go into my USRP block are always
> consistent (tx_time and packet_len) and I don't change anything from
> run to run in my flowgraph.
>
> I'm using UHD 3.9.3 with an X310 that has a GPSDO. My clock and time
> source are both set to use the GPSDO, the clock is set to sync with
> the PC time. I think it's more likely the issue is with the UHD or
> FPGA than GNU Radio, but I could be wrong.
>
> Thanks For any help,
> Devin
>
Unless your PC is also tightly synchronized to GPS, there will be
disagreement between when your PC thinks the second has changed, and
when GPS (via the 1PPS) thinks the second has changed. Without seeing
more of your code, I think that might be a fruitful avenue to explore.
------------------------------
Message: 3
Date: Fri, 15 Apr 2016 17:35:02 +0100
From: Keith <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] "deaf" WBX daughterboard
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 15/04/2016 14:00, Marcus D. Leech via USRP-users wrote:
>
> If you have access to someone with SMD re-work skills and equipment,
> replacing the LNA chip on the GDB should be fairly straightforward,
> and is very-likely the cause of your grief.
I guess I could give it a go. it's only 6 pins. what could possibly go
wrong....
Only I don't have a decent rework station here, but that investment
would be a lot less than a new WBX.
>
> I blew up my own WBX input last week (an early WBX) via a mechanism
> that was not immediately obvious, even to someone who has been
> mucking-about in radio since forever.
eek!! Makes me feel better though. even if I didn't actually blow this
board myself.
>
> Otherwise, replacement of the WBX daughtercard is the only other
> reasonable option.
sounds implicit in what you're saying then, that it's not possible Ettus
might ship me a new GDB for less $$$ than ther entire WBX. :-(
Thanks Marcus for the help!
------------------------------
Message: 4
Date: Fri, 15 Apr 2016 16:36:41 +0000
From: "Swanson, Craig" <[email protected]>
To: James Humphries <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?James,
Do you know of anyone who has had success with their B210 running in the Ubuntu
14.04 VirtualBox environment running from Windows 7?
I running the Oracle VM VirtualBox Version 5.0 with Ubuntu 14.04. I have run
the following:
craig@craig-VirtualBox:~$ sudo uhd_find_devices
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: b200
name: MyB210
serial: 30BF799
product: B210
Then I ran and always get
craig@craig-VirtualBox:~$ uhd_usrp_probe
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
-- Detected Device: B210
-- Operating over USB 2.
Error: AssertionError: accum_timeout < _timeout
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235
?
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
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: James Humphries <[email protected]>
Sent: Friday, April 15, 2016 11:27 AM
To: Swanson, Craig
Cc: Martin Braun; [email protected]
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Hi Craig,
Have you had any luck previously using the VM under Virtualbox? Can you do a
uhd_usrp_probe or uhd_find_devices without error?
It seems like the OS is not getting a response from the B210 in time. VM can be
hit or miss, I have used VMWare successfully, but haven't tried virtual box yet
with USRP hardware.
-Trip
On Fri, Apr 15, 2016 at 9:13 AM, Swanson, Craig via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Martin,
I am running a B210 with my windows 7 computer running Virtualbox Ubuntu 14.04
and when I try to run this off the shelf flowgraph from your website tutorials
called gr-tutorial-spec-an.grc, I get the following error:
Executing: /usr/bin/python2 -u /home/craig/jida/gr-jida/examples/top_block.py
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
-- Detected Device: B210
-- Operating over USB 2.
Traceback (most recent call last):
File "/home/craig/jida/gr-jida/examples/top_block.py", line 162, in <module>
main()
File "/home/craig/jida/gr-jida/examples/top_block.py", line 150, in main
tb = top_block_cls()
File "/home/craig/jida/gr-jida/examples/top_block.py", line 78, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
122, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
2249, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: AssertionError: accum_timeout < _timeout
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235?
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>
_______________________________________________
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/20160415/3cf60758/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 15 Apr 2016 12:59:34 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] "deaf" WBX daughterboard
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/15/2016 12:35 PM, Keith via USRP-users wrote:
>
> sounds implicit in what you're saying then, that it's not possible Ettus
> might ship me a new GDB for less $$$ than ther entire WBX. :-(
>
> Thanks Marcus for the help!
>
> _______________________________________________
In the very olden days, it might have been possible, just due to the
fact that manufacturing (and repair) was managed directly by Ettus
staff. Now that NI manufactures all of Ettus' product, the
repair/replacement mechanisms and pipeline are very different.
------------------------------
Message: 6
Date: Fri, 15 Apr 2016 13:44:54 -0400
From: James Humphries <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID:
<caewgfhudfi7tanoonuvzx2-yoyg0m9nqbvqwutgwhcaod7v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have heard of some success on here of people getting a B200/210 to work
with VirtualBox.
If you execute the b2xx_fx3_utils tool, does that help? It should be
located in <install-directory>/lib/uhd/utils/
Have you installed the extension package for xHCI support?
https://www.virtualbox.org/manual/ch03.html#settings-usb
https://www.virtualbox.org/manual/ch01.html#intro-installing
-Trip
On Fri, Apr 15, 2016 at 12:36 PM, Swanson, Craig <
[email protected]> wrote:
> ?James,
>
> Do you know of anyone who has had success with their B210 running in the
> Ubuntu 14.04 VirtualBox environment running from Windows 7?
>
>
> I running the Oracle VM VirtualBox Version 5.0 with Ubuntu 14.04. I have
> run the following:
>
>
> craig@craig-VirtualBox:~$ sudo uhd_find_devices
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: b200
> name: MyB210
> serial: 30BF799
> product: B210
>
>
> Then I ran and always get
> craig@craig-VirtualBox:~$ uhd_usrp_probe
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
>
> -- Detected Device: B210
> -- Operating over USB 2.
> Error: AssertionError: accum_timeout < _timeout
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235
>
> ?
> 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 <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:* James Humphries <[email protected]>
> *Sent:* Friday, April 15, 2016 11:27 AM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; [email protected]
> *Subject:* Re: [USRP-users] AssertionError: accum_timeout <_timeout
>
> Hi Craig,
>
> Have you had any luck previously using the VM under Virtualbox? Can you do
> a uhd_usrp_probe or uhd_find_devices without error?
>
> It seems like the OS is not getting a response from the B210 in time. VM
> can be hit or miss, I have used VMWare successfully, but haven't tried
> virtual box yet with USRP hardware.
>
> -Trip
>
>
> On Fri, Apr 15, 2016 at 9:13 AM, Swanson, Craig via USRP-users <
> [email protected]> wrote:
>
>> Martin,
>>
>> I am running a B210 with my windows 7 computer running Virtualbox Ubuntu
>> 14.04 and when I try to run this off the shelf flowgraph from your website
>> tutorials called gr-tutorial-spec-an.grc, I get the following error:
>>
>>
>>
>> Executing: /usr/bin/python2 -u
>> /home/craig/jida/gr-jida/examples/top_block.py
>>
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.rfnoc-316-gb7546712
>>
>> -- Detected Device: B210
>> -- Operating over USB 2.
>> Traceback (most recent call last):
>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 162, in
>> <module>
>> main()
>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 150, in main
>> tb = top_block_cls()
>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 78, in
>> __init__
>> channels=range(1),
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>> line 122, in constructor_interceptor
>> return old_constructor(*args)
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 2249, in make
>> return _uhd_swig.usrp_source_make(*args)
>> RuntimeError: AssertionError: accum_timeout < _timeout
>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235?
>>
>>
>>
>> *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 <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>
>>
>>
>>
>> _______________________________________________
>> 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/20160415/a8f559f4/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 15 Apr 2016 11:18:32 -0700
From: Richard Bell <[email protected]>
To: James Humphries <[email protected]>
Cc: "Swanson, Craig" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID:
<CAMMoi3umgqwjWhJXcdToroH=yt2quhmcmartcpfwhcgznsz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I recently experienced this error using a B200 with no virtual box. The fix
was to use my USB3.0 port. It would error out with this message whenever I
tried using the USB2.0 ports. Just throwing this out there.
On Fri, Apr 15, 2016 at 10:44 AM, James Humphries via USRP-users <
[email protected]> wrote:
> I have heard of some success on here of people getting a B200/210 to work
> with VirtualBox.
>
> If you execute the b2xx_fx3_utils tool, does that help? It should be
> located in <install-directory>/lib/uhd/utils/
>
> Have you installed the extension package for xHCI support?
>
> https://www.virtualbox.org/manual/ch03.html#settings-usb
>
> https://www.virtualbox.org/manual/ch01.html#intro-installing
>
> -Trip
>
> On Fri, Apr 15, 2016 at 12:36 PM, Swanson, Craig <
> [email protected]> wrote:
>
>> ?James,
>>
>> Do you know of anyone who has had success with their B210 running in the
>> Ubuntu 14.04 VirtualBox environment running from Windows 7?
>>
>>
>> I running the Oracle VM VirtualBox Version 5.0 with Ubuntu 14.04. I have
>> run the following:
>>
>>
>> craig@craig-VirtualBox:~$ sudo uhd_find_devices
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.rfnoc-316-gb7546712
>>
>> --------------------------------------------------
>> -- UHD Device 0
>> --------------------------------------------------
>> Device Address:
>> type: b200
>> name: MyB210
>> serial: 30BF799
>> product: B210
>>
>>
>> Then I ran and always get
>> craig@craig-VirtualBox:~$ uhd_usrp_probe
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.rfnoc-316-gb7546712
>>
>> -- Detected Device: B210
>> -- Operating over USB 2.
>> Error: AssertionError: accum_timeout < _timeout
>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235
>>
>> ?
>> 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 <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:* James Humphries <[email protected]>
>> *Sent:* Friday, April 15, 2016 11:27 AM
>> *To:* Swanson, Craig
>> *Cc:* Martin Braun; [email protected]
>> *Subject:* Re: [USRP-users] AssertionError: accum_timeout <_timeout
>>
>> Hi Craig,
>>
>> Have you had any luck previously using the VM under Virtualbox? Can you
>> do a uhd_usrp_probe or uhd_find_devices without error?
>>
>> It seems like the OS is not getting a response from the B210 in time. VM
>> can be hit or miss, I have used VMWare successfully, but haven't tried
>> virtual box yet with USRP hardware.
>>
>> -Trip
>>
>>
>> On Fri, Apr 15, 2016 at 9:13 AM, Swanson, Craig via USRP-users <
>> [email protected]> wrote:
>>
>>> Martin,
>>>
>>> I am running a B210 with my windows 7 computer running Virtualbox Ubuntu
>>> 14.04 and when I try to run this off the shelf flowgraph from your website
>>> tutorials called gr-tutorial-spec-an.grc, I get the following error:
>>>
>>>
>>>
>>> Executing: /usr/bin/python2 -u
>>> /home/craig/jida/gr-jida/examples/top_block.py
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_003.010.rfnoc-316-gb7546712
>>>
>>> -- Detected Device: B210
>>> -- Operating over USB 2.
>>> Traceback (most recent call last):
>>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 162, in
>>> <module>
>>> main()
>>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 150, in
>>> main
>>> tb = top_block_cls()
>>> File "/home/craig/jida/gr-jida/examples/top_block.py", line 78, in
>>> __init__
>>> channels=range(1),
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>>> 122, in constructor_interceptor
>>> return old_constructor(*args)
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>>> 2249, in make
>>> return _uhd_swig.usrp_source_make(*args)
>>> RuntimeError: AssertionError: accum_timeout < _timeout
>>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>> at /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235?
>>>
>>>
>>>
>>> *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 <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>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [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/20160415/c4952702/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 15 Apr 2016 14:19:15 -0400
From: devin kelly <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Transmit time variability
Message-ID:
<caanlyubfwtp6twdz0rfo3coedk0xh_ycawuziinococcvk7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm a little confused, when I set tx_time tag is the transmit time relative
to the clock on my PC or the clock on the USRP?
Thanks,
Devin
On Fri, Apr 15, 2016 at 12:28 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 04/15/2016 11:59 AM, devin kelly via USRP-users wrote:
>
>> Hello,
>>
>> I've built a GR flowgraph the transmits a packet 100ms after each PPS. I
>> measure when the USRP starts transmitting and there's always some delay, so
>> the transmission starts a little bit after 100 ms after the PPS. (I set my
>> scope to trigger 100 ms after the PPS). Once I find one burst on my scope
>> I see that all the packet bursts start within a ~20 ns window of each
>> other, which works well for me.
>>
>> My problem is that each time I start my flowgraph there's a different
>> delay after the PPS + 100 ms. For example, one time I'll start my
>> flowgraph and the measured transmit time will be PPS + 100.12, the next
>> time I start my flowgraph the measured transmit time will be PPS + 100.2 ms.
>>
>> Why do I get this random delay that's different for each execution of
>> flowgraph and what can I do about it?
>>
>> For what it's worth the GR tags that go into my USRP block are always
>> consistent (tx_time and packet_len) and I don't change anything from run to
>> run in my flowgraph.
>>
>> I'm using UHD 3.9.3 with an X310 that has a GPSDO. My clock and time
>> source are both set to use the GPSDO, the clock is set to sync with the PC
>> time. I think it's more likely the issue is with the UHD or FPGA than GNU
>> Radio, but I could be wrong.
>>
>> Thanks For any help,
>> Devin
>>
>> Unless your PC is also tightly synchronized to GPS, there will be
> disagreement between when your PC thinks the second has changed, and when
> GPS (via the 1PPS) thinks the second has changed. Without seeing more of
> your code, I think that might be a fruitful avenue to explore.
>
>
>
>
> _______________________________________________
> 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/20160415/f942a2fa/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 15 Apr 2016 20:21:40 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Transmit time variability
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
USRP clock
On 15.04.2016 20:19, devin kelly via USRP-users wrote:
> I'm a little confused, when I set tx_time tag is the transmit time
> relative to the clock on my PC or the clock on the USRP?
>
> Thanks,
> Devin
>
> On Fri, Apr 15, 2016 at 12:28 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 04/15/2016 11:59 AM, devin kelly via USRP-users wrote:
>
> Hello,
>
> I've built a GR flowgraph the transmits a packet 100ms after
> each PPS. I measure when the USRP starts transmitting and
> there's always some delay, so the transmission starts a little
> bit after 100 ms after the PPS. (I set my scope to trigger
> 100 ms after the PPS). Once I find one burst on my scope I
> see that all the packet bursts start within a ~20 ns window of
> each other, which works well for me.
>
> My problem is that each time I start my flowgraph there's a
> different delay after the PPS + 100 ms. For example, one time
> I'll start my flowgraph and the measured transmit time will be
> PPS + 100.12, the next time I start my flowgraph the measured
> transmit time will be PPS + 100.2 ms.
>
> Why do I get this random delay that's different for each
> execution of flowgraph and what can I do about it?
>
> For what it's worth the GR tags that go into my USRP block are
> always consistent (tx_time and packet_len) and I don't change
> anything from run to run in my flowgraph.
>
> I'm using UHD 3.9.3 with an X310 that has a GPSDO. My clock
> and time source are both set to use the GPSDO, the clock is
> set to sync with the PC time. I think it's more likely the
> issue is with the UHD or FPGA than GNU Radio, but I could be
> wrong.
>
> Thanks For any help,
> Devin
>
> Unless your PC is also tightly synchronized to GPS, there will be
> disagreement between when your PC thinks the second has changed,
> and when GPS (via the 1PPS) thinks the second has changed.
> Without seeing more of your code, I think that might be a
> fruitful avenue to explore.
>
>
>
>
> _______________________________________________
> 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/20160415/feb253f0/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 15 Apr 2016 14:38:38 -0400
From: devin kelly <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Transmit time variability
Message-ID:
<CAANLyuZJdwpV0w=Mq8sB4cSA8bfjriSU1d7frfTRu+z=otv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
So it shouldn't matter if my PC clock and USRP clock are out of sync
(within reason) as long as I get my samples to the USRP in time with the
right tx_time tag? I'm generating the packets once a second about a second
in advance, so they aren't late.
Devin
On Fri, Apr 15, 2016 at 2:21 PM, Marcus M?ller <[email protected]>
wrote:
> USRP clock
>
>
> On 15.04.2016 20:19, devin kelly via USRP-users wrote:
>
> I'm a little confused, when I set tx_time tag is the transmit time
> relative to the clock on my PC or the clock on the USRP?
>
> Thanks,
> Devin
>
> On Fri, Apr 15, 2016 at 12:28 PM, Marcus D. Leech via USRP-users <
> <[email protected]>[email protected]> wrote:
>
>> On 04/15/2016 11:59 AM, devin kelly via USRP-users wrote:
>>
>>> Hello,
>>>
>>> I've built a GR flowgraph the transmits a packet 100ms after each PPS.
>>> I measure when the USRP starts transmitting and there's always some delay,
>>> so the transmission starts a little bit after 100 ms after the PPS. (I set
>>> my scope to trigger 100 ms after the PPS). Once I find one burst on my
>>> scope I see that all the packet bursts start within a ~20 ns window of each
>>> other, which works well for me.
>>>
>>> My problem is that each time I start my flowgraph there's a different
>>> delay after the PPS + 100 ms. For example, one time I'll start my
>>> flowgraph and the measured transmit time will be PPS + 100.12, the next
>>> time I start my flowgraph the measured transmit time will be PPS + 100.2 ms.
>>>
>>> Why do I get this random delay that's different for each execution of
>>> flowgraph and what can I do about it?
>>>
>>> For what it's worth the GR tags that go into my USRP block are always
>>> consistent (tx_time and packet_len) and I don't change anything from run to
>>> run in my flowgraph.
>>>
>>> I'm using UHD 3.9.3 with an X310 that has a GPSDO. My clock and time
>>> source are both set to use the GPSDO, the clock is set to sync with the PC
>>> time. I think it's more likely the issue is with the UHD or FPGA than GNU
>>> Radio, but I could be wrong.
>>>
>>> Thanks For any help,
>>> Devin
>>>
>>> Unless your PC is also tightly synchronized to GPS, there will be
>> disagreement between when your PC thinks the second has changed, and when
>> GPS (via the 1PPS) thinks the second has changed. Without seeing more of
>> your code, I think that might be a fruitful avenue to explore.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> USRP-users mailing
> [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/20160415/8f9a7ca9/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 15 Apr 2016 14:26:14 -0500
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] AssertionError: accum_timeout <_timeout
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Can you please try your B-series on a maint or master branch? There
might be some issue with the rfnoc-devel branch and the B-series.
M
On 04/15/2016 01:18 PM, Richard Bell via USRP-users wrote:
> I recently experienced this error using a B200 with no virtual box. The
> fix was to use my USB3.0 port. It would error out with this message
> whenever I tried using the USB2.0 ports. Just throwing this out there.
>
> On Fri, Apr 15, 2016 at 10:44 AM, James Humphries via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> I have heard of some success on here of people getting a B200/210 to
> work with VirtualBox.
>
> If you execute the b2xx_fx3_utils tool, does that help? It should be
> located in <install-directory>/lib/uhd/utils/
>
> Have you installed the extension package for xHCI support?
>
> https://www.virtualbox.org/manual/ch03.html#settings-usb
>
> https://www.virtualbox.org/manual/ch01.html#intro-installing
>
> -Trip
>
> On Fri, Apr 15, 2016 at 12:36 PM, Swanson, Craig
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> ?James,
>
> Do you know of anyone who has had success with their B210
> running in the Ubuntu 14.04 VirtualBox environment running from
> Windows 7?
>
>
> I running the Oracle VM VirtualBox Version 5.0 with Ubuntu
> 14.04. I have run the following:
>
>
> craig@craig-VirtualBox:~$ sudo uhd_find_devices
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-316-gb7546712
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: b200
> name: MyB210
> serial: 30BF799
> product: B210
>
>
> Then I ran and always get
> craig@craig-VirtualBox:~$ uhd_usrp_probe
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-316-gb7546712
>
> -- Detected Device: B210
> -- Operating over USB 2.
> Error: AssertionError: accum_timeout < _timeout
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235
>
> ?
> 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:* James Humphries <[email protected]
> <mailto:[email protected]>>
> *Sent:* Friday, April 15, 2016 11:27 AM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] AssertionError: accum_timeout <_timeout
>
> Hi Craig,
>
> Have you had any luck previously using the VM under Virtualbox?
> Can you do a uhd_usrp_probe or uhd_find_devices without error?
>
> It seems like the OS is not getting a response from the B210 in
> time. VM can be hit or miss, I have used VMWare successfully,
> but haven't tried virtual box yet with USRP hardware.
>
> -Trip
>
>
> On Fri, Apr 15, 2016 at 9:13 AM, Swanson, Craig via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Martin,
>
> I am running a B210 with my windows 7 computer running
> Virtualbox Ubuntu 14.04 and when I try to run this off the
> shelf flowgraph from your website tutorials called
> gr-tutorial-spec-an.grc, I get the following error:
>
>
>
> Executing: /usr/bin/python2 -u
> /home/craig/jida/gr-jida/examples/top_block.py
>
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-316-gb7546712
>
> -- Detected Device: B210
> -- Operating over USB 2.
> Traceback (most recent call last):
> File "/home/craig/jida/gr-jida/examples/top_block.py",
> line 162, in <module>
> main()
> File "/home/craig/jida/gr-jida/examples/top_block.py",
> line 150, in main
> tb = top_block_cls()
> File "/home/craig/jida/gr-jida/examples/top_block.py",
> line 78, in __init__
> channels=range(1),
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
> return old_constructor(*args)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2249, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: AssertionError: accum_timeout < _timeout
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/craig/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:235
> ?
>
>
>
> *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>
>
>
>
> _______________________________________________
> 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] <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
>
------------------------------
Message: 12
Date: Fri, 15 Apr 2016 14:57:58 -0500
From: Kevin McGuire <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] get_rx_sensor exceptions
Message-ID:
<cacvsexnkcu_fc5bygnfkrn5qi_emm_fae9ayictq7fdd7ct...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The workaround does seem to be:
for x in xrange(0, 10):
self.tb.lock()
self.tb.unlock()
# Between 0.001 (no errors) and 0.0001 (errors)
time.sleep(0.001)
If the timeout is removed or decreased then the error happens as follows
and the flow graph becomes stopped with the top_block.start Python method
having no effect on starting it again.
thread[thread-per-block[0]: <block gr uhd usrp source (1)>]:
EnvironmentError: IOError: Radio ctrl (0) packet parse error -
AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/kmcguire/sources/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
On Thu, Apr 14, 2016 at 9:07 PM, Kevin McGuire <[email protected]> wrote:
> On Fri, Jan 29, 2016 at 12:17 PM, Michael West via USRP-users <
> [email protected]> wrote:
>
>> Hi tilla,
>>
>> Unlike the socket buffer for the data streams, the socket buffer for the
>> control packets is not resized by UHD. There can be up to 64 control
>> transactions in flight for each of the 2 radios at any given time. Each of
>> those results in an ACK packet that is only ~58 bytes, but some drivers
>> will allocate enough memory from the socket buffer to hold an entire MTU.
>> If your MTU size is 9000, then you will need a default buffer that is at
>> least 1,152,000 bytes (9000 bytes x 64 ACKs x 2 radios). Another option is
>> to reduce the MTU size to 1500.
>>
>> Regards,
>> Michael
>>
>> On Fri, Jan 29, 2016 at 8:49 AM, <[email protected]> wrote:
>>
>>> The only thing that doesnt make sense is re-arranging the threading does
>>> not change the workload on the ethernet segment, we still run at the same
>>> sample rate, we just dont simultaneously retune tx and rx...
>>>
>>> I am not going to lose any sleep over this cuz the application works
>>> with the updated architecture :), but it still a bit perplexing...
>>>
>>> ------------------------------
>>> *From: *"Michael West" <[email protected]>
>>> *To: *"Marcus D. Leech" <[email protected]>
>>> *Cc: *[email protected], "usrp-users" <[email protected]>
>>> *Sent: *Thursday, January 28, 2016 6:34:21 PM
>>>
>>> *Subject: *Re: [USRP-users] get_rx_sensor exceptions
>>>
>>> Hi tilla,
>>>
>>> The assertion failure of "packet_info.packet_count == (seq_to_ack &
>>> 0xfff)" indicates a control packet was dropped. We have seen this caused
>>> by the default socket buffer size being too small. Try increasing the
>>> default socket buffer size to a minimum of 2 MB (sudo sysctl
>>> net.core.rmem_default=2097152.
>>>
>>> Regards,
>>> Michael
>>>
>>
> Users,
>
> I have the same error using the B200. I am not sure what model the
> original author in this thread was using; however, I do believe it may have
> been one of the models that communicates over a Ethernet type network while
> mine communicates over USB 2.0 specifically.
>
> I may be able to dig into the source code and find this, but I wanted to
> throw it out there and perhaps if anyone has any information or insight
> into the issue I would be very graced to hear of it. I am currently having
> the issue when using GNU Radio and doing a few top_block *lock* and
> *unlock* calls in very tight sequence. It takes about 4 back to back sets
> of lock and unlock calls to trigger it.
>
> *It may be that I simply have to produce some latency between the calls.*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/c2190043/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 15 Apr 2016 15:02:47 -0500
From: Kevin McGuire <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] get_rx_sensor exceptions
Message-ID:
<cacvsexnkvhlq3a-ns3ophsrrd7asv7fb50h5fxtcagynfbf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Better:
def __unlock(self):
self.old_unlock()
time.sleep(0.01)
setattr(self.tb, 'old_unlock', self.tb.unlock)
setattr(self.tb, 'unlock', types.MethodType(__unlock, self.tb))
On Fri, Apr 15, 2016 at 2:57 PM, Kevin McGuire <[email protected]> wrote:
> The workaround does seem to be:
>
> for x in xrange(0, 10):
> self.tb.lock()
> self.tb.unlock()
> # Between 0.001 (no errors) and 0.0001 (errors)
> time.sleep(0.001)
>
> If the timeout is removed or decreased then the error happens as follows
> and the flow graph becomes stopped with the top_block.start Python method
> having no effect on starting it again.
>
> thread[thread-per-block[0]: <block gr uhd usrp source (1)>]:
> EnvironmentError: IOError: Radio ctrl (0) packet parse error -
> AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at
> /home/kmcguire/sources/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
>
>
> On Thu, Apr 14, 2016 at 9:07 PM, Kevin McGuire <[email protected]> wrote:
>
>> On Fri, Jan 29, 2016 at 12:17 PM, Michael West via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi tilla,
>>>
>>> Unlike the socket buffer for the data streams, the socket buffer for the
>>> control packets is not resized by UHD. There can be up to 64 control
>>> transactions in flight for each of the 2 radios at any given time. Each of
>>> those results in an ACK packet that is only ~58 bytes, but some drivers
>>> will allocate enough memory from the socket buffer to hold an entire MTU.
>>> If your MTU size is 9000, then you will need a default buffer that is at
>>> least 1,152,000 bytes (9000 bytes x 64 ACKs x 2 radios). Another option is
>>> to reduce the MTU size to 1500.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Jan 29, 2016 at 8:49 AM, <[email protected]> wrote:
>>>
>>>> The only thing that doesnt make sense is re-arranging the threading
>>>> does not change the workload on the ethernet segment, we still run at the
>>>> same sample rate, we just dont simultaneously retune tx and rx...
>>>>
>>>> I am not going to lose any sleep over this cuz the application works
>>>> with the updated architecture :), but it still a bit perplexing...
>>>>
>>>> ------------------------------
>>>> *From: *"Michael West" <[email protected]>
>>>> *To: *"Marcus D. Leech" <[email protected]>
>>>> *Cc: *[email protected], "usrp-users" <[email protected]>
>>>> *Sent: *Thursday, January 28, 2016 6:34:21 PM
>>>>
>>>> *Subject: *Re: [USRP-users] get_rx_sensor exceptions
>>>>
>>>> Hi tilla,
>>>>
>>>> The assertion failure of "packet_info.packet_count == (seq_to_ack &
>>>> 0xfff)" indicates a control packet was dropped. We have seen this caused
>>>> by the default socket buffer size being too small. Try increasing the
>>>> default socket buffer size to a minimum of 2 MB (sudo sysctl
>>>> net.core.rmem_default=2097152.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>
>> Users,
>>
>> I have the same error using the B200. I am not sure what model the
>> original author in this thread was using; however, I do believe it may have
>> been one of the models that communicates over a Ethernet type network while
>> mine communicates over USB 2.0 specifically.
>>
>> I may be able to dig into the source code and find this, but I wanted to
>> throw it out there and perhaps if anyone has any information or insight
>> into the issue I would be very graced to hear of it. I am currently having
>> the issue when using GNU Radio and doing a few top_block *lock* and
>> *unlock* calls in very tight sequence. It takes about 4 back to back
>> sets of lock and unlock calls to trigger it.
>>
>> *It may be that I simply have to produce some latency between the calls.*
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/13e848f3/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 15 Apr 2016 13:35:20 -0700
From: Jonathon Cheah <[email protected]>
To: [email protected]
Subject: [USRP-users] Compiling E310 device driver issue
Message-ID:
<CAKsUvU_j8dM_HxqYs6yYNwBzKh3YPda65ZxNwXu=oSA5=rA=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Attempting to make the Ralink device driver
2011_0719_RT3070_RT337
0_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO in E310, I got the following..
......
make -C tools
make[1]: Entering directory '/home/JC/RA/tools'
gcc -g bin2h.c -o bin2h
make[1]: Leaving directory '/home/JC/RA/tools'
/home/JC/RA/tools/bin2h
cp -f os/linux/Makefile.6 /home/JC/RA/os/linux/Makefile
make -C /lib/modules/3.14.2-xilinx/build SUBDIRS=/home/JC/RA/os/linux
modules
make[1]: Entering directory '/lib/modules/3.14.2-xilinx/build'
make[1]: *** No rule to make target 'modules'. Stop.
make[1]: Leaving directory '/lib/modules/3.14.2-xilinx/build'
Makefile:356: recipe for target 'LINUX' failed
make: *** [LINUX] Error 2
The '/lib/modules/3.14.2-xilinx/build' is empty. Please advise.
V/R,
-jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/5cf315d2/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 15 Apr 2016 19:03:51 -0400
From: Sam Carey <[email protected]>
To: [email protected]
Subject: [USRP-users] Timed Commands with RFNoC Radios
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Howdy,
I?ve been trying to use timed commands with the RFNoC radio blocks (rfnoc-devel
branch), but I can?t find that feature. If I were using normal uhd radios, I
would do something like:
self.uhd_usrp_sink_0.set_command_time(uhd.time_spec(2.0))
self.uhd_usrp_sink_0.set_center_freq(freq_center, 0)
self.uhd_usrp_sink_0.clear_command_time()
self.uhd_usrp_source_0.set_command_time(uhd.time_spec(2.0))
self.uhd_usrp_source_0.set_center_freq(freq_center, 0)
self.uhd_usrp_source_0.clear_command_time()
However, if I try to use RFNoC radios:
self.uhd_rfnoc_streamer_radio_1.set_command_time(uhd.time_spec(2.0))
self.uhd_rfnoc_streamer_radio_1.set_tx_freq(freq_center)
self.uhd_rfnoc_streamer_radio_1.clear_command_time()
self.uhd_rfnoc_streamer_radio_0.set_command_time(uhd.time_spec(2.0))
self.uhd_rfnoc_streamer_radio_0.set_rx_freq(freq_center)
self.uhd_rfnoc_streamer_radio_0.clear_command_time()
It throws errors like:
AttributeError: ?rfnoc_radio_sptr? object has no attribute
?set_command_time?
I looked in gr-ettus/build/swig/ettus_swig.py and did not see
?set_command_time()? listed under "class rfnoc_radio,? although I did see
?set_rx_freq().?
Could you please explain how I can use timed commands with RFNoC radios?
Thanks,
Sam Carey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160415/39ee2e57/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 15 Apr 2016 23:13:44 +0000
From: Xingjian Chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] (no subject)
Message-ID: <CE1BA7E5929533488C6364476B9C23A81AD7F978@oit-ex2010-mb3>
Content-Type: text/plain; charset="us-ascii"
Hi there,
What is the isolation between the transmitter and receiver of B200mini? I tuned
the gain to maximum for both transmitter and receiver, terminated transmitter
and receiver with matched loads. When I transmit and receive at the same time,
I can still see clearly transmitted waveform in my received file. Any ideas to
prevent this? What I probably have to do is decreasing the gain and adding
external amplifiers.
Best
------------------------------
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 68, Issue 17
******************************************
