Phase 4 Ground Weekly Report!
Big week for Phase 4 and associated projects!
Rohde & Schwartz has announced a student competition (Enhancing Ron W6RZ GNURadio DVB-T2 implementation) that will almost certainly help Phase 4 Ground. This will be particularly helpful for terrestrial designs and operations.
More details here: https://engineering-competition.com/en/#engineering-competition
"GNURadio is part of this year’s Rohde & Schwarz Engineering Competition. Rohde & Schwarz is an international company specialized in electronic test equipment, broadcast electronics, radio communication and much more.
The Engineering Competition takes place every year and in this iteration, the students will look into the DVB-T2 blocks of GNURadio and will try to optimize and improve them while still complying with the official T2 standard.
There will be two rounds for the different participating countries, the first starts on April 1st, the second starts on May 1st and each lasts for about 3-4 weeks.
We will publish all code after the competition ends and plan to prepare a pull request with the most interesting stuff.
In addition, we would like to invite all students reading this list to join the competition. You can find more information on the official homepage at https://engineering-competition.com/en/
Best regards,
Joshua Schüler"
Please help spread the news. This competition directly helps us and many other amateur radio projects using GNU Radio and T2.
Feedback, comment and critique has come in for K4MOT's efforts to design a 5GHz RF board that properly amplifiers levels from the sort of SDRs we're considering. Another revision is expected "very soon". The first draft is here:
John Toscano is expected to release another revision for review of his 5GHz board "very soon". First draft released to this list a couple weeks back.
Paul Wade continues work on his paper on our dual feed project.
AMSAT has begun to plan for Hamvention 2017. If you are going and you are a volunteer, then you need to coordinate with Jerry Buxton et al for hotel information. Everything is new this year with a new site. The good news is that we have more room at the AMSAT booth. If you recall, being in the corner of the booth last year was a tight fit. Do you have a station prototype? Antenna prototype? App prototype? Bring it, we have the room to show it off.
Significant strides forward for planning the GNU Radio Conference in September 2017 in San Diego have been made. Please register, we aim to sell out. https://gnuradio.org/grcon-2017/ Phase 4 Ground will have a poster session and is considering helping sponsor the event. Several of us on the list are working on the radio puzzle challenge. I anticipate a lot of phase 4 ground collaboration and problem solving to happen here. We have a special event call sign of N6U for the conference and an amateur license exam session.
If you have a practical implementation in GNU Radio, then send in a presentation proposal! https://gnuradio.org/grcon-2017/submit/
If you know of someone that would be a fantastic keynote speaker, then please get me in touch with them.
Phase 4 Ground now has a presence at the IEEE Antennas and Propagation conference in San Diego in July. We are sharing a table with ARRL and GNU Radio. Check this conference out here: https://2017apsursi.org/
If you're coming to either conference, then know that both of them are making a big effort to include amateur radio in several significant ways.
At IEEE A&P, there's an amateur operator breakfast, your call sign is on your badge, we're planning a special event station and have a call here as well (N6P), and there's a license exam session here too. We're making a full-court press to get amateur radio promoted. These efforts have been welcomed and appreciated.
Ray Roberge and Paul Williamson are working hard on getting the set of GNU Radio flowgraphs in the in shape for demonstrations at Hamvention. We've learned quite a bit this week and uncovered some unoptimized parts that have been lurking below the surface for a while!
That repository is here:
https://github.com/phase4ground/satellite_ground_emulator
For example, what presents itself as a Qt mismatch on macOS has prevented a type of user interface from working. This works fine on linux, but that implementation appeared to be incomplete.
Underruns appear much worse now than they have for the "middle era" of prior demonstrations and we're still not sure exactly why. A set of instrumentation flowgraphs revealed what seem to be audio processing and quality problems. The NBFM demodulator in GNU radio might could use some attention in terms of audio output. CODE2 blocks work flawlessly with random input data, but the demodulated voice data falls on the floor sometimes. We have stability problems with GNU radio on macOS. We have python version management problems with GNU Radio. It's very susceptible to how python is deployed. Using PyBombs is a way around it, but we've had at least one catastrophic "which version does GNU Radio really use" situation that resulted in just scraping the machine and starting over again. The list goes on!
The advice from us for this week is therefore: pick a relatively fast machine that runs Ubuntu 16.04 and install GNU Radio with PyBombs. Don't use this machine for anything else that you cannot reinstall easily. Don't develop sentimental attachments. Don't fight against the current. If PyBombs throws a rod, then take the machine out back, shoot it, and start over.
When GNU Radio works well, then it works very well. When you color outside the box, then there is a lot of sadness. And tears. And delays. And errors that no one understands. So, just conform to "Linux, Ubuntu, 16.04, PyBombs" and you reduce the pain of the somewhat vertical learning curve involved.
If you have a working system that doesn't look like the above, then great! Use it. You can even brag about it. However, the advice above is advice directly from three core developers. Taking this advice to heart has greatly reduced crashes and the somewhat disheartening "I'm sorry, no one has ever seen that particular error message before" by 40dB.
GNU Radio is incredibly powerful. It's not a silver bullet, and it's not really easy to use. We are having a lot of fun making cool things happen, but there are plenty of sharp edges. The worst part is having a documentation tab for each and every block that is either completely empty or has writing that conflicts with what appears in the settings tab. It's rare to get a block that has helpful documentation. Reading source code for a block is routinely required.
This is the single biggest issue with GNU Radio. It comes up repeatedly in forums and mailing lists and chatrooms and discussion. I can't think of another tool (for users) where reading the source code is routinely required (for users). I have had confusing times with AldecHDL, and Xilinx Vivado, and Cadence tools, and git, and gcc, and adb, and numpy, and Tensorflow, and golang.
The difference I see in using them vs. using GNU Radio is that I have literally never had to go read source code to figure out how to use them.
Drawing a distinction between the often undocumented blocks and the tool underneath (GNU radio) doesn't really solve the problem. From the perspective of someone that uses gnuradio-companion, the tool is completely useless without the blocks.
There's a path forward, but it requires coordinated efforts to fully document blocks. Prioritizing accessibility (documentation) is hard, takes real work, and is often devalued compared to "doing math".
It will be very interesting to see how the blocks that come out of the Rohde & Schwartz engineering competition are documented. Will that be part of the judging or not?
OK more soon!
-Michelle W5NYV
"Sit vis vobiscum."