aboutsummaryrefslogtreecommitdiffstats
path: root/host/lib/usrp
Commit message (Collapse)AuthorAgeFilesLines
* usrp2: Remove unused code segmentsMartin Braun2022-07-201-6/+0
| | | | This fixes compiler warnings under Clang12.
* x300: Fix invalid GPIO source bank error messageAaron Rossetto2022-07-201-2/+2
| | | | | | | | | | | | | | | When calling `get_gpio_srcs()` or `get_gpio_src()` with an invalid bank parameter, the error text associated with the `uhd::runtime_error` that is thrown prints the expected bank, not the erroneous bank, e.g.: >>> my_x310.get_gpio_srcs('BAD_BANK', 0) [ERROR] [X300::MB_CTRL] Invalid GPIO source bank: BAD_BANK. Only supported bank is FP0 Traceback (most recent call last): File "<stdin>", line 2, in <module> RuntimeError: RuntimeError: Invalid GPIO source bank: FP0 The invalid source bank on the last line should read BAD_BANK, not FP0.
* uhd: fix minor typo when querying tx sensors property treeDavid Raeman2022-07-201-1/+1
|
* zbx: Remove stray includeMartin Braun2022-06-101-1/+0
|
* x300: Change order of GPIO banksMartin Braun2022-06-101-1/+1
| | | | | FP0 is now listed first. This helps with determining a default GPIO bank.
* n320: Fix reading DB serial in applying correctionsMartin Braun2022-06-101-2/+2
| | | | | | The frontend corrections for N320 (IQ imbalance, DC offset) require the DB serial. However, there was an error in reading the DB serial in the code that applies the corrections.
* n320: Improve comments regarding low bandMartin Braun2022-06-102-4/+6
| | | | | The N320 code include some constants that were either unused or incorrect. This clarifies the lowband frequency.
* uhd: change default into option flag in register definitionLars Amsel2022-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for read only registers in generated interfaces. For this the default is extended to an option string. The old format is still supported for backward compability, so if options string is just a number it will be handled as a writable number. The option string is a comma separated list with key=value pairs. The value is optional and treated as None if missing. common.py now allows to pass in **kwargs to the generate method which is used by gen_zbx_cpld_regs.py to pass a filter function for registers used by mpm only. get_all_addr now has an additional (optional, defaults to false) flag to indicate whether read only addresses are to be returned or not. It also supports type generic for the result to align with get_changed_addr function. The ZBX CPLD CTRL map is adapted accordingly to reflect read only registers. The power registers are flagged as MPM scope only (and not used in ZBX CPLD control of UHD). Co-authored-by: Martin Braun <martin.braun@ettus.com>
* n310: Improve LO source control options for ALL and LO2 casesmattprost2022-06-101-19/+40
| | | | | | | | If ALL option is specified, set lo source for both lo's. Do not report an error if user sets LO2 to internal. Enforce single lo target for queries about lo state. Signed-off-by: mattprost <matt.prost@ni.com>
* multi_usrp_rfnoc: Set assignment instead of equalitySteven Koo2022-04-121-1/+1
| | | | | | | This resolves a typo intoduced by multi_usrp_rfnoc: Add TX buffering using Replay Signed-off-by: Steven Koo <steven.koo@ni.com>
* uhd: Update MPM compat minorAaron Rossetto2022-04-121-1/+1
|
* n310: Add Filter API to n310mattprost2022-04-077-18/+202
| | | | | | | | | | Add the Filter API to n3xx specifically for the AD937x device. The TX filter is limited to 32 taps, and the RX filter is limited to 48 taps. This feature requires MPM version 4.2 or later on the device. Co-authored-by: bpadalino <bpadalino@gmail.com> Signed-off-by: mattprost <matt.prost@ni.com>
* n310: Add frontend bandwidth controlmattprost2022-04-073-25/+107
| | | | | | | | | | | | Allow users to control the Mykonos frontend bandwidth settings for Rx and Tx. Note that this operation requires the daughterboard to re-initialize, so it may take some time. Values for frontend filter settings were derived using ADI's AD9371 Filter Wizard. This feature requires MPM version 4.1 or later on the device. Co-authored-by: bpadalino <bpadalino@gmail.com> Signed-off-by: mattprost <matt.prost@ni.com>
* n310: cpld: Get and set TX ATR bitsmattprost2022-04-072-0/+66
| | | | | | | | | This allows the user to get the current state of the tx atr bits and set them back to a given state. This is useful for the n310 when resetting the front end, in order to avoid any tx power out of the frontend when the init_cals are run. Signed-off-by: mattprost <matt.prost@ni.com>
* multi_usrp_rfnoc: Add TX buffering using Replaymichael-west2022-04-071-86/+206
| | | | | | | | | | | Enabled with the "tx_replay_buffer" device argument. Buffers TX data in DRAM using the Replay block (version 1.1 or higher required), allowing more buffering of data on the device. May reduce underruns for certain applications. The Replay block is currently limited to 32 play commands, so fewer calls to send() with larger buffers will perform better than more calls with smaller buffers. Signed-off-by: michael-west <michael.west@ettus.com>
* host: SPI: Read number of supported SPI slaves from deviceMartin Anderseck2022-04-043-19/+43
| | | | | | Add support for reading the number of supported SPI slaves from the device. This has become necessary because we may have bitfiles with different capabilities and we want to report this back correctly.
* n320: fix issue that occasionally prevents lo_locked upon first set_freqDavid Raeman2022-04-011-6/+43
| | | | | | | | | | | | For certain frequencies, the LMX2592 will sporadically fail to lock upon the very first tune. When this happens, subsequent tunes (even to the same frequency) do lock. This issue seems to be resolved by programming the FCAL adjustment register fields (FCAL_LPFD_ADJ/FCAL_HPFD_ADJ) as described in the LMX2592 datasheet. These fields adjust the FCAL calibration speed to better accomodate PFD frequencies below 20MHz or above 100MHz. This patch also fixes a few name typos in the register map that were directly in the scope of this change.
* host: x410: Emulate GPIO classic ATR mode using new modeLane Kolbly2022-03-233-13/+83
| | | | | | This fixes an issue with setting the active channel source in MPM, and additionally allows opening up the more flexible API in the future without requiring a filesystem update.
* host: x410: Cache GPIO source in mb_controllerLane Kolbly2022-03-231-1/+6
|
* Fix handling of discontinuities in power calibration dataLars Amsel2022-03-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The power that corresponds to a certain gain values depends on the frequency band we are in. At the edges of these bands discontinuities can occur (the gain necessary to achieve the same power value changes non-continuously). The power calibration does a linear interpolation between two neighbor points in the calibration data set to find at best fitting value. We therefore have to make sure that this interpolation does not cross discontinuities. This is a minimal invasive approach. It adds values at discontinuities for the lower and the upper band. The power calibration format uses the frequency for a power to gain mapping as a map key. Therefore two gain to power mappings cannot be stored for the same frequency as it would be needed for the discontinuity. Instead the mapping for the lower band is stored at the discontinuity frequency itself. The mapping for the upper band is stored at the frequency + 1Hz. The calibration will therefore still fail to yield proper results within this sub-Hertz range. The frequency lookup in the power calibration manager now uses round instead of truncation to find the best mapping frequency in the calibration table. With this, searching for neighbor data points now ensures that the data points used belong to the same band (except for the range of (f_discontinuity, f_discontinuity + 1Hz) ). This commit does not solve the issue for calibration data generated with usrp_power_cal.py because the Python interface has no means to detect band edges for the USRP it is calibrating.
* N310: Deactivate frontend components on radio shutdownmattprost2022-03-033-0/+35
| | | | | | | | Make sure no active components are connected to the TX frontend during next boot. This avoids configurations that could generate unwanted tones during operations such as the Mykonos init cals. Signed-off-by: mattprost <matt.prost@ni.com>
* uhd: fix negligible copy/paste typos in rhodium radio controlDavid Raeman2022-02-282-4/+4
|
* Remove FSRU-related filesMartin Braun2022-02-221-3/+0
| | | | | | | The FSRU (aka EISCAT) was never supported in UHD 4.0. The FPGA repository never had the relevant files, and the block controller also never existed. This removes all the corresponding files from MPM, as well as some references from makefiles.
* uhd: Harmonize fuzzy frequency comparisonsMartin Braun2022-02-047-43/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Throughout UHD, we often do floating-point comparisons for frequency ranges that require resilience to floating point rounding errors. Most of the time the checks look like this: ```cpp if (fp_compare_epsilon<double>(freq) > boundary) { // ... } ``` The exception is the N320 daughterboard control, which uses a custom epsilon: ```cpp if (fp_compare_epsilon<double>(freq, RHODIUM_FREQ_COMPARE_EPSILON) > boundary) { // ... } ``` This was, for the most part, not by design, but because authors simply didn't think about which epsilon value was appropriate for the frequency comparison. This was complicated by the fact that fp_compare_epsilon previously had some issues. This patch introduces FREQ_COMPARE_EPSILON, which is a sensible default value for fp_compare_epsilon when doing frequency comparisons (note that fp_compare_delta already had such a value). Also, it introduces freq_compare_epsilon(x), which is a shorthand for fp_compare_epsilon<double>(x, FREQ_COMPARE_EPSILON). We then replace all occurrences of fp_compare_epsilon<double> which are specific to frequency checks with freq_compare_epsilon.
* host: x4xx: Fix some warnings on mac OSLane Kolbly2022-02-042-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the following warnings: ``` /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2335:5: warning: \ delete called on non-final 'uhd::rfnoc::x400::x400_gpio_port_mapping' that has \ virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor] delete __ptr; ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2648:7: note: in \ instantiation of member function 'std::__1::default_delete<uhd::rfnoc::x400::x4\ 00_gpio_port_mapping>::operator()' requested here __ptr_.second()(__tmp); ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:2602:19: note: in\ instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\ pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\ ping> >::reset' requested here ~unique_ptr() { reset(); } ^ /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:4063:21: note: in\ instantiation of member function 'std::__1::unique_ptr<uhd::rfnoc::x400::x400_g\ pio_port_mapping, std::__1::default_delete<uhd::rfnoc::x400::x400_gpio_port_map\ ping> >::~unique_ptr' requested here unique_ptr<_Yp> __hold(__p); ^ /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_radio_control.cpp:1\ 92:33: note: in instantiation of function template specialization 'std::__1::sh\ ared_ptr<uhd::mapper::gpio_port_mapper>::shared_ptr<uhd::rfnoc::x400::x400_gpio\ _port_mapping>' requested here auto gpio_port_mapper = std::shared_ptr<uhd::mapper::gpio_port_mapper>( ``` and: ``` /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\ 4:75: warning: adding 'const uint32_t' (aka 'const unsigned int') to a string d\ oes not append to the string [-Wstring-plus-int] "Could not find corresponding GPIO pin number for given SPI pin " + value); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ /Users/rfmibuild/myagent/_work/76/s/host/lib/usrp/x400/x400_gpio_control.cpp:15\ 4:75: note: use array indexing to silence this warning "Could not find corresponding GPIO pin number for given SPI pin " + value); ^ & [ ] ```
* host: zbx: Expose tuning table on property treeLane Kolbly2022-02-032-5/+18
| | | | | This allows viewing or, conceivably, customizing the tuning table that ZBX uses, depending on the particular needs of the end user.
* rfnoc: Fix _set_subdev_spec() helper functionAaron Rossetto2022-02-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | In 716ed77, refactoring was performed to merge `set_tx_subdev_spec()` and `set_rx_subdev_spec()` via the use of a shared helper function, `_set_subdev_spec()`, which factors out differences in the two directions by accepting lambda functions from the caller. However, there were two bugs introduced in the refactoring: - The channel map parameter, which is either `_rx_chans` or `_tx_chans` based on direction, was passed by value and not reference, so changes made by the function were not persisted in the member variables maintained in the `multi_usrp_rfnoc` class. - The connection removal loop checks for the presence of an SEP block on an edge as its termination condition. In the pre-refactored code, the direction determined whether the source or destination of the edge was checked for the SEP. However, in the refactoring, the source of the edge is checked for both TX and RX. While this works for the `set_tx_subdev_spec()` call, it breaks the `set_rx_subdev_spec()` call. This commit fixes the issue by adding another lambda parameter to the `set_subdev_spec()` function, which puts the onus of the edge check on the direction-specific code to ensure it is looking at the correct side of the edge.
* host: x4xx: gpio: Properly unmap FPGA GPIO valuesLane Kolbly2022-01-242-39/+44
| | | | | | The FPGA GPIO registers don't exactly match the pin numbering on the front panel and in the docs. This commit changes the algorithm so that the API presented to the user matches the front panel.
* host: Implement nameless_gain_mixinLane Kolbly2022-01-202-67/+25
|
* tests: disable x4xx_radio_block_test on macOSSteven Koo2022-01-191-0/+1
| | | | | | | | This commit disables x4xx_radio_block_test on macOS because the platform has stricter casting and symbol export rules, which causes this test to fail. Signed-off-by: Steven Koo <steven.koo@ni.com>
* SPI: Implement SPI engine for x410Martin Anderseck2022-01-136-15/+294
| | | | | Add SPI Core host implementation for x410 and a discoverable feature to make it accessible.
* uhd: Fix non-standard function name macrosMartin Braun2022-01-122-3/+3
| | | | | | | | | | | | | | | | | Throughout UHD, we are using a random mix of __FUNCTION__, __func__, __PRETTY_FUNCTION__, and BOOST_CURRENT_FUNCTION. Note that the first two macros are non-standard (although many compilers understand them), and the last requires Boost. __func__ is available since C++11, but is not the best choice because the C++ standard doesn't require it to be of any specific value. We thus define UHD_FUNCTION and UHD_PRETTY_FUNCTION as portable macros. The former simply contains the undecorated function name, the latter the expanded function with full signature. As it happens, our currently supported compilers didn't have any issues using non-standard macros, so the main fix here is the removal of the Boost macros and the harmonization of the other macros.
* x300: Fix LED configuration for TwinRXMartin Braun2022-01-111-13/+53
| | | | | | | | | | | | | | The problem was that TwinRX has a special LED configuration (unlike most other daughterboards): Since it has two channels, it is possible to stream RX from both SMA ports. In that case, we would light up both LEDs in green (which was not happening, only one LED would light up, depending on which antenna was set last). This fixes the problem and turns on both LEDs when both channels are used, and both SMA ports are selected. Note that the reason for this issue was an incorrect porting of this code from UHD 3. There, we had separate LED ATR objects per channel.
* x300: clang-formatMartin Braun2022-01-1110-61/+65
|
* e3xx: Fix frequency queryingMartin Braun2022-01-101-2/+11
| | | | | | | The E3xx devices have one LO per TX/RX, respectively. That means when changing the frequency on channel 0, the frequency on channel 1 also gets changed. The code didn't track this change properly: When setting channel 1, channel 0's frequency didn't match.
* RFNoC: Fix DSP frequency accuracymichael-west2022-01-101-4/+5
| | | | | | | | | | 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>
* host: multi_usrp: Merge set_tx_subdev_spec and set_rx_subdev_specLane Kolbly2022-01-101-99/+67
| | | | | This change simply refactors these methods so that the core of the algorithm is no longer duplicated between them.
* host: rf_control: Add internal antenna API abstraction.Lane Kolbly2022-01-051-35/+11
|
* lib: Remove superfluous includes of udp_zero_copy.hppMartin Braun2022-01-052-2/+0
|
* e3xx: Remove unused constantMartin Braun2021-12-091-2/+0
|
* mpmd: Add MTU plausibility checkMartin Braun2021-12-021-0/+42
| | | | | | | | | | | | | | | | | | We have noticed that on 1 GbE connections, MTU discovery can become unreliable. Since we now use the MTU directly for deriving spp and other values, a correct MTU is important. Because we don't have a way of knowing if MTU discovery worked or not, we add some heuristics in form of a plausibility check. For now, the only rule in this check is if that the detected MTU is a bit larger than 1472 bytes, we coerce down to 1472, because this is such a standard value (most 1 GbE interfaces default to an IPv4 MTU of 1500 bytes). For the cases where the interface MTU is set to be between 1500 and 1528 bytes, this would cause a very minor performance loss. We accept this performance loss as it is small, and those cases are very rare. MTUs are usually 1500 bytes, or >= 8000 bytes for high-speed links using jumbo frames.
* x300: Remove usage of CHDR_MAX_LEN_HDRMartin Braun2021-12-021-2/+6
| | | | | | | This constant was generally harmful, since it was only correct under certain circumstances (64 bit CHDR with timestamps). The X3x0 code was the last place it was being used, and we remove it without substitute because it was not doing anything useful here.
* multi_usrp_rfnoc: Reduce latency of get_time_now()michael-west2021-11-171-9/+9
| | | | | | | Getting the time from the mb_controller is slow, so try to get the time from the Radio on the fast path first. Signed-off-by: michael-west <michael.west@ettus.com>
* B200: Re-sync timesmichael-west2021-11-102-10/+31
| | | | | | | | | | The times on the device can glitch if either the tick rate changes or the number of active chains changes. This throws off the time if the user gets streamers, changes the sample rate, or changes the tick rate after synchronizing the time. This change re-synchronizes the times automatically in those cases. Signed-off-by: michael-west <michael.west@ettus.com>
* python: multi_usrp: Add set_rx_spp()Wade Fife2021-11-091-0/+1
|
* mpmd: Increase UHD-side MTU cap for 10 GbE and 1 GbEMartin Braun2021-11-081-4/+14
| | | | | | | | | This gets closer to what our hardware can actually support. See the comments for further explanations. This has the side-effect of patching an issue on X410 (using 200 MHz images) where garbage samples would get injected (one per packet). It is not, however, the final fix for that problem.
* host: Add gpio_voltage discoverable featureLane Kolbly2021-11-051-0/+41
|
* host: python: Return mb_controller with reference_internalLane Kolbly2021-11-041-1/+1
|
* fixup! host: x4xx: Implement GPIO APILane Kolbly2021-11-031-2/+14
|
* host: x4xx: Implement GPIO APILane Kolbly2021-11-035-0/+255
| | | | | | | | | | | | This implements the GPIO API for X410 through get_gpio_attr and set_gpio_attr. In ATR mode, which channel's ATR state is chosen by the set_gpio_src call, setting e.g. DB0_RF0 for channel 0 or DB0_RF1 for channel 1. In manual mode, all 24 bits (for both ports) are set in a single register write. Although the front panel of the device has two ports, labelled GPIO0 and GPIO1, this API exposes them as though they were a single 24-bit GPIO port.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 19:52:15 +0000