Re: [USRP-users] A few questions about RFNoC streaming

[Rob Kossler via USRP-users]

Thanks EJ and Nick,
I hadn't thought about the propagation of the streaming command occurring
in UHD rather than on the FPGA.  I was thinking that after issuing the
rx_streaming start command to the downstream-most block in the chain, some
magic was happening on the FPGA to get the upstream blocks started.
However, I think this makes more sense that there is some magic happening
in UHD such that the upstream blocks get the command to start streaming.  I
will let you know if I figure anything out.
Rob

On Mon, Mar 25, 2019 at 12:37 PM Nick Foster  wrote:

> I can tell you the answer to #3 off the top of my head: the two streams
> will be sample-aligned, and if you use timed start commands, they will be
> time-aligned.
>
> The other two are probably best answered by trying it out. Maybe someone
> from Ettus can chime in.
>
> Nick
>
> On Fri, Mar 22, 2019 at 7:09 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Any suggestions?
>>
>> On Wed, Mar 20, 2019 at 9:49 PM Rob Kossler  wrote:
>>
>>> Yes, the example was for illustration only.  You can throw a couple of
>>> DDCs in between the radio and add/sub block to slow the rate down.  But,
>>> the questions are still the same.
>>>
>>> On Wed, Mar 20, 2019 at 7:49 PM Nick Foster 
>>> wrote:
>>>
 First things first. The flow graph you're describing don't work because
 the two radio blocks will saturate the bus going into the addsub block. You
 will need to decimate the streams going into the addsub block.

 I don't have a ready answer to your question about the streamers, but
 I'd suggest using timed commands to align the two radio streams, if UHD
 isn't smart enough to recognize the two radios and propagate the stream
 command accordingly.

 Nick

 On Thu, Mar 21, 2019, 6:46 AM Rob Kossler via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi,
> I am starting to develop more complicated RFNoC graphs and several
> questions occurred to me. I am using my own C++ application with the UHD
> RFNoC-enabled library.
>
> Consider a receive-only RFNoC graph with 2 radio blocks feeding a
> 2-input, 2-output Add/Sub block.  Also, assume there are two rx_streamers
> connected to the 2 output ports of the Add/Sub block.  Note that these
> streams are no longer independent or one-to-one matched with the radio
> channels.
>
> 1) How does an "issue_stream_cmd()" to one of the Add/Sub block ports
> propagate back to the radio block?  Actually, it would need to propagate
> back to both Radio blocks no matter which rx_streamer I used since they 
> are
> no longer independent streams.  Does this make sense?
> 2) What happens if I only call "issue_stream_cmd()" for one of the
> rx_streamers instead of both? Perhaps since the other streamer isn't
> running, it backpressures the streaming such that it eventually quits and
> thus quits for the other port as well?
> 3) Do I have to do anything in the Add/Sub block to sync up the
> streams or can I rely on the first sample from Radio 0 being time-aligned
> with the first sample from Radio 1 (assuming I issued timed start 
> commands)?
>
> Rob
> ___
> 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
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC FFT size > 1024

[Rob Kossler via USRP-users]

Thanks Jonathon!

On Thu, Mar 28, 2019 at 5:24 AM Jonathon Pendlum 
wrote:

