Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: USRP B200 TX Max IQ Values (Ian Buckley)
2. Re: Missing step for RFNOC XML build (Martin Braun)
3. Re: Missing step for RFNOC XML build (Jason Matusiak)
4. Please Help whit GPSDO (OCXO) (Yamith Becerra Chaves)
5. Re: Please Help whit GPSDO (OCXO) (Marcus M?ller)
6. Re: [Discuss-gnuradio] Please Help whit GPSDO (OCXO)
(Derek Kozel)
7. Measure the power using USRP (w xd)
8. Re: Measure the power using USRP (Marcus M?ller)
9. Re: [Discuss-gnuradio] U32 type for module output (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Dec 2015 09:04:50 -0800
From: Ian Buckley <i...@ionconcepts.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
Message-ID: <8594bc77-7119-4ca3-a4fa-70997a69d...@ionconcepts.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
You should be able to set up a full loopback test including USRP via one of the
internal digital loopback paths with sample_rate=master_clock_rate+CORDIC=0 and
get bit accurate sample coverage of the whole data path+converters(FPGA and
host)
-Ian
On Dec 7, 2015, at 1:11 AM, Marcus M?ller via USRP-users
<usrp-users@lists.ettus.com> wrote:
> Hi Ron,
>
>> I did some more testing on this today. First, sc16 input works fine with
>> both complex int8 and int16 wire format. The correct scaling from complex
>> float is 32768, not 2048.
> ha! Good catch.
>> A wild guess is that some of the lower bits of each int12 sample are being
>> lost (set to zero).
> Hm, that sounds like we'll have some debugging to do.
> The unit tests for converters we have in place simply do a loopback, so, for
> example, they do float->sc12_item32_le->float and compare the in- and output
> to be approximately the same. So, first I'll have to verify that one.
>
> I think I'll do the following:
> Generate a 2**15 amplitude sine, send it as sc16->sc12
> capture traffic, make sure the right data is sent to the device
> if 2. succeeds, verify the right data comes out of the FX3
> if 3. succeeds,...
> Hope I can ping you about progress later on.
> Cheers,
> Marcus
>
> On 07.12.2015 05:36, Ron Economos via USRP-users wrote:
>> I did some more testing on this today. First, sc16 input works fine with
>> both complex int8 and int16 wire format. The correct scaling from complex
>> float is 32768, not 2048.
>>
>> The output with fc32 input and int12 wire format appears to be good on the
>> spectrum analyzer. The level is the same as int8 and int16 and there's no
>> obvious distortion. It just doesn't decode with the DVB-T2 receiver. The
>> receiver does show a video frame occasionally, so the signal isn't
>> completely wrong. But it's going from 35 dB (with int8) to 38 dB (with
>> int16) S/N to not being able to maintain lock.
>>
>> A wild guess is that some of the lower bits of each int12 sample are being
>> lost (set to zero).
>>
>> Ron
>>
>> On 12/06/2015 06:34 AM, Ron Economos via USRP-users wrote:
>>> I'm using a sample rate of 6.85717 Msps ((8000000 * 6) / 7) and a 4X clock
>>> rate of 27.428572 MHz. I can see the receiver reported S/N ratio drop a few
>>> dB from int16 to int8 as expected.
>>>
>>> I can't seem to get sc16 input working either. I'm taking the known good
>>> fc32 output, multiplying by 2048 and using the Complex to IShort type
>>> converter block with the vector output.
>>>
>>> Ron
>>>
>>> On 12/06/2015 05:57 AM, Marcus M?ller via USRP-users wrote:
>>>> Hi Ron,
>>>> hm, that's interesting. Are you using a factor between your sample rate
>>>> and the master_clock_rate?
>>>>
>>>> Point is that I'd expect sc16 to really decrease quantization noise
>>>> compared to sc12 if you're using sufficient oversampling -- the increased
>>>> bit width is actually used during interpolation to the master clock rate
>>>> by the DSP logic, although the DAC is only 12bit.
>>>> Now, you say that int8 works ? that really worries me. I'm scratching my
>>>> head profoundly. Maybe someone else can comment on this?
>>>>
>>>> Can you try with input sc16 and output sc8?
>>>>
>>>> Cheers,
>>>> Marcus
>>>>
>>>> On 06.12.2015 14:48, Ron Economos via USRP-users wrote:
>>>>> I just gave Input Type = Complex float32 and Wire Format = Complex int12
>>>>> a try here on a B210 with the DVB-T2 OFDM transmitter. The output appears
>>>>> to be too distorted to decode. Wire Format Complex int16 and int8 work
>>>>> fine.
>>>>>
>>>>> Ron
>>>>>
>>>>> On 12/06/2015 05:25 AM, Marcus M?ller via USRP-users wrote:
>>>>>> Ok, good news is: I can reproduce; bad news is: I can reproduce. Running
>>>>>> a similar flow graph:
>>>>>> <Mail Attachment.png>
>>>>>> I get the same error; running it with "export UHD_LOG_LEVEL=1" before
>>>>>> yields the usual /tmp/uhd.log, which, with a bit of sed magic, yields
>>>>>> the following input/output table[1].
>>>>>> concentrating on the sc12_* output converters shows that there's only
>>>>>> fc32c ? sc12_item32 conversion; since converters are a bit critical when
>>>>>> it comes to quality assurance, I guess I can try to come up with an
>>>>>> untested converter quickly, but it might not happen overly soon that we
>>>>>> include that with the official UHD; so for the maintime, I'm afraid my
>>>>>> advice has only been half-good, and you'd need to use float32 complex on
>>>>>> the GNU Radio side.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> [1]
>>>>>> input
>>>>>> output
>>>>>> f32 f32_item32_be
>>>>>> f32 f32_item32_le
>>>>>> f32_item32_be f32
>>>>>> f32_item32_le f32
>>>>>> fc32 fc32_item32_be
>>>>>> fc32 fc32_item32_be
>>>>>> fc32 fc32_item32_le
>>>>>> fc32 fc32_item32_le
>>>>>> fc32_item32_be fc32
>>>>>> fc32_item32_be fc32
>>>>>> fc32_item32_be fc64
>>>>>> fc32_item32_le fc32
>>>>>> fc32_item32_le fc32
>>>>>> fc32_item32_le fc64
>>>>>> fc32 sc12_item32_be
>>>>>> fc32 sc12_item32_le
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item32_be
>>>>>> fc32 sc16_item32_be
>>>>>> fc32 sc16_item32_le
>>>>>> fc32 sc16_item32_le
>>>>>> fc32 sc8_item32_be
>>>>>> fc32 sc8_item32_be
>>>>>> fc32 sc8_item32_le
>>>>>> fc32 sc8_item32_le
>>>>>> fc64 fc32_item32_be
>>>>>> fc64 fc32_item32_le
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item32_be
>>>>>> fc64 sc16_item32_be
>>>>>> fc64 sc16_item32_le
>>>>>> fc64 sc16_item32_le
>>>>>> fc64 sc8_item32_be
>>>>>> fc64 sc8_item32_be
>>>>>> fc64 sc8_item32_le
>>>>>> fc64 sc8_item32_le
>>>>>> item32 item32
>>>>>> item32 sc16_item32_be
>>>>>> item32 sc16_item32_le
>>>>>> s16_item32_be s16
>>>>>> s16_item32_le s16
>>>>>> s16 s16_item32_be
>>>>>> s16 s16_item32_le
>>>>>> s8_item32_be s8
>>>>>> s8_item32_le s8
>>>>>> s8 s8_item32_be
>>>>>> s8 s8_item32_le
>>>>>> sc12_item32_be fc32
>>>>>> sc12_item32_le fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be item32
>>>>>> sc16_item32_be sc16
>>>>>> sc16_item32_be sc16
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le item32
>>>>>> sc16_item32_le sc16
>>>>>> sc16_item32_le sc16
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item32_be
>>>>>> sc16 sc16_item32_be
>>>>>> sc16 sc16_item32_le
>>>>>> sc16 sc16_item32_le
>>>>>> sc16 sc8_item32_be
>>>>>> sc16 sc8_item32_be
>>>>>> sc16 sc8_item32_le
>>>>>> sc16 sc8_item32_le
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be sc16
>>>>>> sc8_item32_be sc16
>>>>>> sc8_item32_be sc8
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le sc16
>>>>>> sc8_item32_le sc16
>>>>>> sc8_item32_le sc8
>>>>>> sc8 sc8_item32_be
>>>>>> sc8 sc8_item32_le
>>>>>> u8_item32_be u8
>>>>>> u8_item32_le u8
>>>>>> u8 u8_item32_be
>>>>>> u8 u8_item32_le
>>>>>>
>>>>>>
>>>>>> On 06.12.2015 13:49, Marcus M?ller wrote:
>>>>>>> That's indeed a bit strange. Give me a second to verify, please.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 03.12.2015 19:47, Andrew Wells wrote:
>>>>>>>> I'm now using the "short" file output and a "stream to vector" block
>>>>>>>> to deinterleave into IQ samples, along with a "complex int16" input to
>>>>>>>> the USRP sink. Due to my high sample rate, I need to set the OTW
>>>>>>>> format to sc12 to avoid underflow, but now it gives me the following
>>>>>>>> error when I run:
>>>>>>>>
>>>>>>>> thread[thread-per-block[2]: <block gr uhd usrp sink (1)>]:
>>>>>>>> LookupError: KeyError: Cannot find a conversion routine for conversion
>>>>>>>> ID
>>>>>>>> Input format: sc16
>>>>>>>> Num inputs: 1
>>>>>>>> Output format: sc12_item32_le
>>>>>>>> Num outputs: 1
>>>>>>>>
>>>>>>>> Does this mean that it cannot convert from 16 bits to 12 bits? There
>>>>>>>> was no issue when using a complex float32 input and OTW format sc12.
>>>>>>>>
>>>>>>>> Thanks again,
>>>>>>>> Andrew
>>>>>>>> ________________________________________
>>>>>>>> From: Marcus M?ller [marcus.muel...@ettus.com]
>>>>>>>> Sent: Thursday, December 03, 2015 10:14 AM
>>>>>>>> To: Andrew Wells; Andrew Wells via USRP-users; Marcus D. Leech;
>>>>>>>> usrp-users@lists.ettus.com
>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>
>>>>>>>> "Short" is 16 bit signed integer, so that's probably what you're
>>>>>>>> looking for.
>>>>>>>>
>>>>>>>> By the way, as much as a GNU Radio fanboy I might be, for this simple
>>>>>>>> use case the tx_samples_from_file example that we ship with UHD will
>>>>>>>> do the same, without GNU Radio.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> Am 3. Dezember 2015 17:55:08 WEZ, schrieb Andrew Wells via USRP-users
>>>>>>>> <usrp-users@lists.ettus.com>:
>>>>>>>>
>>>>>>>> Is there a way to get 16 bit complex values from a file? The only
>>>>>>>> options I see are complex, float, int, short, and byte. I have tried
>>>>>>>> selecting "int" as the output of the file source block but it seemed
>>>>>>>> like the USRP sink did not interpret it correctly and would not allow
>>>>>>>> me to set "sc12" as the otw format.
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
>>>>>>>> Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]
>>>>>>>> Sent: Wednesday, December 02, 2015 5:15 PM
>>>>>>>> To: usrp-users@lists.ettus.com
>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>
>>>>>>>> On 12/02/2015 07:59 PM, Andrew Wells via USRP-users wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am working on a project where my GNU Radio flowgraph is as follows:
>>>>>>>>
>>>>>>>> 16 bit int I/Q samples from a binary file -> Interleaved short to
>>>>>>>> complex -
>>>>>>>> >
>>>>>>>> USRP Sink with OTW format = sc12
>>>>>>>>
>>>>>>>> I have a few questions related to this setup:
>>>>>>>>
>>>>>>>> 1. Is there a better way to get 16 bit I/Q samples from a binary file
>>>>>>>> to the USRP? Converting to complex (32 bit float) seems like an
>>>>>>>> unnecessary step, considering that I am only actually sending 12 bits
>>>>>>>> to the USRP and 10 to the DAC.
>>>>>>>>
>>>>>>>> 2. What value stored in the binary file will correspond to the max
>>>>>>>> output from the DAC on the USRP? When I convert from 16 bit int to 32
>>>>>>>> bit float to 12 bits on the wire, then to transmit from the AD9364's
>>>>>>>> 10 bit DAC, how do I know what range of values to write to the file?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew Wells
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> USRP-users mailing list
>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>> The UHD sink will take 16-bit complex short. I think the converters
>>>>>>>> inside UHD will "do the right thing" to deal with getting that onto
>>>>>>>> the wire
>>>>>>>> in an appropriate way, and then the DSP logic in the B200 will scale
>>>>>>>> appropriately.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20151207/741d490a/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 7 Dec 2015 10:14:28 -0800
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Missing step for RFNOC XML build
Message-ID: <5665cc84.2010...@ettus.com>
Content-Type: text/plain; charset=windows-1252
This is a CMake annoyance: It doesn't re-check if there's a new XML file
since you didn't have to update the CMakeLists.txt. Frankly, I think
that's a bug in CMake, but nothing we can do about it right now.
You should be able to simply run CMake before you do make. If that
doesn't work, you can rm -rf include/uhd/rfnoc in your build folder and
re-build.
The segfault is another issue that recently came up and we'll fix that soon.
Cheers,
Martin
On 07.12.2015 05:34, Jason Matusiak via USRP-users wrote:
> I think I am missing a step in my RFNoC build. If I add my XML file to
> ~/pybombs/src/uhd/host/include/uhd/rfnoc/blocks, and then go to
> ~/pybombs/src/uhd/host/build and run a:
> make clean && make -j4 && make install
> I see things getting installed to my target directory (~/target/share),
> but if I look in : ~/target/share/uhd/rfnoc/blocks , I don't see my xml
> file in there, and a running of uhd_usrp_probe seg-faults when it gets
> to my new block. If I copy the xml file in by hand it is then happy.
>
> So my question is, what step am i missing for getting this to happen
> automagically?
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Mon, 07 Dec 2015 11:57:13 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Missing step for RFNOC XML build
Message-ID:
<20151207115713.ba066092a6e013ef68fa4f5a8d80e9ee.85066f6530....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> You should be able to simply run CMake before you do make. If that
> doesn't work, you can rm -rf include/uhd/rfnoc in your build folder and
> re-build.
Bingo, that was it. I had been looking at the CMakeLists and it didn't
appear that I needed to append any anywhere. I'll go ahead and modify
my notes to do that, thanks for the quick response.
> The segfault is another issue that recently came up and we'll fix that soon.
OK, it clued me into the issue, so isn't too big of a deal (since I
obviously had an issue). Will it throw an error now, or do something
else?
~Jason
------------------------------
Message: 4
Date: Mon, 7 Dec 2015 15:36:38 -0500
From: Yamith Becerra Chaves <yamith....@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Please Help whit GPSDO (OCXO)
Message-ID:
<cahqh68jcu8t2qpgk7yz_5ry5fx1v8cnnwhythompylq7bo_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HELLO,
I am new at this.
I have the USRP X310 and board mounted GPSDO (OXCO).
I installed UHD (3.9.0 version) and GNURadio.
I tried my USRP and my USRP detects GPSDO.
I want to put to work the GPS.
I want triangulate my position, preferably using GNURadio. I do not know
how to do this.
Can someone help me with this.
REGARDS
Yamith B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/fb18163e/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 7 Dec 2015 22:09:56 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com, GNURadio Discussion List
<discuss-gnura...@gnu.org>
Subject: Re: [USRP-users] Please Help whit GPSDO (OCXO)
Message-ID: <5665f5a4.2030...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hello Yamith!
Those are two different things:
the GPSDO is a full GPS receiver. Its job is to give your X310 a
reference oscillator that is controlled by the GPS clock, a very high
quality clock, and a pulse per second, so that you can set the time in
the device very exactly.
To decode GPS signals in software, you don't have to use the GPSDO. You
can use different approaches, but probably you want to use gnss-sdr from
gnss-sdr.com
Best regards,
Marcus
On 07.12.2015 21:36, Yamith Becerra Chaves via USRP-users wrote:
> HELLO,
>
> I am new at this.
>
> I have the USRP X310 and board mounted GPSDO (OXCO).
>
> I installed UHD (3.9.0 version) and GNURadio.
> I tried my USRP and my USRP detects GPSDO.
>
> I want to put to work the GPS.
>
> I want triangulate my position, preferably using GNURadio. I do not
> know how to do this.
>
> Can someone help me with this.
>
> REGARDS
>
> Yamith B.
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20151207/6baa49a8/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 7 Dec 2015 15:03:18 -0800
From: Derek Kozel <derek.ko...@ettus.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>,
GNURadio Discussion List <discuss-gnura...@gnu.org>
Subject: Re: [USRP-users] [Discuss-gnuradio] Please Help whit GPSDO
(OCXO)
Message-ID:
<CAA+K=tvpcea5phkmolc-+w8t+gac4qgdy1_x9k7ayg2gtp_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Yamith,
Marcus has pointed you towards a software defined GPS receiver if you want
to work with the GPS radio signals as part of your project. If you only
wish to know your location you can read the GPS position using the sensor
API in UHD. This manual page covers reading the X310's GPS position. The
gps_gpgga sensor will give a standard NMEA string with the device's
position after the GPS has locked.
http://files.ettus.com/manual/page_gpsdo_x3x0.html
There is a C++ example included with UHD.
https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp
Regards,
Derek
On Mon, Dec 7, 2015 at 1:09 PM, Marcus M?ller <marcus.muel...@ettus.com>
wrote:
> Hello Yamith!
>
> Those are two different things:
> the GPSDO is a full GPS receiver. Its job is to give your X310 a reference
> oscillator that is controlled by the GPS clock, a very high quality clock,
> and a pulse per second, so that you can set the time in the device very
> exactly.
>
> To decode GPS signals in software, you don't have to use the GPSDO. You
> can use different approaches, but probably you want to use gnss-sdr from
> gnss-sdr.com
>
> Best regards,
> Marcus
>
>
> On 07.12.2015 21:36, Yamith Becerra Chaves via USRP-users wrote:
>
> HELLO,
>
> I am new at this.
>
> I have the USRP X310 and board mounted GPSDO (OXCO).
>
> I installed UHD (3.9.0 version) and GNURadio.
> I tried my USRP and my USRP detects GPSDO.
>
> I want to put to work the GPS.
>
> I want triangulate my position, preferably using GNURadio. I do not know
> how to do this.
>
> Can someone help me with this.
>
> REGARDS
>
> Yamith B.
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/0e324a16/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 8 Dec 2015 10:34:06 +0800
From: w xd <wxd920...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>,
GNURadio Discussion List <discuss-gnura...@gnu.org>
Subject: [USRP-users] Measure the power using USRP
Message-ID:
<ca+va9qdb5buz4vpzmh3wngy9xmfaf851ym4bbp-xdw1bnqj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I want to measure the power.I'm now transmit the OFDM signal.
I use the usrp to receive data,and I save it to a file.I read all the
data.Then:
I use the formula to calculate the power:
10*log10(sum(abs(data).^2)/0.001) dbm
Is it the right way to calculate the power under the ofdm?
Thanks.
Best Regards,
z sw
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151208/1729d360/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 8 Dec 2015 12:17:03 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] Measure the power using USRP
Message-ID: <5666bc2f.3070...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
To emphasize on what the other Marcus said:
GNU Radio only knows numbers, not physical units. The USRP delivers
numbers, relative to full ADC range, to the computer. What these numbers
represent depends on a lot of factors, most of which are in the analog
domain and different for every device, every application etc.
Now, the USRPs and their daughterboards are pretty linear for a very
large range of powers [1], so you can measure once with a signal source
of known power (a /standard/), and derive a factor between "digital
number power" and "physical receiver power" for a given
frequency/bandwidth/gain/sample rate/antenna/... configuration, as long
as the powers you observe don't leave the linear range (again, [1]).
Problem is: OFDM is notorious for having a large dynamic range due to
its potentially high PAPR. Usually, you configure your receiver gain so
that it gets a high signal power out of OFDM symbols that have a modest
PAPR, because it's not as bad to lose a bit of precision with a symbol
that has an extreme PAPR as to constantly have bad SNR. Now, for exactly
these high-PAPR symbols, your receiver gets pushed into nonlinearity,
and then your power estimate will be a little too low (if you're not
really tricky about correcting that, but that would be very close to
equalization based on data knowledge, and has little to do with receive
strength).
So: get yourself a signal source of known power, connect it to your
USRP, state *very* clearly what you use as a reference (makes a
difference whether you incorporate antenna efficiency or not, for
example), and run a quick calibration, then you'll have a factor between
digital power and physical power. Be aware that for high digital powers,
your physical power estimate is less exact.
Best regards,
Marcus
[1] compare your daughterboard's data from
http://files.ettus.com/performance_data/
On 08.12.2015 04:38, Marcus D. Leech wrote:
> On 12/07/2015 10:25 PM, w xd wrote:
>> Thanks.
>>
>> What is the deviation between the result calculate by the
>> formula and the result measured by the calibration source for the
>> USRP N210? For example,when I ues the formula:10*log10(var(x))+30 to
>> calculate the power of the receiver data is -20dbm.What is the true
>> range for the true result?
>> Thanks.
>>
> I can't tell you that, because there's the whole bit about:
>
> frequency/bandwidth/gain/sample-rate
>
> The numbers you get out of the end of a Gnu Radio are (largely)
> linearly-proportional to the power as seen at the antenna inputs.
> The purpose of using an external calibration source is to determine
> what the proportionality constants are for each of your
> configurations of settings of frequency/bandwidth/gain/sample-rate.
>
> The FFTs in Gnu Radio necessarily can only show dB relative to
> full-scale. Gnu Radio has no way of knowing what those actually
> correspond to in terms of power as seen at the antenna terminals.
>
>
>>
>>
>> 2015-12-08 10:53 GMT+08:00 Marcus D. Leech <mle...@ripnet.com
>> <mailto:mle...@ripnet.com>>:
>>
>> On 12/07/2015 09:34 PM, w xd wrote:
>>
>> Hi,
>> I want to measure the power.I'm now transmit the OFDM signal.
>>
>> I use the usrp to receive data,and I save it to a file.I
>> read all the data.Then:
>> I use the formula to calculate the power:
>> 10*log10(sum(abs(data).^2)/0.001) dbm
>> Is it the right way to calculate the power under the ofdm?
>> Thanks.
>>
>> Best Regards,
>> z sw
>>
>> Instantaneous signal power is proportional to:
>>
>> (I**2)+(Q**2)
>>
>> You can average that to whatever interval you want, and then
>> scale (perhaps converting into dB, as above). But to determine
>> *absolute*
>> power at the antenna terminals you'll need a known calibration
>> source or two, and use that to come up with calibration constants for
>> your particular setup of frequency/gain/bandwidth/sample-rate.
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151208/4b0bb051/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 08 Dec 2015 06:06:10 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] U32 type for module
output
Message-ID:
<20151208060610.ba066092a6e013ef68fa4f5a8d80e9ee.ba3e59fe0e....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> No, there's not. If there's demand, we can add that of course. Do you
> actually need to *stream* u32 types? Will u8 work for you? You can
> re-cast it to whatever in your application.
Martin, I doubt that there is a high demand, I just sort of assumed
since the standard transport was for complex values (a pair of 16b ints)
that a 32b int was probably a baked in option.
I am sure I can make 8b work, I'll just have to work through how best to
shift it. Are there any gotchyas I need to be aware of (like handling
the smaller size within the CHDR frames differently), etc?
Thanks!
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 64, Issue 8
*****************************************
