| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
Co-authored-by: Michael Auchter <michael.auchter@ni.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Paul Butler <paul.butler@ni.com>
Co-authored-by: Cristina Fuentes <cristina.fuentes-curiel@ni.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Co-authored-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Lane Kolbly <lane.kolbly@ni.com>
Co-authored-by: Max Köhler <max.koehler@ni.com>
Co-authored-by: Andrew Lynch <andrew.lynch@ni.com>
Co-authored-by: Grant Meyerhoff <grant.meyerhoff@ni.com>
Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com>
Co-authored-by: Thomas Vogel <thomas.vogel@ni.com>
|
|
|
|
|
|
|
| |
UHD's version of CMakeRC.cmake was patched from the upstream (see also
933eca1) to enable -fPIC for the RC targets. This can also be done
outside of said file, avoiding us having to carry a patched version of
CMakeRC, and using the vanilla upstream version instead.
|
|
|
|
|
|
| |
This class contains methods to store and retrieve data from the local
calibration database. Note that in this case, the "database" is just a
bunch of files on the local filesystem.
|
|
This module allows to add binary files into UHD (e.g., for cal data
storage) in a platform-independent way.
The upstream CMakeRC.cmake is modified in the following way to allow
linkage against a shared object:
```diff
# Generate the actual static library. Each source file is just a single file
# with a character array compiled in containing the contents of the
# corresponding resource file.
add_library(${name} STATIC ${libcpp})
set_property(TARGET ${name} PROPERTY CMRC_LIBDIR "${libdir}")
set_property(TARGET ${name} PROPERTY CMRC_NAMESPACE "${ARG_NAMESPACE}")
target_link_libraries(${name} PUBLIC cmrc::base)
set_property(TARGET ${name} PROPERTY CMRC_IS_RESOURCE_LIBRARY TRUE)
+ set_property(TARGET ${name} PROPERTY POSITION_INDEPENDENT_CODE ON)
```
This forces the -fPIC flag for the static object that CMakeRC generates,
allowing to link it into a shared object file.
The version of CMakeRC used is: a7e355290, cloned from
git@github.com:vector-of-bool/cmrc.git.
|