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: App hangs after upgrade (Josh Blum)
2. Re: Problems with Tx-MIMO (Josh Blum)
3. Re: Problems with Tx-MIMO (Marcus D. Leech)
4. Re: App hangs after upgrade (Per Zetterberg)
5. Re: App hangs after upgrade (Josh Blum)
6. Re: Problems with Tx-MIMO (Tor Andre Myrvoll)
7. Re: USRP1 support in the form of a network server (Simon IJskes)
----------------------------------------------------------------------
Message: 1
Date: Mon, 07 Jan 2013 12:06:54 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] App hangs after upgrade
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/07/2013 09:28 AM, Per Zetterberg wrote:
> 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.
So UHD switched to this streamer API several releases ago. And I think
you ran into the corner case of the backwards compatibility for the old
send/recv calls. The act of calling recv() is creating a new streamer
and shutting of the DSP and any enqueued stream commands
* try making a dummy call to dev->recv with
uhd::io_type_t::COMPLEX_INT16 before issuing the stream command
or * use the streamer api, many examples in host/examples
-josh
>
> 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 ========
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Mon, 07 Jan 2013 12:38:41 -0600
From: Josh Blum <[email protected]>
To: Tor Andre Myrvoll <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/07/2013 04:16 AM, Tor Andre Myrvoll wrote:
> 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:
>
So what I am gathering. send() is returning ENOBUFS, but its a condition
you cant select() for. The other oddity is that there technically should
always be enough buffer space. There is a point to point flow control
between host and USRP DSP that prevents the host from overflowing the
USRP's buffering. The socket send buffer is also resized to match. OK,
well good to know
It seems the fix would be to loop on fail and retry the send?
>
>
> 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; };
>
>
I wonder if freebsd has something similar to TEMP_FAILURE_RETRY that
would conveniently do this:
https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Interrupted-Primitives.html
>
> 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.
>
asio was very helpful to be cross platform at creating the sockets.
Since I wasnt really using the asynchronous stuff, I just pulled out the
socket descriptors and used send() and recv(). Not sure what the asio
wrappers around the synchronous send and recv might offer. Hopefully I
am avoiding extra complications and not causing them... does the asio
socket->send() call handle the error + retry on freebsd?
-josh
>
> 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, 07 Jan 2013 13:55:35 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> So what I am gathering. send() is returning ENOBUFS, but its a condition
> you cant select() for. The other oddity is that there technically should
> always be enough buffer space. There is a point to point flow control
> between host and USRP DSP that prevents the host from overflowing the
> USRP's buffering. The socket send buffer is also resized to match. OK,
> well good to know
>
> It seems the fix would be to loop on fail and retry the send?
>
I agree that there should never be a situation in which you should get
ENOBUFS back, unless the MAC-layer flow-control
logic is being used, and that state machine is getting into a bad
state. Since UDP is not an ACKed protocol, the only time
you should run into trouble is when you're consisently vastly
exceeding the GiGe ports ability to "keep up", to the point where
the protocol-stacks buffers are in danger of becoming exhausted. In
Linux, the kernel just puts you to sleep for a while until
buffer space becomes available. In BSD, maybe it doesn't do that,
but even for blocking sockets, returns an ENOBUFS?
>>
>> 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; };
>>
>>
> I wonder if freebsd has something similar to TEMP_FAILURE_RETRY that
> would conveniently do this:
>
> https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Interrupted-Primitives.html
>
>> 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.
>>
>
> asio was very helpful to be cross platform at creating the sockets.
> Since I wasnt really using the asynchronous stuff, I just pulled out the
> socket descriptors and used send() and recv(). Not sure what the asio
> wrappers around the synchronous send and recv might offer. Hopefully I
> am avoiding extra complications and not causing them... does the asio
> socket->send() call handle the error + retry on freebsd?
>
> -josh
>
>> 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
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Mon, 7 Jan 2013 21:08:55 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] App hangs after upgrade
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks Josh.
I will try to update my code to the streamer API. A few questions:
* Should all transmissions be done using streamers. Even very short ones?
* Previously one could set the buffer size when creating multi_usrp objects by
use of the device address as e.g. dev_addr["recv_buff_size"]=100. Is this now
obsolete?
* For the send command one could use an option SEND_MODE_FULL_BUFF, is this
also obsolete?
* How long does it take to create a streamer object ?
* Can I have multiple streamer objects open to one multi_usrp object and
alternate between them?
BR/
Per
________________________________________
From: USRP-users [[email protected]] on behalf of Josh Blum
[[email protected]]
Sent: Monday, January 07, 2013 7:06 PM
To: [email protected]
Subject: Re: [USRP-users] App hangs after upgrade
On 01/07/2013 09:28 AM, Per Zetterberg wrote:
> 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.
So UHD switched to this streamer API several releases ago. And I think
you ran into the corner case of the backwards compatibility for the old
send/recv calls. The act of calling recv() is creating a new streamer
and shutting of the DSP and any enqueued stream commands
* try making a dummy call to dev->recv with
uhd::io_type_t::COMPLEX_INT16 before issuing the stream command
or * use the streamer api, many examples in host/examples
-josh
>
> 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 ========
>
> _______________________________________________ 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
------------------------------
Message: 5
Date: Mon, 07 Jan 2013 17:31:56 -0600
From: Josh Blum <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] App hangs after upgrade
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/07/2013 03:08 PM, Per Zetterberg wrote:
>
> Thanks Josh.
>
> I will try to update my code to the streamer API. A few questions:
>
> * Should all transmissions be done using streamers. Even very short ones?
Its not about how much data you have to send. Its just that there is
this API where a channel or group of channels is associated with a
streamer object, which is used to deal with sending or receiving data.
So, the answer is yes.
>
> * Previously one could set the buffer size when creating multi_usrp objects
> by use of the device address as e.g. dev_addr["recv_buff_size"]=100. Is this
> now obsolete?
>
That didnt change. I can see how it would be more appropriate for the
construction of the streamer to setup stuff like that. But the sockets
are still created once at init time, do the device's args are used.
> * For the send command one could use an option SEND_MODE_FULL_BUFF, is this
> also obsolete?
>
It always send the entire buffer. If you needed to ensure that exactly
one packet was sent, you would just use the max sample per packet as the
length.
> * How long does it take to create a streamer object ?
Construction of a new streamer resets a few things in the DSP chain. So
100 of us at most, unless I am mistaken and there is a timeout in there
to flush a buffer or something.
The intention however, is not to recreate the streamer for every tx burst.
>
> * Can I have multiple streamer objects open to one multi_usrp object and
> alternate between them?
>
Multiple yes, but alternate- not really. Multiple streamers are OK as
long as they dont overlap which DSPs they control. Otherwise you could
have conflicting settings like the format of samples over the wire.
-josh
------------------------------
Message: 6
Date: Tue, 8 Jan 2013 09:14:20 +0100
From: Tor Andre Myrvoll <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
7. jan. 2013 kl. 19:38 skrev Josh Blum <[email protected]>:
>
>
> On 01/07/2013 04:16 AM, Tor Andre Myrvoll wrote:
>> 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:
>>
>
>
> So what I am gathering. send() is returning ENOBUFS, but its a condition
> you cant select() for.
Technically, send() returns -1 and then you have to check errno for the error,
but yes, that's the gist of it.
> The other oddity is that there technically should
> always be enough buffer space. There is a point to point flow control
> between host and USRP DSP that prevents the host from overflowing the
> USRP's buffering. The socket send buffer is also resized to match. OK,
> well good to know
There is a post on the FreeBSD list that seems to say that the size of the
socket buffer is irrelevant:
http://lists.freebsd.org/pipermail/freebsd-hackers/2004-February/005643.html
Again, I am no network programming expert, but there you have it.
>
> It seems the fix would be to loop on fail and retry the send?
>
Yes. I just do a tiny usleep() before retrying. It's crude, but it solves my
problem for now.
There is just one issue, which is the mysterious output of the letter S in the
./tx_waveform output (this is the unmodified version from examples/)
Here is en example from a process that has been runnning for a few hours:
emphaticmac:build$examples/tx_waveforms --args="addr0=192.168.10.2" --rate 1e6
--wave-freq 100e3 --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
Creating the usrp device with: addr0=192.168.10.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N210
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv3 RX+GDB
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv3 TX+GDB
Setting TX Rate: 1.000000 Msps...
Actual TX Rate: 1.000000 Msps...
Setting TX Freq: 400.000000 MHz...
Actual TX Freq: 400.000000 MHz...
Setting device timestamp to 0...
Checking TX: LO: locked ...
Checking TX: Ref: locked ...
Press Ctrl + C to stop streaming...
SSSSSSSSSSSSSSSSSSSSSSSSSSSSS^C
Done!
I've search the uhd source code, but all I can find is that "O"s and "U"s may
be printed if over- or under-flow occurs.
>
> asio was very helpful to be cross platform at creating the sockets.
> Since I wasnt really using the asynchronous stuff, I just pulled out the
> socket descriptors and used send() and recv(). Not sure what the asio
> wrappers around the synchronous send and recv might offer. Hopefully I
> am avoiding extra complications and not causing them... does the asio
> socket->send() call handle the error + retry on freebsd?
I can't really say from the documentation. I may have to check the source or
actually do an implementation to find out.
The immediate pros of using boost::asio seems to be that it will use more
modern approaches to network programming, e.g. kqueue, epoll and Overlapped IO,
if the platform supports it, and fall back to select() and poll() only if
needed. That and a much higher level of abstraction of course.
Cheers,
--
- Tor
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130108/32b37999/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 08 Jan 2013 14:09:39 +0100
From: Simon IJskes <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] USRP1 support in the form of a network
server
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02-01-13 18:29, Josh Blum wrote:
>
>
> On 01/02/2013 05:38 AM, SImon IJskes wrote:
>> Feature request:
>>
>> A network server executable, running on windows and linux, allowing
>> access to all the features of the USRP1 over a TCP/UDP interface.
>>
>
> You may be interested in:
> http://wiki.spench.net/wiki/Gr-baz#borip
Thanks. I miss the capability to do TX with borip.
It would be wonderfull if ettus produced a single windows installer,
that creates a network server to use the USRP1 for RX as well as TX. A
network server is so much easier to interface then a C++ DLL.
I know a few HAMs and SWLs that are good in HF, medium in electronics
and weak with software. So a single install from uhd-network-server, a
cusomized powersdr or sdr-radio would make the USRP1 so much more
accessible to them.
You will probably gain quite a few customers as soon as a ham oriented
SDR will make a driver for this network USRP1, and make a number of
programming hams, who program in other languages than python or C++ also
very happy.
Gr. Simon
------------------------------
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 8
*****************************************
