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: Problems building E110 FPGA images (Josh Blum)
   2. Re: Read RSSI with LabView (Patrick Sisterhen)
   3. Which firmware and fpga works uhd_fft.py to a spectrum
      analyzer (RFX900+USRP2) ? (Julio Hector Aguilar Renteria)
   4. Re: Which firmware and fpga works uhd_fft.py to a spectrum
      analyzer (RFX900+USRP2) ? ([email protected])
   5. about segmentation fault (????)
   6. External and internal clock sources (Nowlan, Sean)
   7. Re: Digital filters inside the FPGA (Matt Ettus)
   8. Re: Problems building E110 FPGA images (John Buetefuer)
   9. Re: [Discuss-gnuradio] Adding new hardware modules to     USRP
      (John Malsbury)
  10. Adding new hardware modules to USRP (Derrick Ho)
  11. Multiple Bitstreams (Derrick Ho)
  12. does tx i q balance calibration require rx i q balance (Page Jack)
  13. Trace module (Derrick Ho)
  14. E110 - Newbie question (Eddie)
  15. Re: E110 - Newbie question (Philip Balister)
  16. Re: Multiple Bitstreams (Nick Foster)


----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Jul 2012 09:00:09 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems building E110 FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1



On 07/09/2012 11:06 PM, John Buetefuer wrote:
> Has anyone been successful in building and programming the E110 fpga
> using the current UHD firmware?
> 
> We have both a E100 and E110 units. I've tried building the current UHD
> fpga (version 10.1) for both E100 and E110. On the E100 the resulting
> image programs succesfully and the system works.
> 
> On the E110, I continually get "OSError: INIT_B went high, error
> occurred." whenever running a uhd_usrp_probe.
> 
> The pre-built images (v10.0) work fine on this unit. The only obvious
> difference that I can see between the pre-built .bin files and the files
> that "make E110" is generating is that the pre-built are compressed,
> whereas the ones I'm building are not.
> 
> I'm using ISE 13.4 to build the images.
> 

I am unsure as to why, but if it helps in the meantime, all the packaged
bin files for E100, 110 etc are built with ISE 12.1.

Perhaps the interpretation of a project option had changed/renamed
between versions. I hope we get to the bottom of this.

-josh

> Any help would be greatfully appreciated.
> 
> Cheers
> 
> John
> 
> 
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 2
Date: Tue, 10 Jul 2012 11:15:28 -0500
From: Patrick Sisterhen <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Read RSSI with LabView
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Peng,

There is currently no way to query the RSSI value directly in the NI-USRP 
LabVIEW driver.

We could support this feature in the future, but it is not particularly 
useful because

1) it is only supported on the XCVR2450 daughterboards and
2) there is no way associate the RSSI value with data timestamps.

We recommend that you calculate a RSSI value from the digital waveform 
values.

Hope that will be acceptable.

Patrick Sisterhen
National Instruments


> Hello Everyone,
>
> could anybody tell me, how i can get the rssi value directly in LabView
> environment. I just want to make a carrier sensing block for 
decomposable
> MAC framework implementation.
> Thanks a lot.:)
> 
> BR,
> 
> Peng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/685183f2/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 10 Jul 2012 11:27:06 -0500
From: Julio Hector Aguilar Renteria <[email protected]>
To: [email protected]
Subject: [USRP-users] Which firmware and fpga works uhd_fft.py to a
        spectrum analyzer (RFX900+USRP2) ?
Message-ID:
        <CACBKi8eT63qk7CXuhyh3jNjVEda3yJEidGTxT=ued1vot9f...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi, all

Which firmware and fpga works uhd_fft.py to a spectrum analyzer
(RFX900+USRP2)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/4ab95775/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 10 Jul 2012 12:32:01 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Which firmware and fpga works uhd_fft.py to
        a spectrum analyzer (RFX900+USRP2) ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

 

On 10 Jul 2012 12:27, Julio Hector Aguilar Renteria wrote: 

> Hi,
all 
> 
> Which firmware and fpga works uhd_fft.py to a spectrum
analyzer (RFX900+USRP2)

As long as you have matching UHD and firmware,
uhd_fft should work just fine. In recent Gnu Radio revs, uhd_fft.py has
been renamed to uhd_fft. 

-Marcus 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/78b21f7f/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 11 Jul 2012 01:30:34 +0800 (CST)
From: ????   <[email protected]>
To: [email protected]
Subject: [USRP-users] about segmentation fault
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"