> Hey Rob,
>
> Regarding overflows or dropped packets, is this something that might
>> occur inside the FPGA (CE to CE) or is it just a concern on the
>> transfer to the host CPU (which is my only experience with overflows
>> or dropped packets)?  If on the FPGA, what would be the cause of
>> overflows / dropped packets in the following scenario:
>> rx_radio->DDC->FFT->host?
>
>
> Overflow generally only occurs due to the host being unable to consume
> samples quickly enough. It is possible for overflows to occur due to a
> RFNoC block not consuming samples quickly enough, but all in-tree blocks
> are designed to avoid that situation. Drops only occur between the device
> and host.
>
> Regarding the header, is the concern the following? Assume packet size
>> of 1024 and FFT size of 4096 such that there would be 4 packets for
>> each FFT; Now assume that EOB occurs on the 3rd packet such that the
>> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
>> in a bad state.  Is this the issue?  If not, please explain.  If so,
>> is the fix to reset the FFT on any incoming EOB? Without any fix, does
>> this issue correct itself in some way during the subsequent stream or
>> is the input frame mismatch issue going to remain until the FFT is
>> manually reset?
>
>
> Correct, resetting the FFT on EOB is a possible solution. If you reset on
> EOB though, you'll need to figure out a way to still send that final packet
> with EOB set to the host. Maybe zero fill the missing samples to complete
> the FFT? The issue will also fix itself on the next burst assuming you
> don't care that the first FFT might be corrupt.
>
> Jonathon
>
> On Sun, Mar 3, 2019 at 1:16 AM Rob Kossler  wrote:
>
>> Thanks Jonathon,
>>
>> > I'm glad you found those options useful. Unfortunately, there are a
>> number of corner cases that those options do not handle. You can run into
>> synchronization issues when overflows and dropped packets occur. In the
>> overflow case, if one occurs while the FFT is being filled then the next
>> FFT output will be incorrect. In the dropped packet case, the received FFT
>> frames could end up shifted between two FFT frames. The dropped packet case
>> is by the far worse of the two.
>>
>> Regarding overflows or dropped packets, is this something that might
>> occur inside the FPGA (CE to CE) or is it just a concern on the
>> transfer to the host CPU (which is my only experience with overflows
>> or dropped packets)?  If on the FPGA, what would be the cause of
>> overflows / dropped packets in the following scenario:
>> rx_radio->DDC->FFT->host?
>>
>> > The block also does not handle the packet header correctly when FFTs
>> are split between multiple packets. For example, EOBs will not cause the
>> FFT core to reset, so the next burst could have an incorrect FFT output at
>> the beginning. Most of these issues can be worked around or even ignored,
>> but I think for general usage the block will need to be updated to handle
>> them properly.
>>
>> Regarding the header, is the concern the following? Assume packet size
>> of 1024 and FFT size of 4096 such that there would be 4 packets for
>> each FFT; Now assume that EOB occurs on the 3rd packet such that the
>> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
>> in a bad state.  Is this the issue?  If not, please explain.  If so,
>> is the fix to reset the FFT on any incoming EOB? Without any fix, does
>> this issue correct itself in some way during the subsequent stream or
>> is the input frame mismatch issue going to remain until the FFT is
>> manually reset?
>>
>> Thanks for your help.
>> Rob
>>
>>
>> > On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >>
>> >> Turns out there was a surprisingly simple modification to allow FFTs
>> longer than 1024.  The axi_wrapper will automatically resize packets for
>> you if you configure it to do so.  All I had to do was set
>> RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output
>> packets to be resized to match the input packet size.  I was able to then
>> run 2048 and 4096 pt FFTs successfully (& producing the expected results)
>> and I could use any packet size I wanted going in and out of the overall
>> noc block.
>> >>
>> >> I did not even have to resize the packets going into the FFT because
>> the FFT doesn't care about input packet size with the caveat that it
>> generates various "bad size" events if it detects mismatches.  Since I am
>> not monitoring such events, it doesn't really matter. And, if I did care
>> about these bad size events, the fix is simply to add
>> RESIZE_INPUT_PACKET(1) and set the desired resize value (i.e., the FFT
>> length) using the axi_wrapper "m_axis_pkt_len_t*" inputs.
>> >>
>> >> With such a simple fix, it seems that Ettus should permanently change
>> noc_block_fft.v to incorporate this.  Another 

Re: [USRP-users] X310 unable to connect after recovery procedure

[Marcus D. Leech via USRP-users]

On 03/28/2019 07:26 AM, Nicolas GALLAND wrote:

Hi,

I used the file named usrp_x310_fpga_HG.bit

