Transverter works strange after firmware update

[pe2bz]

Hi,

I have been running my X40 with the transverter for about a week on a Windows 7 computer. Last week I connected the combination to my I5 laptop with USB3.0 port. This is running Windows 10 Beta versrion. When installing the Windows software from the Nuand website it offers to update the firmware, which succeeded.

Playing around with the X40 and the SDR Console (2.3 Beta 1990) it does work OK from 300 MHz and up. On HF however, there is no reception. Except for a small part between around 35 and 60 MHz.

I also tried the bladeRF-CLI (version 1.1.2 ) with set frequency, but setting frequencies below 300 MHz result in strange responses. Setting it to 101.5M gave as result that it was set to 237 MHz (give or take a little, do not remember it completely)

I switched back the BladeRF to the Win7 computer, and on that computer also the frequencies below 300 MHz only do HF on 35 - 60 MHz and on the other HF frequencies there is no reception.

Currently I have no clue how to solve this. Neither do I know at the moment how to check which firmware was flashed yesterday and how to revert to the previous version.

Does anyone have any idea ?

Thanks in advance,

Ben - PE2BZ

[jynik]

Hi there,

This sounds strange, so please bear with me as I ask you to try a few things in an effort to collect more information. Can we perhaps try these thing on the Windows 7 machine, so that I can try to maintain a similar setup? (I don't have a Windows 10 machine.)

For long output, please wrap it in:

Code: Select all

[code]
... log output ...

[/code]

(1) You noted that you're looking to work an HF band within 35 - 60 MHz; only a part of this is covered by the on-board filters. Are you using the custom filter path then? If so, do you have a filter in-line or are you just jumpering the custom path to effectively have no front end filter? I can't quite recall how you specify which of the 4 filter bank options (1.25m, 2m, 6m, custom path) you want to use in SDR Console.

(2) After you ran the new installer, did you copy the new bladeRF.dll from the installation location into the SDR Console directory? I know that program ships its own bladeRF.dll, so one has to be sure that the updated one is being used.

(3) Do you recall which installer you had previously used? The first page of the installer generally lists some sort of version number -- I can figure out the firmware version from that. You could then fetch and try that version from https://www.nuand.com/fx3, if you'd like.

(4) With the bladeRF plugged in, could you run the following and share everything from the log?

Code: Select all

> bladeRF-cli.exe -i
bladeRF> info
... This will tell us about your device. You can blank out the serial number if you wish ...
bladeRF> version
... This should list the firmware and FPGA version numbers ...

(5) You mentioned using the bladeRF-cli to try setting frequencies. This was an excellent thought for debugging, as it eliminates SDR Console from the problem scope. Could you try the following from a fresh power cycle, and share all of the log content? I believe SDR Console will override anything you do here in the CLI, by the way. I just want to see if there are any strange errors or debug output that jumps out at me as indicating a problem or misconfiguration.

Code: Select all

> bladeRF-cli.exe -i -v verbose
bladeRF> xb 200 enable
bladeRF> xb 200 filter rx auto_3db
bladeRF> set frequency rx 89.7MHz
bladeRF> print frequency

[pe2bz]

Hi, at first, thanks for your fast reply !

here's some info output below is from my Win7 computer where it had been running last week.

To make things clear: I was not trying to receive or transmit within the 35 - 60 MHz range. I noticed that my BladeRF did not receive anything on the transverter, not even a local radio broadcast on 87.6 MHz, then I tuned down, and between 60 down to 35 I see noise and some pagers around 39 MHz but below 35 MHz all signals disappear again. So, no 10 meter, 15 meter, 20 meter and so on. I have to admit that I also switched the antenna from the logper to a QFH antenna, but the FM broadcast station transmits 5kW at 2 km distance and even that does not come through.

When I first received the unit I connected the RX to the transverter and the antenna to the transverter antenna connection and had SDRconsole running without problem, automatically switching the transverter when tuning. I have no (custom, homebuild) filters attached and I use the default LPF settings.

This all worked quite well, taking a learning curve for the gain and bandpassfilter settings, but I could receive AM from 1008 kHz up to Wifi @ 2400MHz

I did not copy the bladeRF.dll to the SDR-console folder at first, I did now, but at the moment I cannot restart SDR console completely because one instance is recording from a dongle. I restarted the instance with the BladeRF however, but the new dll does not improve my situation.

I hope my comments make things more clear, if not, I'll try to explain better.

Kind regards,
Ben - PE2BZ

Code: Select all

c:\Program Files\bladeRF\x64>bladeRF-cli.exe -i


bladeRF> info

  Serial #:                 90df358a28a4cd8613961979104d
  VCTCXO DAC calibration:   0x9d68
  FPGA size:                40 KLE
  FPGA loaded:              yes
  USB bus:                  1
  USB address:              5
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

bladeRF> version

  bladeRF-cli version:        1.1.2
  libbladeRF version:         1.2.1

  Firmware version:           1.8.0
  FPGA version:               0.1.2

bladeRF>
c:\Program Files\bladeRF\x64>bladeRF-cli.exe -i -v verbo
[VERBOSE @ libusb.c:515] Using libusb version: 1.0.19.10
[VERBOSE @ libusb.c:406] Found a bladeRF (idx=7)
[VERBOSE @ usb.c:257] Changing to USB alt setting 0
[VERBOSE @ usb.c:257] Changing to USB alt setting 1
[VERBOSE @ usb.c:257] Changing to USB alt setting 2
[VERBOSE @ usb.c:257] Changing to USB alt setting 1
[VERBOSE @ usb.c:257] Changing to USB alt setting 2
[VERBOSE @ usb.c:257] Changing to USB alt setting 1
bladeRF> xb 200 enable

  Enabling XB-200 transverter board
  XB-200 Transverter board successfully enabled

bladeRF> xb 200 filter rx auto_3db

[VERBOSE @ usb.c:924] expansion_gpio_write: 0xdfffffdd
  XB-200 Transverter board rx filter successfully set to

bladeRF> set frequency rx 89.7MHz

[VERBOSE @ usb.c:1036] usb_lms_read: 0x5a 0x68
[VERBOSE @ usb.c:1015] usb_lms_write: 0x5a 0x68
[VERBOSE @ usb.c:924] expansion_gpio_write: 0xdfffffdd
[VERBOSE @ usb.c:924] expansion_gpio_write: 0xffffffdd
[VERBOSE @ lms.c:1433] ---- Frequency ----
[VERBOSE @ lms.c:1434]   x        : 4
[VERBOSE @ lms.c:1435]   nint     : 120
[VERBOSE @ lms.c:1436]   nfrac    : 5505024
[VERBOSE @ lms.c:1437]   freqsel  : 0x2d
[VERBOSE @ lms.c:1438]   reference: 38400000
[VERBOSE @ lms.c:1439]   freq     : 1158300000
[VERBOSE @ usb.c:1036] usb_lms_read: 0x09 0x40
[VERBOSE @ usb.c:1015] usb_lms_write: 0x09 0x45
[VERBOSE @ usb.c:1036] usb_lms_read: 0x25 0x95
[VERBOSE @ usb.c:1036] usb_lms_read: 0x08 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x46 0x00
[VERBOSE @ usb.c:1015] usb_lms_write: 0x25 0xb5
[VERBOSE @ usb.c:1015] usb_lms_write: 0x20 0x3c
[VERBOSE @ usb.c:1015] usb_lms_write: 0x21 0x54
[VERBOSE @ usb.c:1015] usb_lms_write: 0x22 0x00
[VERBOSE @ usb.c:1015] usb_lms_write: 0x23 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x26 0x8c
[VERBOSE @ usb.c:1015] usb_lms_write: 0x26 0x8c
[VERBOSE @ usb.c:1036] usb_lms_read: 0x27 0xe0
[VERBOSE @ usb.c:1015] usb_lms_write: 0x27 0xe0
[VERBOSE @ usb.c:1036] usb_lms_read: 0x28 0x40
[VERBOSE @ usb.c:1015] usb_lms_write: 0x28 0x40
[VERBOSE @ usb.c:1036] usb_lms_read: 0x29 0xb7
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0xa0
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x43
[VERBOSE @ lms.c:1529] Too low: 32 -> 16
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x90
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ lms.c:1523] Found normal at VCOCAP: 16
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8f
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8e
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8d
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8c
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8b
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8a
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x89
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x83
[VERBOSE @ lms.c:1562] Found lower limit VCOCAP: 10
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x90
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x91
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x92
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x43
[VERBOSE @ lms.c:1593] Found upper limit VCOCAP: 17
[VERBOSE @ lms.c:1597] Goldilocks VCOCAP: 13
[VERBOSE @ usb.c:1015] usb_lms_write: 0x29 0x8d
[VERBOSE @ usb.c:1036] usb_lms_read: 0x2a 0x03
[VERBOSE @ lms.c:1610] VTUNE: 0
[VERBOSE @ usb.c:1036] usb_lms_read: 0x09 0x45
[VERBOSE @ usb.c:1015] usb_lms_write: 0x09 0x40
[VERBOSE @ usb.c:1036] usb_lms_read: 0x08 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x46 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x75 0x90
[VERBOSE @ usb.c:1015] usb_lms_write: 0x75 0x90
[VERBOSE @ usb.c:913] config_gpio_write: 0x80000057
[VERBOSE @ usb.c:1036] usb_lms_read: 0x20 0x3c
[VERBOSE @ usb.c:1036] usb_lms_read: 0x21 0x54
[VERBOSE @ usb.c:1036] usb_lms_read: 0x22 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x23 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x25 0xb5
  Set RX frequency:   89700000Hz