Dear all:

Now I meet a segmentation fault. Parts of my code are as follows:

if I run 

?????????? uint64_t testfull = timestamp_preamble_full[npreamble-1];

?????????? double testfrac = timestamp_preamble_frac[npreamble-1];



????????? // std::cout <<"the full seconds of rx_time is:" <<? testfull << 
std::endl;

which comments out the line std::cout, it works fine. However if I add 
the line std::cout, the code can run for some time and then always give me the 
segmentation fault.

Any help would be appreciated.

Best regards

Zan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120711/d515b15b/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 10 Jul 2012 17:40:12 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] External and internal clock sources
Message-ID: <195933287DC65748BA7AE867BA8E430B621F940A@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"

Hi all,

I wanted to know what kind of problems I might run into if I use an external 
PPS and the internal 10 MHz reference (USRP N200). For our application we want 
to study performance using both stable (e.g., GPSDO) and unstable  (e.g., 
factory) clocks, but we want to have the ability to tag with accurate 
timestamps.

Ideally the answer would be "timestamp = (time at PPS edge) + (sample rate) * 
(sample offset)", but the freq synthesizer can run off of a reference 
independent from the PPS. But I'm not sure if that's how it's implemented or if 
it's possible. Thanks!

Best regards,

Sean Nowlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/e2716fdf/attachment-0001.html>

------------------------------

Message: 7
Date: Wed, 11 Jul 2012 11:13:25 +0800
From: Matt Ettus <[email protected]>
To: MOISES NAVARRO <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Digital filters inside the FPGA
Message-ID:
        <CAN=1kn-5eqpxbywb+9uhapaevaharc556cw10aqyxn67zin...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 7, 2012 at 2:12 AM, MOISES NAVARRO <[email protected]> wrote:
> Dear all,
>
> We are using a USRP N210 with UHD. We are collecting data with a decimated
> factor equal to 2, so the sampling frequency is 50Mps. The results are quite
> good!
>
> But now, we dont want any digital filtering. I Think that, in the FPGA the
> signals are filtered with a half band filter, isn't it? (@ 50Msps)
> We want to keep the the same sampling frequency, but with any digital
> filtering.
> Is that possible? Can we made a "small modification" in the FPGA code in
> order to avoid the digital filters? or any idea?
>
> I know that, if we reduce the sampling frequency we could have aliasing...
> We can manage this effect without any digital filter :)

The limitation will be the ethernet interface.  It cannot keep up at
100 MS/s, so you would be limited to the number of samples you can
store in the SRAM.  Someone has posted an FPGA design to do this in
the past, so you might be able to use that.

Matt



------------------------------

Message: 8
Date: Wed, 11 Jul 2012 12:59:28 +0930
From: John Buetefuer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problems building E110 FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Josh/Philip,

It also seems that I've been living in "version hell" a little. I'm 
still getting used to "git" repositories. It seems I've been using the 
head of the "master" branch, whereas perhaps I should be using "maint".. 
Is there a document/wiki page somewhere that explains what is going on 
in the "master" branch? I should also clarify that the "S" sync problems 
I have been seeing were with the "master" UHD and fpgas.

Should "master" be (relatively) stable and suitable for use?

I've now re-built for the E110 using the *maint branch*, with ISE12.2 
(did not have 12.1 close at hand) and I get a compressed .bin file which 
successfully programs..  My observations so-far:

Build with 13.4 (maint and master, same result)
  * E100 image programs successfully. (uncompressed) *** Note, I did 
have some problems in the past with very small mods to the verilog 
resulting in a .bin file which also would not program, perhaps this may 
have been a symptom of the same problem.
  * E110 image does not program successfully. (uncompressed)

Build with 12.2 (maint)
  * E100 - not tested
  * E100 image programs successfully (compressed).

After re-building everything (uhd (maint), fpga (12.2), gnuradio), with 
the head of maint I end up with the following.

  * Using the FPGA I built (head of maint), I get no "S" output, but 
also get*no RF output* at all.
  * Using the pre-built images from 
uhd-images_003.004.002-release.tar.gz, I also get*no RF output* at all.
  * Using the pre-built 003.004.000-r0.0.9 firmware, I get output for a 
few sconds, then lots of S (RF output stops).

The 'maint' branch uhd_usrp_probe also does not appear to output the 
FPGA version number.

For completeness, I've attached my GNURadio tx_cw.py file - constant 
source + usrp_sink..

