Consumption of rtl_tcp too slow?

Mr Anthony Arnold anthony.arnold at uqconnect.edu.au
Thu May 7 02:30:47 UTC 2015


Hi list


I'm having some trouble with gr-osmosdr and rtl_tcp. I'm trying to set up a Raspberry Pi as a remote receive to provide I/Q samples over the network to a machine running gnss-sdr (for realtime GPS processing.) The Pi simply runs "rtl_tcp -f 1575420000 -a 0.0.0.0", and then on gnss-sdr the gr-osmosdr block is created with


osmosdr::source::make("rtl_tcp=<address of pi>");


This connects as expected, but the generated data from rtl_tcp is not being consumed fast enough; the linked list quickly fills up to 502.


I thought maybe the WiFi was the bottleneck, so I switched to Ethernet. No luck, same behaviour.


I decided to take it all the way back and plug the dongle straight into the machine that is running gnss-sdr, and then run rtl_tcp on the same machine: "rtl_tcp -f 1575420000" and change the arguments for the gnuradio block to
?

osmosdr::source::make("rtl_tcp");?


I still get this poor performance. Note that on the same machine, with the GrOsmoSdr block connecting straight to the dongle via USB (i.e. creating the block with empty arguments) the performance is fine and I'm able to track GPS satellites in realtime. I understand that having the network layer in between is going to cause some delay, but I didn't expect this much.


I thought that maybe the actual processing of gnss-sdr was holding up the reads in some way, so I tried a different program which post-processes the data; the code which does this is in the listing below (pulled from the function "frontend_capture" from https://raw.githubusercontent.com/gnss-sdr/gnss-sdr/next/src/utils/front-end-cal/main.cc).


The source block is just a wrapper around an osmosdr::source("rtl_tcp"). The conditioner is a pass-through block. Unfortunately, the reads *still* aren't keeping up with the writes from rtl_tcp. I'd like to understand what's causing this. Is it because of the frequency tuning? Is it the sample rate? I have tried various rates. I noticed rtl_tcp_source_c::get_sample_rates? returns a few "known to work" rates. Should I be setting the sample rate to exactly one of these?



    gr::top_block_sptr top_block;
    GNSSBlockFactory block_factory;
    boost::shared_ptr<gr::msg_queue> queue;

    queue =  gr::msg_queue::make(0);
    top_block = gr::make_top_block("Acquisition test");

    std::shared_ptr<GNSSBlockInterface> source;
    source = block_factory.GetSignalSource(configuration, queue);

    std::shared_ptr<GNSSBlockInterface> conditioner = block_factory.GetSignalConditioner(configuration,queue);

    gr::block_sptr sink;
    sink = gr::blocks::file_sink::make(sizeof(gr_complex), "tmp_capture.dat");

    //--- Find number of samples per spreading code ---
    long fs_in_ = configuration->property("GNSS-SDR.internal_fs_hz", 2048000);
    int samples_per_code = round(fs_in_
            / (GPS_L1_CA_CODE_RATE_HZ / GPS_L1_CA_CODE_LENGTH_CHIPS));
    int nsamples = samples_per_code * 50;

    int skip_samples = fs_in_ * 5; // skip 5 seconds

    gr::block_sptr head = gr::blocks::head::make(sizeof(gr_complex), nsamples);

    gr::block_sptr skiphead = gr::blocks::skiphead::make(sizeof(gr_complex), skip_samples);

    try
    {
            source->connect(top_block);
            conditioner->connect(top_block);
            top_block->connect(source->get_right_block(), 0, conditioner->get_left_block(), 0);
            top_block->connect(conditioner->get_right_block(), 0, skiphead, 0);
            top_block->connect(skiphead, 0, head, 0);
            top_block->connect(head, 0, sink, 0);
            top_block->run();
    }
    catch(std::exception& e)
    {
            std::cout << "Failure connecting the GNU Radio blocks " << e.what() << std::endl;
            return false;
    }

    //delete conditioner;
    //delete source;
    return true;



Anthony Arnold | Programmer

b:  http://anthony-arnold.com/
t:   http://twitter.com/anthonyarnold_/
e:  anthony.arnold at uqconnect.edu.au

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20150507/ffff8aef/attachment.html>


More information about the osmocom-sdr mailing list