Nuand / gr-bladeRF

GNU Radio block for bladeRF devices
GNU General Public License v3.0
28 stars 9 forks source link

bladeRF-sink: Floating point values of 1.0 and above cause sign flip #5

Open warnes opened 2 years ago

warnes commented 2 years ago

Passing complex values with I or Q of 1.0 or greater to bladeRF-sink causes the transmitted values for both I and Q to flip sign, presumably due to silent overflow of 12-bit values.

I have a bladeRF 2.0 xA9:

$ bladeRF-cli -e info -e version

  Board:                    Nuand bladeRF 2.0 (bladerf2)
  Serial #:                 de69817e887b4743ae2e4a622023f123
  VCTCXO DAC calibration:   0x1d8f
  FPGA size:                301 KLE
  FPGA loaded:              yes
  Flash size:               128 Mbit
  USB bus:                  4
  USB address:              45
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

  bladeRF-cli version:        1.8.0-git-9ad89f65-dirty
  libbladeRF version:         2.4.1-git-9ad89f65-dirty

  Firmware version:           2.4.0-git-a3d5c55f
  FPGA version:               0.11.0 (configured by USB host)

I have connected TX1 connected to RX1 via a 50 Ohm loopback cable and 42 db of attenuators.

With the attached flowgraph (test_txrx.zip) and the settings:

However, when the amplitude of the signal source ("Cos Amplitude") is set to 1.0 or higher, the peaks of the cosine waves are 'flipped': image [NB: I'm not sure why the flip doesn't align with the peak of the output samples. Phase offset perhaps?]

warnes commented 2 years ago

Suggested solutions:

  1. Warn the user if I or Q integer values outside of [-2048, 2047] or real values outside of [-1.0, 0.9995] are received.
  2. Clip values outside of range to [-2048, 2047].
warnes commented 2 years ago

To avoid filling up the console with too many errors, perhaps the number of warnings should be limited. Perhaps it should only be displayed on the first value outside of the range, or at most x times per second.

warnes commented 2 years ago

Or perhaps the warning would only issue when the logging level was, say, 'debug'.