Nicolas
Could you show me an ifconfig for the interface that you're using for 
the device?






Le 27/03/2019 à 15:10, Marcus D. Leech a écrit :

On 03/27/2019 05:39 AM, Nicolas GALLAND wrote:

Hi,

after the recovery, i can't ping the device to the default address. 
It gives me a "host unreachable" error when I try.


Nicolas
Which image did you select when you used Vivado to recover the device 
via JTAG?





Le 26/03/2019 à 17:28, Marcus D Leech a écrit :

So it’s not clear where we are at here.

After recovery can you ping the device at the default address?



Sent from my iPhone

On Mar 25, 2019, at 12:12 PM, Joe Martin via USRP-users 
 wrote:


Thanks, Nicolas.  I am interested to hear how you eventually clear 
the problem as I also have an X310 and so far all works fine but 
someday I may face the same issue as you are experiencing so 
please when you find a solution please post it.  I am not 
experienced enough yet with mine to be able to suggest a solution 
for you unfortunately. Maybe someone else can.


I (like you) am eager to hear any suggestion(s) to resolve your 
issue.


Regards,

Joe

On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND 
 wrote:


Hi,

it is indeed a typo here. I did ping 192.168.10.2 first, and then 
I tried on 192.168.10.3 to see if the error message was the same. 
In any case (even using ping broadcast on all the sub network my 
computer is connected to) i have this message. It looks like 
there is a connection between the computer and the device, since 
my computer says there is no more network when I switch off the 
USRP.


Kind regards

Nicolas

Le 22/03/2019 à 18:52, Joe Martin a écrit :
Nicolas,

It appears you were pinging 192.168.10.3, not 192.168.10.2.  
Maybe this particular example was simply a typo and you used the 
correct IP address to ping during your other tests?


Regards,

Joe

On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
 wrote:


Hello everyone,

I had some trouble with my X310 and I needed to upload my UHD 
installation and consequently to update the FPGA image on the 
board. After doing it through eternet port, I lost connection 
so I decide to follow the recovery procedure to upload the FPGA 
image using the JTAG port (following 
https://kb.ettus.com/X300/X310_Device_Recovery).


The upload is fine, and the computer recognises the network 
with IP address 192.168.10.1, but when I try to ping 
192.168.10.2 (as explained in the procedure) I have


PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
 From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=5 Destination Host Unreachable

until I stop it. I have two x310 in the same situation, and I 
tried on two different computers with different ethernet cables.


Could the hardware be broken ? (If so, isn't it strange that 
the computer still sees the network ?)


Thanks a lot, and nice week end !

Kind regards,

Nicolas



___
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] X310 unable to connect after recovery procedure

[Jason Matusiak via USRP-users]

And you have a 1Gb SFP plugged into the first port in the X310 going to a 1GB 
connection on the other end?


From: USRP-users  on behalf of Nicolas 
GALLAND via USRP-users 
Sent: Thursday, March 28, 2019 7:26 AM
To: Marcus D. Leech; Joe Martin
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310 unable to connect after recovery procedure

Hi,

I used the file named usrp_x310_fpga_HG.bit

Nicolas


Le 27/03/2019 à 15:10, Marcus D. Leech a écrit :
> On 03/27/2019 05:39 AM, Nicolas GALLAND wrote:
>> Hi,
>>
>> after the recovery, i can't ping the device to the default address.
>> It gives me a "host unreachable" error when I try.
>>
>> Nicolas
> Which image did you select when you used Vivado to recover the device
> via JTAG?
>
>
>>
>> Le 26/03/2019 à 17:28, Marcus D Leech a écrit :
>>> So it’s not clear where we are at here.
>>>
>>> After recovery can you ping the device at the default address?
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
 On Mar 25, 2019, at 12:12 PM, Joe Martin via USRP-users
  wrote:

 Thanks, Nicolas.  I am interested to hear how you eventually clear
 the problem as I also have an X310 and so far all works fine but
 someday I may face the same issue as you are experiencing so please
 when you find a solution please post it.  I am not experienced
 enough yet with mine to be able to suggest a solution for you
 unfortunately.  Maybe someone else can.

 I (like you) am eager to hear any suggestion(s) to resolve your issue.

 Regards,

 Joe

