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. GPSDO & B200 (Simon Brown)
2. Re: USRP x310 RF A TX Red LED (Ryan Marlow)
3. Re: GPSDO & B200 (Ben Hilburn)
4. Re: USRP2 Antenna for 2.4GHz-2.5GHz (Roland Awusie)
5. Re: GPSDO & B200 (Simon Brown)
6. Re: Loading USRP X3x0 by baseband processing functions
(Birhane Alemayoh)
7. Re: B100 + WBX Aliasing (Marcus M?ller)
8. Re: GPSDO & B200 (Marcus M?ller)
9. FW: GPSDO & B200 (Simon Brown)
10. Re: FW: GPSDO & B200 (Simon Brown)
11. [UHD 3.8.0-RC1] Release Candidate Announcement (Martin Braun)
12. Re: X3X0 SBX corrupted samples? (LEMENAGER Claude)
13. OctoClock Firmware Install (LEMENAGER Claude)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Oct 2014 17:20:43 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] GPSDO & B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
B200, no GPSDO, all is well.
B200 with GPSDO I get message handler status messages:
11:02:56> Ettus: UHD:Status
[chop]
11:02:56> Setting references to the internal GPSDO
11:02:56> Initializing time to the internal GPSDO
11:02:56> Ettus: UHD:Warning
11:02:56> get_time: ValueError: get_nmea(): no GPRMC message found
11:02:56> get_time: ValueError: get_nmea(): no GPRMC message found
11:02:56> Exception 00000A4E (2638), ValueError: Timeout after no valid
message found
And then usrp->get_rx_rates() returns an empty list. What documentation did
I not read?
Help appreciated, this is not my hardware, I only have the basic B200.
Simon Brown G4ELI
http://v2.sdr-radio.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141013/27a795d9/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 13 Oct 2014 13:43:13 -0400
From: Ryan Marlow <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP x310 RF A TX Red LED
Message-ID:
<CADVE_uzvT4p7cWpAEirzzAtoZdwWVPCbvWta61Gmy+1Pu1J=v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Martin, All,
I was worried that the LED mix up was an indication of something horribly
wrong with my USRP. I messed around with some other daughter boards and
configurations and I think I had just misconfigured some things because I
can now get data coming through. Thanks for the info.
Ryan
> Date: Mon, 13 Oct 2014 17:38:01 +0200
> From: Martin Braun <[email protected]>
> To: [email protected]
> Subject: Re: [USRP-users] USRP x310 RF A TX Red LED
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> A green LED means receive, and a red LED means transmit. In the early
> versions of the X300 code, this was accidentally flipped, which was not
> a problem per se, but inconsistent with our other devices.
> So no, a red TX LED is not bad, no worries!
>
> As for the bug you see with 'only receiving noise', that's strange and
> probably not connected to the LED colour. There's a chance some gain
> settings changed across versions, although I haven't heard that before.
> Maybe you can elaborate on your test setup.
>
> M
>
> On 10/10/2014 11:04 PM, Ryan Marlow via USRP-users wrote:
> > Hey All,
> > I'm playing around with different versions of the released UHD. I have a
> > simple flowgraph in GNU Radio with a USRP source and sink. and the TX
> > and RX are looped together. I'm trying to just get dataflow through the
> > USRP. UHD 3.7.1 seems to work great. The signal I send to the USRP
> > matches what the USRP sends back to GNU Radio, great! But in UHD 3.7.2
> > and 3.7.3 the TX LED is red instead of green and I appear to just be
> > getting noise back to the host. What exactly does the RED LED indicate
> > (I'm sure it's bad)? In all cases, I run the uhd_usrp_probe utility tool
> > and no significant errors result from that. I'm not sure what I'm doing
> > wrong.
> > Thanks,
> > Ryan Marlow
> >
> > --
> > Ryan L. Marlow
> > Research Assistant in CCM Lab <http://ccm.ece.vt.edu>
> > Virginia <http://www.vt.edu/> Polytechnic Institute and State University
> >
> >
> > ______________________________
> _________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
>
> --
> Ryan L. Marlow
> Research Assistant in CCM Lab <http://ccm.ece.vt.edu>
> Virginia <http://www.vt.edu/> Polytechnic Institute and State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141013/ccd83727/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 13 Oct 2014 14:54:27 -0700
From: Ben Hilburn <[email protected]>
To: Simon Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO & B200
Message-ID:
<CAOEVZkL=nqb4pdaxz1kxzj_ywbulhfls0r2orwd94mquwzj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Simon -
Do you have an external power supply plugged in while trying to use the
GPSDO, or is this just bus-powered?
Cheers,
Ben
On Mon, Oct 13, 2014 at 9:20 AM, Simon Brown via USRP-users <
[email protected]> wrote:
> Hi All,
>
>
>
> B200, no GPSDO, all is well.
>
>
>
> B200 with GPSDO I get message handler status messages:
>
>
>
> 11:02:56> Ettus: UHD:Status
>
> [chop]
>
> 11:02:56> Setting references to the internal GPSDO
>
> 11:02:56> Initializing time to the internal GPSDO
>
> 11:02:56> Ettus: UHD:Warning
>
> 11:02:56> get_time: ValueError: get_nmea(): no GPRMC message found
>
> 11:02:56> get_time: ValueError: get_nmea(): no GPRMC message found
>
> 11:02:56> Exception 00000A4E (2638), ValueError: Timeout after no
> valid message found
>
>
>
> And then usrp->get_rx_rates() returns an empty list. What documentation
> did I not read?
>
>
>
> Help appreciated, this is not my hardware, I only have the basic B200.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
> _______________________________________________
> 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/20141013/f41aedbe/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 13 Oct 2014 21:00:51 -0600
From: Roland Awusie <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 Antenna for 2.4GHz-2.5GHz
Message-ID:
<cagdf4g4vbgyhgyg0rbt8sqpuu9gnjtw8uwx1eabj5avjeji...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
Thank you all for helping me in this direction. I have decided to order two
VERT2450 antennas to meet my sampling frequency requirements. Hoping all
goes well without additional issues.
Thanks,
Roland
On Tue, Oct 7, 2014 at 12:33 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 10/07/2014 07:17 PM, Michael Schwingen via USRP-users wrote:
> > On 07.10.2014 17:54, Martin Braun via USRP-users wrote:
> >> Roland,
> >>
> >> the VERT2450 will do both 2.4 and 5 GHz bands, you can get it via our
> >> web site. You can connect anything with an SMA connector, so if you want
> >> to go really cheap, you could build your own antenna (see, e.g.
> >>
> http://www.makeuseof.com/tag/how-to-make-a-wifi-antenna-out-of-a-pringles-can-nb/
> ).
> >>
> > Not sure if this is a good idea - AFAIR, Oliver Bartels did some
> > measurements on pringles-based cantennas in the german c't magazine and
> > came to the result that it worked noticeably worse than a properly sized
> > waveguide cantenna.
>
> That was just a random Google search -- maybe I should have checked it
> more carefully. What's definitely true is that if money is an issue, you
> can build an antenna.
>
> Have fun, everyone,
> M
>
> _______________________________________________
> 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/20141013/5c5a93dc/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 14 Oct 2014 06:59:40 +0100
From: "Simon Brown" <[email protected]>
To: "'Ben Hilburn'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO & B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ben,
You asking intelligent questions, I?ll forward this to the B200 owner, even I
saw that in the docs.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Ben Hilburn [mailto:[email protected]]
Hi Simon -
Do you have an external power supply plugged in while trying to use the GPSDO,
or is this just bus-powered?
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/347e531a/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 14 Oct 2014 09:15:20 +0300
From: Birhane Alemayoh <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Loading USRP X3x0 by baseband processing
functions
Message-ID:
<capf4mozot5npqq4cqtr7ctow7tinoybpe+lfbkhgkdqsv99...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear Marcus,
Thank you so much, Your ideas and links are very helpful1
On Thu, Oct 9, 2014 at 8:19 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Birhane,
>
> On 09.10.2014 19:04, Birhane Alemayoh wrote:
> >> However, a complete GSM stack is a big thing, and I don't see much use
> in
> >> implementing it in FPGA rather than host code, especially since working
> GSM
> >> base stations already exist (openBTS).
> >>
> > My system is supposed to capture and process downlink and uplink GSM
> > signals in real time from the air using this X310 device.
> OpenBTS [0] does that with USRPs on a host.
> > My system is
> > shall work under frequency hopping environment which requires strict real
> > time requirement.
> Works.
> > We believe that this requirement is difficult to handle
> > by processing the signal in the host.
> It is. But it has been done :)
> > This is the reason why we prefer to
> > write FPGA code.
> Wow, that's dedication. I'd *definitely* spend more time making sure
> things can't be done in host code than spending manyears of development
> on FPGA hardware.
> Since you're asking us for advice, I'd expect you / your company to be
> not very experienced in the implementation of communication standards on
> FPGAs -- deciding early you want to do *everything* in the FPGA this
> early into your development doesn't sound very wise. Re-inventing the
> wheel actually sounds bad. And not looking up the capabilities of
> openBTS with USRPs instead of believing requirements are hard to meet
> with software sounds like a mistake, but one that is easily corrected ;)
>
> > So what do you comment/recommend for this?
> Doing what all the industry has been doing for 20 years: Doing only the
> really necessary part of processing in hardware, and moving higher level
> functionality to general purpose processors. Seriously, look at the
> Osmocom BB project [1]: Even the Motorola C115 [2] brick of a cheap
> consumer mobile phone does its baseband processing in software.
> Seriously, I think it will be easier to instantiate a general purpose
> CPU in the FPGA and just run the baseband processing software on there
> rather than doing everything in real FPGA hardware.
> > Thank you
>
> Hope you find the links I share helpful!
>
> Greetings,
> Marcus
> [0]http://openbts.org/
> [1]http://bb.osmocom.org/trac/
> [2]http://www.gsmarena.com/motorola_c115-876.php
>
--
With best regards,
BirhA
Birhane Alemayoh Siyum
BSc in Electrical and Electronics Engineering
M.Tech in Communication Engineering
CCNA certified
INSA, Addis Ababa, Ethiopia
Mobile: +251 912603216
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/a131ae37/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 14 Oct 2014 11:47:33 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B100 + WBX Aliasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Germano,
usually, 600 MHz should really be far enough to strongly suppress
signals; the filters on the WBX are "rather good".
Do you have any numbers for us, ie. can you give us an impression on how
strong your "powerful replica" is, maybe in relation to a known signal
or the noise floor? What is your gain? How strong is the "original"
GSM900 downlink compared to the image?
As a short explanation: the WBX [1] is centered around the AD5387 IQ
mixer [2] which, if I remember correctly, has a downconversion bandwidth
of up to 240 MHz, which the WBX then filters down to 40 MHz of baseband
bandwidth using a multistage analog filter.
If you're seeing strong intermodulation, then maybe you're driving the
WBX with a *very* strong GSM signal, and even the best amplifiers and
mixers do have nonlinear behaviour when driven too close to their
maximum power. Nonlinearity leads to quadratic and higher order terms,
which lead to mixing...
So the answer is: no, I don't believe that the filtering on the WBX is
not sufficient to suppress usual communication signals, but that depends
on the power of the signals. Also, you're doing spectrum measurements
around 312 MHz, but you also seem to receive GSM900 downlink (should be
somewhere around 925-960 MHz); unless you have a broadband [3] antenna,
one of these should be attenuated.
Greetings,
Marcus
[1] schematics to all our d'boards can be found at
http://files.ettus.com/schematics
[2]
http://www.analog.com/en/rfif-components/modulatorsdemodulators/adl5387/products/product.html
[3] Ok, this is just guesswork, but given the numbers I have: let's
assume your antenna's working range is really just 300 - 1000 MHz,
closely fitting both your observed frequency and GSM, giving it a 700
MHz bandwidth at a 650 MHz center frequency, which is quite a nice
broadband antenna. Our LP0410 comes close to that, with its logperiodic
design, but I don't have numbers on how it works below its lower 400 MHz
boundary.
On 12.10.2014 18:20, Germano Capela via USRP-users wrote:
> Hi,
>
> When I run a simple spectrum measurement around 312MHz, I observe a
> powerful replica of the GSM900 downlink (arround 935 MHz) spectra. Is it
> possible that the anti-aliasing filters are not enough to prevent this
> effect?
>
> Regards,
>
> Germano
>
>
>
> _______________________________________________
> 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/20141014/1d64fc1a/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 14 Oct 2014 11:49:44 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO & B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Simon,
Coul you give the GPSDO an antenna and give it some time till it gets a
fix (green LED next to it), and try again?
Greetings,
Marcus
On 14.10.2014 07:59, Simon Brown via USRP-users wrote:
> Ben,
>
>
>
> You asking intelligent questions, I'll forward this to the B200 owner, even I
> saw that in the docs.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
> From: Ben Hilburn [mailto:[email protected]]
>
>
>
> Hi Simon -
>
>
>
> Do you have an external power supply plugged in while trying to use the
> GPSDO, or is this just bus-powered?
>
>
>
> Cheers,
>
> Ben
>
>
>
>
>
>
> _______________________________________________
> 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/20141014/73c7bf65/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 14 Oct 2014 11:30:49 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] FW: GPSDO & B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I?ve passed on this suggestion and also the use of PSU. I?ll probably get
feedback today. IMO the firmware should return sample rates even if there?s
no lock, this could be a configuration (no PSU power0 which hasn?t happened
exactly this way at Ettus.
FWIW some users reporting 32MHz streaming without any problems, it is an
excellent card.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Hi Simon,
Coul you give the GPSDO an antenna and give it some time till it gets a fix
(green LED next to it), and try again?
Greetings,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/b974fcbe/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 14 Oct 2014 11:34:59 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] FW: GPSDO & B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
>From my user: ?After a lot of playing around I was finally able to load an
image into the FPGA (with the GPSDO module installed). Then I placed the GPS
antenna on the window sill -- and waited. Eventually one of the green LEDs
on the module began to randomly flash. The lock indicated (LED100) on the
B200 board was still off. After quite a while the lock indicators on the
module and the board came on.?
And it worked OK.
So my suggestion is that maybe a firmware update is needed to only use the
GPSDO if there?s a lock, in any event always return sample rates. There are
many reasons why the GPS signals may not be received?
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of
Simon Brown via USRP-users
Sent: 14 October 2014 11:31
To: [email protected]
Subject: [USRP-users] FW: GPSDO & B200
Hi,
I?ve passed on this suggestion and also the use of PSU. I?ll probably get
feedback today. IMO the firmware should return sample rates even if there?s
no lock, this could be a configuration (no PSU power0 which hasn?t happened
exactly this way at Ettus.
FWIW some users reporting 32MHz streaming without any problems, it is an
excellent card.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Hi Simon,
Coul you give the GPSDO an antenna and give it some time till it gets a fix
(green LED next to it), and try again?
Greetings,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/7b82c7c2/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 14 Oct 2014 13:07:05 +0200
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD 3.8.0-RC1] Release Candidate Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hey everyone,
I hinted at it in a previous email, and we're getting closer: The 3.8.0
release is nearly there. As usual, we're putting out a release candidate
first to give it some public exposure and additional testing before we
do the actual release.
You can get this release by either pulling master branch, or checking
out the RC's tag: https://github.com/EttusResearch/uhd/tree/003_008_000_rc1
This is a pretty big change, and there might be more release candidates.
However, we want to get our stuff out to the public as soon as possible,
so here it is.
If you go ahead and pull now, it will be a huge diff (might take a bit,
don't worry).
A couple of notes on this release:
- We have reorganized the firmware and fpga subdirectories. The former
was simply moved around, but the latter is now a git submodule. Run 'git
submodule init' and 'git submodule update' if you want to read and
change the fppga source code.
- B200 updates: We've fixed the issue with B200 rapidly losing
connection on some devices (this particular issue never existed on
maint, but for a while it was in master). The reason was the version of
the SDK we used to compile the firmware. Altogether, B200 initialization
is now much faster.
- E310: This device includes support for our upcoming embedded device.
News on the actual device will follow in the near future, so please be
patient.
- CMake improvements: Among some fixes, we now distribute a
UHDConfig.cmake file which you can use to more easily build applications
linking to UHD. We provide an example on how to do that in
host/examples/init_usrp/.
Since this is a release candidate, we'd appreciate any testing. Thank you!
Cheers,
Martin
## Changelog for 3.8.0-RC1
* Added E310 support
* B200/B210: Moved AD9361 controls from firmware to host
* Added several tools: ZPU dissector, improved CHDR dissector,
kitchen sink, B200/B210 USB debugging utility, latency
measurement tool.
* Reorganized firmware/ directory structure. Refactored some
firmware.
* Removed FPGA sources, is now in own repository (submoduled).
* Cleaned up command line arguments for some tools
* Added math namespace, plus a unified float comparison infrastructure
* Fixed tuning-related bugs
* Moved manual over to Doxygen, also several manual bug fixes and
amendments
* Added many missing virtual destructors (less build warnings)
* Added support for NI-RIO 14.0
* X300 fixes: Not found over PCIe with no eth interfaces,
* CMake improvements: Now comes with own UHDConfig.cmake and example
to build standalone UHD apps, build fixes on Apple, interoperability
with GNU Radio
* OctoClock fixes and improvements: Ethernet initialization, external
ref detection, stability fixes, host driver (UHD can now talk to
OctoClock)
* Examples: Improved GPIO example, rx_samples_to_file
------------------------------
Message: 12
Date: Tue, 14 Oct 2014 16:43:05 +0200
From: LEMENAGER Claude <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
Message-ID:
<28937_1413297786_543d367a_28937_1142_4_59957d668d245c4eb38e8f85c054e90107760e0...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello Marcus,
No changes with this other firmware. I am building UHD 003.007.003-RC1 for
further tests.
Regards,
Claude
=========================================
Hello Marcus,
I am working at 950MHz (RF) sampling 25MHz.
One thing is curious: In grc I specify External for both Clock source and Time
but when running I obtain:
...
- References Initialized to internal sources
WARN: Sensor 'lo_locked' failed to lock within timeout on channel 0
... (other channels)
>From UHD-FFT example (QT), I obtain the same but the indicator 'lo_locked' is
>in locked state.
And more curiously, I use an Octoclock as external source, the PPS led is not
synchronized between Octoclock and X310 (even between X310 despite the fact I
set them to External References! (seems not to be aware from the settings)
With the respect of the images, I used the one of the 20 Aug 2014
(003.007.002-48) but have seen it exists one of 21 Aug-2014 (003.007.002-440)
(dates from tags in directory). I will try with this one.
Thank you,
Claude
De : Marcus M?ller [mailto:[email protected]]
Envoy? : jeudi 9 octobre 2014 15:39
? : [email protected]
Objet : Re: [USRP-users] X3X0 SBX corrupted samples?
Hello Mr. Lem?nager,
the warning that the LO is not locked is severe in principle; are you using an
external reference clock?
Could you paste the complete warning?
At which frequencies are you working?
Greetings,
Marcus
On 09.10.2014 15:30, LEMENAGER Claude via USRP-users wrote:
Hello,
I sample at least two channels (SBX 120) from one or multiple X310 boards each
equipped with two SBX radio boards.
I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
under UBUNTU 14.04LTS).
The input is connected to a CW generator. The channels definition is A:0 B:0,
antenna is RX2 in all cases.
The problems :
1) I receive a warning concerning lo_locked no locked after timeout for each
channel (I read a discuss where this fact was given)
2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I and
Q parts). When I connect a B:0 channel (from any X310 board) I receive the CW
wave plus spurious (sort of dirac through a filter) generally starting on Q
channel but not only. This look like an erroneous sample (digitally speaking
for example just an incorrect bit in the LSBs) before DDC. The spurious looks
like periodic but the period seems to change with radio frequency (to confirm)
Did somebody encounters this problem?
If yes, is there a solution.
I plan to try to reproduce this (or to see if it's the same) with UHD directly
accessed BY a C++ application.
Regards,
Claude Lem?nager
P.S. Conclusion about preceding discussion (june) about PCIe interface: The HP
PC on which I made my firsts experiences was equipped with one of the first
generation PCIe chip. So it failed to interface with X310. I now uses a last
generation pc and then there is no problem except for what I mention above.
Thanks for support.
_______________________________________________
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/20141014/c5ef05d3/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 14 Oct 2014 17:28:02 +0200
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] OctoClock Firmware Install
Message-ID:
<29184_1413300495_543d410f_29184_1587_1_59957d668d245c4eb38e8f85c054e90107760e0...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to setup an Octoclock, following the documentation.
First step, avrdude for the bootloader through an usbasp programmer is
completed (with an error for the readback at an high address so I think it was
not critical).
At this level I mention that for me the schematics of the octoclock shows the
J108 ISP connector reversed (I used a tester to find gnd and Vcc)
The second step should make use of an "octoclock_firmware_burner and I did not
find any trace of it (except source code)
So my question is how to perform the load of the primary Octoclock firmware?
Thank you for help,
Claude Lem?nager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/a6be5c6e/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 50, Issue 13
******************************************
