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: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Bastien Auneau)
2. Re: Problems with the C++ API (Josh Blum)
3. Announcing the LiveUSB SDR Environment (Matt Ettus)
4. Re: Oddity in E1xx FPGA (Almohanad Fayez)
5. Transceiver IC max2829 (Huldi Michael)
6. Broken gpsdo or bad antenna? (Dario Lombardo)
7. Re: Broken gpsdo or bad antenna? (John Malsbury)
8. Re: Transceiver IC max2829 (John Malsbury)
9. Re: Broken gpsdo or bad antenna? (Dario Lombardo)
10. Broken gpsdo or bad antenna? (John Malsbury)
11. Re: Broken gpsdo or bad antenna? (Nick Foster)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Jun 2012 18:49:59 +0200
From: Bastien Auneau <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID:
<CA+avJoYX=tdoovyaf3q8ceovtgz+bspk8c_s0xr3_tyspbw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi
My mistake...
I just choose the wrong compiler VC90 rather than VC90 x64 in Cmake
Don't do the same mistake as I've done, it will save you time ;-)
Best Regards
Bastien
On 18 June 2012 16:34, Bastien Auneau <[email protected]> wrote:
> Hi Josh
>
> You said :
> "
>
> You should tell CMake configure to use the MSVC 64 bit compiler. You
> shouldnt need to change or set any flags. It will just work (tm)
>
> You can simply open the MSVC x64 terminal and run:
> DevEnv uhd.sln /build Debug /project ALL_BUILD
>
> "
> in
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-June/004613.html
> But When I do not change the Additional flags (*/machine:X86 to
> /machine:X64*) and if I do not set manually all UHD solution sub-project
> to win64 using VS2008 Configuration Manager, the compilation simply fails.
> See attached file to see the output. It does not help to use the devenv
> command line
>
> And still, the example, utils and bin folders are not copied to the target
> folder when building INSTALL sub-project
>
> The list of issues for UHD Windows 64 bit is unchanged :
> _ this fixed (*
> http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420*) should be
> applied
> _ CMAKE_EXE_LINKER_FLAGS, CMAKE_MODULE_LINKER_FLAGS and
> CMAKE_SHARED_LINKER_FLAGS should be edited to replace /machine:x86 by
> /machine:x64
> _ each sub-project in UHD solution should be changed to platfomr x64,
> using configuration MAnager of Visual Studio (a bit time consuming)
> _ output of compilation for "example" "utils" and "bin" (uhd.lid .dll)
> folders is not copied to target dir when building INSTALL
>
> Using Windos 7, Boost 1.48 (to avoid the bug with VS2008 and 1.49), maint
> branch
>
> Best Regards
> Bastien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120618/ac74f4a7/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 18 Jun 2012 10:11:39 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems with the C++ API
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> How can I modify this peak value? Because in the source Files I didn't find
> any Attribute like peak to modify.
> Do I need to modify also the "rx_samples_to_file"-example?
>
> What have I to modify in addition to send/receive some sc8 samples over the
> wire?
>
I pushed to the master branch changes to the tx samples from file
example such that the sc8 mode over the wire is also a command line option.
To set peak, lets say for example, peak sample level is 80% of full
scale, make the following change: http://pastebin.com/9zKbZJjK
-josh
------------------------------
Message: 3
Date: Mon, 18 Jun 2012 13:57:22 -0700
From: Matt Ettus <[email protected]>
To: [email protected]
Subject: [USRP-users] Announcing the LiveUSB SDR Environment
Message-ID:
<CAN=1kn8SyEf=nbrrusx2hebe02cangmhgia_3werrq2gj06...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Ettus Research has released the LiveUSB SDR Environment - a 16 GB
bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10,
UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated
documentation. The SDR Environment enables users to get up and running
with the USRP product family quickly and easily, and lets users
familiarize themselves with the included software before installing it
on their own. ? Additionally, the portability of the LiveUSB file
system can be used to deploy standard configurations in classrooms,
R&D labs, or other USRP installations.
https://www.ettus.com/product/details/LiveUSB
Features:
* Ubuntu 11.10, 64-bit
* Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS
* Documentation Included on Drive
* 16 GB
* USB 3.0 Read/Write Speeds - fast boot times and RF record/playback capability
* USB 2.0 Fallback
* Persistent File system - save files, configurations, and other customizations
* Portability - take your projects with you and boot on any PC
The LiveUSB includes the most recent release of UHD, GNU Radio, and
OpenBTS. UHD is compatible with all USRP devices, and allows
applications to be easily ported across different USRP models. The
UHD installation includes documentation and examples. GNU Radio is an
easy-to-use, open-source, DSP toolbox that comes with GNU Radio
Companion, a graphical development tool. OpenBTS is an open-source
GSM air-interface implementation, which can be used with the USRP
product family to assemble a fully functional cellular base station.
The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio
from the Ettus Research 'apt' repositories. This allows users to
update the software without manually downloading, building, and
installing the source code.
This drive is compatible with USB 2.0 ports, but the system will take
longer to boot, load programs, and respond to user interaction.
Now, developing with the USRP product family is as easy as plugging in
the LiveUSB SDR Environment and booting up!
You can buy a USB 3 Flash Drive with the environment on it here:
https://www.ettus.com/product/details/LiveUSB
Matt Ettus
------------------------------
Message: 4
Date: Mon, 18 Jun 2012 15:35:34 -0700
From: Almohanad Fayez <[email protected]>
To: John Buetefuer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Oddity in E1xx FPGA
Message-ID:
<cabv+bnvz4s0xe2s5wkyb5mxnh5woblmcmrh_xfnggxnago4...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
John, I just found out that the E100 can in fact read RS232 through
the J86 connector as detailed in the Ettus GPSDO datasheet. I
apologize for that.
On Thu, May 31, 2012 at 5:49 PM, John Buetefuer
<[email protected]> wrote:
> Thanks Almohanad.. Do you know if the up-to-date E100 schematics are
> available? I assume the differences are not huge between revisions, but it's
> always good to have correct information.
>
> Cheers
>
> John
>
>
> On 31/05/2012 2:12 AM, Almohanad Fayez wrote:
>>
>> To answer your FPGA/GPS/serial question, ?the FPGA image doesn't read
>> in the RS232 values it just takes PPS and the 10 MHz reference signal.
>>
>>
>> On Tue, May 29, 2012 at 10:10 PM, John Buetefuer
>> <[email protected]> ?wrote:
>>>
>>> It appears I may have spoken too soon. If I remove these signals the port
>>> stops working, which suggests that I have outdated schematics for the
>>> E100.
>>>
>>> Are the latest E100/E110 schematics available? (Rev4?)
>>>
>>> Cheers
>>>
>>> John
>>>
>>>
>>> On 30/05/2012 1:15 PM, John Buetefuer wrote:
>>>>
>>>> I've just commenced integrating a 3rd party GPS unit (ie, not a GPSDO)
>>>> with an E100 and have noticed the following odd things with the E100
>>>> FPGA
>>>> and schematics.
>>>>
>>>> * The FPGA appears to be driving the overo_rxd1 net (and uart Rx input
>>>> pin
>>>> on the overo) with a signal from the FPGA input pin "fpga_rxd1" (ball
>>>> AB8) -
>>>> which according to my schematics is not connected on the PCB at all
>>>> (presume
>>>> this is pulled high by the FPGA I/O pull-ups).
>>>> ?[fpga/usrp2/top/E1x0/u1e.v]
>>>>
>>>> ? //
>>>>
>>>> /////////////////////////////////////////////////////////////////////////
>>>> ? // UART level conversion
>>>> ? assign fpga_txd1 = overo_txd1;
>>>> ? assign overo_rxd1 = fpga_rxd1;
>>>>
>>>> overo_rxd1 is defined as an output pin, which sees it driving against
>>>> the
>>>> MAX232 driving this line - surely this is not correct or intended.?
>>>>
>>>> It looks to me that this code may have had some historical purpose on an
>>>> earlier rev of the board, but perhaps with the current version of the
>>>> hardware, is not correct?
>>>>
>>>> On a somewhat related note, can someone confirm that on the E1x0 series
>>>> units, the FPGA firmware does not communicate with the GPSDO unit at all
>>>> (via RS232), and that the UHD accesses the GPS via the Overo serial port
>>>> (ttyO0)?
>>>>
>>>> Cheers
>>>>
>>>> John
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>
--
Almohanad (Al) Fayez
------------------------------
Message: 5
Date: Tue, 19 Jun 2012 11:33:25 +0200
From: Huldi Michael <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Transceiver IC max2829
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
In the datasheet of the transceiver IC MAX2829, which is on the daughterboard
xcvr2450, I read that the reference oscillator input on pin 30 need to be 20 -
44 MHz. But I measured a clock of 50 MHz on this pin. Does someone have an
explanation for that?
I have to know this because I write my own driver in C for the transceiver IC.
The transceiver IC is driven of my microblaze via SPI. Perhaps someone has
already done similar work?!
Huldi Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/0e68ced3/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 19 Jun 2012 13:01:25 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Subject: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<caoyjjfubxdsu1j0wby3-nkhw9x0de9g8iuzo+kpgpc-kta6...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all
After many tries with my gpsdo, I still can't get a good clock.
I've written a sw that continuously polls the gps_locked and the ref_locked
sensors. Both of them are always locked, that means that my antenna is
getting a quite "clear" sky view.
I've connected the front panel connectors of my N210 to a cesium clock/pps
generator, and I get 2 to 0 Hz of error with kal. That should mean that my
usrp works fine and the kal commands are good.
I've left the usrp turned on, with the gps antenna connected, for over 20
hours, but kal still gives me around 11 kHz of error.
I think that one of these 2 things is happening:
1) my gpsdo card is broken. What can I do to ensure that this is not the
case? And if this is the case, what can I do?
2) my antenna can't give a signal that is clear enough, so the gpsdo isn't
unable to give me the clock.
What do you think about the above cases?
Any help appreciated.
Dario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/5eaedf86/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 19 Jun 2012 04:14:54 -0700
From: John Malsbury <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<can5wegqkazx-rtlpfy3riahx1insc905da3ylul1opsh3k3...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dario,
Forgive me if I am not able to see your previous posts as I am answering
from my phone. Are you saying there is
11 khz of error in the 10 mhz ref, or some frequency set to a daughterboard
LO?
You mention using an external reference. I don't think you would achieve
lock if this were the issue, but have you ensured the jumper is in the
proper configuration? Are you selecting default or external as the ref
source in your software?
John
On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
wrote:
> Hi all
> After many tries with my gpsdo, I still can't get a good clock.
> I've written a sw that continuously polls the gps_locked and the
ref_locked sensors. Both of them are always locked, that means that my
antenna is getting a quite "clear" sky view.
> I've connected the front panel connectors of my N210 to a cesium
clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
mean that my usrp works fine and the kal commands are good.hu
> I've left the usrp turned on, with the gps antenna connected, for over 20
hours, but kal still gives me around 11 kHz of error.
> I think that one of these 2 things is happening:
> 1) my gpsdo card is broken. What can I do to ensure that this is not the
case? And if this is the case, what can I do?
> 2) my antenna can't give a signal that is clear enough, so the gpsdo
isn't unable to give me the clock.
> What do you think about the above cases?
> Any help appreciated.
> Dario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/26941e19/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 19 Jun 2012 04:22:36 -0700
From: John Malsbury <[email protected]>
To: Huldi Michael <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Transceiver IC max2829
Message-ID:
<can5wegr7-uzoeq3qekrjavwr4xcry_8pxdc_wjrj9f0f6la...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Are you developing this on a usrp, with an xcvr2450?
John
On Tuesday, June 19, 2012, Huldi Michael <[email protected]> wrote:
> Hello,
>
> In the datasheet of the transceiver IC MAX2829, which is on the
daughterboard xcvr2450, I read that the reference oscillator input on pin
30 need to be 20 ? 44 MHz. But I measured a clock of 50 MHz on this pin.
Does someone have an explanation for that?
>
> I have to know this because I write my own driver in C for the
transceiver IC. The transceiver IC is driven of my microblaze via SPI.
Perhaps someone has already done similar work?!
>
> Huldi Michael
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/9154fd04/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 19 Jun 2012 13:26:31 +0200
From: Dario Lombardo <[email protected]>
To: John Malsbury <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<caoyjjfug+rqzfw+lsunztepykm2vaugcfes3fth1bmc2xhh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh
On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>wrote:
> Dario,
>
> Forgive me if I am not able to see your previous posts as I am answering
> from my phone. Are you saying there is
> 11 khz of error in the 10 mhz ref, or some frequency set to a
> daughterboard LO?
>
I'm saying that error is the output of kalibrate.
>
> You mention using an external reference. I don't think you would achieve
> lock if this were the issue, but have you ensured the jumper is in the
> proper configuration?
When using the front panel connectors, I moved the jumper J510 to select
them. In this case I got 0 Hz of error at my first try. To be sure, I
disconnected the gpsdo from the mainboard.
> Are you selecting default or external as the ref source in your software?
>
When using the gpsdo, I moved the jumper J510, then configured the eeprom
to "internal". In this case I suppose that the N210 automatically selects
the gpsdo. In fact every time I run something I see
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Found a Jackson Labs GPS
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
no matter if any "external ref" is used or not. In kal, I got that error
with and without the "-x" switch.
> John
>
> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
> wrote:
> > Hi all
> > After many tries with my gpsdo, I still can't get a good clock.
> > I've written a sw that continuously polls the gps_locked and the
> ref_locked sensors. Both of them are always locked, that means that my
> antenna is getting a quite "clear" sky view.
> > I've connected the front panel connectors of my N210 to a cesium
> clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
> mean that my usrp works fine and the kal commands are good.hu
> > I've left the usrp turned on, with the gps antenna connected, for over
> 20 hours, but kal still gives me around 11 kHz of error.
> > I think that one of these 2 things is happening:
> > 1) my gpsdo card is broken. What can I do to ensure that this is not the
> case? And if this is the case, what can I do?
> > 2) my antenna can't give a signal that is clear enough, so the gpsdo
> isn't unable to give me the clock.
> > What do you think about the above cases?
> > Any help appreciated.
> > Dario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/cdba9ac2/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 19 Jun 2012 04:45:14 -0700
From: John Malsbury <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<can5wegtmubao54pqn+hkphiafk03eawevjj8r8uns0+k0k9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Just for grins, can you remove the eeprom config that enables the internal
gpsdo? What results do you see from kal when the internal tcxo on the
motherboard is used?
BTW, are you getting reasonable gga strings that correlate to your known
position?
John
On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
wrote:
> Hi Josh
>
> On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
wrote:
>>
>> Dario,
>>
>> Forgive me if I am not able to see your previous posts as I am answering
from my phone. Are you saying there is
>> 11 khz of error in the 10 mhz ref, or some frequency set to a
daughterboard LO?
>
> I'm saying that error is the output of kalibrate.
>
>>
>> You mention using an external reference. I don't think you would
achieve lock if this were the issue, but have you ensured the jumper is in
the proper configuration?
>
> When using the front panel connectors, I moved the jumper J510 to select
them. In this case I got 0 Hz of error at my first try. To be sure, I
disconnected the gpsdo from the mainboard.
>
>>
>> Are you selecting default or external as the ref source in your software?
>
> When using the gpsdo, I moved the jumper J510, then configured the eeprom
to "internal". In this case I suppose that the N210 automatically selects
the gpsdo. In fact every time I run something I see
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Found a Jackson Labs GPS
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> no matter if any "external ref" is used or not. In kal, I got that error
with and without the "-x" switch.
>>
>> John
>>
>> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
wrote:
>> > Hi all
>> > After many tries with my gpsdo, I still can't get a good clock.
>> > I've written a sw that continuously polls the gps_locked and the
ref_locked sensors. Both of them are always locked, that means that my
antenna is getting a quite "clear" sky view.
>> > I've connected the front panel connectors of my N210 to a cesium
clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
mean that my usrp works fine and the kal commands are good.hu
>> > I've left the usrp turned on, with the gps antenna connected, for over
20 hours, but kal still gives me around 11 kHz of error.
>> > I think that one of these 2 things is happening:
>> > 1) my gpsdo card is broken. What can I do to ensure that this is not
the case? And if this is the case, what can I do?
>> > 2) my antenna can't give a signal that is clear enough, so the gpsdo
isn't unable to give me the clock.
>> > What do you think about the above cases?
>> > Any help appreciated.
>> > Dario.
Just for grins, can you remove the eeprom config that enables the internal
gpsdo? What results do you see from kal when the internal tcxo on the
motherboard is used?
Are you getting reasonable gga strings that correlate to your known
position?
John
On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
wrote:
> Hi Josh
>
> On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
wrote:
>>
>> Dario,
>>
>> Forgive me if I am not able to see your previous posts as I am answering
from my phone. Are you saying there is
>> 11 khz of error in the 10 mhz ref, or some frequency set to a
daughterboard LO?
>
> I'm saying that error is the output of kalibrate.
>
>>
>> You mention using an external reference. I don't think you would
achieve lock if this were the issue, but have you ensured the jumper is in
the proper configuration?
>
> When using the front panel connectors, I moved the jumper J510 to select
them. In this case I got 0 Hz of error at my first try. To be sure, I
disconnected the gpsdo from the mainboard.
>
>>
>> Are you selecting default or external as the ref source in your software?
>
> When using the gpsdo, I moved the jumper J510, then configured the eeprom
to "internal". In this case I suppose that the N210 automatically selects
the gpsdo. In fact every time I run something I see
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Found a Jackson Labs GPS
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> no matter if any "external ref" is used or not. In kal, I got that error
with and without the "-x" switch.
>>
>> John
>>
>> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
wrote:
>> > Hi all
>> > After many tries with my gpsdo, I still can't get a good clock.
>> > I've written a sw that continuously polls the gps_locked and the
ref_locked sensors. Both of them are always locked, that means that my
antenna is getting a quite "clear" sky view.
>> > I've connected the front panel connectors of my N210 to a cesium
clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
mean that my usrp works fine and the kal commands are good.hu
>> > I've left the usrp turned on, with the gps antenna connected, for over
20 hours, but kal still gives me around 11 kHz of error.
>> > I think that one of these 2 things is happening:
>> > 1) my gpsdo card is broken. What can I do to ensure that this is not
the case? And if this is the case, what can I do?
>> > 2) my antenna can't give a signal that is clear enough, so the gpsdo
isn't unable to give me the clock.
>> > What do you think about the above cases?
>> > Any help appreciated.
>> > Dario.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120619/f599a749/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 19 Jun 2012 07:53:15 -0700
From: Nick Foster <[email protected]>
To: John Malsbury <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Broken gpsdo or bad antenna?
Message-ID:
<CALALHJV5cn8A=vK3WaLvAXZj0ZAXKYWW0Q=sq279f9t1va5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dario,
Also, please try configuring the USRP for "external" reference as you did
for the cesium test previously. Then connect the GPSDO to the external
reference input and see if kal gives reasonable error.
It does seem like you may have a faulty reference input.
--n
On Tue, Jun 19, 2012 at 4:45 AM, John Malsbury <[email protected]>wrote:
> Just for grins, can you remove the eeprom config that enables the internal
> gpsdo? What results do you see from kal when the internal tcxo on the
> motherboard is used?
>
> BTW, are you getting reasonable gga strings that correlate to your known
> position?
>
>
> John
>
> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
> wrote:
> > Hi Josh
> >
> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
> wrote:
> >>
> >> Dario,
> >>
> >> Forgive me if I am not able to see your previous posts as I am
> answering from my phone. Are you saying there is
> >> 11 khz of error in the 10 mhz ref, or some frequency set to a
> daughterboard LO?
> >
> > I'm saying that error is the output of kalibrate.
> >
> >>
> >> You mention using an external reference. I don't think you would
> achieve lock if this were the issue, but have you ensured the jumper is in
> the proper configuration?
> >
> > When using the front panel connectors, I moved the jumper J510 to select
> them. In this case I got 0 Hz of error at my first try. To be sure, I
> disconnected the gpsdo from the mainboard.
> >
> >>
> >> Are you selecting default or external as the ref source in your
> software?
> >
> > When using the gpsdo, I moved the jumper J510, then configured the
> eeprom to "internal". In this case I suppose that the N210 automatically
> selects the gpsdo. In fact every time I run something I see
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > -- Found a Jackson Labs GPS
> > -- Setting references to the internal GPSDO
> > -- Initializing time to the internal GPSDO
> > no matter if any "external ref" is used or not. In kal, I got that error
> with and without the "-x" switch.
> >>
> >> John
> >>
> >> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
> wrote:
> >> > Hi all
> >> > After many tries with my gpsdo, I still can't get a good clock.
> >> > I've written a sw that continuously polls the gps_locked and the
> ref_locked sensors. Both of them are always locked, that means that my
> antenna is getting a quite "clear" sky view.
> >> > I've connected the front panel connectors of my N210 to a cesium
> clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
> mean that my usrp works fine and the kal commands are good.hu
> >> > I've left the usrp turned on, with the gps antenna connected, for
> over 20 hours, but kal still gives me around 11 kHz of error.
> >> > I think that one of these 2 things is happening:
> >> > 1) my gpsdo card is broken. What can I do to ensure that this is not
> the case? And if this is the case, what can I do?
> >> > 2) my antenna can't give a signal that is clear enough, so the gpsdo
> isn't unable to give me the clock.
> >> > What do you think about the above cases?
> >> > Any help appreciated.
> >> > Dario.
>
> Just for grins, can you remove the eeprom config that enables the internal
> gpsdo? What results do you see from kal when the internal tcxo on the
> motherboard is used?
>
> Are you getting reasonable gga strings that correlate to your known
> position?
>
>
> John
>
> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
> wrote:
> > Hi Josh
> >
> > On Tue, Jun 19, 2012 at 1:14 PM, John Malsbury <[email protected]>
> wrote:
> >>
> >> Dario,
> >>
> >> Forgive me if I am not able to see your previous posts as I am
> answering from my phone. Are you saying there is
> >> 11 khz of error in the 10 mhz ref, or some frequency set to a
> daughterboard LO?
> >
> > I'm saying that error is the output of kalibrate.
> >
> >>
> >> You mention using an external reference. I don't think you would
> achieve lock if this were the issue, but have you ensured the jumper is in
> the proper configuration?
> >
> > When using the front panel connectors, I moved the jumper J510 to select
> them. In this case I got 0 Hz of error at my first try. To be sure, I
> disconnected the gpsdo from the mainboard.
> >
> >>
> >> Are you selecting default or external as the ref source in your
> software?
> >
> > When using the gpsdo, I moved the jumper J510, then configured the
> eeprom to "internal". In this case I suppose that the N210 automatically
> selects the gpsdo. In fact every time I run something I see
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > -- Found a Jackson Labs GPS
> > -- Setting references to the internal GPSDO
> > -- Initializing time to the internal GPSDO
> > no matter if any "external ref" is used or not. In kal, I got that error
> with and without the "-x" switch.
> >>
> >> John
> >>
> >> On Tuesday, June 19, 2012, Dario Lombardo <[email protected]>
> wrote:
> >> > Hi all
> >> > After many tries with my gpsdo, I still can't get a good clock.
> >> > I've written a sw that continuously polls the gps_locked and the
> ref_locked sensors. Both of them are always locked, that means that my
> antenna is getting a quite "clear" sky view.
> >> > I've connected the front panel connectors of my N210 to a cesium
> clock/pps generator, and I get 2 to 0 Hz of error with kal. That should
> mean that my usrp works fine and the kal commands are good.hu
> >> > I've left the usrp turned on, with the gps antenna connected, for
> over 20 hours, but kal still gives me around 11 kHz of error.
> >> > I think that one of these 2 things is happening:
> >> > 1) my gpsdo card is broken. What can I do to ensure that this is not
> the case? And if this is the case, what can I do?
> >> > 2) my antenna can't give a signal that is clear enough, so the gpsdo
> isn't unable to give me the clock.
> >> > What do you think about the above cases?
> >> > Any help appreciated.
> >> > Dario.
> >
>
> _______________________________________________
> 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/20120619/ade3c7c2/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 19
******************************************
