Sunday, October 13, 2013

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.

Sunday, September 29, 2013

BladeRF-python problem "ValueError: No backend available" solved and... python has no problems with bladeRF in USB3

Summary

I want to access the bladeRF-board from a Python-program. The simple program below returns an error. By changing the driver from libusbk to libusb-win32 I solved the problem and now I can also access the bladeRF-board from python using an USB3-port! However, the program bladeRF-cli still cannot access the bladeRF-board when plugged in an USB3-port.

Warning: somehow I screw up the layout, I did copy/paste from Word. I have to find out a better way.... Sorry

Running a simple python-program

The following simple python-program:


import usb.backend
import usb.legacy
import usb.core
import usb.util
import usb.control

# find our device
dev = usb.core.find(idVendor=0x1D50, idProduct=0x6066)

# was it found?
if dev is None:
    raise ValueError('Device not found')
else:
    print ('Device found')

    print 'len =', dev.bLength
    print 'bNumConfigurations =', dev.bNumConfigurations
    print 'bDeviceClass =', dev.bDeviceClass
    num = dev.idVendor
    num = "%#x"%(num)
    print 'idVendor = ', num
    #print 'idVendor = ', dev.idVendor
    num = dev.idProduct
    num = "%#x"%(num)
    print 'idProduct = ', num
    #print 'idProduct = ', dev.idProduct
    print 'bcdUSB = ', dev.bcdUSB
    print 'bcdDevice = ', dev.bcdDevice
    print 'iManufacturer = ', dev.iManufacturer
   
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
#dev.set_configuration(0)


Output:


Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>>

Traceback (most recent call last):
  File "C:\Users\lonneke\python\bladeRF01.py", line 9, in 
    dev = usb.core.find(idVendor=0x1D50, idProduct=0x6066)
  File "C:\Python27\lib\site-packages\usb\core.py", line 846, in find
    raise ValueError('No backend available')
ValueError: No backend available
>>> 

Trying to solve the problem with environment-variables


Changes to the environment-variables PATH and PYTHONPATH did not solve this problem.

Research on the Internet:


PyUSB should run on any platform with Python >= 2.4, ctypes and at least one of the supported builtin backends.

Do I have ctypes?
Yes: I found a directory C:\Python27\Lib\ctypes


I am using Python 2.6.5, libusb-win32-device.bin-0.1.12.1 and pyusb-1.0.0-a0 on a windows XP system and kept receiving ValueError: No backend available.
Since there wasn't any real help on the web for this problem I spent a lot of time finding that ctypes util.py uses the Path variable to find the library file. My path did not includewindows\system32 and PYUSB didn't find the library. I updated the path variable and now the USB is working.

NOTE: I use libusbk, NOT libusb-win32!!

Here is the libusb wiki:


USB 3.0 support

libusb 1.0 supports USB 3.0 controllers and devices on Windows, from 1.0.9 release onwards. Because of the large number of USB 3.0 controllers, the lack of official USB 3.0 support from Microsoft in Windows 7 and earlier as well as limited testing, be mindful that USB 3.0 support should be considered experimental. Also, if you are using a NEC/Renesas USB 3.0 controller, such as the fairly widespread uPD720200/uPD720200A, you please make sure that your controller drivers are ​version 2.1.16.0 or later. Older versions of the drivers have a bug that prevents access to USB devices when using libusb.

Install a different driver, replace libusbk by libusb-win32


Use zadig.exe to install a different driver, libusb-win32:








Now my bladeRF is a libusb-win32-device

Try bladeRF-cli

What about bladeRF-cli???
Microsoft Windows [versie 6.1.7601] 
Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden. 

C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -p 

