TX at 1.6GHz

[michelebavaro]

I would like to use BladeRF as record and playback system for GPS L1 (1.57542GHz).
If I set the frequency to 1.2GHz the device seems to work as expected, if I set 1.6GHz it does not.
In the library, I modified
@bladerf:476
from
if( frequency >= 1500000000 ) {
to
if( frequency >= 1800000000 ) {

@lms.c:783
from
lms_spi_write( dev, base+5, freqsel<<2 | (freq < 1500000000 ? 1 : 2 ) ) ;
to
lms_spi_write( dev, base+5, freqsel<<2 | (freq < 1800000000 ? 1 : 2 ) ) ;

but it still does not work.
Is anybody having problems transmitting something above 1.500 GHz?

Cheers,
Mic

[bpadalino]

How are you trying to send the samples to the device? If it's using the CLI, when you think you are transmitting, can you try to do a 'print gpio' and see if the TX Enable is actually enabled? We had a bug where there was an absurdly short timeout causing some writes to peripherals to not occur. We committed a fix yesterday, so please give that new kernel driver a try.

The band selection should be done for you when you 'set frequency'. Let me know if this works for you.

[michelebavaro]

Hi Brian,

Yes I did a fresh clone this morning (my morning) and tried the new kernel driver. It seems to be more stable now.

Funnily enough, with my changes I could transmit something at 1.575GHz by setting the frequency to 1.2GHz first, then in 100MHz steps up to 1.575GHz.
Setting immediately to 1.575GHz does not work for me.

My GPS receiver (I am doing some playback of recorded data) does not lock properly and it might be a reference oscillator problem.
I don't think any management of the onboard VC-TCXO through the CLI has been implemented yet... but does it at least run at VCTRL midpoint?
Using an external clock is also not supported yet by the CLI, right?

My general feeling is that the bladeRF software is lagging behind quite a bit compared to availability of the hardware.
Better to check back the repository in a few days.

Cheers,
Michele

[michelebavaro]

Hola,

Sorry to revive this old topic, but I have seen some significant activity recently on the github repository so I updated the two BladeRF I have with the latest software.

I cannot believe that nobody else has my problem:
- connect the bladeRF
- load the FPGA with the latest image
- start the CLI in interactive mode
-- set frequency to 1.6GHz (by the way, typing all those zeroes in is a pain)
-- set samplerate to 5M
-- set bandwidth to 2.5M
- set the input file name and format
- tx start

=> nothing happens on the spectrum analyzer :(

If I change the frequency to 1.4GHz, everything works as expected. The problem is surely on selection of the bladerf_select_band() function, switching to LNA2. In fact, if I tweak that 1500000000 magic number to 1700000000, recompile and install, then the waveform magically appears on the spectrum analyzer. By the way, sometimes packets are dropped (especially at high sample-rates) but there is no feedback or error reporting about it to the user.
So please - before I give up and buy yet another USRP - could anybody tell me if my hardware is broken or if this happens elsewhere?

Bests,
Michele

[bpadalino]

Let me give this a try tonight and verify that I can transmit at all frequencies.

There has been a massive amount of activity in the repository. It might be that we broke something in the meantime.

[bpadalino]

Verified that we are missing a call to lms_pa_enable() under lms_lna_select() in bladerf_select_band().

Going to push a fix tonight. Sorry for the inconvenience.

As for setting the frequency, set frequency tx 1.6G works just fine - or at least it should. Let me know if you have issues with that. I'll make another post when I push that change. Again, sorry for the inconvenience.

[bpadalino]

We just pushed a fix.

Please re-clone and make sure it works for you?

[michelebavaro]

Yes, TX works now above 1.5GHz ..but the sign of the Q channel seems to be flipped now

Packets keep dropping from time to time, which I would not expect at 5Msps. Perhaps you will consider in the future having 8-bit samples?

Bests,
Michele

[bpadalino]

If you're using the CLI, it doesn't use the asynchronous interface yet. It's a big to-do item to get the async interface into the API.

In the meantime there is a test_async program which will receive, and a test_repeater which will receive then immediately turnaround and transmit. Those are in the library tests.

The Q conjugate I've seen from time to time and need to track down. It's a bit of a slippery one.