> On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND
>  wrote:
>
> Hi,
>
> it is indeed a typo here. I did ping 192.168.10.2 first, and then
> I tried on 192.168.10.3 to see if the error message was the same.
> In any case (even using ping broadcast on all the sub network my
> computer is connected to) i have this message. It looks like there
> is a connection between the computer and the device, since my
> computer says there is no more network when I switch off the USRP.
>
> Kind regards
>
> Nicolas
>> Le 22/03/2019 à 18:52, Joe Martin a écrit :
>> Nicolas,
>>
>> It appears you were pinging 192.168.10.3, not 192.168.10.2.
>> Maybe this particular example was simply a typo and you used the
>> correct IP address to ping during your other tests?
>>
>> Regards,
>>
>> Joe
>>
>>> On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users
>>>  wrote:
>>>
>>> Hello everyone,
>>>
>>> I had some trouble with my X310 and I needed to upload my UHD
>>> installation and consequently to update the FPGA image on the
>>> board. After doing it through eternet port, I lost connection so
>>> I decide to follow the recovery procedure to upload the FPGA
>>> image using the JTAG port (following
>>> https://kb.ettus.com/X300/X310_Device_Recovery).
>>>
>>> The upload is fine, and the computer recognises the network with
>>> IP address 192.168.10.1, but when I try to ping 192.168.10.2 (as
>>> explained in the procedure) I have
>>>
>>> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
>>>  From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
>>>  From 192.168.10.1 icmp_seq=5 Destination Host Unreachable
>>>
>>> until I stop it. I have two x310 in the same situation, and I
>>> tried on two different computers with different ethernet cables.
>>>
>>> Could the hardware be broken ? (If so, isn't it strange that the
>>> computer still sees the network ?)
>>>
>>> Thanks a lot, and nice week end !
>>>
>>> Kind regards,
>>>
>>> Nicolas
>>>

 ___
 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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] pybombs init error --> volk

[Martin K via USRP-users]

Michael, thank you. That does help.

Do you or anyone know if there is a version of Ubuntu or Debian [or
any distro] that supports the default PyBombs installation out of the
box? I don't have time to learn pybombs and debug the build.

Thanks,
Martin Klingensmith


On Wed, Mar 27, 2019 at 2:56 PM Michael Dickens
 wrote:
>
> The version of Volk currently installed is too new for the version of GNU 
> Radio you're trying to build. I'm not 100% clear on how to install different 
> recipes in PyBOMBS, but if you can do so try a newer version of GNU Radio (if 
> you search the GIT logs for "volk_32f_8u_polarbutterfly_32f" you'll find the 
> commit to be at least a recent as). Hope this is useful! - MLD
>
> On Wed, Mar 27, 2019, at 12:36 PM, Martin K via USRP-users wrote:
> > I am installing the e3xx-rfnoc pybombs recipe for Ettus E310 development.
> > It gets as far as
> > gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o and
> > fails (error follows below). The command I am running is:
> > $ pybombs prefix init ~/e3xx -R e3xx-rfnoc
> >
> > The OS is Ubuntu 18.04LTS. The OS installation is new.
> > Thank you for any help.
> >
> > /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc: In
> > member function 'void
> > gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned
> > char*, int, int, int)':
> > /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc:126:95:
> > error: too many arguments to function
> >  volk_32f_8u_polarbutterfly_32f(llrs, u, block_size(),
> > block_power(), stage, u_num, row);
> >
> > ^
> > gr-fec/lib/CMakeFiles/gnuradio-fec.dir/build.make:1020: recipe for
> > target 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o'
> > failed
> > make[2]: *** 
> > [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o]
> > Error 1
> > CMakeFiles/Makefile2:3846: recipe for target
> > 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all' failed
> > make[1]: *** [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all] Error 2
> > Makefile:143: recipe for target 'all' failed
> > make: *** [all] Error 2
> > [ERROR] Build failed. See output above for error messages.
> > [ERROR] Problem occurred while building package gnuradio:
> > Build failed.
> > [ERROR] Error installing package gnuradio. Aborting.
> >
> >
> > --
> > Martin K.
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >



