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: using tune_request_t (Josh Blum)
2. Re: N200 Factory Clock (Nick Foster)
3. Re: I: Problem with multi-channel UHD version 003.004.001
(Josh Blum)
4. Re: Regarding the 112 decimation and 174 decimation factors
(Thomas Tsou)
5. Slow Frequency hopping using N2xx (Birhane Alemayoh)
6. Re: Slow Frequency hopping using N2xx (Thomas Tsou)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Jun 2012 10:07:12 -0700
From: Josh Blum <[email protected]>
To: Sanat Gulvadi <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] using tune_request_t
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/27/2012 05:52 AM, Sanat Gulvadi wrote:
> Hi Josh,
>
> I'm sorry for asking again. But could you please tell me if the following
> line will help push out the dc component outside my band.
> usrp->set_rx_freq(uhd::tune_request_t(2.44e9,100e6/32));
> Here I am trying to tune to 2.44 GHz and my sampling rate is 100e6/64.
> Should this work ?
>
That looks correct.
-josh
> Regards,
> Sanat
>
> On Tue, Jun 26, 2012 at 7:37 PM, Josh Blum <[email protected]> wrote:
>
>>
>>
>> On 06/26/2012 12:39 AM, Sanat Gulvadi wrote:
>>> Hi Josh,
>>> I actually read through those pages before I emailed the list. Just want
>> to
>>> know if lo_offset is the variable that represents the frequency offset by
>>> which I have to push the dc or if it's the frequency to which I want to
>> set
>>> the dc to.
>>
>> The constructor with the lo_offset will do exactly this.
>>
>>> Also is it necessary to set the policy to manual first ?
>>
>> No, the constructor with lo_offset sets this automatically.
>>
>> -josh
>>
>>> Regards, Sanat
>>> On Jun 26, 2012 8:30 AM, "Josh Blum" <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On 06/25/2012 11:17 PM, Sanat Gulvadi wrote:
>>>>> Greetings,
>>>>>
>>>>> I have a question about using the tune_request_t in my application. I
>>>> have
>>>>> read from previous posts that there is an inherent DC component at the
>>>>> receiver which cannot be eliminated but can be pushed so that it occurs
>>>>> outside the band of interest.
>>>>> When I use
>> usrp->set_rx_freq(uhd::tune_request_t(target_freq,lo_offset))
>>>> I
>>>>> am not sure what lo_offset is. I assume target_freq is the center freq
>> to
>>>>> which I want the RF to tune to. Is lo_offset the offset by which I want
>>>> to *
>>>>> push* the DC component so it ends up outside my band of interest ?
>>>>
>>>>
>>>> You might find helpful notes here:
>>>> http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
>>>>
>>>>
>>>>
>> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
>>>>
>>>>> So in this case, if I made lo_offset say, once or twice my sampling
>> rate,
>>>>> should this be enough to accomplish this? Do I have to additionally set
>>>> the
>>>>> tuning policy to POLICY_MANUAL ?
>>>>>
>>>>
>>>> That constructor w/ the LO offset is simply a shortcut for doing this.
>>>>
>>>> -josh
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>
>>
>
------------------------------
Message: 2
Date: Wed, 27 Jun 2012 10:30:49 -0700
From: Nick Foster <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N200 Factory Clock
Message-ID:
<CALALHJX6_gRXDywL-anKs_foT9=tmneztlgm3ucawppsxzg...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
On Wed, Jun 27, 2012 at 9:17 AM, Nowlan, Sean
<[email protected]>wrote:
> >For compatibility with other TCXOs that may be installed and require a
> pullup, a pulldown, or a divider for enable and frequency control. On the
> FOX924B installed on the N210 those components are not required.****
>
> >** **
>
> >--n****
>
> ** **
>
> Can I assume the bias network is not needed on the N200 either, and that
> it has no effect on its operation? Also, is the latest revision of N200
> still shipping with this same F924B part?****
>
> ** **
>
> The reason I?m asking is because we observed quite a bit of drift using a
> freq counter driven by a Rubidium reference. I used N200 with RFX900 and a
> simple GNU Radio app (Const source --> USRP) to transmit a 900 MHz CW. We
> downmixed the 900 MHz CW to 100 MHz by using an 800 MHz CW from a signal
> generator running off the same Rubidium reference. The freq counter only
> goes up to 225 MHz. So we observed a range of values within 350 Hz on the
> 100 MHz CW. This is within spec for the F924B part, and I know there?s a
> lot of freq synthesis, D/A conversion, and other stuff going on in the
> transmit chain, but what concerned us most was that the drift had high
> rates of change and near-discontinuities, rather than steady drift over a
> long period of time. Hence we were wondering whether the bias network was
> affecting the factory clock at all. A plot is attached. Thanks!
>
The FOX924B uses a digital loop with high and low digital step sizes. We've
noticed the same behavior, and it's definitely not optimal. The accuracy of
the part is well within specifications, but the steps produce the
occasional phase discontinuity. Future revisions of N200/N210 will use an
analog TCXO from another manufacturer that doesn't exhibit this phenomenon.
HTH,
Nick
> ****
>
> ** **
>
> Sean****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120627/e3c32430/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 27 Jun 2012 10:52:46 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] I: Problem with multi-channel UHD version
003.004.001
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/27/2012 07:09 AM, Paola Madonna wrote:
>
> Hi Josh,
> my bug is that I have updated the driver which I developed to acquire GPS
> and GLONASS signals to the new version of UHD 003.004.001 and I have
> observed strange behaviour such as the GPS samples files generated contains
> GLONASS samples and GLONASS samples files generated contains GPS samples.
> The driver which I have updated worked fine with the old version of UHD
> 003.002.003 but this same bug was when I used the UHD 003.001.000 and was
> fixed in the UHD 003.002.003.
> I fear that this could be a problem in the UHD 003.004.001 referred to the
> multiple channel such as in the UHD version 003.001.000.
>
Hey Paola,
It sounds like you are describing a channel swap. Its possible that
something was actually fixed in the recent release. I would like to
confirm the behaviour.
Can you send code snippets or tell me what arguments you pass into:
set_subdev_spec(...)
set_rx_freq(...)
get_rx_stream(...)
Thanks,
-Josh
------------------------------
Message: 4
Date: Wed, 27 Jun 2012 15:10:53 -0400
From: Thomas Tsou <[email protected]>
To: Birhane Alemayoh <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Regarding the 112 decimation and 174
decimation factors
Message-ID:
<caf5fesbmvcfz7by1abbmit13+63sgo9wbarj95lmun-sjwp...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 26, 2012 at 7:10 AM, Birhane Alemayoh <[email protected]> wrote:
> For GSM applications, many litratures recommended to use decimation factor
> of 112 for USRP1 and 174 for USRP2,? N2xxs to capture one GSM channle. But
> how can these decimation factors achieve a bandwidth of one? GSM channel.
> One GSM channel has a bandwidth of 200 kHz. But for a USRP N200? with 100MHz
> sampling rate for example;? if we use 174 decimation factor, we will end up
> with 100/174 =? 574.7KHz. This will be the input for our PC.
> So what is the reason behaind selecting 112 and 174?
> Thank you!!
GSM channels are spaced 200 kHz apart, but the channels are
overlapping; the sample rate needed to capture a signal without
bandlimiting is somewhat higher. The GSM symbol rate is 270.833 ksps
and sampling at two samples-per-symbol will give a sample rate close
to the listed values.
Thomas
------------------------------
Message: 5
Date: Thu, 28 Jun 2012 17:22:48 +0300
From: Birhane Alemayoh <[email protected]>
To: [email protected]
Subject: [USRP-users] Slow Frequency hopping using N2xx
Message-ID:
<capf4moy7dgc2hu2mgeaq8caoq++bydjiix3etsyztf7i3rj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I am working on GSM signal capturing and decoding. GSM uses slow Frequency
hopping, Does the current N2xx devices support frequency hopping,?
Can they really tune with the GSM hoping time?
Can I get any source code or any documentation for this?
Thank you!
Birhane
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120628/590caf62/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 28 Jun 2012 16:24:30 +0100
From: Thomas Tsou <[email protected]>
To: Birhane Alemayoh <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Slow Frequency hopping using N2xx
Message-ID:
<CAF5FEsBDf=itrHjdE8VLBxVy-Vkuh838-3aP=2puph_dg-v...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jun 28, 2012 at 3:22 PM, Birhane Alemayoh <[email protected]> wrote:
> Hi all,
>
> I am working on GSM signal capturing and decoding. GSM uses slow Frequency
> hopping, Does the current N2xx devices support frequency hopping,?
> Can they really tune with the GSM hoping time?
> Can I get any source code or any documentation for this?
The N2xx can support enough bandwidth to simultaneously capture any
reasonable set of hopped GSM carriers. In other words, tune the RF to
a single frequency, oversample the input, and downconvert each of the
individual carriers to baseband for decoding. This approach could be
referred to as baseband hopping with a single multicarrier receiver.
OpenBTS has this functionality, but not in the form of a standalone
scanner / decoder like Airprobe.
Thomas
------------------------------
_______________________________________________
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 28
******************************************
