USRP users mailing list -- Universal Software Radio Peripheral by Ettus Research ()

headers Guanbo Zheng | 1 Mar 2011 02:37

_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum <josh@...> wrote:
> Hello list,
>
> In preparation for the coming gnuradio release, and the cut-over from
> next to master, changes have been pushed to both the uhd.git master
> branch and the gnuradio.git next branch.

I'm getting the following timeouts after the update. I presume this has
something to do with buffering since it always occurs at the same packet
number - code change at end. Same result on e100 and rlt NIC's.

[ttsou <at> fischer examples]$ ./tx_timed_samples --secs 4 --nsamps 400000 --rate 400e3 --dilv --spp 864
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400; UHD_003.20110226000831.77641c6

Creating the usrp device with: ...
Current recv sock buff size: 50000000 bytes
mboard0 MIMO master
Using Device: Single USRP:
  Device: USRP2/N Series device
  Mboard 0: USRP-N210 mboard
  RX DSP 0: USRP-N210 ddc0
  RX Channel: 0
    RX Dboard: USRP-N210 dboard (rx unit)
    RX Subdev: Unknown - Unknown (0xffff)
  TX DSP 0: USRP-N210 duc0
  TX Channel: 0
    TX Dboard: USRP-N210 dboard (tx unit)
    TX Subdev: Basic TX (0x0000) - AB

Setting TX Rate: 0.400000 Msps...
Actual TX Rate: 0.400000 Msps...

Setting TX Freq: 0.000000 Mhz...
Actual TX Freq: 0.000000 Mhz...

Setting device timestamp to 0...
Send timeout... Sent 362 samples of packet 237
Send timeout... Sent 0 samples of packet 238
Send timeout... Sent 0 samples of packet 239
Send timeout... Sent 0 samples of packet 240
Send timeout... Sent 0 samples of packet 241
...

  Thomas

---
 host/examples/tx_timed_samples.cpp |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/host/examples/tx_timed_samples.cpp b/host/examples/tx_timed_samples.cpp
index f10d7e4..1f87ae3 100644
--- a/host/examples/tx_timed_samples.cpp
+++ b/host/examples/tx_timed_samples.cpp
 <at>  <at>  -106,7 +106,8  <at>  <at>  int UHD_SAFE_MAIN(int argc, char *argv[]){
             //send will backup into the host this many seconds before sending:
             seconds_in_future + 0.1 //timeout (delay before transmit + padding)
         );
-        if (num_tx_samps < samps_to_send) std::cout << "Send timeout..." << std::endl;
+        if (num_tx_samps < samps_to_send)
+            std::cout << "Send timeout... Sent " << num_tx_samps << " samples of packet " << i << std::endl;
         if(verbose) std::cout << std::endl << boost::format("Sent %d samples") % num_tx_samps << std::endl;
     }

--

-- 

On 02/28/2011 08:54 AM, Marc Epard wrote:
> I think I just encountered this bug, too. In our case, it's a C++ tool using UHD directly. The first
transmit+receive works, but from then on it looks there's nothing's being transmitted until I kill the
process and restart it. I haven't dug very deep, yet, though.
> 
> -Marc
> 

Ok, found a bug and fixed it, update your repo.

There is a one line fix to restore a buffer to the queue in the event of
a timeout. Basically, the transmit app was running out of receive
buffers and eventually if couldn't get a buffer, and couldn't update the
flow control condition.

Let me know if all is well.
-Josh

_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Josh,

I checked out the code from the next branch in UHD (which did NOT 
comment out if (not

>>  fc_mons[i]->check_fc_condition(fc_word32, send_timeout)) return false;), I updated the diff you
sent me yesterday.

After being idle for few minutes, the data transmission path wad dead 
again. But this time, I could observe 42 B/s data flow to USRP2 (which 
is control data).

Andrew

