Hello Matis,

Can you turn on full UHD logging and pastebin the output?

Jonathon


On Fri, Apr 6, 2018, 4:28 PM Matis Alun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Le 05/04/2018 à 16:29, Marcus D. Leech via USRP-users a écrit :
>
> On 04/05/2018 04:55 AM, Matis Alun via USRP-users wrote:
>
> Hi usrp users,
>
> I experienced some problem using my X300 + TwinRx over 1 Gb/s link.
>
> The following code example shows that after the iteration number 253, the
> program stops
> with the following traceback:
>
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: [0/Radio_0] sr_write() failed:
> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet -
> AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>   at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
>
> I have good news: If I move the part of the code which construct the
> rx_stream, there is no errors.
>
> Is someone can explain me ? Is this an uhd bug or not ?
>
> Matis
>
> This should be possible, but it seems awkward and unusual to do what
> you're doing, in the way that you're doing it.
>
>
> You should:
>
> STREAM_MODE_START_CONTINUOUS
>
> read as much data as you want
>
> STREAM_MODE_STOP_CONTINUOUS
>
> That is, there's no reason to keep doing the start/stop on every
> iteration, since you aren't pausing, you're basically just continuous
> streaming in an
>   awkward and unusual way.
>
> Now, this shouldn't raise that exception, but the workaround is to
> structure your code without tightly looping on START/STOP.
>
> yes, you're right, but this was here a small example to show you the
> traceback. My application is more complicated and acts like a data
> server which answer to any acquisition request. So each request could be
> at another frequency. So I thought we have to STOP, change the frequency
> and START.
>
> However, the problem is not that the START/STOP is inside the loop. Which
> is causing the traceback is the instanciation of the rx_stream inside
> the loop. Of course, I can organize my code to avoid this but I thought
> that it was probably an UHD bug. This is the reason why I send this message
> (and also to help people who had the same kind of problem...).
>
> Regards,
>
> Matis
>
>
>
> bool test2() {
>     std::string args="addr=192.168.10.2";
>     uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>
>     std::string subdev_spec="A:0";
>     usrp->set_rx_subdev_spec(subdev_spec);
>     usrp->set_rx_rate(25e6, 0);
>     usrp->set_rx_freq(1240e6, 0);
>     usrp->set_rx_gain(50.0, 0);
>     usrp->set_rx_antenna("RX1", 0);
>
>     while (true) {
>         uhd::sensor_value_t lo_locked = usrp->get_rx_sensor("lo_
> locked",0);
>         if (lo_locked.to_bool()) {
>             break;
>         }
>         usleep(10000);
>     }
>
>
>     for (int iteration=0; iteration<1000; iteration++) {
>         // try this block outside the loop and every thing is ok
>         uhd::stream_args_t stream_args("sc16", "sc16");
>         stream_args.channels.push_back(0);
>         uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_
> args);
>         // end of block
>
>         cout << "iteration: "<< iteration << endl;
>         uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::
> STREAM_MODE_START_CONTINUOUS);
>         stream_cmd.num_samps = 0;
>         stream_cmd.stream_now = true;
>         stream_cmd.time_spec = uhd::time_spec_t();
>         rx_stream->issue_stream_cmd(stream_cmd);
>
>         std::vector<std::complex<int16_t>> buff_sc16(524288);
>         uhd::rx_metadata_t md;
>         int num_rx_samps;
>
>
>         for (int i=0; i<10; i++) {
>             num_rx_samps = rx_stream->recv(&buff_sc16.front(),
> buff_sc16.size(), md, 1.0);
>             cout << "recv:"<< num_rx_samps<<endl;
>         }
>
>         stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_
> MODE_STOP_CONTINUOUS;
>         rx_stream->issue_stream_cmd(stream_cmd);
>     }
>     return true;
> }
>
>
> _______________________________________________
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to