Oops. Ignore what I said. I now realize you stated you were getting an
Overflow which of course you would never get if streaming hadn't started.
Rob
On Mon, Sep 12, 2022 at 6:32 PM Rob Kossler <rkoss...@nd.edu> wrote:
> 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
