GPS receiver/simulator using bladeRF

[taro]

Hi everyone,

I’m developing a GPS receiver/simulator using bladeRF. As far as I can see, the current firmware and fpga are improved with respect to packet losses.

At this moment, real-time GPS positioning using bladeRF worked well
Here is the demonstration video on YouTube.
http://www.youtube.com/watch?v=uf2vatqek_o

However, there are still few packet losses if we set sampling rate as 40 Msps. The bladeRF is of course connected via USB 3.0 port. In addition, there is also a large DC bias.

Further, Tx at 1.5GHz doesn't work well. For example, I put following commands using bladeRF-cli.exe, but bladeRF-cli.exe has crashed after “tx start”.

Set frequency 1.57542G
Set samplerate 8M
rx config file=test.bin n=8M
rx start
tx config file=test.bin
tx start

Please let me know if anyone has any solutions.

Thank you.
Taro

[drmpeg]

From your video, it looks like you're only using Windows, so this may not help entirely. In Linux, you can use osmocom_fft to eliminate the DC offset.

osmocom_fft -s 8000000 -f 429000000 --dc-offset-mode=0

This starts osmocom_fft with a slider to adjust the DC offset. With some careful tuning, you can just about eliminate the DC offset.



The bladeRF remembers the DC offset correction, so once you've tuned it for a given frequency and RX gains, it will be good for other applications.

Ron

[jynik]

Hey there! Video looked great...looking forward to test driving this myself soon!

DC offset
To build on what Ron said, you can also dial in some correction values for IQ imbalance. (--iq-correction-mode=0 for osmocom_fft IIRC...). Under the hood, these correction values are set via the bladerf_set_correction() function.

Sample rate issue
With respect to losing samples at 40Msps - are you saving samples to disk? Generally, when using the CLI it is recommended to save samples off to RAM (e.g., /dev/shm or /tmp in Linux). I'm not certain if anything similar exists in Windows. Any chance you could try a faster disk, or SSD?

If you're certain the dropped samples has nothing to do with the disk, how's your CPU load looking? Does it look like your program is keeping up? One test you can try is to turn on the 32-bit counter mode in the FPGA (as of v0.0.3), where the 32-bit (I, Q) pair will be replaced with a single 32-bit count value, and look for gaps. Run this over a range of sample rates, and you can get a decent feel of how well your setup is able to perform. To enable this mode run 'set gpio 0x257' in the bladeRF-cli's interactive mode.

For what it's worth, I'm able to hit 40 Msps on my laptop with no issue, but my desktop starts to struggle above 20-30, depending on the software I'm running.

Issue above 1.5GHz?
Is the crash in the CLI the only issue you're seeing? Are there other symptoms indicative of issues when tuning above 1.5GHz?

I see you're RX'ing to and Tx'ing from the same file... are you waiting for the RX to complete before attempting to TX with the same file? I was able to replicate that in Windows, but not Linux, when attempting to TX the file what it was still being written to by RX task...will have to dig deeper into that to identify the issue.

I also just wanted to note that commit a712304f fixed an issue that occurred when transitioning across the 1.5GHz boundary. (This defect was introduced in commit 9ee9c765). I'd suggest ensuring you're got the latest libbladeRF code if you're seeing anything strange.

- Jon

[taro]

Ron and Jon,
Thank you for your quick reply.

DC offset
I’ll try to call the “bladerf_set_correction()” in my software to correct IQ imbalance.

Sample rate issue
In my program, the samples are stored in memory to process in real-time instead of saving samples to disk. I tried to use the 32-bit counter mode. It was very useful to check the sample losses. In both win7 64bit and Ubuntu 13.10 64bit environments, the counter value was continuous except for the first 1ms (but I think it’s not a big problem…) I attached the figure which shows the difference between the counter value.



I think I will have to evaluate the more long-term effects. Anyway, thank you for nice information.

Tx problem
I downloaded and built the latest libbladeRF code from git in the both windows and linux environment. However, “set tx frequency” didn’t work at any frequency…I attached the screen shot of the bladerf-cli. Does the “set tx frequency” work correctly in the latest source code?



Thank you,
Taro

[jynik]

DC Offset and IQ Imbalance
I'd advise taking a look at how osmocom_fft provides these sliders and doing something similar. drmpeg might be able to provide better advise on this, but my general procedure on the RX side looks something like this:

• Tune to my desired frequency
• Sweep DC offset values for I until I see the spike at DC reach a minimum.
• Sweep DC offset values for Q until I see that DC spike further reduced.
• Rinse and repeat until I feel the DC offset is reduced a satisfactory amount.

I do something similar for IQ imbalance -- usually I'm feeding in a tone from a piece of test equipment and doing a similar sweep until I remove images from the spectrum.

On the TX side of things, I usually transmit a sine into a spectrum analzyer and do the same sort of manual tuning until my DC spike and any images are minimized.