Backend: libusb 
Serial: b436de8c8212b9aeaaeba852246866e7 
USB Bus: 2 
USB Address: 3 
C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -l hostedx115.rbf 
[INFO] Using libusb version 1.0.16.10774 
[INFO] Found a bladeRF 
[INFO] Claimed all inferfaces successfully 
[INFO] Change to alternate interface 2 
[INFO] Change to alternate interface 2 
Loading fpga... 
[INFO] Change to alternate interface 0 
[INFO] Change to alternate interface 1 
[INFO] Setting integer sample rate: 1000000 
[INFO] Found r value of: 4 
[INFO] MSx a + b/c: 316 + 4/5 
[INFO] MSx a + b/c: 316 + 4/5 
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5) 
[INFO] Calculated samplerate: 1000000 + 0/1 
[INFO] Set actual integer sample rate: 1000000 
[INFO] Setting integer sample rate: 1000000 
[INFO] Found r value of: 4 
[INFO] MSx a + b/c: 316 + 4/5 
[INFO] MSx a + b/c: 316 + 4/5 
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5) 
[INFO] Calculated samplerate: 1000000 + 0/1 
[INFO] Set actual integer sample rate: 1000000 
Done. 

C:\bladeRF-master\host\build\output\Debug> 
And all LEDs are blinking!!
 Try the python-program Now try the same python-program as above:
 

And the output is: 

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 
Type "copyright", "credits" or "license()" for more information. 
>>> ================================ RESTART ================================ 
>>> 
Device found 
len = 18 
bNumConfigurations = 1 
bDeviceClass = 0 
idVendor = 0x1d50 
idProduct = 0x6066 
bcdUSB = 528 
bcdDevice = 0 
iManufacturer = 1 
>>> 

Now try USB3 instead of USB2 with bladeRF-cli

But what about plug bladeRF in an USB3-port with this driver?
BladeRF in USB2-port:


Microsoft Windows [versie 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden.
C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -l hostedx115.rbf
[INFO] Using libusb version 1.0.16.10774
[INFO] Found a bladeRF
[INFO] Claimed all inferfaces successfully
[INFO] Change to alternate interface 2
[INFO] Change to alternate interface 2
Loading fpga...
[INFO] Change to alternate interface 0
[INFO] Change to alternate interface 1
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
Done.
C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -p
Backend:        libusb
Serial:         b436de8c8212b9aeaaeba852246866e7
USB Bus:        2
USB Address:    3

Now unplug and plug in USB3-port:


C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -l hostedx115.rbf
[INFO] Using libusb version 1.0.16.10774
[ERROR] No devices available on the libusb backend.
Failed to open device (NULL): No devices available
Could not open device

bladeRF-cli cannot handle the USB3-port on my laptop.
Unplug and replug in USB2-port:


C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -l hostedx115.rbf
[INFO] Using libusb version 1.0.16.10774
[INFO] Found a bladeRF
[INFO] Claimed all inferfaces successfully
[INFO] Change to alternate interface 2
[INFO] Change to alternate interface 2
Loading fpga...
[INFO] Change to alternate interface 0
[INFO] Change to alternate interface 1
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
Done.

C:\bladeRF-master\host\build\output\Debug>

Now try USB3 instead of USB2 with bladeRF-cli

And what about python?
First bladeRF in USB2-port:
Run python-program. 
Output:
>>>
Device found
len = 18
bNumConfigurations = 1
bDeviceClass = 0
idVendor =  0x1d50
idProduct =  0x6066
bcdUSB =  528
bcdDevice =  0
iManufacturer =  1
Now unplug and put in USB3-slot:
>>> ================================ RESTART ================================
>>>
Device found
len = 18
bNumConfigurations = 1
bDeviceClass = 0
idVendor =  0x1d50
idProduct =  0x6066
bcdUSB =  768
bcdDevice =  0
iManufacturer =  1
>>> 

Conclusion

YES!!
Python has no problems with USB3 on my laptop!!
The program bladeRF-cli cannot access the bladeRF-board from USB3, so I cannot flash the
FPGA. I should be able to do that from python in this situation. But how?
Anyway, with bladeRF plugged in an USB2-port I can solve this problem for the moment.
December 2012 in Spain, Santiago.
View on the world from within our caravan.
This weather is perfect for programming but
not so pleasant for a long walk with our dog...


Friday, September 27, 2013

At last: my bladeRF is up and running on my laptop in Windows 7

Finally, I succeeded in getting my bladeRF into life! It was alive a long time ago, i.e. it showed a green LED when powered up by USB. It did not mind USB2 of USB3, the LED was on.

But seen from the laptop there was not much life.

At nuand.com there was new software. First there was a https://github.com/nuand/bladerf/wiki with some info to get the beast alive in Windows. And now there is new software at github. Look for the 'host' directory (https://github.com/Nuand/bladeRF/tree/master/host).

I used cmake to make a project-file for Visual Studio. In Visual Studio I found a button 'build all'. And that was about it. Soo simple!!

In the meantime my bladeRF thought it was a 'West-Bridge'. I solved that problem using the recover-function of bladeRF-cli:

I downloaded the latest 1.2 FX3 image and renamed it to latest.img

C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -i
[INFO] Using libusb version 1.0.16.10774
[WARNING] Found FX3 bootloader device libusb:device=2:7, could be bladeRF.
[WARNING] Use "recover libusb:device=2:7 <FX3 firmware>" to boot bladeRF.
[ERROR] No devices available on the libusb backend.
Failed to open device (NULL): No devices available
Could not open device
bladeRF> recover libusb:device=2:7 latest.img
[INFO] Device: 2:7
[INFO] Attempting load with file latest.img
[INFO] open firmware image latest.img for RAM upload
[INFO] normal FW binary executable image with checksum
[INFO] FX3 bootloader version: 0x000000A9
[INFO] writing image...
[INFO] transfer execution to Program Entry at 0x40013818
Loaded! An open is now required
bladeRF> open
[INFO] Using libusb version 1.0.16.10774
[INFO] Found a bladeRF
[INFO] Claimed all inferfaces successfully
[INFO] Change to alternate interface 2
[INFO] Change to alternate interface 2
bladeRF> exit

At this point you have to remove power and reapply power again. So, unplug and plug in again.

C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -p

    Backend:        libusb
    Serial:         b436de8c8212b9aeaaeba852246866e7
    USB Bus:        2
    USB Address:    7

I did not know which FPGA-file to take. I simply downloaded the latest one. 

C:\bladeRF-master\host\build\output\Debug>bladeRF-cli -l hostedx115.rbf
[INFO] Using libusb version 1.0.16.10774
[INFO] Found a bladeRF
[INFO] Claimed all inferfaces successfully
[INFO] Change to alternate interface 2
[INFO] Change to alternate interface 2
Loading fpga...
[INFO] Change to alternate interface 0
[INFO] Change to alternate interface 1
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
[INFO] Setting integer sample rate: 1000000
[INFO] Found r value of: 4
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx a + b/c: 316 + 4/5
[INFO] MSx P1: 0x00009c66 (40038) P2: 0x00000002 (2) P3: 0x00000005 (5)
[INFO] Calculated samplerate: 1000000 + 0/1
[INFO] Set actual integer sample rate: 1000000
Done.

C:\bladeRF-master\host\build\output\Debug>


Some issues

There is a problem with USB3. My bladeRF does not function in the USB3 slot. However in the USB2 slot it is OK. I have a Renesas Electronics USB 3.0 host controller and hub. I'll send nuand an email about this issue. It was mentioned by them as a problem.

I had a Python-program that could 'see' the bladeRF. Now it barks that it cannot find the backend. I have to solve that problem.

I still have a problem with GNUradio in Windows. The waterfall-display is frozen. It is a problem with openGL I think.

I want to use my bladeRF to decode GPS-signals (please don't tell me there are cheaper solutions with SIRF III chips etc. I know!). So I need to connect a GPS-antenna. I have one, an active antenne. Active means that I have to become active to build something to feed the antenna with DC over the same line that carries the sub-micro-volts of GNSS-info. It is called phantom-supply.

I need a protective case to protect the bladeRF to the real world of metal things on my desk. Elektor sells a project case, that might be a solution.

Future steps

I want a program written in Python to access the bladeRF. So, I will have to write an FX3-program too and I will have to build some VHDL-code. In the past I did some experiments with a java-program to access an SDR-board. I'll dig up that attempts and build upon that.


This picture was taken in March this year in
Castrojeriz, Spain while we were on vacation.

I love cats. My wife loves cats. And our dog loves
cats too, but in a different manner...



Wednesday, September 11, 2013

bladeRF, too many options for building the software?

To control the bladeRF-board you have to deal with two  areas:
·         Outside of the bladeRF-board is a system with Windows or linux
·         Inside the bladeRF-board there are two sub-systems:
o   The FX3 Cypress USB subsystem to be programmed in C
there is a non-volatile flash-memory for an initial program
o   The FPGA subsystem to be programmed in VHDL or Verilog
the FPGA is empty at startup, so has to be loaded to perform its virtual hardware function

To use the bladeRF you have to boot the whole system:
1.       The outside system: a laptop, a PC or perhaps a Raspberry Pi connected by USB3 to the bladeRF
2.       The bladeRF has a flash memory with the software for the FX3 USB subsystem
3.       The bladeRF gets a new FX3 program
4.       The bladeRF gets a fresh FPGA image
5.       From now on the bladeRF is able to communicate with the controlling program: bladerf.cli
the bladeRF command line interpreter

·         The bladeRF-board has a JTAG-interface-connector. So it is possible to program the FPGA more or less independent form the remaining hardware.
·         With a suitable program in the FX3-USB-Cypres-chip, the programming of the FPGA can be done without the JTAG-interface, directly from the FX3-chip.
·         On the outside of the board is the bladeRF.cli. This program takes care of loading the FX3-program and the program for the FPGA.

‘Everybody’ seems to use linux for the outside system. So, may be it is better for me to follow the crowd if I want support and results.

To connect the bladeRF to a Windows system there are in fact two possibilities:
1.       Use the Cypress FX3 system with the wizard that generates the INF-file. From then on you can use the FX3-Cypres diagnostic tools to load programs
2.       Use the libusb-system. There seem to be a few flavors of that. Anyway version 0.1 or 1.0. The Zadig software seems to be a keystone for success.

Whether linux or Windows the bladeRF-board can be controlled by a program written in java, python or C. The bladeRF.cli is written in C.

There is also gnu radio, either in Windows or in linux. There is a module, OsmoSDR, that can be used to connect a bladeRF-board.

The above ramblings are sort of start-point-issues.

Now about my dream, my ultimate goal, my ultimate process:

I want to understand GNSS (Global Navigation Satellite Systems) by building a GPS-receiver. Perhaps also a GPS-simulator or a GPS-spoofer. In the past I did some experiments, programming in java, with a file with a few minutes GPS-signal from a wideband receiver. I built a function to read the samples. I built a correlator and could ‘see’ the satellites. I built a phase-locked-loop and got stuck in this very PLL. I did not manage to get the loop stable, but did  manage to recover some almanac-data.

For me, it is not the end-result that counts, but the process itself. By doing, experimenting, programming, testing, debugging and reading I get a deep understanding of GNSS’s. Furthermore a system containing an RF-subsystem, an FPGA and an FX3—USB-system controlled by a program on a laptop is really fascinating. A high level language like python, the C-program in the FX3-chip and VHDL on an FPGA. This is a piece of hardware that should be able to do anything you can imagine. Cognitive radio for example. Combined with an inertial system and Kalman filtering one can do miracles with GNSS. The boys and girls of Pentex have the real stuff! But the bladeRF-board is such a marvelous piece of hardware!

I am very confused which route to take:
·         I have a laptop, an old but usable one, I could replace Windows and put genuine Ubuntu on it.
·         I might try to solve the  Windows gnuradio opengl problem and go for the gnuradio solution
·         I might stubbornly stay with Windows and python
·         I might try to go on with Ubuntu in VMware under Windows 7 professional (64 bit)


So far I tried almost everything a little bit, but I don’t yet know which route to take!


a painting, a reproduction, whatever?
This beautiful picture we found in VilaCha, Portugal.

Wednesday, August 28, 2013

bladeRF board talks back (more or less) to a python program

I installed libusb0 (libusb-win32). With inf-wizard I managed to make the bladeRF board visible to Windows. When I connect the device I have a libusb-board called bladeRF!




The problem is, however, that libusb0.sys is a libusb 0.1 implementation.

Well, let's see if can find this device with a Python-program:
I found this snippet on the big Internet. Wish I saved the URL to give credit to the programmer!

#!/usr/bin/env python

import usb

for bus in usb.busses():
  for dev in bus.devices:
    print "Bus %s Device %s: ID %04x:%04x %s" % (bus.dirname,dev.filename,dev.idVendor,dev.idProduct,dev.open().getString(1,30))

The output:

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
Bus  Device : ID 1d50:6066 Nuand
>>> 

This is encouraging!

From a USB-tutorial I copied:

# import usb.backend
# import usb.legacy
import usb.core
# import usb.util
# import usb.control


# find our device
dev = usb.core.find(idVendor=0x1D50, idProduct=0x6066)

# was it found?
if dev is None:
    raise ValueError('Device not found')
else:
    print ('Device found')

    print 'len =', dev.bLength
    print 'bNumConfigurations =', dev.bNumConfigurations
    print 'bDeviceClass =', dev.bDeviceClass
    num = dev.idVendor
    num = "%#x"%(num)
    print 'idVendor = ', num
    #print 'idVendor = ', dev.idVendor
    num = dev.idProduct
    num = "%#x"%(num)
    print 'idProduct = ', num
    #print 'idProduct = ', dev.idProduct
    print 'bcdUSB = ', dev.bcdUSB
    print 'bcdDevice = ', dev.bcdDevice
    print 'iManufacturer = ', dev.iManufacturer
    
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
#dev.set_configuration(0)

And the output:

>>> 
Device found
len = 18
bNumConfigurations = 1
bDeviceClass = 0
idVendor =  0x1d50
idProduct =  0x6066
bcdUSB =  768
bcdDevice =  0
iManufacturer =  1

Traceback (most recent call last):
  File "C:\Users\lonneke\python\bladeRF01.py", line 34, in <module>
    dev.set_configuration()
  File "C:\Python27\lib\site-packages\usb\core.py", line 547, in set_configuration
    self._ctx.managed_set_configuration(self, configuration)
  File "C:\Python27\lib\site-packages\usb\core.py", line 92, in managed_set_configuration
    self.backend.set_configuration(self.handle, cfg.bConfigurationValue)
  File "C:\Python27\lib\site-packages\usb\backend\libusb01.py", line 437, in set_configuration
    _check(_lib.usb_set_configuration(dev_handle, config_value))
  File "C:\Python27\lib\site-packages\usb\backend\libusb01.py", line 384, in _check
    raise USBError(errmsg, ret)
USBError: [Errno None] libusb0-dll:err [set_configuration] could not set config 1: win error: De parameter is onjuist.


>>> 

The problem seems to be that dev.set_configuration() needs an argument.

I think I have a version problem. I have libusb 0.1 on my Windows system.

I googled a lot and found a lot. The right search-arguments are: "libusb pyusb winusb".
In fact WinUSB is what I was looking for.

Then I found zadig:


I experimented with their zadig.exe
I hope I did not do something very stupid!
You can install WinUSB and also libusbK with that program.

My little python-program did not see the bladeRF board anymore. Luckily I could reinstall the old driver and try again.

This libusb 0.1 1.0 issue is very confusing. There is also a libusbK.
I just want to use PyUSB with my bladeRF board and probably need libusb1.0 for that?
I read something about legacy, backend, etc. A lot to study, I am afraid.

Perhaps now is the time to formulate a question in the bladerf forum...


In VilaCha, Portugal, there is a marvelous small pub
where you can drink and eat typical Portuguese food.
We have been there in February, 2013 and surely will return.
If you drive along, you can't miss this pirate!





Sunday, August 25, 2013

BladeRF board finally visible somehow, but I will go for python, libusb, Windows

If you want to connect a USB-device in VMWare to a program running in the OS under VMWare you have to tell VMWare what you want!

So, plug-in your USB-device and window will recognize your USB-plugged-in device. Windows will try to find a driver. The USB-device shows up finally in the list of connected hardware devices, with or without an error-message (a yellowish exclamation point)

Now comes the trick:

Start VMWare with your favorite OS, linux-Ubuntu in my case. Then, in VMWare find the settings for your virtual OS. You will find a list, click USB-devices. There you will see your USB-device. In my case BladeRF. The device is connected to the host. Just say YOU want the device and it will be connected to linux!!! Click again and it will be reconnected to the host!

In my case linux is not aware of the device. It does not show up in /dev, and bladerf-cli does not see the device, not in probe, neither in print. It is still possible that this is simply a linux-problem that I might be able solve with the help of the community.

Now for the bad news:

Of course I searched the internet for this problem and I found out that VMWare has problems with USB3.0 devices!

I found:

"
Now in order to get Intel USB 3.0 Passthrough working with VMware Workstation 9 in Windows 7, make sure that you are running·         VMware Workstation Version 9.0.1 with Build Number 894247 OR HIGHER·         Intel USB 3.0 xHCI Drivers – version 1.0.6.245 OR HIGHERAlso make sure that you have installed Intel USB 3.0 Controller and USB 3.0 Root Hub Drivers using “Device Manager” GUI and NOT USING the installable Binary Package version 1.0.6.245 (SETUP.exe).
"
I did plug the bladeRF-board in a USB 2.0 port and also tried to disable USB3.0 support. I just tried about everything I could think of. But I want genuine USB3-support, not crippled USB2.
Connect bladeRF into a USB3.0 port. In VMWare Player -> removable decices ->  OpenMoko bladeRF -> Connect (disconnect from host)
After a few seconds I see an error message in a box lower-right “The connection for the USB device “OpenMoko bladeRF” was unsuccessful”. Driver error.
I don’t know if this is a message from Ubuntu or VMWare????

Well, the last few days I went for a 'quick' way to play with my bladeRF board. So, I diverted to linux under VMWare. But, I am afraid that is the wrong way.

 If you need a machine to make holes in a wall you need an electric drill. I you want to turn screws in the wall you might buy an electric screwdriver. But DO NOT buy a universal solution because that is always a compromise. Anyway that is what my daddy taught me.

 So now I have to make a choice. Either go for genuine linux (perhaps multiboot or boot from a USB-stick or CD) or go for genuine Windows. I have a spare laptop, I could install genuine linux on that laptop but then I have to take with me (a lot of travelling abroad)  two laptops (one Windows (my wife, you know) and one linux). No, too much hassle. I will go for Windows.


  1. I am used to Windows, my Sony VAIO is powerful enough to run Windows 7 prof.
  2. I still have a lot of space on my harddisk.
  3. Quartos runs perfectly.
  4. The python implementation works flawlessly.
  5. Gnuradio works (almost) perfectly (a problem with OPENGL that I will solve later)
  6. Windows can handle the USB3-port that will be used for the bladeRF
  7. I have some experience with an SDRboarSDR4000 from DSPTools, this board has a very big FPGA that is not supported by the free ISE-WEBPACK-software from Xilinx. I accessed this board with a java-program but my Xilinx-license expired ;>((
  8. Because I am retired, the Mathwork is not longer interested in me, so I cannot use MATLAB anymore (OK, 100 euro I am willing to pay for software for my hobby, but $2000, noway!)
  9. I started to fall in love with Python.
Conclusion:
  1. From now on I will use Python whenever possible (but I will use C, java or whatever is necessary)
  2. I will go for libusb
  3. I will stick to Windows for developing my GPS-sofware for the bladeRF board
  4. I will always have the bladeRF board with me in my laptop-case   ;>)))



This is not me, by the way, but it demonstrates my
feelings about the sofware problems I encounter...