A case for bladeRF and DesignSpark Mechanical

A case for DesignSparc Mechanical

The bladeRF-board was bought for GNSS-experiments. So I need to connect a GPS-antenna. The one I have is an active antenna that needs power. I built a small circuit to feed the antenna using phantom power. From two small pieces of PCB I made a stand and soldered them on a PCB-ground plate. This became the basis of my bladeRF-case.

I did some drawing with DesignSpark Mechanical and was looking for some serious work to develop skills: a case was born...

First sketch

The GPS-antenna is a Unictron GPS 02 and needs 2.4 .. 5,5 V. At 5 V it draws about 20 mA current. Not too much for the 5 V regulator in the bladeRF-board. I placed a jumper  on J70 and soldered a wire to get the needed 5 V for the antenna-supply. 

In UHF the golden rule is: the smaller the better. I decided to use SMD only. From my (big) SMD-junkbox I found the needed parts. The values are not calculated: I just more or less took what I found in the junkbox...

In retrospect the value of 39 ohm for the series resistor might become a problem. The power dissipation I*I*R = 20 * 20 * 39 = 15.6 mW. This SMD is very small, about 1*2 mm. I have no idea how much it can dissipate.

In case of a short cut the dissipation will be U*U/R = 5 *5 / 39 = 0,6 W. The resistor will act as a fuse in that case!

The RX-enty of the bladeRF is protected by two anti-parallel-diodes, hence the 820 pF capacitor to the RX-entry.

Connectors

I bought an SMB socket and a socket for the GPS-antenna, I think is was MMX with a diameter of 3.2 mm. Quite expensive: 6 + 10 euro at my local electronics-store. I needed some support for this sockets so decided to use a piece of PCB. Drilling an soldering of PCB makes a nice and sturdy support.

In the picture above you see a PCB ground plane and the support stand for the connectors. In the air between the two connectors you see the SMD- 820 pF capacitor. The red wire is the +5 V wire connecting to a jumper on J70 nof the bladeRF.

In the upper right you see that the bolt that holds the bladeRF is soldered to the base-plate.

Warning

For the sockets you need to drill a hole of 6.5 mm. I was so stupid to hold the small piece of PCB with my fingers firmly pressed to the table while drilling the 6.5 mm hole in the PCB. You might guess what happened: the PCB will be lifted up by the drill and will turn around the drill. With your fingers so close-by you get a nice long (15 mm) wound and rather deep too.

OK, not love and understanding this time, but my wife helped me close the wound with a nice plaster. Yes, I am 65 and stupid too!

The SMD-circuit in 3D

I used DesignSpark Mechanical to draw the circuit (just for fun). 

The same, but now in real-life:

The case

The case is a lower case and an upper case (my name, by the way is Kees which is pronounced like case, just in case). The lower case is a piece of PCB. At Elektor's shop I bought a "project-case". This is not much more than two pieces of plastic with some hex-stands. I used one plate of the project-case as the top plate. 

The bladeRF board is mounted with 4 bolts 2.5 mm. The bolts are soldered on the bottom-plate. The holes in the bladeRF-board are not 3 mm, just slightly smaller. That is a pity because M3 is much stronger than M2.5 that I had to use.

Epilogue

It was nice, after a long time of only programming, to find myself with a soldering iron again. It was great fun to solder the tiny SMD-parts, this time without a microscope. I found spectacles with very thick glasses +3. Sometimes I wear two spectacles for a better view (I am not joking, try it yourself!).

PCB is a very good material to make a housing, a case, for your circuits.

DesignSpark Mechanical is a free tool. Download it free and use it. I thought it is only a package to use a pre defined library of connectors from RS, but it is more, much more than that!

Next time, my ramblings with DesignSpark Mechanics or my struggling with getting GNSS-bladeRF-samples into a file and processing that file with Python.

Feel free to comment if something is not soo obvious!

The Windows installer for bladeRF-software

Nuand has new installer software for Windows

In the blog at nuand.com they write:

There is now a Windows based installer for the bladeRF that will install all of the relevant drivers, user mode utilities, and FX3/FPGA images. The file can be directly downloaded from http://nuand.com/downloads/bladerf_win_installer.exe .

OK, download this installer and open it

A warning, but what else can I do than execute this file?

Yes! There is bladeRF CLI in the Windows Start Menu

What about USB3?

The bladeRF-board was connected all the time at anUSB2-port. Now the LEDs stopped blinking. The installation did something to it. The bladeRF-board was connected all the time at a USB2-port. I’ll unplug it and reconnect to a USB3-port and start bladeRF CLI