The one thing that I don't believe I've touched (yet) is the usrp_e 
driver - this is per the e1xx-003 build that shipped with the unit.

uhd_usrp_probe version output as follows:
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.004.002-7-gce2d5e2b
-- Opening device node /dev/usrp_e0...
-- Loading FPGA image: 
/home/root/uhd-images_003.004.002-release/share/uhd/images/usrp_e110_fpga.bin...
 
done = 1

Is there a 'known stable' UHD+fpga configuration for the E100/E110?

As a last-ditch effort I've tried the following:
   opkg install uhd uhd-dev uhd-examples uhd-test
   ldconfig

Producing
Installing uhd (3.4.1-r0.0.9) to root...
Downloading 
http://files.ettus.com/binaries/oe-classic-feeds/ipk/armv7a/uhd_3.4.1-r0.0.9_armv7a.ipk.
Installing uhd-dev (3.4.1-r0.0.9) to root...
Downloading 
http://files.ettus.com/binaries/oe-classic-feeds/ipk/armv7a/uhd-dev_3.4.1-r0.0.9_armv7a.ipk.
uhd-dev: unsatisfied recommendation for uhd-firmware-dev
uhd-dev: unsatisfied recommendation for boost-date-time-dev
uhd-dev: unsatisfied recommendation for boost-filesystem-dev
uhd-dev: unsatisfied recommendation for boost-program-options-dev
uhd-dev: unsatisfied recommendation for boost-regex-dev
uhd-dev: unsatisfied recommendation for boost-unit-test-framework-dev
uhd-dev: unsatisfied recommendation for liborc-0.4-dev
uhd-dev: unsatisfied recommendation for ncurses-libncurses-dev
uhd-dev: unsatisfied recommendation for ncurses-libform-dev
uhd-dev: unsatisfied recommendation for ncurses-libtinfo-dev
Installing uhd-examples (3.4.1-r0.0.9) to root...
Downloading 
http://files.ettus.com/binaries/oe-classic-feeds/ipk/armv7a/uhd-examples_3.4.1-r0.0.9_armv7a.ipk.
Installing uhd-tests (3.4.1-r0.0.9) to root...
Downloading 
http://files.ettus.com/binaries/oe-classic-feeds/ipk/armv7a/uhd-tests_3.4.1-r0.0.9_armv7a.ipk.

*uhd_usrp_probe* produces:
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.004.001-0-unknown

And I get the same "S" behaviour after 2 seconds of tx_cw.py running.

Cheers

John



On 11/07/2012 1:30 AM, Josh Blum wrote:
>
> On 07/09/2012 11:06 PM, John Buetefuer wrote:
>> Has anyone been successful in building and programming the E110 fpga
>> using the current UHD firmware?
>>
>> We have both a E100 and E110 units. I've tried building the current UHD
>> fpga (version 10.1) for both E100 and E110. On the E100 the resulting
>> image programs succesfully and the system works.
>>
>> On the E110, I continually get "OSError: INIT_B went high, error
>> occurred." whenever running a uhd_usrp_probe.
>>
>> The pre-built images (v10.0) work fine on this unit. The only obvious
>> difference that I can see between the pre-built .bin files and the files
>> that "make E110" is generating is that the pre-built are compressed,
>> whereas the ones I'm building are not.
>>
>> I'm using ISE 13.4 to build the images.
>>
> I am unsure as to why, but if it helps in the meantime, all the packaged
> bin files for E100, 110 etc are built with ISE 12.1.
>
> Perhaps the interpretation of a project option had changed/renamed
> between versions. I hope we get to the bottom of this.
>
> -josh
>
>> Any help would be greatfully appreciated.
>>
>> Cheers
>>
>> John
>>
>>
>> _______________________________________________
>> 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/20120711/c6c7f4fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_cw.py
Type: text/x-python
Size: 2486 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120711/c6c7f4fa/attachment-0001.py>

------------------------------

Message: 9
Date: Tue, 10 Jul 2012 21:14:25 -0700
From: John Malsbury <[email protected]>
To: Derrick Ho <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Adding new hardware
        modules to      USRP
Message-ID:
        <CAN5WegRAEBczJU0E_e=dqijzkanaaejsgpycg12bvbz6hx9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

What "hardware module" are you trying  to add?  I am cross-posting this to
usrp-users, which is the right place to go for USRP specific questions.

-John



On Tue, Jul 10, 2012 at 9:08 PM, Derrick Ho <[email protected]> wrote:

