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: Thread AssertionError and Libc++abi.dylib on Mac
Transmissions (Tor Andre Myrvoll)
2. Re: Thread AssertionError and Libc++abi.dylib on Mac
Transmissions (David Greene)
3. Re: B100 no longer detected (Marcus D. Leech)
4. Re: B100 no longer detected (Marcus D. Leech)
5. Re: B100 no longer detected (James Balnaves)
6. digital hopping (Nuria Ibrahim)
7. UHD device in Windows (Luong Tan Phong)
8. tune time for N210 (gang li)
9. Re: digital hopping (Nick Foster)
10. Re: Thread AssertionError and Libc++abi.dylib on Mac
Transmissions (David Greene)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Jan 2013 18:10:32 +0100
From: Tor Andre Myrvoll <[email protected]>
To: David Greene <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Thread AssertionError and Libc++abi.dylib on
Mac Transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
15. jan. 2013 kl. 15:38 skrev David Greene <[email protected]>:
> "
>> but I see that you use the same release of OS X as me, 10.8.2
> "
>
> Tor, what version of boost and compiler are you using for UHD? Could you send
> me the startup info when you begin a UHD application, say uhd_fft for example:
>
> Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
> 2336.11.00); Boost_105100; UHD_003.005.000-0-unkown
This is my output (Note, I build uhd from the git checkout, not using the
MacPorts version) :
emphaticmac:build$examples/tx_waveforms --args="addr0=192.168.10.2" --rate 5e6
--wave-freq 1e6 --wave-type SINE --freq 400e6 --ampl 1.0 --ant "TX/RX" --ref
external
Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66)); Boost_105200;
UHD_003.005.000-26-gb65a3924
As for your alternative installation procedure - I can make the exception go
away by inserting a simple std::cout before send() in tx_waveform, or just
compiling with debug support. So I am not sure if doing what you do really
fixes anything as the "fix" here may just be some suble timing issue. Have you
run your setup for an extensive period of time, say 24 hours? If your program
gets past the initial few send()s it may go on for hours without issues in my
experience.
--
- Tor Andre
------------------------------
Message: 2
Date: Tue, 15 Jan 2013 14:00:52 -0500
From: David Greene <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Thread AssertionError and Libc++abi.dylib on
Mac Transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> I build uhd from the git checkout, not using the MacPorts version
I'll give the git version a shot and see how it goes, as well as Josh's
patch.
> Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66));
> Boost_105200; UHD_003.005.000-26-gb65a3924
I'm on boost 1.51, don't think it'll make a difference in your case:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00079.html
> So I am not sure if doing what you do really fixes anything as the
> "fix" here may just be some suble timing issue.
You're probably right, I was just hoping it was a compilation or
dependency issue on the mac.
> Have you run your setup for an extensive period of time, say 24 hours?
> If your program gets past the initial few send()s it may go on for
> hours without issues in my experience.
Yes, certain programs have no trouble transmitting and they run on and
on. I'll try leaving them going overnight to see if I encounter any issues.
-David
------------------------------
Message: 3
Date: Tue, 15 Jan 2013 16:53:32 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B100 no longer detected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 01/15/2013 12:07 AM, James Balnaves wrote:
> I tried it in another port that I'm sure is USB 2.0 and I get exactly the
> same behavior, except that the error message now refers to ehci_hcd.
> I wonder if it's possible that the EEPROM got corrupted somehow when I tried
> to install the windows USB driver?
It's conceivable that *something* tried to overwrite the boot EEPROM on
your USRP-B100.
When you say "windows USB drivers", to what are you referring? UHD uses
the libusb port for Windows as far as I know, and doesn't require
any Windows drivers, as such.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Tue, 15 Jan 2013 17:08:21 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B100 no longer detected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> I tried it in another port that I'm sure is USB 2.0 and I get exactly the
> same behavior, except that the error message now refers to ehci_hcd.
> I wonder if it's possible that the EEPROM got corrupted somehow when I tried
> to install the windows USB driver?
>
>
Also, could you show us the output of 'lsusb' when it's plugged in?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 5
Date: Tue, 15 Jan 2013 16:33:04 -0800
From: James Balnaves <[email protected]>
To: Marcus D. Leech <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B100 no longer detected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I had run Zadig as part of the ExtIO_USRP setup for use with HDSDR, but it
never showed up as a device so it's probably not related.
Thanks everyone for the insightful suggestions, I've sent the unit in for an
official diagnosis.
Regards, James.
On Jan 15, 2013, at 1:53 PM, Marcus D. Leech wrote:
> On 01/15/2013 12:07 AM, James Balnaves wrote:
>> I tried it in another port that I'm sure is USB 2.0 and I get exactly the
>> same behavior, except that the error message now refers to ehci_hcd.
>> I wonder if it's possible that the EEPROM got corrupted somehow when I tried
>> to install the windows USB driver?
> It's conceivable that *something* tried to overwrite the boot EEPROM on your
> USRP-B100.
>
> When you say "windows USB drivers", to what are you referring? UHD uses the
> libusb port for Windows as far as I know, and doesn't require
> any Windows drivers, as such.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Tue, 15 Jan 2013 23:18:46 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: [email protected]
Subject: [USRP-users] digital hopping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear Josh
I have been reading the two-stage usrp
tuning process to see what I was missing in my implementation of
digital hopping and I found out from one of your replay on the same
topic, that I have to set the dsp-policy to Manual and it works well
here is the code:
float LO_freuqncy=936.4e6; %beacon
frequency
usrp->set_rx_freq(LO_freuqncy);
%tune to beacon frequency
.
.
. %and do
synchronization
while(true)
{
.
.
.
arfcn=MAList[MAIO];
if(arfcn>=1 &&
arfcn<=124)
{
hope_freq=(935+ .2*arfcn)*1e6 ;
}
%hopping from cord
uhd::tune_request_t
tune_req(LO_freuqncy);
tune_req.rf_freq_policy=uhd::tune_request_t::POLICY_NONE;%this leaves
LO fixed
tune_req.dsp_freq_policy=
uhd::tune_request_t::POLICY_MANUAL;
tune_req.dsp_freq =
LO_freuqncy-hope_freq;
uhd::tune_result_t tune_res =
usrp->set_rx_freq(tune_req);
std::string tune_res_out =
tune_res.to_pp_string();
cout<<"tune_res_out
"<<tune_res_out<<endl;
usrp->get_rx_freq();%returns hope_freq as over_all RX frequency
-expected
}
Thanks a lot!
I have question regading continuous
streaming,while doing digital hopping
Q. when we say the usrp needs time to
settle before starting streaming data, I think we are referring to
the daughter board,if so does it mean there is no such issue if the
tunning is from the Cord/DSP and if the streaming is continuous we
don`t have to discard samples while processing to avoid garbage data?
Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130115/ae93755c/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 16 Jan 2013 05:54:44 -0800
From: Luong Tan Phong <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD device in Windows
Message-ID:
<caa8yxsrncrjmlhtz+2qza4jywptkb_e12gq+ysbnpstnwag...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I installed UHD and Gnuradio latest version (binaries download from
http://files.ettus.com/, 09-Jan-2013) in Windows. My application base on
C++, boost 1.47 (flow graph: uhd source -> Fft) is OK when I call
gr_top_block->start(); stop(), wait(). The error "thread[thread-per-block[0]:
<gr_block gr uhd usrp source (1)>]: ValueError: bad vrt header or packet
fragment" show on console when I call gr_top_block->start() (after stop(),
wait() functions). The application is OK on Ubuntu.
Could you help me to solve the issue, please?
Thank you.
Best regrads,
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130116/1fa11db3/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 16 Jan 2013 10:39:35 -0500
From: gang li <[email protected]>
To: [email protected]
Subject: [USRP-users] tune time for N210
Message-ID:
<CAKro2L2jQpzthuhKsy2cUn=yO9Z_UP0uzK+NB7O=tdacfbt...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi, all,
Does someone know how long it takes to tune the frequency and lock the
LO in N210 with SBX? I saw some discussions here but i couldnt find
them. Thanks.
Best,
Gang
------------------------------
Message: 9
Date: Wed, 16 Jan 2013 08:00:24 -0800
From: Nick Foster <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] digital hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 01/15/2013 11:18 PM, Nuria Ibrahim wrote:
>
> Dear Josh
>
> I have been reading the two-stage usrp tuning process to see what I
> was missing in my implementation of digital hopping and I found out
> from one of your replay on the same topic, that I have to set the
> dsp-policy to Manual and it works well here is the code:
>
> <snip>
>
> Thanks a lot!
>
> I have question regading continuous streaming,while doing digital hopping
>
> Q. when we say the usrp needs time to settle before starting streaming
> data, I think we are referring to the daughter board,if so does it
> mean there is no such issue if the tunning is from the Cord/DSP and if
> the streaming is continuous we don`t have to discard samples while
> processing to avoid garbage data?
>
That's correct. The settling time refers to the VCO on the daughterboard.
--n
>
>
> Thanks in advance!
>
>
>
>
> _______________________________________________
> 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/20130116/29c14938/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 16 Jan 2013 11:55:51 -0500
From: David Greene <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Thread AssertionError and Libc++abi.dylib on
Mac Transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> So here is my updated patch. I am going to test that this hasn't broke
> anything under linux, and then I can get it into mainline and a patch
> release.
>
> http://pastebin.com/YtMu0xj5
>
> -josh
Success!
I removed the MacPorts install, grabbed the latest version from the
repository and made your suggested changes. Everything is running great
now, as it seems my previous "Ulibc++abi.dylib: terminate called without
an active exception" was also related to this.
Thank you Josh and Tor for your help.
-David
------------------------------
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 29, Issue 16
******************************************
