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. Re: GPSDO as stand-alone component (Steven Knudsen)
2. Re: uhd_usrp_probe in rfnoc-radio-redo for custom
noc_block_Receiver in uhd_usrp_probe is showing up as Block
(Swanson, Craig)
3. Re: [RFNoC] X310 timeout during uhd_usrp_probe (Jonathon Pendlum)
4. How do I turn off one of the radios in rfnoc-radio-redo and
how can I use the debug UART? (Swanson, Craig)
5. Re: RFNoC with E310 (Martin Braun)
6. Re: [RFNoC] X310 timeout during uhd_usrp_probe (Collins, Richard)
7. Re: Octoclock updating firmware & change ip (Michael West)
8. N210s not recognized (avinash kalyanaraman)
9. Re: Effective a length of VERT2450 antenna and its impact on
receiving signal. (Marcus M?ller)
10. Re: N210s not recognized (Marcus D. Leech)
11. Re: N210s not recognized (avinash kalyanaraman)
12. Re: N210s not recognized (avinash kalyanaraman)
13. Re: N210s not recognized (Marcus D. Leech)
14. Power management E310 (Claudio Cicconetti)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Jun 2016 10:27:36 -0600
From: Steven Knudsen <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] GPSDO as stand-alone component
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Being lazy, and since my Octoclock-G is already connected to a scope for
triggering, I measured the 1 PPS pulse to be 200 ms wide and 2.82 V pk-pk. You
can easily find GPS chips or modules that will output that level, but I am not
sure about pulse width. I suspect that as long as the pulse width is on the
order of 200 us or more, the B200mini will be fine. If you are not super fussy
about pulse edge degradation, then a 555-based one-shot will make the pulse
from the GPS module as long as you want.
Obviously, it?s worth consulting the schematic where is says the 1 PPS max is
-5 / +5 V and min is 0 / 2.5 V and the SN75AUP1T57 is used to buffer the
signal for FPGA input.
Hope that helps.
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
> On Jun 15, 2016, at 08:32, Claudio Cicconetti via USRP-users
> <[email protected]> wrote:
>
> 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
>
>
> _______________________________________________
> 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/ecbc0fe8/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 15 Jun 2016 16:33:35 +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,
Yes that fixed my problems by installing the radio-redo? in gr-ettus.
Thank you for your help.
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: Wednesday, June 15, 2016 10:23 AM
To: Swanson, Craig
Cc: Marcus M?ller; Martin Braun; [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
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: 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<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/b4b38a11/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 15 Jun 2016 11:39:40 -0500
From: Jonathon Pendlum <[email protected]>
To: "Collins, Richard" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] X310 timeout during uhd_usrp_probe
Message-ID:
<CAGdo0uT5c0MwsiyVFVnBGncEjwGDU0jsaCCTzrk=2l9gend...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Richard,
It looks like the DDC RFNoC block may have an issue. I'm looking into it.
For now, don't instantiate it in a design. If you run into other issues,
let me know.
Jonathon
On Wed, Jun 15, 2016 at 10:37 AM, Collins, Richard via USRP-users <
[email protected]> wrote:
>
> 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
>
> _______________________________________________
> 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/7a8b9227/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 15 Jun 2016 16:41:37 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] How do I turn off one of the radios in
rfnoc-radio-redo and how can I use the debug UART?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I am assuming that I un-comment out one of the lines in the /top/x300/Makefile
to turn off one of the radios. It says it is experimental. Is it more robust
now? I think this only applies to the DSP's, but not removing the actual
radio? I want to remove one of the radios to save space for someday moving my
code over to the much smaller E310.
Also I noticed a UART is available for debug. Have you found that useful?
Here is the portion in the Makefile:
# Debug Options
# Uncomment the following lines to build radio's with no DSP's (experimental!)
#OPTIONS += DELETE_DSP0=1
#OPTIONS += DELETE_DSP1=1
# Uncomment the following line to add a debug UART on GPIO 10 & 11
#OPTIONS += DEBUG_UART=1
Here is what I get when I uhd_usrp_probe:
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/MovingAverage_0
-- * 0/Receiver_0
?
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/20160615/93a0cc90/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 15 Jun 2016 09:45:01 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC with E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
John,
we don't provide images except for the occasional stable release
udpates, so there's no RFNoC image. You'll need to set up a cross
compile environment, see here for instructions:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312
Cheers,
Martin
On 06/15/2016 01:40 AM, john liu via USRP-users wrote:
> 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
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Wed, 15 Jun 2016 13:43:58 -0400
From: "Collins, Richard" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] X310 timeout during uhd_usrp_probe
Message-ID:
<cabgq8cy-frko4nfii1od__ck+_vu0pkwe6phw8xyw+q6mqb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Thanks for the quick reply! That sounds good.
I was wondering if it would help if I ran a make cleanall first, and
re-generated. I'm doing that now on one computer, but since it'll take a
while, I'm going to let it run through.
Again, thanks for the heads up. I appreciate what you and Martin Braun (and
whomever else) are doing, and have been wanting to get into using RFNoC for
some time now.
Richard
On Wed, Jun 15, 2016 at 12:39 PM, Jonathon Pendlum <
[email protected]> wrote:
> Hi Richard,
>
> It looks like the DDC RFNoC block may have an issue. I'm looking into it.
> For now, don't instantiate it in a design. If you run into other issues,
> let me know.
>
>
>
> Jonathon
>
> On Wed, Jun 15, 2016 at 10:37 AM, Collins, Richard via USRP-users <
> [email protected]> wrote:
>
>>
>> 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
>>
>> _______________________________________________
>> 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/a98e29d9/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 15 Jun 2016 10:49:55 -0700
From: Michael West <[email protected]>
To: Pol Henarejos <[email protected]>
Cc: Nicholas Corgan <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock updating firmware & change ip
Message-ID:
<CAM4xKrrRUsRhBOz6HZegYanL4VtF8YysZURWP_kZHRN=or8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pol,
If the bootloader is loaded, the internal, external, and status LEDs will
all be on for one second upon power up. If you only see the internal and
status LEDs, the bootloader is not loaded and the Octoclock is booting
directly into the firmware.
Regards,
Michael
On Jun 14, 2016 11:05 PM, "Pol Henarejos" <[email protected]> wrote:
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 --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/951a1ee2/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 15 Jun 2016 14:00:50 -0400
From: avinash kalyanaraman <[email protected]>
To: [email protected]
Subject: [USRP-users] N210s not recognized
Message-ID:
<cajpbu_hebovw8b3beg5742rykcejars00ofqyo9tdbcmbqn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have connected to my USRP N210 to a computer running Ubuntu 15.04 via a
GigE switch. However, the computer fails to recognize the USRPs, both via
uhd_find_devices and a ping 192.168.10.2 says "connect: network is
unreachable" .
I set a static ip via : sudo ifconfig eth0 192.168.10.1 .
It isn't an issue with the ethernet port, as a direct ethernet "internet"
connection works fine.
Could you please let me know how I might be able to fix this ?
Thanks!
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/d5bdf23f/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 15 Jun 2016 20:05:44 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Effective a length of VERT2450 antenna and
its impact on receiving signal.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
In addition to Steven's references, I'd like to add that yes, VERT2450
is really just a monopole. It *is* a good 2.4GHz WiFi antenna, but if
you're looking for measurement antennas, it's definitely not the product
of choice.
Other than that: WiFi cards equalize heavily. I don't believe that even
a very narrowband antenna would pose a significant problem for that.
But yes, *everything*, including temperature, air moisture and connector
pressure influence the channel matrix. The question is how you would
measure that with something like a WiFi card, which is by no means a
device meant for measurements, or with something as varying, fading,
selective as the typical WiFi channel, short of using an anechoic chamber.
Best regards,
Marcus
On 06/14/2016 03:14 PM, Steven Knudsen via USRP-users wrote:
> Good places to start reading and learning would be
>
> http://www.arrl.org/antennas
>
> http://www.arrl.org/arrl-antenna-book
>
> and there may be some good starting points here
>
> http://www.antenna-theory.com/
>
> For your particular topic, I?d start by reading IEEE journals as much
> work has been published on channel characterization. There you will
> find the answer to your last question is ?yes?.
>
> Finally, it?s likely worth searching for theses and dissertations on
> the topic. I remember a few published back in the late 90s early 2000s
> by students at my university.
>
>
> Good luck.
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> /Der entscheidende Augenblick der menschlichen Entwicklung
> ist immerw?hrend. Darum sind die revolution?ren geistigen Bewegungen,
> welche alles Fr?here f?r nichtig erkl?ren, im Recht, denn es ist
> noch nichts geschehen. - Franz Kafka/
>
>> On Jun 14, 2016, at 06:43, Jeon via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Dear USRP users,
>>
>> I wonder that how long a length of VERT2450 antenna inside plastic
>> cover is.
>>
>> Currently, I am trying to measure channel matrix, channel state
>> information (magnitude and phase of each OFDM subcarrier) of Wi-Fi.
>>
>> And also I am curious whether a length of VERT2450 antenna has an
>> impact of measuring magnitude and phase of each OFDM subcarrier.
>> (e.g., incorrect antenna length results in incorrect channel state
>> information.)
>>
>> Frankly speaking, I am using not USRP, but only VERT2450 antenna. I
>> am using it with connected to Atheros 802.11n Wi-Fi card. (ath9k
>> series; AR9580, etc.)
>>
>> The last small question is,does a length of a cable, and shielding
>> connecting VERT2450 and Wi-Fi card (or duaghterboard) have an impact
>> on channel matrix?
>>
>> Regards,
>> Jeon.
>> _______________________________________________
>> 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/20160615/330f8825/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 15 Jun 2016 14:09:09 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210s not recognized
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/15/2016 02:00 PM, avinash kalyanaraman via USRP-users wrote:
> Hi all,
>
> I have connected to my USRP N210 to a computer running Ubuntu 15.04
> via a GigE switch. However, the computer fails to recognize the USRPs,
> both via uhd_find_devices and a ping 192.168.10.2 says "connect:
> network is unreachable" .
>
> I set a static ip via : sudo ifconfig eth0 192.168.10.1 .
>
> It isn't an issue with the ethernet port, as a direct ethernet
> "internet" connection works fine.
>
> Could you please let me know how I might be able to fix this ?
>
> Thanks!
>
>
You're going to need to use Network Manager via the gui widgets to
configure static IP. Anything you do with "ifconfig" will get overwritten
by whatever policy Network Manager has in place.
------------------------------
Message: 11
Date: Thu, 16 Jun 2016 06:29:00 +1200
From: avinash kalyanaraman <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210s not recognized
Message-ID:
<cajpbu_hhh0zkjpipod4+1n5pcoaebsfseir79wh-xa91q7w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks.
In the GUI variant, I select manual IPV4 and it asks for Netmask and
Gateway addresses too. What would be the addresses ?
Attached is an image of what I have set, and it still fails to recognize
the device.
One more point is that the lshw command indicates the following - i.e. the
speed is 100Mb/s, and not a 1000Mb/s. I have however connected the computer
to the USRP via a switch. Is this a concern?
configuration: autonegotiation=on broadcast=yes driver=atl1c
driverversion=1.0.1.1-NAPI duplex=full ip=192.168.10.1 latency=0 link=yes
multicast=yes port=twisted pair speed=100Mbit/s
On Wed, Jun 15, 2016 at 2:09 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/15/2016 02:00 PM, avinash kalyanaraman via USRP-users wrote:
>
>> Hi all,
>>
>> I have connected to my USRP N210 to a computer running Ubuntu 15.04 via a
>> GigE switch. However, the computer fails to recognize the USRPs, both via
>> uhd_find_devices and a ping 192.168.10.2 says "connect: network is
>> unreachable" .
>>
>> I set a static ip via : sudo ifconfig eth0 192.168.10.1 .
>>
>> It isn't an issue with the ethernet port, as a direct ethernet "internet"
>> connection works fine.
>>
>> Could you please let me know how I might be able to fix this ?
>>
>> Thanks!
>>
>>
>> You're going to need to use Network Manager via the gui widgets to
> configure static IP. Anything you do with "ifconfig" will get overwritten
> by whatever policy Network Manager has in place.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/16a60070/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network_manager.png
Type: image/png
Size: 290291 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/16a60070/attachment-0001.png>
------------------------------
Message: 12
Date: Thu, 16 Jun 2016 06:35:46 +1200
From: avinash kalyanaraman <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210s not recognized
Message-ID:
<cajpbu_fn5kjqjvmkzygmqvnpfst9y+kvofyy0cmk2yya_gv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry - the attachment was incorrect. Attached again.
On Thu, Jun 16, 2016 at 6:29 AM, avinash kalyanaraman <[email protected]
> wrote:
> Thanks.
>
> In the GUI variant, I select manual IPV4 and it asks for Netmask and
> Gateway addresses too. What would be the addresses ?
>
> Attached is an image of what I have set, and it still fails to recognize
> the device.
>
> One more point is that the lshw command indicates the following - i.e. the
> speed is 100Mb/s, and not a 1000Mb/s. I have however connected the computer
> to the USRP via a switch. Is this a concern?
>
> configuration: autonegotiation=on broadcast=yes driver=atl1c
> driverversion=1.0.1.1-NAPI duplex=full ip=192.168.10.1 latency=0 link=yes
> multicast=yes port=twisted pair speed=100Mbit/s
>
>
> On Wed, Jun 15, 2016 at 2:09 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 06/15/2016 02:00 PM, avinash kalyanaraman via USRP-users wrote:
>>
>>> Hi all,
>>>
>>> I have connected to my USRP N210 to a computer running Ubuntu 15.04 via
>>> a GigE switch. However, the computer fails to recognize the USRPs, both via
>>> uhd_find_devices and a ping 192.168.10.2 says "connect: network is
>>> unreachable" .
>>>
>>> I set a static ip via : sudo ifconfig eth0 192.168.10.1 .
>>>
>>> It isn't an issue with the ethernet port, as a direct ethernet
>>> "internet" connection works fine.
>>>
>>> Could you please let me know how I might be able to fix this ?
>>>
>>> Thanks!
>>>
>>>
>>> You're going to need to use Network Manager via the gui widgets to
>> configure static IP. Anything you do with "ifconfig" will get overwritten
>> by whatever policy Network Manager has in place.
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> --
> Avinash
>
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/39c4a799/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network_manager.png
Type: image/png
Size: 286421 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160616/39c4a799/attachment-0001.png>
------------------------------
Message: 13
Date: Wed, 15 Jun 2016 14:38:42 -0400
From: "Marcus D. Leech" <[email protected]>
To: avinash kalyanaraman <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210s not recognized
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/15/2016 02:35 PM, avinash kalyanaraman wrote:
> Sorry - the attachment was incorrect. Attached again.
You don't want a gateway address of .255 in this case. Set it to any
other legit address on that subnet--the gateway is only use to route
off-subnet traffic that happens to get to that interface.
It may be the case that your switch is not set up to gateway 100Mbit to
1000Mbit traffic? The USRP2 absolutely requires 1000Mbit to work.
>
> On Thu, Jun 16, 2016 at 6:29 AM, avinash kalyanaraman
> <[email protected] <mailto:[email protected]>> wrote:
>
> Thanks.
>
> In the GUI variant, I select manual IPV4 and it asks for Netmask
> and Gateway addresses too. What would be the addresses ?
>
> Attached is an image of what I have set, and it still fails to
> recognize the device.
>
> One more point is that the lshw command indicates the following -
> i.e. the speed is 100Mb/s, and not a 1000Mb/s. I have however
> connected the computer to the USRP via a switch. Is this a concern?
>
> configuration: autonegotiation=on broadcast=yes driver=atl1c
> driverversion=1.0.1.1-NAPI duplex=full ip=192.168.10.1 latency=0
> link=yes multicast=yes port=twisted pair speed=100Mbit/s
>
>
> On Wed, Jun 15, 2016 at 2:09 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> On 06/15/2016 02:00 PM, avinash kalyanaraman via USRP-users wrote:
>
> Hi all,
>
> I have connected to my USRP N210 to a computer running
> Ubuntu 15.04 via a GigE switch. However, the computer
> fails to recognize the USRPs, both via uhd_find_devices
> and a ping 192.168.10.2 says "connect: network is
> unreachable" .
>
> I set a static ip via : sudo ifconfig eth0 192.168.10.1 .
>
> It isn't an issue with the ethernet port, as a direct
> ethernet "internet" connection works fine.
>
> Could you please let me know how I might be able to fix this ?
>
> Thanks!
>
>
> You're going to need to use Network Manager via the gui
> widgets to configure static IP. Anything you do with
> "ifconfig" will get overwritten
> by whatever policy Network Manager has in place.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Avinash
>
>
>
>
> --
> Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160615/33bb82a7/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 16 Jun 2016 11:25:54 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: [USRP-users] Power management E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear all,
Has anybody tried to user power management on an E310?
I would like to suspend Linux, then resume based on certain trigger.
Timed sleep would be ideal, but I understand this might be difficult to
achieve.
A suitable alternative could be waking up on LAN or GPIO stimulus.
Best regards,
Claudio
--
Claudio Cicconetti, PhD
Software Engineer - MBI S.r.l. - Pisa, Italy
------------------------------
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 16
******************************************