> Hi
> I'm trying to add a new module to the USRP's design.
> My default strategy is to look at the source code and type something up.
> I was wondering if there was an easy way to quickly plug in a new module.
> Is there a way that it can be added at a higher level?  By high level
> graphically.
>
> Thanks
>
> --Derrick
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/783009fb/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 10 Jul 2012 21:18:04 -0700
From: Derrick Ho <[email protected]>
To: [email protected]
Subject: [USRP-users] Adding new hardware modules to USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi
I'm trying to add a new module to the USRP's design.
My default strategy is to look at the source code and type something up.
I was wondering if there was an easy way to quickly plug in a new module.
Is there a way that it can be added at a higher level?  By high level 
graphically.

Thanks

--Derrick


------------------------------

Message: 11
Date: Tue, 10 Jul 2012 21:26:25 -0700
From: Derrick Ho <[email protected]>
To: [email protected]
Subject: [USRP-users] Multiple Bitstreams
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi
I was looking into modifying the source code to add custom modules.
Everything would be great except that there would be a risk in breaking
the original design.  So I looked into the FPGA chip and found that it allows 
multiple
bit streams to be loaded.  This would allow me to add a my modified design 
without ruining the
original.  This would be very helpful in case I start doing more harm then 
good.  If the new
design ends up not working then I can always default back to the original.

1) One place to have a bitstream is in a Compact flash (CF).  I don't know if 
the URSP has one.


2) I know for sure that the SPartan 3a has SPI/BPI and what I'm wondering is if 
the USRP's bit stream
is located in the SPI/BPI.

3) Can I extract the bit file out of the FPGA?  This would be for back up 
purposes incase something goes wrong.


--Derrick


------------------------------

Message: 12
Date: Wed, 11 Jul 2012 14:28:37 +0800
From: Page Jack <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] does tx i q balance calibration require rx i q
        balance
Message-ID:
        <cameg1vlijm_ha_3cyshn4sdssmhonsqny89j3oncuwe_gqq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi list,
I want to calibrate usrp tx i q balance but seems it require the receiver
side have perfect i q balance. So it is need to
do rx i q balance calibration first. but how to calibrate rx i q balance?

Regards!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120711/5c3fcf24/attachment-0001.html>

------------------------------

Message: 13
Date: Tue, 10 Jul 2012 23:42:44 -0700
From: Derrick Ho <[email protected]>
To: [email protected]
Subject: [USRP-users] Trace module
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hello

I'm trying to figure out how to add new vhdl or verilog modules to the usrp
so as a start I placed all the relevant files in a xilinx project.
In the source code I traveled to the N2x0 folder since it looked like the one 
that
matched my model.  The first problem I saw was that xilinx showed an orange 
question
mark next to modules that were inside the top level unit (i.e. u2plus.v).  
Usually that means
the project doesn't know where the files are.  So I went ahead and added 
all the files from the source.

Most of the question marks disappeared except for one.  it was called "trace".
The file "/fpga/usrp2/opencores/zpu/core/zpu_core.vhd" seems to be the only one 
using it.

The port map looks like this

----start snippit

   if Generate_Trace generate
        trace_file: trace port map (
        clk => clk,
        begin_inst => begin_inst,
        pc => trace_pc,
                opcode => trace_opcode,
                sp => trace_sp,
                memA => trace_topOfStack,
                memB => trace_topOfStackB,
                busy => busy,
                intsp => (others => 'U')
        );
        end generate;

----end snippit

At first it looked like there was no component declaration,  but I found it in 
"zpupkg.vhd"

---start snippit

        component trace is
          port(
                clk         : in std_logic;
                begin_inst  : in std_logic;
                pc          : in std_logic_vector(maxAddrBitIncIO downto 0);
                        opcode          : in std_logic_vector(7 downto 0);
                        sp                      : in 
std_logic_vector(maxAddrBitIncIO downto minAddrBit);
                        memA            : in std_logic_vector(wordSize-1 downto 
0);
                        memB            : in std_logic_vector(wordSize-1 downto 
0);
                        busy         : in std_logic;
                        intSp           : in std_logic_vector(stack_bits-1 
downto 0)
                        );
        end component;

---end snippit


The only problem is that the entity that describes this component is missing.  
I can't seem to find it.
My guess is that it is an IP core.  



Where can I FIND or GET this component?


Derrick Ho


------------------------------

