[USRP-users] Re: What's means ce_clk in orginal USRP blocks? as it is not in rfnoc-example ....

[Jeffrey Cuenco via USRP-users]

Hello,

I am also currently developing with UHD v4.1.0.5 and the default verilog
template code generated by *rfnoc_mod_tool *does not automatically include
ce_clk.

If you would like to use ce_clk you can use the *rfnoc_create_verilog* tool
to regenerate and customize the verilog code from the template with
parameters you specify in your block .YML file.

Example:

python3 $PATH_TO_UHD_DIR/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py
-c $PATH_TO_BLOCK_YML/yourblock.yml -d $DESIRED_PATH/rfnoc_block_yourblock

If you are more interested in as to what the various clocks are intended to
be used for, the general explanation is that certain parts of RFNoC are
designed to operate at the primary bus clock of the USRP, yet one's logic
may need to operate at a different clock, especially if it was designed to
operate at a specific frequency... so the customizability is built into
RFNoC.

The following RFNoC 4 Workshop video may help provide more of a deep-dive:
https://www.youtube.com/watch?v=M9ntwQie9vs

There are also a few other slide materials (some from RFNoC 3 but are still
useful). Recommend going into the RFNoC 4 Migration Guide as it discusses
the differences if you have prior experience working with RFNoC 3

Slides: Part 1: Overview of RFNoC 4 -
https://kb.ettus.com/images/5/5b/rfno...

Part 2: Deep dive into RFNoC 4 - https://kb.ettus.com/images/e/e9/rfno...

Useful Knowledge Base Application Notes: Getting Started with RFNoC in UHD
4.0 - https://kb.ettus.com/Getting_Started_...

RFNoC 4 Migration Guide - https://kb.ettus.com/RFNoC_4_Migratio...

Other useful videos: Exploring RFNoC 4 with the UHD Python API -
https://youtu.be/fbcxm7f-Tj0
 RFNoC 3 workshop video -
https://youtu.be/VbODcrmpLaU


Hope this helps,
-Jeff

On Sat, May 21, 2022 at 2:33 AM sp h  wrote:

> when I examine RFNOC block that is in the below path, I am faced with a
> wire ce_clk and ce_rst, but in rfnoc-example there is not a ce_clk.
>
> uhd-4.1.0.5/fpga/usrp3/lib/rfnoc/blocks
>
> Can anyone guide me ce clocks?  why instead using rfnoc_chdr clk,
> original blocks uses ce clock?
>
>
> ___
> 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

[USRP-users] Re: RFNoC 4.0 OOT FPGA Testbench Writing Guidance?

[Jeffrey Cuenco via USRP-users]

gt;
>>>>>>>>>>> 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 
>>>>>>>>>>> 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 
>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>

[USRP-users] Re: RFNoC 4.0 OOT FPGA Testbench Writing Guidance?

[Jeffrey Cuenco via USRP-users]

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  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  
>> wrote:
>> Hi Wade,
>> 
>> Please see attached. Thanks!
>> 
>> -Jeff
>> 
>> 
>> 
>> 
>>>> On May 11, 2022, at 08:42, Wade Fife  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  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  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
>>>>>  
>>>>> 
>>>>> 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, r

[USRP-users] Re: RFNoC 4.0 OOT FPGA Testbench Writing Guidance?

[Jeffrey Cuenco via USRP-users]

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  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

[USRP-users] RFNoC 4.0 OOT FPGA Testbench Writing Guidance?

[Jeffrey Cuenco via USRP-users]

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

I've also included the module and testbench files as well as the xsim log.

Thanks in advance!
-Jeff


rfnoc_block_conv.v
Description: Binary data


rfnoc_block_conv_tb.sv
Description: Binary data


xsim.log
Description: Binary data
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] [Clarification]: Reminder: GNU Radio and RFNoC Hackfest, Nov 12-16 in Santa Clara, CA!

[Jeffrey Cuenco via USRP-users]

Hi again,

I received a few questions from some of you wanting to attend if it’s
possible to just attend a few days instead of all 5, and I just want to
clarify for everyone that the answer is yes. :)

Whether you are attending all 5 days or can only make one or a few, please
still RSVP to the Eventbrite if you haven’t yet already.

After registering via Eventbrite, please also reply to this message letting
me know which specific days you will be attending so that I have an
accurate headcount each day for food.

Thanks!

-- Forwarded message -
From: Jeffrey Cuenco 
Date: Sun, Nov 4, 2018 at 17:24
Subject: Reminder: GNU Radio and RFNoC Hackfest, Nov 12-16 in Santa Clara,
CA!
To: usrp-users@lists.ettus.com 


Hi everyone,

Just a friendly reminder that our GNU Radio and RFNoC Hackfest is coming up
next week, so if you were planning on coming and haven’t RSVP’d yet, please
do so via the link below!

If you’re having trouble looking for places with reasonable lodging, below
are a few places with nightly rates < $200/night. It is recommended to get
a rental car or budget up to $50/day for Uber/Lyft rides to and from our NI
Santa Clara office (off peak average cost is about $10 each way, but can
increase during rush hour traffic times).


Days Inn Sunnyvale
504 Ross Dr
Sunnyvale, CA  94089


Vagabond Inn Sunnyvale
816 W Ahwanee Ave
Sunnyvale, CA  94085


Motel 6 Sunnyvale (two locations literally across the street from each
other):

Motel 6 Location 1
806 W Ahwanee Ave
Sunnyvale, CA  94085
United States

Motel 6 Location 2
775 N Mathilda Ave
Sunnyvale, CA 94086
United States


Travel Inn Sunnyvale
590 N Mathilda Ave
Sunnyvale, CA 94086
United States

