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: GPS signal Acquisation using USRP N210, DBSRX (Raj)
2. Re: GPS signal Acquisation using USRP N210, DBSRX (Raj)
3. Re: UHD dissector for Wireshark (Nick Foster)
4. Re: UHD dissector for Wireshark (Alexander Chemeris)
5. Re: Disturbance in the force or Glitch in the matrix? NOT
FIXED (mepard)
6. Alternative USRP Ref clock frequency (Damien Serant)
7. B100 Requires Power Reset (Dan CaJacob)
8. Re: B100 Requires Power Reset (Josh Blum)
9. Re: UHD dissector for Wireshark (Dario Lombardo)
10. Re: B100 Requires Power Reset (Dan CaJacob)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 Mar 2013 00:00:08 +0800 (SGT)
From: Raj <[email protected]>
To: Carles Fernandez <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210,
DBSRX
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear Carles,
Many thanks for your valuable suggestion, I will install gnss-sdr.
I am using LNA amplifier from Mini-Circuits (ZRL-2150) with gain 25dB, and of
course DC bias is supplied to the active antenna. I was expecting to see some
difference with additional LNA but there is none, may be I am wrong.
?
Regards
Raj
________________________________
From: Carles Fernandez <[email protected]>
To: Raj <[email protected]>
Cc: USRP List <[email protected]>
Sent: Thursday, 21 March 2013 10:39 AM
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210, DBSRX
Dear Raj,
this is as expected, since the GPS signals are under the noise floor. If you
are using a Low Noise Amplifier in your antenna, you should see the shape of
its transfer function when applying the FFT.
If you are interested in processing GPS signals, maybe GNSS-SDR
(http://gnss-sdr.org) could be of help. It is a c++ application based on GNU
Radio that implements all the processing chain, from the USRP output to the
computation of position, velocity and time. It supports UHD, so you will be
able to use your N210+DBSRX setup.
Best regards,
Carles
On Thu, Mar 21, 2013 at 11:04 AM, Raj <[email protected]> wrote:
Hi
>
>
>I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The FFT
>figure using grc are the same with and without GPS signal input. Any
>suggestion would be highly appreciated, thanks in advance.
>?
>Regards
>Raj
>
>_______________________________________________
>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/20130322/6dd4eb6c/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 22 Mar 2013 00:08:40 +0800 (SGT)
From: Raj <[email protected]>
To: Mike Jameson <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210,
DBSRX
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Mike,
Thanks for your suggestion, its really very informative.
An additional LNA used before USRP, and bias (LNA amplifier from Mini-Circuits
[ZRL-2150] with gain 25dB, and 5v DC bias is supplied to the active antenna). I
fallowed all instructions for installing gr-baz so as to use Fast
Auto-Correlation approach to see GPS signal. Please find the screen shots of
GRC window and obtained figure, unfortunately, its not close to your figures.
I had trouble seeing figures from your given link
(http://sites.google.com/site/radiorausch/USRPFastAutocorrelation.html ), could
you please send it again.
?
Regards
Raj
________________________________
From: Mike Jameson <[email protected]>
To: Raj <[email protected]>
Cc: USRP List <[email protected]>
Sent: Thursday, 21 March 2013 11:14 AM
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210, DBSRX
I meant to say that the 'Size' variable in the 'Fast AutoCorrelation
Sink' block needs to be changed in order to view at 1ms.? Use a
sampling rate of (100e6/20) and set the Fast AutoCorrelation Sink
'Size' to (2**14).
Also, if you happen to be using a 5v active GPS antenna don't forget
to power it! You can use the 5v bias on the DBSRX by shorting J101.
See: http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpDBoardDBSRX
Mike
--
Mike Jameson M0MIKBSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://www.scanoo.com
On 21 March 2013 10:44, Mike Jameson <[email protected]> wrote:
> Hi Raj,
>
> Have a play with balint's groovy gr-baz block called 'Fast
> AutoCorrelation Sink' in GRC and look for peaks at 1ms (alter the
> fft-rate). The autocorrelation technique allows you to see the GPS
> signal below the noise floor.
>
> See: http://wiki.spench.net/wiki/Fast_Auto-correlation
>
> Here are two FFT plots from
> http://sites.google.com/site/radiorausch/USRPFastAutocorrelation.html
> to show you what to look for:
>
> https://sites.google.com/site/radiorausch/usrp_fac_gps.png
> https://sites.google.com/site/radiorausch/usrp_fac_gps_full.png
>
> Mike
>
> --
> Mike Jameson M0MIKBSc
> Radio Communications Technology Specialist
> Email: [email protected]
> Web: http://www.scanoo.com
>
>
> On 21 March 2013 10:04, Raj <[email protected]> wrote:
>> Hi
>>
>> I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The
>> FFT figure using grc are the same with and without GPS signal input. Any
>> suggestion would be highly appreciated, thanks in advance.
>>
>> Regards
>> Raj
>>
>> _______________________________________________
>> 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/20130322/b5a2937b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GRC_ScreenShot.png
Type: image/png
Size: 193165 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/b5a2937b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FFT_and_Fast_AutoCorrelation.png
Type: image/png
Size: 77584 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/b5a2937b/attachment-0003.png>
------------------------------
Message: 3
Date: Thu, 21 Mar 2013 11:24:25 -0700
From: Nick Foster <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/21/2013 01:38 AM, Dario Lombardo wrote:
> Perfect, you're right.
> If you agree I can try to submit both to the wireshark trunk.
The VRT dissector is not quite complete although it should work for most
uses. The parts of the protocol used by the N210 should be fully
dissected; however, IF context packets and other minutiae in the
protocol have not been implemented. I don't know the Wireshark
community's standards regarding dissector completeness, but just FYI.
Alexander, I've pulled your commit back into the master branch.
--n
>
> Don't you think that the UHD dissector should be renamed to UHD CTRL?
> Having a quick look at the uhd code, seems that each part of the
> communication works on a different port, so different dissectors
> should be implemented.
>
> On Thu, Mar 21, 2013 at 4:40 AM, Alexander Chemeris
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Looking at the size of the packet I think it's VRT aka VITA 49:
> https://github.com/chemeris/vrt-dissector
>
> On Thu, Mar 21, 2013 at 2:31 AM, Dario Lombardo
> <[email protected] <mailto:[email protected]>>
> wrote:
> >
> >
> > On Wed, Mar 20, 2013 at 6:24 PM, Alexander Chemeris
> > <[email protected]
> <mailto:[email protected]>> wrote:
> >>
> >> There is no formal description, at least no which I know of. We
> based
> >> our implementation on this header and relevant code:
> >>
> >>
>
> https://github.com/fairwaves/UHD-Fairwaves/blob/fairwaves/umtrx/host/lib/usrp/usrp2/fw_common.h
> >
> >
> > At last I need some help from the UHD masters.
> > Once understood the protocol, the dissector will be complete.
> Hope someone
> > helps me.
> >
> > CTRL support seems ok.
> >
> > What is missing is decoding of frames as the following:
> >
> > 0x0000: 4500 0308 0000 4000 2011 c291 c0a8 0a02
> E.....@.........
> > 0x0010: c0a8 0a01 c004 8e97 02f4 0000 1411 00bb
> ................
> > 0x0020: 0000 0003 0000 7078 413d ae59 f4ed ee0b
> ......pxA=.Y....
> > 0x0030: fef3 02fa fd04 0112 f721 00ff fffd f5f7
> .........!......
> > 0x0040: f7fc fd0c ec08 ec13 130c f9fc 0800 0b0e
> ................
> > 0x0050: 0605 f703 fcf0 0cfc 0914 f906 fdfb ea0e
> ................
> > 0x0060: 0e04 0a0d 1608 1b03 ff04 f5fb ff0f 0713
> ................
> > 0x0070: faec fdfe 1afb f603 1507 0af6 fef8 f606
> ................
> > 0x0080: f7ff 00f3 f5fb f7f5 f5f9 fdf0 f6f1 ef09
> ................
> > 0x0090: 0304 f204 ecfd fa0c 02f0 fa08 04fd fc00
> ................
> > 0x00a0: 060a 07f6 f8f2 0fe5 15f6 0003 e910 0307
> ................
> > 0x00b0: 0a01 0215 ed24 f802 02ee f300 e701 f8ee
> .....$..........
> > 0x00c0: faf2 fffe f902 f4fd 04fb 0105 fa0a fa01
> ................
> > 0x00d0: fb0e 0702 f60b 040b fd0c eb1a 0d10 0f07
> ................
> > 0x00e0: eff3 ef12 03ef e8f5 f6f4 03ec fd0c fefe
> ................
> > 0x00f0: fe17 f6fc ef08 fb1d edf4 ed08 0601 f9fc
> ................
> > 0x0100: f30d ff02 f3f7 0b04 11f1 fefc f101 0104
> ................
> > 0x0110: 1412 03fe 090d fbfe 020a 0d0f 0107 fdf8
> ................
> > 0x0120: 1104 feeb fbfb fc05 05e9 0bf2 0cf4 fff1
> ................
> > 0x0130: fb08 f908 0619 fb09 0005 0406 ee0a fcff
> ................
> > 0x0140: 0600 ff04 19fc f707 06f4 fcf9 fa03 0004
> ................
> > 0x0150: e702 ed06 f6f5 f40d 0802 e4ef 0d09 07f1
> ................
> > 0x0160: 0aee 10f7 06e7 f90d 010b 00f3 0c0d 0205
> ................
> > 0x0170: 0605 0bfd fb10 010f fcf3 010b 11ff edfd
> ................
> > 0x0180: 0a07 05fd 0cfa 130f 0406 050b 0113 0608
> ................
> > 0x0190: feff e3f4 0af7 02fd fffe 1a04 fcf7 fbf9
> ................
> > 0x01a0: 06e7 0506 fe07 fdf4 000a f70d 00f2 070b
> ................
> > 0x01b0: 07f7 0a09 f8fa eef7 05fa 04f8 ecec 0ce3
> ................
> > 0x01c0: f7fa 0000 f906 f713 f20c f9fe 0002 0710
> ................
> > 0x01d0: ed0e f704 0100 f7ff 00fa 05f7 1bfa 0ef4
> ................
> > 0x01e0: f900 05f6 eff9 f3f9 ef04 f400 fdf1 f502
> ................
> > 0x01f0: f507 0903 0bf9 f3f8 06fc fe05 f315 ff03
> ................
> > 0x0200: 14f5 04f3 01ff 0302 0b17 fd06 f504 041c
> ................
> > 0x0210: 00f3 0a08 edfa 03f8 1b01 f7ef 01fb 04f9
> ................
> > 0x0220: fbfb fbfe 01df 1ce0 11fd 0a00 0203 fb03
> ................
> > 0x0230: 11e7 12fd fc00 fbe5 02fb 07f9 e9e5 f10a
> ................
> > 0x0240: f0f0 f1e3 070e f4fd 071b 220b 05fc f619
> ..........".....
> > 0x0250: 00f1 fcf8 0b0b fd10 ec02 f60d 0105 fc0b
> ................
> > 0x0260: 1108 12f6 10f9 0ef8 0f03 fd1b ff12 fb05
> ................
> > 0x0270: e90c f110 07fa f9ff 0e0c 0df3 0df7 0af9
> ................
> > 0x0280: 0504 1616 f805 0e17 f614 02fe 00fa 0b06
> ................
> > 0x0290: 0604 0d01 0df6 fa04 0805 18fb f005 0f00
> ................
> > 0x02a0: 05fb 0415 01f0 f1f9 db02 0ffa f4fa ee05
> ................
> > 0x02b0: fe03 0107 f9f9 eef4 0104 f008 010b 08f7
> ................
> > 0x02c0: e218 eefb 0a06 ec10 ed01 fe11 f4fb 0ff9
> ................
> > 0x02d0: 00f2 dfff 0302 f7ea ff0d fa05 f40e fbf7
> ................
> > 0x02e0: 0b06 ff06 f903 f6fd 020f f8f0 0805 fd00
> ................
> > 0x02f0: 0105 04fc fffb f403 fdfb f502 140e f90d
> ................
> > 0x0300: 0000 1008 0050 0400 .....P..
> >
> > UHD section starts from 0x141100BB (second line).
> > Those frames are exchanged between my pc and my N210 when no
> software runs
> > (at least pc side...).
> > What are them? The dissector forces the header against them, and
> fails
> > (unknown UHD message type), but the header itself seems to be forced
> > wrongly, since casted "version" is 0x141100BB, that seems nonsense.
> > Can anyone explain me what is it and where I can find reference
> code in
> > libuhd?
> > Thanks anyone who helps.
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ??? ???????
> http://fairwaves.ru
>
>
>
>
> _______________________________________________
> 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/20130321/b74a0211/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 21 Mar 2013 23:13:56 +0400
From: Alexander Chemeris <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<cabmjbfwncpqp99wtyoxrpbjza0aav8o4hjv7fh1-wl2vf0v...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 21, 2013 at 10:24 PM, Nick Foster <[email protected]> wrote:
> Alexander, I've pulled your commit back into the master branch.
Thanks.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
------------------------------
Message: 5
Date: Thu, 21 Mar 2013 18:01:40 -0500
From: mepard <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Disturbance in the force or Glitch in the
matrix? NOT FIXED
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Mar 19, 2013, at 4:21 PM, mepard <[email protected]> wrote:
> Increasing the MTU and recv_frame_size to 4096 and the spp (samples per
> packet) to 1000 seems to prevent the dropped samples.
Turns out this wasn't the case -- it's an intermittent problem and I just got
lucky.
I looked into how the packets from the two N210s are aligned and added some
instrumentation to super_recv_packet_handler.hpp (enclosed). That's definitely
where the samples are getting dropped, but I'm still not sure what the root
cause is. In recv_packet_handler::alignment_check, I made it write a message
with the packet type when it is about to toss existing buffers due to the time.
Lost samples I see in the data correspond to these messages. I also added a
message when it (re)gains alignment. Here's what a 70-second acquisition looks
like:
_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_
The first _A_ is the initial alignment and the subsequent _A_s are when it
regains alignment after the zeros which represent dropped buffers due to a
PACKET_IF_DATA. Note there are no sequence errors. So far, that has been the
case every single time. I also added more one-letter messages for other
conditions and none of those are appearing either.
I did find one thing a little suspicious. It looks like the trick of swapping
the current and next buffer info's when returning an error could potentially
break the relationship between current and previous info's, triggering
PACKET_TIMESTAMP_ERROR, but I have not seen it actually happen.
The usual sample rate is 12.5e6 sps, which is what I used with the sequence
above. When reduced, the packet drops still occur, but it seems to take fewer
dropped packets to recover with lower sample rates.
At 3125000 sps I got this:
_A_0000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000_A_
At 390625 sps, this:
_A_0000_A_0000_A_0000_A_0000_A_
Still no sequence errors or the like.
I can understand how dropped packets from either box can cause this, but why
would it always be a multiple of 16 packets, thus avoiding a
PACKET_SEQUENCE_ERROR?
Any ideas?
-Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: super_recv_packet_handler.hpp
Type: application/octet-stream
Size: 26884 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130321/ec0bbf6d/attachment-0001.hpp>
------------------------------
Message: 6
Date: Fri, 22 Mar 2013 01:30:00 +0100
From: Damien Serant <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] Alternative USRP Ref clock frequency
Message-ID:
<CAM=tNL=bu4qoiyqy6kv-4p24geespcfvnptgrk8kbanyh3b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi list,
I'm trying to use an external ref for my usrp2 which have a frequency lower
than the required 10 Mhz (1 or 8 Mhz).
Hi read on the Gnuradio mailling list that this was possible thanks to a
modification of one line in the clock.c file of the firmware source code.
Unfortunatly this line does not appear anymore in the current version of
this file.
So, the modification is still possible and how ?
And hoppefully if somebody has already a firmware image including this
modification i would be very interested.
Thanks.
Damien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/00b38203/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 22 Mar 2013 00:21:56 -0400
From: Dan CaJacob <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] B100 Requires Power Reset
Message-ID:
<camomjobyvazoi5ss6vgjq8yrmdbc1l7+j6u4x7jvpxmmrms...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We use USRPs in a lot of remote locations. We often have flowgraphs that
run continuously and occasionally, we need to change them. The process
will often include changing the GRC file, building the python file,
stopping the running flowgraph and then starting it again. Often, the
whole process is done quickly and if not enough time is allowed between
stopping and starting the flowgraph, we get an error like that below. The
error is independent of the flowgraph and USRP. The major problem is that
this error seems to be unrecoverable, save for physically power-cycling the
USRP. That can be a problem when the hardware is on a another continent or
(depending on my energy) the other room.
We really love the Ettus hardware. Is there any way we can recover from
these errors without having to physically power cycle the units?
Thanks!
Linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.005.001-release
> Using Volk machine: avx_64_mmx
> -- USRP-B100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.000000MHz
> -- chan_rate: 320.000000MHz
> -- out_rate: 64.000000MHz
> --
> Traceback (most recent call last):
> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 216, in
> <module>
> tb = uhd_sqsdr_rx(rx_gain=options.rx_gain, dlci=options.dlci,
> rx_frequency=options.rx_frequency, rx_baud_rate=options.rx_baud_rate)
> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 82, in
> __init__
> channels=range(1),
> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> 116, in constructor_interceptor
> return old_constructor(*args)
> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 2882, in usrp_source
> return _uhd_swig.usrp_source(*args)
> RuntimeError: AssertionError: libusb_submit_transfer(_lut) == 0
> in virtual void libusb_zero_copy_mrb::release()
> at
> /root/remote_fs_root/workspace/bf2_linux-build/Slaves/Ubuntu-11.10-x86_64/uhd/host/lib/transport/libusb1_zero_copy.cpp:101
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/60edcfff/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 21 Mar 2013 23:36:20 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B100 Requires Power Reset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/21/2013 11:21 PM, Dan CaJacob wrote:
> We use USRPs in a lot of remote locations. We often have flowgraphs that
> run continuously and occasionally, we need to change them. The process
> will often include changing the GRC file, building the python file,
> stopping the running flowgraph and then starting it again. Often, the
> whole process is done quickly and if not enough time is allowed between
> stopping and starting the flowgraph, we get an error like that below. The
> error is independent of the flowgraph and USRP. The major problem is that
> this error seems to be unrecoverable, save for physically power-cycling the
> USRP. That can be a problem when the hardware is on a another continent or
> (depending on my energy) the other room.
>
So, at some point, you get this error when opening a device session:
libusb_submit_transfer(_lut), and it just consistently does that forever
until power cycle?
Is the flowgraph nicely stopped or is it killed? Just curious.
I think the best hope of recovery, because I havent seen this, is to get
the firmware to reload. Now, the software is being smart and only
reloading firmware when its 1) not loaded or 2) the hex file has a
different hash.
So, if you were to copy usrp_b100_fw.hex, and add a teensy extra byte to
the end of the file. And then run uhd_usrp_probe
--args="fw=/path/to/new_usrp_b100_fw.hex" Then this should cause the
driver to reload fw.
If thats whats going to unstick it from this situation, I can add a
better hook to do so. AFAIK, the driver is resetting all it can when the
session is opened every time, without resetting the fw and causing a
device renumeration... so this reload is a still bigger hammer.
-josh
> We really love the Ettus hardware. Is there any way we can recover from
> these errors without having to physically power cycle the units?
>
> Thanks!
>
> Linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.005.001-release
>> Using Volk machine: avx_64_mmx
>> -- USRP-B100 clock control: 10
>> -- r_counter: 2
>> -- a_counter: 0
>> -- b_counter: 20
>> -- prescaler: 8
>> -- vco_divider: 5
>> -- chan_divider: 5
>> -- vco_rate: 1600.000000MHz
>> -- chan_rate: 320.000000MHz
>> -- out_rate: 64.000000MHz
>> --
>> Traceback (most recent call last):
>> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 216, in
>> <module>
>> tb = uhd_sqsdr_rx(rx_gain=options.rx_gain, dlci=options.dlci,
>> rx_frequency=options.rx_frequency, rx_baud_rate=options.rx_baud_rate)
>> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 82, in
>> __init__
>> channels=range(1),
>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>> 116, in constructor_interceptor
>> return old_constructor(*args)
>> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>> 2882, in usrp_source
>> return _uhd_swig.usrp_source(*args)
>> RuntimeError: AssertionError: libusb_submit_transfer(_lut) == 0
>> in virtual void libusb_zero_copy_mrb::release()
>> at
>> /root/remote_fs_root/workspace/bf2_linux-build/Slaves/Ubuntu-11.10-x86_64/uhd/host/lib/transport/libusb1_zero_copy.cpp:101
>
>
>
> Very Respectfully,
>
> Dan CaJacob
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Fri, 22 Mar 2013 10:19:18 +0100
From: Dario Lombardo <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<caoyjjftb-jctdtkaw-t8dqtvfsel8uqt41jprfcsv3tsv8j...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Mar 21, 2013 at 7:24 PM, Nick Foster <[email protected]> wrote:
> The VRT dissector is not quite complete although it should work for most
> uses. The parts of the protocol used by the N210 should be fully dissected;
> however, IF context packets and other minutiae in the protocol have not
> been implemented. I don't know the Wireshark community's standards
> regarding dissector completeness, but just FYI.
>
I think that a partial decode is better than nothing. Newer support will be
added in the future. I will update you with news from wireshark community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/a7a87b33/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 22 Mar 2013 11:14:24 -0400
From: Dan CaJacob <[email protected]>
To: Josh Blum <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B100 Requires Power Reset
Message-ID:
<camomjod9mnrwp3o33aa2svbqsy6k9fr5z_-ya260xyab9j0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the quick response, Josh! Your suggestion seems to fix the
problem. See my other answers below.
On Fri, Mar 22, 2013 at 12:36 AM, Josh Blum <[email protected]> wrote:
>
>
> On 03/21/2013 11:21 PM, Dan CaJacob wrote:
> > We use USRPs in a lot of remote locations. We often have flowgraphs that
> > run continuously and occasionally, we need to change them. The process
> > will often include changing the GRC file, building the python file,
> > stopping the running flowgraph and then starting it again. Often, the
> > whole process is done quickly and if not enough time is allowed between
> > stopping and starting the flowgraph, we get an error like that below.
> The
> > error is independent of the flowgraph and USRP. The major problem is
> that
> > this error seems to be unrecoverable, save for physically power-cycling
> the
> > USRP. That can be a problem when the hardware is on a another continent
> or
> > (depending on my energy) the other room.
> >
>
> So, at some point, you get this error when opening a device session:
> libusb_submit_transfer(_lut), and it just consistently does that forever
> until power cycle?
>
That is correct. Any subsequent try to access the affected USRP gives the
same error until a power cycle of the unit.
>
> Is the flowgraph nicely stopped or is it killed? Just curious.
>
I think the flowgraph is always killed. I have seen the problem in all
three ways that I kill flowgraphs:
1. Ctrl-C from the command line on a running py file
2. sudo service [name] stop on a daemonized flowgraph we are running (I
think that just kills it rather than stop, unfortunately)
3. In GRC, clicking the red "Kill the flowgraph" button (does this use
stop? Besides this particular case, this button has always seemed to be
the safest way to kill flowgraphs.)
> I think the best hope of recovery, because I havent seen this, is to get
> the firmware to reload. Now, the software is being smart and only
> reloading firmware when its 1) not loaded or 2) the hex file has a
> different hash.
>
> So, if you were to copy usrp_b100_fw.hex, and add a teensy extra byte to
> the end of the file. And then run uhd_usrp_probe
> --args="fw=/path/to/new_usrp_b100_fw.hex" Then this should cause the
> driver to reload fw.
>
That definitely worked!
>
> If thats whats going to unstick it from this situation, I can add a
> better hook to do so. AFAIK, the driver is resetting all it can when the
> session is opened every time, without resetting the fw and causing a
> device renumeration... so this reload is a still bigger hammer.
>
> -josh
>
>
> > We really love the Ettus hardware. Is there any way we can recover from
> > these errors without having to physically power cycle the units?
> >
> > Thanks!
> >
> > Linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.005.001-release
> >> Using Volk machine: avx_64_mmx
> >> -- USRP-B100 clock control: 10
> >> -- r_counter: 2
> >> -- a_counter: 0
> >> -- b_counter: 20
> >> -- prescaler: 8
> >> -- vco_divider: 5
> >> -- chan_divider: 5
> >> -- vco_rate: 1600.000000MHz
> >> -- chan_rate: 320.000000MHz
> >> -- out_rate: 64.000000MHz
> >> --
> >> Traceback (most recent call last):
> >> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 216, in
> >> <module>
> >> tb = uhd_sqsdr_rx(rx_gain=options.rx_gain, dlci=options.dlci,
> >> rx_frequency=options.rx_frequency, rx_baud_rate=options.rx_baud_rate)
> >> File "/home/spacequest/Desktop/sq-ant/uhd_sqsdr_rx.py", line 82, in
> >> __init__
> >> channels=range(1),
> >> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> >> 116, in constructor_interceptor
> >> return old_constructor(*args)
> >> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> >> 2882, in usrp_source
> >> return _uhd_swig.usrp_source(*args)
> >> RuntimeError: AssertionError: libusb_submit_transfer(_lut) == 0
> >> in virtual void libusb_zero_copy_mrb::release()
> >> at
> >>
> /root/remote_fs_root/workspace/bf2_linux-build/Slaves/Ubuntu-11.10-x86_64/uhd/host/lib/transport/libusb1_zero_copy.cpp:101
> >
> >
> >
> > Very Respectfully,
> >
> > Dan CaJacob
> >
> >
> >
> > _______________________________________________
> > 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/20130322/552fe0b1/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 31, Issue 21
******************************************
