A question for anyone: when changing the frequency of a DUC (or DDC) would you
expect the output of the block to be phase continuous through the change?
Phase-continuous behavior would be typical for many DDC implementations, but
with the RFNoc block I am seeing big, arbitrary phase jumps wi
at present we have data flowing in a loopback mode- that’s good. However, the
data flowing is the full 200MHz BW of the radio blocks, as if the DDC and DUC
rfnoc blocks were using output/input rates of 200M, i.e. no decimation, despite
being configured for various decimated output rates. Don’
Hi, yes that is helpful, thanks!
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Hi, and thanks Paul again for this post.
Would you mind forwarding your implementation for loopback (grc picture, or
yml file, or whatever)? I’d like to check connections and block parameters for
loopback.
Thanks in advance rb
___
USRP-users maili
Ettus documentation suggests the radio can be configured for a 25 MS sampling
rate (The master 200M / 8). I’m wondering if it is possible to get the RFNoc
RX \*Radio block \*to do this without the DDC block. Is that possible?
Entering anything other than 200M in the “Sample Rate (Hz)” field
Has anyone had success running RFNoc Fosphor Block connected to the RFNoc QT
Fosphor Display?
The error messages indicate a data mismatch between the two blocks, and I
cannot find a set of parameters that allow valid data connections between the
blocks?
_
OK, thanks
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I have a couple of questions about the GnuRadio QT GUI Frequency Sink Block ,
which allows you to specify FFT size and update rate.
* My understanding it that , when it is time go compute another spectrum
according to the update rate setting, the block will grab the most recent N
samples to
We would probably vote for gr-ettus support for the following, in more or less
this order of preference: Split_stream, fir, replay, keep_one_in_n.
thx rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-u
Thanks for that.
Not a lot to work with there- too bad.
thx
rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Thanks Johnathon, that is very helpful. Can you please also state the list of
blocks that currently have gr-ettus support?We would really like to know
what we should be looking for in current UHD/gnuradio builds.
___
USRP-users mailing list -- usrp
My understanding is that the currently available in-tree blocks does not match
the list in the reference that you point to. FOr instance, the “replay” block
shown in that list is not available. I’m not sure that siggen is available
either.
___
USRP-u
Mark, I concur with the “modulation” approach. In this case the waveform is
not pre-computed, so this will need to be done with an OOT RFNoc block.
thanks, rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to u
Request for a sanity check- I’m in the process of building UHD 4-
What In-tree ettus RFNoc blocks are actually currently available in UHD4? I’m
aware that it is less than the list of blocks in the Ettus “knowlege base” note
on RFnoc and UHD4, and for instance that Replay and SIGGen are not a
X310.
Doesn’t a time command only set the transmit /streaming time for a single time
event (as opposed to an infinite series)?
If so, then how would you stuff a \*very\* fast series of commands in to the
command queue?
___
USRP-users mailing list --
20 MSamp/sec. So if we, say, gate the signal on/off 10 microsec on/10 microsec
off, then we’d have 200 samples on, 200 samples off.
thx rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists
More like sending radar pulses, than OOK. And working through the host
software interface will be too slow for this.
It may indeed require a custom block.
thanks rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an
Hi and thanks. The reference was a good read, but I don’t think it quite
covers my application. It describes how to send commands to the Radio Block to
initiate transmission at a specific precise time. But I need to repeatedly
gate the transmit signal on/off very rapidly (microsec), and it
Can someone suggest a straightforward way to turn the radio block transmit
on/off at precise times? (“Off” could just mean changing transmit output level
to “0’, provided it could be done at exact times)
___
USRP-users mailing list -- usrp-users@lists
My current gnuradio/UHD install has the xml files for a number of RFNoc blocks
in /usr/share/gnuradio/grc/blocks; e.g. uhd_rfnoc_radio.xml.
But I do not have such a file for the rfnoc replay block, even though I do have
the rfnoc replay function in my firmware .bit load. Does such a block exis
Sorry I see that the HA just indicates the image built for 1G. We intend to
use 10G (XA), but I doubt that this has any effect on the patch.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lis
Hi, That is very helpful and I appreciate it.
My only question: what is the “HA” image? Is this not a “standard” image
build? and if so do you need that for the patch to work.?
thanks! rb
___
USRP-users mailing list -- usrp-users@lists.ettus.com
T
Hi Johnathon,
I am also trying to get loopback working on the X310. Several questions:
* Did Maris’s issues get resolved? With her last post she was still having
problems after the patch install
* Which UHD versions is your patch compatible with?
* The software load comes with an “example pro
23 matches
Mail list logo
