Development Roadmap

Documentation to be added/changed

Software features

sdr-calibrator / ROADMAP.md

Receiver Gain Calibration for SDR-based Spectrum Sensors
Dave Aragon
March 14, 2017

Development Roadmap

• Devel (RX-time): Provide a Gnu Radio module for applying the calibration data to an RX stream.

  • Ought to be integrated w/ existing UHD and OsmoSDR source blocks. TBD whether that's better done by modifying them or by wrapping them.
  • Clarify policy re: data file search path.

• Feature (calibration-time): Provide the capability to step the amplitude calibration tool's frequency to follow a stepping signal generator.

  (Controlling a signal generator via GPI be, however, is not a goal for this project. Such a tool is already provided and has already been developed by NIST/NTIA, and a better approach would be to interface that code with GNU radio, should a volunteer be interested in that development.)

• Doc: Specify in full detail how the receive-time software can/should use the file name metadata for choosing a receive calibration file.

• Feature (calibration & RX time): Accommodate (and validate with) additional radio types. At least: Nuand bladeRF, RTL- SDR.

  • bladeRF has some self-calibration tools – how to interoperate with those?

  • RTL-SDR positioning: we know it will never be a precision instrument! Intent is to make outputs of different units sufficiently comparable to each other that they can be used effectively together (e.g. in arrays).

  • If intent is to provide a layer that's independent of radio type, then does this project really belong under OsmoSDR?

• Doc: Publish a more precise specification of the file header metadata (even though the current readers skip all of it).

  • Clarify policy re: back-compatibility to Ettus DC offset files.
  • I suspect that UHD doesn't apply those DC corrections to an RX stream! If we provide a DC correction capability analogous to this existing amplitude-correction capability, then are the Ettus numbers the right ones to use? If they aren't the right data for our DC correction to use, then by reading the Ettus files would we only invite error?

• Design enhancement: accommodate radios for which the required gain correction is not a function of frequency alone.

  For example, USRP/UBX, there is a slight interaction between the frequency and the front and analog gain, whereby the highest gain cannot quite be attained at the highest frequency. As another example, the Nuand bladeRF has two front and receive gain controls, and we have not determined how they may interact with each other and/or with the frequency.

• _Devel (calib. & RX): _ Provide a corresponding ability for calibration in frequency.

• Doc & Design: Clarify policy re: a corresponding ability for calibration of DC offset.

  The isssue is interoperability with an existing, SDR-specific capability.

  • Problem: Might do RX stream correction twice, by different layers unaware of each other (ours + (UHD or Nuand)). If we find a DC offset file, should we
    • Read & apply it?
    • If it's found in the right directory? (i.e. do we assume that by putting the file there, the user is instructing our RX block to use it in all cases?)
      • If it's in an SDR-specific directory/file? (Sounds wrong, but don't rule it out w/o investigation. Ettus DC offset files might not be applied to an RX stream by UHD.)
    • Assume the SDR's library will apply its own, so we shouldn't apply ours even if we have one?
      • Then we don't have to read & apply the vendor's files, nor ours.
      • Requires checking for existence of SDR-specific directories & filenames.
      • If files are keyed to an SDR serial #, should we assume they'll work with the connected radio? Or do we need to check the radio/dboard serial numbers? (ugh)
    • Snoop the SDR's library for clues at SDR-init time, and apply our corrections only if the SDR "seems not to have already done it" ?