# Latest Hackfest **URL:** \ **Category:** GNU Radio\ **Created:** [April 3, 2014, 7:34pm UTC](https://www.ruby-forum.com/t/latest-hackfest/240243 "2014-04-03T19:34:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [April 3, 2014, 7:34pm UTC](https://www.ruby-forum.com/t/latest-hackfest/240243/1 "2014-04-03T19:34:01Z")
We had our latest GNU Radio Hackfest last week at Ettus R… It was a fantastic week with a lot of good work getting done. If you’re interested in what we are working on and to get a glimpse of some of the new things we’ll be rolling out in the next few GNU Radio versions, find our working notes here: [http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1403-2](http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1403-2) Thanks to everyone who came and hacked with us. Thanks, too, to Ettus Research for being great hosts for our motley band of developers! Tom ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [April 3, 2014, 9:06pm UTC](https://www.ruby-forum.com/t/latest-hackfest/240243/2 "2014-04-03T21:06:52Z")
Dear Tom, I have read about the FEC work done during the Hackfest, so this would be an appropriate time to bring this up. We have participated in the Darpa Spectrum Challenge, and developed some good and fast codes. Specifically, we have a generic convolutional code encoder and decoder (any R and K is supported, tailbiting can be enabled), with fast SSE implementation. In the attached BER figure we have used R=1/8, K=9 and length = 3 bytes = 24 bits for encoding headers. The speed is not much worse than the spiral generated one. More importantly, we have a specially crafted version of a repeat accumulate coder/decoder that can be quickly decoded with SSE. On the figure we have used rates 1/3, 1/2, 1/3 and 4/5 with a payload size of 1440 bytes. On the orbit-lab machines (core-i7) our SSE code can decode more than 1000 packets per second on a single core. I plan to release this code under the GPL (and maybe under an MIT license as well) after I have a paper written up about it. So the question would be: 1. how to incorporate this into gnuradio (separate OOT or built in) 2. how to deal with puncturing (we have some good generic solution) 3. how to deal with variable packet lengths and variable rates (have some ides) 4. how mature is the FEC API, can it be modified if needed? Best, Miklos ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [April 4, 2014, 12:23am UTC](https://www.ruby-forum.com/t/latest-hackfest/240243/3 "2014-04-04T00:23:06Z")
On Thu, Apr 3, 2014 at 3:05 PM, Miklos M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > specially crafted version of a repeat accumulate coder/decoder that > can be quickly decoded with SSE. On the figure we have used rates 1/3, > 1/2, 1/3 and 4/5 with a payload size of 1440 bytes. On the orbit-lab > machines (core-i7) our SSE code can decode more than 1000 packets per > second on a single core. > > I plan to release this code under the GPL (and maybe under an MIT > license as well) after I have a paper written up about it. So the > question would be: Miklos, This sounds like a fantastic result. > 1. how to incorporate this into gnuradio (separate OOT or built in) If it’s to go into GNU Radio, it would only be license GPLv3, like the rest of the code base. Also, we require a copyright transfer from you. We can discuss and work on that on the side. Also, with the use of SSE, we’d want to separate the code into a VOLK kernel with a generic and SSE implementation. That way, we’re not restricting ourselves to certain platforms. And then, we can extend it to other SIMD architectures. > 1. how to deal with puncturing (we have some good generic solution) We let the FEC API encoder and decoder blocks handle the puncturing and depuncturing separate from the coders themselves. I think they are generic enough, but we’d probably want to update them if they don’t fit every scenario. > 1. how to deal with variable packet lengths and variable rates (have some > ides) The FEC API encoder/decoder blocks don’t care about the packet lengths as long as the coders themselves can handle it. Right now, our working example uses fixed packet length, but (I don’t think) that’s a requirement. Might have to double-check this. Same should go for the rate. In the FEC API world, there is an FEC encoder and decoder block that sets just a few parameters. One of them is the variable that actually defines the encoder and decoder code, and those variables are designed to work with the API. So most of this is on how these variable blocks are built. > 1. how mature is the FEC API, can it be modified if needed? It’s mature in that we’ve tested it out-of-tree with a number of situations. But as we’re moving it into GNU Radio, there’s a window here to update it. Best done before we merge it into master, though, which will set the API until 3.8 of GNU Radio. It’d be great if you could take my current github repo branch “fecapi” and see about fitting your coder into it. That’ll get us some feedback before we merge into master. > Best, > Miklos Thanks! Tom ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [April 7, 2014, 8:26pm UTC](https://www.ruby-forum.com/t/latest-hackfest/240243/4 "2014-04-07T20:26:06Z")
On Mon, Apr 7, 2014 at 11:52 AM, Miklos M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > > > be an appropriate time to bring this up. We have participated in the > > > second on a single core. > > > > with a generic and SSE implementation. That way, we’re not restricting > > ourselves to certain platforms. And then, we can extend it to other SIMD > > architectures. > > I have thought about it. I know that all SSE code is currently > separated into a VOLK kernel (with the exception of FFT which is > coming from a separate library). Of course you can do that, but then > most of the gnuradio blocks will be just wrappers around the VOLK > kernels. Yeah, so what? Seriously, this is a good thing, not a problem. The more we can wrap up into volk, the easier it is to use on multiple platforms and reuse in other situations. We won’t put any SIMD code into GNU Radio at this point that doesn’t come through VOLK since VOLK handles the mechanics of dealing with multiple platforms and different available SIMD architectures. > blocks and reorders (permutes) them and extends them with zero at > arbitrary places. Basically it takes a map (integer list between -1 > and N-1) where -1 means “zero out” and 0 through N-1 means some > element of the input. Probably it is harder to explain than to see it. > Anyhow, the puncturing design is important and you have to omit > encoded (unsigned char) hard bits and insert soft (float) zeros. Having the block interleaver would be nice. We have the generic puncturer block, as I said, but if you have them roped together, seems like (I’m guessing) it should be easy to use this block as an interleaver and/or a puncture block. I’m assuming you have the deinterleaver/depuncture block as well? > > In the FEC API world, there is an FEC encoder and decoder block that sets > > just a few parameters. One of them is the variable that actually defines > > the > > encoder and decoder code, and those variables are designed to work with > > the > > API. So most of this is on how these variable blocks are built. > > Do you have a working coder/decoder pair with this API? [https://github.com/trondeau/gnuradio/tree/fecapi](https://github.com/trondeau/gnuradio/tree/fecapi) We’re still messing around with things right now, so this is all work-in-progress right now (in other words, it’s a bit messy). > get > > > us some feedback before we merge into master. > > Probably the best would be to put my code (separate it from the rest) > into a OOT module for you to see it, and then we pick up the > discussion from there. > > Miklos Sure. If you can fit your encoder/decoder blocks into FEC API-style variables, it’ll be easy to use within our system and would make vetting it for incorporation easier, too. Tom ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [April 7, 2014, 5:53pm UTC](https://www.ruby-forum.com/t/latest-hackfest/240243/5 "2014-04-07T17:53:38Z")
Hi Tom, On Fri, Apr 4, 2014 at 12:21 AM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > (any R and K is supported, tailbiting can be enabled), with fast SSE > > license as well) after I have a paper written up about it. So the > > If it’s to go into GNU Radio, it would only be license GPLv3, like the rest > of the code base. Also, we require a copyright transfer from you. We can > discuss and work on that on the side. > > Also, with the use of SSE, we’d want to separate the code into a VOLK kernel > with a generic and SSE implementation. That way, we’re not restricting > ourselves to certain platforms. And then, we can extend it to other SIMD > architectures. I have thought about it. I know that all SSE code is currently separated into a VOLK kernel (with the exception of FFT which is coming from a separate library). Of course you can do that, but then most of the gnuradio blocks will be just wrappers around the VOLK kernels. > > 1. how to deal with puncturing (we have some good generic solution) > > We let the FEC API encoder and decoder blocks handle the puncturing and > depuncturing separate from the coders themselves. I think they are generic > enough, but we’d probably want to update them if they don’t fit every > scenario. I have a generic interleaver / puncturer that takes chunks of memory blocks and reorders (permutes) them and extends them with zero at arbitrary places. Basically it takes a map (integer list between -1 and N-1) where -1 means “zero out” and 0 through N-1 means some element of the input. Probably it is harder to explain than to see it. Anyhow, the puncturing design is important and you have to omit encoded (unsigned char) hard bits and insert soft (float) zeros. > just a few parameters. One of them is the variable that actually defines the > encoder and decoder code, and those variables are designed to work with the > API. So most of this is on how these variable blocks are built. Do you have a working coder/decoder pair with this API? > > 1. how mature is the FEC API, can it be modified if needed? > > It’s mature in that we’ve tested it out-of-tree with a number of situations. > But as we’re moving it into GNU Radio, there’s a window here to update it. > Best done before we merge it into master, though, which will set the API > until 3.8 of GNU Radio. It’d be great if you could take my current github > repo branch “fecapi” and see about fitting your coder into it. That’ll get > us some feedback before we merge into master. Probably the best would be to put my code (separate it from the rest) into a OOT module for you to see it, and then we pick up the discussion from there. Miklos