Capture RX samples with bladeRF test program

[anrp]

I can't capture with the bladeRF test program.

I did manage to rebuild both the FX3 firmware and the FPGA firmware (commandline linux, quartus 12.1sp1). Apparently the device shipped with 1.0 FX3 firmware and I downgraded to 0.3 (what was in the github...) don't really know if that's related. Everything I installed/built out of github was as of 7PM EST July 24.

anrp@laptop5:~/bladerf/bladeRF/linux/apps$ sudo ./bin/bladeRF --device /dev/bladerf1 --load-fpga ../../hdl/quartus/hostedx40.rbf
Loading fpga...
FPGA aleady loaded - reloading!
Done.
bladeRF> probe

Path: /dev/bladerf1
Serial: 0x0000000000000000
Firmware: v0.3
FPGA: v0.0

bladeRF> set gpio 0x00
bladeRF> set gpio 0x57
bladeRF> set frequency rx 900000000

start=0 stop=63 set=31
Set RX frequency: 900000000Hz

bladeRF> set bandwidth 28000000

Set RX bandwidth - req: 28000000Hz actual: 28000000Hz
Set TX bandwidth - req: 28000000Hz actual: 28000000Hz

bladeRF> set samplerate 40000000

Setting RX sample rate - req: 40000000Hz, actual: 40000000Hz
Setting TX sample rate - req: 40000000Hz, actual: 40000000Hz

bladeRF> rx file.bin binary 100000000
bladeRF> print gpio

GPIO: 0x00000057

LMS Enable: Enabled
LMS RX Enable: Enabled
LMS TX Enable: Enabled
TX Band: Low Band (300M - 1.5GHz)
RX Band: Low Band (300M - 1.5GHz)


.... nothing, no file.bin. ??

Nothing really interesting in the kernel log.
[172041.949749] usb 4-1: new SuperSpeed USB device number 27 using xhci_hcd
[172041.967134] usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted.
[172041.969036] usb 4-1: New USB device found, idVendor=1d50, idProduct=6066
[172041.969046] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[172041.969052] usb 4-1: Product: bladeRF
[172041.969057] usb 4-1: Manufacturer: Nuand
[172041.969433] xhci_hcd 0000:0e:00.0: xHCI xhci_add_endpoint called with enabled ep ffff8804243652c0
[172041.969442] xhci_hcd 0000:0e:00.0: xHCI xhci_add_endpoint called with enabled ep ffff880423e130c0
[172041.985597] nuand_bladerf 4-1:1.0: Nuand bladeRF device is now attached

LED2 starts blinking after I load the FPGA, LED3 is always on, and LED1 blinks fast after I issue the samplerate command.
Should I be waiting for things to smooth out?

[anrp]

Looking at bladeRF's rx.c test code, it's not implemented yet. Oops...

However, the rx_test.c doesn't work either.

sudo strace ./rx_test 40000000 40000000
execve("./rx_test", ["./rx_test", "40000000", "40000000"], [/* 18 vars */]) = 0
brk(0) = 0xa77000
[lots of boring library setup here]
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0) = 0xa77000
brk(0xa98000) = 0xa98000
open("/dev/bladerf1", O_RDWR) = 3
ioctl(3, 0x80044e1b, 0x7fffc78b21ac) = 0
ioctl(3, 0x80044e01, 0x7fffc78b218c) = 0
ioctl(3, 0x80044e00, 0x7fffc78b2170) = 0
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)
read(3, 0x602080, 4096) = -1 ETIMEDOUT (Connection timed out)

[bpadalino]

We have someone working on getting TX and RX going on the CLI on github.

The format is something like

Code: Select all

rx config file=blah.bin n=8192
rx
rx start

That should setup to store to a file 'blah.bin' for 8192 samples. It will be binary, host native format. The 'rx' will print the configuration. The 'rx start' should start it. If you did 'n=0', the reception would be infinite until an 'rx stop' was issued.

The timeouts are strange. Are you connected via USB SS or HS in your dmesg? If you do a 'gpio print' what do you get?

Give the branch mentioned above a try and see how it works for you? Note that sample numbers being multiples of 1024 make life easy, but I believe support for different file sizes have been implemented.

[jynik]

We have someone working on getting TX and RX going on the CLI on github.

Hi there! I'm just finishing up the implementation of the TX and RX support. I just have to squash a couple more bugs, and then I'll be submitting this to the Nuand mainline git:

A (mostly) working version can be found here:
changeset 491e396353f568f6a309ee0c307df57c70942bcf

I'll be documenting this in the README.md (or perhaps a cli.md) soon. For now, I'll try to quickly give an overview. This information is in the help tx and help rx text as well (in the aforementoned changeset.

To save 10,000 samples to a csv, one could doe:

Code: Select all

rx config file=samples.txt format=csv n=10000
rx            # or 'rx config' to print the current settings
rx start
# If you're capturing a large amount of samples, you could run 'rx' or 'rx config' here and see the RX task in the "Running" state
# Once the task shows "Running" your sample file is ready!

By setting n=0, you can receive samples until you run the command, rx stop. Be careful though, and ensure you have ample disk space or RAM (if writing to a ramdisk or /dev/shm), considering the sample rate you're running at.

If you don't mind processing the the raw binary data, I'd recommend format=bin, just to keep files a bit smaller. Depending on your HDD speed, you may want to save samples off to RAM (e.g., /dev/shm/samples.txt) to avoid overrun conditions. (Detection and warning of this is planned!) I'm seeing that when transmitting at higher sample rates, I get better results on my slower HDDs when files are in RAM. Similarly, I had been tx'ing /dev/urandom as a test, and I found that this device is actually too slow! (dd some data from it...I only got like 16 MB/s!)

You could re-transmit what you sampled via:

Code: Select all

tx config file=samples.txt format=csv repeat=1 delay=0
tx # Or 'tx config' to view this configuration
tx start

Note that the CLI will convert your CSV file to a binary file (stored in /tmp) before starting transmission, to alleviate the need to parse the file while transmitting. (As of the aforementioned commit, I still have to fix a few things so that this temp file path is shown!)

If you want to repeatedly transmit the contents of a file with some delay, you can use the repeat=X and delay=Y parameters.

For example to send that file 10 times, with a 500 ms delay between each transmission...

Code: Select all

tx config file=samples.txt format=csv repeat=10 delay=500000
tx # Just view and double check our settings
tx start
tx # For longer delays, you can see that the TX task will be in the running state now

With respect to your timeouts, could you try some slightly lower sample rates? I had seen some timeouts when writing to files -- it seems there's a sneaky bug somewhere that results in timeouts if the Host isn't keeping up. (folks are looking into this currently, but feel free to review driver and FX3 code and offer suggestions! )

I'll try to review this thread more later and come back with any additonal ideas.

I'll be AFK for the next few days, so bear with me. I'll be sure to check back on this thread when I can get to a computer. In the meantime, keep an eye out for CLI commits to the Nuand mainline git repo...I'm looking to push code there today!

I haven't been able to test it yet, but I'm looking forward to using this CLI with some fifos (i.e., unix named pipes) -- I'm hoping this CLI could become a useful little swiss army knife for prototyping and would like to try implemeting a little FSK modem terminal program that writes/reads to FIFOs that the CLI is operating on.