-- 
Martin K.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 unable to connect after recovery procedure

[Nicolas GALLAND via USRP-users]

Hi,

I used the file named usrp_x310_fpga_HG.bit

Nicolas


Le 27/03/2019 à 15:10, Marcus D. Leech a écrit :

On 03/27/2019 05:39 AM, Nicolas GALLAND wrote:

Hi,

after the recovery, i can't ping the device to the default address. 
It gives me a "host unreachable" error when I try.


Nicolas
Which image did you select when you used Vivado to recover the device 
via JTAG?





Le 26/03/2019 à 17:28, Marcus D Leech a écrit :

So it’s not clear where we are at here.

After recovery can you ping the device at the default address?



Sent from my iPhone

On Mar 25, 2019, at 12:12 PM, Joe Martin via USRP-users 
 wrote:


Thanks, Nicolas.  I am interested to hear how you eventually clear 
the problem as I also have an X310 and so far all works fine but 
someday I may face the same issue as you are experiencing so please 
when you find a solution please post it.  I am not experienced 
enough yet with mine to be able to suggest a solution for you 
unfortunately.  Maybe someone else can.


I (like you) am eager to hear any suggestion(s) to resolve your issue.

Regards,

Joe

On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND 
 wrote:


Hi,

it is indeed a typo here. I did ping 192.168.10.2 first, and then 
I tried on 192.168.10.3 to see if the error message was the same. 
In any case (even using ping broadcast on all the sub network my 
computer is connected to) i have this message. It looks like there 
is a connection between the computer and the device, since my 
computer says there is no more network when I switch off the USRP.


Kind regards

Nicolas

Le 22/03/2019 à 18:52, Joe Martin a écrit :
Nicolas,

It appears you were pinging 192.168.10.3, not 192.168.10.2.  
Maybe this particular example was simply a typo and you used the 
correct IP address to ping during your other tests?


Regards,

Joe

On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
 wrote:


Hello everyone,

I had some trouble with my X310 and I needed to upload my UHD 
installation and consequently to update the FPGA image on the 
board. After doing it through eternet port, I lost connection so 
I decide to follow the recovery procedure to upload the FPGA 
image using the JTAG port (following 
https://kb.ettus.com/X300/X310_Device_Recovery).


The upload is fine, and the computer recognises the network with 
IP address 192.168.10.1, but when I try to ping 192.168.10.2 (as 
explained in the procedure) I have


PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
 From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=5 Destination Host Unreachable

until I stop it. I have two x310 in the same situation, and I 
tried on two different computers with different ethernet cables.


Could the hardware be broken ? (If so, isn't it strange that the 
computer still sees the network ?)


Thanks a lot, and nice week end !

Kind regards,

    Nicolas



___
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] Standalone signal generator on B205mini

[Justo Ramos, Diego via USRP-users]

Hello Ian,

I want a continuous TX  of a generated signal, because I want to use the USB 
exclusively for RX. I don't know if I can configure by UHD this option at first 
time, without sending data all time and modifying the input TX data of the 
b205_io block with my desired signal. Is this option of configuration possible? 
I think that with that option I could accomplish the 3 tips that you wrote.

Thanks for your answer.

Regards,
Diego

De: Ian Buckley 
Enviado el: Wednesday, March 27, 2019 4:50 AM
Para: Justo Ramos, Diego 
CC: usrp-users 
Asunto: Re: [USRP-users] Standalone signal generator on B205mini

