Issues with ATSC and USB2 on ARM and X86_64

Having issues with the site, hardware, source code, or any other issues?
Post Reply
postman
Posts: 11
Joined: Tue Mar 04, 2014 7:47 am

Issues with ATSC and USB2 on ARM and X86_64

Post by postman »

All,

I am attempting to get the bladeRF and Gnuradio working on an ARM board and am hoping you can help me with an issue that I have encountered. I'm not sure whether this will come down to bladeRF, Gnuradio, or osmosdr, but I figured that this would be a good place to start.

Hardware:
- Wandboard (Freescale iMX6 Quad-based Cortex A9 32-bit ARM board) running Ubuntu 13.10 ARMHF. 4 cores, 2GB RAM, graphics acceleration, HW floating point support so there's some horsepower here. USB2 only though.
- bladeRF running fpga v0.0.3 and fx3 v1.6.1, connected via a USB2 port on an Anker USB/peripheral dock.

Software:
- Gnuradio 3.7.1 (currently using this as I've had the most luck with it in the past), 3.7.1.1, and 3.7.2.1
- libbladeRF 0.13.0
- bladeRF-cli 0.10.4
- rtl-sdr latest from master
- gr-osmosdr latest from master
All packages compiled natively on from source on both X86_64 and ARM architectures - no cross compiling or VMs

Test:
I'm trying to get this ATSC transmitter working to test the install: https://github.com/argilo/sdr-examples/ ... de-usb2.py argilo's USB3 version works fine on my desktop (Ubuntu 13.10, X86_64 w/ 8 cores and 16GB RAM), but the script with decimation for USB2 crashes on both ARM and X86_64 with the following error:

ARM:

Code: Select all

    knight@ubuntu-armhf:~/Documents/bladeRF/python/atsc$ python atsc-blade-usb2-works-with-adventure-club.py ~/ramdisk/advatsc.ts
    Using Volk machine: generic
    gr-osmosdr v0.1.0-70-gcc083037 (0.1.1git) gnuradio 3.7.1
    built-in sink types: bladerf
    [bladeRF source] Using nuand LLC bladeRF #0 SN a380...a17a FW v1.6.1 FPGA v0.0.3
    [WARNING] Loss of precision in reducing fraction from 1230769232/1993006993 to 615384616/996503496
    python: /home/knight/sandbox/gnuradio-builds/gnuradio-3.7.1/build/gr-digital/lib/chunks_to_symbols_bc_impl.cc:71: virtual int gr::digital::chunks_to_symbols_bc_impl::work(int, gr_vector_const_void_star&, gr_vector_void_star&): Assertion `((unsigned int)in[i]*d_D+d_D) <= d_symbol_table.size()' failed.
    Aborted
     
X86_64:

Code: Select all

    knight@dev-wks-24lx13:~/Documents/bladeRF/python/atsc$ python atsc-blade-usb2-works-with-adventure-club.py ~/Videos/advatsc.ts
    Using Volk machine: avx_64_mmx
    gr-osmosdr v0.1.0-70-gcc083037 (0.1.1git) gnuradio 3.7.1
    built-in sink types: bladerf
    [bladeRF source] Using nuand LLC bladeRF #0 SN a380...a17a FW v1.6.1 FPGA v0.0.3
    [WARNING] Loss of precision in reducing fraction from 1230769232/1993006993 to 615384616/996503496
    python: /home/knight/sandbox/gnuradio-builds/gnuradio-old/build/gr-digital/lib/chunks_to_symbols_bc_impl.cc:71: virtual int gr::digital::chunks_to_symbols_bc_impl::work(int, gr_vector_const_void_star&, gr_vector_void_star&): Assertion `((unsigned int)in[i]*d_D+d_D) <= d_symbol_table.size()' failed.
    Aborted (core dumped)
     
As you can see, both architectures crash in the same way -- chunks_to_symbols in gr-digital. At this point I have tried 3 different gnuradio versions (3.7.2.1, 3.7.1.1, and 3.7.1) and it crashes in the same spot (different actual line in chunks_to_symbols_XX.cc but same instruction). I am currently on 3.7.1 given that it is the version that I have had the most success in the past with. My attempts to dive into the issue with gdb haven't yielded much. The key variables of interest (d_D, d_symbol_table, in, i) are typically optimized out so I haven't gotten too far there.

I will add that this same USB2 script worked on an old desktop running gnuradio 3.7.1. I no longer have access to that machine though (traded up since it didn't have USB3 compatible hardware).

Any ideas? Let me know if I can provide any additional info or run any tests and I'll get it for you ASAP. I appreciate your assistance and hope we can figure out what's going on here.
drmpeg
Posts: 62
Joined: Fri Mar 01, 2013 3:58 am
Location: Silicon Valley
Contact:

Re: Issues with ATSC and USB2 on ARM and X86_64

Post by drmpeg »

I have a version of atsc-blade-usb2.py that doesn't use the chunks_to_symbols_bc block. It's just an older version of atsc-blade.py with the USB2 resampling added. Tested good here on Ubuntu 13.04 i686 architecture. If you have performance issues on ARM, you can reduce the number of RRC taps from 200 to 10.

Code: Select all

#!/usr/bin/env /usr/bin/python

# Copyright 2013 Clayton Smith ([email protected])
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

from gnuradio import gr, atsc, blocks, analog, filter
from gnuradio.filter import firdes
from grc_gnuradio import blks2 as grc_blks2
import sys, os
import osmosdr

def main(args):
    nargs = len(args)
    if nargs == 1:
        infile  = args[0]
        outfile = None
    elif nargs == 2:
        infile  = args[0]
        outfile  = args[1]
    else:
        sys.stderr.write("Usage: atsc-blade-usb2.py input_file [output_file]\n");
        sys.exit(1)

    symbol_rate = 4500000.0 / 286 * 684
    pilot_freq = 309441
    center_freq = 429000000
    txvga1_gain = -6
    txvga2_gain = 9

    tb = gr.top_block()

    src = blocks.file_source(gr.sizeof_char, infile, True)

    pad = atsc.pad()
    rand = atsc.randomizer()
    rs_enc = atsc.rs_encoder()
    inter = atsc.interleaver()
    trell = atsc.trellis_encoder()
    fsm = atsc.field_sync_mux()

    v2s = blocks.vector_to_stream(gr.sizeof_char, 1024)
    minn = blocks.keep_m_in_n(gr.sizeof_char, 832, 1024, 4)
    b2f = blocks.uchar_to_float()
    mul = blocks.multiply_const_vff((2, ))
    add = blocks.add_const_vff((-7 + 1.25, ))
    zero = analog.sig_source_f(0, analog.GR_CONST_WAVE, 0, 0, 0)
    f2c = blocks.float_to_complex(1)
    offset = analog.sig_source_c(symbol_rate, analog.GR_COS_WAVE, -3000000 + pilot_freq, 1.1, 0)
    mix = blocks.multiply_vcc(1)
    rrc_taps = firdes.root_raised_cosine(0.1, symbol_rate*2, symbol_rate/2, 0.1152, 200)
    rrc = filter.rational_resampler_ccc(interpolation=2, decimation=3, taps=rrc_taps, fractional_bw=None, )

    out = osmosdr.sink(args="bladerf=0,buffers=128,buflen=32768")
    out.set_sample_rate(symbol_rate * 2 / 3)
    out.set_center_freq(center_freq, 0)
    out.set_freq_corr(0, 0)
    out.set_gain(txvga2_gain, 0)
    out.set_bb_gain(txvga1_gain, 0)
    out.set_bandwidth(6000000, 0)

    tb.connect(src, pad, rand, rs_enc, inter, trell, fsm, v2s, minn, b2f, mul, add)
    tb.connect((add, 0), (f2c, 0))
    tb.connect((zero, 0), (f2c, 1))
    tb.connect((f2c, 0), (mix, 0))
    tb.connect((offset, 0), (mix, 1))
    tb.connect(mix, rrc, out)

    if outfile:
        dst = blocks.file_sink(gr.sizeof_gr_complex, outfile)
        tb.connect(rrc, dst)

    tb.run()


if __name__ == '__main__':
    main(sys.argv[1:])
Ron
postman
Posts: 11
Joined: Tue Mar 04, 2014 7:47 am

Re: Issues with ATSC and USB2 on ARM and X86_64

Post by postman »

Ron,

Thanks for your response, and for taking the time to look at this. I'll give this a shot first thing tomorrow and will report back. Out of curiosity, have you had issues with the chunks_to_symbols block, or have you heard of anyone else running into trouble with it? Trying to figure out if it's an installation problem or something else.
postman
Posts: 11
Joined: Tue Mar 04, 2014 7:47 am

Re: Issues with ATSC and USB2 on ARM and X86_64

Post by postman »

As an update, the new file you provided runs well on the desktop but not the ARM. There are no specific error messages, although LED1 turns off almost immediately after the radio starts up. top indicates that it is using between 250-350% of my 4 CPUs even with just 10 taps enabled, so I fear I may be hitting the performance limit on this one.

Unless you have any optimization ideas, I may look into offloading some of the modulation to the FPGA. I saw some discussion of this on the other thread (http://nuand.com/forums/viewtopic.php?f=8&t=3503) and also found some relevant cores online, so that's a start.
Post Reply