[USRP-users] E310 and latest sdcard image
Hello, I'm having trouble booting from the latest sdcard images for the e310. [1] I've tried a couple of different sd-cards, but consistently error out in uboot with the following error Copying FIT from SD to RAM... 5866988 bytes read in 338 ms (16.6 MiB/s) ## Loading kernel from FIT Image at 0200 ... Could not find configuration node ERROR: can't get kernel image! ## Error: "distro_bootcmd" not defined Has anyone been able to successfully use the latest e310 images? Thanks. [1] https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/e3xx_e310_sg1_sdimg_default-v3.15.0.0.zip ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 and latest sdcard image
Never mind. I should have been using "speed grade 3" not 1 for my model of e310. For future googlers this page [2] talks about how to read the product number to determine the speed grade. [2] https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images On Wed, Feb 19, 2020 at 9:33 AM Luke Whittlesey wrote: > > Hello, > I'm having trouble booting from the latest sdcard images for the e310. [1] > I've tried a couple of different sd-cards, but consistently error out > in uboot with the following error > > > Copying FIT from SD to RAM... > 5866988 bytes read in 338 ms (16.6 MiB/s) > ## Loading kernel from FIT Image at 0200 ... > Could not find configuration node > ERROR: can't get kernel image! > ## Error: "distro_bootcmd" not defined > > > > Has anyone been able to successfully use the latest e310 images? > > Thanks. > > [1] > https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/e3xx_e310_sg1_sdimg_default-v3.15.0.0.zip ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] GNU Radio UHD Blocks Resolution
Hello, I am using GNU Radio and the USRP B200. I have noticed that for the GNU block UHD: USRP Sink, the values you pass to the block must be in the range 0 to 1. I guess that means if you do not want to lose resolution you must ensure that you use the full range, that is to say, your minimum is 0 or close to 0, and your max is 1 or close to 1. Am I correct? On the other hand, what are the meaning of the values produce by the block UHD: USRP Source? They must be related to the signal power, but I am not sure about their range. Is the minimum value that block can produce the min of the ADC output, and the max, the max of the ADC output? With the USRP B200 the ADC resolution is 12 bits, are the min and the max always set with the same value, or does it depend on the USRP configuration? I am using GNU Radio right now, but probably, just knowing how this works with UHD would be enough to understand the rest. Thank you for your time, Alvaro ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] GNU Radio UHD Blocks Resolution
On 02/19/2020 12:01 PM, Alvaro Pendas via USRP-users wrote:
Hello,
I am using GNU Radio and the USRP B200. I have noticed that for the
GNU block UHD: USRP Sink, the values you pass to the block must be in
the range 0 to 1. I guess that means if you do not want to lose
resolution you must ensure that you use the full range, that is to
say, your minimum is 0 or close to 0, and your max is 1 or close to 1.
Am I correct?
On the other hand, what are the meaning of the values produce by the
block UHD: USRP Source? They must be related to the signal power, but
I am not sure about their range. Is the minimum value that block can
produce the min of the ADC output, and the max, the max of the ADC
output? With the USRP B200 the ADC resolution is 12 bits, are the min
and the max always set with the same value, or does it depend on the
USRP configuration?
I am using GNU Radio right now, but probably, just knowing how this
works with UHD would be enough to understand the rest.
Thank you for your time,
Alvaro
Gnu radio generally likes to have baesband data streams scaled into
{-1.0,+1.0} which are linearly related to instantaneous voltages at
the antenna of the hardware.
To a first approximation, a value near +1.0 or -1.0 will drive the ADC
to its maximum +/- value. But that's only an approximation, since the
signal is processed a fair amount (linearly) prior to reaching the
ADC/DAC, and with analog hardware there's no way of ensuring that
a max value wont' over-drive the analog hardware.
Power of a sinusoidal signal is proportional to the I*I + Q*Q --
remember we're dealing with *voltages* here, so ohms law applies...
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] GNU Radio UHD Blocks Resolution
Marcus thank your for your answer,
First of all, you are right, the range is -1 to 1 (instead of 0 to 1 as I
said before). So, for example, in the receiving part, the values you get
out of the UHD Source have a linear relationship with the voltage of the
analog signal, but I understand there is no easy way to calculate that
level with the only information of the GNU Radio samples. Is that correct?
El mié., 19 feb. 2020 a las 19:22, Marcus D. Leech via USRP-users (<
usrp-users@lists.ettus.com>) escribió:
> On 02/19/2020 12:01 PM, Alvaro Pendas via USRP-users wrote:
> > Hello,
> > I am using GNU Radio and the USRP B200. I have noticed that for the
> > GNU block UHD: USRP Sink, the values you pass to the block must be in
> > the range 0 to 1. I guess that means if you do not want to lose
> > resolution you must ensure that you use the full range, that is to
> > say, your minimum is 0 or close to 0, and your max is 1 or close to 1.
> > Am I correct?
> >
> > On the other hand, what are the meaning of the values produce by the
> > block UHD: USRP Source? They must be related to the signal power, but
> > I am not sure about their range. Is the minimum value that block can
> > produce the min of the ADC output, and the max, the max of the ADC
> > output? With the USRP B200 the ADC resolution is 12 bits, are the min
> > and the max always set with the same value, or does it depend on the
> > USRP configuration?
> >
> > I am using GNU Radio right now, but probably, just knowing how this
> > works with UHD would be enough to understand the rest.
> >
> > Thank you for your time,
> >
> > Alvaro
> >
> Gnu radio generally likes to have baesband data streams scaled into
> {-1.0,+1.0} which are linearly related to instantaneous voltages at
>the antenna of the hardware.
>
> To a first approximation, a value near +1.0 or -1.0 will drive the ADC
> to its maximum +/- value. But that's only an approximation, since the
>signal is processed a fair amount (linearly) prior to reaching the
> ADC/DAC, and with analog hardware there's no way of ensuring that
>a max value wont' over-drive the analog hardware.
>
> Power of a sinusoidal signal is proportional to the I*I + Q*Q --
> remember we're dealing with *voltages* here, so ohms law applies...
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] GNU Radio UHD Blocks Resolution
Indeed. You’d have to use an external calibration source at several places over
your parameter space (frequency gain sample rate)
Sent from my iPhone
> On Feb 19, 2020, at 1:54 PM, Alvaro Pendas wrote:
>
>
> Marcus thank your for your answer,
>
> First of all, you are right, the range is -1 to 1 (instead of 0 to 1 as I
> said before). So, for example, in the receiving part, the values you get out
> of the UHD Source have a linear relationship with the voltage of the analog
> signal, but I understand there is no easy way to calculate that level with
> the only information of the GNU Radio samples. Is that correct?
>
>> El mié., 19 feb. 2020 a las 19:22, Marcus D. Leech via USRP-users
>> () escribió:
>> On 02/19/2020 12:01 PM, Alvaro Pendas via USRP-users wrote:
>> > Hello,
>> > I am using GNU Radio and the USRP B200. I have noticed that for the
>> > GNU block UHD: USRP Sink, the values you pass to the block must be in
>> > the range 0 to 1. I guess that means if you do not want to lose
>> > resolution you must ensure that you use the full range, that is to
>> > say, your minimum is 0 or close to 0, and your max is 1 or close to 1.
>> > Am I correct?
>> >
>> > On the other hand, what are the meaning of the values produce by the
>> > block UHD: USRP Source? They must be related to the signal power, but
>> > I am not sure about their range. Is the minimum value that block can
>> > produce the min of the ADC output, and the max, the max of the ADC
>> > output? With the USRP B200 the ADC resolution is 12 bits, are the min
>> > and the max always set with the same value, or does it depend on the
>> > USRP configuration?
>> >
>> > I am using GNU Radio right now, but probably, just knowing how this
>> > works with UHD would be enough to understand the rest.
>> >
>> > Thank you for your time,
>> >
>> > Alvaro
>> >
>> Gnu radio generally likes to have baesband data streams scaled into
>> {-1.0,+1.0} which are linearly related to instantaneous voltages at
>>the antenna of the hardware.
>>
>> To a first approximation, a value near +1.0 or -1.0 will drive the ADC
>> to its maximum +/- value. But that's only an approximation, since the
>>signal is processed a fair amount (linearly) prior to reaching the
>> ADC/DAC, and with analog hardware there's no way of ensuring that
>>a max value wont' over-drive the analog hardware.
>>
>> Power of a sinusoidal signal is proportional to the I*I + Q*Q --
>> remember we're dealing with *voltages* here, so ohms law applies...
>>
>>
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] [Non-DoD Source] Re: RFNOC: 2 input/2 output block, synchronizing their outputs to GNURadio host
Hello Jonathan,
Fortunately, a lot of progress has been made since you mentioned some ideas for
me, I was just hesitating to reply until I got stuck again. I have been
running on an e310 a 2-stream custom noc_block with axi wrappers set to simple
mode successfully for the past few days, proving it is very much possible and
not a difficult task. I think the root cause of my problem was either:
1. Not running make clean before make install in my rfnocmodtool directory
2. Not inputting my settings registers correctly in the UHD nocsript.
3. Not correctly setting up my GRC block xml file.
4. Correcting a bug in my custom Verilog code in my noc_block.
But now there is a slight issue that I hope you can help me out with. My test
bench is composed of the e310 receiving RF from a sig gen tuned to a center
freq and sweeping the amplitude from noise floor to less than max input,
running through my custom string of IP blocks that comprise my rfnoc block
(complex to magnitude -> moving sum -> keep one in n). Data streams through
just fine, no timeouts, but sometimes I get odd results such as the magnitude
going down a little when I expected it to keep rising with the sig gen input.
I wanted to dig a little deeper into the sampling details from the rx front
end. Here’s my list of questions for you:
1. I understand from Analog documentation that the AD9361 outputs 12-bit
samples in two’s complement, is that right? Also I gather from tracing through
the HDL, within e31x_core, the data is packed MSB-aligned, with LSBs 3…0 locked
at 1’b0. When you feed a 16-bit I, 16-bit Q sample into the
complex_to_magphase IP block it outputs a 16-bit real, 16-bit phase result. So
is the magnitude (16-bit real output) formatted the same way, i.e. {D11…D0,
4’d0}? Does it not matter to that IP block whether it is MSB padded or LSB
padded? Is it also in 2’s complement?
2. Dynamic range of e310, if the samples are 12-bit then does this come
out to 20*log10(4095) = 72.2 dB? So I should be experiencing some
abnormalities at the extremes?
3. Since I have the analog bw set to 10 MHz, and I am feeding the SDR a
CW signal which is very narrow in the spectrum, is it possible to actually max
out the ADC with this bench setup?
4. Most import question, I’m using noc_block_fft as a guide for producing
magnitude samples. In that file mag_tdata[31:0] is assigned {1’b0,
mag_tdata_int[15:0], 15’d0}, then that mag_tdata is fed to axi_round_and_clip
wherein the first MSB is clipped, and truncated such that 16 bit data is
outputted. My question is: Does that not just clip the leading 0 off and round
the LSB? Then wouldn’t the host computer interpret this over the wire real
uint16 as a two’s complement float or int, going negative as the MSB goes high?
How can I treat that result as an unsigned 16-bit int?
Thank you,
Andrew
From: Jonathon Pendlum
Sent: Thursday, February 13, 2020 14:07
To: Payne, William Andrew (Andrew) CIV USN NSWC CD CRANE ID (USA)
Cc: usrp-users@lists.ettus.com; matt.peg...@ni.com
Subject: [Non-DoD Source] Re: [USRP-users] RFNOC: 2 input/2 output block,
synchronizing their outputs to GNURadio host
Hi Andrew,
Are you able to run any of the in-tree RFNoC blocks on your E310 without this
error? Does your block work if you make it 1 input / 1 output? Also, do you
have access to an X310? If so, can you try running your block on there and see
if it works?
Jonathon
On Thu, Feb 13, 2020 at 7:10 AM Payne, William Andrew (Andrew) CIV USN NSWC CD
CRANE ID (USA) via USRP-users mailto:usrp-users@lists.ettus.com> > wrote:
Hi,
I am trying to solve what I think is a timing issue with my RFNOC design. I
have an E310 running UHD 3.15LTS/GNUradio 3.7/gr-ettus.
I have created a custom RFNOC block for GNUradio without much custom logic,
I've managed to just reuse code blocks from the uhd-fpga repo in lib/rfnoc. In
particular, I am using the following blocks in this order: complex to magphase
(ISE IP in lib/rfnoc) -> moving_sum -> keep_one_in_n -> fifo with size 5 (so I
don't have to have RFNOC:FIFO blocks taking up room in the FPGA). For
moving_sum I'm trying to use 511 as the sum length and for keep_one_in_n I am
using 512. I have made this block a permanent 2 input/2 output block by
setting those parameters in noc_shell instantiation. I am using the
axi_wrappers (0 and 1) with SIMPLE MODE set to 0, and simply utilizing the
cvita_hdr_modify.v IP exactly as utilized in the noc_block_keep_one_in_n.v
block to set the tuser headers.
In Vivado behavioral simulation the data correctly flows through but what I am
unsure about is the fact that after synthesizing and loading the FPGA bit file
into the e310 and running my flowgraph, it just repeatedly prints out timeout
on channel 0. By the way this code does work on just a single input/single
output application but I want to consolidate it into a sin