It might be worth jotting down the values you come up with for a specific frequency, just so you have a rough starting point for the next time you power on the device. Granted, they'll change over time (and certainly with frequency).


Sample Rate issue
I believe what you're seeing there is 1 buffer of "old" sample data that was in some host/FPGA/FX3 buffers before switching modes. Until that's fixed, you might want to just flush out the first few buffers worth of data.

TX Tuning issue
I can at least confirm that I'm able to tune fine with the same versions you've shown here.

Could you run the bladeRF-cli with -v verbose and share the full log up through setting the TX frequency. I expect that we may see some messages about a VCOCAP not converging.

It sounds a little weird, but does it fail if you do a 'print frequency' before setting it? (That will immediately indicate a bug to me and give me some sense of where the problem could lie).

Based upon this log, we can figure out where to debug further. Just totally guessing, I'd supect the issue could be:

• A defect was introduced in this commit. (Most likely) In this case, I'll look to reproduce and fix the bug.
• Your board has some HW issue (Less likely). We'll cross this bridge if/when we get there.

To help determine if a software bug is at fault, could you try checking out the host-software at commit 0655e83d and letting me know if you're able to successfully tune the TX module there?

[taro]

Thanks for every help.

Today, I saved the bladeRF-cli log when I was setting the TX frequency. I tried to do “print frequency” before setting, but it worked well. After that, I could not change to any frequency.

I’m sure that the source code is up-to-date.
I might borrow another bladeRF board in a few days, and if so, I will try to check TX tuning using another board.

Code: Select all

ubuntu@ubuntu:~/bladeRF/host/build/output$ sudo ./bladeRF-cli -i -v verbose
[VERBOSE] Using libusb version: 1.0.16.10774
[VERBOSE] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE] Non-bladeRF device found: VID 1d6b, PID 0003
[VERBOSE] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE] Non-bladeRF device found: VID 058f, PID 6362
[VERBOSE] Non-bladeRF device found: VID 04f2, PID 1060
[VERBOSE] Non-bladeRF device found: VID 8087, PID 0024
[VERBOSE] Non-bladeRF device found: VID 1d6b, PID 0002
[VERBOSE] Found a bladeRF (based upon VID/PID)
[VERBOSE] Claimed all inferfaces successfully
[VERBOSE] Change to alternate interface 0
[VERBOSE] Change to alternate interface 1
[VERBOSE] Changed into RF link mode: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x0c, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x0d, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x0e, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x0f, 0xff ]
[DEBUG] Raw FPGA Version: 0x00030000
[DEBUG] bladerf_open_with_devinfo: fw=v1.6.1-git-b7e6642 serial=b6c56fbd99eab1a80445117597964bcd trim=0xaaad fpga_size=40
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x00, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x01, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x02, 0xff ]
[VERBOSE] Peripheral access: [ 0x4e, 0x81, 0x03, 0xff ]
bladeRF> print frequency tx
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x10, 0xff ]
[VERBOSE] lusb_lms_read: 0x10 0x34
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x11, 0xff ]
[VERBOSE] lusb_lms_read: 0x11 0x15
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x12, 0xff ]
[VERBOSE] lusb_lms_read: 0x12 0x55
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x13, 0xff ]
[VERBOSE] lusb_lms_read: 0x13 0x55
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x15, 0xff ]
[VERBOSE] lusb_lms_read: 0x15 0x95

  TX Frequency: 1000000000Hz

bladeRF> set frequency tx 1.57542G

