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: USRP-users Digest, Vol 50, Issue 13 (Abhijit Kulkarni)
2. Maximum receivers with USRP X300/310 (Rob Miller)
3. Re: Maximum receivers with USRP X300/310 (Marcus D. Leech)
4. Re: Maximum receivers with USRP X300/310 (Rob Miller)
5. B210 FPGA/FW Issue (hossein talaiee)
6. Re: B210 FPGA/FW Issue (Marcus M?ller)
7. Re: B210 FPGA/FW Issue (hossein talaiee)
8. Re: B210 FPGA/FW Issue (Ian Buckley)
9. 3.8.0 build issues on centos 6 (Stan Vitebsky)
10. Re: FW: GPSDO & B200 (Ben Hilburn)
11. Re: OctoClock Firmware Install (Ben Hilburn)
12. Re: OctoClock Firmware Install (Ben Hilburn)
13. Usrp Gain Settings (drpaulcreaser)
14. Re: 3.8.0 build issues on centos 6 (Ben Hilburn)
15. Re: Usrp Gain Settings (Marcus M?ller)
16. Re: Loading USRP X3x0 by baseband processing functions
(Marcus M?ller)
17. Re: OctoClock Firmware Install (LEMENAGER Claude)
18. Re: B100 + WBX Aliasing (Germano)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Oct 2014 13:50:57 -0400
From: Abhijit Kulkarni <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 13
Message-ID:
<cabxhtfnvrtrx7slkx8qdana7ymtzhilj9smh1c_cx6hqux-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ggg
On Oct 14, 2014 12:05 PM, <[email protected]> wrote:
> 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=
> [email protected]>
> 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=
> [email protected]>
> 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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/df7df6a0/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 14 Oct 2014 14:30:54 -0400
From: Rob Miller <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Maximum receivers with USRP X300/310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
All,
Am I correct in assuming that a single USRP X300/310 can support four receive
streams? E.g., by using 2 SBX daughterboards, can I use the 'TX/RX' and 'RX2'
ports on both daughterboards simultaneously?
I understand that there are general restrictions for tuning the streams, but
for my application this won't be an issue.
Best,Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/d3d325ea/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 14 Oct 2014 14:33:17 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Maximum receivers with USRP X300/310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/14/2014 02:30 PM, Rob Miller via USRP-users wrote:
> All,
>
> Am I correct in assuming that a single USRP X300/310 can support four
> receive streams? E.g., by using 2 SBX daughterboards, can I use the
> 'TX/RX' and 'RX2' ports on both daughterboards simultaneously?
>
> I understand that there are general restrictions for tuning the
> streams, but for my application this won't be an issue.
>
> Best,
> Rob
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There is only a single analog receive chain per SBX, and only a single
ADC pair per slot, so, no, you can't use RX2 and TX/RX simultaneously.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/d3fae739/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 14 Oct 2014 14:56:56 -0400
From: Rob Miller <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Maximum receivers with USRP X300/310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Marcus,Thanks for the clarification and prompt reply.Best,Rob
Date: Tue, 14 Oct 2014 14:33:17 -0400
To: [email protected]
Subject: Re: [USRP-users] Maximum receivers with USRP X300/310
From: [email protected]
On 10/14/2014 02:30 PM, Rob Miller via
USRP-users wrote:
All,
Am I correct in assuming that a single USRP X300/310 can
support four receive streams? E.g., by using 2 SBX
daughterboards, can I use the 'TX/RX' and 'RX2' ports on both
daughterboards simultaneously?
I understand that there are general restrictions for tuning
the streams, but for my application this won't be an issue.
Best,
Rob
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There is only a single analog receive chain per SBX, and only a
single ADC pair per slot, so, no, you can't use RX2 and TX/RX
simultaneously.
_______________________________________________
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/6a3b2edc/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 15 Oct 2014 00:09:06 +0330
From: hossein talaiee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 FPGA/FW Issue
Message-ID:
<caaibebt2d5oyvdnctcfd-xyykmiunyf6rpnj75a78wgbohc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I have e B210 board with spec:
revision: 4
product: 2
FW Version: 4.0
FPGA Version: 3.0
Each time I want to run examples of UHD like benchmark it start to load
FPGA image and sometimes fw too!
Why this happen? Isn't it a one time procedure ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/0c40d5de/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 14 Oct 2014 22:51:23 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 FPGA/FW Issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Hossein,
these images have to be loaded everytime you reset your device, ie.
whenever you plug it into power; it's not a one-time procedure.
Greetings,
Marcus
On 14.10.2014 22:39, hossein talaiee via USRP-users wrote:
> Hi
>
> I have e B210 board with spec:
>
> revision: 4
> product: 2
> FW Version: 4.0
> FPGA Version: 3.0
>
>
> Each time I want to run examples of UHD like benchmark it start to load
> FPGA image and sometimes fw too!
>
> Why this happen? Isn't it a one time procedure ?
>
>
>
> _______________________________________________
> 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/4a920f5b/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 15 Oct 2014 00:49:38 +0330
From: hossein talaiee <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 FPGA/FW Issue
Message-ID:
<CAAiBEBQxptnRaFJumaXXLAz+1H68NFMP7=p2z-dvgjpfhkd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Why ?
Can't be permanently programmed on board?
On Wed, Oct 15, 2014 at 12:21 AM, Marcus M?ller <[email protected]>
wrote:
> Hi Hossein,
>
> these images have to be loaded everytime you reset your device, ie.
> whenever you plug it into power; it's not a one-time procedure.
>
> Greetings,
> Marcus
>
> On 14.10.2014 22:39, hossein talaiee via USRP-users wrote:
>
> Hi
>
> I have e B210 board with spec:
>
> revision: 4
> product: 2
> FW Version: 4.0
> FPGA Version: 3.0
>
>
> Each time I want to run examples of UHD like benchmark it start to load
> FPGA image and sometimes fw too!
>
> Why this happen? Isn't it a one time procedure ?
>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.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/20141015/696e731f/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 14 Oct 2014 14:32:20 -0700
From: Ian Buckley <[email protected]>
To: hossein talaiee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 FPGA/FW Issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Nope. There is non no-volatile memory on the board to store the FPGA
configuration.
This in fact makes the design much easier since handling the update and
fail-safe of stored images is a non-trivial problem.
-Ian
On Oct 14, 2014, at 2:19 PM, hossein talaiee via USRP-users
<[email protected]> wrote:
> Why ?
> Can't be permanently programmed on board?
>
> On Wed, Oct 15, 2014 at 12:21 AM, Marcus M?ller <[email protected]>
> wrote:
> Hi Hossein,
>
> these images have to be loaded everytime you reset your device, ie. whenever
> you plug it into power; it's not a one-time procedure.
>
> Greetings,
> Marcus
>
> On 14.10.2014 22:39, hossein talaiee via USRP-users wrote:
>> Hi
>>
>> I have e B210 board with spec:
>>
>> revision: 4
>> product: 2
>> FW Version: 4.0
>> FPGA Version: 3.0
>>
>>
>> Each time I want to run examples of UHD like benchmark it start to load
>> FPGA image and sometimes fw too!
>>
>> Why this happen? Isn't it a one time procedure ?
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.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/20141014/ec817326/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 14 Oct 2014 18:21:05 -0400
From: Stan Vitebsky <[email protected]>
To: <[email protected]>
Subject: [USRP-users] 3.8.0 build issues on centos 6
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hello,
I have trouble building newly released uhd 3.8.0 on Centos 6 (3.10.33
kernel).
Previous release as well as the current maint branch are building
successfully.
The first error that fails the build is that
boost/thread/shared_lock_guard.hpp file cannot be found in
include/uhd/transport/nirio/niriok_proxy.h on line 26.
I suppose this is because this file doesn't exist in boost 1.41, which
is default for Centos 6.
Does this mean that Centos 6 will no longer be supported by uhd?
Thanks,
-Stan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3305 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141014/9951e22d/attachment-0001.p7s>
------------------------------
Message: 10
Date: Tue, 14 Oct 2014 15:25:16 -0700
From: Ben Hilburn <[email protected]>
To: Simon Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FW: GPSDO & B200
Message-ID:
<caoevzk+rys4hsk19q_x7nsiszclxx9_m-nhgp5yvvpd8ofv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Simon -
In terms of it dropping out occasionally, it is quite possible to cause a
power brown-out on the device when using a GPSDO and relying on bus power.
I'm happy your user is up and running!
Cheers,
Ben
On Tue, Oct 14, 2014 at 3:34 AM, Simon Brown via USRP-users <
[email protected]> wrote:
> 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]
> <[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
>
>
>
> _______________________________________________
> 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/24857b2b/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 14 Oct 2014 16:37:53 -0700
From: Ben Hilburn <[email protected]>
To: LEMENAGER Claude <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] OctoClock Firmware Install
Message-ID:
<caoevzk+dod-aemx5opwske3ak1jf4mkkans9s248gutmxkr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Claude -
So, first thing is that you don't need to do any of this. The new firmware
is only necessary if you want to use some of the newly developed features,
like reading the NMEA strings out to UHD. The octoclock is fully functional
as it arrives.
The firmware burner utility will run if the Octoclock device is enabled
during your CMake configuration. When you run CMake, do you see it as an
enabled module?
Cheers,
Ben
On Tue, Oct 14, 2014 at 8:28 AM, LEMENAGER Claude via USRP-users <
[email protected]> wrote:
> 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
>
>
>
> _______________________________________________
> 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/c1ca5450/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 14 Oct 2014 16:41:49 -0700
From: Ben Hilburn <[email protected]>
To: LEMENAGER Claude <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] OctoClock Firmware Install
Message-ID:
<CAOEVZkLffk3FWzXNyzEWxQWFVTeXw9jgVXbEEE6tUfLuO=e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, would you mind clarifying what you mean by "the schematic shows the
connector reversed"? The schematic doesn't indicate orientation. Are there
docs somewhere that are incorrect?
If our docs are wrong somewhere, we want to fix that as soon as possible.
Cheers,
Ben
On Tue, Oct 14, 2014 at 4:37 PM, Ben Hilburn <[email protected]> wrote:
> Hi Claude -
>
> So, first thing is that you don't need to do any of this. The new firmware
> is only necessary if you want to use some of the newly developed features,
> like reading the NMEA strings out to UHD. The octoclock is fully functional
> as it arrives.
>
> The firmware burner utility will run if the Octoclock device is enabled
> during your CMake configuration. When you run CMake, do you see it as an
> enabled module?
>
> Cheers,
> Ben
>
> On Tue, Oct 14, 2014 at 8:28 AM, LEMENAGER Claude via USRP-users <
> [email protected]> wrote:
>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/6f2da82a/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 14 Oct 2014 09:34:30 +0900
From: drpaulcreaser <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Usrp Gain Settings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi
I currently have a usrp x310 with a sbx daughter board.
Using the uhd driver, I can set the transmission and reception gains.
I assume there are two gain types on the usrp:
1 Daughter board- ADC gain
2 Digital Gain which may occur in the fpga.
I am assuming the software/firmware automatically splits the gain between gain
types.
Another assumption I am making is the gain is fixed. There is no AGC
functionality?
Are these assumptions correct? I come from a software engineering background,
so apologies if these questions are a bit basic.
Best Regards
------------------------------
Message: 14
Date: Tue, 14 Oct 2014 16:45:49 -0700
From: Ben Hilburn <[email protected]>
To: Stan Vitebsky <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 3.8.0 build issues on centos 6
Message-ID:
<caoevzk+hlj0kdak1n-9sni7z3bhyoxd9d1vfeuo-xcebchs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Stan -
Thanks for letting us know! We'll look into it. It does sound like we may
need to bump the minimum required version of Boost.
Cheers,
Ben
On Tue, Oct 14, 2014 at 3:21 PM, Stan Vitebsky via USRP-users <
[email protected]> wrote:
> Hello,
>
> I have trouble building newly released uhd 3.8.0 on Centos 6 (3.10.33
> kernel).
> Previous release as well as the current maint branch are building
> successfully.
> The first error that fails the build is that
> boost/thread/shared_lock_guard.hpp
> file cannot be found in include/uhd/transport/nirio/niriok_proxy.h on
> line 26.
> I suppose this is because this file doesn't exist in boost 1.41, which is
> default for Centos 6.
> Does this mean that Centos 6 will no longer be supported by uhd?
>
> Thanks,
> -Stan
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20f2437b/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 15 Oct 2014 10:25:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Usrp Gain Settings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello Paul,
On 14.10.2014 02:34, drpaulcreaser via USRP-users wrote:
> Hi
>
> I currently have a usrp x310 with a sbx daughter board.
>
> Using the uhd driver, I can set the transmission and reception gains.
>
> I assume there are two gain types on the usrp:
>
> 1 Daughter board- ADC gain
> 2 Digital Gain which may occur in the fpga.
Your assumptions are accurate. Actually, on some daughterboards you even
have multiple stages of amplification and UHD distributes gain optimally
by itself (minimizing noise figure).
> I am assuming the software/firmware automatically splits the gain between
> gain types.
>
> Another assumption I am making is the gain is fixed. There is no AGC
> functionality?
On the SBX there is no AGC functionality, as AGC is inherently
application specific (e.g. your AGC needs to be significantly slower
than your amplitude modulation).
> Are these assumptions correct? I come from a software engineering background,
> so apologies if these questions are a bit basic.
Rest assured that those are good questions and especially your question
regarding splitting gains shows you have understanding of the technology
at hand ;)
Greetings,
Marcus
------------------------------
Message: 16
Date: Wed, 15 Oct 2014 10:56:23 +0200
From: Marcus M?ller <[email protected]>
To: Birhane Alemayoh <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Loading USRP X3x0 by baseband processing
functions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Birhane,
sorry, I can't tell you what your host must look like for your specific
application, because that is a crucial part of your job as an
application designer, and I don't know how much processing power you'll
need for that task. Simply go for workstation as fast as you can afford[1].
Greetings,
Marcus
[1] Assuming you don't want to wait days on your X3x0 FPGA image to be
generated, you'll have workstation around that has a vast amounts of RAM
and quite possibly a high-performance RAID, and that will be a good
starter for beginning your development on. Upgrade later if necessary.
On 15.10.2014 10:38, Birhane Alemayoh wrote:
> Dear Marcus,
>
>
>
> On Tue, Oct 14, 2014 at 9:15 AM, Birhane Alemayoh <[email protected]>
> wrote:
>
>> 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.
>>
> One more question please!
> You told me that implementing most of the signal processing is preferred in
> the host PC. However, my requirement is to capture and process multiple
> simultaneous GSM conversations (uplink and downlink) from the air. This
> could be up to 8 different ARFCN channels in which each channel has 8 time
> slots according to the GSM standard. Basically what we are doing is
> implementing GSM interception using the open software and hardware
> technologies. So what should be the performance or specification of the
> host PC?
> Thank you again!
>
>
>> 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
>>>
>>
>>
>> --
>>
>>
>>
------------------------------
Message: 17
Date: Wed, 15 Oct 2014 11:52:32 +0200
From: LEMENAGER Claude <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] OctoClock Firmware Install
Message-ID:
<6331_1413366754_543e43e1_6331_1794_1_59957d668d245c4eb38e8f85c054e901077612c...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="utf-8"
Hello Ben ;
Thank you for your answer.
No the Octoclock was not fully functional when it arrives (at that moment, it
was specified that the final firmware was not installed).
If I remember well, I checked through the Ethernet but nothing was present. So
I buy AVR programmer as soon as I have seen that firmware was available for it
(our Octoclock is equipped with GPSDO).
I have performed the first documented step. When powering The three led on left
are on and remains on (External, Internal and status), pps is off Gpslock is on
then off and power on is on.
Connecting the Ethernet cable shows activity.
Now, I had the habits to work with precompiled binary. I actually try to
install 003.007.003 (but maybe 003.008.000 should be better) and have to use
CMake.
So I wasn?t able to obtain the utility from the 003.007.003-rc1 but don?t know
how to configure it. I will search for that.
Is there one Cmake pass for Uhd soft and one pass for images?
For the schematics:
On the board, we can think, as there are no other indication (pin 1 seems not
to be marked), that the mark of J108 is like the schematics. I clearly suspect
that?s not the case. So it?s rather a problem between serigraphy on the board
and documentation (or my eyes are becoming bad and this can be the case).
Regards,
Claude
De : Ben Hilburn [mailto:[email protected]]
Envoy? : mercredi 15 octobre 2014 01:42
? : LEMENAGER Claude
Cc : [email protected]
Objet : Re: [USRP-users] OctoClock Firmware Install
Also, would you mind clarifying what you mean by "the schematic shows the
connector reversed"? The schematic doesn't indicate orientation. Are there docs
somewhere that are incorrect?
If our docs are wrong somewhere, we want to fix that as soon as possible.
Cheers,
Ben
On Tue, Oct 14, 2014 at 4:37 PM, Ben Hilburn
<[email protected]<mailto:[email protected]>> wrote:
Hi Claude -
So, first thing is that you don't need to do any of this. The new firmware is
only necessary if you want to use some of the newly developed features, like
reading the NMEA strings out to UHD. The octoclock is fully functional as it
arrives.
The firmware burner utility will run if the Octoclock device is enabled during
your CMake configuration. When you run CMake, do you see it as an enabled
module?
Cheers,
Ben
On Tue, Oct 14, 2014 at 8:28 AM, LEMENAGER Claude via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
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
_______________________________________________
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/20141015/806b721d/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 15 Oct 2014 10:59:23 +0100
From: Germano <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] B100 + WBX Aliasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Marcus,
Thanks for the detailed answer.
I tested with two different antennas, Ettus' VERT400 and a DVB-T antenna
(not one of those that come with the rtl dongles) and the results are
similar (more prominent w/ the DVBT antenna).
I attached some screenshots of my measurements (I also tried with lower
gain, 10dB, and the results are equivalent).
Regards,
Germano
On 14-10-2014 17:00, [email protected] wrote:
> 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/20141015/e896cf00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvbt-311MHz.png
Type: image/png
Size: 55100 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/e896cf00/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvbt-935MHz.png
Type: image/png
Size: 51931 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/e896cf00/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vert400-311MHz.png
Type: image/png
Size: 48342 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/e896cf00/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vert400-935MHz.png
Type: image/png
Size: 51054 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/e896cf00/attachment-0007.png>
------------------------------
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 14
******************************************