I can’t give you a specific solution Diego because there are a lot of things 
here that *could* be the issue.
However in general my tips for hacking fast custom B2xx FPGA images are:
1) Do it in such a way that UHD can not tell you changed the FPGA.
i.e All register transactions should work as expected from the perspective of 
UHD (Understand though it doesn’t “know” if the transaction did what it 
expected, only that it got an acknowledgement)
If you want to transmit then still send a sample stream to the USRP even if you 
discard it after it is acknowledged by the USRP (It can be a much lower sample 
rate than your custom logic outputs, you control radio_clk directly with 
master_clock_rate, sample rate controls the interpolation ratio down from 
radio_clk)
2) Use the driver functionality of UHD to control all the H/W. Really you don’t 
want to debug driver style code if you are in a hurry, especially the 
transceiver.
3) Don't touch the logic that interfaces immediately to the FPGA pins so as too 
preserve off-chip timing…a lot of work went into qualifying that.
-Ian

On Mar 26, 2019, at 10:07 AM, Justo Ramos, Diego via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hello all,

I have an B205mini board and I'm interested in modifying the internal TX block 
of the FPGA, to be an standalone signal generator.

I created a custom block that generates a signal, in this case a pulse 
generator, with the two components of 12 bits for I and Q. Then I connect these 
two components into  b205_io's tx_i0 y rx_i0. I use the radio_clk as clock to 
generate samples of the signal.

Finally I remake the binary files of the FPGA and I reprogram the B205mini, but 
when I use the Spectrum Analyzer I don't have any signal  on the TX frequency.

I don't know if I have to change the clock for generation of samples or 
activate another signal. Could someone give me an advice to achieve custom 
transmission from the FPGA?

Thanks you.

Best regards,
Diego



Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda 
notificado que la lectura, utilización, divulgación y/o copia sin autorización 
está prohibida en virtud de la legislación vigente. En el caso de haber 
recibido este correo electrónico por error, se ruega notificar inmediatamente 
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its recipient(s). If 
you are not the indicated recipient, you are informed that reading, using, 
disseminating and/or copying it without authorisation is forbidden in 
accordance with the legislation in effect. If you have received this email by 
mistake, please immediately notify the sender of the situation by resending it 
to their email address.
Avoid printing this message if it is not absolutely necessary.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda 
notificado que la lectura, utilización, divulgación y/o copia sin autorización 
está prohibida en virtud de la legislación vigente. En el caso de haber 
recibido este correo electrónico por error, se ruega notificar inmediatamente 
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its recipient(s). If 
you are not the indicated recipient, you are informed that reading, using, 
disseminating and/or copying it without authorisation is forbidden in 
accordance with the legislation in effect. If you have received this email by 
mistake, please 

Re: [USRP-users] RFNoC FFT size > 1024

[Jonathon Pendlum via USRP-users]

Hey Rob,

Regarding overflows or dropped packets, is this something that might
> occur inside the FPGA (CE to CE) or is it just a concern on the
> transfer to the host CPU (which is my only experience with overflows
> or dropped packets)?  If on the FPGA, what would be the cause of
> overflows / dropped packets in the following scenario:
> rx_radio->DDC->FFT->host?


Overflow generally only occurs due to the host being unable to consume
samples quickly enough. It is possible for overflows to occur due to a
RFNoC block not consuming samples quickly enough, but all in-tree blocks
are designed to avoid that situation. Drops only occur between the device
and host.

Regarding the header, is the concern the following? Assume packet size
> of 1024 and FFT size of 4096 such that there would be 4 packets for
> each FFT; Now assume that EOB occurs on the 3rd packet such that the
> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
> in a bad state.  Is this the issue?  If not, please explain.  If so,
> is the fix to reset the FFT on any incoming EOB? Without any fix, does
> this issue correct itself in some way during the subsequent stream or
> is the input frame mismatch issue going to remain until the FFT is
> manually reset?


