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: Burst Error in USRP2 (Amith Khandakar)
2. Re: Problems with Tx-MIMO (Tor Andre Myrvoll)
3. Multiple IP Addresses Break MATLAB SDRU Package (Volkan YAZICI)
4. Re: Multiple IP Addresses Break MATLAB SDRU Package (Ethem Sozer)
5. Re: Simulation round_sd.v module block encounters errors
(Florian Schlembach)
6. App hangs after upgrade (Per Zetterberg)
7. USRP N210 revision? (Per Zetterberg)
8. Re: USRP N210 revision? (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Jan 2013 08:20:09 +0000
From: Amith Khandakar <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Burst Error in USRP2
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear all
Can you please tell me how to solve the following Error when ever USRP 2 (XCVR
2450 daughter board and software interface with simulink) is transmitting:
Could not execute UHD driver command in
'sendData_c': tx send error: sequence error in Burst.
Thank you in advance.
Regards
Amith khandakar
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, December 27, 2012 8:00 PM
To: [email protected]
Subject: USRP-users Digest, Vol 28, Issue 22
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: (no subject) (Farhad Abdolian)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Dec 2012 17:17:26 -0800 (PST)
From: Farhad Abdolian <[email protected]>
To: Farhad Abdolian <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] (no subject)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I am very sorry, but my account was hacked last week. This is a hack site
>________________________________
> From: Farhad Abdolian <[email protected]>
>To: [email protected]; [email protected]; [email protected];
>[email protected]
>Sent: Friday, December 21, 2012 4:49 PM
>Subject:
>
>
>http://carleenzimbalatti.com/wp-content/themes/Envisioned/mypage.php?th
>ee287.img
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121226/6fd78010/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 28, Issue 22
******************************************
------------------------------
Message: 2
Date: Mon, 7 Jan 2013 11:16:21 +0100
From: Tor Andre Myrvoll <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi all,
I've had some time to investigate the problem, and it seems to boil down to the
following:
On OS X (and FreeBSD in general), send is non-blocking when UDP sockets are
used, and the same goes for select. See
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=167319+0+/usr/local/www/db/text/2004/freebsd-hackers/20040125.freebsd-hackers
for more information on this.
This means that the following code in udp_zero_copy.cpp may (and indeed do)
fail at some point:
class udp_zero_copy_asio_msb : public managed_send_buffer{
public:
udp_zero_copy_asio_msb(void *mem, int sock_fd, const size_t frame_size):
_mem(mem), _sock_fd(sock_fd), _frame_size(frame_size) { /*NOP*/ }
void release(void){
UHD_ASSERT_THROW(::send(_sock_fd, (const char *)_mem, size(), 0) ==
ssize_t(size()));
_claimer.release();
}
UHD_INLINE sptr get_new(const double timeout, size_t &index){
if (not _claimer.claim_with_wait(timeout)) return sptr();
index++; //advances the caller's buffer
return make(this, _mem, _frame_size);
}
private:
void *_mem;
int _sock_fd;
size_t _frame_size;
simple_claimer _claimer;
};
I've made a small modification that seems to work for me at the moment. I am no
network programming expert, so improvements are welcome.
class udp_zero_copy_asio_msb : public managed_send_buffer{
public:
udp_zero_copy_asio_msb(void *mem, int sock_fd, const size_t frame_size):
_mem(mem), _sock_fd(sock_fd), _frame_size(frame_size) { /*NOP*/ }
void release(void){
// Quick and dirty fix for the ENOBUFS problem on OS X (and FreeBSD in
general)
// The problem is that send is non-blocking on UDP (as is select).
Thus, we need to catch the error and wait if needed
ssize_t sent = ::send(_sock_fd, (const char *)_mem, size(), 0);
while(errno == ENOBUFS){
usleep(1);
sent = ::send(_sock_fd, (const char *)_mem, size(), 0);
}
UHD_ASSERT_THROW(sent == ssize_t(size()));
_claimer.release();
}
UHD_INLINE sptr get_new(const double timeout, size_t &index){
if (not _claimer.claim_with_wait(timeout)) return sptr();
index++; //advances the caller's buffer
return make(this, _mem, _frame_size);
}
private:
void *_mem;
int _sock_fd;
size_t _frame_size;
simple_claimer _claimer;
};
On another note, I wonder why you are using native file descriptors (int
_sock_fd) instead of the boost::asio sockets? I don't know if the boost::asio
implementation would address this issue, but I am still curious about your
motivation.
Cheers,
--
- Tor
6. des. 2012 kl. 20:14 skrev Josh Blum <[email protected]>:
>
>
> On 12/06/2012 09:33 AM, Tor Andre Myrvoll wrote:
>> Hi,
>>
>> I am trying to setup a simple 2x2 MIMO system using four N210 USRPs.
>> They are connected pairwise with MIMO cables, and the master of both
>> pairs have an external 10 MHz reference clock. The daughterboards are
>> XCVR2450s.
>>
>> I am running the latest UHD under OS X 10.8.2.
>>
>> When trying to run my code (based on tx_waveform.cpp and attached at
>> the end of the email), I get the following:
>>
>> Katsuo:GNURadio$TxMIMO --rate 1e6 --wave-freq 100e3 --wave-type SINE
>> --freq 2450e6 --ampl 1.0 --ant J1 Mac OS; Clang version 4.1
>> ((tags/Apple/clang-421.11.66)); Boost_105200;
>> UHD_003.005.000-26-gb65a3924
>>
>>
>> -- Opening a USRP2/N-Series device... -- Current recv frame size:
>> 1472 bytes -- Current send frame size: 1472 bytes Using Device: Multi
>> USRP: Device: USRP2 / N-Series Device Mboard 0: N210 Mboard 1: N210
>> RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: XCVR2450 RX RX
>> Channel: 1 RX DSP: 0 RX Dboard: A RX Subdev: XCVR2450 RX TX Channel:
>> 0 TX DSP: 0 TX Dboard: A TX Subdev: XCVR2450 TX TX Channel: 1 TX DSP:
>> 0 TX Dboard: A TX Subdev: XCVR2450 TX
>>
>> Setting TX Rate: 1.000000 Msps... Actual TX Rate: 1.000000 Msps...
>>
>> Setting TX Freq: 2450.000000 MHz... Actual TX Freq: 2450.000000
>> MHz...
>>
>> Setting TX Freq: 2450.000000 MHz... Actual TX Freq: 2450.000000
>> MHz...
>>
>> Setting device timestamp to 0... Checking TX: LO: locked ... Checking
>> TX: LO: locked ... Checking TX: Ref: locked ... Checking TX: MIMO:
>> locked ... Press Ctrl + C to stop streaming... LLLLLLLLLLLLLL UHD
>> Error: An unexpected exception was caught in a task loop. The task
>> loop will now exit, things may not work. AssertionError:
>> ::send(_sock_fd, (const char *)_mem, size(), 0) == ssize_t(size()) in
>> virtual void udp_zero_copy_asio_msb::release() at
>> /Users/myrvoll/CompilePit/uhd/host/lib/transport/udp_zero_copy.cpp:115
>>
>>
>
>
> Can you tell me this. Does the single channel case work ok for you?
>
> Also, that set clock config stuff is deprecated. I would try to sync the
> devices like this:
>
> usrp->set_time_source("mimo", 0); //device 0 syncs time over mimo cable
> usrp->set_clock_source("mimo", 0); //device 0 syncs ref clock over mimo
> cable
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 7 Jan 2013 14:03:27 +0200
From: Volkan YAZICI <[email protected]>
To: [email protected]
Subject: [USRP-users] Multiple IP Addresses Break MATLAB SDRU Package
Message-ID:
<CAP7pH7tt=crqj5hgj5qxkgey8ppj5ugpkfnsy_thzbz9a52...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi!
In the result of "findsdru" command, we observe multiple (two) IP addresses
for each device. Consider the below network.
H1 [eth0]
|
|10.100.92.17/24
|192.168.10.17/24
|
+
Unmanaged +---------- 192.168.10.201 -- USRP2
Switch +---------- 192.168.10.202 -- USRP2
+
|
|10.100.92.18/24
|192.168.10.18/24
|
H2 [eth0]
Here USRP2 devices are installed usrp2_fw.bin and usrp2_fpga.bin bundled
with uhd-images_003.005.000-release.zip archive. H1 and H2 run MATLAB
R2011b with USRP? Hardware Binary Release
003.002.003<http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.002.003-release/images-only/>installed.
When I type findsdru at the MATLAB command prompt it tells me
that
>> findsdru
linux; GNU C++ version 4.3.4; Boost_104400; UHD_003.002.003-vendor
---------- see libuhd version information above this line ----------
ans =
192.168.10.202,192.168.10.201,192.168.10.201,192.168.10.202
Per see, it observes multiple IP addresses from each device. Further, when
I try to run a simple demo bundled with the SDRU package it fails as
follows.
>> sdruFMStereoReceiver
stereoFM =
AudioSampleRate: 48000
USRPDecimationFactor: 500
FrameLength: 4000
USRPGain: 30
RCDemodInterpFactor: 19
RCDemodDecimFactor: 25
RCDemodNumerator: [1x600 double]
FsData: 152000
peak19fil: [1x1 dfilt.df2sos]
RCAudioInterpFactor: 6
RCAudioDecimFactor: 19
LP15k: [1x501 double]
Deemp: [1x1 dfilt.df2sos]
StopTime: 10
AudioFrameTime: 0.0200
Error using StringSet.checkValues (line 119)
Strings must be case-insensitive unique.
Error in
/usr/local/MATLAB/R2011b/toolbox/shared/system/+matlab/+system/StringSet.p>StringSet.setValues
(line 101)
Error in
/usr/local/MATLAB/R2011b/toolbox/shared/system/+matlab/+system/StringSet.p>StringSet.changeValues
(line 89)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/+internal/SDRuBase.p>SDRuBase.updateIPAddressSet
(line 615)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/+internal/SDRuBase.p>SDRuBase.SDRuBase
(line 146)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/SDRuReceiver.p>SDRuReceiver.SDRuReceiver
(line 185)
Error in sdruFMStereoReceiver (line 137)
hSDRu = comm.SDRuReceiver('192.168.10.202', ...
Any ideas? What might be going wrong? How can I fix the problem?
Best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130107/43aa11f9/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 7 Jan 2013 14:25:26 +0000
From: Ethem Sozer <[email protected]>
To: Volkan YAZICI <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Multiple IP Addresses Break MATLAB SDRU
Package
Message-ID:
<93d53efe258f7b40996b3005458c751d1cbf3...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Volkan,
This problem is fixed in 12a. Also, please make sure that the UHD version on
the radio matches the MATLAB required UHD version.
Regards,
Ethem
From: USRP-users [mailto:[email protected]] On Behalf Of
Volkan YAZICI
Sent: Monday, January 07, 2013 7:03 AM
To: [email protected]
Subject: [USRP-users] Multiple IP Addresses Break MATLAB SDRU Package
Hi!
In the result of "findsdru" command, we observe multiple (two) IP addresses for
each device. Consider the below network.
H1 [eth0]
|
|10.100.92.17/24<http://10.100.92.17/24>
|192.168.10.17/24<http://192.168.10.17/24>
|
+
Unmanaged +---------- 192.168.10.201 -- USRP2
Switch +---------- 192.168.10.202 -- USRP2
+
|
|10.100.92.18/24<http://10.100.92.18/24>
|192.168.10.18/24<http://192.168.10.18/24>
|
H2 [eth0]
Here USRP2 devices are installed usrp2_fw.bin and usrp2_fpga.bin bundled with
uhd-images_003.005.000-release.zip archive. H1 and H2 run MATLAB R2011b with
USRP(r) Hardware Binary Release
003.002.003<http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.002.003-release/images-only/>
installed. When I type findsdru at the MATLAB command prompt it tells me that
>> findsdru
linux; GNU C++ version 4.3.4; Boost_104400; UHD_003.002.003-vendor
---------- see libuhd version information above this line ----------
ans =
192.168.10.202,192.168.10.201,192.168.10.201,192.168.10.202
Per see, it observes multiple IP addresses from each device. Further, when I
try to run a simple demo bundled with the SDRU package it fails as follows.
>> sdruFMStereoReceiver
stereoFM =
AudioSampleRate: 48000
USRPDecimationFactor: 500
FrameLength: 4000
USRPGain: 30
RCDemodInterpFactor: 19
RCDemodDecimFactor: 25
RCDemodNumerator: [1x600 double]
FsData: 152000
peak19fil: [1x1 dfilt.df2sos]
RCAudioInterpFactor: 6
RCAudioDecimFactor: 19
LP15k: [1x501 double]
Deemp: [1x1 dfilt.df2sos]
StopTime: 10
AudioFrameTime: 0.0200
Error using StringSet.checkValues (line 119)
Strings must be case-insensitive unique.
Error in
/usr/local/MATLAB/R2011b/toolbox/shared/system/+matlab/+system/StringSet.p>StringSet.setValues
(line 101)
Error in
/usr/local/MATLAB/R2011b/toolbox/shared/system/+matlab/+system/StringSet.p>StringSet.changeValues
(line 89)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/+internal/SDRuBase.p>SDRuBase.updateIPAddressSet
(line 615)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/+internal/SDRuBase.p>SDRuBase.SDRuBase
(line 146)
Error in
/usr/local/MATLAB/usrp/out/commusrp/+comm/SDRuReceiver.p>SDRuReceiver.SDRuReceiver
(line 185)
Error in sdruFMStereoReceiver (line 137)
hSDRu = comm.SDRuReceiver('192.168.10.202', ...
Any ideas? What might be going wrong? How can I fix the problem?
Best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130107/96f362d3/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 07 Jan 2013 16:25:35 +0100
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: "[email protected]"
<[email protected]>, Florian
Schlembach
<[email protected]>
Subject: Re: [USRP-users] Simulation round_sd.v module block
encounters errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> To get it to simulate properly, set the initial values of the registers
> where they are defined, like this:
>
> reg [15:0] myreg = 0;
>
> Matt
>
Matt, for sure thats right. Actually, considering the example of
round_sd.v it is not obvious to me where the register err gets any
value? It is initialized in line 13 but no value is assigned?
See
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/sdr_lib/round_sd.v
If err_ext should be inserted into module add2_and_clip_reg in line 19,
how is err_ext being calculated via the macro sign_extend in line 16?
To me, it seems that the sign_extend module instantiation is redundant here?
------------------------------
Message: 6
Date: Mon, 7 Jan 2013 15:28:02 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] App hangs after upgrade
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Josh and List,
I have a little app that grabs samples from multiple USRPs. It works with 4
USRPs and it used to work with 6 USRPs. In a sense it still works with 6 USRPs
but it won't exit. The decimation factor doesn't seem to matter.
Previously I was using commit 50073e54b5bee27d361fba3c915be3b27c84e3b7 (Mon Aug
29 18:56:44 2011 -0700) now I am using release_003_005_000. Below is a code
snippet. The app does print "Done!" and the data written to file seems to be
valid for all 6 USRPs. It's just that the program won't exit.
BR/
Per
===== snippet start ========
uhd::rx_metadata_t md_rx;
unsigned int num_rx_samps=0;
while (num_rx_samps==0) {
num_rx_samps=dev->recv(
d_rx_buffers,
total_num_samps,
md_rx,
uhd::io_type_t::COMPLEX_INT16,
uhd::device::RECV_MODE_FULL_BUFF
);
};
std::cout << std::endl << "save on disc!" << std::endl << std::endl;
// Save output to disc
std::ofstream s1(filename.c_str(), std::ios::binary);
for (uint32_t i1=0;i1<no_chan;i1++) {
d_buffer_rx = (std::complex<short int>*) d_rx_buffers[i1];
s1.write((char *) d_buffer_rx ,4*total_num_samps); //ZP
};
s1.flush();
s1.close();
//finished
std::cout << std::endl << "Done!" << std::endl << std::endl; //
===== snippet stop ========
------------------------------
Message: 7
Date: Mon, 7 Jan 2013 15:35:28 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP N210 revision?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi List,
I have a USRP N210. It seems to say "r:2.0" on the back side which I interpret
as revision 2. However, the usrp_n2xx_net_burner.py tool says "Hardware type:
n210_r3". What should I assume ?
BR/
Per
------------------------------
Message: 8
Date: Mon, 07 Jan 2013 10:42:37 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 revision?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi List,
>
> I have a USRP N210. It seems to say "r:2.0" on the back side which I
> interpret as revision 2. However, the usrp_n2xx_net_burner.py tool says
> "Hardware type: n210_r3". What should I assume ?
>
> BR/
> Per
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
From the firmware/FPGA perspective, R3 and R2 are the same.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
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 7
*****************************************