[VERBOSE] ---- Frequency ----
[VERBOSE]   x        : 4
[VERBOSE]   nint     : 164
[VERBOSE]   nfrac    : 891290
[VERBOSE]   freqsel  : 0x35
[VERBOSE]   reference: 38400000
[VERBOSE]   freq     : 1575420000
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x09, 0xff ]
[VERBOSE] lusb_lms_read: 0x09 0x40
[VERBOSE] lusb_lms_write: 0x09 0x45
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x09, 0x45 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x15, 0xff ]
[VERBOSE] lusb_lms_read: 0x15 0x95
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x08, 0xff ]
[VERBOSE] lusb_lms_read: 0x08 0x00
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x46, 0xff ]
[VERBOSE] lusb_lms_read: 0x46 0x00
[VERBOSE] lusb_lms_write: 0x15 0xd6
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x15, 0xd6 ]
[VERBOSE] lusb_lms_write: 0x10 0x52
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x10, 0x52 ]
[VERBOSE] lusb_lms_write: 0x11 0x0d
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x11, 0x0d ]
[VERBOSE] lusb_lms_write: 0x12 0x99
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x12, 0x99 ]
[VERBOSE] lusb_lms_write: 0x13 0x9a
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x13, 0x9a ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x16, 0xff ]
[VERBOSE] lusb_lms_read: 0x16 0x8c
[VERBOSE] lusb_lms_write: 0x16 0x8c
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x16, 0x8c ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x17, 0xff ]
[VERBOSE] lusb_lms_read: 0x17 0xe3
[VERBOSE] lusb_lms_write: 0x17 0xe3
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x17, 0xe3 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x18, 0xff ]
[VERBOSE] lusb_lms_read: 0x18 0x40
[VERBOSE] lusb_lms_write: 0x18 0x40
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x18, 0x40 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x19, 0xff ]
[VERBOSE] lusb_lms_read: 0x19 0xa0
[VERBOSE] lusb_lms_write: 0x19 0xa0
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0xa0 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 32 -> 16
[VERBOSE] lusb_lms_write: 0x19 0x90
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x90 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 16 -> 8
[VERBOSE] lusb_lms_write: 0x19 0x88
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x88 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 8 -> 4
[VERBOSE] lusb_lms_write: 0x19 0x84
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x84 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 4 -> 2
[VERBOSE] lusb_lms_write: 0x19 0x82
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x82 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 2 -> 1
[VERBOSE] lusb_lms_write: 0x19 0x81
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x81 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 1 -> 1
[DEBUG] VTUNE is not locked at the end of initial loop
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x09, 0xff ]
[VERBOSE] lusb_lms_read: 0x09 0x45
[VERBOSE] lusb_lms_write: 0x09 0x40
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x09, 0x40 ]

Error: An unexpected error occurred
bladeRF> set frequency tx 429M

[VERBOSE] ---- Frequency ----
[VERBOSE]   x        : 16
[VERBOSE]   nint     : 178
[VERBOSE]   nfrac    : 6291456
[VERBOSE]   freqsel  : 0x3f
[VERBOSE]   reference: 38400000
[VERBOSE]   freq     : 429000000
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x09, 0xff ]
[VERBOSE] lusb_lms_read: 0x09 0x40
[VERBOSE] lusb_lms_write: 0x09 0x45
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x09, 0x45 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x15, 0xff ]
[VERBOSE] lusb_lms_read: 0x15 0xd6
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x08, 0xff ]
[VERBOSE] lusb_lms_read: 0x08 0x00
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x46, 0xff ]
[VERBOSE] lusb_lms_read: 0x46 0x00
[VERBOSE] lusb_lms_write: 0x15 0xfd
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x15, 0xfd ]
[VERBOSE] lusb_lms_write: 0x10 0x59
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x10, 0x59 ]
[VERBOSE] lusb_lms_write: 0x11 0x60
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x11, 0x60 ]
[VERBOSE] lusb_lms_write: 0x12 0x00
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x12, 0x00 ]
[VERBOSE] lusb_lms_write: 0x13 0x00
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x13, 0x00 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x16, 0xff ]
[VERBOSE] lusb_lms_read: 0x16 0x8c
[VERBOSE] lusb_lms_write: 0x16 0x8c
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x16, 0x8c ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x17, 0xff ]
[VERBOSE] lusb_lms_read: 0x17 0xe3
[VERBOSE] lusb_lms_write: 0x17 0xe3
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x17, 0xe3 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x18, 0xff ]
[VERBOSE] lusb_lms_read: 0x18 0x40
[VERBOSE] lusb_lms_write: 0x18 0x40
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x18, 0x40 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x19, 0xff ]
[VERBOSE] lusb_lms_read: 0x19 0x81
[VERBOSE] lusb_lms_write: 0x19 0xa0
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0xa0 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 32 -> 16
[VERBOSE] lusb_lms_write: 0x19 0x90
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x90 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 16 -> 8
[VERBOSE] lusb_lms_write: 0x19 0x88
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x88 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 8 -> 4
[VERBOSE] lusb_lms_write: 0x19 0x84
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x84 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 4 -> 2
[VERBOSE] lusb_lms_write: 0x19 0x82
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x82 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 2 -> 1
[VERBOSE] lusb_lms_write: 0x19 0x81
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x19, 0x81 ]
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x1a, 0xff ]
[VERBOSE] lusb_lms_read: 0x1a 0x43
[VERBOSE] Too low: 1 -> 1
[DEBUG] VTUNE is not locked at the end of initial loop
[VERBOSE] Peripheral access: [ 0x4e, 0x91, 0x09, 0xff ]
[VERBOSE] lusb_lms_read: 0x09 0x45
[VERBOSE] lusb_lms_write: 0x09 0x40
[VERBOSE] Peripheral access: [ 0x4e, 0x51, 0x09, 0x40 ]

Error: An unexpected error occurred
bladeRF> 

Taro

[jynik]

Taro,

That's a good plan. Nothing here jumps out at me as anything indicative of a software defect.

If you find the other board works, touch base with Brian and Robert via [email protected], to see what can be done with that board. Be sure to reference this forum thread to show that we've ruled out some potential SW issues I initially suspected.

- Jon