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.w...@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 < > zz4...@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 < >> zz4...@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.w...@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@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@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
