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. uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Swanson, Craig)
2. x310 loopback test (Tihomir Mescic)
3. Run Python Script after boot without Login - E310 (David Hamann)
4. srsLTE & X300 box. (Jasuja, Ishwar)
5. Error when executing flowgraph with rfnoc-radio-redo with
moving_avg and fifo (Swanson, Craig)
6. Re: x310 loopback test (Derek Kozel)
7. Re: Error when executing flowgraph with rfnoc-radio-redo with
moving_avg and fifo (Jonathon Pendlum)
8. Re: Error when executing flowgraph with rfnoc-radio-redo with
moving_avg and fifo (Martin Braun)
9. Re: uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Jonathon Pendlum)
10. Re: Error: RuntimeError: x300_dac_ctrl: timeout waiting for
DAC PLL to lock (Jonathon Pendlum)
11. Re: Resetting N210 & X310 Remotely (Neel Pandeya)
12. Re: USRP2 not communicating (Neel Pandeya)
13. Re: Fw: USRP2 not communicating (Neel Pandeya)
14. Re: Zero sample rx_time tag value not zero (Ashish Chaudhari)
15. Re: Reg : custom_dsp_rx.v for B210 (Ashish Chaudhari)
16. Re: Reg : Invoking FPGA functions thru C program
(Ashish Chaudhari)
17. Re: Resetting N210 & X310 Remotely (Michael West)
18. USRP2 not communicating (md mahbubur)
19. Re: Octoclock updating firmware & change ip (Nicholas Corgan)
20. Re: USRP2 not communicating (Neel Pandeya)
21. X310 RFNOC getting UHD to recognize new RFNOC block (James Wagner)
22. Re: Problem with gr-ettus OFDM sync block (Martin Braun)
23. Re: Octoclock updating firmware & change ip (Michael West)
24. Re: Problem with gr-ettus OFDM sync block (Sergio Cruz Perez)
25. Define custom setting register on x310 and access them from
uhd. (Patrick Berger)
26. Re: Problem with gr-ettus OFDM sync block (Martin Braun)
27. 'internal' spurs with GPSDO (John Shields)
28. csma in rfnoc (Ekko)
29. Re: Decaying RX energy & oscillations on N210+RFX2450 Re:
Frequency synchronization problem (Marcus D. Leech)
30. Re: Error: RuntimeError: x300_dac_ctrl: timeout waiting for
DAC PLL to lock (Swanson, Craig)
31. Re: uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Swanson, Craig)
32. Re: Resetting N210 & X310 Remotely (Dave NotTelling)
33. USRP2 not communicating (md mahbubur)
34. Re: Octoclock updating firmware & change ip (Pol Henarejos)
35. RFNoC with E310 (john liu)
36. E310 rates and frequencies (????)
37. 2 heterogeneous TX channels on X310 (LEMENAGER Claude)
38. Re: USRP2 not communicating (Marcus D. Leech)
39. Re: E310 rates and frequencies (Marcus D. Leech)
40. Re: uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Jonathon Pendlum)
41. GPSDO as stand-alone component (Claudio Cicconetti)
42. ??RE: E310 rates and frequencies (????)
43. Re: csma in rfnoc (Jonathon Pendlum)
44. Re: uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Swanson, Craig)
45. Re: ??RE: E310 rates and frequencies (Marcus D. Leech)
46. Re: Resetting N210 & X310 Remotely (Dan CaJacob)
47. [RFNoC] X310 timeout during uhd_usrp_probe (Collins, Richard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Jun 2016 16:19:29 +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] uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
I made it past my problem of using rfnoc-radio-redo with my X310.
Using my own python code running in cocotb, I was able to simulate the
noc_block_skeleton.v file and in the process learned a lot more about flow
control and the changes you made from the rfnoc-devel branch.
My testbench imports my file sink data generated by gnuradio and runs the data
through your noc_block_skeleton.v file. Then I renamed the
noc_block_skeleton.v as noc_block_Receiver.v and generated a bit file. I also
generated the necessary XML files with a unique NOC ID so uhd_usrp_probe would
recognize it.
What is strange is that uhd_usrp_probe recognized my .bit file but didn't match
it up with my
Receiver.xml file located in /usr/local/share/uhd/rfnoc/blocks/Receiver.xml.
My NOC ID for Receiver is 614A. (Today's date)
Instead it matched it with the block.xml. It also named it block instead of
Receiver.
I also tried imitating the noc_block_moving_avg instead of noc_block_skeleton
and I got the same result.
How can this be? I have done this plenty of times with the rfnoc-devel branch
coupled with my E310.
Also I thought the rfnoc-radio-redo branch eliminated one of the radios?
Shown below is a portion of what I got when I ran uhd_usrp_probe --init-only
Craig
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:6e>02:70)...Setting up NoC-Shell Control for port #0 (SID:
00:6e>02:70)...OK
-- Port 112: Found NoC-Block with ID 614A000000000000.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Using default block configuration.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- [RFNoC Factory] Using controller key 'Block' and block name 'Block'
-- block_ctrl_base()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x614A000000000000 Block ID: 0/Block_0
-- [0/Block_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/Block_0] block_ctrl_base::_clear()
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/MovingAverage_0
-- * 0/Block_0
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached from
b62d96c))$ cd ..
?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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/294b4c15/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 14 Jun 2016 10:46:55 +0200 (CEST)
From: Tihomir Mescic <[email protected]>
To: [email protected]
Subject: [USRP-users] x310 loopback test
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I recently bought the x310 device with the UBX 160 daughterboard. I would now
like to perform a loopback test - by connecting the TX and RX channels with a
cable, then transmitting the signal on the TX and simultaneously receiving it
on the RX channel. I've heard that this can be dangerous because to signal
strength on the TX is too high for the RX so I've bought the Loopback kit
(https://www.ettus.com/product/details/LPBK-KIT). I have a couple of questions.
1) Is it safe to connects the TX and RX with a cable plus a single attenuator
(30 dB, 50Ohm) or do I need to use both attenuators that I got in the kit
(serial connection)?
2) When I connect the TX and RX through the cable plus the attenuator (or two)
do I need to make sure that the gain on the TX channel that I set in software
that I use (GNU radio) is not too big to avoid damage on the device?
Kind regards,
Tihomir
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/beaf848f/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 14 Jun 2016 14:03:13 +0200
From: David Hamann <[email protected]>
To: [email protected]
Subject: [USRP-users] Run Python Script after boot without Login -
E310
Message-ID:
<CAJP+TgR72Zj8TW4FPTMHO=mkmbtf5mutd3ap12chlcqc-xf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
being new to the USRP/Linux world I'd like to configure my E310 in a way
that it runs a python script automatically after booting if no Login is
performed within a given time (let's say a Minute or so).
Can I simply add a line to one of the scripts in one of the rcX.d, does it
have to be included in the init.d and how would I include the nologin
function?
Any help is appreciated!
Regards,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/bb5674bc/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 14 Jun 2016 16:11:20 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] srsLTE & X300 box.
Message-ID:
<by2pr1001mb1061936133cec5fdafcc8d8bec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
Has anyone been running srsLTE software on X300? I have not had much luck with
it. I have tried different X300 FPGA versions (15.0 & 20.0) but could not get
pdsch_enodeb test app to work.
I am connected to the X300 box on GigE interface. If the mtu value is left at
default (1500) value, then I get continuous Underruns. If I increase the MTU
value to a large value (> 5000), then I get following error.
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
If anyone has this test-app running, can you please let me know what version of
FPGA & UHD Host drivers you are using? Also, how X300 box is connected to PC
that is running the test app.
I am using quad-core machine with following x86 CPU.
model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
I don't have any other app running on this machine ( which could starve the
test app).
Strange thing is that the pdsch_ue app does not give this error.
Any help will be greatly appreciated.
Note: I asked for help on srsLTE mailing list and author asked me to run the
question by this mailing list.
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/250daefc/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 14 Jun 2016 16:58:28 +0000
From: "Swanson, Craig" <[email protected]>
To: Martin Braun <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] Error when executing flowgraph with
rfnoc-radio-redo with moving_avg and fifo
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Martin,
Now that I am using rfnoc-radio-redo, I am getting the following error when
executing my flowgraph:
Generating:
'/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
Generating:
'/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
Executing: /usr/bin/python2 -u
/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-549-geb3036f6
Traceback (most recent call last):
File
"/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
line 266, in <module>
main()
File
"/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
line 254, in main
tb = top_block_cls()
File
"/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
line 62, in __init__
self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
",".join(("type=x300", "")) ))
AttributeError: 'module' object has no attribute 'device3'
>>> Done (return code 1)?
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/302c5f15/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 14 Jun 2016 10:44:16 -0700
From: Derek Kozel <[email protected]>
To: Tihomir Mescic <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 loopback test
Message-ID:
<CAA+K=tvaHJMd4F0FqH5=g4z3xlza9v+fneyr3cqsx2spa3q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Tihomir,
The 30 dB attenuator is sufficient to provide protection for any amount of
transmit and receive gain. You will see clipping though with maximum gains
so it is a good idea to find a balance of transmit and receive gain for
best performance.
Regards,
Derek
On Tue, Jun 14, 2016 at 1:46 AM, Tihomir Mescic via USRP-users <
[email protected]> wrote:
> Hi everyone,
>
> I recently bought the x310 device with the UBX 160 daughterboard. I would
> now like to perform a loopback test - by connecting the TX and RX channels
> with a cable, then transmitting the signal on the TX and simultaneously
> receiving it on the RX channel. I've heard that this can be dangerous
> because to signal strength on the TX is too high for the RX so I've bought
> the Loopback kit (https://www.ettus.com/product/details/LPBK-KIT). I have
> a couple of questions.
>
> 1) Is it safe to connects the TX and RX with a cable plus a single
> attenuator (30 dB, 50Ohm) or do I need to use both attenuators that I got
> in the kit (serial connection)?
>
> 2) When I connect the TX and RX through the cable plus the attenuator (or
> two) do I need to make sure that the gain on the TX channel that I set in
> software that I use (GNU radio) is not too big to avoid damage on the
> device?
>
> Kind regards,
> Tihomir
>
>
>
> _______________________________________________
> 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/20160614/fecfe41b/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 14 Jun 2016 13:41:36 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error when executing flowgraph with
rfnoc-radio-redo with moving_avg and fifo
Message-ID:
<cagdo0urzuctzmj14dwrhnx3u6vhpbnre5k8+db+3dctmhmd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI Craig,
That kind of error usually means you didn't get gr-ettus installed
correctly. Try reinstalling it and see if it that fixes it.
Jonathon
On Tue, Jun 14, 2016 at 11:58 AM, Swanson, Craig via USRP-users <
[email protected]> wrote:
> ?Martin,
>
> Now that I am using rfnoc-radio-redo, I am getting the following error
> when executing my flowgraph:
>
>
> Generating:
> '/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
>
> Generating:
> '/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
>
> Executing: /usr/bin/python2 -u
> /home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py
>
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-radio-redo-549-geb3036f6
>
> Traceback (most recent call last):
> File
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 266, in <module>
> main()
> File
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 254, in main
> tb = top_block_cls()
> File
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 62, in __init__
> self.device3 = variable_uhd_device3_0 =
> ettus.device3(uhd.device_addr_t( ",".join(("type=x300", "")) ))
> AttributeError: 'module' object has no attribute 'device3'
>
> >>> Done (return code 1)?
>
>
>
> 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>
>
>
>
> _______________________________________________
> 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/20160614/f068904c/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 14 Jun 2016 11:43:09 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Error when executing flowgraph with
rfnoc-radio-redo with moving_avg and fifo
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Oh yeah, my other message (off-list), is wrong. Jonathon is right.
M
On 06/14/2016 11:41 AM, Jonathon Pendlum wrote:
> HI Craig,
>
> That kind of error usually means you didn't get gr-ettus installed
> correctly. Try reinstalling it and see if it that fixes it.
>
>
>
> Jonathon
>
> On Tue, Jun 14, 2016 at 11:58 AM, Swanson, Craig via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> ?Martin,
>
> Now that I am using rfnoc-radio-redo, I am getting the following
> error when executing my flowgraph:
>
>
> Generating:
>
> '/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
>
> Generating:
>
> '/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py'
>
> Executing: /usr/bin/python2 -u
>
> /home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py
>
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-radio-redo-549-geb3036f6
>
> Traceback (most recent call last):
> File
>
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 266, in <module>
> main()
> File
>
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 254, in main
> tb = top_block_cls()
> File
>
> "/home/craig/cocotb/examples/noc_block_Receiver/tests/noc_block_Receiver_rx.py",
> line 62, in __init__
> self.device3 = variable_uhd_device3_0 =
> ettus.device3(uhd.device_addr_t( ",".join(("type=x300", "")) ))
> AttributeError: 'module' object has no attribute 'device3'
>
> >>> Done (return code 1)?
>
>
>
> 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>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 9
Date: Tue, 14 Jun 2016 13:47:15 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] uhd_usrp_probe in rfnoc-radio-redo for
custom noc_block_Receiver in uhd_usrp_probe is showing up as Block
Message-ID:
<CAGdo0uRcFL41=rny+badjhnc8i-vky77od-xbcjxbnb+ep7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
block.xml is the default XML that is loaded when a block's XML is not found
-- basically a NOC ID is not matched with a corresponding XML file. Double
check your XML file is installed in the right place (looks
like /usr/local/share/uhd/rfnoc from the log), that the NOC IDs match, and
that you don't have any syntax errors in the XML file.
Jonathon
On Tue, Jun 14, 2016 at 11:19 AM, Swanson, Craig <
[email protected]> wrote:
> ?Jonathon,
>
> I made it past my problem of using rfnoc-radio-redo with my X310.
>
> Using my own python code running in cocotb, I was able to simulate the
> noc_block_skeleton.v file and in the process learned a lot more about flow
> control and the changes you made from the rfnoc-devel branch.
>
> My testbench imports my file sink data generated by gnuradio and runs the
> data through your noc_block_skeleton.v file. Then I renamed the
> noc_block_skeleton.v as noc_block_Receiver.v and generated a bit file. I
> also generated the necessary XML files with a unique NOC ID so
> uhd_usrp_probe would recognize it.
>
>
> What is strange is that uhd_usrp_probe recognized my .bit file but didn't
> match it up with my
>
> Receiver.xml file located in
> /usr/local/share/uhd/rfnoc/blocks/Receiver.xml. My NOC ID for Receiver is
> 614A. (Today's date)
>
> Instead it matched it with the block.xml. It also named it block instead
> of Receiver.
>
>
> I also tried imitating the noc_block_moving_avg instead of
> noc_block_skeleton and I got the same result.
>
>
> How can this be? I have done this plenty of times with the rfnoc-devel
> branch coupled with my E310.
>
> Also I thought the rfnoc-radio-redo branch eliminated one of the radios?
>
> Shown below is a portion of what I got when I ran uhd_usrp_probe
> --init-only
>
>
> Craig
>
>
> -- [RFNOC] ------- Block Setup -----------
> -- SEND (SID: 00:6e>02:70)...Setting up NoC-Shell Control for port #0
> (SID: 00:6e>02:70)...OK
> -- Port 112: Found NoC-Block with ID 614A000000000000.
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Using default block configuration.
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
> -- [RFNoC Factory] block_ctrl_base::make()
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- [RFNoC Factory] Using controller key 'Block' and block name 'Block'
> -- block_ctrl_base()
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- base_path = "/usr/local/share/uhd/rfnoc"
> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x614A000000000000 Block ID: 0/Block_0
> -- [0/Block_0] block_ctrl_base::clear()
> -- node_ctrl_base::clear()
> -- [0/Block_0] block_ctrl_base::_clear()
> -- [0/Block_0] Adding port definition at xbar/Block_0/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Block_0] Adding port definition at xbar/Block_0/ports/out/0: type =
> '' pkt_size = '0' vlen = '0'
> -- ========== Full list of RFNoC blocks: ============
> -- * 0/Radio_0
> -- * 0/Radio_1
> -- * 0/FIFO_0
> -- * 0/MovingAverage_0
> -- * 0/Block_0
> craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached
> from b62d96c))$ cd ..
>
> ?*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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/1b0fabed/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 14 Jun 2016 13:54:05 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Error: RuntimeError: x300_dac_ctrl: timeout
waiting for DAC PLL to lock
Message-ID:
<cagdo0uriztbwxd8u3yhrcb7uagvko5r5jyeebh17cvbjwdg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
Was this resolved by using the correct FPGA image?
Jonathon
On Sat, Jun 11, 2016 at 11:16 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I am getting this error when I run uhd_usrp_probe --init-only on an X310
> using noc_block_skeleton in rfnoc-radio-redo:
>
>
> craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached
> from b62d96c))$ uhd_usrp_probe --init-only
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
>
> -- 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...
> -- Radio 0 Ctrl SID: 00:00>02:30
> -- Performing register loopback test... fail
> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock
>
> ?
>
>
>
> *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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/438a7287/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 14 Jun 2016 12:32:38 -0700
From: Neel Pandeya <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Resetting N210 & X310 Remotely
Message-ID:
<CACaXmv826sju+J9JXBUzevROaZt3=5jl6r8ckv1jcdtib8h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dave:
By reset, do you mean to power cycle, or to reset to some known initial
state? There is no API call in UHD to reset or power cycle the radio. You
might be able to achieve the same goal by using a managed power strip [1,2].
[1] http://www.digital-loggers.com/lpc.html
[2] https://www.amazon.com/gp/product/B00EZWD146/
--Neel Pandeya
On 18 May 2016 at 13:20, Dave NotTelling via USRP-users <
[email protected]> wrote:
> Is it possible to reset the N210 and X310 radios remotely? Hopefully some
> API command that can trigger something like an FPGA reset / bit file reload?
>
> Thanks!
>
> _______________________________________________
> 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/20160614/9e06b0bb/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 14 Jun 2016 12:45:19 -0700
From: Neel Pandeya <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 not communicating
Message-ID:
<cacaxmv-_czulq5fx6mz9a77+92lhdnevledbtoz3aeqa--e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mahbubur Rahman:
What is the exact command that you're using to burn the SD Card??
Make sure that the SD Card is not mounted or in use when you're trying to
write to it.
You mentioned that you're using
uhd-images_003.010.twinrx-devel-234-g6189cea6. You should be using a tagged
release of UHD, such as 3.9.4. The images for 3.9.4 are here:
http://files.ettus.com/binaries/images/uhd-images_003.009.004-release.tar.gz
--Neel Pandeya
On 10 June 2016 at 18:47, md mahbubur via USRP-users <
[email protected]> wrote:
>
>
> Sent from Yahoo7 Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Sat, 11 Jun, 2016 at 11:17 AM, md mahbubur
> <[email protected]> wrote:
> Hi,
> Currently, I am working with USRP2 device for my research. I have been
> trying to activate this previously used device for last three days but
> failed to make it talk to my computer(Mac OSx El Capitan) via ping command
> (usb2 ethernet adapter is used for connection between computer and device;
> also direct ethernet cable connection was tested with another pc but seems
> the device is dead, no response!). Then I assumed the there might be a
> firmware issue. I erased the sd card and tried to copy usrp2_fw.bin and
> usrp2_fpga.bin files via sdcard_burner_gui.py program but the program was
> giving an error saying "the dd/disk3: resource is busy!". However, Then I
> tried to copy those files by drag and dropping them, which copied well but
> couldn't help to communicate the device. The device loads the firmware
> first and stays with only F LED indicator lit up. In this instance, I need
> suggestion what should I do to make it run! P.S. bin files are collected
> from
> ??
> uhd-images_003.010.twinrx-devel-234-g6189cea6 folder from ettus support
> website. Thanks
> [image: Inline image]
>
> Regards,
> ??
> Mahbubur Rahman
> Univerity of New South Wales, Australia
>
>
> _______________________________________________
> 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/20160614/2769b3bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blob.jpg
Type: image/png
Size: 519417 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/2769b3bf/attachment-0001.jpg>
------------------------------
Message: 13
Date: Tue, 14 Jun 2016 12:48:22 -0700
From: Neel Pandeya <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Fw: USRP2 not communicating
Message-ID:
<CACaXmv_5qrQVYq76ag1uX4eFyHCDMLnr=mqfg+jtm89vilx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mahbubur Rahman:
What is the exact command that you're using to burn the SD Card??
Make sure that the SD Card is not mounted or in use when you're trying to
write to it.
You mentioned that you're using
uhd-images_003.010.twinrx-devel-234-g6189cea6. You should be using a tagged
release of UHD, such as 3.9.4. The images for 3.9.4 are here:
http://files.ettus.com/binaries/images/uhd-images_003.009.004-release.tar.gz
--Neel Pandeya
On 10 June 2016 at 18:47, md mahbubur via USRP-users <
[email protected]> wrote:
>
>
> Sent from Yahoo7 Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Sat, 11 Jun, 2016 at 11:17 AM, md mahbubur
> <[email protected]> wrote:
> Hi,
> Currently, I am working with USRP2 device for my research. I have been
> trying to activate this previously used device for last three days but
> failed to make it talk to my computer(Mac OSx El Capitan) via ping command
> (usb2 ethernet adapter is used for connection between computer and device;
> also direct ethernet cable connection was tested with another pc but seems
> the device is dead, no response!). Then I assumed the there might be a
> firmware issue. I erased the sd card and tried to copy usrp2_fw.bin and
> usrp2_fpga.bin files via sdcard_burner_gui.py program but the program was
> giving an error saying "the dd/disk3: resource is busy!". However, Then I
> tried to copy those files by drag and dropping them, which copied well but
> couldn't help to communicate the device. The device loads the firmware
> first and stays with only F LED indicator lit up. In this instance, I need
> suggestion what should I do to make it run! P.S. bin files are collected
> from uhd-images_003.010.twinrx-devel-234-g6189cea6 folder from
> ettus support website. Thanks
> [image: Inline image]
>
> Regards,
> Mahbubur Rahman
> Univerity of New South Wales, Australia
>
>
> _______________________________________________
> 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/20160614/e710a956/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blob.jpg
Type: image/png
Size: 519417 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/e710a956/attachment-0001.jpg>
------------------------------
Message: 14
Date: Tue, 14 Jun 2016 13:03:29 -0700
From: Ashish Chaudhari <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Zero sample rx_time tag value not zero
Message-ID:
<caozxt+bt2p0bsq2udxjiytbbaoulfyjv4drh7j2dahnzzpd...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Jacob,
Unfortunately your assumption of time = 0 corresponding to the ADC
conversion is not true. The time-stamp associated with each sample
corresponds to the time at with it was framed/deframed into a packet
so it depends on the sample rate and packet size in addition to some
other parameters. On the RX side, framing happens after the signal
propagates through the RF chain, gets digitized by the ADC, gets
filtered by the DSP chain and after it traverses a short sample
buffer. In order to accurately synchronize TX to RX, I would recommend
doing a pulse/burst based calibration with the daughterboard in a
TX->RX RF loopback configuration. That way you are compensating for
any delay variations upstream from the ADC as well. You could send a
burst at TX time 0 and look at a reasonable amount of RX data and
detect when it shows up and use that time-stamp as the cumulative TX
to RX latency.
Thanks,
Ashish Chaudhari
On Mon, Jun 6, 2016 at 12:45 PM, Jacob Gilbert via USRP-users
<[email protected]> wrote:
> I am working on an application that requires very precise rx/tx time
> synchronization and have noticed something unexpected that I am looking for
> a little clarification on. The USRP is a B200 mini and UHD release 3.9.2.
> Currently I start my flowgraph as follows so that I know exactly when it
> started - in this case, at time = {1, 0.0}.
>
> 1) tb = <tb setup here, just a USRP source, tag debug and null sink>
> 2) tb.usrp_src.set_time_unknown_pps(uhd.time_spec_t(0.0))
> 3) tb.usrp_src.set_start_time(uhd.time_spec_t(1.0))
> 4) tb.run()
>
> I would therefore expect the first sample received to be representative of
> the signal digitized at time {1, 0.0} within a small margin due to
> decimation. I would also expect to receive a rx_time tag on the first sample
> with value {1, 0.0} however I receive a tag with the floating point
> component of the tuple off by some number of microseconds. This number is
> precisely repeatable upon consecutive runs, and depends on master clock rate
> and FPGA decimation and nothing else I can see:
>
> For example (B200 Mini):
> 1) Master Rate = 32M, decim = 100, output = 320k: rx_time = {1 0.000112531}
> 2) Master Rate = 16M, decim = 50, output = 320k: rx_time = {1 7.68125e-05}
> 3) Master Rate = 32M, decim = 50, output = 640k: rx_time = {1 3.84063e-05}
> 4) Master Rate = 16M, decim = 20, output = 800k: rx_time = {1 4.75625e-05}
> 5) Master Rate = 32M, decim = 20, output = 1.6M: rx_time = {1 2.37812e-05}
> 6) Master Rate = 16M, decim = 10, output = 1.6M: rx_time = {1 1.68125e-05}
>
> I am assuming this is due to internal FPGA filter group delay as for a
> particular decimation the offset represents the same number of samples but
> want to verify.
>
> Is my initial assumption that the 0th sample was digitized at exactly {1,
> 0.0} correct? Is there an identical delay on the transmit path (or some
> other delay that can be calculated) so transmission (at DAC) relative to
> receive (at ADC) can be synchronized within a sample or two? Is this even
> necessary?
>
> Thank you,
> Jacob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 15
Date: Tue, 14 Jun 2016 13:07:42 -0700
From: Ashish Chaudhari <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Reg : custom_dsp_rx.v for B210
Message-ID:
<caozxt+c+cbdrpckop_tj9czdc5expezaaj-wq6o934npjyk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Sumit,
The sample data-path in the B210 FPGA is very different so it does not
have the same custom_dsp hooks as the N210. If you have some custom
DSP to insert, you can do so in the radio module:
https://github.com/EttusResearch/fpga/blob/master/usrp3/lib/radio/radio_legacy.v
Thanks,
Ashish Chaudhari
Ashish Chaudhari | Senior Software Engineer | Software Defined Radio
Ettus Research, A National Instruments Company
[email protected]
On Sun, Jun 5, 2016 at 6:03 PM, Sumit Kumar via USRP-users
<[email protected]> wrote:
> Do we have something like
>
> custom_dsp_rx.v
>
> for B210 also. It was there for N series.
>
> Regards
>
> Sumit
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Tue, 14 Jun 2016 13:21:20 -0700
From: Ashish Chaudhari <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Reg : Invoking FPGA functions thru C program
Message-ID:
<CAOzXT+BYc4ZVE061Vd6S-Ruj4t7emJmMw=+3aca9lm7kkzh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Sumit,
If by "my own function in Verilog" you mean you want to access memory
mapped registers you can do so in the radio module [1] in the FPGA. It
gives you access to 32-bit registers with a shared 8 bit address
space. If you add your registers to avoid the ranges in [2] then you
should be able to safely write them from software without affecting
the operation of the device. In UHD the interface to access your new
registers would be [3] and it is instantiated in the B2x0 codebase in
[4]
[1]
https://github.com/EttusResearch/fpga/blob/master/usrp3/lib/radio/radio_legacy.v#L154
[2]
https://github.com/EttusResearch/fpga/blob/master/usrp3/lib/radio/radio_legacy.v#L119
[3]
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/radio_ctrl_core_3000.hpp
[4]
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/b200/b200_impl.cpp#L755
Thanks,
Ashish Chaudhari
Ashish Chaudhari | Senior Software Engineer | Software Defined Radio
Ettus Research, A National Instruments Company
[email protected]
On Tue, Jun 14, 2016 at 6:12 AM, Sumit Kumar via USRP-users
<[email protected]> wrote:
> This is a very basic question I guess. Suppose I write my own function in
> Verilog for B210 FPGA, how will I execute that function from my own C
> program.
>
> Context : Developing MAC layer for 802.11a. Writing some functions to be
> implemented inside FPGA.
>
> Any pointers on this. Its a very new work for me and I am puzzled.
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Tue, 14 Jun 2016 13:21:42 -0700
From: Michael West <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: Dave NotTelling <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Resetting N210 & X310 Remotely
Message-ID:
<cam4xkrphk5jrzvpsmkwepj5gp6jwvkx9oxurezqzmfergha...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There is no software reset built in. You can accomplish it by either 1)
adding remote power management as Neel indicated or 2) by loading the FPGA
image via JTAG. Remote power cycling will be instant. Loading the FPGA
image over JTAG takes ~20 second and means connecting a JTAG programmer to
the J203 header on the N210 and a USB cable to the JTAG port on the front
panel of the X310.
Regards,
Michael
On Tue, Jun 14, 2016 at 12:32 PM, Neel Pandeya via USRP-users <
[email protected]> wrote:
> Hello Dave:
>
> By reset, do you mean to power cycle, or to reset to some known initial
> state? There is no API call in UHD to reset or power cycle the radio. You
> might be able to achieve the same goal by using a managed power strip [1,2].
>
> [1] http://www.digital-loggers.com/lpc.html
> [2] https://www.amazon.com/gp/product/B00EZWD146/
>
> --Neel Pandeya
>
>
>
> On 18 May 2016 at 13:20, Dave NotTelling via USRP-users <
> [email protected]> wrote:
>
>> Is it possible to reset the N210 and X310 radios remotely? Hopefully
>> some API command that can trigger something like an FPGA reset / bit file
>> reload?
>>
>> Thanks!
>>
>> _______________________________________________
>> 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/20160614/3303cdcf/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 14 Jun 2016 20:28:13 +0000 (UTC)
From: md mahbubur <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP2 not communicating
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,Currently, I am working with USRP2 device for my research. I have been
trying to activate this previously used device for last three days but failed
to make it talk to my computer(Mac?OSx?El Capitan) via ping command (usb2
ethernet adapter is used for connection between computer and device; also
direct ethernet cable connection was tested with another?pc?but seems the
device is dead, no response!). Then I assumed the there might be a firmware
issue. I erased the sd card and tried to copy usrp2_fw.bin and usrp2_fpga.bin
files via sdcard_burner_gui.py program but the program was giving an error
saying "the dd/disk3: resource is busy!". However, Then I tried to copy those
files by drag and dropping them, which copied well but couldn't help to
communicate the?device. The device loads the firmware first and stays with only
F LED indicator lit up. In this instance, I need suggestion what should I do to
make it run! P.S. bin files are collected
from?uhd-images_003.010.twinrx-devel-234-g6
189cea6 folder from ettus?support website. Thanks
Regards,Mahbubur RahmanUniverity of New South Wales, Australia
Sent from Yahoo7 Mail on Android
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/b56d776f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blob.jpg
Type: image/png
Size: 519417 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/b56d776f/attachment-0001.jpg>
------------------------------
Message: 19
Date: Tue, 14 Jun 2016 13:30:37 -0700
From: Nicholas Corgan <[email protected]>
To: Pol Henarejos <[email protected]>
Cc: "usrp-users lists.ettus.com" <[email protected]>
Subject: Re: [USRP-users] Octoclock updating firmware & change ip
Message-ID:
<cagcyn2oxs6af4kmqdsayttnshghzghrnbkxc0m9w6n6zzhm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Apologies for the delayed response.
When you power on your OctoClock-G, do all three LED's in the left column
light up, or does only the Internal LED light up?
On Wed, Jun 1, 2016 at 6:30 AM, Pol Henarejos via USRP-users <
[email protected]> wrote:
> Dear all,
>
> Recently we acquired an Octoclock-G. When I try to upgrade the firmware to
> the newest image, I get the following error:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$ sudo uhd_image_loader
> --args="type=octoclock,addr=192.168.10.3"
> linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.002-0-gf18abe54
>
> Unit: OctoClock (192.168.10.3)
> Firmware: /usr/local/share/uhd/images/octoclock_r4_fw.hex
> -- Resetting into bootloader...failed.
> Error: RuntimeError: Failed to reset OctoClock.
>
> And no additional messges.
>
> Plus, when I try to change the default IP I get:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$ ./octoclock_burn_eeprom
> --args="addr=192.168.10.3"
> --values="ip-addr=10.1.1.10,netmask=255.0.0.0,gateway=10.1.1.1"
> linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.002-0-gf18abe54
>
> Creating OctoClock device from args: addr=192.168.10.3
> -- Opening an OctoClock device...
> -- Detecting internal GPSDO...No GPSDO found
>
> UHD Warning:
> Device reports that it has a GPSDO, but we cannot communicate with it.
>
> -- Detecting external reference...false
> -- Detecting switch position...Prefer external
> -- Device is using internal reference
>
> Fetching current settings from EEPROM...
> EEPROM ["ip-addr"] is "192.168.10.3"
> EEPROM ["netmask"] is "255.255.255.0"
> EEPROM ["gateway"] is "192.168.10.1"
>
> Setting EEPROM ["ip-addr"] to "10.1.1.10"...
> Setting EEPROM ["netmask"] to "255.0.0.0"...
> Setting EEPROM ["gateway"] to "10.1.1.1"...
> Error: RuntimeError: Error writing to OctoClock EEPROM.
>
> Could someone help me to update and change IP of the octoclock?
>
> Thank you so much.
>
> --
> Pol Henarejos
> Research Engineer, MSc
> [email protected]
>
> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
> Engineering Unit
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels
> Tel: +34 93 396 71 70 Ext: 2177
> Fax. +34 93 645 29 01
> www.cttc.es
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Nicholas Corgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/e65f1cfe/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 14 Jun 2016 13:32:30 -0700
From: Neel Pandeya <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 not communicating
Message-ID:
<CACaXmv9Nq=Dmc-hBEVyCM9gAFfjNuaNUDS7=a389o9iawsx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mahbubur Rahman:
What is the exact command that you're using to burn the SD Card??
Make sure that the SD Card is not mounted and is not in use when you're
trying to write to it.
You mentioned that you're using
uhd-images_003.010.twinrx-devel-234-g6189cea6. You should not be using this
version. You should be using a tagged release of UHD, such as 3.9.4. The
images for 3.9.4 are here:
http://files.ettus.com/binaries/images/uhd-images_003.009.004-release.tar.gz
--Neel Pandeya
On 14 June 2016 at 13:28, md mahbubur via USRP-users <
[email protected]> wrote:
> Hi,
> Currently, I am working with USRP2 device for my research. I have been
> trying to activate this previously used device for last three days but
> failed to make it talk to my computer(Mac OSx El Capitan) via ping command
> (usb2 ethernet adapter is used for connection between computer and device;
> also direct ethernet cable connection was tested with another pc but seems
> the device is dead, no response!). Then I assumed the there might be a
> firmware issue. I erased the sd card and tried to copy usrp2_fw.bin and
> usrp2_fpga.bin files via sdcard_burner_gui.py program but the program was
> giving an error saying "the dd/disk3: resource is busy!". However, Then I
> tried to copy those files by drag and dropping them, which copied well but
> couldn't help to communicate the device. The device loads the firmware
> first and stays with only F LED indicator lit up. In this instance, I need
> suggestion what should I do to make it run! P.S. bin files are collected
> from uhd-images_003.010.twinrx-devel-234-g6189cea6 folder from
> ettus support website. Thanks
> [image: Inline image]
>
> Regards,
> Mahbubur Rahman
> Univerity of New South Wales, Australia
>
> Sent from Yahoo7 Mail on Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> _______________________________________________
> 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/20160614/0fcd1ef7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blob.jpg
Type: image/png
Size: 519417 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/0fcd1ef7/attachment-0001.jpg>
------------------------------
Message: 21
Date: Tue, 14 Jun 2016 13:37:08 -0700
From: James Wagner <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] X310 RFNOC getting UHD to recognize new RFNOC
block
Message-ID:
<ca+usoo+o2qyge_exu6ojxf12-zb6-xprf8iu4pc_af0nqd6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
we have created a RFNOC block and then successfully loaded it into the
x310's FPGA but now we are not sure exactly what has to be done in order to
get the UHD to recognize and communicate with it. looking at the getting
started page we were able to create an XML which seems to enable the
uhd_usrp_probe to run without seg faulting but the outputted list of blocks
shows a blank name for our block. the getting started page also suggested
that a header and implementation for a block controller would need to
created but seeing how only the fir has it's own block controller(and that
seems to be for a special method to load the taps) I am not sure that
requirement is still current.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/9e417e91/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 14 Jun 2016 13:37:20 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Problem with gr-ettus OFDM sync block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Sergio,
can you please reiterate what the problems where that you saw?
Is this still the error you're seeing:
```
File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
3002, in set_argreturn _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/xbar/SchmidlCox_0/args/0/offset/value
```
-- M
On 06/07/2016 10:23 AM, Sergio Cruz Perez wrote:
> 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
>
------------------------------
Message: 23
Date: Tue, 14 Jun 2016 13:43:39 -0700
From: Michael West <[email protected]>
To: Nicholas Corgan <[email protected]>
Cc: Pol Henarejos <[email protected]>, "usrp-users
lists.ettus.com" <[email protected]>
Subject: Re: [USRP-users] Octoclock updating firmware & change ip
Message-ID:
<CAM4xKrp0m0SDgW=uq2uz8d2d5_vpxjj1unf0nyj_hz8-kek...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pol,
What Nicholas is asking is if your Octoclock has the bootloader. Since the
image loader reported "-- Resetting into bootloader...failed.", it seems
like your Octoclock is missing the bootloader. Upgrading the firmware with
uhd_image_loader will not work if the bootloader is not present. Loading
the bootloader requires an AVR programmer and avrdude (Linux) or WinAVR
(Windows). The instructions to load the bootloader can be found in the UHD
manual here <http://files.ettus.com/manual/page_octoclock.html#bootloader>.
Regards,
Michael
On Tue, Jun 14, 2016 at 1:30 PM, Nicholas Corgan via USRP-users <
[email protected]> wrote:
> Apologies for the delayed response.
>
> When you power on your OctoClock-G, do all three LED's in the left column
> light up, or does only the Internal LED light up?
>
> On Wed, Jun 1, 2016 at 6:30 AM, Pol Henarejos via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>>
>> Recently we acquired an Octoclock-G. When I try to upgrade the firmware
>> to the newest image, I get the following error:
>>
>> phenarejos@pc :/usr/local/lib/uhd/utils$ sudo uhd_image_loader
>> --args="type=octoclock,addr=192.168.10.3"
>> linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.002-0-gf18abe54
>>
>> Unit: OctoClock (192.168.10.3)
>> Firmware: /usr/local/share/uhd/images/octoclock_r4_fw.hex
>> -- Resetting into bootloader...failed.
>> Error: RuntimeError: Failed to reset OctoClock.
>>
>> And no additional messges.
>>
>> Plus, when I try to change the default IP I get:
>>
>> phenarejos@pc :/usr/local/lib/uhd/utils$ ./octoclock_burn_eeprom
>> --args="addr=192.168.10.3"
>> --values="ip-addr=10.1.1.10,netmask=255.0.0.0,gateway=10.1.1.1"
>> linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.002-0-gf18abe54
>>
>> Creating OctoClock device from args: addr=192.168.10.3
>> -- Opening an OctoClock device...
>> -- Detecting internal GPSDO...No GPSDO found
>>
>> UHD Warning:
>> Device reports that it has a GPSDO, but we cannot communicate with it.
>>
>> -- Detecting external reference...false
>> -- Detecting switch position...Prefer external
>> -- Device is using internal reference
>>
>> Fetching current settings from EEPROM...
>> EEPROM ["ip-addr"] is "192.168.10.3"
>> EEPROM ["netmask"] is "255.255.255.0"
>> EEPROM ["gateway"] is "192.168.10.1"
>>
>> Setting EEPROM ["ip-addr"] to "10.1.1.10"...
>> Setting EEPROM ["netmask"] to "255.0.0.0"...
>> Setting EEPROM ["gateway"] to "10.1.1.1"...
>> Error: RuntimeError: Error writing to OctoClock EEPROM.
>>
>> Could someone help me to update and change IP of the octoclock?
>>
>> Thank you so much.
>>
>> --
>> Pol Henarejos
>> Research Engineer, MSc
>> [email protected]
>>
>> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
>> Engineering Unit
>> Parc Mediterrani de la Tecnologia
>> Av. Carl Friedrich Gauss, 7
>> 08860 Castelldefels
>> Tel: +34 93 396 71 70 Ext: 2177
>> Fax. +34 93 645 29 01
>> www.cttc.es
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> --
> Nicholas Corgan
>
> _______________________________________________
> 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/20160614/519e59cb/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 14 Jun 2016 16:39:40 -0500
From: Sergio Cruz Perez <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problem with gr-ettus OFDM sync block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin,
No, that problem was solved when I included the registers in the xml files.
Currently, when I run the command uhd_usrp_probe --tree with my fpga image I
can see the registers used in noc_block_schmidl_cox module
/mboards/0/xbar/SchmidlCox_0/registers/sr/FRAME_LENGTH/mboards/0/xbar/SchmidlCox_0/registers/sr/GAP_LENGTH/mboards/0/xbar/SchmidlCox_0/registers/sr/OFFSET/mboards/0/xbar/SchmidlCox_0/registers/sr/NUM_SYMBOLS_MAX/mboards/0/xbar/SchmidlCox_0/registers/sr/NUM_SYMBOLS_SHORT/mboards/0/xbar/SchmidlCox_0/registers/sr/THRESHOLD/mboards/0/xbar/SchmidlCox_0/registers/sr/AGC_REF_LEVEL
Now the problem is a segmentation fault:
Program terminated with signal SIGSEGV, Segmentation fault.#0 0xb64d3738 in
gr::io_signature::sizeof_stream_item (this=0x6363c0,_index=0) at
/home/sheko/E310_SW/gnuradio/gnuradio/gnuradio-runtime/lib/io_signature.cc:108108
return d_sizeof_stream_item[std::min(index, d_sizeof_stream_item.size() - 1)];
Any suggestion where can I look for the solution?
Thanks
Sergio Cruz
> To: [email protected]
> Date: Tue, 14 Jun 2016 13:37:20 -0700
> Subject: Re: [USRP-users] Problem with gr-ettus OFDM sync block
> From: [email protected]
>
> Sergio,
>
> can you please reiterate what the problems where that you saw?
>
> Is this still the error you're seeing:
>
> ```
> File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
> 3002, in set_argreturn _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
> RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
> ```
>
> -- M
>
> On 06/07/2016 10:23 AM, Sergio Cruz Perez wrote:
> > 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
> >
>
>
> _______________________________________________
> 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/20160614/39f24dae/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: schmidl_backtrace_2.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/39f24dae/attachment-0001.txt>
------------------------------
Message: 25
Date: Tue, 14 Jun 2016 23:49:28 +0200
From: Patrick Berger <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Define custom setting register on x310 and
access them from uhd.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi
Is it possible to add custom setting registers in the ddc and duc chain? I've
read that there are separate address ranges on the b210 but nothing about the
x310. If I define the adresses to avoid conflicts with the predefined register
in radio.v would that work? (Was a discussion in an earlier post)
On the other hand I've read that the peek/poke function could be used from uhd.
But this seems to me that I've to rebuild the uhd driver so shared libraries
wont be supported on different computers? Isn't there a function like this one
to access gain or center frequency, just with define the radio modul and the
adress for reading and adress + value for writing?
Best regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160614/9229815f/attachment-0001.html>
------------------------------
Message: 26
Date: Tue, 14 Jun 2016 16:32:48 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Problem with gr-ettus OFDM sync block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Sergio,
I can't reproduce this, unfortunately (or fortunately). However, we'll
be merging our OFDM code by next week, and that'll consolidate the OFDM
code and a bunch of other fixes. Hopefully, that'll just fix this issue.
If not, it'll be much easier to find out what's wrong.
Cheers,
M
On 06/14/2016 02:39 PM, Sergio Cruz Perez wrote:
> Hi Martin,
>
> No, that problem was solved when I included the registers in the xml
> files. Currently, when I run the command uhd_usrp_probe --tree with my
> fpga image I can see the registers used in noc_block_schmidl_cox module
>
> /mboards/0/xbar/SchmidlCox_0/registers/sr/FRAME_LENGTH
> /mboards/0/xbar/SchmidlCox_0/registers/sr/GAP_LENGTH
> /mboards/0/xbar/SchmidlCox_0/registers/sr/OFFSET
> /mboards/0/xbar/SchmidlCox_0/registers/sr/NUM_SYMBOLS_MAX
> /mboards/0/xbar/SchmidlCox_0/registers/sr/NUM_SYMBOLS_SHORT
> /mboards/0/xbar/SchmidlCox_0/registers/sr/THRESHOLD
> /mboards/0/xbar/SchmidlCox_0/registers/sr/AGC_REF_LEVEL
>
>
> Now the problem is a segmentation fault:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0xb64d3738 in gr::io_signature::sizeof_stream_item
> (this=0x6363c0,_index=0) at
> /home/sheko/E310_SW/gnuradio/gnuradio/gnuradio-runtime/lib/io_signature.cc:108
> 108 return d_sizeof_stream_item[std::min(index,
> d_sizeof_stream_item.size() - 1)];
>
> Any suggestion where can I look for the solution?
>
> Thanks
>
> Sergio Cruz
>
>
>
>> To: [email protected]
>> Date: Tue, 14 Jun 2016 13:37:20 -0700
>> Subject: Re: [USRP-users] Problem with gr-ettus OFDM sync block
>> From: [email protected]
>>
>> Sergio,
>>
>> can you please reiterate what the problems where that you saw?
>>
>> Is this still the error you're seeing:
>>
>> ```
>> File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>> 3002, in set_argreturn _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
>> RuntimeError: LookupError: Path not found in tree:
>> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
>> ```
>>
>> -- M
>>
>> On 06/07/2016 10:23 AM, Sergio Cruz Perez wrote:
>> > 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
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 27
Date: Wed, 15 Jun 2016 12:39:16 +1200
From: "John Shields" <[email protected]>
To: "usrp-users" <[email protected]>
Subject: [USRP-users] 'internal' spurs with GPSDO
Message-ID: <9E0D87FEC9734849B6F8A67176357169@JohnsHPLaptop>
Content-Type: text/plain; charset="utf-8"
Hi,
Have an N200 with SBX and GPSDO option. My system is Ubuntu 14.04
LTS and UHD is 003.010.git-216-gb1c2d4bb.
When I run:
uhd_fft -s 5e6 -f 1420.4057e6 -g 37.5 --fft-size 2048 --fft-average
high -a type=usrp2,addr=192.168.10.2,lo_offset=2.5e6,subdev=A:0
I receive the attached.
As you can see, there is a spur at 1420 MHz (and at every 10 MHz
step) and a spur in the middle.
After advice from Marcus (Leech), I have put 50-ohm SMA terminators
on ref in and pps in connectors on the front panel and also the TX/RX
connector directly on the SBX - I am using RX2 input which I terminate
with 50-ohm on the front panel for this test.
While there might be some who would say these signals are quite low
in level, they are enough to cause problems when running simple-ra as
evinced by the second attachment.
The active GPS antenna's unplugging does not improve the situation.
Even when I put a second N200 connected by MIMO cable to the first and
received on the second with an SBX card, I still see the same spikes. As
instructed in the GPSDO installation instructions I have put all the
cables under the daughtercard.
Any advice on what else I can do to mitigate?
Kind Regards,
John
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/51e2efa5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot of UHD_FFT screen.png
Type: image/png
Size: 103295 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/51e2efa5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: June_11_GP2_s_zenith.png
Type: image/png
Size: 11147 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/51e2efa5/attachment-0003.png>
------------------------------
Message: 28
Date: Wed, 15 Jun 2016 09:53:36 +0800
From: Ekko <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] csma in rfnoc
Message-ID:
<CAGgoB6Y6PTcT1vByuyH70AmO=tzoy5_vx1as+hu4gvbqgy1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hello all
whether the csma havs been achieved in the rfnoc, just like this
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control #0 (SID: 00:02>02:50)...OK
-- Port 80: Found NoC-Block with ID 1440000000000000.
-- base_path = "/usr/local/uhd/rfnoc"
-- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
-- Setting up NoC-Shell Control #0 (SID: 00:03>02:51)...
-- Setting up NoC-Shell Control #0 (SID: 00:04>02:52)...
-- Setting up NoC-Shell Control #0 (SID: 00:05>02:53)...
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/uhd/rfnoc"
-- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'CUSTOM'
-- block_ctrl_base()
-- base_path = "/usr/local/uhd/rfnoc"
-- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
-- Found valid blockdef
-- NOC ID: 0x1440000000000000 Block ID: 0/CUSTOM_0
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/2: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/3: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/out/1: type =
'sc16' pkt_size = '0' vlen = '0'
i saw this on the internet
but i did not find this in the rfnoc,os i want to know whether the csma has
benn achieved in rfnoc,and how to use it
thank you
--Ekko
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/8bf92846/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 14 Jun 2016 23:05:05 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Decaying RX energy & oscillations on
N210+RFX2450 Re: Frequency synchronization problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/20/2016 10:55 AM, Marc Bauduin via USRP-users wrote:
> Hi everyone,
>
> I made a simulation with the DC compensation algorithm for a carrier
> frequency of 2.43 GHz and an interpolation factor of 16. In this case,
> the peak at -1.43 MHz is reduced by -25 dB. Even with this algorithm,
> I am able to recover the steps with this carrier frequency. I don't
> understand why the DC algorithm affect a value which not in DC. Could
> it be due to the CORDIC algorithm if this one is after the DC
> compensation? It makes sense in this case because we would have a DC
> offset before the frequency translation. This one would become a
> progressive phase rotation at the output of the CORDIC algorithm. Is
> that right?
>
> I also removed the I/Q balance compensation algorithm and, in this
> case, it is the peak at -2.86 MHz which decreases by -25 dB. Maybe the
> I/Q compensation doesn't work very well? It is strange as I made a
> calibration with the UHD tools. Or maybe I misinterpret my results?
>
> Marc
Something you could try is the latest version of UHD--there were some
subtle problems in the I/Q compensation algorithms that have been
improved in later revisions of UHD.
>
> 2016-05-18 14:47 GMT+02:00 Marc Bauduin <[email protected]
> <mailto:[email protected]>>:
>
> Hi Marcus,
>
> I disabled the dc offset filter in this scenario with
> set_rx_dc_offset(false).
>
> I would not be surprise to see some oscillations at the beginning
> of each step because of the finite bandwidth of the front-end.
> But, in this case, they would decrease to finally disappear in the
> noise of the communication. But it is not the case.
>
> Just to be sure that my scenario is clear. I do a communication
> between two USRPs. The signal which is created by the Tx USRP is a
> step signal in baseband.
>
> For the synchronisation, I use a 10 MHz square wave. This one is
> generated with a clock-tamer 1.30.
>
> I sent you four figures. On the first one (stepSignal.png), you
> can see the step signal for different interpolation factor when
> the signal is transmitted around 2.43 GHz. The second one
> (stepSignal240.png) is also a step signal but with a carrier
> frequency of 2.4 GHz.
>
> The third figure (stepSpectre.png) is the spectrum of one step of
> my signal transmitted with an amplitude of 0.5. I used different
> interpolation/ decimation factors. As you can see the received
> spectrum is very different from the spectrum of constant signal.
> It can explain the degradation that I observe on "stepSignal.png"
> when I reduce the interpolation factor. It explain also the
> presence of these oscillations.
>
> Finally, the fourth figure (stepSpectreAmp16.png) is the spectrum
> of some steps with an interpolation factor of 16 and a carrier
> frequency of 2.43 GHz. We can see the spectrum of three different
> amplitudes. It is interesting to see that the component around
> -2.85 MHz decreases in the same proportion as the DC component
> (which is the amplitude of the step). The amplitude of the
> component around -1.43 MHz does not depend on the amplitude of the
> step (this is very strange). For the peak around 2.85 MHz, it
> seems that it comes from the non-linear behavior of some
> components. This one is not a surprise because, with an amplitude
> of 0.9, I am very close to the saturation point of the power
> amplifier of the transmitter.
>
> I also made an experiment where I removed the antenna from my Rx
> USRP and evaluate the received spectrum. Normally, it should only
> be a white noise. But I also observe a peak around -1.43 MHz. It
> seems that this component is always present in the receiver. I
> tried with another USRP and I have the same result. The position
> of the peak only changes with the carrier frequency. It can
> explain why I have a so different result between these two carrier
> frequencies.
>
> Do you know the origin of this peak?
>
> I hope that these results are easy to read.
>
> Thanks in advance for your answers.
>
> Marc
>
> 2016-05-13 13:06 GMT+02:00 Marcus M?ller
> <[email protected] <mailto:[email protected]>>:
>
> Hi Marc,
>
> On 13.05.2016 10:55, Marc Bauduin via USRP-users wrote:
>> Thanks for the information.
>>
>> I reduced decimation and interpolation factor to 4. In this
>> case, the CIC filter is bypassed and the decimation is only
>> done with the help of two half-band filters. Is that right?
> yes!
>>
>> In that case, I don't observe the decay anymore but each step
>> are affected by an important oscillation. I checked the
>> spectrum of each step and I can see some important peak for
>> some specific frequencies. I still need to find their origin.
> can you give us plots or samples? What kind of oscillation, is
> it decaying, constant in frequency?
>
> Like Marcus L., my first suspicion here is the rx_dc_offset
> filter; did you disable that in this case?
> Oscillations at a step wouldn't surprise me; after all, all
> linear systems have what is called a step response, and so do
> our halfband filters, and the analog baseband filters on the
> daughterboard.
>>
>> I also changed the carrier frequency. Previously, I worked
>> around 2.4 GHz. Now I tried 2.43 GHz. In this case, I still
>> observe important oscillations with an interpolation factor
>> of 4. If I reduce the sampling frequency, I am now able to
>> recover the step signal.
> How do you synchronize your signal generator to the USRP?
> What's the generators' bandwidth.
> Point is that you physically can't produce a proper step
> function without any oscillations ? that would simply have
> infinite bandwidth.
>
> My suspicion is that there might be analog non-perfections
> going on.
> Again, can you give us a plot of what you're seeing?
> How does your signal generator connect to the USRP?
> What happens if you reduce the power of the signal and the
> gain of the daughterboard?
>
> Best regards,
> Marcus
>
>>
>> Any idea of why the results are so different when I change
>> the carrier frequency?
>>
>> 2016-05-10 16:17 GMT+02:00 <[email protected]
>> <mailto:[email protected]>>:
>>
>> It's a CIC decimator with FIR-based clean-up filters, as
>> far as I know.
>>
>> On 2016-05-10 05:10, Marc Bauduin via USRP-users wrote:
>>
>>> I increased the duration of each step to 1e4 samples. I
>>> made this simulation for several interpolation factors.
>>> Each time, I can approximate the decay with an
>>> exponential decay exp(-t/d) where d = 1.7e-4 seconds.
>>> This value is a little bit lower (1.2e-4 seconds) for an
>>> interpolation factor of 8.
>>> I am not surprised to see a peak at the beginning of
>>> each step. The problem is that the decay always go back
>>> the same value. I expected that, after some oscillation
>>> due to the decimation filter, I could observe the
>>> different steps.
>>> What kind of filter is used for the decimation?
>>>
>>> 2016-05-06 16:51 GMT+02:00 <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> What is the period of the decay? This may just be
>>> the decimation filters reacting to a step change in
>>> the input, and it's just more obvious when the
>>> devices are strictly synchronous. That's just a guess.
>>>
>>> On 2016-05-06 05:09, Marc Bauduin via USRP-users wrote:
>>>
>>> Maybe I answered too quickly.
>>> I made a new test where I send a step signal
>>> (0.1, 0.2, ..., 1). Each value is maintained
>>> during 1e3 samples. If I look at the amplitude
>>> of the received signal in baseband, I am able to
>>> recover this step signal if the USRPs are not
>>> synchronized. But if I synchronize them with the
>>> 10MHz clock, I can see quick changes in
>>> amplitude followed by a decay. As if the radio
>>> still tried to compensate a DC offset.
>>> I used the function set_rx_dc_offset(false) or
>>> set_rx_dc_offset(false)(std::complex<double>(a,b)).
>>> The only difference is the value reached after
>>> the decay.
>>>
>>> 2016-04-27 22:24 GMT+02:00 Marc Bauduin
>>> <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> Thank you for your answer. It was
>>> effectively that.I used the
>>> function set_rx_dc_offset(false) to remove
>>> the algorithm and I don't observe this
>>> effect anymore when I send a signal constant
>>> in baseband.
>>>
>>> 2016-04-27 15:39 GMT+02:00 Marcus D. Leech
>>> via USRP-users <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> On 04/27/2016 08:40 AM, Herlook Search
>>> via USRP-users wrote:
>>>
>>> Hi everyone,
>>>
>>> I use two USRP N210 with the
>>> RFX2450. I manipulate them in C++.
>>>
>>> I would like to characterize the
>>> USRPs. In that way, I send very
>>> simple signals, as a constant signal
>>> in baseband. When I send this
>>> signal, I observe a circle in
>>> baseband due to the CFO. This is
>>> what I expected.
>>>
>>> If I send the same signal when the
>>> USRPs are synchronized with the same
>>> 10 MHz clock (I use an external
>>> square wave generator), I see that
>>> the amplitude of this sequence
>>> quickly decreases through time. If I
>>> use an alternate sequence of
>>> {-1;+1}, I also observe that its
>>> amplitude decreases.
>>>
>>> But it seems that the
>>> synchronisation works because, when
>>> I do an OFDM communication or a
>>> single carrier communication with
>>> the 10 MHz clock, I can recover my
>>> QAM constellation without CFO.
>>>
>>> Can you confirm that these results
>>> are expected from such a
>>> configuration? If it is the case,
>>> can we avoid them?
>>>
>>> Thanks in advance.
>>>
>>> Marc
>>>
>>> Make sure that your baseband tone is far
>>> enough away from DC so as not to get
>>> swallowed by the DC-offset compensation
>>> algorithm, which takes a while to converge.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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]
>>> <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] <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/20160614/1c84a30b/attachment-0001.html>
------------------------------
Message: 30
Date: Wed, 15 Jun 2016 03:20:22 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Error: RuntimeError: x300_dac_ctrl: timeout
waiting for DAC PLL to lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Yes, this was resolved with the correct FPGA image.
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: Jonathon Pendlum <[email protected]>
Sent: Tuesday, June 14, 2016 2:54 PM
To: Swanson, Craig
Cc: Marcus M?ller; Martin Braun; [email protected]
Subject: Re: Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to
lock
Hi Craig,
Was this resolved by using the correct FPGA image?
Jonathon
On Sat, Jun 11, 2016 at 11:16 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I am getting this error when I run uhd_usrp_probe --init-only on an X310 using
noc_block_skeleton in rfnoc-radio-redo:
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached from
b62d96c))$ uhd_usrp_probe --init-only
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.rfnoc-316-gb7546712
-- 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...
-- Radio 0 Ctrl SID: 00:00>02:30
-- Performing register loopback test... fail
Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock
?
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/20160615/5d78b8c7/attachment-0001.html>
------------------------------
Message: 31
Date: Wed, 15 Jun 2016 03:23:33 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] uhd_usrp_probe in rfnoc-radio-redo for
custom noc_block_Receiver in uhd_usrp_probe is showing up as Block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
I reinstalled everything in the following order:
1. ?uhd under the rfnoc-radio-redo branch
2. gnuradio
3. gr-ettus
When I installed gr-ettus I got the following error when I ran "make -j4"
[ 44%] Building CXX object
swig/CMakeFiles/ettus_swig_swig_2d0df.dir/ettus_swig_swig_2d0df.cpp.o
Linking CXX executable ettus_swig_swig_2d0df
Swig source
/home/craig/gr-ettus/lib/device3.cc: In member function ?virtual void
device3_impl::connect(const string&, size_t, std::string, size_t)?:
/home/craig/gr-ettus/lib/device3.cc:61:11: error: ?class uhd::usrp::multi_usrp?
has no member named ?connect?
_dev->connect(
^
/home/craig/gr-ettus/lib/device3.cc: In member function ?virtual void
device3_impl::connect(const string&, std::string)?:
/home/craig/gr-ettus/lib/device3.cc:73:11: error: ?class uhd::usrp::multi_usrp?
has no member named ?connect?
_dev->connect(
^
/usr/local/include/uhd/types/sensors.hpp:141: Warning 362: operator= ignored
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/craig/gr-ettus/lib/rfnoc_block_impl.cc: In constructor
?gr::ettus::rfnoc_block_impl::rfnoc_block_impl(const sptr&, const string&,
const uhd::stream_args_t&, const uhd::stream_args_t&)?:
/home/craig/gr-ettus/lib/rfnoc_block_impl.cc:146:49: error: ?class
uhd::device3? has no member named ?find_block_ctrl?
_blk_ctrl(dev->get_device()->get_device3()->find_block_ctrl(block_id)),
^
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_block_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 44%] Built target ettus_swig_swig_2d0df
make: *** [all] Error 2
craig@craig-VirtualBox:~/gr-ettus/build (master)$
?
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: Jonathon Pendlum <[email protected]>
Sent: Tuesday, June 14, 2016 2:47 PM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller; [email protected]
Subject: Re: uhd_usrp_probe in rfnoc-radio-redo for custom noc_block_Receiver
in uhd_usrp_probe is showing up as Block
Hi Craig,
block.xml is the default XML that is loaded when a block's XML is not found --
basically a NOC ID is not matched with a corresponding XML file. Double check
your XML file is installed in the right place (looks like
/usr/local/share/uhd/rfnoc from the log), that the NOC IDs match, and that you
don't have any syntax errors in the XML file.
Jonathon
On Tue, Jun 14, 2016 at 11:19 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
?Jonathon,
I made it past my problem of using rfnoc-radio-redo with my X310.
Using my own python code running in cocotb, I was able to simulate the
noc_block_skeleton.v file and in the process learned a lot more about flow
control and the changes you made from the rfnoc-devel branch.
My testbench imports my file sink data generated by gnuradio and runs the data
through your noc_block_skeleton.v file. Then I renamed the
noc_block_skeleton.v as noc_block_Receiver.v and generated a bit file. I also
generated the necessary XML files with a unique NOC ID so uhd_usrp_probe would
recognize it.
What is strange is that uhd_usrp_probe recognized my .bit file but didn't match
it up with my
Receiver.xml file located in /usr/local/share/uhd/rfnoc/blocks/Receiver.xml.
My NOC ID for Receiver is 614A. (Today's date)
Instead it matched it with the block.xml. It also named it block instead of
Receiver.
I also tried imitating the noc_block_moving_avg instead of noc_block_skeleton
and I got the same result.
How can this be? I have done this plenty of times with the rfnoc-devel branch
coupled with my E310.
Also I thought the rfnoc-radio-redo branch eliminated one of the radios?
Shown below is a portion of what I got when I ran uhd_usrp_probe --init-only
Craig
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:6e>02:70)...Setting up NoC-Shell Control for port #0 (SID:
00:6e>02:70)...OK
-- Port 112: Found NoC-Block with ID 614A000000000000.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Using default block configuration.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- [RFNoC Factory] Using controller key 'Block' and block name 'Block'
-- block_ctrl_base()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x614A000000000000 Block ID: 0/Block_0
-- [0/Block_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/Block_0] block_ctrl_base::_clear()
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/MovingAverage_0
-- * 0/Block_0
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached from
b62d96c))$ cd ..
?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/20160615/4fd5b18a/attachment-0001.html>
------------------------------
Message: 32
Date: Wed, 15 Jun 2016 00:23:04 -0400
From: Dave NotTelling <[email protected]>
To: Michael West <[email protected]>
Cc: Neel Pandeya <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Resetting N210 & X310 Remotely
Message-ID:
<CAK6GVuNkGX72gmGdTM9NmsV=daag_hon52w4y_jkgk1s83_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Michael & Neel,
Thank you for the explanation and suggestions! The USB reload is
pretty fast, but doing so over the network or PCIe is horribly slow. Power
cycling via a managed power strip might be the only viable solution =\
Thanks!
-Dave
On Tue, Jun 14, 2016 at 4:21 PM, Michael West <[email protected]>
wrote:
> There is no software reset built in. You can accomplish it by either 1)
> adding remote power management as Neel indicated or 2) by loading the FPGA
> image via JTAG. Remote power cycling will be instant. Loading the FPGA
> image over JTAG takes ~20 second and means connecting a JTAG programmer to
> the J203 header on the N210 and a USB cable to the JTAG port on the front
> panel of the X310.
>
> Regards,
> Michael
>
> On Tue, Jun 14, 2016 at 12:32 PM, Neel Pandeya via USRP-users <
> [email protected]> wrote:
>
>> Hello Dave:
>>
>> By reset, do you mean to power cycle, or to reset to some known initial
>> state? There is no API call in UHD to reset or power cycle the radio. You
>> might be able to achieve the same goal by using a managed power strip [1,2].
>>
>> [1] http://www.digital-loggers.com/lpc.html
>> [2] https://www.amazon.com/gp/product/B00EZWD146/
>>
>> --Neel Pandeya
>>
>>
>>
>> On 18 May 2016 at 13:20, Dave NotTelling via USRP-users <
>> [email protected]> wrote:
>>
>>> Is it possible to reset the N210 and X310 radios remotely? Hopefully
>>> some API command that can trigger something like an FPGA reset / bit file
>>> reload?
>>>
>>> Thanks!
>>>
>>> _______________________________________________
>>> 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/20160615/ef844789/attachment-0001.html>
------------------------------
Message: 33
Date: Wed, 15 Jun 2016 04:48:41 +0000 (UTC)
From: md mahbubur <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] USRP2 not communicating
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Neel,the fpga and fw files you sent me were worse. Not booting at all. My
previous ones?uhd-images_003.010.twinrx-devel-234-g6189cea6??were at least
bootable and can power the device up with lit up Led. Once I burnt your files
the device seems not powered up at all, as no led are lit up. I believe
the?main problem is from lack of ?right fw and fpga files. Please send me the
right files that I can try again. Another thing is my mac osx?is not responding
to?sdcard_burner_gui.py? anymore! I don't know why but I burnt your files
through terminal command and made them FAT32 bootable sdcard. I erased your
files from the loaded sdcard and reloaded my previous files. Seems the device
is booted well as F Led is lit up again. But the ethernet?is not responding to
my terminal command ?<ping 192.168.10.2> and shows continuous timed out...?
Hi,Currently, I am working with USRP2 device for my research. I have been
trying to activate this previously used device for last three days but failed
to make it talk to my computer(Mac?OSx?El Capitan) via ping command (usb2
ethernet adapter is used for connection between computer and device; also
direct ethernet cable connection was tested with another?pc?but seems the
device is dead, no response!). Then I assumed the there might be a firmware
issue. I erased the sd card and tried to copy usrp2_fw.bin and usrp2_fpga.bin
files via sdcard_burner_gui.py program but the program was giving an error
saying "the dd/disk3: resource is busy!". However, Then I tried to copy those
files by drag and dropping them, which copied well but couldn't help to
communicate the?device. The device loads the firmware first and stays with only
F LED indicator lit up. In this instance, I need suggestion what should I do to
make it run! P.S. bin files are collected
from?uhd-images_003.010.twinrx-devel-234-g6
189cea6 folder from ettus?support website. Thanks
Regards,Mahbubur RahmanUniverity of New South Wales, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/b15c7337/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blob.jpg
Type: image/png
Size: 519417 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/b15c7337/attachment-0001.jpg>
------------------------------
Message: 34
Date: Wed, 15 Jun 2016 08:05:52 +0200
From: Pol Henarejos <[email protected]>
To: Michael West <[email protected]>, Nicholas Corgan
<[email protected]>
Cc: "usrp-users lists.ettus.com" <[email protected]>
Subject: Re: [USRP-users] Octoclock updating firmware & change ip
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear Nikolas and Michael,
I guess I do have the bootloader. Indeed, I can ping to 192.168.10.3 and
two LED's in the left column (Internal and Status LED's) are turn on. Is
it right?
Thank you.
Pol Henarejos
Researcher, MSc
[email protected]
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 14/6/2016 a les 22:43, Michael West ha escrit:
> Hi Pol,
>
> What Nicholas is asking is if your Octoclock has the bootloader. Since
> the image loader reported "-- Resetting into bootloader...failed.", it
> seems like your Octoclock is missing the bootloader. Upgrading the
> firmware with uhd_image_loader will not work if the bootloader is not
> present. Loading the bootloader requires an AVR programmer and avrdude
> (Linux) or WinAVR (Windows). The instructions to load the bootloader
> can be found in the UHD manual here
> <http://files.ettus.com/manual/page_octoclock.html#bootloader>.
>
> Regards,
> Michael
>
> On Tue, Jun 14, 2016 at 1:30 PM, Nicholas Corgan via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Apologies for the delayed response.
>
> When you power on your OctoClock-G, do all three LED's in the left
> column light up, or does only the Internal LED light up?
>
> On Wed, Jun 1, 2016 at 6:30 AM, Pol Henarejos via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Dear all,
>
> Recently we acquired an Octoclock-G. When I try to upgrade the
> firmware to the newest image, I get the following error:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$ sudo uhd_image_loader
> --args="type=octoclock,addr=192.168.10.3"
> linux; GNU C++ version 4.9.2; Boost_105500;
> UHD_003.009.002-0-gf18abe54
>
> Unit: OctoClock (192.168.10.3)
> Firmware: /usr/local/share/uhd/images/octoclock_r4_fw.hex
> -- Resetting into bootloader...failed.
> Error: RuntimeError: Failed to reset OctoClock.
>
> And no additional messges.
>
> Plus, when I try to change the default IP I get:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$ ./octoclock_burn_eeprom
> --args="addr=192.168.10.3"
> --values="ip-addr=10.1.1.10,netmask=255.0.0.0,gateway=10.1.1.1"
> linux; GNU C++ version 4.9.2; Boost_105500;
> UHD_003.009.002-0-gf18abe54
>
> Creating OctoClock device from args: addr=192.168.10.3
> -- Opening an OctoClock device...
> -- Detecting internal GPSDO...No GPSDO found
>
> UHD Warning:
> Device reports that it has a GPSDO, but we cannot communicate
> with it.
>
> -- Detecting external reference...false
> -- Detecting switch position...Prefer external
> -- Device is using internal reference
>
> Fetching current settings from EEPROM...
> EEPROM ["ip-addr"] is "192.168.10.3"
> EEPROM ["netmask"] is "255.255.255.0"
> EEPROM ["gateway"] is "192.168.10.1"
>
> Setting EEPROM ["ip-addr"] to "10.1.1.10"...
> Setting EEPROM ["netmask"] to "255.0.0.0"...
> Setting EEPROM ["gateway"] to "10.1.1.1"...
> Error: RuntimeError: Error writing to OctoClock EEPROM.
>
> Could someone help me to update and change IP of the octoclock?
>
> Thank you so much.
>
> --
> Pol Henarejos
> Research Engineer, MSc
> [email protected] <mailto:[email protected]>
>
> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
> Engineering Unit
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels
> Tel: +34 93 396 71 70 Ext: 2177
> <tel:%2B34%2093%20396%2071%2070%20Ext%3A%202177>
> Fax. +34 93 645 29 01 <tel:%2B34%2093%20645%2029%2001>
> www.cttc.es <http://www.cttc.es>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Nicholas Corgan
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/fb0c4af5/attachment-0001.p7s>
------------------------------
Message: 35
Date: Wed, 15 Jun 2016 16:40:36 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC with E310
Message-ID:
<caf6nntj3ehuufkeckhiafmgfvr7jdq7u2ssszx8l8qvi5eg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We want to update e310 images with RFNoC. should we update uhd on e310? or
we can just update e310 image and with command dd update sd images.if
so,where can we download the rfnoc image?
thank you
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/cd60f79a/attachment-0001.html>
------------------------------
Message: 36
Date: Wed, 15 Jun 2016 13:52:20 +0000
From: ???? <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 rates and frequencies
Message-ID:
<bdac4f2dd20ba24991ebdc81b4052584c0e76...@imail-exch02.govmail.tehila.gov.il>
Content-Type: text/plain; charset="windows-1255"
Hi,
A few questions regarding the E310:
* What are the possible TX sample rates, that is, what are the quantized
values?
* Can I set different sample rates for each channel?
* I noticed that in the UHD API (multi_usrp.hpp), the set_tx_freq function
has a channel parameter. However, I also read that both TX channels use the
same LO. Therefore, is it possible to set a different frequency to each
channel? What are the limitations?
Thanks a lot,
Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/d3bea0a5/attachment-0001.html>
------------------------------
Message: 37
Date: Wed, 15 Jun 2016 15:56:01 +0200
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] 2 heterogeneous TX channels on X310
Message-ID:
<59957d668d245c4eb38e8f85c054e9010d3570e...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am using an X310 equipped with a SBX board on site A and Basic RX/TX on site
B.
I want to use the TX parts of SBX (homodyne) and Basic TX (heterodyne, FI
75MHz) at the same time, under gnuradio .
I can separately make each channel working in an URSP SINK block with
- numMboards=1; subdev=A:0; numchannels= 1; antenna=TX/RX;
or
- numMboards=1; subdev=B:A; numchannels= 1; antenna=TX-A;
but
- numMboards=2; subdev1=A:0; subdev2=B:A numchannels= 2; antenna1=TX/RX;
antenna2=TX-A;
gives the error:
error in set_subdev_spec....
....multiusrp::mb_root(1)-vector::M_range_check.
1) Is it possible to make this configuration working?
2) It seems that my subdev spec. is not appropriate. But how to specify this?
Thank you for answers.
Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/8bc19c5b/attachment-0001.html>
------------------------------
Message: 38
Date: Wed, 15 Jun 2016 10:10:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP2 not communicating
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/15/2016 12:48 AM, md mahbubur via USRP-users wrote:
> Hi Neel,
> the fpga and fw files you sent me were worse. Not booting at all. My
> previous ones uhd-images_003.010.twinrx-devel-234-g6189cea6 were at
> least bootable and can power the device up with lit up Led. Once I
> burnt your files the device seems not powered up at all, as no led are
> lit up. I believe the main problem is from lack of right fw and fpga
> files. Please send me the right files that I can try again. Another
> thing is my mac osx is not responding to sdcard_burner_gui.py
> anymore! I don't know why but I burnt your files through terminal
> command and made them FAT32 bootable sdcard. I erased your files from
> the loaded sdcard and reloaded my previous files. Seems the device is
> booted well as F Led is lit up again. But the ethernet is not
> responding to my terminal command <ping 192.168.10.2> and shows
> continuous timed out...
>
It's possible that your device has had a different IP address set, in
which case, if you put it in "safe mode", as below:
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash_brick
The IP address will be (temporarily) at the factory-default, which will
allow you to change the IP address.
> Hi,
> Currently, I am working with USRP2 device for my research. I have been
> trying to activate this previously used device for last three days but
> failed to make it talk to my computer(Mac OSx El Capitan) via ping
> command (usb2 ethernet adapter is used for connection between computer
> and device; also direct ethernet cable connection was tested with
> another pc but seems the device is dead, no response!). Then I assumed
> the there might be a firmware issue. I erased the sd card and tried to
> copy usrp2_fw.bin and usrp2_fpga.bin files via sdcard_burner_gui.py
> program but the program was giving an error saying "the dd/disk3:
> resource is busy!". However, Then I tried to copy those files by drag
> and dropping them, which copied well but couldn't help to communicate
> the device. The device loads the firmware first and stays with only F
> LED indicator lit up. In this instance, I need suggestion what should
> I do to make it run! P.S. bin files are collected
> from uhd-images_003.010.twinrx-devel-234-g6189cea6 folder from
> ettus support website. Thanks
> Inline image
>
> Regards,
> Mahbubur Rahman
> Univerity of New South Wales, Australia
>
>
>
> _______________________________________________
> 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/20160615/bfd830e5/attachment-0001.html>
------------------------------
Message: 39
Date: Wed, 15 Jun 2016 10:20:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 rates and frequencies
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/15/2016 09:52 AM, ???? via USRP-users wrote:
> Hi,
>
> A few questions regarding the E310:
>
> * What are the possible TX sample rates, that is, what are the
> quantized values?
>
Since you can set the master-clock rate anywhere between 10Mhz and
56MHz, and then use factor-of-2 decimation in the FPGA,
sample rates as delivered to the application are pretty flexible.
> * Can I set different sample rates for each channel?
>
I don't believe that is supported, since the AD9361 delivers samples at
the same rate on both channels.
> * I noticed that in the UHD API (multi_usrp.hpp), the set_tx_freq
> function has a channel parameter. However, I also read that both
> TX channels use the same LO. Therefore, is it possible to set a
> different frequency to each channel? What are the limitations?
>
You can have different frequencies on the two channels, subject to the
"reach" of the DDC chains in the FPGA--such "reach" would be limited
to about 30Mhz in the two-channel case, because the master clock
can't be any higher than that for two-channel use.
> Thanks a lot,
> 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/20160615/b2b131d5/attachment-0001.html>
------------------------------
Message: 40
Date: Wed, 15 Jun 2016 09:23:13 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] uhd_usrp_probe in rfnoc-radio-redo for
custom noc_block_Receiver in uhd_usrp_probe is showing up as Block
Message-ID:
<cagdo0usxx86hctho026cojpnbru3krhpl_pnewiv1ig5nee...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig,
Did you checkout the radio-redo branch on gr-ettus?
Jonathon
On Tue, Jun 14, 2016 at 10:23 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I reinstalled everything in the following order:
>
>
>
> 1. ?uhd under the rfnoc-radio-redo branch
> 2. gnuradio
> 3. gr-ettus
>
> When I installed gr-ettus I got the following error when I ran "make -j4"
>
> [ 44%] Building CXX object
> swig/CMakeFiles/ettus_swig_swig_2d0df.dir/ettus_swig_swig_2d0df.cpp.o
> Linking CXX executable ettus_swig_swig_2d0df
> Swig source
> /home/craig/gr-ettus/lib/device3.cc: In member function ?virtual void
> device3_impl::connect(const string&, size_t, std::string, size_t)?:
> /home/craig/gr-ettus/lib/device3.cc:61:11: error: ?class
> uhd::usrp::multi_usrp? has no member named ?connect?
> _dev->connect(
> ^
> /home/craig/gr-ettus/lib/device3.cc: In member function ?virtual void
> device3_impl::connect(const string&, std::string)?:
> /home/craig/gr-ettus/lib/device3.cc:73:11: error: ?class
> uhd::usrp::multi_usrp? has no member named ?connect?
> _dev->connect(
> ^
> /usr/local/include/uhd/types/sensors.hpp:141: Warning 362: operator=
> ignored
> make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /home/craig/gr-ettus/lib/rfnoc_block_impl.cc: In constructor
> ?gr::ettus::rfnoc_block_impl::rfnoc_block_impl(const sptr&, const string&,
> const uhd::stream_args_t&, const uhd::stream_args_t&)?:
> /home/craig/gr-ettus/lib/rfnoc_block_impl.cc:146:49: error: ?class
> uhd::device3? has no member named ?find_block_ctrl?
>
> _blk_ctrl(dev->get_device()->get_device3()->find_block_ctrl(block_id)),
> ^
> make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_block_impl.cc.o]
> Error 1
> make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs....
> [ 44%] Built target ettus_swig_swig_2d0df
> make: *** [all] Error 2
> craig@craig-VirtualBox:~/gr-ettus/build (master)$
>
> ?
>
>
>
> *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:* Jonathon Pendlum <[email protected]>
> *Sent:* Tuesday, June 14, 2016 2:47 PM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; Marcus M?ller; [email protected]
> *Subject:* Re: uhd_usrp_probe in rfnoc-radio-redo for custom
> noc_block_Receiver in uhd_usrp_probe is showing up as Block
>
> Hi Craig,
>
> block.xml is the default XML that is loaded when a block's XML is not
> found -- basically a NOC ID is not matched with a corresponding XML file.
> Double check your XML file is installed in the right place (looks
> like /usr/local/share/uhd/rfnoc from the log), that the NOC IDs match, and
> that you don't have any syntax errors in the XML file.
>
>
>
> Jonathon
>
> On Tue, Jun 14, 2016 at 11:19 AM, Swanson, Craig <
> [email protected]> wrote:
>
>> ?Jonathon,
>>
>> I made it past my problem of using rfnoc-radio-redo with my X310.
>>
>> Using my own python code running in cocotb, I was able to simulate the
>> noc_block_skeleton.v file and in the process learned a lot more about flow
>> control and the changes you made from the rfnoc-devel branch.
>>
>> My testbench imports my file sink data generated by gnuradio and runs the
>> data through your noc_block_skeleton.v file. Then I renamed the
>> noc_block_skeleton.v as noc_block_Receiver.v and generated a bit file. I
>> also generated the necessary XML files with a unique NOC ID so
>> uhd_usrp_probe would recognize it.
>>
>>
>> What is strange is that uhd_usrp_probe recognized my .bit file but didn't
>> match it up with my
>>
>> Receiver.xml file located in
>> /usr/local/share/uhd/rfnoc/blocks/Receiver.xml. My NOC ID for Receiver is
>> 614A. (Today's date)
>>
>> Instead it matched it with the block.xml. It also named it block instead
>> of Receiver.
>>
>>
>> I also tried imitating the noc_block_moving_avg instead of
>> noc_block_skeleton and I got the same result.
>>
>>
>> How can this be? I have done this plenty of times with the rfnoc-devel
>> branch coupled with my E310.
>>
>> Also I thought the rfnoc-radio-redo branch eliminated one of the radios?
>>
>> Shown below is a portion of what I got when I ran uhd_usrp_probe
>> --init-only
>>
>>
>> Craig
>>
>>
>> -- [RFNOC] ------- Block Setup -----------
>> -- SEND (SID: 00:6e>02:70)...Setting up NoC-Shell Control for port #0
>> (SID: 00:6e>02:70)...OK
>> -- Port 112: Found NoC-Block with ID 614A000000000000.
>> -- base_path = "/usr/local/share/uhd/rfnoc"
>> -- Using default block configuration.
>> -- base_path = "/usr/local/share/uhd/rfnoc"
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
>> -- [RFNoC Factory] block_ctrl_base::make()
>> -- base_path = "/usr/local/share/uhd/rfnoc"
>> -- [RFNoC Factory] Using controller key 'Block' and block name 'Block'
>> -- block_ctrl_base()
>> -- base_path = "/usr/local/share/uhd/rfnoc"
>> -- base_path = "/usr/local/share/uhd/rfnoc"
>> -- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
>> -- NOC ID: 0x614A000000000000 Block ID: 0/Block_0
>> -- [0/Block_0] block_ctrl_base::clear()
>> -- node_ctrl_base::clear()
>> -- [0/Block_0] block_ctrl_base::_clear()
>> -- [0/Block_0] Adding port definition at xbar/Block_0/ports/in/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- [0/Block_0] Adding port definition at xbar/Block_0/ports/out/0: type =
>> '' pkt_size = '0' vlen = '0'
>> -- ========== Full list of RFNoC blocks: ============
>> -- * 0/Radio_0
>> -- * 0/Radio_1
>> -- * 0/FIFO_0
>> -- * 0/MovingAverage_0
>> -- * 0/Block_0
>> craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached
>> from b62d96c))$ cd ..
>>
>> ?*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>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/dac1ebe0/attachment-0001.html>
------------------------------
Message: 41
Date: Wed, 15 Jun 2016 16:32:21 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: [USRP-users] GPSDO as stand-alone component
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear All,
The B200mini does not support any board-mount GPSDO.
I am wondering: would it be possible to operate one of the different
Ettus GPSDO devices as a stand-alone GPS-disciplined 10 MHz reference
clock generator by providing only the external power (+ GPS antenna of
course)?
Disclaimer: I known a better and more straightforward alternative in the
Ettus catalogue would be the OctoClock-G, but the latter does not fit my
SWaP constraints.
Best regards,
Claudio
--
Claudio Cicconetti, PhD
Software Engineer - MBI S.r.l. - Pisa, Italy
------------------------------
Message: 42
Date: Wed, 15 Jun 2016 14:32:33 +0000
From: ???? <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] ??RE: E310 rates and frequencies
Message-ID:
<bdac4f2dd20ba24991ebdc81b4052584c0e77...@imail-exch02.govmail.tehila.gov.il>
Content-Type: text/plain; charset="windows-1255"
Thank you Marcus,
Regarding, the samples rate, so what is the meaning of the "channel" parameter
in the "set_tx_rate" function (multi_usrp.hpp)?
Best regards,
Roy
________________________________
?: ??USRP-users ?[[email protected]]? ??? Marcus D. Leech via
USRP-users ?[[email protected]]?
??????: ??? ????? 15 ???? 2016 17:20
????: [email protected]
??????: Re: [USRP-users] E310 rates and frequencies
On 06/15/2016 09:52 AM, ???? via USRP-users wrote:
Hi,
A few questions regarding the E310:
* What are the possible TX sample rates, that is, what are the quantized
values?
Since you can set the master-clock rate anywhere between 10Mhz and 56MHz, and
then use factor-of-2 decimation in the FPGA,
sample rates as delivered to the application are pretty flexible.
* Can I set different sample rates for each channel?
I don't believe that is supported, since the AD9361 delivers samples at the
same rate on both channels.
* I noticed that in the UHD API (multi_usrp.hpp), the set_tx_freq function
has a channel parameter. However, I also read that both TX channels use the
same LO. Therefore, is it possible to set a different frequency to each
channel? What are the limitations?
You can have different frequencies on the two channels, subject to the "reach"
of the DDC chains in the FPGA--such "reach" would be limited
to about 30Mhz in the two-channel case, because the master clock can't be any
higher than that for two-channel use.
Thanks a lot,
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/20160615/cc778552/attachment-0001.html>
------------------------------
Message: 43
Date: Wed, 15 Jun 2016 09:34:11 -0500
From: Jonathon Pendlum <[email protected]>
To: Ekko <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] csma in rfnoc
Message-ID:
<CAGdo0uSiho1ijEu2f6BKgZZhbhqH=thjfp1akoifomrkmkm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ekko,
We (Ettus) currently have not released a CSMA block for RFNoC. That log
looks like it came from a custom block written by someone in the community.
Jonathon
On Tue, Jun 14, 2016 at 8:53 PM, Ekko via USRP-users <
[email protected]> wrote:
> hello all
> whether the csma havs been achieved in the rfnoc, just like this
>
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control #0 (SID: 00:02>02:50)...OK
> -- Port 80: Found NoC-Block with ID 1440000000000000.
> -- base_path = "/usr/local/uhd/rfnoc"
> -- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
> -- Setting up NoC-Shell Control #0 (SID: 00:03>02:51)...
> -- Setting up NoC-Shell Control #0 (SID: 00:04>02:52)...
> -- Setting up NoC-Shell Control #0 (SID: 00:05>02:53)...
> -- [RFNoC Factory] block_ctrl_base::make()
> -- base_path = "/usr/local/uhd/rfnoc"
> -- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
> -- [RFNoC Factory] Using controller key 'Block' and block name 'CUSTOM'
> -- block_ctrl_base()
> -- base_path = "/usr/local/uhd/rfnoc"
> -- Reading XML file: /usr/local/uhd/rfnoc/blocks/csma.xml
> -- Found valid blockdef
> -- NOC ID: 0x1440000000000000 Block ID: 0/CUSTOM_0
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/0: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/1: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/2: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/in/3: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/out/0: type
> = 'sc16' pkt_size = '0' vlen = '0'
> -- [0/CUSTOM_0] Adding port definition at xbar/CUSTOM_0/ports/out/1: type
> = 'sc16' pkt_size = '0' vlen = '0'
>
> i saw this on the internet
>
> but i did not find this in the rfnoc,os i want to know whether the csma
> has benn achieved in rfnoc,and how to use it
>
> thank you
>
> --Ekko
>
> _______________________________________________
> 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/20160615/dce67283/attachment-0001.html>
------------------------------
Message: 44
Date: Wed, 15 Jun 2016 14:35:44 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus Brown
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] uhd_usrp_probe in rfnoc-radio-redo for
custom noc_block_Receiver in uhd_usrp_probe is showing up as Block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Oops. I tried switching to an rfnoc-radio-redo branch but it didn't let me.
Thanks for the heads up on the correct name.
Craig
Sent from my iPhone
On Jun 15, 2016, at 10:23 AM, Jonathon Pendlum
<[email protected]<mailto:[email protected]>> wrote:
Craig,
Did you checkout the radio-redo branch on gr-ettus?
Jonathon
On Tue, Jun 14, 2016 at 10:23 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I reinstalled everything in the following order:
1. ?uhd under the rfnoc-radio-redo branch
2. gnuradio
3. gr-ettus
When I installed gr-ettus I got the following error when I ran "make -j4"
[ 44%] Building CXX object
swig/CMakeFiles/ettus_swig_swig_2d0df.dir/ettus_swig_swig_2d0df.cpp.o
Linking CXX executable ettus_swig_swig_2d0df
Swig source
/home/craig/gr-ettus/lib/device3.cc<http://device3.cc>: In member function
?virtual void device3_impl::connect(const string&, size_t, std::string,
size_t)?:
/home/craig/gr-ettus/lib/device3.cc<http://device3.cc>:61:11: error: ?class
uhd::usrp::multi_usrp? has no member named ?connect?
_dev->connect(
^
/home/craig/gr-ettus/lib/device3.cc<http://device3.cc>: In member function
?virtual void device3_impl::connect(const string&, std::string)?:
/home/craig/gr-ettus/lib/device3.cc<http://device3.cc>:73:11: error: ?class
uhd::usrp::multi_usrp? has no member named ?connect?
_dev->connect(
^
/usr/local/include/uhd/types/sensors.hpp:141: Warning 362: operator= ignored
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/device3.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/craig/gr-ettus/lib/rfnoc_block_impl.cc: In constructor
?gr::ettus::rfnoc_block_impl::rfnoc_block_impl(const sptr&, const string&,
const uhd::stream_args_t&, const uhd::stream_args_t&)?:
/home/craig/gr-ettus/lib/rfnoc_block_impl.cc:146:49: error: ?class
uhd::device3? has no member named ?find_block_ctrl?
_blk_ctrl(dev->get_device()->get_device3()->find_block_ctrl(block_id)),
^
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_block_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 44%] Built target ettus_swig_swig_2d0df
make: *** [all] Error 2
craig@craig-VirtualBox:~/gr-ettus/build (master)$
?
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: Tuesday, June 14, 2016 2:47 PM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller;
[email protected]<mailto:[email protected]>
Subject: Re: uhd_usrp_probe in rfnoc-radio-redo for custom noc_block_Receiver
in uhd_usrp_probe is showing up as Block
Hi Craig,
block.xml is the default XML that is loaded when a block's XML is not found --
basically a NOC ID is not matched with a corresponding XML file. Double check
your XML file is installed in the right place (looks like
/usr/local/share/uhd/rfnoc from the log), that the NOC IDs match, and that you
don't have any syntax errors in the XML file.
Jonathon
On Tue, Jun 14, 2016 at 11:19 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
?Jonathon,
I made it past my problem of using rfnoc-radio-redo with my X310.
Using my own python code running in cocotb, I was able to simulate the
noc_block_skeleton.v file and in the process learned a lot more about flow
control and the changes you made from the rfnoc-devel branch.
My testbench imports my file sink data generated by gnuradio and runs the data
through your noc_block_skeleton.v file. Then I renamed the
noc_block_skeleton.v as noc_block_Receiver.v and generated a bit file. I also
generated the necessary XML files with a unique NOC ID so uhd_usrp_probe would
recognize it.
What is strange is that uhd_usrp_probe recognized my .bit file but didn't match
it up with my
Receiver.xml file located in /usr/local/share/uhd/rfnoc/blocks/Receiver.xml.
My NOC ID for Receiver is 614A. (Today's date)
Instead it matched it with the block.xml. It also named it block instead of
Receiver.
I also tried imitating the noc_block_moving_avg instead of noc_block_skeleton
and I got the same result.
How can this be? I have done this plenty of times with the rfnoc-devel branch
coupled with my E310.
Also I thought the rfnoc-radio-redo branch eliminated one of the radios?
Shown below is a portion of what I got when I ran uhd_usrp_probe --init-only
Craig
-- [RFNOC] ------- Block Setup -----------
-- SEND (SID: 00:6e>02:70)...Setting up NoC-Shell Control for port #0 (SID:
00:6e>02:70)...OK
-- Port 112: Found NoC-Block with ID 614A000000000000.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Using default block configuration.
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- [RFNoC Factory] Using controller key 'Block' and block name 'Block'
-- block_ctrl_base()
-- base_path = "/usr/local/share/uhd/rfnoc"
-- base_path = "/usr/local/share/uhd/rfnoc"
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x614A000000000000 Block ID: 0/Block_0
-- [0/Block_0] block_ctrl_base::clear()
-- node_ctrl_base::clear()
-- [0/Block_0] block_ctrl_base::_clear()
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Block_0] Adding port definition at xbar/Block_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/MovingAverage_0
-- * 0/Block_0
craig@craig-VirtualBox:~/uhd/fpga-src/usrp3/top/x300/build ((detached from
b62d96c))$ cd ..
?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/20160615/1687ecdf/attachment-0001.html>
------------------------------
Message: 45
Date: Wed, 15 Jun 2016 10:38:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: ???? <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] ??RE: E310 rates and frequencies
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1255"; Format="flowed"
On 06/15/2016 10:32 AM, ???? wrote:
> Thank you Marcus,
>
> Regarding, the samples rate, so what is the meaning of the "channel"
> parameter in the "set_tx_rate" function (multi_usrp.hpp)?
>
> Best regards,
> Roy
It sets the sample rate of the corresponding streamer channel. In the
case of E310, all channels must be the same.
The UHD API spans a wide range of hardware, so some of its features and
API elements apply differently, depending on the hardware.
> ------------------------------------------------------------------------
> *?:*??USRP-users ?[[email protected]]? ??? Marcus D.
> Leech via USRP-users ?[[email protected]]?
> *??????:* ??? ????? 15 ???? 2016 17:20
> *
> *????:* [email protected]
> **
> *??????:* Re: [USRP-users] E310 rates and frequencies
> *
>
> On 06/15/2016 09:52 AM, ???? via USRP-users wrote:
>> Hi,
>>
>> A few questions regarding the E310:
>>
>> * What are the possible TX sample rates, that is, what are the
>> quantized values?
>>
> Since you can set the master-clock rate anywhere between 10Mhz and
> 56MHz, and then use factor-of-2 decimation in the FPGA,
> sample rates as delivered to the application are pretty flexible.
>
>> * Can I set different sample rates for each channel?
>>
> I don't believe that is supported, since the AD9361 delivers samples
> at the same rate on both channels.
>
>> * I noticed that in the UHD API (multi_usrp.hpp), the set_tx_freq
>> function has a channel parameter. However, I also read that both
>> TX channels use the same LO. Therefore, is it possible to set a
>> different frequency to each channel? What are the limitations?
>>
> You can have different frequencies on the two channels, subject to the
> "reach" of the DDC chains in the FPGA--such "reach" would be limited
> to about 30Mhz in the two-channel case, because the master clock
> can't be any higher than that for two-channel use.
>
>
>> Thanks a lot,
>> 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/20160615/d6c363a0/attachment-0001.html>
------------------------------
Message: 46
Date: Wed, 15 Jun 2016 14:39:00 +0000
From: Dan CaJacob <[email protected]>
To: Dave NotTelling <[email protected]>, Michael West
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Resetting N210 & X310 Remotely
Message-ID:
<CAMOmJOBguaiLMzvAkGcLYu4YDquZ1ZP=wev4hpilern3jtt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I typically used a USB relay to accomplish this in the past at dozens of
remote sites. Doing the same for the B2XX products is more complicated and
requires modding the board because there is a clever power-switching device
that toggles between the USB port and barrel connector for power.
On Wed, Jun 15, 2016 at 12:24 AM Dave NotTelling via USRP-users <
[email protected]> wrote:
> Michael & Neel,
>
> Thank you for the explanation and suggestions! The USB reload is
> pretty fast, but doing so over the network or PCIe is horribly slow. Power
> cycling via a managed power strip might be the only viable solution =\
>
> Thanks!
>
> -Dave
>
> On Tue, Jun 14, 2016 at 4:21 PM, Michael West <[email protected]>
> wrote:
>
>> There is no software reset built in. You can accomplish it by either 1)
>> adding remote power management as Neel indicated or 2) by loading the FPGA
>> image via JTAG. Remote power cycling will be instant. Loading the FPGA
>> image over JTAG takes ~20 second and means connecting a JTAG programmer to
>> the J203 header on the N210 and a USB cable to the JTAG port on the front
>> panel of the X310.
>>
>> Regards,
>> Michael
>>
>> On Tue, Jun 14, 2016 at 12:32 PM, Neel Pandeya via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello Dave:
>>>
>>> By reset, do you mean to power cycle, or to reset to some known initial
>>> state? There is no API call in UHD to reset or power cycle the radio. You
>>> might be able to achieve the same goal by using a managed power strip [1,2].
>>>
>>> [1] http://www.digital-loggers.com/lpc.html
>>> [2] https://www.amazon.com/gp/product/B00EZWD146/
>>>
>>> --Neel Pandeya
>>>
>>>
>>>
>>> On 18 May 2016 at 13:20, Dave NotTelling via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Is it possible to reset the N210 and X310 radios remotely? Hopefully
>>>> some API command that can trigger something like an FPGA reset / bit file
>>>> reload?
>>>>
>>>> Thanks!
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/3d2e6e94/attachment-0001.html>
------------------------------
Message: 47
Date: Wed, 15 Jun 2016 11:37:47 -0400
From: "Collins, Richard" <[email protected]>
To: [email protected]
Subject: [USRP-users] [RFNoC] X310 timeout during uhd_usrp_probe
Message-ID:
<CABgQ8cbnj6yZ0RQ6y50xiciUQMUHhH06o2QyQKBGrWzSwH=p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
The error:
I'm using rfnoc-radio-redo, and here is the header that's printed out when
using uhd:
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-549-geb3036f6
When I run uhd_usrp_probe, it gets most of the way through listing all the
RFNoC info, waits for a second or two, and times out with this error:
Error: EnvironmentError: IOError: Radio ctrl (CE_09_Port_192) no response
packet - AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/ninja/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
The whole output can be found at http://pastebin.com/9rWpk1TP .
What I did to get here:
Building a default bitstream (according to
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started#building-an-image-with-rfnoc
) was succesful, and ran successfully (I was able to run the
rfnoc_fosphor.grc example just fine). I also wanted to be able to use a
couple different (standard) Noc Blocks. I edited rfnoc_ce_auto_inst_x310.v
with the changes that can be seen by the output of
"*diff rfnoc_ce_auto_inst_x310.v.default rfnoc_ce_auto_inst_x310.v*":
48c48
< noc_block_null_source_sink inst_noc_block_null_source_sink (
---
> noc_block_logpwr inst_noc_block_logpwr (
69c69
< noc_block_vector_iir inst_noc_block_vector_iir (
---
> noc_block_ddc inst_noc_block_ddc (
The whole rfnoc_ce_auto_inst_x310.v file that I'm using can be found at
http://pastebin.com/kNYrfRTZ .
After changing rfnoc_ce_auto_inst_x310.v, I ran "*source setupenv.sh*",
followed by a "*make X310_RFNOC_HGS*" (which completed successfully),
programmed the X310 with: *uhd_image_loader
--args="type=x300,addr=192.168.40.2" --fpga-path="/home/*<user>
*/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HGS.bit"* , and
restarted the X310. It responds to pings and uhd_find_devices, but gives
the same error as above when trying to run a gr-ettus rfnoc example.
Not knowing any better, I also tried re-building uhd and gr-ettus to see if
that would help, as well as rebooting the computer, and I still get the
same error. Any suggestions?
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/b60841ac/attachment-0001.html>
------------------------------
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 15
******************************************