bladeRF> print frequency
[VERBOSE @ usb.c:1036] usb_lms_read: 0x20 0x3c
[VERBOSE @ usb.c:1036] usb_lms_read: 0x21 0x54
[VERBOSE @ usb.c:1036] usb_lms_read: 0x22 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x23 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x25 0xb5

  RX Frequency:   89700000Hz
[VERBOSE @ usb.c:1036] usb_lms_read: 0x10 0x3b
[VERBOSE @ usb.c:1036] usb_lms_read: 0x11 0x9c
[VERBOSE @ usb.c:1036] usb_lms_read: 0x12 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x13 0x00
[VERBOSE @ usb.c:1036] usb_lms_read: 0x15 0xb5
  TX Frequency:  103500000Hz

bladeRF>
c:\Program Files\bladeRF\x64>

[jynik]

Hi there,

Just to confirm, you have the bladeRF and XB-200 connected as follows, correct?

• The bladeRF RX port connected to the XB-200 RXIF port via an SMA cable
• the XB-200 RXFILT port connected to the RXFILT_ANT port via an SMA cable (which means there's no front end filter - if you see strange behavior in the presence of strong transmitters, this should be suspect)
• A 50 ohm SMA male antenna connected to the RXANT SMA port

The output from the bladeRF-cli looks good to me for the following reasons:

• Your version numbers all indicate the latest versions of everything, which is a compatible set.
• A sane version of libusb appears to be installed
• The XB-200 enables correctly, as evidenced by it being able to tune to 89.7MHz, which ends up being 1158.3 MHz, considering the 1248.0MHz IF.
• The requested frequency reads back correctly.

I ran SDR Console 3.2 Build 1990 with the configuration mentioned above, and confirmed I see no issues with that firmware/fpga version:

However, with the FM stations being so strong, I had to turn gains all the way down. Even still, I didn't like how hot the signals are (they should be kept under -15 dB to avoid saturating the frontend). So I added a 30 dB attenuator to my RXANT port, and turned the gains up a bit, getting something that looked like this:

sdr_console_fm.png

So at this point, it sounds like we'll have to play the "what changed?" game. You could uninstall the bladeRF software and use an older installer to revert to an older firmware. However, I don't really thing there are any FX3 firmware changes that would affect this. Any chance you could share a screenshot or two?

[pe2bz]

Hi,

I am not at home for the next 4 days. I wll reply as soon as I return.

Kind regards,

Ben

[pe2bz]

Hi Jynik,

all works now.

I have made an error when I connected the bladeRF to the Windows10 laptop to do some rx and re- tx experiments. To be able to TX I had to remove the SMA patch cable (XB-200 RXFILT port connected to the RXFILT_ANT port) and used that one for the TX connection for the transverter. Still received signals at 400 MHz with LPF mode bypass so I assumed that LPF mode bypass was a (RF relay) switch wich bypassed the bandpass so I did not have to attach that patch cable.

Now, I attached another SMA patch cable XB-200 RXFILT port to the RXFILT_ANT port and I do receive all signals now.

For the TX experiments I attached the antenna directly to the TXANT on the XB-200, Am I right to say now that I also need the SMA patch cable for the TXFILT to the TXFILT_ant port and if this is not attached I am transmitting without antenna ?

Thanks again for your reply,

Ben

[jynik]

Hi Ben,

Allow me to first explain a bit more about the custom filter path:

The XB-200 has 3 on-board band pass filters, designed to cover the 6m, 2m, and 1.25 amateur bands.

The libbladeRF library allows the software to select which of these are in use. There are "auto_3db" and "auto_1db" options in which libbladeRF will select the most appropriate bank based on the desired frequency. In the case where none of the above apply, it falls back to that custom path (e.g., RXANT <-> RXANT_FILTER).

The intent of this custom path is that users can purchase/build filters for their desired band and attach them in-line here.

However, it's common for folks to simply use no front-end filter by directly connecting the RXANT <-> RXANT_FILTER, allowing them to receive things like FM bands. However, by not using a front-end filter, you'll likely run into some (potentially strange) signal quality issues, especially if you've got a strong FM station blasting the spectrum nearby.

So in short - if you're not receiving from within the 6m, 2m, or 1.25m bands, yes, you must either insert a custom filter or directly connect RXANT <-> RXANT_FILTER.

I highly advise against jumpering TXANT <-> TXANT_FILTER without a filter . If you're transmitting, you're responsible for ensuring that your emissions remain in the allocated regions of the spectrum. Without a proper filter in place, you certainly cannot guarantee that. (Fun exercise, find someone with a spectrum analyzer and see for yourself. Take a look at your harmonics.)

Best regards,
Jon