Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
warnes opened this issue Feb 1, 2022 · 3 comments
Open

Comments

@warnes
Copy link

warnes commented Feb 1, 2022

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:

  • TX Gain: 22db
  • Cos Amplitude: 0.999
    everything looks pretty good:
    image

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
Copy link
Author

warnes commented Feb 1, 2022

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
Copy link
Author

warnes commented Feb 1, 2022

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
Copy link
Author

warnes commented Feb 1, 2022

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant