Are you sure that the radio is even streaming? The typical method for
starting streaming is to tell the rx_streamer to start streaming. Then, in
UHD-land, the rx_streamer ctrl tells the next upstring block to start
streaming such that this streaming command propagates up the chain until
the radio receives it and starts streaming. So, if your custom block does
not forward the streaming command from the rx_streamer to the radio, then
the radio never even starts streaming. You can verify by simply monitoring
the LEDs.
If this is the problem, you can go-around the intended use by simply
telling the radio to start streaming rather than the rx_streamer. Or, of
course, you can modify your custom block controller to propagate the
streaming command.
Rob
On Mon, Sep 12, 2022 at 4:18 PM Kevin Williams <zs1...@gmail.com> wrote:
> Yes, of course. But I don't get 1 sample from the ddc's, even with just
> one channel of a 2:1 decimated channel connected to the rx streamer.
>
> On Mon, 12 Sept 2022 at 22:13, Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> The aggregate output rate of the 5 streams could require more bandwidth
>> than the 10 GigE interface can sustain. What are the exact output rates?
>>
>> On Mon, Sep 12, 2022 at 3:53 PM Kevin Williams <zs1...@gmail.com> wrote:
>>
>>> Those rates vary from a 2:1 decimation down to other rates.
>>>
>>> The host has 10 Gbe interfaces to the USRP.
>>>
>>> I get samples if i connect the radio to the rx streamer, just nothing
>>> from the ddc's.
>>>
>>> On Mon, 12 Sept 2022 at 21:48, Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
>>>> Hi Kevin,
>>>>
>>>> What are the sample rates for the 5 outputs? What connection are you
>>>> using to your host PC, 1 GigE or 10 GigE?
>>>>
>>>> Jonathon
>>>>
>>>> On Mon, Sep 12, 2022 at 3:38 PM Kevin Williams <zs1...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Jonathon,
>>>>>
>>>>> I've got an x310. The flowgraph is a simple radio->multiddc->(to 5x
>>>>> outputs). I've tried both static and dynamic routing from the radio block.
>>>>> I.e. the static route version:
>>>>>
>>>>> | /
>>>>> | | Static connections on this device:
>>>>> | |
>>>>> | | * 0/Radio#0:0==>0/multiddc#0:0
>>>>> | | * 0/multiddc#0:0==>0/SEP#2:0
>>>>> | | * 0/multiddc#0:1==>0/SEP#3:0
>>>>> | | * 0/multiddc#0:2==>0/SEP#4:0
>>>>> | | * 0/multiddc#0:3==>0/SEP#5:0
>>>>> | | * 0/multiddc#0:4==>0/SEP#6:0
>>>>>
>>>>>
>>>>> On the input side it is all at the radio rate, but I hope my core is
>>>>> being clocked at 214 MHz.
>>>>>
>>>>> When I simulate my IP core (which includes the AXI streaming
>>>>> interfaces) it looks ok.
>>>>>
>>>>> Regards, Kevin
>>>>>
>>>>> On Mon, 12 Sept 2022 at 21:29, Jonathon Pendlum <
>>>>> jonathon.pend...@ettus.com> wrote:
>>>>>
>>>>>> Hello Kevin,
>>>>>>
>>>>>> What device are you using and what does your flowgraph look like?
>>>>>> What sample rate are you running at? If your block is running at the
>>>>>> radio
>>>>>> sample rate (e.g. 200 MSPS on a X310), your block will need to process
>>>>>> one
>>>>>> input sample every clock cycle on average.
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> On Mon, Sep 12, 2022 at 9:09 AM Kevin Williams <zs1...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I've got an IP core that is causing an "ERROR_CODE_OVERFLOW" when
>>>>>>> used in an RFNoC project.
>>>>>>>
>>>>>>> The core responds correctly when simulated outside the RFNoC
>>>>>>> environment. (I can see correct output, the AXI streaming signalling,
>>>>>>> back-pressure when required, etc.)
>>>>>>>
>>>>>>> I'm not sure how to go about debugging this, and am not yet familiar
>>>>>>> enough with RFNoC to know what to ask.
>>>>>>>
>>>>>>> I have been thinking it was the core not being reset or clocked
>>>>>>> correctly, but this is how it gets instantiated:
>>>>>>>
>>>>>>> multiddc multiddc_i (
>>>>>>> // - Using different clocks for the IP core and the AXI
>>>>>>> interface. The IPCore_Clk and AXILite_ACLK must be
>>>>>>> // synchronous and connected to the same clock source. The
>>>>>>> IPCore_RESETN and AXILite_ARESETN must be
>>>>>>> // connected to the same reset source. See Synchronization
>>>>>>> of Global Reset Signal to IP Core Clock Domain.
>>>>>>> .IPCORE_CLK (axis_data_clk),
>>>>>>> .IPCORE_RESETN (~axis_data_rst),
>>>>>>>
>>>>>>> .AXI4_Lite_ACLK (axis_data_clk),
>>>>>>> .AXI4_Lite_ARESETN (~axis_data_rst),
>>>>>>>
>>>>>>> The core YAML file describes the clock as:
>>>>>>>
>>>>>>> data:
>>>>>>> fpga_iface: axis_chdr
>>>>>>> clk_domain: ce
>>>>>>>
>>>>>>> In the project YAML file:
>>>>>>>
>>>>>>> clk_domains:
>>>>>>> - { srcblk: _device_, srcport: radio, dstblk: radio0,
>>>>>>> dstport: radio }
>>>>>>> - { srcblk: _device_, srcport: ce, dstblk: multiddc0,
>>>>>>> dstport: ce }
>>>>>>>
>>>>>>> Is there something that might be an obvious first place to check?
>>>>>>>
>>>>>>> Many thanks, Kevin
>>>>>>>
>>>>>>> --
>>>>>>> Kevin Williams
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Kevin Williams
>>>>>
>>>>
>>>
>>> --
>>> Kevin Williams
>>>
>>
>
> --
> Kevin Williams
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
