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. Local Oscillator Lock Problem (Simon HB9DRV)
2. Re: Local Oscillator Lock Problem (Josh Blum)
3. Re: Local Oscillator Lock Problem (Simon HB9DRV)
4. Transmission with timestamps (Matthias P. Braendli)
5. Re: Transmission with timestamps (Josh Blum)
6. Re: [Discuss-gnuradio] dc offset is different from unit to
unit (Josh Blum)
7. Re: What is the largest data transfer rate between the PC &
USRP2/USRP N Series through a GB ethernet cable? (Nazmul Islam)
8. GPSDO Support (Simon HB9DRV)
----------------------------------------------------------------------
Message: 1
Date: Sat, 2 Jun 2012 19:15:55 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Local Oscillator Lock Problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
With the WBX board there are random frequencies at which the LO doesn't
lock, for example 72 MHz and 98 MHz. What's annoying is that when the LO
isn't locked the returned data isn't too excellent L
I'm testing the lock status every second, problem is independent on
bandwidth, antenna, RF gain. I do not have MIMO, GPS or any fancy stuff,
just a WBX in a N210 and my software. CPU is not overloaded.
Please look at these two screenshots, both with a 10MHz bandwidth,
ftp://ftp.ham-radio.ch/common/sdr-radio/pics/98MHz.png (98MHz) lock is
on/off/on/off
ftp://ftp.ham-radio.ch/common/sdr-radio/pics/100MHz.png (100MHz) lock is on
always.
So are there known center (LO) frequencies to avoid?
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/20120602/3958c3fa/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 02 Jun 2012 10:32:09 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Local Oscillator Lock Problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/02/2012 10:15 AM, Simon HB9DRV wrote:
> Hi,
>
>
>
> With the WBX board there are random frequencies at which the LO doesn't
> lock, for example 72 MHz and 98 MHz. What's annoying is that when the LO
> isn't locked the returned data isn't too excellent L
>
>
>
> I'm testing the lock status every second, problem is independent on
> bandwidth, antenna, RF gain. I do not have MIMO, GPS or any fancy stuff,
> just a WBX in a N210 and my software. CPU is not overloaded.
>
>
>
> Please look at these two screenshots, both with a 10MHz bandwidth,
>
>
>
> ftp://ftp.ham-radio.ch/common/sdr-radio/pics/98MHz.png (98MHz) lock is
> on/off/on/off
>
> ftp://ftp.ham-radio.ch/common/sdr-radio/pics/100MHz.png (100MHz) lock is on
> always.
>
>
>
> So are there known center (LO) frequencies to avoid?
>
>
What version of UHD are you using?
If you installed from unstable aka the master branch, there is a known
issue tuning below the clock rate; introduced when implementing phase
synchronization for the WBX.
I recommend in the meantime using a release installer or something from
the maint branch. Or if not that, staying > 100 MHz in the meantime when
using WBX with USRP N-series.
-josh
------------------------------
Message: 3
Date: Sat, 2 Jun 2012 19:51:15 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Local Oscillator Lock Problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
Thanks for the fast answer, I'm happy with the beta for now, I'll stay above
100MHz.
Simon Brown, HB9DRV
http://dit-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. The sunspot count
is -25.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Josh Blum
If you installed from unstable aka the master branch, there is a known issue
tuning below the clock rate; introduced when implementing phase
synchronization for the WBX.
------------------------------
Message: 4
Date: Sat, 02 Jun 2012 22:48:23 +0200
From: "Matthias P. Braendli" <[email protected]>
To: [email protected]
Subject: [USRP-users] Transmission with timestamps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Dear USRP-Users,
I am transmitting a stream (without any interruption) of data to the
USRP (I have both a B100 and a USRP2) using a C++ program. All the
packets[1] have a timestamp.
Now, what poses a problem is that once in a while, I want to change my
timestamps a bit (creating a small gap in transmission, or dropping a
few samples). But, as long as there are no underruns, the FSM in
vita_tx_control seems to stay in IBS_RUN and IBS_CONT_BURST (that's only
a hypothesis), and ignores the timestamps that have changed. I only
observe the change if I force an underrun (e.g. by suspending my
software a short instant).
What is the best way to make the USRP reconsider the timestamps while
the stream runs ? Is there a better way than dropping a packet, thereby
creating an underrun ?
I've also tried setting the end-of-burst, and with both
STREAM_MODE_NUM_SAMPS_AND_MORE and STREAM_MODE_START_CONTINUOUS
<http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html#a4df1f2e22148b7e09ace0eca0dfbf904a91fa979980d1a6de6bf861b8459ed5c3>,
but I get a lot of late packets (prints 'L' on the console). This
approach seemed to be better, because the FSM would go back to IBS_IDLE,
but I'm not sure I'm doing it right.
Furthermore, I have not quite understood what the stream mode
influences. Is it changing the policy_next_packet and policy_next_burst
in vita_tx_control.v ?
Best regards,
Matthias
[1]:
by "packet" I mean the data given to the tx_streamer::send function.
Please tell me if the official terminology differs.
------------------------------
Message: 5
Date: Sat, 02 Jun 2012 13:59:25 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Transmission with timestamps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> What is the best way to make the USRP reconsider the timestamps while
> the stream runs ? Is there a better way than dropping a packet, thereby
> creating an underrun ?
>
Basically, set the end of burst on the last TX packet.
Then send the next packet with a new time.
The examples/tx_bursts.cpp should demonstrate this.
> I've also tried setting the end-of-burst, and with both
> STREAM_MODE_NUM_SAMPS_AND_MORE and STREAM_MODE_START_CONTINUOUS
> <http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html#a4df1f2e22148b7e09ace0eca0dfbf904a91fa979980d1a6de6bf861b8459ed5c3>,
> but I get a lot of late packets (prints 'L' on the console). This
> approach seemed to be better, because the FSM would go back to IBS_IDLE,
> but I'm not sure I'm doing it right.
>
Maybe there is some confusion, but the STREAM_MODE/stream command stuff
only applies to the RX side of things, its independent of TX.
> Furthermore, I have not quite understood what the stream mode
> influences. Is it changing the policy_next_packet and policy_next_burst
> in vita_tx_control.v ?
>
This may help:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef
-josh
> Best regards,
>
> Matthias
>
> [1]:
> by "packet" I mean the data given to the tx_streamer::send function.
> Please tell me if the official terminology differs.
>
Too many layers and too many things are called packets :-)
I guess more specifically, its a "VRT IF data packet"
-josh
------------------------------
Message: 6
Date: Sat, 02 Jun 2012 20:05:36 -0700
From: Josh Blum <[email protected]>
To: James Jordan <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] dc offset is different
from unit to unit
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/02/2012 07:47 PM, James Jordan wrote:
> Hi John,
> Thanks. But how to deal with rx dc offset?
>
Long run RX DC level is subtracted out of the signal by default. You can
turn this behaviour on and off, and even freeze the average DC level at
its current value. See set_rx_dc_offset(...)
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html
-josh
> On 6/2/12, John Malsbury <[email protected]> wrote:
>> James,
>>
>> In the case of DC calibration for tx, we'd recommend running the dc
>> calibration routines provided with UHD for each unit. The cal routines
>> make it a relatively easy process.
>>
>> In theory, if the average DC offset is non-zero you may be able to apply
>> an average correction and see some improvement - but less than a
>> per-unit calibration. I don't have have any data on hand for an average
>> DC offset.
>>
>> I'm cross-posting to the usrp-users list, which is more oriented to USRP
>> specific questions.
>>
>> Best Regards
>> John Malsbury
>>
>>
>>
>> On 6/1/2012 8:57 PM, James Jordan wrote:
>>> Hi list,
>>> I need to compensate usrp dc offset. but the dc offset is different
>>> from unit to unit. so do I need to calibrate each unit dc offset or
>>> there is a universal value that work
>>> for each unit?
>>>
>>> Regards
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 7
Date: Sun, 3 Jun 2012 01:36:26 -0400
From: Nazmul Islam <[email protected]>
To: [email protected], [email protected], GNURadio Discussion
List <[email protected]>
Subject: Re: [USRP-users] What is the largest data transfer rate
between the PC & USRP2/USRP N Series through a GB ethernet cable?
Message-ID:
<CAFtrfEZyzHjmF2S_b_cdx0YQdN5iVohZOWM=v8ew2-8vtx0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am using gnuradio companion to transmit a BPSK modulated data. I have the
following questions:
1. Does the complex int16 data type of the UHD: USRP sink correspond to the
16 bit per complex sample scenario?
2. I don't need to transmit any Q data since I am using BPSK modulation. If
I connect a float data to the complex int16 input port of the USRP sink,
does the USRP consider the input as a 16 bit real data? The grc file
captured in the attached png picture shows the type of connection that I am
asking about.
Thanks,
Nazmul
On Wed, May 30, 2012 at 12:58 PM, Josh Blum <[email protected]> wrote:
>
>
> On 05/30/2012 07:11 AM, Nazmul Islam wrote:
> > Hello,
> >
> > I found a tutorial on GNUradio (
> > http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf) that mentions that
> USRP
> > downconverts the signal to 8 Mega Sample per second before passing it to
> > the USB cable. They do it due to the 32 Mega byte data transfer rate of
> USB
> > cable and 16 bit I & Q samples. I assume that this information applies to
> > USRP1 with USB cable.
> >
> > I am planning to use USRP2 & USRP N series along with GB ethernet cables
> in
> > my experiments. Do these USRP's downconvert the signal before passing on
> to
> > the computer? If my computer is fast enough, can I transmit and receive
> (in
> > seperate USRP's) a signal with 20 MHz bandwidth?
> >
>
> There is a downconversion and upconversion chain in the USRP. The
> practical rate limitations are 25 Msps at 32 bits per complex sample or
> 50 Msps at 16 bits per complex sample.
>
> Is your computer fast enough? Thats an open ended question, but if you
> can test your processing IP without a USRP pretty easily: send samples
> from another computer over GigE and benchmark performance to see if your
> application can process the samples fast enough.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Muhammad Nazmul Islam
Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120603/5484fd74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bit_per_sample.png
Type: image/png
Size: 131693 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120603/5484fd74/attachment-0001.png>
------------------------------
Message: 8
Date: Sun, 3 Jun 2012 17:43:56 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] GPSDO Support
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
If I have a GPSDO in a N210 do I have to issue any extra commands to enable
it, or is it really plug-in, connect Trimble Thunderbolt, and just use it?
I'm asking because I would only buy this if I have to issue commands,
otherwise for now it's not necessary (but would be very nice to have).
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/20120603/9d7a4ad6/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 22, Issue 3
*****************************************
