The competition, along with its organizers, look to set a new standard in wireless efficiency and durability. This is done by providing a simulated wireless environment and scoring structure that challenges competitors to build resilient and reliable radios. More detailed information can be found on their website.
The Radio Resilience Competition debuted at the GNURadio Conference 2020. Their presentation on the competition and the simulated environment is linked below.
Competition Environment
2 blue competitor radios, 1 red interferer radio, and channel muxer containers are built using Docker along with the score marshaling container that controls the scoring traffic to be passed between radios.
competitor score is achieved by the maximum number of consecutive scoring packets are provided to the scoring marshaller.
both competitor radios can transmit and receive data therefore a robust radio architecture can be developed to pass messages other than scoring traffic between the radios.
Initial Blue Radios
The competition provides a transmit and receive radio architecture that is fully capable of competing. These GNURadio flowgraphs take advantage of custom blocks provided by the competition that instantiate the Liquid DSP FlexFrame radios.
Base Blue1 
Base Blue2
Initial Red Radio
The competition also provides an initial interfering radio that blocks half the frequency band from use. This is done using a fast noise source block, frequency shift, and filtering.
Clone the Simulator Environment
To get started they provide a GitLab repository that contains all the code you need to get started. You will need to install both docker and docker-compose as well as an application called baudline which is a powerful spectrum visualization tool, albeit closed source, if you want to view the IQ spectrum while the match plays out.
It would also be helpful to install GNURadio, LiquidDSP, and the gr-rircsim OOT blocks on your local machine if you want to run some quick flowgraph tests without running the entire Docker container environment. This is particularly useful in debugging grc flowgraph errors that might occur in embedded python blocks.
Scrimmages
Each week the competition held a scrimmage between the competitors and an interfering red radio. These scrimmages provide scores back to the competitors to assess how they are doing in the overall competition. I competed in 4 of the 5 Scrimmages that were run. Here is a little bit about each one, what I tried to accomplish that week, and the results.
S1
I was not able to make it to the first scrimmage since I was too busy with work and other projects. But I decided to join the first video conference anyway because I was excited to compete in the next scrimmage.
This week the interferer was denying half the IQ channel.
S2
My first entry was an intentionally narrowband signal as I was not able to fully implement my main idea yet. The narrowband signal was created by using the base FlexFrameTX and RX blocks provided but then resampling the output to create a smaller bandwidth within the IQ channel.
S2 Blue1 
S2 Blue2
This week the interferer was called a bathtub interferer. This is where the interfering power level, across the entire IQ channel, increased over the duration of the test. Until the entire band was essentially blocked.
My narrowband radio was able to deliver packets but due to the decreased bandwidth, the score turned out fairly low.
S3
I Didn’t submit an updated radio this time. It’s hard to get something working on the side but I am learning more every time! This week I was working to get Direct Sequence Spread Spectrum (DSSS) working on my radio. The design used a simple parallel acquisition method with a python module and a function probe block to poll the data! The parallel energy detector was using a hierarchical block to tame the mess.
The interferer this week was a pulsed modification on the bathtub interference from the last scrimmage.
My previous submission did ok, as the red radio being used was similar to last week’s.
S4
This week I was able to submit my new radio that has DSSS. This was in order to try to combat my own red radio submission. In order to enable DSSS, I created hierarchical blocks to encapsulate both the transmit chip and receiver synchronization. This required me to change the competitor docker file to pull in the new grc files for the hierarchical blocks. The parallel DSSS uses a small barker sequence for the chip and energy detectors on each of the delayed versions of the sequence.
The above image is a small snippet of the block as I could not get the entire flowgraph in the screenshot. Along with this block, a python module accumulated the output energies per delay and selected the largest to be used as the main path delay going into the FlexFrameRX. The submitted design used a longer chip sequence to enable a higher resampling rate.
S4 Blue1 
S4 Blue2
The red radio this week was a slightly frequency shifted version of my red radio submission that replays a delayed version of the IQ that it sees on the channel.
Unfortunately the modifications to the red radio I submitted that the organizers introduced caused my radio to have too much interference causing CRC errors early on.
S5
I worked on modifying my parallel DSSS to run in serial search with a GLFSR source as the PN. I also worked on encapsulating the scoring packets so I could enable retransmission feedback. The problem that I was running into was that the end of burst tags that inform the muxer when to expect IQ were getting obscured by my resampling and DSSS blocks I created in GNURadio. This complicated my design significantly as I would need to move the resamplers and DSSS inside the C++ FlexFrameTX. Therefore in the scrimmage, I used an old image that used my previous DSSS parallel algorithm that had a higher FEC and lower modulation rate.
This week the red radio was a toned-down version of last week’s delayed repeat interferer that I originally submitted.
The results for my radio were not that great this round, as the parallel algorithm was still causing issues in the competition environment.
The Finale
I was able to work on my final submission a bit over the holidays but was also hindered by a server outage back home which ment I had to re-implement most of my radio code as my last gitlab commit was a bit old.
I tried to implement a simple radio with encapsulation and retransmission. The problem was that I was still running into eob_tag issues so I had to work around it with a keep-alive PDU signal. I believe this is also causing some of my re-transmission logic to lock up in some scenarios, but I was able to submit my radio!
Final Blue1 
Final Blue2
The format for the final was a bit different than the previous scrimmages. This time there were three different rounds that had different interfering patterns that were taken from the past scrimmages.
My radio worked just well enough that I didn’t get last place! This is really just the beginning as I have learned so much about GNURadio, LiquidDSP, Docker, and Python PMTs.
My Red Radio Submission
I also submitted a red radio that would try to interfere with competitors. I created a dynamic interferer that would re-transmit or re-play a delayed version of the IQ channel. The two variants were a fixed amplitude delay re-transmitter and a swept amplitude delay re-transmitter. These are now included in the main Simulator GitLab repo for the competition!
The competition organizers also needed the main simulator environment updated because of the feedback occurring at the red radio input caused some unintended artifacts in the channel.
Apparently, I submitted a “Particularly Evil Red Radio” as one of the organizers put it, which made my day! A version of this radio was used in two of the scrimmages as well as the final.
What’s Next
My next step is to keep working on my radio for the next phase of the competition, but first I want to plan out a strategy based on what I have learned. I think the biggest change I can make is to not get too ambitious and make small incremental improvements each week.
Howdy! Would you mind if I share your blog with my zynga group? There’s a lot of folks that I think would really appreciate your content. Please let me know. Cheers
Thank you for another fantastic post. Where else could anybody get that kind of info in such an ideal way of writing? I have a presentation next week, and I’m on the look for such info.