On 03/01/2011 02:19 PM, Josh Blum wrote:
>
> On 02/28/2011 08:54 AM, Marc Epard wrote:
>> I think I just encountered this bug, too. In our case, it's a C++ tool using UHD directly. The first
transmit+receive works, but from then on it looks there's nothing's being transmitted until I kill the
process and restart it. I haven't dug very deep, yet, though.
>>
>> -Marc
>>
> Ok, found a bug and fixed it, update your repo.
>
> There is a one line fix to restore a buffer to the queue in the event of
> a timeout. Basically, the transmit app was running out of receive
> buffers and eventually if couldn't get a buffer, and couldn't update the
> flow control condition.
>
> Let me know if all is well.
> -Josh

Hello,

What is the right way to read data into matlab, written to a file by the 
UHD rx_sample_to_file?

I am trying
fid=fopen('filename','r','ieee-be')
data=fread(fid,[2,1e6],'int16');
data=[1 1i]*data;

And getting junk.

I am just testing with an input CW, and it looks just fine on my 
spectrum analyzer and on the uhd_fft.grc, written by marcus.

Thanks

Scott

Did you update the uhd master repo? The fix was in commit
c69d9c0205d897923b07ac77cb87633fb4925b53

-Josh

On 03/01/2011 01:36 PM, Feng Andrew Ge wrote:
> Josh,
> 
> I checked out the code from the next branch in UHD (which did NOT
> comment out if (not
> 
>>>  fc_mons[i]->check_fc_condition(fc_word32, send_timeout)) return
>>> false;), I updated the diff you sent me yesterday.
> 
> 
> After being idle for few minutes, the data transmission path wad dead
> again. But this time, I could observe 42 B/s data flow to USRP2 (which
> is control data).
> 
> Andrew
> 
> On 03/01/2011 02:19 PM, Josh Blum wrote:
>>
>> On 02/28/2011 08:54 AM, Marc Epard wrote:
>>> I think I just encountered this bug, too. In our case, it's a C++
>>> tool using UHD directly. The first transmit+receive works, but from
>>> then on it looks there's nothing's being transmitted until I kill the
>>> process and restart it. I haven't dug very deep, yet, though.
>>>
>>> -Marc
>>>
>> Ok, found a bug and fixed it, update your repo.
>>
>> There is a one line fix to restore a buffer to the queue in the event of
>> a timeout. Basically, the transmit app was running out of receive
>> buffers and eventually if couldn't get a buffer, and couldn't update the
>> flow control condition.
>>
>> Let me know if all is well.
>> -Josh
> 

Im not familiar. But, if you receive complex ints, they will be in host
byte order. Each complex sample is composed of 2 signed 16 bit integers

-Josh

On 03/01/2011 02:17 PM, Scott Johnston wrote:
> Hello,
> 
> What is the right way to read data into matlab, written to a file by the
> UHD rx_sample_to_file?
> 
> I am trying
> fid=fopen('filename','r','ieee-be')
> data=fread(fid,[2,1e6],'int16');
> data=[1 1i]*data;
> 
> And getting junk.
> 
> I am just testing with an input CW, and it looks just fine on my
> spectrum analyzer and on the uhd_fft.grc, written by marcus.
> 
> Thanks
> 
> Scott
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@...
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

94	May 2013
172	April 2013
215	March 2013
215	February 2013
146	January 2013
138	December 2012
196	November 2012
225	October 2012
139	September 2012
173	August 2012
253	July 2012
285	June 2012
311	May 2012
220	April 2012
272	March 2012
244	February 2012
184	January 2012
241	December 2011
321	November 2011
263	October 2011
249	September 2011
255	August 2011
293	July 2011
321	June 2011
232	May 2011
157	April 2011
179	March 2011
19	February 2011

Re: USRP2 frequency offset

Multiple-carrier signal with Simulink and USRP2

Re: Multiple-carrier signal with Simulink and USRP2

Re: UHD Announcement - February 25rd 2011

Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

OFDM implementation

Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

UHD rx_sample_to_file

Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

Re: UHD rx_sample_to_file

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31