Skip to content

Development Roadmap

Jump to bottom
dave-aragon edited this page Jul 11, 2017 · 4 revisions

Work items below are not necessarily listed in priority order.

Summary

Type of work Modules Description
Design Develop Doc Calibrate (lab) RX (sensor)
X X Provide a Gnu Radio module for applying the calibration data to an RX stream.
X X Provide capability to step the amplitude calibration tool's frequency to follow a stepping signal generator.
X X Specify in full detail the intended/recommended use of file name metadata for choosing a calibration file.
X X X X Support additional radio types. At least: Nuand bladeRF, RTL-SDR.
X X X More precise specification of the file header metadata.
X X X X Accommodate radios for which the required gain correction is not a function of frequency alone.
X X X Provide a corresponding ability for calibration in frequency.
X Clarify policy re: a corresponding ability for calibration of DC offset.

Details, Notes

  • Develop SW (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.

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

    (Controlling a signal generator via GPIB, however, is _not _a goal for this project. Such a tool has already been developed by NIST/NTIA, and a better approach would be to interface their code with GNU radio -- should a volunteer be interested in such development!)

  • Doc (RX-time): Specify in full detail the intended/recommended use of file name metadata for choosing a calibration file.

  • Feature Devel (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 the outputs of different units sufficiently comparable to each other that they can be used effectively together (e.g. in arrays).
    • Policy question: if intent is to be 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 RX-time SW skips all of it)

    • Clarify policy re: back-compatibility to Ettus DC offset files.
      • I suspect that UHD doesn't even 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 does our appearance of file-level interoperability only invite mistakes?

  • Design / Develop Feature: 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.

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

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

    The issue is coexistance (maybe interoperability) with an existing, SDR-specific DC offset ability. Their layer will be unaware of ours, and we want to do the RX-time correction once, not twice.

    So if we do find an SDR-native DC offset file, should we ...

    • Read & apply it?

      • If it's found in the "right" directory for our RX-time cal files? (i.e. do we assume that the user, by putting the file there, is instructing our RX block to use it in all cases?)
      • If it's in an SDR-specific directory/file? (This sounds wrong, but don't rule it out w/o investigation. Ettus DC offset files might not be applied by UHD, and in that case maybe we want to read & apply them.)

    • Assume the SDR's library will apply its own, so we should _not _apply ours even if we have one?

      • This way we don't need to read or apply theirs or ours.
      • Requires checking for existence of SDR-specific directories & filenames.
        • If filenames are keyed to an SDR serial #, should we assume they'll work with the radio that's actually connected? 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" ?

      • Too elaborate -- software would be a hairball

Clone this wiki locally