[USRP-users] USRP-users Digest, Vol 50, Issue 13

Abhijit Kulkarni abhisk.amey at gmail.com
Tue Oct 14 13:50:57 EDT 2014


Ggg
On Oct 14, 2014 12:05 PM, <usrp-users-request at lists.ettus.com> wrote:

> Send USRP-users mailing list submissions to
>         usrp-users at 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-request at lists.ettus.com
>
> You can reach the person managing the list at
>         usrp-users-owner at 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. 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" <simon at sdr-radio.com>
> To: <usrp-users at lists.ettus.com>
> Subject: [USRP-users] GPSDO & B200
> Message-ID: <031601cfe701$a3117e90$e9347bb0$@sdr-radio.com>
> 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 <rynmrlw at vt.edu>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] USRP x310 RF A TX Red LED
> Message-ID:
>         <CADVE_uzvT4p7cWpAEirzzAtoZdwWVPCbvWta61Gmy+1Pu1J=
> vQ at 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 <martin.braun at ettus.com>
> > To: usrp-users at lists.ettus.com
> > Subject: Re: [USRP-users] USRP x310 RF A TX Red LED
> > Message-ID: <543BF1D9.6080804 at ettus.com>
> > 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
> > > USRP-users at lists.ettus.com
> > > 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 <ben.hilburn at ettus.com>
> To: Simon Brown <simon at sdr-radio.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] GPSDO & B200
> Message-ID:
>         <CAOEVZkL=
> nQB4pdAXz1KXZj_YWBULHfLs0r2ORWd94MQuWzJCXA at 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 <
> usrp-users at lists.ettus.com> 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
> > USRP-users at 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/20141013/f41aedbe/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Mon, 13 Oct 2014 21:00:51 -0600
> From: Roland Awusie <rolandgatsby at gmail.com>
> To: Martin Braun <martin.braun at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] USRP2 Antenna for 2.4GHz-2.5GHz
> Message-ID:
>         <
> CAGdF4G4vbGyHgyG0RBT8SqpUu9gnJtW8uwX1eAbj5AvjEJiKVA at 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 <
> usrp-users at lists.ettus.com> 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
> > USRP-users at 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/20141013/5c5a93dc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 14 Oct 2014 06:59:40 +0100
> From: "Simon Brown" <simon at sdr-radio.com>
> To: "'Ben Hilburn'" <ben.hilburn at ettus.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] GPSDO & B200
> Message-ID: <061301cfe774$0b0cbb00$21263100$@sdr-radio.com>
> 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:ben.hilburn at ettus.com]
>
>
>
> 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 <birhanea at gmail.com>
> To: Marcus M?ller <marcus.mueller at ettus.com>
> Cc: "usrp-users at lists.ettus.com" <USRP-users at lists.ettus.com>
> Subject: Re: [USRP-users] Loading USRP X3x0 by baseband processing
>         functions
> Message-ID:
>         <
> CAPF4MOzot5NpQQ4cQTR7ctow7tinoYBPE+LfBKHGkdQSv99KQg at 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 <marcus.mueller at ettus.com>
> 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 <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] B100 + WBX Aliasing
> Message-ID: <543CF135.1000208 at ettus.com>
> 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
> > USRP-users at 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/20141014/1d64fc1a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Tue, 14 Oct 2014 11:49:44 +0200
> From: Marcus M?ller <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] GPSDO & B200
> Message-ID: <543CF1B8.8080602 at ettus.com>
> 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:ben.hilburn at ettus.com]
> >
> >
> >
> > 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
> > USRP-users at 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/20141014/73c7bf65/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Tue, 14 Oct 2014 11:30:49 +0100
> From: "Simon Brown" <simon at sdr-radio.com>
> To: <usrp-users at lists.ettus.com>
> Subject: [USRP-users] FW:  GPSDO & B200
> Message-ID: <073c01cfe799$ec2d0660$c4871320$@sdr-radio.com>
> 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:usrp-users-bounces at lists.ettus.com] 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" <simon at sdr-radio.com>
> To: <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] FW:  GPSDO & B200
> Message-ID: <074d01cfe79a$81330ca0$839925e0$@sdr-radio.com>
> 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:usrp-users-bounces at lists.ettus.com] On Behalf Of
> Simon Brown via USRP-users
> Sent: 14 October 2014 11:31
> To: usrp-users at lists.ettus.com
> 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:usrp-users-bounces at lists.ettus.com] 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 <martin.braun at ettus.com>
> To: "'USRP-users at lists.ettus.com'" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] [UHD 3.8.0-RC1] Release Candidate Announcement
> Message-ID: <543D03D9.3010401 at ettus.com>
> 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 <claude.lemenager at thalesgroup.com>
> To: Marcus M?ller <marcus.mueller at ettus.com>,
>         "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
> Message-ID:
>
> <28937_1413297786_543D367A_28937_1142_4_59957D668D245C4EB38E8F85C054E90107760E002F at 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:marcus.mueller at ettus.com]
> Envoy? : jeudi 9 octobre 2014 15:39
> ? : usrp-users at lists.ettus.com
> 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
>
> USRP-users at lists.ettus.com<mailto:USRP-users at 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/20141014/c5ef05d3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Tue, 14 Oct 2014 17:28:02 +0200
> From: LEMENAGER Claude <claude.lemenager at thalesgroup.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] OctoClock Firmware Install
> Message-ID:
>
> <29184_1413300495_543D410F_29184_1587_1_59957D668D245C4EB38E8F85C054E90107760E0174 at 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
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 50, Issue 13
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/df7df6a0/attachment-0002.html>


More information about the USRP-users mailing list