Oeps, the board is invisible for bladeRF-cli when connected at a USB3-port!
Reconnect to a USB2-port and restart bladeRF CLI

Get the latest image for the FPGA

I have to get the latest.img from http://nuand.com/fx3/latest.img
C:\bladeRF-master_new might be a good place for it.
I’ll put it on C:\Program Files (x86)\bladeRF

A lot of errors, I seem to have to define a variable

I get a lot of errors and I have to define an environment variable in Windows.
So, in the configuration screen of the start menu of Windows I select advanced and environment-variables.

Defined BLADERF_SKIP_FW_SIZE_CHECK = 0

Now it seems to be OK

Connect an antenna and try to get samples into a file

Oh boy, this is interesting. It is late in the night already but I take the antenna from my Kenwood  TH-F7, it has the same connector as the bladeRF-board, and connect it to RX.

I created a file with samples. What is in this comma-separated-values file?

File  C:/temp/new282810M.csv reads:

…
89, 81
88, 80
92, 76
84, 76
90, 77
88, 76
92, 77
90, 84
85, 77
92, 80
88, 81
86, 75
92, 73
86, 82
91, 76
89, 81
91, 77
92, 77
88, 81
86, 73
88, 77
86, 77
90, 77
90, 77
91, 77
88, 77
91, 79

…

So, not so interesting. I’d expect more variation in the value of the numbers…

Epilogue

OK, installation of the Windows software with the installer from Nuand is a breeze! Thanks a lot for all their efforts. They keep doing a great job.

After installation I got error-messages with a clue: define BLADERF_SKIP_FW_SIZE_CHECK = 0

It seems I did only get some noise in the file with the samples. I'll experiment with some parameters like the gain, bandwidth, frequency and samplerate. I have a signal-generator that can put a signal up to 1 GHz on the antenna. With 100 W output-power to the RX-input of the bladeRF-board I should be able to get some smoke into and out of my file!

(dont try this with 100 W, some microVolts should be enough :>))

Architecture of the bladeRF-software

Thoughts

Before I bought the bladeRF-board I decided to make a program coded in python to control my bladeRF-board from the laptop. Furthermore I wanted to do the time-consuming calculations on the FPGA coded in VHDL. Quite challenging. Now I understand more of the bladeRF. There is a very good program bladeRF-cli that can do almost everything I want. There is C-coded program in the FX3-USB-chip. And there seems to be a NIOS-processor soft-programmed in the FPGA. That can be programmed in C too?

Goal

To understand/learn a device I define a goal and try to achieve that goal:

 "Try to code a python-program that gets some info from the bladeRF, eg. the bandwidth".

 Investigating the bladeRF-software

On my laptop the software is at C:\bladeRF-master.

Have a look at the source bladeRF.cli

The source for the basic funtions of bladeRF seems to be at

C:\bladeRF-master\host\libraries\libbladeRF\src

Doc for the libusb-API

I was desperately looking for the python-libusb-API on the internet. I did not find it!! However, the doc is in python itself, just type “help(usb)” and you get:

Help on package usb:

NAME
    usb - PyUSB - Easy USB access in Python

FILE
    c:\python27\lib\site-packages\usb\__init__.py

DESCRIPTION
    This package exports the following modules and subpackages:
    
        core - the main USB implementation
        legacy - the compatibility layer with 0.x version
        backend - the support for backend implementations.
    
    Since version 1.0, main PyUSB implementation lives in the 'usb.core'
    module. New applications are encouraged to use it.

PACKAGE CONTENTS
    _debug
    _interop
    backend (package)
    control
    core
    legacy
    util

DATA
    __all__ = ['legacy', 'core', 'backend', 'util']
    __author__ = 'Wander Lairson Costa'

AUTHOR
    Wander Lairson Costa


>>> Help(usb.core):

Help on module usb.core in usb:
NAME
    usb.core - usb.core - Core USB features.

FILE
    c:\python27\lib\site-packages\usb\core.py

DESCRIPTION
    This module exports:
    
    Device - a class representing a USB device.
    Configuration - a class representing a configuration descriptor.
    Interface - a class representing an interface descriptor.
    Endpoint - a class representing an endpoint descriptor.
    find() - a function to find USB devices.

CLASSES
    __builtin__.object
        Configuration
        Device
        Endpoint
        Interface

Etcetera, so the doc is in python!!

My goal again

In order to set the bandwidth to 12.345 MHz what to program in python? After that, read back the bandwidth from bladeRF-cli.

bladeRF-software

C:\bladeRF-master\host\libraries\libbladeRF\src contains bladerf.c:

…. int bladerf_get_bandwidth(struct bladerf *dev, bladerf_module module, unsigned int *bandwidth ) { /* TODO: Make return values for lms call and return it for failure */ lms_bw_t bw = lms_get_bandwidth( dev, module ); *bandwidth = lms_bw2uint(bw); return 0; } ….

C:\bladeRF-master\host\libraries\libbladeRF\src contains lms.c:

… // Get the bandwidth for the selected module lms_bw_t lms_get_bandwidth(struct bladerf *dev, bladerf_module mod) { uint8_t data; uint8_t reg = (mod == BLADERF_MODULE_RX) ? 0x54 : 0x34; bladerf_lms_read(dev, reg, &data); data &= 0x3c; data >>= 2; return (lms_bw_t)data; } …

So, search for bladerf_lms_read.

C:\bladeRF-master\host\libraries\libbladeRF\include

libbladeRF.h contains:

/** * Read a LMS register * * @param dev Device handle * @param address LMS register offset * @param val Pointer to variable the data should be read into * * @return 0 on success, value from \ref RETCODES list on failure */ API_EXPORT int bladerf_lms_read(struct bladerf *dev, uint8_t address, uint8_t *val); /** * Write a LMS register * * @param dev Device handle * @param address LMS register offset * @param val Data to write to register * * @return 0 on success, value from \ref RETCODES list on failure */ API_EXPORT int bladerf_lms_write(struct bladerf *dev, uint8_t address, uint8_t val);

What is API_EXPORT? a macro?

… /** Marks an API routine to be made visible to dynamic loader */ #if defined _WIN32 || defined _CYGWIN__ # ifdef __GNUC__ # define API_EXPORT __attribute__ ((dllexport)) # else # define API_EXPORT __declspec(dllexport) # endif #else # define API_EXPORT __attribute__ ((visibility ("default"))) #endif …

Search for lms_read and lms_write

C:\bladeRF-master\host\libraries\libbladeRF\src
bladerf.c

/*------------------------------------------------------------------------------ * LMS register read / write functions *----------------------------------------------------------------------------*/ int bladerf_lms_read(struct bladerf *dev, uint8_t address, uint8_t *val) { return dev->fn->lms_read(dev,address,val); } int bladerf_lms_write(struct bladerf *dev, uint8_t address, uint8_t val) { return dev->fn->lms_write(dev,address,val); } C:\bladeRF-master\host\libraries\libbladeRF\src bladerf_priv.h /* LMS6002D accessors */ int (*lms_write)(struct bladerf *dev, uint8_t addr, uint8_t data); int (*lms_read)(struct bladerf *dev, uint8_t addr, uint8_t *data);

Where are lms_read and lms_write defined?

C:\bladeRF-master\hdl\fpga\ip\altera\nios_system\software\lms_spi_controller hello_world_small.c

#define LMS_READ 0 #define LMS_WRITE (1<<7 data-blogger-escaped-access="" data-blogger-escaped-address="" data-blogger-escaped-an="" data-blogger-escaped-backend="(struct" data-blogger-escaped-bladerf-master="" data-blogger-escaped-bladerf="" data-blogger-escaped-bladerf_linux="" data-blogger-escaped-c:="" data-blogger-escaped-definition="" data-blogger-escaped-dev-="" data-blogger-escaped-dev="" data-blogger-escaped-finally="" data-blogger-escaped-for="" data-blogger-escaped-fpga="" data-blogger-escaped-host="" data-blogger-escaped-in="" data-blogger-escaped-int="" data-blogger-escaped-ioctl="" data-blogger-escaped-is="" data-blogger-escaped-it="" data-blogger-escaped-libbladerf="" data-blogger-escaped-libraries="" data-blogger-escaped-linux.c="" data-blogger-escaped-linux_lms_read="" data-blogger-escaped-lms="" data-blogger-escaped-lms_read:="" data-blogger-escaped-nios="" data-blogger-escaped-processor="" data-blogger-escaped-register="" data-blogger-escaped-ret="" data-blogger-escaped-runs="" data-blogger-escaped-software="" data-blogger-escaped-src="" data-blogger-escaped-static="" data-blogger-escaped-struct="" data-blogger-escaped-that="" data-blogger-escaped-the="" data-blogger-escaped-this="" data-blogger-escaped-uart_cmd="" data-blogger-escaped-uc="" data-blogger-escaped-uint8_t="" data-blogger-escaped-val="" data-blogger-escaped-virtual="">backend; address &= 0x7f; uc.addr = address; uc.data = 0xff; ret = ioctl(backend->fd, BLADE_LMS_READ, &uc); *val = uc.data; return ret; } static int linux_lms_write(struct bladerf *dev, uint8_t address, uint8_t val) { struct uart_cmd uc; struct bladerf_linux *backend = (struct bladerf_linux *)dev->backend; uc.addr = address; uc.data = val; return ioctl(backend->fd, BLADE_LMS_WRITE, &uc); }

