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: B200 GPSDO Dimensions (Jacob Gilbert)
2. LOs alignment in SBX daughterboards (Perper)
3. Re: LOs alignment in SBX daughterboards (Marcus D. Leech)
4. Re: LOs alignment in SBX daughterboards (Perper)
5. Re: LOs alignment in SBX daughterboards (Marcus D. Leech)
6. Re: B210 as standalone transmitter? (Robert Kossler)
7. Re: time_spec (Michael West)
8. usrp_samples.dat plot (alejandro kilei)
9. Re: usrp_samples.dat plot (Robert Kossler)
10. Re: (no subject) (Marcus D. Leech)
11. Re: UHD support for National Instruments DAQ hardware
(Ashish Chaudhari)
12. Re: Inquiries on Ettus USRP E110 Hardware Driver
(Hacker Fantastic)
13. Re: B210 as standalone transmitter? (Marcus M?ller)
14. Re: B210 as standalone transmitter? (Martin Braun)
15. Re: [Discuss-gnuradio] Ver 3.7 stable? (Martin Braun)
16. FW: Inquiries on Ettus USRP E110 Hardware Driver (Chun Mein Soon)
17. FW: Inquiries on Ettus USRP E110 Hardware Driver (Chun Mein Soon)
18. Re: FW: Inquiries on Ettus USRP E110 Hardware Driver
(Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Mon, 9 Jun 2014 12:06:09 -0400
From: Jacob Gilbert <[email protected]>
To: "Garver, Paul W" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 GPSDO Dimensions
Message-ID:
<CAC52AkCqbshScQ0R5eMoA7VvhF2EVae3vPaOd9r=frpkvp2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just measured quickly, but the top of the OXCO is about 0.665" above the
bottom of the board, and there tallest components on the bottom sit up
about 0.11", so 0.775" total height.
Jacob
On Mon, Jun 9, 2014 at 11:23 AM, Garver, Paul W via USRP-users <
[email protected]> wrote:
> What is the height of the B200 + GPSDO stack? I can't find the dimensions
> of the GPSDO (P/N 783454-01) for the B200 and want to ensure it will clear
> my enclosure.
>
> PWG
>
> _______________________________________________
> 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/20140609/31cb45d4/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 09 Jun 2014 18:44:23 +0200
From: Perper <[email protected]>
To: [email protected]
Subject: [USRP-users] LOs alignment in SBX daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi all,
I have questions regarding SBX daughterboard as I'm considering if it
will fit my needs. I'm curious if it is appropriate for beamforming
without performing recalibration of antenna array after every powering
up of USRPs (in other words I don't want to transmit training sequences
after each powering up).
The "Application Note Selecting an RF Daughterboard"
(http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf)
states,
that SBX has a feature that makes it distinctive among other
daugtherboards:
"The Ettus Research SBX daughterboard utilizes
an RF PLL that includes a resynchronization feature, which can be used
to align the LOs across multiple SBXs, and multiple USRP hardware devices."
How is this feature different from resynchronization in other
daughterboards? I'm interested in the way it is achieved and differences
in obtained results from other daughterboards. The "UHD -
Synchronization Application Notes"
(http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series)
doesn't make any differentiation.
I'm also interested if this feature is fully supported by UHD driver and
performing steps described in "Align LOs in the front-end (SBX, WBX,
CBX)" of "UHD - Synchronization Application Notes" is enough to take
advantage of it.
Thank you in advance!
Best Regads,
Piotr Krysik
------------------------------
Message: 3
Date: Mon, 09 Jun 2014 13:08:28 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LOs alignment in SBX daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/09/2014 12:44 PM, Perper via USRP-users wrote:
> Hi all,
>
> I have questions regarding SBX daughterboard as I'm considering if it
> will fit my needs. I'm curious if it is appropriate for beamforming
> without performing recalibration of antenna array after every powering
> up of USRPs (in other words I don't want to transmit training sequences
> after each powering up).
>
> The "Application Note Selecting an RF Daughterboard"
> (http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf)
> states,
> that SBX has a feature that makes it distinctive among other
> daugtherboards:
>
> "The Ettus Research SBX daughterboard utilizes
> an RF PLL that includes a resynchronization feature, which can be used
> to align the LOs across multiple SBXs, and multiple USRP hardware devices."
>
> How is this feature different from resynchronization in other
> daughterboards? I'm interested in the way it is achieved and differences
> in obtained results from other daughterboards. The "UHD -
> Synchronization Application Notes"
> (http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series)
> doesn't make any differentiation.
>
> I'm also interested if this feature is fully supported by UHD driver and
> performing steps described in "Align LOs in the front-end (SBX, WBX,
> CBX)" of "UHD - Synchronization Application Notes" is enough to take
> advantage of it.
>
> Thank you in advance!
>
> Best Regads,
> Piotr Krysik
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Both the WBX and SBX share a common synthesizer family from ADI, the
ADF4351, which is a fractional-N synthesizer. Something to note
about frac-N synthesis is that when two synthesizers each getting a
common reference clock are asked to tune to the same frequency, the
LO phase between them will have some random, unknown, offset, every
time they're tuned. This is just a basic property of these types of
synthesizers. However, these *particular* synthesizers have a
special feature, called re-synch, which can be used to drag both units into
exactly the same relative phase offset from each other. In UHD land,
this is enabled using the "timed commands" feature which is available
on the N2xx family of devices, and I believe also on the X3xx family
of devices. This works by having the tuning commands happen at precisely
the same time across all units, which causes the resynch pulse to
happen at precisely the same time, thus vastly reducing the phase offset
between synthesizers.
Now, this all requires a common refclock, and that all units in the
"group" agree on the current time-of-day, so that timed-commands can work
correctly.
A further consideration is that on the WBX card, while the *synthesizer*
can be made to agree with all its friends in the group, the *mixer* is
based on a 2XLO architecture, which means that there will always be a
180degree phase ambiguity after tuning--either its in-phase or exactly
180deg out-of-phase with others in the group. That's just because
the 2XLO phase-splitter has an unpredictable start state, so there's no way
to predict what state it's in. Resolving a 180deg phase ambiguity
should be easy enough to deal with though, if you choose to use WBX cards.
The other daughtecards have no such phase-resynch feature, because they
use different synthesizers. The "resynch" is rather a unique feature
among fractional-N synthesizers in the market. I don't know of any
other than the ADF4350/4351 that have this feature.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Mon, 09 Jun 2014 20:16:24 +0200
From: Perper <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LOs alignment in SBX daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
W dniu 09.06.2014 19:08, Marcus D. Leech via USRP-users pisze:
> On 06/09/2014 12:44 PM, Perper via USRP-users wrote:
>> Hi all,
>>
>> I have questions regarding SBX daughterboard as I'm considering if it
>> will fit my needs. I'm curious if it is appropriate for beamforming
>> without performing recalibration of antenna array after every powering
>> up of USRPs (in other words I don't want to transmit training sequences
>> after each powering up).
>>
>> The "Application Note Selecting an RF Daughterboard"
>> (http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf)
>> states,
>> that SBX has a feature that makes it distinctive among other
>> daugtherboards:
>>
>> "The Ettus Research SBX daughterboard utilizes
>> an RF PLL that includes a resynchronization feature, which can be used
>> to align the LOs across multiple SBXs, and multiple USRP hardware
>> devices."
>>
>> How is this feature different from resynchronization in other
>> daughterboards? I'm interested in the way it is achieved and differences
>> in obtained results from other daughterboards. The "UHD -
>> Synchronization Application Notes"
>> (http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series)
>>
>> doesn't make any differentiation.
>>
>> I'm also interested if this feature is fully supported by UHD driver and
>> performing steps described in "Align LOs in the front-end (SBX, WBX,
>> CBX)" of "UHD - Synchronization Application Notes" is enough to take
>> advantage of it.
>>
>> Thank you in advance!
>>
>> Best Regads,
>> Piotr Krysik
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> Both the WBX and SBX share a common synthesizer family from ADI, the
> ADF4351, which is a fractional-N synthesizer. Something to note
> about frac-N synthesis is that when two synthesizers each getting a
> common reference clock are asked to tune to the same frequency, the
> LO phase between them will have some random, unknown, offset, every
> time they're tuned. This is just a basic property of these types of
> synthesizers. However, these *particular* synthesizers have a
> special feature, called re-synch, which can be used to drag both units
> into
> exactly the same relative phase offset from each other. In UHD
> land, this is enabled using the "timed commands" feature which is
> available
> on the N2xx family of devices, and I believe also on the X3xx family
> of devices. This works by having the tuning commands happen at precisely
> the same time across all units, which causes the resynch pulse to
> happen at precisely the same time, thus vastly reducing the phase offset
> between synthesizers.
>
> Now, this all requires a common refclock, and that all units in the
> "group" agree on the current time-of-day, so that timed-commands can work
> correctly.
>
> A further consideration is that on the WBX card, while the
> *synthesizer* can be made to agree with all its friends in the group,
> the *mixer* is
> based on a 2XLO architecture, which means that there will always be
> a 180degree phase ambiguity after tuning--either its in-phase or exactly
> 180deg out-of-phase with others in the group. That's just because
> the 2XLO phase-splitter has an unpredictable start state, so there's
> no way
> to predict what state it's in. Resolving a 180deg phase ambiguity
> should be easy enough to deal with though, if you choose to use WBX
> cards.
>
> The other daughtecards have no such phase-resynch feature, because
> they use different synthesizers. The "resynch" is rather a unique
> feature
> among fractional-N synthesizers in the market. I don't know of any
> other than the ADF4350/4351 that have this feature.
>
>
>
Marcus, many thanks for very fast response.
I have one more question to someone who can edit documents on the
ettus.com website. The table 2 of
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
document
states that CBX and WBX daughterboard have phase sync feature. Shouldn't it be
that SBX and WBX have that capability?
Best regards,
Piotr Krysik
------------------------------
Message: 5
Date: Mon, 09 Jun 2014 14:24:59 -0400
From: "Marcus D. Leech" <[email protected]>
To: Perper <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] LOs alignment in SBX daughterboards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/09/2014 02:16 PM, Perper via USRP-users wrote:
> Marcus, many thanks for very fast response.
>
> I have one more question to someone who can edit documents on the
> ettus.com website. The table 2 of
> http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
> document
> states that CBX and WBX daughterboard have phase sync feature. Shouldn't it
> be that SBX and WBX have that capability?
>
> Best regards,
> Piotr Krysik
Yes, that's clearly a typo. The CBX uses a completely-different
synthesizer, from MAXIM, as I recall.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 6
Date: Mon, 9 Jun 2014 14:47:19 -0400
From: Robert Kossler <[email protected]>
To: Metso Mikko <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] B210 as standalone transmitter?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Mikko,
I am also interested in such a feature where the TX waveform cycles
automatically in the FPGA after initial configuration. I may look into this
down the road, but it won't be for a little while. Let me know how it goes.
Rob
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Metso Mikko via USRP-users
> Sent: Monday, June 09, 2014 7:31 AM
> To: [email protected]
> Subject: [USRP-users] B210 as standalone transmitter?
>
> hi,
>
> I am fairly new to gnuradio and we recently got an Ettus B210 to try with it.
> It
> seems to work ok , for example I can now generate an arbitrary data stream
> that is then read in a loop to be transferred from PC -> USB -> B210 -> RF.
>
> As an FPGA designer I would like to have the arbitrary transmit baseband
> data stream be generated by the FPGA on B210, instead of a PC. Then it
> would be up converted and transmitted just as the current data originating
> from PC. This way after initial configuration, the B210 would be acting as a
> highly configurable, standalone signal generator, without a need for the USB
> connection (until we want to change some run-time parameters). Is this
> doable?
>
> The Verilog source files for the current FPGA implementation are short of
> comments which makes it fairly difficult to follow. And I have not bumped
> into any documents regarding to the FPGA codes.
>
> What might be the best transmit interface inside the FPGA to de-attach data
> source side and replace it with a self-made signal source instead? Any
> directions and/or instructions would be highly welcome.
>
> Regards
> mikko
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Mon, 9 Jun 2014 12:17:57 -0700
From: Michael West <[email protected]>
To: ??? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time_spec
Message-ID:
<CAM4xKrrdeZgtwYZ4yzU=ErDfH_ZAG37YdoFq6cNf4NSXjs4y=g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi W,
The time_spec should only be set on the first packet in the burst. The
timing of the rest of the samples is determined by the tx_rate. Data is
buffered up and transmitted at the specified rate, so send the data as
quickly as possible to keep the buffer from getting empty (you will see a
"U" if not sending data fast enough).
Regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Fri, Jun 6, 2014 at 6:56 PM, ??? via USRP-users <
[email protected]> wrote:
> Hi everyone:
> Now i use the uhd api to write a program.I want to realize:
>
> ---------->(master usrpN210)send
> ---------->(slave usrpN210)send
> Namely.two usrp send the first sample simultaneously after some times.
> So,i use the command like this:
> uhd::tx_metadata_t md[tx_ant];
> md[i].has_time_spec=true;
> md[i].start_of_burst=true;
> md[i].end_of_burst=false;
> md[i].time_spec = uhd::time_spec_t(time_to_send);
> But i find a phenomenon:if i set the time_to_send too small,when the
> program run,it will display so many "LLLLLLL".If i set the time_to_send too
> large,my program can't run normally.
> Can someone tell me what is the relationship between the
> time_to_send and the number of samples which to be send.Or others?
> Thanks.
> Best regards,
> W
>
>
>
>
>
>
> _______________________________________________
> 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/20140609/022eb8a5/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 9 Jun 2014 13:25:50 -0600
From: alejandro kilei <[email protected]>
To: [email protected]
Subject: [USRP-users] usrp_samples.dat plot
Message-ID:
<CAN6OAx2Wr=atam7t3+q+nzss2yzb8erxf0xpyo+12xvsyvh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am using the example program rx_samples_to_file that saves to
usrp_samples.dat. usrp_samples.dat is saved as a binary file. My question
is how do I plot usrp_samples.dat in matlab? I know I should be expecting
two 100kHz sine waves with 90 degrees out of phase. How do I plot this file
in Matlab or is there some example code that I could use to plot it to make
sure it is working correctly?
Thanks for the help. You guys are great.
Alejandro Kilei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140609/53f2e0a4/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 9 Jun 2014 15:39:58 -0400
From: Robert Kossler <[email protected]>
To: alejandro kilei <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] usrp_samples.dat plot
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Alejandro,
Something like the following should work assuming that you saved the data as
16-bit integers rather than floating point numbers. If you have a two channel
device and you have the two signals you mention on separate channels, keep in
mind that the ?rx_samples_to_file? utility only saves one channel.
Rob
fh = fopen(?usrp_samples.dat?,?rb?);
data = fread(fh,?int16?);
cdata = complex(data(1:2:end),data(2:2:end));
fclose(fh);
plot(real(cdata))
From: USRP-users [mailto:[email protected]] On Behalf Of
alejandro kilei via USRP-users
Sent: Monday, June 09, 2014 3:26 PM
To: [email protected]
Subject: [USRP-users] usrp_samples.dat plot
I am using the example program rx_samples_to_file that saves to
usrp_samples.dat. usrp_samples.dat is saved as a binary file. My question is
how do I plot usrp_samples.dat in matlab? I know I should be expecting two
100kHz sine waves with 90 degrees out of phase. How do I plot this file in
Matlab or is there some example code that I could use to plot it to make sure
it is working correctly?
Thanks for the help. You guys are great.
Alejandro Kilei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140609/86cce420/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 09 Jun 2014 16:36:50 -0400
From: "Marcus D. Leech" <[email protected]>
To: Roland Awusie <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] (no subject)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 06/09/2014 04:12 PM, Roland Awusie wrote:
> Marcus,
>
> Thank you for the speedy response. I just removed all saved
> build-gnuradio versions and rerun the script. The msg below similar to
> earlier one above.
Not sure how to communicate this more effectively. When you run the
build-gnuradio script, run it with the "-v" option:
build-gnuradio -v
So that it gives more information about what it's doing.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 11
Date: Mon, 9 Jun 2014 13:51:19 -0700
From: Ashish Chaudhari <[email protected]>
To: GW <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD support for National Instruments DAQ
hardware
Message-ID:
<CAOzXT+CA5nwFeGhjLG9aJn=hw7dw3v1tft4_1tve2qrb_sr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Greg,
It should be possible to support NI DAQ hardware through GNU Radio,
however, I must warn you that it is not going to be a trivial task. The NI
DAQmx (http://www.ni.com/dataacquisition/nidaqmx.htm) software package
provides a C/C++ API to do things like creating tasks, channels, streaming
data, etc. In theory you can write a GNU Radio block that wraps this API to
create the source and sink that you talk about. Here are some resources
that you can use to do some basic stuff with a DAQ device (some of them are
for LabVIEW but you should be able to find a C API mapping for everything):
http://www.ni.com/white-paper/5468/en/
http://www.ni.com/white-paper/5409/en/
http://www.ni.com/white-paper/3021/en/
A major part of the effort to make a GNU Radio block would be to bridge the
GNU Radio and DAQmx APIs. NI DAQmx is supported in Windows and certain
enterprise Linux distributions and most DAQ hardware products have Linux
support.
Unfortunately, UHD is not the right framework to support DAQ devices
because the USRP programming model is drastically different from the DAQmx
model, and we are not planning on supporting non-USRP devices with UHD at
least in the near future.
Regards,
Ashish Chaudhari
On Sun, Jun 8, 2014 at 6:11 PM, GW via USRP-users <
[email protected]> wrote:
>
> I would like to configure GNU Radio to support a new source and sink
> device such as a National Instruments DAQ device. Sort of like the audio
> sink except with faster sample rates. Has anyone looked at developing a
> UHD driver for a general purpose DAQ device? Is UHD even the right
> framework to developing such a driver?
>
> If not, I would like to look into developing one. I welcome any advice or
> pointers.
>
> Thanks,
>
> Greg
>
> _______________________________________________
> 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/20140609/6a76d067/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 9 Jun 2014 22:27:25 +0100
From: Hacker Fantastic <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Inquiries on Ettus USRP E110 Hardware Driver
Message-ID:
<cag-oiemc7khhru_axpim7r4gylun15vxgzmrkm6w8_jje84...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Apologies you are correct, you can do all development in the E110 itself
however when performing lots of computations & FFTs with X11 loaded I found
development to be slowed and as a preference developed on a different
system before running on E series!
On 9 Jun 2014 16:37, "Thierry Guichon via USRP-users" <
[email protected]> wrote:
> As a matter of fact, everything is already pre-installed in the
> E100/E110. Not the latest version though.
>
> I suggest to become familiar with the way it works before trying to
> update anything.
>
>
>
> A serial port connection, an SSH connection or connecting the E110
> directly to a display and keyboard will work.
>
>
>
> Sincerely
>
>
>
> Thierry
>
>
> ------------------------------
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Hacker Fantastic via USRP-users
> *Sent:* Sunday, June 08, 2014 5:51 AM
> *To:* Chun Mein Soon
> *Cc:* [email protected]; ahmad zuri sha'ameri
> *Subject:* Re: [USRP-users] Inquiries on Ettus USRP E110 Hardware Driver
>
>
>
> Hi Chun,
>
> The E110 series is an embedded platform and not accessible
> from your computer via the UHD driver. You will need to use the CONSOLE
> connection with a USB cable to access the embedded Linux platform. You copy
> your GNU/Radio applications from your computer and run it on the E110.
>
>
>
> Kind Regards,
>
> Matthew
>
>
>
>
>
> On Sun, Jun 8, 2014 at 4:18 AM, Chun Mein Soon via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
>
>
> I have encountered issue with of finding suitable driver of this device
> (Ettus USRP E110).
>
>
>
> Device: Ettus Research USRP E110 S/N No: E9R 12X6E2
>
> Daugtherboards: SBX
>
> Software: Visual Studio 2010 C++
>
> Installed Software Dependencies: 1) CMake 2.6
>
> 2) Boost 1.55
>
> 3) LibUSB
>
> 4) Python 2.6
>
> 5) Cheetah 2.0
>
> Installed Driver: 1) UHD Driver version *003.007.001(Stable) *
>
> Report Issue: 1) Driver not detected in system device manager (Refer to
> Attachment Picture No Driver.jpg)
> 2) Inappropriate driver(Refer to Attachment Picture
> Driver From Ettus.jpg)
> - Driver Link Source:
> http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
> - Supported Device in the zip package doesn't
> include E110
>
>
>
>
>
> Summary: What I was trying to do is just to run a simple example software
> that come from the UHD folder after the driver installation(e.g.
> tx_waveforms.exe). However, it won't run because my computer can't detect
> the USRP device. I connect the USB console to my PC and
> run uhd_find_devices.exe file which show that my PC does not detect the
> device.
>
>
>
> Could you kindly send me a tutorials for using this device?
>
>
>
> Thank you
>
>
>
> Regards
>
> Soon Chun Mein
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> --
> Matthew Hickey
> Tel: +44 7543 661237
> Web: http://blog.hackerfantastic.com
>
> Please visit my website for blog postings, status updates and project
> information.
>
>
>
>
> _______________________________________________
> 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/20140609/d714cc6e/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 10 Jun 2014 10:11:46 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 as standalone transmitter?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello Mikko,
> As an FPGA designer I would like to have the arbitrary transmit baseband data
> stream be generated by the FPGA on B210, instead of a PC.Then it would be up
> converted and transmitted just as the current data originating from PC. This
> way after initial configuration, the B210 would be acting as a highly
> configurable, standalone signal generator, without a need for the USB
> connection (until we want to change some run-time parameters). Is this doable?
Doable: Yes (with some small print[1]); a lot of work: Yes.
The B200 series basically consists of two logic devices: the USB3
controller, running the firmware to talk to the PC, and the FPGA, which
does all the heavy DSP lifting and timing-sensitive and high-bandwidth
hardware interfacing.
The signal processing done in the FPGA includes digital frequency
shifting, so this kind of already is a signal generation on the FPGA.
You might want to have a look at the uhd/fpga/usrp3/lib/dsp folder.
Since there is the assumption that data comes from the PC through the
USB3 controller into the FPGA, you'll have to thoroughly change the
firmware, too. If you wanted to do narrowband signal generation (i.e.
only USB3-achievable sampling rates) that wouldn't need a significant
amount of processing power, you'd be likely to put that into your
firmware fork.
Since I assume that, because FPGA development is kind of hard compared
to software, you're asking because you want to use the full DAC/ADC
bandwidth (which wouldn't pass through USB3), you might want to ask
yourself what data you want to produce. The typical usecase for high
ADC/DAC bandwidth without much information going from PC to device is
radar, where high signal bandwidth means better resolution, and you want
to mix the RX with the TX (depending the type of radar) on the device
itself. That, on the other hand, seems more likely possible, because it
is but a modification to the DSP chain; a significant one, but it leaves
the streaming architecture intact, and the firmware wouldn't even
necessarily notice.
Having described this, it's a step away from the USRP approach to SDR,
and you should carefully consider if it's worth the effort to write
something that is inherently specific to your singular use case.
Greetings,
Marcus
[1] Controller firmware and FPGA bitstream are loaded at device
initialization from the host PC; you will need a PC for the B210 to be a
B210.
On 09.06.2014 13:30, Metso Mikko via USRP-users wrote:
> hi,
>
> I am fairly new to gnuradio and we recently got an Ettus B210 to try with it.
> It seems to work ok , for example I can now generate an arbitrary data stream
> that is then read in a loop to be transferred from PC -> USB -> B210 -> RF.
>
> As an FPGA designer I would like to have the arbitrary transmit baseband data
> stream be generated by the FPGA on B210, instead of a PC. Then it would be up
> converted and transmitted just as the current data originating from PC. This
> way after initial configuration, the B210 would be acting as a highly
> configurable, standalone signal generator, without a need for the USB
> connection (until we want to change some run-time parameters). Is this doable?
>
> The Verilog source files for the current FPGA implementation are short of
> comments which makes it fairly difficult to follow. And I have not bumped
> into any documents regarding to the FPGA codes.
>
> What might be the best transmit interface inside the FPGA to de-attach data
> source side and replace it with a self-made signal source instead? Any
> directions and/or instructions would be highly welcome.
>
> Regards
> mikko
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 14
Date: Tue, 10 Jun 2014 14:20:48 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 as standalone transmitter?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/10/2014 10:11 AM, Marcus M?ller via USRP-users wrote:
> Since I assume that, because FPGA development is kind of hard compared
> to software, you're asking because you want to use the full DAC/ADC
> bandwidth (which wouldn't pass through USB3), you might want to ask
> yourself what data you want to produce. The typical usecase for high
> ADC/DAC bandwidth without much information going from PC to device is
> radar, where high signal bandwidth means better resolution, and you want
> to mix the RX with the TX (depending the type of radar) on the device
> itself. That, on the other hand, seems more likely possible, because it
> is but a modification to the DSP chain; a significant one, but it leaves
> the streaming architecture intact, and the firmware wouldn't even
> necessarily notice.
If bandwidth is an issue, then remember that the AD9361 has lower
sampling rate than other devices, such as the N210 or even USRP1. At max
recommended clock rate (56 MHz), you can still get the full bandwidth
over USB3 -- in theory. The reality of USB3 chipsets is that this won't
always work, but with good chipsets there's no reason it shouldn't.
Martin
------------------------------
Message: 15
Date: Tue, 10 Jun 2014 14:26:53 +0200
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Ver 3.7 stable?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/07/2014 06:05 PM, Mamoru Yamamoto wrote:
> Dear experts,
>
> <I send this question to both GNU radio and USRP mailing lists. I do not
> know which is better place for this discussion.>
Mamoru,
in this case, the GNU Radio mailing list would have been better, but
cross-posting is also fine.
I hope our responses have been helpful!
Martin
>
> (1) Introduction
> I am Mamoru Yamamoto from Kyoto Univ.
> Some may know that I am doing satellite-beacon experiment
> by using USRP1 + GNU Radio. We call the receiver as
> GRBR (GNU Radio Beacon Receiver).
> http://www.rish.kyoto-u.ac.jp/digitalbeacon/
> Sorry this web site is very old. Now I am using
> USRP1 + uhd + GNU Radio from python script
> Also I am using Ubuntu 12.04LTS.
> My application is a very simple dual-channel receiver
> recording IQ time-series on two files.
> The system is VERY stable and useful. I like it very much.
>
> (2) Current situation
> Now I try to move to Ver 3.7.
> (I installed the software by "build-gnuradio script".)
> Necessary small changes for me were
> -- "optfir.low_pass" location change
> -- "freq_xlating_fir_filter_ccf" location change & centerfrequency
> setting from negative to positive
> -- "file_sink" location change
>
> (3) Questions
> These changes were done. I now start running the system,
> but have problems. I have 2 questions.
>
> Q1: I run the modified code with Ubuntu-32bit 12.04LTS. My code worked
> for several times, but after that, it created only "0-byte" files
> (=immediate stop), and then no files were created. I checked the uhd
> status, and found that "uhd_find_devices" was successful while
> "uhd_usrp_probe" failed (see below). I now connect USRP1 to USB3 port.
> Is this wrong?
>
> Q2: I also tried to use the same V3.7 code with Ubuntu-64bit 12.04LTS.
> But output file from my code is always 0-bytes (=immediate stop).
> Please tell me if 64bit OS is useless.
>
> === Check after the problem (Q1) ===
> beacon@Beacon-36:~/beaconRX$ uhd_find_devices
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.001-72-g383061d8
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: usrp1
> name:
> serial: 2R24X5U1
>
>
> beacon@Beacon-36:~/beaconRX$ uhd_usrp_probe
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.001-72-g383061d8
>
> -- Opening a USRP1 device...
> Error: RuntimeError: usb rx6 submit failed: LIBUSB_ERROR_IO
>
> ==============================
>
> Thanks for your help and suggestions.
>
------------------------------
Message: 16
Date: Tue, 10 Jun 2014 23:48:23 +0800
From: Chun Mein Soon <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: Inquiries on Ettus USRP E110 Hardware
Driver
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thx for the clarification!
I already successful access the device via console through serial com. After
that, i follow the steps in this following link
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ
remove the old uhd driver then install the latest uhd driver built and install.
However, the example wont run as expected..
the error code is
RuntimeError: Expected module compatibility number 0x4, but got 0x3..May refer
to screenshot as attached in this email..
Many thanks
Date: Mon, 9 Jun 2014 22:27:25 +0100
To: [email protected]
CC: [email protected]
Subject: Re: [USRP-users] Inquiries on Ettus USRP E110 Hardware Driver
From: [email protected]
Apologies you are correct, you can do all development in the E110 itself
however when performing lots of computations & FFTs with X11 loaded I found
development to be slowed and as a preference developed on a different system
before running on E series!
On 9 Jun 2014 16:37, "Thierry Guichon via USRP-users"
<[email protected]> wrote:
As a matter of fact, everything is already
pre-installed in the E100/E110. Not the latest version though.
I suggest to become familiar with
the way it works before trying to update anything.
A serial port connection, an SSH
connection or connecting the E110 directly to a display and keyboard will work.
Sincerely
Thierry
From: USRP-users
[mailto:[email protected]] On
Behalf Of Hacker Fantastic via USRP-users
Sent: Sunday, June 08, 2014 5:51
AM
To: Chun Mein Soon
Cc: [email protected];
ahmad zuri sha'ameri
Subject: Re: [USRP-users]
Inquiries on Ettus USRP E110 Hardware Driver
Hi Chun,
The E110 series is an
embedded platform and not accessible from your computer via the UHD driver. You
will need to use the CONSOLE connection with a USB cable to access the embedded
Linux platform. You copy your GNU/Radio applications from your computer and run
it on the E110.
Kind Regards,
Matthew
On Sun, Jun 8, 2014 at 4:18 AM, Chun Mein Soon via USRP-users
<[email protected]>
wrote:
Hi,
I have encountered issue with of finding suitable driver of this
device (Ettus USRP E110).
Device: Ettus Research USRP E110 S/N No: E9R 12X6E2
Daugtherboards: SBX
Software: Visual Studio 2010 C++
Installed Software Dependencies: 1) CMake 2.6
2) Boost 1.55
3) LibUSB
4) Python 2.6
5) Cheetah 2.0
Installed Driver: 1) UHD Driver version 003.007.001(Stable)
Report Issue: 1) Driver not detected in system device manager
(Refer to Attachment Picture No Driver.jpg)
2) Inappropriate driver(Refer to Attachment Picture Driver From
Ettus.jpg)
- Driver Link Source:
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
- Supported Device in the zip package doesn't
include E110
Summary: What I was trying to do is just to run a simple example
software that come from the UHD folder after the driver installation(e.g.
tx_waveforms.exe). However, it won't run because my computer can't detect
the USRP device. I connect the USB console to my PC and
run uhd_find_devices.exe file which show that my PC does not detect the
device.
Could you kindly send me a tutorials for using this device?
Thank you
Regards
Soon Chun Mein
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Matthew Hickey
Tel: +44 7543 661237
Web: http://blog.hackerfantastic.com
Please visit my website for blog postings, status updates and project
information.
_______________________________________________
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/20140610/63da314b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.jpg
Type: image/jpeg
Size: 250077 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/63da314b/attachment-0001.jpg>
------------------------------
Message: 17
Date: Tue, 10 Jun 2014 23:49:20 +0800
From: Chun Mein Soon <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: Inquiries on Ettus USRP E110 Hardware
Driver
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thx for the clarification!
I already successful access the device via console through serial com. After
that, i follow the steps in this following link
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ
remove the old uhd driver then install the latest uhd driver built and install.
However, the example wont run as expected..
the error code is
RuntimeError: Expected module compatibility number 0x4, but got 0x3..May refer
to screenshot as attached in this email..
Many thanks
Date: Mon, 9 Jun 2014 22:27:25 +0100
To: [email protected]
CC: [email protected]
Subject: Re: [USRP-users] Inquiries on Ettus USRP E110 Hardware Driver
From: [email protected]
Apologies you are correct, you can do all development in the E110 itself
however when performing lots of computations & FFTs with X11 loaded I found
development to be slowed and as a preference developed on a different system
before running on E series!
On 9 Jun 2014 16:37, "Thierry Guichon via USRP-users"
<[email protected]> wrote:
As a matter of fact, everything is already
pre-installed in the E100/E110. Not the latest version though.
I suggest to become familiar with
the way it works before trying to update anything.
A serial port connection, an SSH
connection or connecting the E110 directly to a display and keyboard will work.
Sincerely
Thierry
From: USRP-users
[mailto:[email protected]] On
Behalf Of Hacker Fantastic via USRP-users
Sent: Sunday, June 08, 2014 5:51
AM
To: Chun Mein Soon
Cc: [email protected];
ahmad zuri sha'ameri
Subject: Re: [USRP-users]
Inquiries on Ettus USRP E110 Hardware Driver
Hi Chun,
The E110 series is an
embedded platform and not accessible from your computer via the UHD driver. You
will need to use the CONSOLE connection with a USB cable to access the embedded
Linux platform. You copy your GNU/Radio applications from your computer and run
it on the E110.
Kind Regards,
Matthew
On Sun, Jun 8, 2014 at 4:18 AM, Chun Mein Soon via USRP-users
<[email protected]>
wrote:
Hi,
I have encountered issue with of finding suitable driver of this
device (Ettus USRP E110).
Device: Ettus Research USRP E110 S/N No: E9R 12X6E2
Daugtherboards: SBX
Software: Visual Studio 2010 C++
Installed Software Dependencies: 1) CMake 2.6
2) Boost 1.55
3) LibUSB
4) Python 2.6
5) Cheetah 2.0
Installed Driver: 1) UHD Driver version 003.007.001(Stable)
Report Issue: 1) Driver not detected in system device manager
(Refer to Attachment Picture No Driver.jpg)
2) Inappropriate driver(Refer to Attachment Picture Driver From
Ettus.jpg)
- Driver Link Source:
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
- Supported Device in the zip package doesn't
include E110
Summary: What I was trying to do is just to run a simple example
software that come from the UHD folder after the driver installation(e.g.
tx_waveforms.exe). However, it won't run because my computer can't detect
the USRP device. I connect the USB console to my PC and
run uhd_find_devices.exe file which show that my PC does not detect the
device.
Could you kindly send me a tutorials for using this device?
Thank you
Regards
Soon Chun Mein
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Matthew Hickey
Tel: +44 7543 661237
Web: http://blog.hackerfantastic.com
Please visit my website for blog postings, status updates and project
information.
_______________________________________________
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/20140610/517ec3f5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.jpg
Type: image/jpeg
Size: 250077 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/517ec3f5/attachment-0001.jpg>
------------------------------
Message: 18
Date: Tue, 10 Jun 2014 11:50:48 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FW: Inquiries on Ettus USRP E110 Hardware
Driver
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 06/10/2014 11:48 AM, Chun Mein Soon via USRP-users wrote:
> Thx for the clarification!
>
> I already successful access the device via console through serial com.
> After that, i follow the steps in this following link
> http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ
>
> remove the old uhd driver then install the latest uhd driver built and
> install. However, the example wont run as expected..
>
> the error code is
> RuntimeError: Expected module compatibility number 0x4, but got 0x3..
> May refer to screenshot as attached in this email..
>
> Many thanks
>
Do an:
opkg update; opkg upgrade
Then reboot
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140610/97629615/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 46, Issue 10
******************************************
