Re: [USRP-users] E310 v3.15.0.0 pre-release rfnoc fpga images build but modules not recognized

[d.des via USRP-users]

It turns out that I was building the same image over and over again. 

uhd_image_builder.py doesn't work out of the box for the e310 because
of the directory name change at top from e300 to e31x. I'd modified a
line:

   build_dir = {
:
 #'e310':'e300',
'e310':'e31x',
:

This caused

uhd_image_builder.py window fft -d e310 -t E310_RFNOC -m 5

to generate a new rfnoc_ce_auto_inst_e310.v with every invocation but
then proceed to call the same old rfnoc_ce_auto_inst_e31x.v. that was
left over from some previous run.

I made link from the file that python generates to the one that the
Vivado build script wants and now images made from noc_block_*.v build
and enumerate to show correct modules.





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

[USRP-users] CLUES : B205 Half-Duplex problem

[Tom McDermott via USRP-users]

Finally identified the B205 Half-Duplex problem I think.  No packets
involved
here - everything is streaming. No Tags, no Messages.

My hypothesis is that when the B205 transmitter starts (the 2nd and later
times)
it tries to fill up something like a TX FIFO, sucking samples out of the
flowgraph
way faster than they can be provided. This causes the TX to underrun going
back
to receive. Then it catches back up and switches to transmit, bouncing back
and forth.

The first time the TX starts (on flowgraph startup) it seems to pace the TX
correctly.
After switching to RX then back to TX (by stopping TX samples the
restarting) is when
the problem occurs.

A number of different approaches seem to yield the same behavior:

1) I used an Audio Source block (microphone) to feed a multiplier
(frequency shifter)
that feeds the TX. If I remove that and replace it with a signal source
block sinewave
(something that does not involve real time) then the TX can suck samples as
fast as
it wants, and everything T/R switches correctly.

2) The original flowgraph used a Signal Source Block as a L.O. feeding two
multipliers:
one in the RX chain, and one in the TX chain.   The receiver is feeding
samples
to it's multiplier at a constant rate, which limits how fast the buffer on
the L.O. has
samples pulled. That same L.O. is also feeding a multiplier in the transmit
chain,
which drains all the buffers in the TX path up to that point.

I created two gnuradio Signal Source blocks, with identical input
parameters but
instantiated as two separate blocks in the flowgraph.  One feeds the
receiver
multiplier, one feeds the transmit multiplier - this avoids any common path
that could slow down samples to the TX. As long as the TX side has no
real-time
sources then it T/R switches correctly.  Using the Audio Source block in
the TX chain
causes the problem to resurface.

This seems to confirm the hypothesis.

My opinion is that this is probably a BUG in the B205 FPGA code.  It should
attempt
to pull samples at a rate close to the sample rate of the transmitter when
restarting.

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