-- Forwarded message -

*Greetings USRP Community,*

Announcing the *GNU Radio* and *RFNoC Hackfest* at NI Silicon Valley!

The GNU Radio and RFNoC HackFest will provide an opportunity for SDR
developers to collaborate in person, and work on problems, bugs, or
projects related to GNU Radio and RFNoC.

*When*

November 12th - 16th, 2018 (Monday - Friday)

*Where*

National Instruments
4600 Patrick Henry Dr
Santa Clara, CA 95054

This event is designed to provide a stage for people to talk in front of
fellow developers about problems they're currently working on. The majority
of the week will be reserved for working groups to collaboratively
discuss, work and debug issues related to GNU Radio and RFNoC projects. To
help facilitate discussions and help with issues, Ettus Research software
engineers will be on hand throughout the week.

On Wednesday, an update on the future of RFNoC will be shared with
participants.

*Logistics*

This is a free event hosted by National Instruments and food and drinks
will be provided throughout the week.

The National Instruments office in Santa Clara is within 7 miles of the
Norman Y. Mineta San Jose International Airport (SJC), and there are plenty
of hotels within a 1-5 mile radius.

Please RSVP using the link below:
https://www.ettus.com/gnu-radio-hackfest

We look forward to seeing you there!


-- 

Jeffrey Cuenco USRP Software Product Manager Ettus Research Phone:
+1-619-840-4508 Fax: +1-866-807-9801

-- 

Jeffrey Cuenco USRP Software Product Manager Ettus Research Phone:
+1-619-840-4508 Fax: +1-866-807-9801
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Reminder: GNU Radio and RFNoC Hackfest, Nov 12-16 in Santa Clara, CA!

[Jeffrey Cuenco via USRP-users]

Hi everyone,

Just a friendly reminder that our GNU Radio and RFNoC Hackfest is coming up
next week, so if you were planning on coming and haven’t RSVP’d yet, please
do so via the link below!

If you’re having trouble looking for places with reasonable lodging, below
are a few places with nightly rates < $200/night. It is recommended to get
a rental car or budget up to $50/day for Uber/Lyft rides to and from our NI
Santa Clara office (off peak average cost is about $10 each way, but can
increase during rush hour traffic times).


Days Inn Sunnyvale
504 Ross Dr
Sunnyvale, CA  94089


Vagabond Inn Sunnyvale
816 W Ahwanee Ave
Sunnyvale, CA  94085


Motel 6 Sunnyvale (two locations literally across the street from each
other):

Motel 6 Location 1
806 W Ahwanee Ave
Sunnyvale, CA  94085
United States

Motel 6 Location 2
775 N Mathilda Ave
Sunnyvale, CA 94086
United States


Travel Inn Sunnyvale
590 N Mathilda Ave
Sunnyvale, CA 94086
United States

-- Forwarded message -

*Greetings USRP Community,*

Announcing the *GNU Radio* and *RFNoC Hackfest* at NI Silicon Valley!

The GNU Radio and RFNoC HackFest will provide an opportunity for SDR
developers to collaborate in person, and work on problems, bugs, or
projects related to GNU Radio and RFNoC.

*When*

November 12th - 16th, 2018 (Monday - Friday)

*Where*

National Instruments
4600 Patrick Henry Dr
Santa Clara, CA 95054

This event is designed to provide a stage for people to talk in front of
fellow developers about problems they're currently working on. The majority
of the week will be reserved for working groups to collaboratively
discuss, work and debug issues related to GNU Radio and RFNoC projects. To
help facilitate discussions and help with issues, Ettus Research software
engineers will be on hand throughout the week.

On Wednesday, an update on the future of RFNoC will be shared with
participants.

*Logistics*

This is a free event hosted by National Instruments and food and drinks
will be provided throughout the week.

The National Instruments office in Santa Clara is within 7 miles of the
Norman Y. Mineta San Jose International Airport (SJC), and there are plenty
of hotels within a 1-5 mile radius.

Please RSVP using the link below:
https://www.ettus.com/gnu-radio-hackfest

We look forward to seeing you there!


-- 

Jeffrey Cuenco USRP Software Product Manager Ettus Research Phone:
+1-619-840-4508 Fax: +1-866-807-9801
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] GNU Radio and RFNoC Hackfest, Nov 12-16 in Santa Clara, CA!

[Jeffrey Cuenco via USRP-users]

*Greetings USRP Community,*

Announcing the *GNU Radio* and *RFNoC Hackfest* at NI Silicon Valley!

The GNU Radio and RFNoC HackFest will provide an opportunity for SDR
developers to collaborate in person, and work on problems, bugs, or
projects related to GNU Radio and RFNoC.

*When*

November 12th - 16th, 2018 (Monday - Friday)

*Where*

National Instruments
4600 Patrick Henry Dr
Santa Clara, CA 95054

This event is designed to provide a stage for people to talk in front of
fellow developers about problems they're currently working on. The majority
of the week will be reserved for working groups to collaboratively
discuss, work and debug issues related to GNU Radio and RFNoC projects. To
help facilitate discussions and help with issues, Ettus Research software
engineers will be on hand throughout the week.

On Wednesday, an update on the future of RFNoC will be shared with
participants.

*Logistics*

This is a free event hosted by National Instruments and food and drinks
will be provided throughout the week.

The National Instruments office in Santa Clara is within 7 miles of the
Norman Y. Mineta San Jose International Airport (SJC), and there are plenty
of hotels within a 1-5 mile radius.

Please RSVP using the link below:
https://www.ettus.com/gnu-radio-hackfest

We look forward to seeing you there!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com