The Who What When Where Why
Open Research Institute is a non-profit dedicated to open source digital radio work on the amateur bands. We do both technical and regulatory work. Our designs are intended for both space and terrestrial deployment. We’re all volunteer and we work to use and protect the amtaeur radio bands.
You can get involved in our work by visiting https://openresearch.institute/getting-started
Membership is free. All work is published to the general public at no cost. Our work can be reviewed and designs downloaded at https://github.com/OpenResearchInstitute
We equally value ethical behavior and over-the-air demonstrations of innovative and relevant open source solutions. We offer remotely accessible lab benches for microwave band radio hardware and software development. We host meetups and events at least once a week. Members come from around the world.
Icom IC-905 10 GHz Polarization Issue
Good news for amateur radio operators using the Icom IC-905 10 GHz system!
Following feedback from the San Bernardino Microwave Society (SBMS), Gordon West WB6NOA, and other users, Icom America has agreed to address the polarization configuration issue that’s been affecting signal performance.
The issue: The IC-905’s dish antenna comes configured for vertical polarization. Vertical polarization is standard in Japan. However, most U.S. amateur microwave operations use horizontal polarization.
This mismatch has resulted in significant signal strength differences during contacts.
The solution is simple: rotate either the entire dish or just the feed horn 90 degrees to achieve horizontal polarization. However, many operators weren’t aware of this requirement.
Ray Novak (N9JA) from Icom America has committed to updating the product instructions and adding a label to the packaging that alerts customers about the dish’s default vertical polarization and how to configure it for horizontal operation.
Icom has also expressed willingness to work with SBMS on developing educational content about this issue, potentially including information about SBMS membership.
Amateur radio groups interested in contributing to this effort should contact Ray Novak directly at
raynovak@icomamerica.com.
This collaborative approach between manufacturers and the amateur radio community demonstrates how user feedback can lead to improved documentation and better user experiences for microwave enthusiasts.
Below is a diagram showing the 90 degree relationship between horizontal and vertical polarization. Rotating the dish or feed by 90 degrees restores the 20-30 dB loss that you will get if your equipment is cross-polarized.
Opulent Voice Protocol Development
Opulent Voice is an open source high bitrate digital voice (and chat, and data!) protocol developed by ORI. It’s designed as the native digital uplink protocol for ORI’s broadband microwave digital satellite transponder project. Opulent Voice (OPV) is good for both space and terrestrial use.
Locutus
The focus of most of the recent work has been on the minimum shift keying (MSK) modem, called Locutus. The target hardware for implementation is the PLUTO SDR from Analog Devices. See
https://github.com/OpenResearchInstitute/pluto_msk for source code, documentation, and installation instructions.
The modem in an excellent “rough draft” state. There are positive results in over-the-air testing.
Interlocutor: The Human-Radio Interface
Interlocutor is the part of the design that takes input audio, text, and keyboard chat from the operator and processes this data into frames for the modem.
Current Interlocutor code can be found at
https://github.com/OpenResearchInstitute/interlocutor
Interlocutor also handles received audio, text, and data. The target hardware for this part of the design is a Raspberry Pi version 4, with expectations that it will run on other Python-capable and/or Linux-based devices.
What’s Happened Since Our May 2025 Updates?
What were the “Next Steps” from last month? We intended to take the functional Opulent Voice framing, which successfully delivered Opus packets, and insert COBS, RTP, UDP, and IP layers in order to gain a substantial increase in functionality. All of that has happened. The stream of Opulent Voice frames are much more functional and can be handled by a very large number of existing applications. The additional overhead was well worth the investment of complexity and latency.
What Else is New?
We implemented configuration files. This is a YAML file that stores settings for the radio.
A configuration manager codebase was added to handle config file tasks.
We implemented audio hardware configuration files. This is a YAML file that stores settings for the audio hardware choices made by the operator.
We implemented an audio hardware manager. The audio hardware manager helps the operator test, list, and save audio hardware configurations. A microphone gain measurement and speaker test are included.
We wrote an automated test suite. It has four phases, with multiple tests per phase. As development proceeds, we can easily test if any code changes damage previously achieved functionality. If it’s in the test suite, then it needs to still be working regardless of anything we add to the codebase. This helps ensure a quality product moving forward.
Automated Test Suite Overview
Phase 1: Basic Operations
run_test “help_display”
run_test “version_info”
run_test “no_callsign”
run_test “invalid_callsign”
Phase 2: Command Line Options
run_test “audio_help_options”
run_test “list_audio_exits_clean”
run_test “test_audio_exits_clean”
run_test “setup_audio_handles_eof”
Phase 3: Network Configuration
run_test “custom_ip”
run_test “custom_port”
run_test “invalid_ip_accepted”
run_test “invalid_port”
Phase 4: Operating Modes
run_test “chat_only_mode”
run_test “verbose_mode”
run_test “quiet_mode”
Phase 5: Configuration File Handling
run_test “no_config_files”
run_test “partial_config”
run_test “corrupted_config”
run_test “good_config_loaded”
run_test “cli_overrides_config”
Next Steps?
If the Opus encoder does a good enough job of detecting when the speaker is silent, we can take advantage of those silence frames to send (fragments of) waiting control, text, or data packets. This would be useful mainly if we are also multiplexing multiple streams with an advance variant of COBS.
We have an ongoing discussion on how to deal with the potential problem of getting out-of-order frames, which may happen when we use Interlocutor with a remote computer network, or with a modem that is (significantly) remote.
An out-of-order Opulent Voice frame problem isn’t expected to occur over the radio link. Packets either get through or they don’t, but never out of order, because they are always transmitted in order and there’s no mechanism to retry transmitting them later. This assumes that the modem is located close to Interlocutor.
So the problem can only occur if we try to use this radio link protocol as a network (transport) protocol, which can introduce complications like out of order delivery. This happens when we’re communicating to another computer with Interlocutor software, over the Internet. Which, we expect people might want to do.
The obvious solution here is to use TCP, which is designed as a transport protocol. TCP can turn a channel that delivers packets unreliably and possibly out of order into a channel that never does either of those things. Bytes always arrive perfectly correct and perfectly in order, or else the link fails.
So where we are using just UDP to encapsulate our OPV frames on a short wire between the host and the modem, we would probably want to use TCP on a network link if we for some reason wanted to remote the modem over a network.
Since we already have a configuration item for “computer” or “modem”, then we have a way to distinguish between the two modes. The difference between the two modes right now in the code is that selecting “computer” means a KEEPALIVE signal is sent as a control channel message. The KEEPALIVE is not sent when Interlocutor is configured as being connected to a “modem”. We could use TCP in computer and UDP in modem. Discussions on this will continue!
Voice detection or VOX? Live voice-to-text transcripts? Smart QSO logging?
Want to Help?
If you would like to help make these and the many other things that we do happen more quickly or better, then you are welcome at ORI!
Read over our code of conduct and developer and participant policies on our website at https://www.openresearch.institute/developer-and-participant-policies/, and then visit our getting started page at https://www.openresearch.institute/getting-started/
Efficiently Using Transmitted Symbol Energy via Delay-Doppler Channels – Part II
by Pete Wychoff, KA3WCA
Inner Circle Sphere of Activity
If you know of an event that would welcome ORI, please let your favorite board member know at our hello at openresearch dot institute email address.
30 June 2025 – Future Amateur Geostationary Payload Definitions comment deadline. Our submission was submitted on time and has been acknowledged.
20 Jul 2025 – Submission deadline for Open Source Cubesat Workshop, to be held 25–26 October 2025. Location is Serafio of the Municipality of Athens, Greece.
5 August 2025 – Final Technological Advisory Council meeting at the US Federal Communications Commission (FCC) in Washington, DC. The current charter concludes 5 September 2025.
7-10 August 2025 – DEFCON 33 in Las Vegas, Nevada, USA. ORI plans an Open Source Digital Radio exhibit in RF Village, which is hosted by Radio Frequency Hackers Sanctuary.
1 September 2025 Our Complex Modulation Math article will be published in ARRL’s QEX magazine in the September/October issue.
5 September 2025 – Charter for the current Technological Advisory Council of the US Federal Communications Commission concludes.
19-21 September 2025 – ESA and AMSAT-DL workshop in Bochum, Germany.
25-26 October 2025 – Open Source Cubesat Workshop, Athens, Greece.
Thank you to all who support our work! We certainly couldn’t do it without you.
Anshul Makkar, Director ORI
Frank Brickle, Director ORI (SK)
Keith Wheeler, Secretary ORI
Steve Conklin, CFO ORI
Michelle Thompson, CEO ORI
Matthew Wishek, Director ORI