Attention is currently required from: Hoernchen, laforge, pespin.

View Change

15 comments:

• File Transceiver52M/device/usdr/USDRDevice.h:

  • Patch Set #3, Line 54: int txsps; ///< samples count per GSM symbol for Tx

    unsigned? […]

    Replaced with `tx_sps` and `rx_sps` from `RadioDevice`

  • Patch Set #3, Line 60: int timeTxCorr = 0; ///< time correction for TX timestamp, in samples, to align it with RX timestamp, which is needed to achieve correct timing of the transmitted signal. This is a device-specific parameter that can be configured via dev_args and defaults to 0 if not specified.

    Change all these comments using /* */ and properly split into acceptable width (<=120 chars).

    Done

  • Patch Set #3, Line 63: TIMESTAMP ts_last_recv = 0;

    wrong indentation

    Fixed indentation throughout the file

  • Patch Set #3, Line 90: Read samples from the USDR.

    syntax for comment (at least indentation) is different here and in next block. […]

    Fixed comments throughout the file

  • Patch Set #3, Line 100: TIMESTAMP timestamp = 0xffffffff, bool *underrun = NULL);

    wrong indentation here and below.

    Fixed indentation throughout the file

  • Patch Set #3, Line 121:

    Pleasr get rid of trailing whitespace.

    Fixed whitespaces throughout the file

  • Patch Set #3, Line 132: TIMESTAMP initialReadTimestamp(void) { return ts_initial;}

    Please, fix indentation in the whole file.

    Fixed indentation throughout the file

• File Transceiver52M/device/usdr/USDRDevice.cpp:

  • Patch Set #3, Line 49: {"limemini", {tx_offset: 86.769us}}, /* 94 samples at 1083333.33333 sps corresponds to 86.769 us */

    are you sure this is correct? isn't it xsdr? maybe add an extra commit explaining?

    Thanks, good catch — I indeed lost xSDR in that section.

    Regarding LimeSDR Mini: this was not a typo. The hardware is supported in principle, but I have temporarily removed it from the list.

    The current implementation does not correctly handle readSamples() / writeSamples() for LimeSDR Mini, as it requires inserting/handling transport headers every 1020 samples, which is not yet implemented properly in this backend.

  • Patch Set #3, Line 52: enum {

    I don't see why this should be an enum. […]

    Replaced the enum with #define constants as suggested

  • Patch Set #3, Line 85: std::string msg = std::string("Error creating USDR device with connection string '") + connection_string + "' res: " + std::to_string(res) + "(" + strerror(res) + ")";

    Fix all lines too long like this. Maximum is 120 chars.

    Reformatted the file to ensure all lines are within the 120-character limit

  • Patch Set #3, Line 180: dev = NULL;

    Please fix indentation in the whole file. Better use tabs everywhere.

    Fixed indentation throughout the file

• File debian/osmo-trx-usdr.postinst:

  • Patch Set #3, Line 18: # Fix permissions of previous (root-owned) install (OS#4107)

    This is AFAICT not needed here, because there's no previous root-owned install ;)

    Removed the unnecessary legacy permission-fix block.

• File doc/manuals/chapters/trx-backends.adoc:

  • Patch Set #3, Line 85: The backend supports single-channel SDR hardware and is designed for setups

    But in the other . […]

    Yes, xSDR and sSDR hardware support multiple RF channels sharing a common LO. These channels are intended for MIMO operation and do not represent independent GSM TRX instances. So the current osmo-trx-usdr implementation operates in single-channel mode only.

  • Patch Set #3, Line 86: where multiple small SDRs are combined to present one or more TRX instances

    You mean using multiple SDR devices controlled by one osmo-trx-usdr process? […]

    Currently, one osmo-trx-usdr process handles one SDR device.
    Multi-TRX deployments are achieved by running multiple osmo-trx-usdr instances, typically one per device.
    In synchronized systems such as xMass (4 × xSDR with shared clock and sync),
    hardware-level clock and synchronization distribution ensures timing alignment
    between devices. While `osmo-trx-usdr` can theoretically operate with multiple
    externally synchronized devices, the Osmocom OsmoTRX architecture operates with one TRX per `osmo-trx` process.

• File doc/manuals/chapters/trx-devices.adoc:

  • Patch Set #3, Line 102: scale the number of TRX instances.

    I'd welcome some extra documentation here regarding how "multi-unit setups to […]

    Good point, thanks.

    By "multi-unit setups" I mean deployments where multiple independent SDR devices
    (e.g. several uSDR units) are used, each controlled by its own `osmo-trx-usdr`
    process instance, thereby providing one TRX per device.

    If synchronization between devices is required, it must be provided externally
    via shared clock and sync distribution (e.g. 1PPS and reference clock, as in
    xMass setups).

    I will extend this section to clarify the deployment model and add a reference
    to the relevant USDR documentation.

To view, visit change 42198. To unsubscribe, or for help writing mail filters, visit settings.