Guanbo Zheng | 1 Mar 02:37 2011
Picon

Re: USRP2 frequency offset

The CFO should be stable for that USRP.
Different USRP would have different CFO, but it would locate in the range of 3ppm-10ppm(I remember)
Interp/decim do not affect CFO, because it depends on hardware only.

Best,
Guanbo

On Feb 28, 2011, at 7:36 AM, "Song, Mujun  CAPT KR USAF AETC AFIT/ENG" <Mujun.Song.KR-HIBJ9SdasBE@public.gmane.org> wrote:

Hi, all.

 

I know there’s a frequency offset that comes from USRP2 hardware. But I have one more question on the frequency offset. I found that the frequency offset varies as the decimation factor changes. So does the frequency offset varies for every decimation factor or for every individual USRP2? Or do every USRP2 have the same offset or does the offset varies every time I run the USRP2?

 

Hope to get response from you.

 

Thanks,

Mujun

_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Nick Pers | 1 Mar 12:32 2011
Picon

Multiple-carrier signal with Simulink and USRP2

Hi all,
 
Is it possible to transmit multiple carrier signal (OFDM) with Simulink and USRP2?
 
Thanks,
NIck
_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Mike McLernon | 1 Mar 15:06 2011
Picon

Re: Multiple-carrier signal with Simulink and USRP2

Hi Nick,

 

It certainly is possible, but you will have to serialize the data first.  The USRP2 Transmitter block accepts only column vector inputs.

 

Hth,

Mike

 

 

From: usrp-users-bounces-p6fHTpcPDZaz3Dx2OeFgIA@public.gmane.org [mailto:usrp-users-bounces-p6fHTpcPDZaz3Dx2OeFgIA@public.gmane.org] On Behalf Of Nick Pers
Sent: Tuesday, March 01, 2011 6:33 AM
To: usrp-users-p6fHTpcPDZaz3Dx2OeFgIA@public.gmane.org
Subject: [USRP-users] Multiple-carrier signal with Simulink and USRP2

 

Hi all,

 

Is it possible to transmit multiple carrier signal (OFDM) with Simulink and USRP2?

 

Thanks,

NIck

_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Thomas Tsou | 1 Mar 17:55 2011
Picon

Re: UHD Announcement - February 25rd 2011

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;
     }

--

-- 
Josh Blum | 1 Mar 20:19 2011

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


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
Varun Krishnamurthy | 1 Mar 21:27 2011
Picon

OFDM implementation

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 
_______________________________________________
USRP-users mailing list
USRP-users@...
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Feng Andrew Ge | 1 Mar 22:36 2011
Picon

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

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
Scott Johnston | 1 Mar 23:17 2011
Picon

UHD rx_sample_to_file

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
Josh Blum | 1 Mar 23:29 2011

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

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
> 
Josh Blum | 1 Mar 23:30 2011

Re: UHD rx_sample_to_file

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

Gmane