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. 8-bit over the wire format and noise floor (Knee, Peter A)
2. Re: 8-bit over the wire format and noise floor ([email protected])
3. Re: FW: Config N210 with Microblaze (Ian Buckley)
4. Re: 8-bit over the wire format and noise floor ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Jun 2012 17:08:39 +0000
From: "Knee, Peter A" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] 8-bit over the wire format and noise floor
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
All,
I am currently developing a spectrum analyzer using my USRP N210. I want to be
able to display larger bandwidths so I have been experimenting with the 8-bit
over the wire mode. I'm having some issues with the ADC counts that the device
is returning. To test I am using a signal generator outputting a constant tone.
When the tone is not present, at startup, I get fairly large ADC values that
quickly go to zero. As I'm computing the FFT of these values, an all-zero
sequence is causing issues with the values returned by the FFT. There are
obvious ways around this but I have a feeling it is part of a larger issue.
When the tone is present, being generated anywhere from -50 to -20 dBm, I begin
seeing larger values over the wire, but they are not scaling with the increase
in power output. After the initial startup sequence, the values I'm seeing for
both the I and Q channels are no larger than +/- 20 on average.
I'm attaching the basics of the C++ code I'm using to acquire the signal in
8-bit mode. My guess is that this issue is a lack of understanding about the
basics of the receiver and the ADC conversion process. I should not that
everything seems to scale accordingly when using 16-bit over the wire mode.
Any help that can be provided would be greatly appreciated.
Thanks,
Peter Knee
Code:
//Variables
uhd::rx_metadata_t md;
uhd::rx_streamer::sptr rx_stream;
//Setup device
uhd::stream_args_t stream_args("sc16","sc8");
rx_stream = usrp->get_rx_stream(stream_args);
uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
usrp->issue_stream_cmd(stream_cmd);
//Set up buffer
std::vector< std::complex<short> > buff(10000);
//Read in short data
nSampsRead = rx_stream->recv(&buff.front(),buff.size(),md);
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/13bf7504/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 12 Jun 2012 13:15:45 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] 8-bit over the wire format and noise floor
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Jun 2012 13:08, Knee, Peter A wrote:
> All,
>
> I am
currently developing a spectrum analyzer using my USRP N210. I want to
be able to display larger bandwidths so I have been experimenting with
the 8-bit over the wire mode. I'm having some issues with the ADC counts
that the device is returning. To test I am using a signal generator
outputting a constant tone.
>
> When the tone is not present, at
startup, I get fairly large ADC values that quickly go to zero. As I'm
computing the FFT of these values, an all-zero sequence is causing
issues with the values returned by the FFT. There are obvious ways
around this but I have a feeling it is part of a larger issue.
>
>
When the tone is present, being generated anywhere from -50 to -20 dBm,
I begin seeing larger values over the wire, but they are not scaling
with the increase in power output. After the initial startup sequence,
the values I'm seeing for both the I and Q channels are no larger than
+/- 20 on average.
>
> I'm attaching the basics of the C++ code I'm
using to acquire the signal in 8-bit mode. My guess is that this issue
is a lack of understanding about the basics of the receiver and the ADC
conversion process. I should not that everything seems to scale
accordingly when using 16-bit over the wire mode.
>
> Any help that
can be provided would be greatly appreciated.
>
> Thanks,
>
> Peter
Knee
>
> CODE:
>
> //Variables
>
> uhd::rx_metadata_t md;
>
>
uhd::rx_streamer::sptr rx_stream;
>
> //Setup device
>
>
uhd::stream_args_t stream_args("sc16","sc8");
>
> rx_stream =
usrp->get_rx_stream(stream_args);
>
> uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>
>
usrp->issue_stream_cmd(stream_cmd);
>
> //Set up buffer
>
>
std::vector< std::complex > buff(10000);
>
> //Read in short data
>
> nSampsRead = rx_stream->recv(&buff.front(),buff.size(),md);
They're
proportional to the instantaneous voltage seen by the ADC. Power is
proportional to the square-root of the voltage. Does that make more
sense now?
-Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/8ecc4531/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 12 Jun 2012 10:16:15 -0700
From: Ian Buckley <[email protected]>
To: Huldi Michael <[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] FW: Config N210 with Microblaze
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sorry, I answered without thinking yesterday and led you astray, too much talk
about promgen.....usrp_n2xx_net_burner.py indeed expects a raw bitstream format
file, 0xAA99 is what Xilinx call the synchronization word, and it's used by the
configuration logic to align the incoming data for correct FPGA configuration.
usrp_n2xx_net_burner.py looks for this in a file as a sanity check that it's
the correct format file.
Normally bitgen directly produces both .bit and .bin files (and many others)
and these are directly used by usrp_n2xx_net_burner.py in the normal USRP flow.
If you need help with post-processing blockRAM initializations into a
pre-compiled bitstream try this document:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2mem.pdf
-Ian
On Jun 12, 2012, at 2:16 AM, Huldi Michael wrote:
> Isn?t the file in MCS format for loading directly to the Flash via Jtag? If I
> convert the BIT file with the command ?promgen -w -spi -p mcs -o $(MCS_FILE)
> -s 4096 -u 0 $(BIT_FILE)? the generated MCS file is around 3.9MB, that means
> four times bigger than the BIT or BIN file.
>
> I figured out that the net burner scan the BIN file for 0hAA99 to accept the
> BIN file. If I combine the BIT file with the ELF file I overwrite this part.
> Could you say me the meaning of this check? Is there perhaps a conflict
> between the bootloader part and the program code from the microblaze?
>
> Michael
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> usrp_n2xx_net_burner.py expects FPGA configuration images to be in MCS
> format. Look in Makefile.common to understand the > correct invocation of
> promgen
> -Ian
On Jun 11, 2012, at 7:38 AM, Huldi Michael wrote:
> Hi,
> I give you right that the problems with the tools of Xilinx not your issue
> is. But fact is if I add a elf-file from microblaze to a ise-project and
> generate the .bit file for an other hardware than USRP N210 so I can download
> the generated download.bit file via Jtag and it works.
> But if I generate the download.bit file on the same way and convert the
> generated download.bit file with the command "promgen -u 0x0 download.bit -p
> bin -w " to a .bin file, the net-burner doesn?t accept the file.
> Do you have an idea how I can solve this problem on a simple way. Because to
> write some extra zpu-firmware is too complex.
> Thanks Michael
>
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Donnerstag, 7. Juni 2012 18:54
> To: Huldi Michael
> Cc: '[email protected]'
> Subject: Re: [USRP-users] Config N210 with Microblaze
>
> Michael, I'm a little confused by what your actual question is? It seems your
> having fundamental tactical problems loading a new FPGA image onto the N210,
> but the question you pose is architectural: "Is it possible to program the
> fpga with impact via JTAG? How could I insert the zpu firmware file in this
> case?"
>
> I'm not going to address your problems with using the Xilinx Microblaze SDK,
> that's a Xilinx proprietary flow and not something I, nor anyone at Ettus
> uses. But I'll try to give you some architectural guidelines how to add a new
> microprocessor to the N210:
>
> First, yes it's entirely possible to use impact to program the FPGA, this is
> how all new H/W is initially brought up. However note that unless you design
> the H/W to have an attached FLASH RAM in a way supported by impact for JTAG
> programming then you are only to directly configure the FPGA and that
> configuration will be lost every power cycle/reset. The USRP SPI flash is not
> programable via impact, so all non-volatile FPGA images and firmware images
> have to be burned under firmware & FPGA control.
>
> Now to boot an embedded microprocessor there are generally 2 different
> approaches:
> 1) The boot vector (PC after reset) directly addresses a discrete FLASH RAM
> that you can program externally (normally via JTAG)...this option doesn't
> exist for unmodified N210 H/W.
> 2) The boot vector addresses an internal stable boot ROM (a pre-initialized
> BRAM in a Xilinx) and the microcode in there performs a second stage boot,
> getting more firmware from elsewhere (FLASH RAM, network etc). This is how
> the stock N210 works with the ZPU and the attached SPI flash, which contains
> multiple FPGA and firmware images. In this case the ZPU boot's with the
> bootrom code in one BRAM, and uses this code to load the production firmware
> ware image from SPI FLASH to the other at which point it does a quick FPGA
> logic trick, swaps the MSB of the 2 BRAM's so that the boot vector now points
> to the other BRAM and toggles the ZPU reset line to cause a new (ZPU not
> FPGA) boot.
>
> Since you already have a working bootable and upgradable system in the stock
> N210, I strongly suggest the following approach:
> 1) Add your second microprocessor (I suggest reusing the ZPU, firmware
> libraries and tools..but you may have a compelling reason to learn and use
> Xilinx microblaze SDK) to the existing FPGA build methodology and continue to
> use the Ettus Makefile driven scripts to build and upload a new FPGA image
> via the network.
>
> 2) Make the BRAM(s) that contain the firmware for your new microprocessor
> exist also in the existing ZPU memory map. You can do this either by
> multiplexing them or making use of the dual port nature of BRAM.
>
> 3) Write some extra firmware for the existing ZPU so that it handles the
> download of your new microprocessors firmware from network to SPI flash and
> from SPI flash to BRAM exploiting all the TCP/IP based updater code that
> already exists. Boot your second microprocessor after and under the control
> of the original ZPU.
>
> This will be less work than you imagine since you will essentially be able to
> re-use all Josh's existing firmware code and the H/W design idea's behind the
> N210. You'll have a system quickly where you will not have to rebuild the
> FPGA every time you change firmware.
>
> Hope this helps,
> -Ian
>
>
>
>
>
>
> On Jun 7, 2012, at 5:53 AM, Huldi Michael wrote:
>
>
> Hello,
>
> I need help to get a simple microblaze configuration with bram-memory working
> with the USRP N210 release_003_004_001.
>
> I removed the tx chain and insert the microblaze in the top and connect 2 of
> the leds from the front to the microblaze gpio. Run a software with a
> blinking led function.
>
> I tried different ways to program the fpga without success:
>
> 1. add the elf-file from the microblaze to the ise-project and generate a
> .bin File with double click to "generate programming file" in ise, then
> download with net burner.
>
> 2. combine the bitstream with the elf file, which resides in the bram in SDK
> with "Programm FPGA" to a .bit file, then convert the generated file
> download.bit to a .bin file with "promgen -u 0x0 download.bit -p bin -w " and
> try to download with net burner. But the net burner says "Invalid FPGA image
> file".
>
> 3. Download with Platform Cable and with SDK, JTAG connected to the FPGA. But
> here it doesn't load the new configuration, since the leds I disconnect still
> light up in startup.
>
> I also changed the StartUpClk in the bitgen.ut from JTAGCLK to CCLK.
>
> Someone have an idea, how to make my configuration working? Is it possible to
> program the fpga with impact via JTAG? How could I insert the zpu firmware
> file in this case?
>
> Thanks for your help!
> Huldi
>
> _______________________________________________
> 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/20120612/5a4b5bf0/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 12 Jun 2012 13:16:54 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] 8-bit over the wire format and noise floor
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Jun 2012 13:15, [email protected] wrote:
> On 12 Jun 2012
13:08, Knee, Peter A wrote:
>
>> All,
>>
>> I am currently
developing a spectrum analyzer using my USRP N210. I want to be able to
display larger bandwidths so I have been experimenting with the 8-bit
over the wire mode. I'm having some issues with the ADC counts that the
device is returning. To test I am using a signal generator outputting a
constant tone.
>>
>> When the tone is not present, at startup, I get
fairly large ADC values that quickly go to zero. As I'm computing the
FFT of these values, an all-zero sequence is causing issues with the
values returned by the FFT. There are obvious ways around this but I
have a feeling it is part of a larger issue.
>>
>> When the tone is
present, being generated anywhere from -50 to -20 dBm, I begin seeing
larger values over the wire, but they are not scaling with the increase
in power output. After the initial startup sequence, the values I'm
seeing for both the I and Q channels are no larger than +/- 20 on
average.
>>
>> I'm attaching the basics of the C++ code I'm using to
acquire the signal in 8-bit mode. My guess is that this issue is a lack
of understanding about the basics of the receiver and the ADC conversion
process. I should not that everything seems to scale accordingly when
using 16-bit over the wire mode.
>>
>> Any help that can be provided
would be greatly appreciated.
>>
>> Thanks,
>>
>> Peter Knee
>>
>>
CODE:
>>
>> //Variables
>>
>> uhd::rx_metadata_t md;
>>
>>
uhd::rx_streamer::sptr rx_stream;
>>
>> //Setup device
>>
>>
uhd::stream_args_t stream_args("sc16","sc8");
>>
>> rx_stream =
usrp->get_rx_stream(stream_args);
>>
>> uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>>
>>
usrp->issue_stream_cmd(stream_cmd);
>>
>> //Set up buffer
>>
>>
std::vector< std::complex > buff(10000);
>>
>> //Read in short data
>>
>> nSampsRead = rx_stream->recv(&buff.front(),buff.size(),md);
>
>
They're proportional to the instantaneous voltage seen by the ADC. Power
is proportional to the square-root of the voltage. Does that make more
sense now?
>
> -Marcus
Damnit! Proportional to the *SQUARE* of the
voltage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120612/951e58d5/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 22, Issue 13
******************************************
