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. UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
2. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Nick Foster)
3. Re: GPSDO time is wrong (Nowlan, Sean)
4. Re: GPSDO time is wrong (Josh Blum)
5. Re: GPSDO time is wrong (Nowlan, Sean)
6. SDR card with PCIe (Colby Boyer)
7. Re: Question about Future Products (Matt Ettus)
8. win64 uhd showing wrong architecture (Stefano Speretta)
9. N210 / WBX General Questions (Simon HB9DRV)
10. DC value getting added at Rx (Sanat Gulvadi)
11. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
12. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
13. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
14. Re: N210 / WBX General Questions (Marcus D. Leech)
15. Re: DC value getting added at Rx (Marcus D. Leech)
16. Re: N210 / WBX General Questions (Dean Ferraro)
17. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
18. Re: N210 / WBX General Questions (Simon HB9DRV)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 May 2012 13:28:40 -0400
From: Isaac Gerg <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD Tx Issues with Spurious Samples Being Tx'ed
Message-ID:
<cadnn3yxxogngz4s2emwdhwrrbyk_pg5oyg+mnhxktq9q+wz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
I updated to the new UHD interface (the one that uses multi_usrp and
tx_streamer). I am seeing a problem with spurious samples being sent which
looks similar to the problem I had here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
with the old interface. My code worked fine with the old interface after I
found a bug in it which caused this problem but was fixed.
Here is sample code that sends a burst of 100 samples all with the same
value.
// Set up tx params. We wish to send a burst.
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = true;
md.has_time_spec = false;
size_t num_tx_samps = 0;
//send the entire packet (driver fragments internally)
//num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
// New interface usage
uhd::stream_args_t stream_args("fc32", "sc16");
uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args);
num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
pVec is 100 complex samples long.
The output isnt right when I look at it. There's spurious energy floating
around.
Thanks in advance,
Isaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120501/9ff57f68/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 1 May 2012 10:39:17 -0700
From: Nick Foster <[email protected]>
To: Isaac Gerg <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<calalhju3vtb8jt_y-xqazk6z_ypjs0moejnb2ov3hr_tsaj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <[email protected]> wrote:
> Hi All,
>
> I updated to the new UHD interface (the one that uses multi_usrp and
> tx_streamer). I am seeing a problem with spurious samples being sent which
> looks similar to the problem I had here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
> with the old interface. My code worked fine with the old interface after I
> found a bug in it which caused this problem but was fixed.
>
> Here is sample code that sends a burst of 100 samples all with the same
> value.
> // Set up tx params. We wish to send a burst.
> uhd::tx_metadata_t md;
> md.start_of_burst = true;
> md.end_of_burst = true;
> md.has_time_spec = false;
>
> size_t num_tx_samps = 0;
>
> //send the entire packet (driver fragments internally)
> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
>
> // New interface usage
> uhd::stream_args_t stream_args("fc32", "sc16");
> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args);
> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
>
> pVec is 100 complex samples long.
>
> The output isnt right when I look at it. There's spurious energy floating
> around.
>
Isaac,
Can you please elaborate a bit? Can you provide your data samples, a plot
of what you are observing, and a plot or description of what you believe
you should be seeing?
Thanks,
Nick
>
> Thanks in advance,
> Isaac
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120501/a9eb3b04/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 2 May 2012 01:04:41 +0000
From: "Nowlan, Sean" <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO time is wrong
Message-ID: <195933287DC65748BA7AE867BA8E430B6218BB3E@apatlisdmbx02>
Content-Type: text/plain; charset="iso-8859-1"
Thanks! That's essentially the approach I took, i.e., fetch the sensor and set
time at next PPS. Even after doing this and sleeping for 1 second to hopefully
let the register latch at the next PPS, the GPSDO was still providing a bad
time, even after lock. I "solved" it by fetching the "gps_time" sensor several
times, hoping that at least one of them would bump the GPSDO out of its
initialization state. Still, this seems hack-ish.
The function get_mboard_sensor("gps_time") takes around 1 second to return a
value. Is it possible that the value could get returned near a PPS edge and
that setting to GPS time + 1 would be 1 second late?
Thanks,
Sean
________________________________
From: Nick Foster [[email protected]]
Sent: Tuesday, May 01, 2012 11:16 AM
To: Nowlan, Sean
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO time is wrong
On Mon, Apr 30, 2012 at 9:14 PM, Nowlan, Sean
<[email protected]<mailto:[email protected]>> wrote:
I'm having an issue with the FPGA time register taking on a bad time value from
the GPSDO unit when it's not locked. Essentially I'm doing this:
while not usrp.get_mboard_sensor("gps_locked", 0).to_bool():
print "STILL waiting..."
sleep(4)
if usrp.get_mboard_sensor("gps_locked", 0).to_bool():
print "FINALLY LOCKED!"
usrp.get_time_last_pps(0)
>>> prints 1136074108, which is 2006-01-01 00:08:28
How do you force the GPSDO to give the correct time?
The USRP PPS time and the GPSDO time aren't the same clock. You have to set the
time at next PPS to the gps_time sensor value, plus one second. It's supposed
to do this automatically at initialization time (see usrp2_impl.cpp lines
~659-666), but if the GPSDO isn't locked when UHD initializes it won't set a
time (since the GPSDO time isn't known until GPS lock). Either init after GPS
is locked or duplicate that behavior in your own program after lock.
If you don't care about the USRP PPS time (used for TX scheduling and RX
timestamping) but only care about GPSDO time at initialization (for, say,
coarse timestamping and logging) you can just fetch the GPS time from the GPSDO
with usrp.get_mboard_sensor("gpsdo_time", 0).to_int().
--n
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/5949a8e5/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 01 May 2012 20:22:10 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO time is wrong
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> The function get_mboard_sensor("gps_time") takes around 1 second to
> return a value. Is it possible that the value could get returned near
> a PPS edge and that setting to GPS time + 1 would be 1 second late?
>
Because the gps_time returns immediately after a PPS, you have an entire
second to call set_time_next_pps()
-Josh
------------------------------
Message: 5
Date: Wed, 2 May 2012 03:42:30 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] GPSDO time is wrong
Message-ID: <195933287DC65748BA7AE867BA8E430B6218BBDC@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
Ah, I didn't know it blocked like that. Thanks for clarifying.
Sean
________________________________________
From: [email protected] [[email protected]]
on behalf of Josh Blum [[email protected]]
Sent: Tuesday, May 01, 2012 11:22 PM
To: [email protected]
Subject: Re: [USRP-users] GPSDO time is wrong
> The function get_mboard_sensor("gps_time") takes around 1 second to
> return a value. Is it possible that the value could get returned near
> a PPS edge and that setting to GPS time + 1 would be 1 second late?
>
Because the gps_time returns immediately after a PPS, you have an entire
second to call set_time_next_pps()
-Josh
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Tue, 1 May 2012 21:49:56 -0700
From: Colby Boyer <[email protected]>
To: GNU Radio Discussion <[email protected]>,
[email protected]
Subject: [USRP-users] SDR card with PCIe
Message-ID:
<cagkjzgnymkihy86g9tsadtjpppmseayj7qo0c60ozxja81z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just saw this on the blogosphere, but no mention on the list I think. May
be an interesting addition to GNURadio?
http://www.pervices.com/about.html
--Colby
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120501/567a431a/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 2 May 2012 00:50:59 -0700
From: Matt Ettus <[email protected]>
To: Robert Palumbo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Question about Future Products
Message-ID:
<CAN=1kn8wMQXFWgpreEssa63ag=czxQ9zB-Y3ekxge52P+A=j...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Robert,
Thank you very much. We do have a few products coming with significantly
bigger FPGAs, but I can't be more specific right now. In the shorter term,
is your app slightly larger than the 3400 will hold, or is it much bigger?
If it is close, there may be some ways we can help you squeeze it in.
What resource is running short? Is it logic, BRAM, or DSP units?
Matt
On Sat, Apr 28, 2012 at 9:59 AM, Robert Palumbo <[email protected]> wrote:
> Hello,
>
> I would like to start off by saying that you guys sell a great line of
> products. I've been using the N200/N210 series for my applications
> extensively, and their performance has been superior thus far,
> especially in terms of flexibility and reliability.
>
> I was wondering if Ettus Research has any upcoming plans to develop
> another USRP-product, similar in performance to the N210, but with a
> larger FPGA (i.e., Virtex family)? The N210 works perfectly for my
> application, but the only limitation right now is the size of the
> DSP3400A FPGA.
>
> Thanks for any info you can give,
>
> Rob
>
> --
> Robert A Palumbo
> [email protected]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/a88be4f4/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 02 May 2012 10:49:31 +0200
From: Stefano Speretta <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] win64 uhd showing wrong architecture
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hello,
I tried today the UHD version 3.4.1 (x64) and on my machine works fine
(amd64), but when the library is loaded
this string is printed:
Win32; Microsoft Visual C++ version 10.0; Boost_104700;
UHD_003.004.001-0-release
while the architecture should have been Win64.
I checked and the same library does not run under a 32-bit machine.
Regards,
Stefano
------------------------------
Message: 9
Date: Wed, 2 May 2012 11:41:12 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] N210 / WBX General Questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
I stumbled across Ettus by accident and will soon have a N210, WBX and a few
HF cards. My hope is to add Ettus support to my http://sdr-radio.com
software.
Q1: With 16-bit IQ samples what bandwidth can I expect from the WBX, Basic
RX (1-250MHz) and LFRX (0-30MHz) boards?
Q2: Just how good are the Basic RX and LFRX boards? I haven't found any
specs but I probably overlooked this information even though it was in front
of my nose.
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/593513ab/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 2 May 2012 13:33:58 +0200
From: Sanat Gulvadi <[email protected]>
To: [email protected]
Subject: [USRP-users] DC value getting added at Rx
Message-ID:
<CAH12yLtFOp5gxpFtt0=jcAdZ1FByCQEbG68y5a_BZT-BDDkb=a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Good Afternoon,
I used 2 USRP2-Rev4 devices on 2 different host computers each with an
RFX2400 daughterboard, to transmit some distinct unmodulated sub-carriers
to see if on reception I can identify the same sub-carriers. I am able to
do this successfully but I end up seeing a peak at 0. I have noticed that I
get this peak even if I do the reception without transmitting any data. Is
some DC getting added somewhere, for some reason ?
This also happens when I transmit some tones using regular single carrier
transmission.
Pictures :
http://imgur.com/a/oAEtZ#0
The peak seen at 2.6MHz seems to be something detected over the air by the
receiver which is unrelated to my experiments, which I think can be ignored.
If I have overlooked some previous post where this was asked and answered
then I apologize. I only had a quick glance through the mailing list and
didn't really find anything quite similar.
Regards,
Sanat
p.s - I am using a command line app I developed using
UHD_003.004.000-325-g7e296167 for these experiments. I tried setting
usrp->set_rx_dc_offset(true) but that didn't really do anything. Not even
sure if that is in anyway related.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/6f0a9bc6/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 2 May 2012 08:30:45 -0400
From: Isaac Gerg <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<CADnN3yUZWP0LqNO6voMMVr92NRZWUBebCRV8b2SKytRg=j_...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Nick,
I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am
transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250
sample burst with the I/Q parts being float32 and being set to 1.0, I get a
burst on the Rx end that is about 1330 samples long, sometimes more
sometimes less. I have code that flushes the rx buffer so I know its not
any kind of "left over" signal.
I had a similar problem January 2011 using the old UHD interface (the one
with the single_usrp::make) and it turned out to be a bug Josh found. What
I am seeing from my experiments is something very similar to what saw last
January.
I should add that I _am_ using the new tx_streamer interface.
Isaac
On Tue, May 1, 2012 at 1:39 PM, Nick Foster <[email protected]> wrote:
> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <[email protected]>wrote:
>
>> Hi All,
>>
>> I updated to the new UHD interface (the one that uses multi_usrp and
>> tx_streamer). I am seeing a problem with spurious samples being sent which
>> looks similar to the problem I had here:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
>> with the old interface. My code worked fine with the old interface after I
>> found a bug in it which caused this problem but was fixed.
>>
>> Here is sample code that sends a burst of 100 samples all with the same
>> value.
>> // Set up tx params. We wish to send a burst.
>> uhd::tx_metadata_t md;
>> md.start_of_burst = true;
>> md.end_of_burst = true;
>> md.has_time_spec = false;
>>
>> size_t num_tx_samps = 0;
>>
>> //send the entire packet (driver fragments internally)
>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
>>
>> // New interface usage
>> uhd::stream_args_t stream_args("fc32", "sc16");
>> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args);
>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
>>
>> pVec is 100 complex samples long.
>>
>> The output isnt right when I look at it. There's spurious energy
>> floating around.
>>
>
> Isaac,
>
> Can you please elaborate a bit? Can you provide your data samples, a plot
> of what you are observing, and a plot or description of what you believe
> you should be seeing?
>
> Thanks,
> Nick
>
>
>>
>> Thanks in advance,
>> Isaac
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/70b0c726/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 2 May 2012 08:33:47 -0400
From: Isaac Gerg <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<CADnN3yWd9MUNAk31F8obEEwbo5m3_RqxX9a1WCkkmH67aaM+=w...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi again Nick,
It's early for me here :) I should be more clear -- the bug I found was in
the ettus code. I expect to see a burst of roughly 250 samples but I get
one that is many times longer.
Isaac
On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <[email protected]> wrote:
> Hi Nick,
>
> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am
> transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250
> sample burst with the I/Q parts being float32 and being set to 1.0, I get a
> burst on the Rx end that is about 1330 samples long, sometimes more
> sometimes less. I have code that flushes the rx buffer so I know its not
> any kind of "left over" signal.
>
> I had a similar problem January 2011 using the old UHD interface (the one
> with the single_usrp::make) and it turned out to be a bug Josh found. What
> I am seeing from my experiments is something very similar to what saw last
> January.
>
> I should add that I _am_ using the new tx_streamer interface.
>
> Isaac
>
>
> On Tue, May 1, 2012 at 1:39 PM, Nick Foster <[email protected]> wrote:
>
>> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <[email protected]>wrote:
>>
>>> Hi All,
>>>
>>> I updated to the new UHD interface (the one that uses multi_usrp and
>>> tx_streamer). I am seeing a problem with spurious samples being sent which
>>> looks similar to the problem I had here:
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
>>> with the old interface. My code worked fine with the old interface after I
>>> found a bug in it which caused this problem but was fixed.
>>>
>>> Here is sample code that sends a burst of 100 samples all with the same
>>> value.
>>> // Set up tx params. We wish to send a burst.
>>> uhd::tx_metadata_t md;
>>> md.start_of_burst = true;
>>> md.end_of_burst = true;
>>> md.has_time_spec = false;
>>>
>>> size_t num_tx_samps = 0;
>>>
>>> //send the entire packet (driver fragments internally)
>>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
>>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
>>>
>>> // New interface usage
>>> uhd::stream_args_t stream_args("fc32", "sc16");
>>> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args);
>>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
>>>
>>> pVec is 100 complex samples long.
>>>
>>> The output isnt right when I look at it. There's spurious energy
>>> floating around.
>>>
>>
>> Isaac,
>>
>> Can you please elaborate a bit? Can you provide your data samples, a plot
>> of what you are observing, and a plot or description of what you believe
>> you should be seeing?
>>
>> Thanks,
>> Nick
>>
>>
>>>
>>> Thanks in advance,
>>> Isaac
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/bd33213a/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 2 May 2012 10:32:42 -0400
From: Isaac Gerg <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<CADnN3yUs4ViQZEuHbF5QfagkM=w6bxoh2dfhxp+fwx3sbve...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I've hooked my USRP1 up to an oscilloscope and can see the following
1. When I try to tx 250 samps and pad the heck out of it with tons of
zeros, I *sometimes* get a burst of 1ms.
2. When I don't do the padding and simply try to send 250 samps, I don't
see the burst. I get something like looks like a decaying exponential in
terms of magnitude.
It looks like something with the sending 250 samps by itself does not work
correctly. This previously worked with the old UHD interface on my USRP1.
Isaac
On Wed, May 2, 2012 at 8:33 AM, Isaac Gerg <[email protected]> wrote:
> Hi again Nick,
>
> It's early for me here :) I should be more clear -- the bug I found was
> in the ettus code. I expect to see a burst of roughly 250 samples but I
> get one that is many times longer.
>
> Isaac
>
>
> On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <[email protected]> wrote:
>
>> Hi Nick,
>>
>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am
>> transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250
>> sample burst with the I/Q parts being float32 and being set to 1.0, I get a
>> burst on the Rx end that is about 1330 samples long, sometimes more
>> sometimes less. I have code that flushes the rx buffer so I know its not
>> any kind of "left over" signal.
>>
>> I had a similar problem January 2011 using the old UHD interface (the one
>> with the single_usrp::make) and it turned out to be a bug Josh found. What
>> I am seeing from my experiments is something very similar to what saw last
>> January.
>>
>> I should add that I _am_ using the new tx_streamer interface.
>>
>> Isaac
>>
>>
>> On Tue, May 1, 2012 at 1:39 PM, Nick Foster <[email protected]> wrote:
>>
>>> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <[email protected]>wrote:
>>>
>>>> Hi All,
>>>>
>>>> I updated to the new UHD interface (the one that uses multi_usrp and
>>>> tx_streamer). I am seeing a problem with spurious samples being sent which
>>>> looks similar to the problem I had here:
>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
>>>> with the old interface. My code worked fine with the old interface after I
>>>> found a bug in it which caused this problem but was fixed.
>>>>
>>>> Here is sample code that sends a burst of 100 samples all with the same
>>>> value.
>>>> // Set up tx params. We wish to send a burst.
>>>> uhd::tx_metadata_t md;
>>>> md.start_of_burst = true;
>>>> md.end_of_burst = true;
>>>> md.has_time_spec = false;
>>>>
>>>> size_t num_tx_samps = 0;
>>>>
>>>> //send the entire packet (driver fragments internally)
>>>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
>>>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
>>>>
>>>> // New interface usage
>>>> uhd::stream_args_t stream_args("fc32", "sc16");
>>>> uhd::tx_streamer::sptr tx_stream = m_pDev->get_tx_stream(stream_args);
>>>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
>>>>
>>>> pVec is 100 complex samples long.
>>>>
>>>> The output isnt right when I look at it. There's spurious energy
>>>> floating around.
>>>>
>>>
>>> Isaac,
>>>
>>> Can you please elaborate a bit? Can you provide your data samples, a
>>> plot of what you are observing, and a plot or description of what you
>>> believe you should be seeing?
>>>
>>> Thanks,
>>> Nick
>>>
>>>
>>>>
>>>> Thanks in advance,
>>>> Isaac
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/b9d94cdf/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 02 May 2012 10:39:34 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 / WBX General Questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On 02/05/12 05:41 AM, Simon HB9DRV wrote:
>
> Hi All,
>
>
>
> I stumbled across Ettus by accident and will soon have a N210, WBX and
> a few HF cards. My hope is to add Ettus support to my
> http://sdr-radio.com software.
>
>
>
> Q1: With 16-bit IQ samples what bandwidth can I expect from the WBX,
> Basic RX (1-250MHz) and LFRX (0-30MHz) boards?
>
With 16-bit samples, the N210 can push 25Msps towards the host. Whether
or not the host PC can actually
reliably processing that amount of data depends very much on the host
PC, and the algorithms that are
being used.
>
>
> Q2: Just how good are the Basic RX and LFRX boards? I haven't found
> any specs but I probably overlooked this information even though it
> was in front of my nose.
>
>
>
That's a very broad question. Could you be more specific?
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/c8137b9d/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 02 May 2012 10:52:06 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] DC value getting added at Rx
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/05/12 07:33 AM, Sanat Gulvadi wrote:
> Good Afternoon,
>
> I used 2 USRP2-Rev4 devices on 2 different host computers each with an
> RFX2400 daughterboard, to transmit some distinct unmodulated
> sub-carriers to see if on reception I can identify the same
> sub-carriers. I am able to do this successfully but I end up seeing a
> peak at 0. I have noticed that I get this peak even if I do the
> reception without transmitting any data. Is some DC getting added
> somewhere, for some reason ?
>
> This also happens when I transmit some tones using regular single
> carrier transmission.
> Pictures :
> http://imgur.com/a/oAEtZ#0
>
> The peak seen at 2.6MHz seems to be something detected over the air by
> the receiver which is unrelated to my experiments, which I think can
> be ignored.
> If I have overlooked some previous post where this was asked and
> answered then I apologize. I only had a quick glance through the
> mailing list and didn't really find anything quite similar.
>
> Regards,
> Sanat
>
> p.s - I am using a command line app I developed using
> UHD_003.004.000-325-g7e296167 for these experiments. I tried setting
> usrp->set_rx_dc_offset(true) but that didn't really do anything. Not
> even sure if that is in anyway related.
>
Direct-conversion receivers nearly-always have residual DC offset.
There are algorithms in the FPGA for
DC-offset removal, but they're not perfect. The usual technique is
to use offset tuning, to move the
"DC anomaly" outside your passband.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 16
Date: Wed, 2 May 2012 11:01:31 -0400
From: Dean Ferraro <[email protected]>
To: Simon HB9DRV <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [USRP-users] N210 / WBX General Questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I use an LFRX board in a USRP1 with a Z1501 active antenna from Clifton labs.
With HDSDR or other s/w I find it to perform exceptional as a general purpose
HF receiver.
I look forward to it's inclusion in your s/w.
On May 2, 2012, at 5:41 AM, "Simon HB9DRV" <[email protected]> wrote:
> Hi All,
>
> I stumbled across Ettus by accident and will soon have a N210, WBX and a few
> HF cards. My hope is to add Ettus support to my http://sdr-radio.com software.
>
> Q1: With 16-bit IQ samples what bandwidth can I expect from the WBX, Basic RX
> (1-250MHz) and LFRX (0-30MHz) boards?
>
> Q2: Just how good are the Basic RX and LFRX boards? I haven?t found any specs
> but I probably overlooked this information even though it was in front of my
> nose.
>
> Simon Brown, HB9DRV
> http://dit-dit-dit.com
>
> Not sent from an iPhone: I don't have one and I don't want one.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/b3826d26/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 2 May 2012 11:02:20 -0400
From: Isaac Gerg <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<cadnn3yvdcunqjmkeyv8nite-4nuebx8ynyhxbotzm8a+dvh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have tried to zero pad my bursts to see if this flushes something out in
the UHD interface. It helps somewhat. However, when I try to send
something like 40e3 samps with a single send call (start and end of burst
set), sometimes the UHD segfaults.
Isaac
On Wed, May 2, 2012 at 10:32 AM, Isaac Gerg <[email protected]> wrote:
> I've hooked my USRP1 up to an oscilloscope and can see the following
> 1. When I try to tx 250 samps and pad the heck out of it with tons of
> zeros, I *sometimes* get a burst of 1ms.
> 2. When I don't do the padding and simply try to send 250 samps, I don't
> see the burst. I get something like looks like a decaying exponential in
> terms of magnitude.
>
> It looks like something with the sending 250 samps by itself does not work
> correctly. This previously worked with the old UHD interface on my USRP1.
>
> Isaac
>
> On Wed, May 2, 2012 at 8:33 AM, Isaac Gerg <[email protected]> wrote:
>
>> Hi again Nick,
>>
>> It's early for me here :) I should be more clear -- the bug I found was
>> in the ettus code. I expect to see a burst of roughly 250 samples but I
>> get one that is many times longer.
>>
>> Isaac
>>
>>
>> On Wed, May 2, 2012 at 8:30 AM, Isaac Gerg <[email protected]>wrote:
>>
>>> Hi Nick,
>>>
>>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. I am
>>> transmitting at baseband (fc=0) with a fs of 250e3. When I send a 250
>>> sample burst with the I/Q parts being float32 and being set to 1.0, I get a
>>> burst on the Rx end that is about 1330 samples long, sometimes more
>>> sometimes less. I have code that flushes the rx buffer so I know its not
>>> any kind of "left over" signal.
>>>
>>> I had a similar problem January 2011 using the old UHD interface (the
>>> one with the single_usrp::make) and it turned out to be a bug Josh found.
>>> What I am seeing from my experiments is something very similar to what saw
>>> last January.
>>>
>>> I should add that I _am_ using the new tx_streamer interface.
>>>
>>> Isaac
>>>
>>>
>>> On Tue, May 1, 2012 at 1:39 PM, Nick Foster <[email protected]> wrote:
>>>
>>>> On Tue, May 1, 2012 at 10:28 AM, Isaac Gerg <[email protected]>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I updated to the new UHD interface (the one that uses multi_usrp and
>>>>> tx_streamer). I am seeing a problem with spurious samples being sent
>>>>> which
>>>>> looks similar to the problem I had here:
>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000541.html
>>>>> with the old interface. My code worked fine with the old interface after I
>>>>> found a bug in it which caused this problem but was fixed.
>>>>>
>>>>> Here is sample code that sends a burst of 100 samples all with the
>>>>> same value.
>>>>> // Set up tx params. We wish to send a burst.
>>>>> uhd::tx_metadata_t md;
>>>>> md.start_of_burst = true;
>>>>> md.end_of_burst = true;
>>>>> md.has_time_spec = false;
>>>>>
>>>>> size_t num_tx_samps = 0;
>>>>>
>>>>> //send the entire packet (driver fragments internally)
>>>>> //num_tx_samps = m_pDev->send(&pVec->front(), pVec->size(),
>>>>> md,uhd::io_type_t::COMPLEX_FLOAT32,uhd::device::SEND_MODE_FULL_BUFF);
>>>>>
>>>>> // New interface usage
>>>>> uhd::stream_args_t stream_args("fc32", "sc16");
>>>>> uhd::tx_streamer::sptr tx_stream =
>>>>> m_pDev->get_tx_stream(stream_args);
>>>>> num_tx_samps = tx_stream->send(&pVec->front(), pVec->size(), md);
>>>>>
>>>>> pVec is 100 complex samples long.
>>>>>
>>>>> The output isnt right when I look at it. There's spurious energy
>>>>> floating around.
>>>>>
>>>>
>>>> Isaac,
>>>>
>>>> Can you please elaborate a bit? Can you provide your data samples, a
>>>> plot of what you are observing, and a plot or description of what you
>>>> believe you should be seeing?
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>>
>>>>>
>>>>> Thanks in advance,
>>>>> Isaac
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/1c1aeb63/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 2 May 2012 17:34:11 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] N210 / WBX General Questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
Q1 - 25 Ms/s - excellent info.
Q2 - any info would be appreciated. I guess I'm wondering about MDS
(sensitivity) and Dynamic range. The filters in the N210 would be
interesting - how good are they, for example one radio I have is quotes as
115+ dB 80% alias free.
Obviously I'll see this for myself once I get the hardware, I'm just wonder
what I can expect.
Simon Brown, HB9DRV
<http://dir-dit-dit.com> http://dir-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A small stream flows out of the building and down a gully.
From: [email protected]
[mailto:[email protected]] On Behalf Of Marcus D. Leech
Q1: With 16-bit IQ samples what bandwidth can I expect from the WBX, Basic
RX (1-250MHz) and LFRX (0-30MHz) boards?
Q2: Just how good are the Basic RX and LFRX boards? I haven't found any
specs but I probably overlooked this information even though it was in front
of my nose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120502/5949be0f/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 2
*****************************************