C:\bladeRF-master\firmware_common
bladeRF.h

#define BLADE_LMS_WRITE _IOR(BLADERF_IOCTL_BASE, 20, unsigned int) #define BLADE_LMS_READ _IOR(BLADERF_IOCTL_BASE, 21, unsigned int)

It looks like BLADE_LMS_WRITE and BLADE_LMS_READ are defined here. In the interface to the USB-FX3-chip!! IOR = Input Output Request??

IOR/IOCTL

http://h30097.www3.hp.com/docs/dev_doc/DOCUMENTATION/HTML/DDK_R2/DOCS/HTML/MAN/MAN9/0028___R.HTM

NAME _IOR - General: Defines ioctl types for device control operations SYNOPSIS #include _IOR( g, n, t ); ARGUMENTS g Specifies the group that this ioctl type belongs to. This argument must be a nonnegative 8-bit number (that is, in the range 0-255 inclusive). You can pass the value zero (0) to this argument if a new ioctl group is not being defined. n Specifies the specific ioctl type within the group. These types should be sequentially assigned numbers for each different ioctl operation the driver supports. This argument must be a nonnegative 8-bit number (that is, in the range 0-255 inclusive). t Specifies the data structure size, which cannot exceed 128 bytes. You use this argument to size how much data is passed from the kernel back to the user application. The kernel determines the number of bytes to transfer by passing the value in this argument to the sizeof operator.

http://en.wikipedia.org/wiki/Ioctl

The ioctl system call first appeared in Version 7 of Unix under that name. It is supported by most Unix and Unix-like systems, including Linux and Mac OS X, though the available request 

codes differ from system to system. Microsoft Windows provides a similar function, named "DeviceIoControl", in its Win32 API.

…

For example, on Win32 systems, ioctl calls can communicate with USB devices, or they can discover drive-geometry information for attached storage-devices.

…

http://docs.python.org/2/library/fcntl.html

35.10. fcntl — The fcntl() and ioctl() system calls¶
This module performs file control and I/O control on file descriptors. It is an interface to the fcntl() and ioctl() Unix routines.

All functions in this module take a file descriptor fd as their first argument. This can be an integer file descriptor, such as returned by sys.stdin.fileno(), or a file object, such as 

sys.stdin itself, which provides a fileno() which returns a genuine file descriptor.
http://sourceforge.net/apps/trac/libusb-win32/wiki/libusbwin32_documentation

http://tali.admingilde.org/linux-docbook/usb/ch07s06.html

The ioctl() Requests
Chapter 7. The USB Filesystem (usbfs)  
The ioctl() Requests

http://www.ioctls.net/

IOCTL_USB_DIAGNOSTIC_MODE_OFF 0x220404 inc\api\usbioctl.h 
IOCTL_USB_DIAGNOSTIC_MODE_ON
0x220400 inc\api\usbioctl.h TheIOCTL_USB_DIAGNOSTIC_MODE_ONI/O control has been deprecated. Do not use.


...

IOCTL_USB_HCD_GET_STATS_1
0x2203fc inc\api\usbioctl.h TheIOCTL_USB_HCD_GET_STATS_1IOCTL has been deprecated. Do not use.
IOCTL_USB_HCD_GET_STATS_2
0x220428 inc\api\usbioctl.h TheIOCTL_USB_HCD_GET_STATS_2IOCTL has been deprecated. Do not use.
IOCTL_USB_HUB_CYCLE_PORT
0x220444 inc\api\usbioctl.h TheIOCTL_USB_HUB_CYCLE_PORTI/O control request power cycles the port that is associated with the PDO that receives the request.
IOCTL_USB_RESET_HUB
0x22044c inc\api\usbioctl.h TheIOCTL_USB_RESET_HUBIOCTL is used by the USB driver stack. Do not use.
IOCTL_USB_USER_REQUEST
0x220438 inc\api\usbuser.h Do not use this request.

Conclusion

I have to dig further in IOCTL and have a look at/in PYUSB. Somehow these two worlds should meet. I am sure the final Python-program to set the bandwidth will be remarkably simple! But I don't yet know how to do it. If there is any reader who knows the answer? Make a comment and I will be (almost eternally) grateful!

This is art. An artist put some stuff on a pillar,

paint it in nice bright colors and that's it! In 

Spain, Zarautz, in December 2012.