Regarding the payload/context change, it looks like the modtool sets the fpga_iface to axis_pyld_ctxt, but in conv.yml you changed it to axis_data? So when you ran rfnoc_create_verilog, it changed the interface type used by the NoC shell. You can read about "AXI-Stream Payload Context" and "AXI-Stream Data" interface types in the RFNoC Specification <https://files.ettus.com/app_notes/RFNoC_Specification.pdf>. I think either could be used.
Wade On Thu, May 19, 2022 at 4:18 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> wrote: > Thanks Wade! I just remembered that I forgot to set my output to input > ratio which may be explaining why the timeouts are happening even with the > extended delay. > > When I used the rfnoc_create_verilog, I noticed that the client interface > only has m_in_axis_* and s_out_axis_* connections and no separation between > context and payload for the template of noc shell used by the tool. > > As such the logpwr example you shared with me earlier isn't > straightforward to port over and the duc example appears to be most > compatible pin-out wise with axi_rate_change so I'm about to attempt to > hook it up it but wanted to clarify that there aren't any additional > changes I would need to do aside from adjusting MAX_M, MAX_N, and ensuring > the input/output wire names match what are in my signal declarations > section? Thanks! > > -Jeff > > > > > > > > On Thu, May 19, 2022 at 12:36 PM Wade Fife <wade.f...@ettus.com> wrote: > >> The testbench has start_test() and end_test() calls around each test. >> There's a timeout in the start_test() call, and there's also a global >> timeout (part of start_tb(), but I think 10 ms by default). If the >> end_test() doesn't occur within a certain amount of time of the >> start_test(), then the testbench assumes something went wrong. Otherwise, >> the simulation could just keep running forever. >> >> So you'll need to look at your simulation to see where things are getting >> stuck. Also, make sure what you're doing doesn't just need more time. >> >> Wade >> >> On Thu, May 19, 2022 at 2:29 PM Jeffrey Cuenco <jeffrey.cue...@gmail.com> >> wrote: >> >>> Thanks Wade! I used the rfnoc_create_verilog and it generated code that >>> contained ce_clk and added >>> >>> output wire ce_rst; >>> >>> following the ce_clk declaration around line 32 of rfnoc_block_conv.v in >>> the generated file, then plugged it into .ce_rst of noc_shell_conv later in >>> the file and also used it in my axi_conv instantiation. >>> >>> After doing that and building I was able to get the testbench to run but >>> I now get a fatal timeout, something about time limit exceeded. >>> >>> Is there something that needs to be wired in so that it knows when >>> things finish? Thanks! >>> >>> -Jeff >>> >>> On Thu, May 19, 2022 at 12:23 Wade Fife <wade.f...@ettus.com> wrote: >>> >>>> I think those versions are fine, but your gr-ettus might be out of >>>> date. I'm not very familiar with the GNU Radio integration. You could try >>>> updating your gr-ettus then regenerate your block, or you could run the >>>> rfnoc_create_verilog tool using the YML file as an input if you need to >>>> customize the YAML to add the ce_clk/ce_rst signals. It's really up to you >>>> if you need those signals. But your IP needs to be clocked and probably >>>> reset by something, and you need to make sure the generated noc_shell uses >>>> the same clock domains you're expecting to use. >>>> >>>> >>>> Wade >>>> >>>> On Wed, May 18, 2022 at 10:10 PM Jeffrey Cuenco < >>>> jeffrey.cue...@gmail.com> wrote: >>>> >>>>> Neel recommended I use UHD v4.1.0.5 and GRC v3.8.5.0 so that’s what >>>>> I’ve been using - does this version not generate the right items? If not >>>>> which version of UHD should I update to, and which version of GRC works >>>>> best with it? Thanks! >>>>> >>>>> -Jeff >>>>> >>>>> On May 18, 2022, at 19:59, Wade Fife <wade.f...@ettus.com> wrote: >>>>> >>>>> >>>>> If you want to customize the YAML and regenerate from your modified >>>>> YAML, then I think you need to use rfnoc_create_verilog (part of UHD). So >>>>> you could do something like: >>>>> >>>>> python3 uhd/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py -c >>>>> conv.yml -d ./rfnoc_block_conv >>>>> >>>>> However, I see ce_rst in the modtool templates: >>>>> >>>>> >>>>> https://github.com/EttusResearch/gr-ettus/blob/master/python/rfnoc_modtool/templates.py#L994 >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_gr-2Dettus_blob_master_python_rfnoc-5Fmodtool_templates.py-23L994&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=1DdbigE2N0YgkBb5QwxGwLoaLzBicQiQrNdYgLIklkzVPw_RkRIL9bq4dINC9Cqd&s=fKouuct_wr3CdcChBQjBmaL6WDVq7l3U1zAVR7DcnDY&e=> >>>>> >>>>> https://github.com/EttusResearch/gr-ettus/blob/master/python/rfnoc_modtool/templates.py#L1384 >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_gr-2Dettus_blob_master_python_rfnoc-5Fmodtool_templates.py-23L1384&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=1DdbigE2N0YgkBb5QwxGwLoaLzBicQiQrNdYgLIklkzVPw_RkRIL9bq4dINC9Cqd&s=g8-XZVaLen6JS347_frcJqnHnCFTxWbAtw1WcLKrtzA&e=> >>>>> >>>>> Perhaps you're using an older version of modtool? >>>>> >>>>> Wade >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, May 18, 2022 at 12:33 PM Jeffrey Cuenco < >>>>> jeffrey.cue...@gmail.com> wrote: >>>>> >>>>>> Spoke too soon - sent last one out too fast so apologies for the >>>>>> message clutter: >>>>>> >>>>>> What I see in rfnoc_block_conv.v is ce_clk as an input wire within >>>>>> the rfnoc_block_conv module declaration. >>>>>> >>>>>> However, I don't see ce_rst anywhere in either the noc_shell_conv.v >>>>>> nor the rfnoc_block_conv.v files. >>>>>> >>>>>> Is this something I should be concerned about, or will I need to >>>>>> manually add this wire in? Please advise - thanks! >>>>>> >>>>>> -Jeff >>>>>> >>>>>> >>>>>> On Wed, May 18, 2022 at 10:26 AM Jeffrey Cuenco < >>>>>> jeffrey.cue...@gmail.com> wrote: >>>>>> >>>>>>> To clarify - I see them in rfnoc_block_conv.v but not in >>>>>>> noc_shell_conv.v - just want to ensure that is okay; I ended up >>>>>>> regenerating from scratch as I had used the gain block as a base the >>>>>>> first >>>>>>> time and it seems it was generated with an older RFNoC 3.x codegen. >>>>>>> >>>>>>> Will proceed with this and let you know my results. Thanks! >>>>>>> >>>>>>> On Wed, May 18, 2022 at 7:55 AM Jeffrey Cuenco < >>>>>>> jeffrey.cue...@gmail.com> wrote: >>>>>>> >>>>>>>> Thanks Wade! >>>>>>>> >>>>>>>> I tried to regenerate using rfnocmodtool and noticed that the >>>>>>>> ce_clk and ce_rst wires aren't present in the template code and the >>>>>>>> yaml >>>>>>>> files get overwritten - is there another command for rfnocmodtool that >>>>>>>> I >>>>>>>> should be using to regenerate after customizing the yaml? Thanks! >>>>>>>> >>>>>>>> -Jeff >>>>>>>> >>>>>>>> On Mon, May 16, 2022 at 11:07 AM Wade Fife <wade.f...@ettus.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I was looking at your code to answer your question when I noticed >>>>>>>>> that the noc_shell code doesn't seem to match your YAML, so I'm >>>>>>>>> wondering >>>>>>>>> if the YAML was modified after you generated your noc_shell? The >>>>>>>>> noc_shell >>>>>>>>> is missing the ce_clk declared in your YAML. >>>>>>>>> >>>>>>>>> To answer your question, I'm going to assume you want a ce_clk >>>>>>>>> that's different from rfnoc_chdr_clk and rfnoc_ctrl_clk and you want >>>>>>>>> your >>>>>>>>> DSP and the registers to use ce_clk. In that case: >>>>>>>>> >>>>>>>>> 1. Regenerate your block to get a new noc_shell_conv. This >>>>>>>>> will add a ce_clk input and a ce_rst output to noc_shell_conv. >>>>>>>>> Again, be >>>>>>>>> careful to not overwrite your existing code when regenerating your >>>>>>>>> block. >>>>>>>>> 2. In rfnoc_block_conv, connect the ce_clk input port to the >>>>>>>>> ce_clk input port of noc_shell_conv. >>>>>>>>> 3. In rfnoc_block_conv, declare a ce_rst wire at the top and >>>>>>>>> connect it to the ce_rst output port of your noc_shell. >>>>>>>>> 4. Update your registers and custom logic to use ce_clk and >>>>>>>>> ce_rst. >>>>>>>>> >>>>>>>>> The answer is slightly different if you want to use the current >>>>>>>>> noc_shell. But in general, you say what clocks you want to use in the >>>>>>>>> YAML >>>>>>>>> file. When the noc_shell is generated, it will take as inputs the >>>>>>>>> clocks >>>>>>>>> you declared in the YAML, it will output resets that you can use for >>>>>>>>> those >>>>>>>>> clock domains, and it will output on ctrlport_clk and axis_data_clk >>>>>>>>> whatever clocks you said in the YAML that you wanted to use for those >>>>>>>>> interfaces. This can be a bit confusing because it means you can have >>>>>>>>> multiple versions of the same clock under different names (e.g., >>>>>>>>> ce_clk, >>>>>>>>> ctrlport_clk, and axis_data_clk might all be the same clock, just on >>>>>>>>> different signal names). >>>>>>>>> >>>>>>>>> Wade >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, May 13, 2022 at 1:09 PM Jeffrey Cuenco <jcue...@ucsd.edu> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks Wade! >>>>>>>>>> >>>>>>>>>> I went ahead and restored the signal sizes to 32-bit as you >>>>>>>>>> suggested. >>>>>>>>>> >>>>>>>>>> For using ce_clk, does it suffice for me to create a wire for >>>>>>>>>> ce_clk in the .v file and then reference it from the yaml? Is >>>>>>>>>> ordering >>>>>>>>>> important or just ensuring the name matches the wire? Thanks! >>>>>>>>>> >>>>>>>>>> -Jeff >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On May 12, 2022, at 10:29, Wade Fife <wade.f...@ettus.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Jeff, >>>>>>>>>> >>>>>>>>>> I took a look and noticed a couple things. >>>>>>>>>> >>>>>>>>>> - There are some signal width mismatches in >>>>>>>>>> rfnoc_block_conv.v. Take a look at s_rfnoc_ctrl_tdata, >>>>>>>>>> m_rfnoc_ctrl_tdata, >>>>>>>>>> m_in_payload_tdata, s_out_payload_tdata. They have different >>>>>>>>>> widths than >>>>>>>>>> what the noc_shell expects. I think it's possible to change the >>>>>>>>>> payload_tdata width to 8 on the noc_shell by changing the >>>>>>>>>> item_width in >>>>>>>>>> your YAML, but you'll want to regenerate the noc_shell to do that >>>>>>>>>> (be >>>>>>>>>> careful not to overwrite your other files if you do this). But >>>>>>>>>> the ctrl bus >>>>>>>>>> must be 32-bit. >>>>>>>>>> - The ctrlport_clk has no driver. It looks like you specified >>>>>>>>>> ce_clk as the clock domain in your YAML, so perhaps that's the >>>>>>>>>> clock you >>>>>>>>>> want to use? >>>>>>>>>> >>>>>>>>>> Try resolving these issues and see where that gets you. >>>>>>>>>> >>>>>>>>>> Wade >>>>>>>>>> >>>>>>>>>> On Wed, May 11, 2022 at 2:19 PM Jeffrey Cuenco < >>>>>>>>>> jeffrey.cue...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Wade, >>>>>>>>>>> >>>>>>>>>>> Please see attached. Thanks! >>>>>>>>>>> >>>>>>>>>>> -Jeff >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On May 11, 2022, at 08:42, Wade Fife <wade.f...@ettus.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Can you also share your block's YML and the noc_shell you >>>>>>>>>>> generated? >>>>>>>>>>> >>>>>>>>>>> Wade >>>>>>>>>>> >>>>>>>>>>> On Wed, May 11, 2022 at 4:27 AM Jeffrey Cuenco <jcue...@ucsd.edu> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Wade, >>>>>>>>>>>> >>>>>>>>>>>> Yes, I have the ctrlport:has_status set to False in the block >>>>>>>>>>>> YAML... I ended up having to comment out that test sequence to >>>>>>>>>>>> move onto >>>>>>>>>>>> the part that sends samples into and out of the block; now I have >>>>>>>>>>>> an error >>>>>>>>>>>> that states >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Fatal: Timeout: Test "Test passing through samples" time limit >>>>>>>>>>>> exceeded* >>>>>>>>>>>> so I must be doing something that it isn't liking :) I've >>>>>>>>>>>> attached my updated .v and .sv files that I modified based on your >>>>>>>>>>>> guidance >>>>>>>>>>>> in your first response, as well as the updated xsim.log. Please >>>>>>>>>>>> let me know >>>>>>>>>>>> if there are any additional things I may need to change such as >>>>>>>>>>>> sizes and >>>>>>>>>>>> what not - thanks! >>>>>>>>>>>> >>>>>>>>>>>> -Jeff >>>>>>>>>>>> >>>>>>>>>>>> On Mon, May 9, 2022 at 3:12 PM Wade Fife <wade.f...@ettus.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Jeffrey, >>>>>>>>>>>>> >>>>>>>>>>>>> Very curious that you're getting that CTRL_STS_OKAY error, >>>>>>>>>>>>> since it looks like you're not using the status. I assume >>>>>>>>>>>>> ctrlport:has_status is set to False in your block's YAML? In that >>>>>>>>>>>>> case the >>>>>>>>>>>>> status should always be OK. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) For different input/output packet sizes, you need to modify >>>>>>>>>>>>> the context to set the payload length of the outgoing packet. >>>>>>>>>>>>> That's the >>>>>>>>>>>>> block of code starting on line 283 in the rfnoc_block_conv.v file >>>>>>>>>>>>> you sent. >>>>>>>>>>>>> There's an example in rfnoc_block_logpower, in which the output >>>>>>>>>>>>> packet >>>>>>>>>>>>> length is half the length of input packets. In your case you'll >>>>>>>>>>>>> need to set >>>>>>>>>>>>> it to 3/2 instead of 1/2. See here: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_logpwr/rfnoc_block_logpwr.v#L202 >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_master_fpga_usrp3_lib_rfnoc_blocks_rfnoc-5Fblock-5Flogpwr_rfnoc-5Fblock-5Flogpwr.v-23L202&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=GXbgyQxDz4yiy7ZI94I9ia-1XvF2rdmrbxprVfQojmcljlWVOVrjE1Z7g7qsBL_a&s=WkFBbmpL8IpvF2oHp-4Vfhy73qA49jSJD2tHoTQ0anQ&e=> >>>>>>>>>>>>> >>>>>>>>>>>>> 2) The testbenches typically have an ITEM_W constant that >>>>>>>>>>>>> indicates the size of the data type you want to work with. The >>>>>>>>>>>>> ITEM_W is >>>>>>>>>>>>> normally set to the sample size (e.g., 32 for sc16 samples). >>>>>>>>>>>>> Since you want >>>>>>>>>>>>> to work with bytes, you could change that to 8 then create an >>>>>>>>>>>>> item_t array >>>>>>>>>>>>> and send it as a single packet using blk_ctrl.send_items(). Then >>>>>>>>>>>>> you can >>>>>>>>>>>>> call blk_ctrl.recv_items() to get the data output packet, and >>>>>>>>>>>>> inspect the >>>>>>>>>>>>> items array that is returned. Take a look at PkgRfnocBlockCtrlBfm >>>>>>>>>>>>> to see >>>>>>>>>>>>> what other send/recv methods are available. Here's a quick >>>>>>>>>>>>> example assuming >>>>>>>>>>>>> the item size is 8-bit: >>>>>>>>>>>>> >>>>>>>>>>>>> item_t sent[$], received[$]; >>>>>>>>>>>>> sent = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; // Whatever values >>>>>>>>>>>>> you want for the input packet, one byte per element >>>>>>>>>>>>> blk_ctrl.send_items(0, sent); >>>>>>>>>>>>> >>>>>>>>>>>>> blk_ctrl.recv_items(0, received); >>>>>>>>>>>>> foreach(received[i]) begin >>>>>>>>>>>>> // Compare the expected value to the byte in received[i] and >>>>>>>>>>>>> see if it matches >>>>>>>>>>>>> end >>>>>>>>>>>>> >>>>>>>>>>>>> Wade >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, May 9, 2022 at 1:30 PM Jeffrey Cuenco via USRP-users < >>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Long time no see! I am currently on a final stretches of >>>>>>>>>>>>>> completing a masters project for my wireless embedded systems >>>>>>>>>>>>>> program that >>>>>>>>>>>>>> involves a USRP X310 with RFNoC 4.0 and GNURadio that implements >>>>>>>>>>>>>> a >>>>>>>>>>>>>> Hierarchical Modulation design using nested 4QAM / QPSK (final >>>>>>>>>>>>>> constellation "appears" like 16QAM but has embedded high >>>>>>>>>>>>>> priority and low >>>>>>>>>>>>>> priority layers that can adapt based on SNR). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am currently attempting to integrate the Xilinx >>>>>>>>>>>>>> Convolutional Encoder v9.0 IP block into the template >>>>>>>>>>>>>> rfnoc_block_conv.v >>>>>>>>>>>>>> design that was created using rfnocmodtool and modeled after the >>>>>>>>>>>>>> Ettus FFT >>>>>>>>>>>>>> example. With a bit of work I was able to get the .xci file >>>>>>>>>>>>>> loaded by >>>>>>>>>>>>>> Vivado when the make target is executed for the testbench, and >>>>>>>>>>>>>> the >>>>>>>>>>>>>> testbench appears to build without much modification. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When executing 'make rfnoc_block_conv_tb' it appears to >>>>>>>>>>>>>> fully execute the build process to the end, but I receive a >>>>>>>>>>>>>> fatal "Did not >>>>>>>>>>>>>> receive CTRL_STS_OKAY status" message in the process which I >>>>>>>>>>>>>> attribute to >>>>>>>>>>>>>> either something not being configured in the testbench file or >>>>>>>>>>>>>> something >>>>>>>>>>>>>> not being configured right in my verilog module file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've attempted to summarize where I'm stuck and need help on >>>>>>>>>>>>>> in the below three summary points / questions: >>>>>>>>>>>>>> 1) I have configured the convolutional encoder with rate 1/2 >>>>>>>>>>>>>> and punctured (effective rate 2/3), which I assume will require >>>>>>>>>>>>>> me >>>>>>>>>>>>>> modifying the "axi_wrapper" so that the output to input ratios >>>>>>>>>>>>>> are set >>>>>>>>>>>>>> properly - are there additional examples that I can follow for >>>>>>>>>>>>>> this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've seen the axi_wrapper migration note but as I'm still a >>>>>>>>>>>>>> novice at Verilog and System Verilog additional examples would >>>>>>>>>>>>>> be helpful. >>>>>>>>>>>>>> :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) I would like to modify my testbench so that I send 10 >>>>>>>>>>>>>> bytes (80 bits) of data, and read out the 15 bytes (120 bits) >>>>>>>>>>>>>> that get spit >>>>>>>>>>>>>> out and verify that the encoded bytes coming out of the core >>>>>>>>>>>>>> match ground >>>>>>>>>>>>>> truth data I would generate using MATLAB. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do we have any additional testbench examples or additional >>>>>>>>>>>>>> documentation that show sending 1 or more bytes of data through >>>>>>>>>>>>>> an IP core? >>>>>>>>>>>>>> The IP core's *s_axis_data_tdata* and *m_axis_data_tdata *are >>>>>>>>>>>>>> 8-bit while most of the examples show sending 32 bits. Aside >>>>>>>>>>>>>> from setting >>>>>>>>>>>>>> the assignments to [7:0] are there any other adjustments that >>>>>>>>>>>>>> need to be >>>>>>>>>>>>>> made in any of the signal declarations and/or block definition >>>>>>>>>>>>>> wires >>>>>>>>>>>>>> earlier in the file? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've provided the IP core documentation for reference just in >>>>>>>>>>>>>> case: >>>>>>>>>>>>>> https://docs.xilinx.com/v/u/en-US/pg026_convolution >>>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.xilinx.com_v_u_en-2DUS_pg026-5Fconvolution&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=Y3cOHwFMBDXttsqnINKoCyXB-ta6yD08QrmMzW9aeZY&m=GXbgyQxDz4yiy7ZI94I9ia-1XvF2rdmrbxprVfQojmcljlWVOVrjE1Z7g7qsBL_a&s=VpTL0Eev0xGrPxywg6lGumMok1Lx8kj5t4uFefeMWNA&e=> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've also included the module and testbench files as well as >>>>>>>>>>>>>> the xsim log. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks in advance! >>>>>>>>>>>>>> -Jeff >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>>>>>>> To unsubscribe send an email to >>>>>>>>>>>>>> usrp-users-le...@lists.ettus.com >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>> >>> >>> >>> Jeffrey Cuenco >>> Tech & Marketing Specialist | Cooperative Capitalist >>> (619) 840-4508 >>> jeffrey.cue...@gmail.com >>> >>> LinkedIn: >>> https://www.linkedin.com/in/jeffrey-g-cuenco/ >>> >>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