Message: 14
Date: Wed, 11 Jul 2012 11:55:53 +0100
From: "Eddie" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] E110 - Newbie question
Message-ID: <97806DFEA1FE41FBB8D6F5BC97AA1453@dylan>
Content-Type: text/plain; charset="us-ascii"

I tried to update UHD on the E110 to the latest version from the Ettus
site and now when I type uhd_usrp_probe I get the error;
 
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
UHD_003.004.002-171-g7c8fef85
 
-- Opening device node /dev/usrp_e0...
Error: EnvironmentError: IOError: Could not find path for image:
usrp_e110_fpga.bin
 
 
My path (echo $PATH) is;
/usr/local/bin:/usr/bin:/bin:/usr/share/uhd:/usr/share/uhd/images:/usr/local
/sbin:/usr/sbin:/sbin
 
When I run uhd_usrp_probe from the /usr/share/uhd/images directory it
works OK. So obviously some sort of path issue but I cannot suss what
the problem is.
 
Can anyone help? (Be gentle - I am relatively new to Linux)
 
Alistair

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120711/c0fd53a2/attachment-0001.html>

------------------------------

Message: 15
Date: Wed, 11 Jul 2012 07:42:46 -0400
From: Philip Balister <[email protected]>
To: Eddie <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E110 - Newbie question
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 07/11/2012 06:55 AM, Eddie wrote:
> I tried to update UHD on the E110 to the latest version from the Ettus
> site and now when I type uhd_usrp_probe I get the error;
>
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.004.002-171-g7c8fef85
>
> -- Opening device node /dev/usrp_e0...
> Error: EnvironmentError: IOError: Could not find path for image:
> usrp_e110_fpga.bin
>
>
> My path (echo $PATH) is;
> /usr/local/bin:/usr/bin:/bin:/usr/share/uhd:/usr/share/uhd/images:/usr/local
> /sbin:/usr/sbin:/sbin
>
> When I run uhd_usrp_probe from the /usr/share/uhd/images directory it
> works OK. So obviously some sort of path issue but I cannot suss what
> the problem is.
>
> Can anyone help? (Be gentle - I am relatively new to Linux)

I am seeing something similar here. While we sort it out you can always 
do something like this:

uhd_usrp_probe --args="fpga=/usr/share/uhd/images/imagename.bin"


Where you replace the imagename bit with the path to the image you want 
to load.

Philip


>
> Alistair
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>





------------------------------

Message: 16
Date: Wed, 11 Jul 2012 07:31:24 -0700
From: Nick Foster <[email protected]>
To: Derrick Ho <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Multiple Bitstreams
Message-ID:
        <calalhjw1fq_24crpqjftbg1rknmejcwdn-ycnftdgerdmcb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Derrick,

The FPGA is programmed at boot each time the device is initialized; there
is no persistent memory on board the FPGA.

On N200/N210, the bitstream is loaded at boot via a SPI Flash memory, which
can be programmed over the Ethernet interface using the
"usrp_n2xx_net_burner" application included in UHD.

On USRP1 and B100, the bitstream is loaded over USB via the FX2 slave
controller the first time the device is used after power-on, and the FPGA
image can be specified as an initialization parameter -- for instance in
the examples which come installed with UHD, you can generally use
"--args=fpga=<path_to_binfile>" to specify the FPGA image you wish to use.

On E100, the bitstream is loaded via the embedded processor, and the same
method and syntax as B100 applies to specify a custom image.

Does this help?

Best,
Nick

On Tue, Jul 10, 2012 at 9:26 PM, Derrick Ho <[email protected]> wrote:

> Hi
> I was looking into modifying the source code to add custom modules.
> Everything would be great except that there would be a risk in breaking
> the original design.  So I looked into the FPGA chip and found that it
> allows multiple
> bit streams to be loaded.  This would allow me to add a my modified design
> without ruining the
> original.  This would be very helpful in case I start doing more harm then
> good.  If the new
> design ends up not working then I can always default back to the original.
>
> 1) One place to have a bitstream is in a Compact flash (CF).  I don't know
> if the URSP has one.
>
>
> 2) I know for sure that the SPartan 3a has SPI/BPI and what I'm wondering
> is if the USRP's bit stream
> is located in the SPI/BPI.
>
> 3) Can I extract the bit file out of the FPGA?  This would be for back up
> purposes incase something goes wrong.
>
>
> --Derrick
> _______________________________________________
> 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/20120711/d6f76979/attachment-0001.html>

------------------------------

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


End of USRP-users Digest, Vol 23, Issue 10
******************************************

Reply via email to