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: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Josh Blum)
2. OFDM implementation (Varun Krishnamurthy)
3. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Feng Andrew Ge)
4. UHD rx_sample_to_file (Scott Johnston)
5. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Josh Blum)
6. Re: UHD rx_sample_to_file (Josh Blum)
7. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Feng Andrew Ge)
8. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Marc Epard)
9. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Feng Andrew Ge)
10. Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd
2011 (Marc Epard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Mar 2011 11:19:13 -0800
From: Josh Blum <[email protected]>
To: [email protected]
Cc: Feng Andrew Ge <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
------------------------------
Message: 2
Date: Tue, 1 Mar 2011 15:27:54 -0500
From: Varun Krishnamurthy <[email protected]>
To: [email protected], discuss-gnuradio
<[email protected]>
Subject: [USRP-users] OFDM implementation
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I want to implement OFDM on gnu radio platform.
Is it possible to simulate the code provided without using the hardware .
Ben told me to use the Benchmark ofdm code. I wanted to know whether there
is some documentation for it or not.
Thanking you
Varun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110301/f91caafe/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 01 Mar 2011 16:36:38 -0500
From: Feng Andrew Ge <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
Message: 4
Date: Tue, 1 Mar 2011 17:17:28 -0500
From: Scott Johnston <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD rx_sample_to_file
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
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
------------------------------
Message: 5
Date: Tue, 01 Mar 2011 14:29:17 -0800
From: Josh Blum <[email protected]>
To: Feng Andrew Ge <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
>
------------------------------
Message: 6
Date: Tue, 01 Mar 2011 14:30:50 -0800
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD rx_sample_to_file
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Tue, 01 Mar 2011 17:47:29 -0500
From: Feng Andrew Ge <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Yes, I did.
After transmitting some time, then being idle for a while, the
transmission could not work appropriately.
Andrew
On 03/01/2011 05:29 PM, Josh Blum wrote:
> 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
------------------------------
Message: 8
Date: Tue, 01 Mar 2011 16:56:03 -0600
From: Marc Epard <[email protected]>
To: Feng Andrew Ge <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; CHARSET=US-ASCII
On Mar 1, 2011, at 4:47 PM, Feng Andrew Ge wrote:
> After transmitting some time, then being idle for a while, the transmission
> could not work appropriately.
FWIW, the fix worked for us. I've run thousands of transmits since building UHD
with the fix, sometimes with long gaps, and haven't had a problem. Like I said
previously, we're using UHD directly from C++ w/o GR so it's a little different.
-Marc
------------------------------
Message: 9
Date: Tue, 01 Mar 2011 18:08:49 -0500
From: Feng Andrew Ge <[email protected]>
To: Marc Epard <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Josh,
I tested the code a few times again and the transmitter didn't stop. I
guess that I made some configuration changes last time which disrupted
the transmitter.
However, I confirmed that the LONG GAPs Marc mentioned is severe,
sometimes up to many seconds. If possible, would you say some words on
what you have changed.
Andrew
On 03/01/2011 05:56 PM, Marc Epard wrote:
> On Mar 1, 2011, at 4:47 PM, Feng Andrew Ge wrote:
>
>> After transmitting some time, then being idle for a while, the transmission
>> could not work appropriately.
> FWIW, the fix worked for us. I've run thousands of transmits since building
> UHD with the fix, sometimes with long gaps, and haven't had a problem. Like I
> said previously, we're using UHD directly from C++ w/o GR so it's a little
> different.
>
> -Marc
>
------------------------------
Message: 10
Date: Tue, 01 Mar 2011 17:16:46 -0600
From: Marc Epard <[email protected]>
To: Feng Andrew Ge <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Re: UHD Announcement -
February 25rd 2011
Message-ID: <[email protected]>
Content-Type: text/plain; CHARSET=US-ASCII
On Mar 1, 2011, at 5:08 PM, Feng Andrew Ge wrote:
> However, I confirmed that the LONG GAPs Marc mentioned is severe, sometimes
> up to many seconds. If possible, would you say some words on what you have
> changed.
Sorry, I didn't mean to imply gaps created by the UHD. The gaps were my own, as
I was spending time editing MATLAB code, scratching my head, or whatever.
During an actual measurement run, it does hundreds of tx+rx in a row with very
little time between them. In both cases, the same C++ server process was
keeping the UHD objects alive while waiting for another request. I've seen no
unexpected delays between issuing a send and having it happen.
-Marc
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 7, Issue 3
****************************************
