Hi Brian,

I have finished the DDC block 1:8 and it works perfectly!! :) :)

Now I am in my final step, a 2:16 DDC block:
- Channels 0:7 connected to input 0.
- Channels 8:15 connected to input 1.

The verilog module works, but I have a problem with the UHD driver. I have
timeout on chan 8,9,10...15.
When I use GNURadio Signal Source it runs fine, but when I use rfnoc Radio
block no.

I have tried (device3_io_impl.cpp) :

...
        // Update args so args.args is always valid for this particular
channel:
        args.args = chan_args[stream_i];
        size_t mb_index = block_id.get_device_no();
        size_t suggested_block_port = args.args.cast<size_t>("block_port",
rfnoc::ANY_PORT);
        // printf("Puerto: %i\n",suggested_block_port);
        // change
        // size_t radio_block_port = args.args.cast<size_t>("radio_port",
rfnoc::ANY_PORT) ;
        size_t radio_block_port = 0;

        if (stream_i<8){
          radio_block_port = 0;
        }
        else{
          radio_block_port = 1;
        }
...

(( I recognize that I am not an expert on the driver)) :/

Thank you :)











El lun., 3 dic. 2018 a las 17:38, Carlos Alberto Ruiz Naranjo (<
carlosruiznara...@gmail.com>) escribió:

> Ok, I had a problem with *radio_block_port. *I had a signed number... :(
>
> I think now it runs. I will pass to 1:8 DCC and later with 2:16 DDC. I
> continue... :)
>
> El lun., 3 dic. 2018 a las 16:09, Carlos Alberto Ruiz Naranjo (<
> carlosruiznara...@gmail.com>) escribió:
>
>> Hello Brian,
>>
>> thanks for your answer! I have returned today and I am testing your
>> changes.
>>
>> I am using grc and I have the error:
>>
>> *thread[thread-per-block[0]: <block uhd_rfnoc_DDC (2)>]: LookupError:
>> KeyError: [0/Radio_0] sr_write(): No such port: 18446744073709551615*
>>
>> I assume the error is in the configuration of uhd::device_addr_t. Can you
>> explain how it works? I have not understood it well, I'm sorry :( :(
>>
>> I am configuring it with grc python block:
>>
>> *self.device3 = variable_uhd_device3_0 = ettus.device3(uhd.device_addr_t(
>> ",".join(('type=x300', " block_port%d, radio_id%d, radio_port%d")) ))*
>>
>> I have never tried to change the settings.
>>
>> Thank you in advance!!! :)
>>
>> El vie., 30 nov. 2018 a las 16:58, Brian Padalino (<bpadal...@gmail.com>)
>> escribió:
>>
>>> Hey Carlos,
>>>
>>> The attached patch is what I used applied to 3.13.0.1 I want to say.
>>> You get the idea.
>>>
>>> To get the controller, I use get_block_ctrl(uhd::rfnoc::block_id_t(0,
>>> "NAME", 0)) since there is only one instance, for me, in my radio.
>>>
>>> When setting up the uhd::device_addr_t, I populate: block_port%d,
>>> radio_id%d, and radio_port%d where block_port%d is the output block you're
>>> looking at streaming from.
>>>
>>> Hope this is helpful.
>>>
>>> Good luck.
>>>
>>> Brian
>>>
>>> On Fri, Nov 30, 2018 at 4:34 AM Carlos Alberto Ruiz Naranjo <
>>> carlosruiznara...@gmail.com> wrote:
>>>
>>>> Hello Brian,
>>>>
>>>> I have finished the FPGA code. I got a DDC 1:2 but I have problems with
>>>> 1:8. I think I have your same problems: /
>>>>
>>>> *thread[thread-per-block[0]: <block uhd_rfnoc_DDC (2)>]: LookupError:
>>>> KeyError: [0/Radio_0] sr_write(): No such port: 2*
>>>>
>>>> In rfnoc code:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *        std::vector<boost::shared_ptr<uhd::rfnoc::radio_ctrl> >
>>>> upstream_radio_nodes =
>>>> blk_ctrl->find_upstream_node<uhd::rfnoc::radio_ctrl>();
>>>> UHD_RX_STREAMER_LOG() << "Number of upstream radio nodes: " <<
>>>> upstream_radio_nodes.size();        for(const
>>>> boost::shared_ptr<uhd::rfnoc::radio_ctrl> &node:  upstream_radio_nodes)
>>>> {            node->sr_write(uhd::rfnoc::SR_RESP_OUT_DST_SID,
>>>> xport.send_sid.get_src(), block_port);        }*
>>>>
>>>> I've found your post (
>>>> http://ettus.80997.x6.nabble.com/USRP-users-Multiple-Output-RFNoC-Block-td9587.html
>>>> ), but I'm stuck on the same point.
>>>> Could you give me any suggestions?
>>>>
>>>> Thank you!! :)
>>>>
>>>>
>>>>
>>>>
>>>> El mié., 28 nov. 2018 a las 16:17, Carlos Alberto Ruiz Naranjo (<
>>>> carlosruiznara...@gmail.com>) escribió:
>>>>
>>>>> Ok! Thank you :)
>>>>>
>>>>> El mié., 28 nov. 2018 a las 16:13, Brian Padalino (<
>>>>> bpadal...@gmail.com>) escribió:
>>>>>
>>>>>> On Wed, Nov 28, 2018 at 9:43 AM Carlos Alberto Ruiz Naranjo <
>>>>>> carlosruiznara...@gmail.com> wrote:
>>>>>>
>>>>>>> Thank you! I already have enough work to continue :)
>>>>>>>
>>>>>>> One last thing. In the split_stream module, did you concat tuser
>>>>>>> with m_axis_data_tuser with m_axis_data_tdata?
>>>>>>>
>>>>>>
>>>>>> No tuser at that point.  Just the stream part - tdata, tlast, tvalid,
>>>>>> and tready.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I'm curious about you election. Why do you think that version 0 is
>>>>>>> better than version 1?
>>>>>>>
>>>>>>
>>>>>> Not really sure.  It is just the way I ended up.  I think either way
>>>>>> will work.  Whichever way makes sense to you, try it out!  Have fun! :)
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to