Correct, resetting the FFT on EOB is a possible solution. If you reset on
EOB though, you'll need to figure out a way to still send that final packet
with EOB set to the host. Maybe zero fill the missing samples to complete
the FFT? The issue will also fix itself on the next burst assuming you
don't care that the first FFT might be corrupt.

Jonathon

On Sun, Mar 3, 2019 at 1:16 AM Rob Kossler  wrote:

> Thanks Jonathon,
>
> > I'm glad you found those options useful. Unfortunately, there are a
> number of corner cases that those options do not handle. You can run into
> synchronization issues when overflows and dropped packets occur. In the
> overflow case, if one occurs while the FFT is being filled then the next
> FFT output will be incorrect. In the dropped packet case, the received FFT
> frames could end up shifted between two FFT frames. The dropped packet case
> is by the far worse of the two.
>
> Regarding overflows or dropped packets, is this something that might
> occur inside the FPGA (CE to CE) or is it just a concern on the
> transfer to the host CPU (which is my only experience with overflows
> or dropped packets)?  If on the FPGA, what would be the cause of
> overflows / dropped packets in the following scenario:
> rx_radio->DDC->FFT->host?
>
> > The block also does not handle the packet header correctly when FFTs are
> split between multiple packets. For example, EOBs will not cause the FFT
> core to reset, so the next burst could have an incorrect FFT output at the
> beginning. Most of these issues can be worked around or even ignored, but I
> think for general usage the block will need to be updated to handle them
> properly.
>
> Regarding the header, is the concern the following? Assume packet size
> of 1024 and FFT size of 4096 such that there would be 4 packets for
> each FFT; Now assume that EOB occurs on the 3rd packet such that the
> FFT is 3/4 filled.  Thus, on the next start-of-stream, the FFT will be
> in a bad state.  Is this the issue?  If not, please explain.  If so,
> is the fix to reset the FFT on any incoming EOB? Without any fix, does
> this issue correct itself in some way during the subsequent stream or
> is the input frame mismatch issue going to remain until the FFT is
> manually reset?
>
> Thanks for your help.
> Rob
>
>
> > On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >>
> >> Turns out there was a surprisingly simple modification to allow FFTs
> longer than 1024.  The axi_wrapper will automatically resize packets for
> you if you configure it to do so.  All I had to do was set
> RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output
> packets to be resized to match the input packet size.  I was able to then
> run 2048 and 4096 pt FFTs successfully (& producing the expected results)
> and I could use any packet size I wanted going in and out of the overall
> noc block.
> >>
> >> I did not even have to resize the packets going into the FFT because
> the FFT doesn't care about input packet size with the caveat that it
> generates various "bad size" events if it detects mismatches.  Since I am
> not monitoring such events, it doesn't really matter. And, if I did care
> about these bad size events, the fix is simply to add
> RESIZE_INPUT_PACKET(1) and set the desired resize value (i.e., the FFT
> length) using the axi_wrapper "m_axis_pkt_len_t*" inputs.
> >>
> >> With such a simple fix, it seems that Ettus should permanently change
> noc_block_fft.v to incorporate this.  Another change would be to modify
> this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting
> of 11 in order to match the axi_fft IP core set for a max FFT of 4096.
> >>
> >> Rob

[USRP-users] Invalid or Corrupt file

[VINAYAK KARANDIKAR via USRP-users]

Hello,
   I am trying to mex the file multi_usrp.hpp located on my
computer in the folder:
   C:\Program Files\UHD\include\uhd\usrp\multi_usrp.hpp

However i get the error:

   multi_usrp.hpp : fatal error LNK1107: invalid or corrupt file:
cannot read at 0x105AE

   C:\PROGRA~1\MATLAB\R2013B\BIN\MEX.PL : Error:
Link of 'multi_usrp.mexw64'
   failed.

   Unable to complete successfully.

So, what do i do? I have a windows 10 system with SDK 7.1  c++
compiler installed.

Thanks a lot,
 Vinayak Anant Karandikar
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com