Running "make INTERACTIVE=n" gives me this output:

mkdir -p bin
make -C src/cli \
        BIN_DIR="/home/cyrozap/bladeRF/linux/apps/bin" CFLAGS="-Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE   -O2 -DNDEBUG" LDFLAGS="-lbladeRF  " INTERACTIVE="n"
make[1]: Entering directory `/home/cyrozap/bladeRF/linux/apps/src/cli'
cc common.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE   -O2 -DNDEBUG -Icmd -Iinteractive -I. -pthread -c -o common.o
cc main.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE   -O2 -DNDEBUG -Icmd -Iinteractive -I. -pthread -c -o main.o
main.c:318:54: error: macro "interactive" passed 2 arguments, but takes just 1
main.c: In function ‘main’:
main.c:318: error: ‘interactive’ undeclared (first use in this function)
main.c:318: error: (Each undeclared identifier is reported only once
main.c:318: error: for each function it appears in.)
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/home/cyrozap/bladeRF/linux/apps/src/cli'
make: *** [bin/cli] Error 2

The device doesn't show up in /dev when running kernel 3.2 (Comes with ubuntu 12.0.4 LTS)

Work around is simple use 3.5+

If using Ubuntu 12.04 LTS http://askubuntu.com/questions/257617/how-can-i-upgrade-the-ubuntu-12-04-2-kernel-to-3-5-0-23

This appears to return bytes, rather than # of IQ pairs sent, which contradicts the interface defined in libbladeRF.h.

For, example I'd expect the following to return 1024. However, it will return 4096:
ssize_t len = bladerf_read_c16(this->dev, buf, 1024);

Should the return value or the interface change? FWIW, I vote this returning 1024, so the units of the parameters and the return value are consistent.

On a similar note, it might be worth noting in the doxygen comments that the _c16 function deal with a pair of 16-bit IQ values, not 16-bits total... I suppose it might be clear, but that has potential to snag someone.

After setting a samplerate of 2MHz, the clock going to the LMS is 4MHz (correct) but the total number of samples delivered to the host system is only 1Msps. Samples appear to be disappearing between the FPGA and FX3 when in HS mode at a rate of very close to 1/2 the samples being dropped.

Hi,

I have 2 boards connected to my system, 1 being driven by osmocom_fft and the other by siggen. Seconds into the experience my system crashes and when I recover my syslog contains the trace below.

The driver I am running was all built yesterday.

Regards

Paul

Aug 21 17:43:47 Z820 kernel: [33464.603045] ------------[ cut here ]------------
Aug 21 17:43:47 Z820 kernel: [33464.603061] WARNING: at /build/buildd/linux-3.8.0/kernel/watchdog.c:246 watchdog_overflow_callback+0x9c/0xd0()
Aug 21 17:43:47 Z820 kernel: [33464.603065] Hardware name: HP Z820 Workstation
Aug 21 17:43:47 Z820 kernel: [33464.603067] Watchdog detected hard LOCKUP on cpu 4
Aug 21 17:43:47 Z820 kernel: [33464.603069] Modules linked in: nfnetlink_log(F) nfnetlink(F) r8712u(C) binfmt_misc(F) nls_utf8 hfsplus snd_hda_codec_hdmi coretemp kvm ghash_clmulni_intel(F) aesni_intel(F) aes_x86_64(F) xts(F) lrw(F) gf128mul(F) ablk_helper(F) cryptd(F) gpio_ich hp_wmi sparse_keymap parport_pc(F) microcode(F) ppdev(F) psmouse(F) serio_raw(F) sb_edac edac_core bnep rfcomm bluetooth snd_hda_codec_realtek nvidia(POF) lpc_ich snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F) snd_hda_intel snd_hda_codec snd_hwdep(F) snd_pcm(F) mei snd_page_alloc(F) snd_seq(F) snd_seq_device(F) snd_timer(F) snd(F) soundcore(F) wmi mac_hid nls_iso8859_1(F) bladeRF(OF) lp(F) parport(F) hid_generic usbhid hid usb_storage(F) firewire_ohci firewire_core crc_itu_t(F) ahci(F) libahci(F) e1000e(F) isci libsas(F) mpt2sas raid_class(F) scsi_transport_sas(F)
Aug 21 17:43:47 Z820 kernel: [33464.603152] Pid: 27025, comm: osmocom_siggen Tainted: PF C O 3.8.0-27-generic #40-Ubuntu
Aug 21 17:43:47 Z820 kernel: [33464.603155] Call Trace:
Aug 21 17:43:47 Z820 kernel: [33464.603157] [] warn_slowpath_common+0x7f/0xc0
Aug 21 17:43:47 Z820 kernel: [33464.603171] [] warn_slowpath_fmt+0x4c/0x50
Aug 21 17:43:47 Z820 kernel: [33464.603178] [] ? sched_clock_cpu+0xbd/0x110
Aug 21 17:43:47 Z820 kernel: [33464.603183] [] ? touch_nmi_watchdog+0x80/0x80
Aug 21 17:43:47 Z820 kernel: [33464.603188] [] watchdog_overflow_callback+0x9c/0xd0
Aug 21 17:43:47 Z820 kernel: [33464.603197] [] __perf_event_overflow+0x9d/0x230
Aug 21 17:43:47 Z820 kernel: [33464.603206] [] ? x86_perf_event_set_period+0xd7/0x160
Aug 21 17:43:47 Z820 kernel: [33464.603211] [] perf_event_overflow+0x14/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603221] [] intel_pmu_handle_irq+0x1ab/0x330
Aug 21 17:43:47 Z820 kernel: [33464.603229] [] perf_event_nmi_handler+0x1d/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603234] [] nmi_handle.isra.0+0x59/0x90
Aug 21 17:43:47 Z820 kernel: [33464.603238] [] do_nmi+0xe0/0x360
Aug 21 17:43:47 Z820 kernel: [33464.603244] [] end_repeat_nmi+0x1e/0x2e
Aug 21 17:43:47 Z820 kernel: [33464.603253] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603258] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603264] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603267] <> [] default_spin_lock_flags+0x9/0x10
Aug 21 17:43:47 Z820 kernel: [33464.603277] [] _raw_spin_lock_irqsave+0x2e/0x40
Aug 21 17:43:47 Z820 kernel: [33464.603286] [] bladerf_write+0x18d/0x300 [bladeRF]
Aug 21 17:43:47 Z820 kernel: [33464.603293] [] ? apparmor_file_permission+0x18/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603303] [] ? security_file_permission+0x2c/0xb0
Aug 21 17:43:47 Z820 kernel: [33464.603311] [] vfs_write+0xac/0x180
Aug 21 17:43:47 Z820 kernel: [33464.603315] [] sys_write+0x52/0xa0
Aug 21 17:43:47 Z820 kernel: [33464.603321] [] system_call_fastpath+0x1a/0x1f
Aug 21 17:43:47 Z820 kernel: [33464.603324] ---[ end trace 1031a883afd2f9ce ]---

TO DO - correct the implementation of host/cmake/modules/Version.cmake to only append -dirty when the git repo is not in a clean state.

TODO item

Intended to allow a user to execute a single command and exit.

For rx/tx commands this will require waiting until the command completes. (This is a similar requirement for scripting support, when 'rx start' is at the end of a script)

The FPGA design contains a asynchronous reset, which is fine. However the reset release (ie falling edge) is also asynchronous. This may result in different parts of the design leaving reset. A reset controller should created to provide a synchronous reset release.

Currently we have dbg_printf compile-time printfs. A more desirable approach would be to have healthy set of logging routines, and a configurable log-level.

int bladerf_log(level, ...);
int bladerf_set_log_verbosity(level);

int bladerf_set_log_output(FILE ); / Optional */

On my TODO list after higher priority items.

To reproduce:

tx config file=/dev/urandom format=csv
tx start

The pointer increments for buffers is wrong

    i = read(dev->fd, samples + bytes_read, bytes_total - bytes_read);

I think it should be something like.

    i = read(dev->fd, samples + bytes_read/sizeof(int16_t), bytes_total - bytes_read);

In routines like bladerf_enable_module() we need to ensure there's a default case in the switch statement that returns BLADERF_ERR_INVAL. This would help users catch things like uninitialized values being passed to these routines.

115KLE FPGA is reported as a 40KLE. This is due to a typo in bladerf_priv.c

Find the patch here-below

diff --git a/host/libraries/libbladeRF/src/bladerf_priv.c b/host/libraries/libbladeRF/src/bladerf_priv.c
index 727b870..f371120 100644
--- a/host/libraries/libbladeRF/src/bladerf_priv.c
+++ b/host/libraries/libbladeRF/src/bladerf_priv.c
@@ -295,7 +295,7 @@ int bladerf_get_and_cache_fpga_size(struct bladerf *device)
     if (!strcmp("40", tmp)) {
         device->fpga_size = BLADERF_FPGA_40KLE;
     } else if(!strcmp("115", tmp)) {
-        device->fpga_size = BLADERF_FPGA_40KLE;
+        device->fpga_size = BLADERF_FPGA_115KLE;
     } else {
         device->fpga_size = BLADERF_FPGA_UNKNOWN;
     }

lms_lpf_enable doesn't change the enable bit unless you're changing bandwidth, when calling it after lms_lpf_disable you have to specify something other than 28Mhz for the call to work.

proposed fix

// When enabling an LPF, we must select both the module and the filter bandwidth
void lms_lpf_enable( struct bladerf *dev, lms_module_t mod, lms_bw_t bw )
{
    uint8_t reg = (mod == RX) ? 0x54 : 0x34 ;
    uint8_t data ;
    // Check to see which bandwidth we have selected
    lms_spi_read( dev, reg, &data ) ;
    data |= (1<<1) ;
    if( (lms_bw_t)(data&0x3c>>2) != bw )
    {
        data &= ~0x3c ;
        data |= (bw<<2) ;
    }
    lms_spi_write( dev, reg, data ) ;
    // Check to see if we are bypassed
    lms_spi_read( dev, reg+1, &data ) ;
    if( data&(1<<6) )
    {
        data &= ~(1<<6) ;
        lms_spi_write( dev, reg+1, data ) ;
    }
    return ;
}

This is sorely out of date.

I'd volunteer to update it if someone could let me know what content should be in there.

I know there had been some discussion about developing a docs/ full of multimarkdown-based documentation. So perhaps the top-level README should just provide info on where in the tree to find everything, point the website, git repo, issue tracker, forum, site, etc?

It is unclear if the warnings and timing errors are mistake on my part when building the image, or if there are problems in the HDL.

7 critical warnings shown below:

Critical Warning (169085): No exact pin location assignment(s) for 1 pins of 139 total pins
Info (169086): Pin fx3_ctl[9] not assigned to an exact location on the device
Info (169086): Pin fx3_ctl[9] not assigned to an exact location on the device
Critical Warning (332012): Synopsys Design Constraints File file not found: '../../fpga/platforms/bladerf/constraints/bladerf.vhd'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.
Critical Warning (332012): Synopsys Design Constraints File file not found: '../../fpga/platforms/bladerf/constraints/bladerf.vhd'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.

In Linux (haven't tested on other OSs), if libncurses is not installed, the build process will fail as the library is unavailable to link against. First, I'm not sure that this library is necessary to begin with on Linux, as I was able to build libtecla support previously without it. Second, if it is necessary, it should be detected during the cmake process rather than during the make process.

UPDATE: I verified that removing the ncurses library dependency from the CMakeLists still allows the CLI to build fine without libncurses present. Thus, I don't believe this dependency is required for linux.

"With great powers comes great responsibility". Running in kernel space is a bit like that :)

For example this snippet : (there is actually the same kind of safety issue in various forms at various places)

        if (copy_from_user(&brf_fw, data, sizeof(struct bladeRF_firmware))) {
            return -EFAULT;
        }

        fw_buf = kzalloc(256, GFP_KERNEL);
        if (!fw_buf)
            return -EINVAL;
        memset(fw_buf, 0xff, 256);

        if (copy_from_user(fw_buf, brf_fw.ptr, brf_fw.len)) {
            retval = -EFAULT;
            kfree(fw_buf);
            break;
        }

The brf_fw.len can't be trusted ... it comes from userspace and you use it for a memcpy into a kernel buffer of fixed space. So userspace can overrun it and do bad things.

Everything coming from userspace must be checked and not trusted.

You should also not assume anything about the device, someone could impersonate the bladeRF IDs and trigger bad driver behavior to compromise the machine. For eg:

        sz = 0;
        if (dev->udev->speed == USB_SPEED_HIGH) {
            sz = 64;
        } else if (dev->udev->speed == USB_SPEED_SUPER) {
            sz = 256;
        }

What about the other speed ? Like if the device pretended to be low speed, sz=0 and the code doesn't return -EINVAL or -EFAULT, it just continues with a bad size.

• Replace lib_ and gpio_calls with appropriately named routines that perform a specific function (e.g., bladerf_enable_tx(bool enable))
• Query device state and initialize device in bladerf_open(). (Alleviate the need for the app-code caller to be configuring mandatory LMS registers.)
• Provide sane bitmask definitions for any register access interfaces.

See http://pastebin.com/AsBhyky3

Not sure why/how it happened, but it should just not be possible. Looks like missing locking somewhere / bad concurrency / race ...

Result was that USB became unusable and the process accessing the bladrf was left unkillable, using 100% of CPU. So just had to reboot ...

Provide the ability to call scripts from the console (or from within other scripts) -- this will allow module little scripts to be created and reused.

Currently in the works, will finish up and commit after some higher priority items.

When I run the osmosdr-siggen program it appears to properly configure the FPGA and lime chip for the Carrier requested in the GUI. The TX Gain adjusts seems to be working as well. But I can't seem to get samples into the modulator.
my /dev/bladerf0 file is mode 666

running osmosdr-siggen
user@host $ ./osmosdr-siggen

In the console I get:
Failed to write samples: provided parameters where out of allowable range.

When I change the carrier frequency, the bladeRF responses. On my spectrum analyzer I can see the TX carrier (LO leakage) move.

But can't get any samples though...

Stopping the osmosdr-siggen causes the LO on the lime chip to disappear. Chip deactivate, as expected result.

Sometimes after running it and start osmosdr-siggen up again.
I get the dreaded "Bladerf_enable_module has returned with -6"

Which I think means the board got stuck..
Doesn't go away until I power cycle the bladeRF.

I am using the lastest bladeRF GIT (as of 8/2/2013 00:53:00 UTC ) and the latest osmosdr git head.
Running ubuntu-13.04 linux-3.8 kernel.

Currently this defaults to ON, forcing Windows users to manually disable it to get the build working.

See the swap when comparing the results of bladeRF-cli's "probe" command to lsusb.

Basically I/Q are registred but the IQSel signal is used as if they were not and so I/Q get mixed across sample.

rf_rx_fifo_w <= not lms_rx_iq_select;

Solution would be to either to register lms_rx_iq_select, or simply not to invert it since that signal is just 0/1/0/1/...

Software workaround is to inverse polarity of IQSel in LMS 0x5a ...

After programming the FPGA and setting the GPIO bits to 0x57, using the CLI to do:

peek lms 0 0x80

The end of the register list will say:

Error: An unexpected error occurred

This error corresponds to an unchecked else statement in the kernel which indicates the device write has timed out.

Forgetting this will cause issues in Windows-land. (This is a TO DO item for this evening).

09:37 < Bzzt_Ploink> one more minor fix static  void LIBUSB_CALL 
                     lusb_stream_cb(struct libusb_transfer *transfer) needs 
                     that LIBUSB_CALL there to switch to stdcall instead of the 
                     cdecl standard

TODO item

Remove -b and make "batch mode" the default. Require user to add -i to drop into interactive mode.

TODO - check state->curr_device in printset.c and return a less cryptic error.

In order for the timing analysis to correct determine if the FPGA design meets timing, all inputs and output should be constrained. Altera also recommends using virtual clocks to drive IO constraints, not pin clocks.

A number of the print arguments remain stubs (e.g., lmsregs).

Let's use this thread to aggregate a list of unimplemented items and either get them implemented or remove them for the time being.

Please submit patches against the dev-libusb_support branch, as this is further along and will soon be getting merged back into mainline.

Setting the same interface twice in a row will cause the FX3 to be unresponsive due to the FX3 trying to setup the same DMA channel a second time.

The firmware needs to check if we're trying to set the same interface twice in a row.

Use the CLI to automate loading the FPGA via udev rules. Someone wrote a blog about it.

The following items will need to be fixed/replaced for portability:

• stdbool.h not supported in msvc
• C99 not supported in MSVC: Switch to -std=c89 and remove dependencies upon -D_GNU_SOURCE
• Named initializers not supported in MSVC

root@ubuntu:/bladeRF/linux/apps# make
Package libbladeRF was not found in the pkg-config search path.
Perhaps you should add the directory containing libbladeRF.pc' to the PKG_CONFIG_PATH environment variable No package 'libbladeRF' found Package libbladeRF was not found in the pkg-config search path. Perhaps you should add the directory containinglibbladeRF.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libbladeRF' found
mkdir -p bin
make -C src/cli
BIN_DIR="/home/geek/bladeRF/linux/apps/bin" CFLAGS="-Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG" LDFLAGS="" INTERACTIVE=""
make[1]: Entering directory /home/geek/bladeRF/linux/apps/src/cli' cc common.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG -Icmd -Iinteractive -I. -DINTERACTIVE -c -o common.o In file included from cmd/cmd.h:5:0, from common.c:4: ./common.h:4:24: fatal error: libbladeRF.h: No such file or directory compilation terminated. make[1]: *** [common.o] Error 1 make[1]: Leaving directory/home/geek/bladeRF/linux/apps/src/cli'
make: *** [bin/cli] Error 2
root@ubuntu:/bladeRF/linux/apps# exit

root@ubuntu:~/bladeRF/linux/apps# uname -a
Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Attempting to load the FPGA code within Fedora 19 fails:

[bharrington@leviathan bladeRF]$ bladeRF-cli -p

    Backend:        libusb
    Serial:         
    USB Bus:        4
    USB Address:    12

[bharrington@leviathan bladeRF]$ bladeRF-cli -l ~/Downloads/hostedx40.rbf 
INFO - Found a bladeRF
INFO - Claimed all inferfaces successfully
Loading fpga...
INFO - Change to alternate interface 0
INFO - Change to alternate interface 1
Done.
[bharrington@leviathan bladeRF]$ 
[bharrington@leviathan bladeRF]$ 
[bharrington@leviathan bladeRF]$ bladeRF-cli -p

    Backend:        libusb
    Serial:         
    USB Bus:        4
    USB Address:    12

[bharrington@leviathan bladeRF]$ bladeRF-cli -l ~/Downloads/hostedx40.rbf 
INFO - Found a bladeRF
INFO - Claimed all inferfaces successfully
INFO - Change to alternate interface 1
INFO - Changed into RF link mode: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
Loading fpga...
INFO - FPGA is already loaded -- reloading.
INFO - Change to alternate interface 0
INFO - Change to alternate interface 1
Done.
[bharrington@leviathan bladeRF]$ bladeRF-cli -p

    Backend:        libusb
    Serial:         
    USB Bus:        4
    USB Address:    12

[bharrington@leviathan bladeRF]$ rpm -qa libusbx libusbx-devel
libusbx-1.0.16-3.fc19.x86_64
libusbx-devel-1.0.16-3.fc19.x86_64
[bharrington@leviathan bladeRF]$ id
uid=1000(bharrington) gid=1000(bharrington) groups=1000(bharrington),10(wheel),18(dialout),54(lock),985(plugdev),986(wireshark) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[bharrington@leviathan dev]$ ll /dev/nuand /dev/bus/usb/004/012
lrwxrwxrwx. 1 root root          15 Sep  2 23:54 /dev/nuand -> bus/usb/004/012
crw-rw----. 1 root plugdev 189, 395 Sep  3 00:01 /dev/bus/usb/004/012

This code from the CLI should be integrated into an API call, and the CLI adjusted to use this:

int set_sampling(struct cli_state *state, int argc, char **argv)
{
    /* Usage: set sampling [internal|external] */
    int rv = CMD_RET_OK;
    uint8_t val = 0;
    if( argc != 3 ) {
        rv = CMD_RET_NARGS ;
    } else {
        if( strcasecmp( "internal", argv[2] ) == 0 ) {
            /* Disconnect the ADC input from the outside world */
            bladerf_lms_read( state->dev, 0x09, &val );
            val &= ~(1<<7) ;
            bladerf_lms_write( state->dev, 0x09, val );

            /* Turn on RXVGA2 */
            bladerf_lms_read( state->dev, 0x64, &val );
            val |= (1<<1) ;
            bladerf_lms_write( state->dev, 0x64, val );

        } else if( strcasecmp( "external", argv[2] ) == 0 ) {
            /* Turn off RXVGA2 */
            bladerf_lms_read( state->dev, 0x64, &val );
            val &= ~(1<<1) ;
            bladerf_lms_write( state->dev, 0x64, val );

            /* Connect the external ADC pins to the internal ADC input */
            bladerf_lms_read( state->dev, 0x09, &val );
            val |= (1<<7) ;
            bladerf_lms_write( state->dev, 0x09, val );
        } else {
            cli_err(state, argv[0], "Invalid sampling mode (%s)", argv[2] );
        }
    }
    return rv;
}

The c16_sample_fixup routine should be reviewed for proper endian conversion. Samples coming from the FX3 (little endian) need to be converted to the file format endianness, NOT the host endianness.

A critical eye reviewing potential endianess issues would be appreciated, however.

https://github.com/Nuand/bladeRF/blob/dev-libusb_support/host/utilities/bladeRF-cli/src/cmd/rxtx.c#L272

IRC log describing issue below. Rob, from my understanding you have some more info on this -- mind updating it here?

10:18 < BzztPloink> but i ran USB30CV which pointed out that set_interface
10:18 < BzztPloink> doesn't set the 'active interface' so calling (set 
                    interface (int:0 alt:0), set interface (int:1 alt:0) in a 
                    row)
10:18 < BzztPloink> doesn't mean 1 is 'active'
10:19 < BzztPloink> set_interface merely sets the alt-setting for the specified 
                    interface
10:19 < BzztPloink> there is not concept of an 'active interface'
10:19 < jynik> ok...lemme jot this down. it's easier not to forget things when 
               they're staring us in the face on github ;)
10:20 < BzztPloink> i gave mike the cv3 logs already
10:20 < jynik> excellent. I think i recall seeing that link "Chapter 4" or 
               something..
10:20 < BzztPloink> problem is, the solution is probably to go from 3 
                    interfaces to 1 interface with 3 alt settings
10:20 < BzztPloink> which is going to cause world of hurt driver wise
10:21 < jynik> Linux driver or do you mean in a more general sense?
10:21 < BzztPloink> general sense
10:21 < BzztPloink> fx3 + driver have to be in sync
10:22 < BzztPloink> i see a wrapper call for the set_interface in the near 
                    future that figures out wtf the fx3 is configured with and 
                    does the right call
10:22 < BzztPloink> hmm wait that's not that bad really

The data of interest is likely the calibration data sector, for backup purposes.

However, being able to read back arbitrary sections of flash might come in useful down the line.

I was compiling the FPGA image via the instructions provided in the README, however when I preformed the:
"c) Synthesize FPGA image
i) Processing -> Start Compilation"

step, the following error came up:

Error (10793): VHDL error at bladerf.vhd(7): entity bladerf does not have an architecture

What am I doing wrong?

I am running Quartus 12.01sp1 64-bit on Windows 7 64. I started following the README process with a clean version of the bladeRF repo at revision 55c3879 (latest as of writing this ticket).

When built for release mode, the FX3 firmware does not ever produce samples coming back to the host. The kernel driver fails to send a control message with a return code of -110 followed by 2 more with a return code of -71.

Compiling the FX3 firmware for debug with DEBUG=yes creates a working firmware.

There are a number of warnings that look like they might be the cause of some issues.

Right now, there's a few items (e.g., struct bladeRF_firmware) that are exchanged without serialization/deserialization.

Fortunately, all these are nicely aligned and not padded structures. However, this will yield nasty results if and when changes are made to the relevant structures.

Fresh load of FPGA, open bladerf-cli -i, trying to tx a test csv file full of 2047, 0. No signal goes out (viewing from an rtlsdr on a laptop to verify).

Open gnuradio, run a test tx script, transmits strong with the exact same settings CLI had. Close out of gnuradio, boot back into bladerf-cli, tx config file=/tmp/test.csv format=csv repeat=0 and tx start and big spike on the spectrum as expected.

Exit out, reload fpga, go back into CLI and can't tx no matter what settings. Run the gnuradio tx test script and go back to CLI and CLI can tx just fine. Interesting to note, I can tx start tx stop as many times as I want after running the gnuradio script. As soon as I set frequency to something else then tx start, CLI stops allowing me to transmit no matter what.

What does gr-osmosdr do to init bladerf? It's configuring something to allow the tx to work.

The initial frequency set tunes both rx and tx. Subsequent set frequency commands do not tune the tx, the tx is stuck on whatever the initial frequency set was. tx is tunable in gnuradio on linux, this bug seems to be limited to windows.

This falls under the "nice to have" category and is a very low priority item.

Currently, items such as samplerate must be entered in units of Hz. A desirable enhancement would be the ability to enter something such as "10M" or "10e6" instead of 10000000.

Be wary of cases such as "10.5M"

Current calls to bladerf_get_sample_rate() does not return anything. In fact, the rate pointer is never touched at all.

The rate should be updated with the current sample rate from the device.