[USRP-users] [RFNoC] Listen Before Talking (LBT)

Felipe Augusto Pereira de Figueiredo zz4fap at gmail.com
Tue Oct 17 14:24:00 EDT 2017


Dear Michael,

Thanks for your reply! I'll try to do something like that. I hope it works.

Thanks once more and Kind Regards,

Felipe Augusto

On Tue, Oct 17, 2017 at 2:02 AM, Michael West <michael.west at ettus.com>
wrote:

> Hi Felipe,
>
> 1)  As with any custom RFNoC block, yes it would connect to the crossbar.
>
> 2)  Yes, your understanding is correct.
>
> 3)  You would have to define what "high latency" is.  The block would
> certainly add latency to the path.  I would expect it to be on the order of
> 1 packet due to packet gating.  Anything you add to split the stream to
> duplicate the RX data to your custom logic and the host will add the same
> amount of latency.  Splitting the stream within your custom block will use
> fewer resources than adding a separate block (such as a Split Stream block).
>
> 4)  The DMA FIFO doesn't need control.  The noc_shell and crossbar handle
> the control.  Use it as a simple FIFO.  Mostly, the DMA FIFO is used to
> buffer up TX data to absorb host system "jitter" (random amount of time
> between data packets from host to device).
>
> Regards,
> Michael
>
> On Sat, Oct 14, 2017 at 9:11 AM, Felipe Augusto Pereira de Figueiredo <
> zz4fap at gmail.com> wrote:
>
>> Sorry, I've just noticed my last email did not include the USRP mailing
>> list.
>>
>> On Sat, Oct 14, 2017 at 12:30 PM, Felipe Augusto Pereira de Figueiredo <
>> zz4fap at gmail.com> wrote:
>>
>>> Dear Michael,
>>>
>>> Thanks for your answers!
>>>
>>> However, I still have some questions.
>>>
>>> 1) Will this new block be connected to the crossbar as the other NoC
>>> modules? I'm asking it because you mention the block should have 2 input
>>> ports and 2 output ports, so I'm supposing they are all connected to the
>>> crossbar and will communicate through DMA.
>>>
>>> 2) As I understood, this new block would be placed between DDC and Host
>>> PC, and also, between DMA FIFO and the DUC block. I mean, the flow would
>>> be, DDC -> New Block -> Host PC and DMA FIFO -> New Block -> DUC, is my
>>> understanding correct?
>>>
>>> 3) Would the new data flow: DDC -> New Block -> Host PC add very high
>>> latency to the communication between USRP and Host PC, or it would not
>>> impact too much? Wouldn't it be better for new block to receive data from
>>> the DDC without being in the middle between DDC and Host PC?
>>>
>>> 4) Is there some trick to control the DMA FIFO reading or is it simple
>>> as done by other blocks connected to the crossbar? I've never worked with
>>> those kinds of FIFO...
>>>
>>> Thanks again and Kind Regards,
>>>
>>> Felipe Augusto
>>>
>>> On Fri, Oct 13, 2017 at 9:48 PM, Michael West <michael.west at ettus.com>
>>> wrote:
>>>
>>>> Hi Felipe,
>>>>
>>>> That is absolutely possible to do in RFNoC and not very hard.  You
>>>> simply create a block that has 2 input ports and 2 output ports with one
>>>> input from the DDC, one input from the DMA FIFO, one output for the RX data
>>>> back to the host, and one output for data to the DUC.  All of your power
>>>> calculation and control logic sits in the block.  User registers can be
>>>> instantiated to control the threshold and any other dynamic parameters you
>>>> need.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Tue, Oct 3, 2017 at 1:42 AM, Felipe Augusto Pereira de Figueiredo
>>>> via USRP-users <usrp-users at lists.ettus.com> wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> I'm thinking of implementing LBT with RFNoC, however, after an initial
>>>>> study of the RFNoC framework I realized it would be hard to implement
>>>>> what I had in mind:
>>>>>
>>>>> Initially, I would start with a very basic approach:
>>>>> 1) Calculate the power received just after the DDC for every received
>>>>> packet
>>>>> 2) If the power is greater than a defined threshold I would disable
>>>>> the DUC from reading new IQ samples from the dmaFIFO. Disabling DUC
>>>>> would require a new output signal (DDC) and input signal (DUC).
>>>>>
>>>>> However, I think the approach with input/output signals would not be
>>>>> the best one but I don't really have better ideas as I'm quite new to
>>>>> RFNoC.
>>>>>
>>>>> Now comes the reason why I'm writing this email, I'd like to know if
>>>>> there is a better approach for this LBT implementation with RFNoC.
>>>>>
>>>>> Any hint will be very helpful!
>>>>>
>>>>> Thanks and Kind Regards,
>>>>>
>>>>> Felipe Augusto
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users at lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171017/c8370d84/attachment-0002.html>


More information about the USRP-users mailing list