| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the default MTU forwarding policy is ONE_TO_ONE, therefore,
it is only strictly necessary to modify the MTU forwarding policy for
blocks that route data in a different manner. However, it may be nice to
explicitly state the forwarding policy for the benefit of the reader.
The following blocks had their policies updated:
- addsub: ONE_TO_FAN
- duc: ONE_TO_ONE
- dmafifo: ONE_TO_ONE
- null block: DROP
- replay block: DROP
- split stream: ONE_TO_FAN
- switchboard: ONE_TO_FAN
|
| |
|
|
|
|
|
|
|
|
| |
The host code was calculating and programming a 32-bit value for the DSP
frequency, but the DDS modules in the FPGA only use the upper 24-bits.
This led to inaccurate frequency values being returned. This change
corrects the resolution of the value on the host side so an accurate
value is returned.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
| |
As Github user johnwstanford points out, the DUC calls the argument
'input_rate', which is wrong (and was copy/pasted from the DDC code). By
calling it dds_rate in both cases, we avoid such confusion.
This commit only renames a variable. No changes whatsoever.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tuning range of the DUC depends on the output sample rate (which is
larger), but it was using the input sample rate. This was causing a bug
where for Tx, the DSP tuning range was limited when using multi_usrp API,
and thus would not allow to DSP-tune beyond the current sampling rate.
In this patch, we also re-use the existing calculation of the sampling
rate, and harmonize that code between duc_block_control and
ddc_block_control.
Consider the following Python REPL code:
>>> import uhd
>>> U = uhd.usrp.MultiUSRP('type=x300')
>>> U.set_rx_rate(10e6)
>>> U.set_tx_rate(10e6)
>>> # Creating a streaming is required, or the input rate will not be
>>> # set:
>>> S = U.get_tx_stream(uhd.usrp.StreamArgs("fc32", "sc16"))
>>> treq = uhd.types.TuneRequest(1e9)
>>> treq.rf_freq = 1e9
>>> treq.dsp_freq = 50e6
>>> treq.dsp_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> treq.rf_freq_policy = uhd.types.TuneRequestPolicy.manual
>>> tres = U.set_rx_freq(treq, 0)
>>> print(str(tres))
Tune Result:
Target RF Freq: 1000.000000 (MHz)
Actual RF Freq: 1000.000000 (MHz)
Target DSP Freq: 50.000000 (MHz)
Actual DSP Freq: 5.000000 (MHz)
>>> # Note the last two lines: The *target* DSP freq was already clipped
>>> # to 5 MHz. These lines show 50.0 MHz when this patch is applied.
This bugfix is accompanied some related changes:
- The unit test is amended to verify the behaviour
- The API documentation is amended with details on its behaviour
|
| |
|
|
|
|
|
| |
Its behaviour is almost identical to std::lround, which we use instead.
The only downside of std::lround is that it always returns a long, which
we don't always need. We thus add some casts for those cases to make the
compiler happy.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The checks from the new clang-tidy file are applied to the source tree
using:
$ find . -name "*.cpp" | sort -u | xargs \
--max-procs 8 --max-args 1 clang-tidy --format-style=file \
--fix -p /path/to/compile_commands.json
|
| |
|
|
|
|
|
| |
Fixes incorrect value for the DDS_GAIN that was causing the TX output
power to be 6 dB lower than it was supposed to be.
Signed-off-by: michael-west <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
| |
Sets time increment based on tick rate and sample rate instead of
assuming one tick per sample. Defaults to legacy behavior.
Minor compat number bumped on DUC and DDC blocks.
Signed-off-by: Michael West <michael.west@ettus.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds (and calls) methods to manually pass radio block sample rate
to the input/output properties of the ddc/duc during creation of the
multi_usrp_rfnoc object. The ddc/duc require this information in order
to return valid, possible output/input sample rates in
get_rx_rates()/get_tx_rates().
Before, the ddc/duc wouldn't have this rate until the rfnoc_graph had
been connected and committed, which happens in
get_rx_stream()/get_tx_stream(). Thus, this fixes an issue where a user
was unable to query possible sample rates prior to specifying a sample
rate and creating a stream.
|
| | |
|
| |
|
|
|
|
|
|
| |
Allows RFNoC blocks to perform register peeks and pokes on blocks with
multiple channels without having to worry about handling register address
translation every time.
Signed-off-by: mattprost <matt.prost@ni.com>
|
| |
|
|
|
|
| |
Only update DDC/DUC samp_rate properties if the number is substantially
different (don't update for sub-1Hz property calculations). This fixes
resolver exceptions for certain rates.
|
| |
|
