Tag: interlocutor

Posted on

Inner Circle Newsletter July 2025

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

Want more Inner Circle Newsletters? Sign up for email delivery at http://eepurl.com/h_hYzL 

The Microwave Link Mystery Puzzle (Solution Below)

Four amateur radio operators (Alice, Bob, Carol, and Dave) are setting up 10 GHz microwave links. Each has a different antenna polarization: Horizontal, Vertical, Right-Hand Circular (RHC), and Left-Hand Circular (LHC).

Polarization Loss Rules

Same polarization: 0 dB loss

Cross-polarized linear (H vs V): 20+ dB loss

Circular to linear: 3 dB loss (either direction)

Opposite circular (RHC vs LHC): 20+ dB loss

The Clues

1. Alice can communicate with Bob with perfect signal strength (0 dB loss).

2. Alice gets terrible reception from Carol (20+ dB loss).

3. Alice receives Dave’s signal at reduced power (3 dB loss).

4. Bob can barely hear Carol (20+ dB loss).

5. Bob gets a good but reduced signal from Dave (3 dB loss).

6. Carol receives Dave’s signal at reduced power (3 dB loss).

7. One operator forgot to rotate their new IC-905 dish from its factory vertical polarization setting.

8. Bob notices that a 10 degree rotation resulted in a lot of signal loss.

Who has which antenna polarization?

Solution:

Alice: Horizontal

Bob: Horizontal

Carol: Vertical (IC-905 factory setting – forgot to rotate!)

Dave: Right-Hand Circular (RHCP)

From clue 1, Alice and Bob have 0 dB loss, therefore they have identical polarization.

From clues 2 & 4, both Alice and Bob get 20+ dB loss from Carol, so Carol has the orthogonal polarization to Alice/Bob. This 20+ dB loss could happen in two scenarios:

1. Alice/Bob are one linear polarization (for example, Horizontal), Carol is the orthogonal linear (for example, Vertical).

2. Alice/Bob are one circular polarization (for example, RHCP), Carol is the opposite circular (for example, LHCP).

From Clue 8, Bob has either vertical or horizontal polarization, as rotating the antenna results in noticeable loss. Rotating a circular polarized antenna doesn’t result in much loss.

From clues 3, 5, & 6, Dave gets 3 dB loss from Alice, Bob, and Carol. Since 3 dB loss occurs between circular and linear polarizations, and we suspect Bob is linear, then Dave must be circular. 

Dave can get 3 dB from all three is if Alice/Bob/Carol are all linear polarizations, and Dave is circular. 

Then clue 7 (IC-905 vertical) helps us determine which linear polarizations they have.

From clue 7, someone has an IC-905 in vertical polarization. This some “one” must be Carol (since she’s orthogonal to Alice/Bob). Only one operator forgot to rotate, so it can’t be both Alice and Bob with vertical. 

Therefore: Carol = Vertical, 

Alice/Bob = Horizontal.

Since we have Horizontal (Alice/Bob), Vertical (Carol), and one circular (Dave), Dave must be either RHCP or LHCP. We are going to say RHCP, but it is arbitrary. LHCP is correct too. 

Amateur Radio Band Sudoku

Amateur Radio Band Sudoku – PuzzleDownload

“Take This Job”

30 July 2025

Interested in Open Source software and hardware? Not sure how to get started? Here’s some places to begin at Open Research Institute. If you would like to take on one of these tasks, please write hello@openresearch.institute and let us know which one. We will onboard you onto the team and get you started.

Opulent Voice:

Add a carrier sync lock detector in VHDL. After the receiver has successfully synchronized to the carrier, a signal needs to be presented to the application layer that indicates success. Work output is tested VHDL code. 

Bit Error Rate (BER) waterfall curves for Additive White Gaussian Noise (AWGN) channel.

Bit Error Rate (BER) waterfall curves for Doppler shift.

Bit Error Rate (BER) waterfall curves for other channels and impairments.

Review Proportional-Integral Gain design document and provide feedback for improvement. 

Generate and write a pull request to include a Numerically Controlled Oscillator (NCO) design document for the repository located at https://github.com/OpenResearchInstitute/nco. 

Generate and write a pull request to include a Pseudo Random Binary Sequence (PRBS) design document for the repository located at https://github.com/OpenResearchInstitute/prbs.

Generate and write a pull request to include a Minimum Shift Keying (MSK) Demodulator design document for the repository located at https://github.com/OpenResearchInstitute/msk_demodulator 

Generate and write a pull request to include a Minimum Shift Keying (MSK) Modulator design document for the repository located at https://github.com/OpenResearchInstitute/msk_modulator

Evaluate loop stability with unscrambled data sequences of zeros or ones.

Determine and implement Eb/N0/SNR/EVM measurement. Work product is tested VHDL code.

Review implementation of Tx I/Q outputs to support mirror image cancellation at RF. 

Haifuraiya:

HTML5 radio interface requirements, specifications, and prototype. This is the primary user interface for the satellite downlink, which is DVB-S2/X and contains all of the uplink Opulent Voice channel data. Using HTML5 allows any device with a browser and enough processor to provide a useful user interface. What should that interface look like? What functions should be prioritized and provided? A paper and/or slide presentation would be the work product of this project. 

Default digital downlink requirements and specifications. This specifies what is transmitted on the downlink when no user data is present. Think of this as a modern test pattern, to help operators set up their stations quickly and efficiently. The data might rotate through all the modulation and coding, transmitting a short loop of known data. This would allow a receiver to calibrate their receiver performance against the modulation and coding signal to noise ratio (SNR) slope. A paper and/or slide presentation would be the work product of this project.

ORI’s “Real and Complex Signal Basics” Article to be Published in QEX

The September/October 2025 issue of ARRL’s QEX magazine features “Real and Complex Signal Basics” by Michelle Thompson W5NYV. The article provides a step-by-step mathematical explanation of how complex modulation works in digital radio systems.

The piece starts with simple single-carrier real signals and builds up to explain quadrature amplitude modulation (QAM). Using clear mathematical derivations, it shows how two real signals can be transmitted simultaneously using sine and cosine carriers that are 90 degrees out of phase, then separated at the receiver using trigonometric identities and integration.

Subjects covered include:


How real signals create symmetrical frequency domain images

The transition from 4-level amplitude modulation to 16QAM using I and Q coordinates

The mathematical basis for quadrature mixing at both transmitter and receiver

Why complex modulation eliminates unwanted frequency images

How this approach enables higher data rates without requiring finer amplitude resolution

The article emphasizes the practical advantages of complex modulation. You get increased spectral efficiency, easier filtering due to single-sided transmission, and the flexibility to implement any modulation scheme through software-defined radio techniques.

This mathematical foundation underlies much of ORI’s digital radio development work, including the Opulent Voice protocol and other broadband digital communications projects.


The full article is available to ARRL members through QEX magazine. Want to publish it in your club newsletter? Article is available on request from ARRL from qst@arrl.org

Looking to Learn more about IQ Modulation?

Basics of IQ Signals and IQ modulation & demodulation – A tutorial by W2AEW

https://www.youtube.com/watch?v=h_7d-m1ehoY

Software Defined Radio For Engineers (free PDF from Analog Devices)

https://www.analog.com/en/resources/technical-books/software-defined-radio-for-engineers.html

These resources will get you well on your way!

ORI’s FCC Comment on Proceeding 25-201

Opposition to AST & Science LLC (AST SpaceMobile) Request for Amateur Radio Band Usage

July 21, 2025

Executive Summary

We respectfully submit this comment in strong opposition to AST & Science LLC’s (AST SpaceMobile) request to utilize the 430-440 MHz amateur radio band for Telemetry, Tracking, and Command (TT&C) operations for their planned 243-satellite constellation. We urge the Commission to deny this application and direct AST SpaceMobile toward established commercial satellite frequency allocations that are much more appropriate for their commercial operations.

Background and Technical Concerns

First, we have currently unauthorized operations going on. AST SpaceMobile currently operates five Bluebird commercial satellites launched on September 12, 2024, using amateur radio frequencies at 430.5, 432.3, 434.1, 435.9, and 439.5 MHz with 50 kHz bandwidth for telemetry links. This existing operation has already demonstrated the potential for interference with legitimate amateur radio operations. 

The scope of the proposed expansion is a problem. AST SpaceMobile seeks to expand this usage to a 243-satellite constellation, with each TT&C beam supporting command and telemetry channels with bandwidths between 64-256 kHz. This massive expansion would fundamentally transform the character of the amateur radio band from experimental and emergency communications to commercial satellite operations.

Amateur Radio uses this band and is important. The 430-440 MHz band serves a variety of critical Amateur Radio applications including amateur space communications, weak-signal SSB, digital television, data communications, repeaters and other applications. The amateur radio service in this band supports:

Emergency Communications: Amateur radio operators provide vital public service during disasters when commercial communications infrastructure fails.

Space Communication: Educational and experimental satellite communications that advance the radio arts.

Technical Innovation: Experimentation and development of new communication technologies. Where do we think new engineers come from? Many of them come from amateur radio. 

International Coordination: The proposed constellation will cause interference to amateurs world-wide. This is opposed by a wide variety of international amateur radio organizations. 

Regulatory and Precedential Concerns

This is a very inappropriate band allocation. The 430-440 MHz band is allocated to the Amateur Radio Service, not commercial satellite operations. ITU study groups investigated potential TT&C frequency allocations in the frequency ranges 150.05–174 MHz and 400.15–420 MHz, specifically excluding the amateur allocation at 430-440 MHz. Permitting a commercial satellite constellation to operate in amateur radio spectrum sets a dangerous precedent that could lead to further commercial encroachment on bands reserved for experimental, educational, and emergency communications.

Frequency coordination frameworks exist. Satellite frequency coordination, particularly in these frequency bands, relies on a global regulatory and technical framework maintained by the International Telecommunication Union (ITU). AST SpaceMobile should utilize this established framework rather than seeking unauthorized access to amateur spectrum. ITU study results are clear. ITU study groups conducted sharing studies in various bands which yield that no new allocations are suitable for small satellite TT&C on a co-channel sharing basis. Proper commercial allocations exist that would not interfere with amateur operations.

Proposed Alternative Solutions

We recommend the Commission direct AST SpaceMobile to utilize appropriate commercial satellite frequency allocations:

1. S-Band Operations: Migrate TT&C operations to established S-band satellite allocations (2025-2110 MHz and 2200-2290 MHz)

2. X-Band Implementation: Utilize X-band frequencies (8025-8400 MHz) which offer excellent propagation characteristics for satellite communications

3. Ka-Band Adoption: Consider Ka-band frequencies for high-capacity operations

4. Proper ITU Coordination: Work through established international coordination procedures for legitimate commercial satellite spectrum

Technical feasibility is not an issue. Modern satellite technology readily supports operations in these higher frequency bands. The primary frequency bands of S, X, and Ka are more advantageous than using the UHF band, which has a higher probability of local interference.

Economic and Public Interest Considerations

Protecting Public Service is important. Amateur radio operators provide critical emergency communications during disasters. Interference from commercial satellite operations could compromise this vital public service capability. The amateur radio service serves as a proving ground for new technologies and provides STEM education opportunities. Commercial encroachment limits these important societal benefits and harms our national competitiveness. 

Precedential impact is negative. Approving commercial use of amateur spectrum without compelling technical justification would invite similar requests from other commercial operators, potentially destroying the character of amateur radio allocations.

Conclusion and Recommendations: We respectfully urge the Commission to:

1. DENY AST SpaceMobile’s request to operate in the 430-440 MHz amateur radio band

2. DIRECT AST SpaceMobile to utilize appropriate commercial satellite frequency allocations in S, X, or Ka bands

3. REQUIRE proper ITU coordination for international satellite operations

4. REAFFIRM the Commission’s commitment to protecting amateur radio spectrum for its intended non-commercial, experimental, and emergency communications purposes

The amateur radio bands serve critical public interest functions that would be compromised by large-scale commercial satellite operations. Abundant alternative spectrum exists that is specifically allocated for commercial satellite TT&C operations. We urge the Commission to preserve the amateur radio bands for their intended purposes and direct AST SpaceMobile toward appropriate commercial spectrum.


References: FCC DA 25-532 (June 20, 2025), AMSAT-UK Technical Analysis, ITU Radio Regulations and Study Reports, and NASA Small Satellite Guidelines

ORI’s Contribution to FCC Technological Advisory Council


Open Research Institute contributed to the US Federal Communications Commission Technological Advisory Council final report for the 2024-2025 term. A summary of ORI’s final draft contribution to the report is presented here.

We describe how spectrum sharing models must evolve to meet growing demand, particularly focusing on terrestrial-satellite integration. The core thesis suggests we’re experiencing a crisis in current spectrum management that requires transitioning to a new “Era 4” model incorporating AI/ML automation and market-based mechanisms.


Historical Evolution of Spectrum Management

We identify three distinct eras of spectrum management.


Era 1 (1890-1912): Unregulated Model – A “loudest-served” system with no regulatory oversight, which collapsed following the Titanic disaster due to communication congestion.


Era 2 (1927-1981): Command-and-Control Model – Centralized FCC authority making static allocations based on “public interest.” This system struggled with emerging technologies like FM radio and cellular networks.


Era 3 (1993-present): Market-Based/Flexible Use Model – Introduced spectrum auctions and flexible licensing, but now showing signs of regulatory overload and crisis.


Evidence of Current Crisis


Several indicators suggest Era 3 regulatory models are failing.

219 MHz Band Limbo: Years of regulatory deadlock between amateur radio, commercial, and federal interests with zero amateur activity despite allocated rights


C-Band Aviation Disputes: $81 billion auction created interference concerns with radar altimeters, requiring presidential intervention


Inter-agency Conflicts: NTIA and FCC reaching opposite conclusions on identical technical evidence (Ligado case)


Reallocation Resistance: Broadcasting industry claiming all “low hanging fruit” has been picked from spectrum repacking


Technical Challenges in Terrestrial-Satellite Sharing


We highlight complex coordination requirements across multiple services in bands like 7.125-8.4 GHz, including Fixed Satellite Service, Mobile Satellite Service, and various terrestrial services. The SiriusXM situation exemplifies ongoing interference challenges between satellite and terrestrial broadband services.

AI/ML Enhanced Spectrum Management

The report positions AI/ML as essential for Era 4, comparing it to sophisticated air traffic control for the electromagnetic domain. Key capabilities include real-time spectrum sensing and occupancy analysis, dynamic allocation based on interference patterns, pattern recognition for optimization, and automated coordination at scale beyond human regulatory capacity


However, the report recommends against mandating specific AI/ML technologies, favoring technology-neutral approaches.


Proposed Era 4 Solutions


Band Managers and Spectrum Bucks: Government exits direct allocation, appointing non-governmental band managers who negotiate usage using a “Spectrum Bucks” currency system. This would enable both commercial and non-commercial users to coexist through market mechanisms.

Amateur Radio Model: Highlighted as a successful example of dynamic spectrum sharing through self-regulation, technical excellence requirements, and community governance. Amateur satellites demonstrate effective secondary service operations and have pioneered numerous technologies later adopted commercially.


Regulatory Sandboxes: Supplemental Coverage from Space (SCS) is the first terrestrial-to-satellite spectrum leasing framework, creating economic incentives for cooperation rather than just technical coordination. This hybrid model enables spectrum reuse in the same geographic areas.


Key Recommendations


Improve Spectrum Sensing: Establish independent measurement networks through citizen science projects, public-private partnerships, and dedicated monitoring systems to provide transparent occupancy data.


Create More Regulatory Sandboxes: Use controlled environments to test new sharing models before broad deployment, building on SCS and amateur radio examples.


Optimize Satellite Uplink Sharing: Prioritize sharing arrangements for uplink services while providing separate allocations for downlink services, recognizing the different interference characteristics.


Develop HetNet Principles: Create coordination algorithms that leverage satellite orbital mechanics and optimize handoffs between terrestrial and non-terrestrial networks.


The report concludes that the complexity and scale of modern spectrum management demands a paradigm shift toward automated, AI/ML-enhanced systems that can handle what human regulators cannot, while maintaining proven principles from successful sharing models like amateur radio.

[We’ll share full versions of all the charter items when the final report is approved by the TAC. This should be in early August 2025. -Michelle Thompson ]

What is the ESA FutureGEO Project?

Here is ORI’s response to the call for participation from AMSAT-DL concerning the FutureGEO project, sponsored by the European Space Agency. We are looking forward to participating in the FutureGEO workshop in September 2025.

questionnaire-answers-2Download

Matthew Wishek Wins 2025 ARRL Technical Innovation Award

We are thrilled to announce that Matthew Wishek NB0X has been awarded the prestigious 2025 ARRL Technical Innovation Award by the American Radio Relay League (ARRL) Board of Directors. This distinguished honor recognizes licensed radio amateurs who develop and apply new technical ideas or techniques that advance the state of amateur radio technology.

Matthew received this recognition for his innovative contributions to amateur radio digital communications, specifically his development of an open source minimum shift keying (MSK) implementation for software-defined radio.

Matthew’s primary achievement centers on his work with the pluto_msk project, a sophisticated MSK modem implementation designed for the Analog Devices ADALM-Pluto SDR platform. This project represents a significant advancement in efficient digital communications for amateur radio, particularly for the Opulent Voice (OPV) digital voice and data protocol.

MSK modulation is a type of continuous phase modulation that eliminates phase discontinuities, resulting in superior spectral efficiency compared to traditional FSK and other binary modulations. Matthew’s custom hardware description language (HDL) implementation targeting the AMD Zynq 7010 system on chip, maximizes performance and resource utilization. The design has multiple sophisticated components including numerically controlled oscillators (NCO), Proportional Integral (PI) controllers, power detectors, and exponential moving average filters.

Equally significant is Matthew’s pioneering modem module approach to HDL design. This architectural approach makes a large positive difference in how digital signal processing systems are designed and implemented in FPGAs. The modem module approach is the systematic creation of reusable, well-defined building blocks that can be combined for a variety of communication protocols. While many projects and people pay lip service to modularity, Matthew’s execution and leadership in this area have supercharged ORI’s work.


All components are freely available, fostering collaboration and continued innovation in the amateur radio community

The ARRL Technical Innovation Award recognizes not just technical achievement, but also contributions that benefit the broader amateur radio community. Matthew’s work exemplifies both criteria

Matthew’s innovations in modular HDL design and MSK implementation provide a solid foundation for future developments in amateur radio digital communications. His work demonstrates how modern software-defined radio platforms can be leveraged to implement sophisticated communication techniques that were previously the domain of commercial and military systems.

The amateur radio community benefits enormously from contributions like Matthew’s, which not only advance the technical state of the art but also provide practical, implementable solutions that enhance our communication capabilities.

Congratulations to Matthew Wishek on this well-deserved recognition of his outstanding technical contributions to amateur radio!

The American Radio Relay League (ARRL) is the national association for amateur radio, connecting hams around the U.S. with news, information and resources. The ARRL Technical Innovation Award is presented annually to recognize exceptional technical innovation that advances amateur radio.

Highlights from the New Interlocutor Installation and Operator Manual

A Human Radio Interface for Opulent Voice is ready for you to try out at https://github.com/OpenResearchInstitute/interlocutor

Overview

Interlocutor is the human-radio interface component of the Open Research Institute’s Opulent Voice digital communication system. Think of it as the “radio console” that transforms your computing device (such as  Raspberry Pi or a laptop) into a sophisticated digital voice and data terminal. While traditional amateur radio digital modes often sacrifice audio quality for bandwidth efficiency, Interlocutor enables very high-quality voice communications with seamless integration of keyboard chat, file transfer, and system control messages.

What Does Interlocutor Do?

Interlocutor provides high-quality digital voice communication using the high-bitrate open source Opus voice encoder. It enables keyboard chat that integrates seamlessly with voice, handles file transfer and system control messages, and offers both command-line and web-based interfaces. Interlocutor manages audio devices with sophisticated conflict resolution and implements priority-based message queuing (voice always wins)

It acts as the bridge between human operators and radio equipment. It processes voice, text, and data into properly formatted frames that can be sent to any Opulent Voice-compatible modem via Ethernet, enabling remote operation and modular system design.

On first run, you’ll be prompted to:

1. Select audio input device where you choose your microphone.

2. Test audio input where you speak to verify microphone works.

3. Select audio output device where you choose your speakers/headphones

4. Test audio output where you listen for test tone. 

Where to Send Your Frames?

After Interlocutor does all the work required to gather your voice and text input and create Opulent Voice Protocol frames, those frames are then sent to a modem or other program that can make use of them. How does this work? If frames are sent to a modem then it turns the frames into a modulated signal. This signal is then sent out over the air. The current implemented target modem is the PLUTO SDR from Analog Devices.

Or, the frames can go to a computer or conference server over the Internet. In other words, frames can be sent to another computer, a modem for radio transmission, a conference server (repeater) receiver, and more. If it has an IP address, and if it understands what to do with the frames, then you are ready to communicate.

The Basics of Running Interlocutor

See the online manual for detailed installation instructions.

# Launch with web interface

python3 interlocutor.py YOUR_CALLSIGN --web-interface

# Launch with a specific config file

python3 interlocutor.py YOUR_CALLSIGN -c myconfig.yaml --web-interface

You’ll need to configure network targets to tell Interlocutor where your Opulent Voice data frames need to be sent. Modify the network target configuration through the web interface in the Target IP Address box or use the command-line argument like this:
-i <IP address> 
as needed.

The web interface is available at http://localhost:8000 on the device running interlocutor.py. 

Interlocutor features a modern glassmorphism-styled web interface for operation and complete system configuration. All configuration items are available at the command line or in the web interface.

The purpose of the Configuration System is to create, validate, and save one or more configuration files so that an operator can start the radio in a fully defined state. 

Operational Modes

First, let’s talk about the command line interface (CLI) mode. This offers traditional terminal-based operation with full keyboard chat capabilities. 

The simplest way to invoke this mode is by typing:

python3 interlocutor.py YOUR_CALLSIGN

In CLI mode, real-time voice transmission is done with a hardware PTT button. There is a keyboard chat interface. Voice has priority, with control messages second highest priority, and keyboard chat third. Debug output and system status are shown as text on the screen. 

Second, let’s explore the web interface mode. The web interface is a modern browser-based interface with visual controls. 

It is invoked by adding the –web-interface argument to program start.
python3 interlocutor.py YOUR_CALLSIGN --web-interface

We find a detailed configuration management in Configuration tab, live status indicators, and real-time voice transmission with PTT control available in three different ways. First, as a hardware switch on designated GPIOs. Second, as a clickable button in the web interface. Third, the space bar when the message entry box does not have focus. Web interface has keyboard chat and shows system log, notifications for important events, debug output, and system status. Sent and received audio can be replayed from the message history window. 

Dual-Mode Operation

Both interfaces can run simultaneously, providing flexibility for different operational scenarios or preferences. There are instant updates between command line and web interfaces via WebSocket communication.

Protocol and Network Configuration

Interlocutor implements the Opulent Voice protocol with sophisticated frame management. Here are the frame types and priorities.

1. VOICE (Priority 1): Opus-encoded audio, immediate transmission

2. CONTROL (Priority 2): PTT state changes, high priority queue, A5 messages

3. TEXT (Priority 3): Keyboard chat, normal priority queue

4. DATA (Priority 4): File transfers, low priority queue

External Network Ports:

57372: Network Transmitter port (configurable, connects to radio hardware, computer, or repeater). This is the only port you have to configure.

Internal Protocol Ports:

57373: Audio frames

57374: Text frames  

57375: Control frames

These ports tell the receiver what kind of information it’s receiving. These ports are in the UDP header in each Opulent Voice frame. The protocol is extendable. Future data types get the next port available. 

All frames follow the Opulent Voice protocol format.
Opulent Voice Header: 12 bytes (sync word + station ID + type + sequence + length + reserved)

Payload: 122 bytes of data loaded up in 40 ms frames

Encoding: COBS (Consistent Overhead Byte Stuffing) framing

Transport: UDP over IP with RTP headers for audio, UDP over IP for control, text, and data

Network Integration

# Basic operation (connects to default target with default values)

python3 interlocutor.py YOUR_CALLSIGN

# Specify target IP and port

python3 interlocutor.py YOUR_CALLSIGN --target-ip 192.168.1.100 --target-port 57372

# Load specific configuration file

python3 interlocutor.py YOUR_CALLSIGN -c mystation.yaml

Audio System Operation

Push-to-Talk (PTT) Operation:

GPIO Button: Physical button connected to Raspberry Pi GPIO

Web PTT: Additional click/touch controls in web interface. There’s a PTT button and the space bar activates PTT when the message entry box is not highlighted (does not have focus). 

Audio Processing Pipeline:

1. Microphone input to PyAudio capture

2. Audio validation

3. Opus encoding (40ms frames, 16,000 bps bitrate)

4. Hardware audio callback

5. RTP header addition

6. UDP header addition

7. IP header addition

8. COBS encoding

9. Opulent Voice header addition

10. Network transmission

Chat Integration

Voice transmission has absolute priority. Text messages typed during PTT are buffered. Buffered messages transmit immediately when PTT releases. Control messages maintain high priority for system functions

Chat Modes:

Voice + Chat: Normal operation with seamless integration. Operators can choose voice or text as appropriate. This is the default mode.

Chat Only Mode: Keyboard-to-keyboard communication (similar to RTTY). This is set up with a command line argument
--chat-only

Automatic Reconnection System

Interlocutor implements intelligent reconnection logic for the web interface.

Reconnection Timing is as follows.

1. First retry: 1 second delay

2. Subsequent retries: Exponential backoff (1.5x increase)

3. Maximum delay: 30 seconds

4. Maximum attempts: 10 attempts

5. Total auto-retry time: 2-3 minutes

A manual retry button appears after auto-retry exhaustion. 

Documentation Resources

Project repository: https://github.com/OpenResearchInstitute/interlocutor

Open Research Institute: https://www.openresearch.institute/getting-started

GitHub Issues for bug reports

Code contributions welcome via GitHub pull requests and filing issues. Documentation improvements welcome and encouraged. Testing and feedback valuable for development. Hardware testing on different platforms welcome and encouraged! 

The system is actively developed open-source software, and features will evolve. Check the project repository for the latest updates and documentation. 

But Wait, There’s More

Opulent Voice Demonstration Conference Server Beta Test Now Open

This project is called Locus, and the repository link, with manual and installation instructions, can be found here:

https://github.com/OpenResearchInstitute/locus

Key components of a fully implemented conference server (Opulent Voice repeater) are outlined below.

1. FDMA Uplink Channels Received at Spacecraft or Terrestrial Repeater

Multiple receivers monitoring different frequency slots simultaneously, each capable of demodulating and decoding the Opulent Voice protocol.

2. Conference Management Hardware and Software

This manages how stations can connect with other stations by maintaining lists of rooms or conferences. Conferences are logical groupings of stations.

3. DVB-S2 Downlink Multiplexer

This component takes all the conference data and creates a single high-bandwidth downlink stream.

Software modifications to Interlocutor, the human-radio interface for Opulent Voice stations, have been made in order to realize a simple repeater system. The Interlocutor repository can be found here:

https://github.com/OpenResearchInstitute/interlocutor

By targeting the IP address of opulent.openresearch.institute, anyone running Interlocutor can participate on ORI’s demonstration conference repeater. This repeater is internet-only at the moment, but will have RF hardware in the next phase of work.

To configure Interlocutor for the conference server, here is an example invocation.

python3 interlocutor.py QUARTER --web-interface  -i 172.236.237.16

This sets up a station with ID QUARTER, running a web interface at 127.0.0.1:8000, and sends frames to opulent.openresearch.institute.

The next phase of work is to set up named conference rooms so that people can join based on event, subject matter, scheduled meetups, and other searchable categories. There will be a Conferences tab in the Interlocutor web interface that will populate whenever conferences metadata is received.

Key Features Unlocked in the Next Phase

Multiple simultaneous conversations are possible. Instead of traditional “one-at-a-time” repeater operation, users will have multiple conferences running simultaneously. A local weather net, an emergency coordinator channel, and a tech Q&A room are all active at once. Each of the voice transmissions and chat messages appear in the message history window of Interlocutor. The voice transmissions and chat messages are filtered by the receiving station based on the conferences from which the transmissions originated from.

Operators will browse active conferences and see things like participant counts, last activity, and have the ability to freely monitor any conferences.

Conference participation is straightforward. Operators have their station join a conference by transmitting in one. At that point, the station ID appears in the conference membership list. Before transmission to a Conference, the station ID would not appear in the list.

Conference lists are kept clean. Over time, a station ID that has joined a conference expires and is dropped off the list of stations in the conference. This is done after some configurable period of inactivity. The default in Locus is one hour. Conferences themselves, without active transmissions, can expire after some amount of time as well. This “time out” process emphasizes active conferences, reducing the amount of “empty rooms” that an operator would have to search through to find someone to communicate with.

Technical Implementation Strategy

Within Interlocutor, current conference server operation is essentially the same as if it was connecting directly to another station. If the target IP address is a conference server, then voice and text appear in the message history from all the stations that are transmitting. The Locus demonstration station at ORI simply forwards frames received. It has essentially one conference. This will change in the next phase. Current work is to continuously improve performance and user experience with the basic functions. Adding additional conference functions will follow shortly.

For this next phase, Interlocutor will have a third Conference Tab in the web interface. This will allow conference discovery and enable full participation. The banner on the Communications Tab will change to show when a server is connected, as opposed to a single directly connected station. This will be unobtrusive but clear.

We need to implement the frequency division multiple access (FDMA) receiver that manages multiple frequency slots on the uplink, and build the DVB-S2 Multiplexer for the downlink aggregation. Hardware for our open source HEO/GEO satellite project Haifuraiya has been demonstrated in the past, and these designs will be used for this project as well.

Discoverability Improves Engagement

In order to take advantage of the conference functions, individual stations use the Interlocutor program in essentially the same way as they would in a point-to-point contact. A fully implemented conference server will broadcast messages to be detected by Interlocutor receiver. These broadcasts list the conferences and the participants. Then, the web interface populates with the available conferences and exposes the controls for starting a new conference, joining an existing conference, or monitoring any conference. Operators join conferences by participating with a transmission. The repeater handles the complexity. The broadcast will be sent at the lowest priority level (data), as to not interfere with voice, text, or control frames.

The concept of conferences is central to the repeater experience. People playing a D&D game over the air would be in a game conference. That conference might be called “The Elven Empire”. People coming and going during drive time might join “I-15 Rollout”. An individual calling another individual for a one-on-one QSO would be in a conference too, which might be called “Ken’s Coffee Break” or “Everyone Welcome”.

Conferences become the fundamental organizing principle. This organizing principal shifts amateur radio from “everyone talks to everyone on one frequency” to “purposeful gatherings with context and discoverability.”

Traditional repeaters are like having one conference room where everyone shows up, takes turns to talk, and if you miss a transmission then that is just too bad. You missed it.

A conference-based system creates purposeful spaces. The D&D group doesn’t interfere with the emergency coordinators, and both can run simultaneously. If you missed a message, you can scroll up in the message history window. You can replay past audio transmissions from the UI Audio Bubbles or read the past chat message history. Both are in the message history window. Empty conferences time out and are removed, so that it doesn’t look like a ghost town or give a false sense of activity. 

Instead of “I hope someone interesting is on the repeater,” users can browse conferences in the past, present, and future. A list of past conferences, out to some point in the past, can be maintained to show the frequency and type of activity. Any conference can be monitored. Current conferences are joined by transmitting in the conference. Future conferences can be listed in a schedule. This is like the difference between wandering into a random tavern hoping for good company versus checking a bulletin board that says “Adventuring Party Seeking Ranger Meet by the Old Oak” or “Storytelling by the Fire in the Great Hall.” This type of radio experience has natural social dynamics.

An operator can make a casual discovery and meet new friend.

“Oh, there’s a Python programming discussion with 4 people – that sounds interesting!”

Operators can make and advertise planned events.

“Tech Book Club session every Tuesday at 7 PM – join us!

Emergency coordination can be greatly improved. Operators can quickly and easily create dedicated emergency conferences during disasters. With authentication and authorization functions, these conferences can be limited to people that have, for example, completed specific training. A system like this can provide realistic emergency training opportunities that do not interfere with normal operation. Mentoring conferences can be set up to provide friendly and welcoming alternatives for education and learning.

The conference server manages conference data. A goal is to keep this to the minimal required state. The conference server doesn’t decide who can listen to what, unless there is an authentication and authorization policy in place from the repeater owner.

Use Cases

Opulent Voice naturally scales up. Here are some anticipated use cases. This is not intended to be a comprehensive list.

Simple Point-to-Point: Two or more people communicating point-to-point create the equivalent of a single conference. Whether the station is operating point-to-point or in a conference at a repeater, the program behaves almost identically. The only difference on the Communications tab is the heading color and title.

Local Repeater: Multiple conferences on one repeater system that is running a conference server.

Regional Network: Conferences can span multiple repeaters.

Satellite Integration: HEO satellites carry conference multiplexes to different continents

Internet Bridging: Conferences can include remote participants via internet gateways

The conference concept transforms amateur radio from “broadcast to everyone in range” to “purposeful communities of interest.” Conference discovery/joining is a different mental mode than active communication. Therefore, it gets a separate tab in the Interlocutor web interface.

Three-Tab Architecture Defined

Tab 1: Communications “I’m having a conversation”
We keep the current design
We use current message history and audio playback
Active conference indicator at the top: “Currently in: Morning Coffee Chat (4 people)”
Quick leave/switch button – minimal, non-intrusive
Focus stays on the actual conversations

Tab 2: Conferences “I’m choosing who to talk to”
New design to be implemented in the very near future
Conference browser and discovery
Create new conferences
Join/schedule conferences
Personal conference history and favorites
Block lists

Tab 3: Configuration “I’m setting up my radio”
We keep the current design
Configuration Tab moves from position 2 to position 3
New conference configuration items
Radio and system settings

Operator Mental Models

This creates a clear progression in the operator’s mind:

1) “I want to join a conversation” Check conference server status
2) If connected browse and join conferences
3) If no conferences appeal then “I can still talk directly to someone”

The central idea behind the conference tab is the transition experience: User browses conferences, finds “Python Coding Discussion (3 people)“, clicks join, gets smoothly transitioned back to their familiar communications interface, but now they’re talking with Python enthusiasts instead of whoever happened to be on the repeater.

Conference Servers feel like choosing your conversation rather than hoping for a good one.

Expect conference functionality to increase at the internet demonstration station over the next few months. 

Open Research Institute Sphere of Activity

August, September, October 2025

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. 

10 August 2025 – Submission deadline for Open Source Cubesat Workshop, to be held 25–26 October 2025. Location is Serafio of the Municipality of Athens, Greece. Submission status !!!AI

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

Keith Wheeler, Secretary ORI

Steve Conklin, CFO ORI

Michelle Thompson, CEO ORI

Matthew Wishek, Director ORI

Posted on

But Wait, There’s More

Opulent Voice Demonstration Conference Server Beta Test Now Open

This project is called Locus, and the repository link, with manual and installation instructions, can be found here:

https://github.com/OpenResearchInstitute/locus

Key components of a fully implemented conference server (Opulent Voice repeater) are outlined below.

1. FDMA Uplink Channels Received at Spacecraft or Terrestrial Repeater

Multiple receivers monitoring different frequency slots simultaneously, each capable of demodulating and decoding the Opulent Voice protocol.

2. Conference Management Hardware and Software

This manages how stations can connect with other stations by maintaining lists of rooms or conferences. Conferences are logical groupings of stations.

3. DVB-S2 Downlink Multiplexer

This component takes all the conference data and creates a single high-bandwidth downlink stream.

Software modifications to Interlocutor, the human-radio interface for Opulent Voice stations, have been made in order to realize a simple repeater system. The Interlocutor repository can be found here:

https://github.com/OpenResearchInstitute/interlocutor

By targeting the IP address of opulent.openresearch.institute, anyone running Interlocutor can participate on ORI’s demonstration conference repeater. This repeater is internet-only at the moment, but will have RF hardware in the next phase of work.

To configure Interlocutor for the conference server, here is an example invocation.

python3 interlocutor.py QUARTER --web-interface  -i 172.236.237.16

This sets up a station with ID QUARTER, running a web interface at 127.0.0.1:8000, and sends frames to opulent.openresearch.institute.

The next phase of work is to set up named conference rooms so that people can join based on event, subject matter, scheduled meetups, and other searchable categories. There will be a Conferences tab in the Interlocutor web interface that will populate whenever conferences metadata is received.

Key Features Unlocked in the Next Phase

Multiple simultaneous conversations are possible. Instead of traditional “one-at-a-time” repeater operation, users will have multiple conferences running simultaneously. A local weather net, an emergency coordinator channel, and a tech Q&A room are all active at once. Each of the voice transmissions and chat messages appear in the message history window of Interlocutor. The voice transmissions and chat messages are filtered by the receiving station based on the conferences from which the transmissions originated from.

Operators will browse active conferences and see things like participant counts, last activity, and have the ability to freely monitor any conferences.

Conference participation is straightforward. Operators have their station join a conference by transmitting in one. At that point, the station ID appears in the conference membership list. Before transmission to a Conference, the station ID would not appear in the list.

Conference lists are kept clean. Over time, a station ID that has joined a conference expires and is dropped off the list of stations in the conference. This is done after some configurable period of inactivity. The default in Locus is one hour. Conferences themselves, without active transmissions, can expire after some amount of time as well. This “time out” process emphasizes active conferences, reducing the amount of “empty rooms” that an operator would have to search through to find someone to communicate with.

Technical Implementation Strategy

Within Interlocutor, current conference server operation is essentially the same as if it was connecting directly to another station. If the target IP address is a conference server, then voice and text appear in the message history from all the stations that are transmitting. The Locus demonstration station at ORI simply forwards frames received. It has essentially one conference. This will change in the next phase. Current work is to continuously improve performance and user experience with the basic functions. Adding additional conference functions will follow shortly.

For this next phase, Interlocutor will have a third Conference Tab in the web interface. This will allow conference discovery and enable full participation. The banner on the Communications Tab will change to show when a server is connected, as opposed to a single directly connected station. This will be unobtrusive but clear.

We need to implement the frequency division multiple access (FDMA) receiver that manages multiple frequency slots on the uplink, and build the DVB-S2 Multiplexer for the downlink aggregation. Hardware for our open source HEO/GEO satellite project Haifuraiya has been demonstrated in the past, and these designs will be used for this project as well.

Discoverability Improves Engagement

In order to take advantage of the conference functions, individual stations use the Interlocutor program in essentially the same way as they would in a point-to-point contact. A fully implemented conference server will broadcast messages to be detected by Interlocutor receiver. These broadcasts list the conferences and the participants. Then, the web interface populates with the available conferences and exposes the controls for starting a new conference, joining an existing conference, or monitoring any conference. Operators join conferences by participating with a transmission. The repeater handles the complexity. The broadcast will be sent at the lowest priority level (data), as to not interfere with voice, text, or control frames.

The concept of conferences is central to the repeater experience. People playing a D&D game over the air would be in a game conference. That conference might be called “The Elven Empire”. People coming and going during drive time might join “I-15 Rollout”. An individual calling another individual for a one-on-one QSO would be in a conference too, which might be called “Ken’s Coffee Break” or “Everyone Welcome”.

Conferences become the fundamental organizing principle. This organizing principal shifts amateur radio from “everyone talks to everyone on one frequency” to “purposeful gatherings with context and discoverability.”

Traditional repeaters are like having one conference room where everyone shows up, takes turns to talk, and if you miss a transmission then that is just too bad. You missed it.

A conference-based system creates purposeful spaces. The D&D group doesn’t interfere with the emergency coordinators, and both can run simultaneously. If you missed a message, you can scroll up in the message history window. You can replay past audio transmissions from the UI Audio Bubbles or read the past chat message history. Both are in the message history window. Empty conferences time out and are removed, so that it doesn’t look like a ghost town or give a false sense of activity. 

Instead of “I hope someone interesting is on the repeater,” users can browse conferences in the past, present, and future. A list of past conferences, out to some point in the past, can be maintained to show the frequency and type of activity. Any conference can be monitored. Current conferences are joined by transmitting in the conference. Future conferences can be listed in a schedule. This is like the difference between wandering into a random tavern hoping for good company versus checking a bulletin board that says “Adventuring Party Seeking Ranger Meet by the Old Oak” or “Storytelling by the Fire in the Great Hall.” This type of radio experience has natural social dynamics.

An operator can make a casual discovery and meet new friend.

“Oh, there’s a Python programming discussion with 4 people – that sounds interesting!”

Operators can make and advertise planned events.

“Tech Book Club session every Tuesday at 7 PM – join us!

Emergency coordination can be greatly improved. Operators can quickly and easily create dedicated emergency conferences during disasters. With authentication and authorization functions, these conferences can be limited to people that have, for example, completed specific training. A system like this can provide realistic emergency training opportunities that do not interfere with normal operation. Mentoring conferences can be set up to provide friendly and welcoming alternatives for education and learning.

The conference server manages conference data. A goal is to keep this to the minimal required state. The conference server doesn’t decide who can listen to what, unless there is an authentication and authorization policy in place from the repeater owner.

Use Cases

Opulent Voice naturally scales up. Here are some anticipated use cases. This is not intended to be a comprehensive list.

Simple Point-to-Point: Two or more people communicating point-to-point create the equivalent of a single conference. Whether the station is operating point-to-point or in a conference at a repeater, the program behaves almost identically. The only difference on the Communications tab is the heading color and title.

Local Repeater: Multiple conferences on one repeater system that is running a conference server.

Regional Network: Conferences can span multiple repeaters.

Satellite Integration: HEO satellites carry conference multiplexes to different continents

Internet Bridging: Conferences can include remote participants via internet gateways

The conference concept transforms amateur radio from “broadcast to everyone in range” to “purposeful communities of interest.” Conference discovery/joining is a different mental mode than active communication. Therefore, it gets a separate tab in the Interlocutor web interface.

Three-Tab Architecture Defined

Tab 1: Communications “I’m having a conversation”
We keep the current design
We use current message history and audio playback
Active conference indicator at the top: “Currently in: Morning Coffee Chat (4 people)”
Quick leave/switch button – minimal, non-intrusive
Focus stays on the actual conversations

Tab 2: Conferences “I’m choosing who to talk to”
New design to be implemented in the very near future
Conference browser and discovery
Create new conferences
Join/schedule conferences
Personal conference history and favorites
Block lists

Tab 3: Configuration “I’m setting up my radio”
We keep the current design
Configuration Tab moves from position 2 to position 3
New conference configuration items
Radio and system settings

Operator Mental Models

This creates a clear progression in the operator’s mind:

1) “I want to join a conversation” Check conference server status
2) If connected browse and join conferences
3) If no conferences appeal then “I can still talk directly to someone”

The central idea behind the conference tab is the transition experience: User browses conferences, finds “Python Coding Discussion (3 people)“, clicks join, gets smoothly transitioned back to their familiar communications interface, but now they’re talking with Python enthusiasts instead of whoever happened to be on the repeater.

Conference Servers feel like choosing your conversation rather than hoping for a good one.

Expect conference functionality to increase at the internet demonstration station over the next few months. 

Posted on

Highlights from the New Interlocutor Installation and Operator Manual

A Human Radio Interface for Opulent Voice is ready for you to try out at https://github.com/OpenResearchInstitute/interlocutor

Overview

Interlocutor is the human-radio interface component of the Open Research Institute’s Opulent Voice digital communication system. Think of it as the “radio console” that transforms your computing device (such as  Raspberry Pi or a laptop) into a sophisticated digital voice and data terminal. While traditional amateur radio digital modes often sacrifice audio quality for bandwidth efficiency, Interlocutor enables very high-quality voice communications with seamless integration of keyboard chat, file transfer, and system control messages.

What Does Interlocutor Do?

Interlocutor provides high-quality digital voice communication using the high-bitrate open source Opus voice encoder. It enables keyboard chat that integrates seamlessly with voice, handles file transfer and system control messages, and offers both command-line and web-based interfaces. Interlocutor manages audio devices with sophisticated conflict resolution and implements priority-based message queuing (voice always wins)

It acts as the bridge between human operators and radio equipment. It processes voice, text, and data into properly formatted frames that can be sent to any Opulent Voice-compatible modem via Ethernet, enabling remote operation and modular system design.

On first run, you’ll be prompted to:

1. Select audio input device where you choose your microphone.

2. Test audio input where you speak to verify microphone works.

3. Select audio output device where you choose your speakers/headphones

4. Test audio output where you listen for test tone. 

Where to Send Your Frames?

After Interlocutor does all the work required to gather your voice and text input and create Opulent Voice Protocol frames, those frames are then sent to a modem or other program that can make use of them. How does this work? If frames are sent to a modem then it turns the frames into a modulated signal. This signal is then sent out over the air. The current implemented target modem is the PLUTO SDR from Analog Devices.

Or, the frames can go to a computer or conference server over the Internet. In other words, frames can be sent to another computer, a modem for radio transmission, a conference server (repeater) receiver, and more. If it has an IP address, and if it understands what to do with the frames, then you are ready to communicate.

The Basics of Running Interlocutor

See the online manual for detailed installation instructions.

# Launch with web interface

python3 interlocutor.py YOUR_CALLSIGN --web-interface

# Launch with a specific config file

python3 interlocutor.py YOUR_CALLSIGN -c myconfig.yaml --web-interface

You’ll need to configure network targets to tell Interlocutor where your Opulent Voice data frames need to be sent. Modify the network target configuration through the web interface in the Target IP Address box or use the command-line argument like this:
-i <IP address>
as needed.

The web interface is available at http://localhost:8000 on the device running interlocutor.py. 

Interlocutor features a modern glassmorphism-styled web interface for operation and complete system configuration. All configuration items are available at the command line or in the web interface.

The purpose of the Configuration System is to create, validate, and save one or more configuration files so that an operator can start the radio in a fully defined state. 

Operational Modes

First, let’s talk about the command line interface (CLI) mode. This offers traditional terminal-based operation with full keyboard chat capabilities. 

The simplest way to invoke this mode is by typing:

python3 interlocutor.py YOUR_CALLSIGN

In CLI mode, real-time voice transmission is done with a hardware PTT button. There is a keyboard chat interface. Voice has priority, with control messages second highest priority, and keyboard chat third. Debug output and system status are shown as text on the screen. 

Second, let’s explore the web interface mode. The web interface is a modern browser-based interface with visual controls. 

It is invoked by adding the –web-interface argument to program start.
python3 interlocutor.py YOUR_CALLSIGN --web-interface

We find a detailed configuration management in Configuration tab, live status indicators, and real-time voice transmission with PTT control available in three different ways. First, as a hardware switch on designated GPIOs. Second, as a clickable button in the web interface. Third, the space bar when the message entry box does not have focus. Web interface has keyboard chat and shows system log, notifications for important events, debug output, and system status. Sent and received audio can be replayed from the message history window. 

Dual-Mode Operation

Both interfaces can run simultaneously, providing flexibility for different operational scenarios or preferences. There are instant updates between command line and web interfaces via WebSocket communication.

Protocol and Network Configuration

Interlocutor implements the Opulent Voice protocol with sophisticated frame management. Here are the frame types and priorities.

1. VOICE (Priority 1): Opus-encoded audio, immediate transmission

2. CONTROL (Priority 2): PTT state changes, high priority queue, A5 messages

3. TEXT (Priority 3): Keyboard chat, normal priority queue

4. DATA (Priority 4): File transfers, low priority queue

External Network Ports:

57372: Network Transmitter port (configurable, connects to radio hardware, computer, or repeater). This is the only port you have to configure.

Internal Protocol Ports:

57373: Audio frames

57374: Text frames  

57375: Control frames

These ports tell the receiver what kind of information it’s receiving. These ports are in the UDP header in each Opulent Voice frame. The protocol is extendable. Future data types get the next port available. 

All frames follow the Opulent Voice protocol format.
Opulent Voice Header: 12 bytes (sync word + station ID + type + sequence + length + reserved)

Payload: 122 bytes of data loaded up in 40 ms frames

Encoding: COBS (Consistent Overhead Byte Stuffing) framing

Transport: UDP over IP with RTP headers for audio, UDP over IP for control, text, and data

Network Integration

# Basic operation (connects to default target with default values)

python3 interlocutor.py YOUR_CALLSIGN

# Specify target IP and port

python3 interlocutor.py YOUR_CALLSIGN --target-ip 192.168.1.100 --target-port 57372

# Load specific configuration file

python3 interlocutor.py YOUR_CALLSIGN -c mystation.yaml

Audio System Operation

Push-to-Talk (PTT) Operation:

GPIO Button: Physical button connected to Raspberry Pi GPIO

Web PTT: Additional click/touch controls in web interface. There’s a PTT button and the space bar activates PTT when the message entry box is not highlighted (does not have focus). 

Audio Processing Pipeline:

1. Microphone input to PyAudio capture

2. Audio validation

3. Opus encoding (40ms frames, 16,000 bps bitrate)

4. Hardware audio callback

5. RTP header addition

6. UDP header addition

7. IP header addition

8. COBS encoding

9. Opulent Voice header addition

10. Network transmission

Chat Integration

Voice transmission has absolute priority. Text messages typed during PTT are buffered. Buffered messages transmit immediately when PTT releases. Control messages maintain high priority for system functions

Chat Modes:

Voice + Chat: Normal operation with seamless integration. Operators can choose voice or text as appropriate. This is the default mode.

Chat Only Mode: Keyboard-to-keyboard communication (similar to RTTY). This is set up with a command line argument
--chat-only

Automatic Reconnection System

Interlocutor implements intelligent reconnection logic for the web interface.

Reconnection Timing is as follows.

1. First retry: 1 second delay

2. Subsequent retries: Exponential backoff (1.5x increase)

3. Maximum delay: 30 seconds

4. Maximum attempts: 10 attempts

5. Total auto-retry time: 2-3 minutes

A manual retry button appears after auto-retry exhaustion. 

Documentation Resources

Project repository: https://github.com/OpenResearchInstitute/interlocutor

Open Research Institute: https://www.openresearch.institute/getting-started

GitHub Issues for bug reports

Code contributions welcome via GitHub pull requests and filing issues. Documentation improvements welcome and encouraged. Testing and feedback valuable for development. Hardware testing on different platforms welcome and encouraged! 

The system is actively developed open-source software, and features may evolve. Check the project repository for the latest updates and documentation. 

Posted on

Inner Circle Newsletter June 2025

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

Efficiently Using Transmitted Symbol Energy via Delay Doppler Channels Part II REV A 06302025Download

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

Posted on

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/

Posted on

Inner Circle Newsletter May 2025

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 amateur radio bands.

You can get involved by visiting
https://openresearch.institute/getting-started

Membership is free. All work is published to the general public at no cost. Review and download our work 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.

Want more Inner Circle Newsletters? go to:

http://eepurl.com/h_hYzL 

and sign up. 

Contents

What’s Double Doppler Shift in Radar?

Open Source CubeSat Workshop 2025 Announced

Take This Job

An ORI Recommended Off-the-Shelf Photogrammetry Method for Dish Surface Mapping at Deep Space Exploration Society

Opulent Voice Protocol Progress

Efficiently Using Transmitted Symbol Energy via Delay Doppler Channels

Inner Circle Sphere of Activity

What’s Double Doppler Shift in Radar? Or, Why Do We Have a Factor of Two?

11 May 2025

As part of our ongoing work to provide an Earth-Venus-Earth (EVE) communications link budget for amateur radio and citizen science use, we have updated several sections of the Jupyter Lab notebook.

Link Budget Document Locations

A PDF version of the EVE link budget (lots of updates) is here: https://github.com/OpenResearchInstitute/documents/blob/master/Engineering/Link_Budget/Link_Budget_Modeling.pdf

The Jupyter Lab notebook is available right here: https://github.com/OpenResearchInstitute/documents/blob/master/Engineering/Link_Budget/Link_Budget_Modeling.ipynb

Explaining Doppler Spread

Doppler spread happens when our signal reflects off a rotating structure, like Venus. Part of Venus (the East limb, on the right side of Venus as viewed from Earth) is moving towards us. And, part of Venus is moving away from us (the West limb, on the left side of Venus as viewed from Earth). The parts moving towards us cause reflected frequencies to increase. In the radar community, when a target is moving towards you, it produces a negative Doppler shift. The parts moving away from us cause reflected frequencies to decrease. In the radar community, when a target is moving away you, it produces a positive Doppler shift. The signal reflected off the center of the planet is reflected back with little to no frequency change. Doppler spread is a quantification of how muddled up our reflected signal becomes due to the rotation of the reflector.

Gary K6MG writes “A rough calculation of venus limb-to-limb doppler spreading @ 1296MHz: 4 * venus rotation velocity 1.8 m/s / 3e8 m/s * 1.296e9 c/s = 31 c/s. This calculation is the same as K1JT uses for EME in Frequency-Dependent Characteristics of the EME Path and is motivated from first principles. One edge of venus is approaching the earth at a 1.8m/s velocity relative to the center of venus, the other edge is receding at the same velocity giving one factor of 2. The other factor of 2 is due to the reflection, the wave is shortened or lengthened on both the approach and the retreat.”

You may be curious as to how the wave can be shortened or lengthened on both the approach and the retreat.

The double Doppler shift happens because radar involves a two-way journey of the radio wave. For example, a station on Earth may transmit a radio wave at exactly 1296 MHz. This wave travels toward Venus. When the wave hits a moving point on Venus’s surface (like the East or West limb), the wave’s frequency as experienced by that point is different from what was transmitted.

If the point is moving away from Earth, it “sees” a lower frequency (in other words, a redshift). If the point is moving toward Earth, it “sees” a higher frequency (in other words, a blueshift). The wave bounces off part of Venus’s surface. The wave is now re-emitted at the shifted frequency that the moving point “sees” or experiences. So the reflected wave already has one Doppler shift applied. As this already-shifted wave travels back to Earth, a second Doppler shift occurs. This is because the reflecting point is still moving, so the wave gets compressed or stretched again. The wave returns to Earth with two Doppler shifts applied. Therefore, there is a factor of two in the equation explained by Gary K6MG.

An example with real-world objects can help visualize what’s going on. Imagine throwing a tennis ball at a person on a moving train, and the train is coming right at you. You throw the ball to the person on the train at 10 mph. To the person on the train, your 10 mph ball appears to be moving faster or slower depending on the train’s direction. Since they are moving towards you, your 10 mph ball’s speed is added to the train’s 30 mph speed, and the ball would arrive at what felt like 40 mph. From their perspective, they received a 40 mph ball. Now they are just going to “reflect” the ball back at you at the same relative force as they received it. Now the ball is coming back to you at that 40 mph plus the velocity of the train, which is 30 mph. So you are going to be catching a 70 mph fast ball! When you receive the ball, its speed has been affected twice by the train’s motion.

This works in the other direction as well. Now that the train is moving away from you, it’s a lot harder to catch up to. So, you get a baseball pro, your friend Shohei Ohtani, to throw the ball for you. The train is moving away from you at 30 mph. Ohtani throws the ball at 100 mph. The person on the train catches it. It arrives at what feels like 70 mph to the person on the train. He tosses it back to Ohtani at 70 mph, because that’s how fast it arrived, relative to him. The train takes another 30 mph off the velocity of the ball, and Ohtani catches a ball going 40 mph.

The important insight about radar returns off of moving objects is that the reflection does not simply “bounce back” the original frequency. The moving reflector actually re-emits the signal at the Doppler-shifted frequency it receives, and then this already-shifted frequency undergoes a second Doppler shift on its return journey.

Fun Doppler Shift Challenge

While driving your car, you are stopped for running a red light. You tell the police officer that because of the Doppler shift, the red light (650 nm) was blueshifted to a green light (470 nm) as you drove towards the stop light. How fast would you have to be going in order for this to be true?

A) 0.5 times the speed of light

B) 0.3 times the speed of light

C) 0.1 times the speed of light

D) 0.01 times the speed of light

E) 70 mph

Namulus Crossword Puzzle

ACROSS

  1. no longer a planet
  2. long for the modulation scheme used in Opulent Voice
  3. name of the human-radio interface project for Opulent Voice
  4. short for the modulation scheme used in Opulent Voice

DOWN

  1. name of ORI’s conference badge design
  2. modem name for Opulent Voice

Open Source Cubesat Workshop 2025 Announced

https://events.libre.space/event/9/overview

Want to represent ORI at this event? Join our Slack workspace and participate in the process of applying to present a talk, workshop, or roundtable. See https://openresearch.institute/getting-started

Information from Libre Space Foundation about the workshop is below:

Reignite the Open Source CubeSat Workshop!

Join Libre Space Foundation again for a two-day workshop to see how the open source approach can be applied to CubeSat missions with a focus on innovative and state-of-the-art concepts!

Open source software and hardware is empowering and democratizing all areas of life, so why not apply it to space exploration? The Open Source Cubesat Workshop was created exactly for that: to promote the open source philosophy for CubeSat missions and beyond. The sixth edition of the workshop takes place in Athens, Greece, hosted by Libre Space Foundation.

CubeSats have proven to be an ideal tool for exploring new ways of doing space missions; therefore, let’s remove the barrier of confidentiality and secrecy, and start to freely share knowledge and information about how to build and operate CubeSats. This workshop provides a forum for CubeSat developers and CubeSat mission operators to meet and join forces on open source projects to benefit from transparency, inclusivity, adaptability, collaboration and community.

The focus of this year’s workshop is to develop and apply open source technologies for all aspects of a space mission. The target audience of this workshop is academia, research institutes, companies, and individuals.

Starts Oct 25, 2025, 10:00 AM

Ends Oct 26, 2025, 6:00 PM

Europe/Athens – Serafio of the Municipality of Athens
19 Echelidon Street & 144 Piraeus Street 11854, Athens Greece

The workshop is free of charge but limited to 200 people.

“Take This Job”

30 May 2025

Interested in Open Source software and hardware? Not sure how to get started? Here’s some places to begin at Open Research Institute. If you would like to take on one of these tasks, please write hello@openresearch.institute and let us know which one. We will onboard you onto the team and get you started.

Opulent Voice:

Add a carrier sync lock detector in VHDL. After the receiver has successfully synchronized to the carrier, a signal needs to be presented to the application layer that indicates success. Work output is tested VHDL code.

Bit Error Rate (BER) waterfall curves for Additive White Gaussian Noise (AWGN) channel.

Bit Error Rate (BER) waterfall curves for Doppler shift.

Bit Error Rate (BER) waterfall curves for other channels and impairments.

Review Proportional-Integral Gain design document and provide feedback for improvement.

Generate and write a pull request to include a Numerically Controlled Oscillator (NCO) design document for the repository located at https://github.com/OpenResearchInstitute/nco.

Generate and write a pull request to include a Pseudo Random Binary Sequence (PRBS) design document for the repository located at https://github.com/OpenResearchInstitute/prbs.

Generate and write a pull request to include a Minimum Shift Keying (MSK) Demodulator design document for the repository located at https://github.com/OpenResearchInstitute/msk_demodulator

Generate and write a pull request to include a Minimum Shift Keying (MSK) Modulator design document for the repository located at https://github.com/OpenResearchInstitute/msk_modulator

Evaluate loop stability with unscrambled data sequences of zeros or ones.

Determine and implement Eb/N0/SNR/EVM measurement. Work product is tested VHDL code.

Review implementation of Tx I/Q outputs to support mirror image cancellation at RF.

Haifuraiya:

HTML5 radio interface requirements, specifications, and prototype. This is the primary user interface for the satellite downlink, which is DVB-S2/X and contains all of the uplink Opulent Voice channel data. Using HTML5 allows any device with a browser and enough processor to provide a useful user interface. What should that interface look like? What functions should be prioritized and provided? A paper and/or slide presentation would be the work product of this project.

Default digital downlink requirements and specifications. This specifies what is transmitted on the downlink when no user data is present. Think of this as a modern test pattern, to help operators set up their stations quickly and efficiently. The data might rotate through all the modulation and coding, transmitting a short loop of known data. This would allow a receiver to calibrate their receiver performance against the modulation and coding signal to noise ratio (SNR) slope. A paper and/or slide presentation would be the work product of this project.

An ORI Recommended Off-the-Shelf Photogrammetry Method for Dish Surface Mapping at DSES

Equipment Needed

DSLR or Mirrorless Camera: Any modern camera with 20+ megapixels (Canon, Nikon, Sony, etc.) Higher resolution is better, but even a good smartphone camera can work in a pinch. Fixed focal length (prime) lenses are preferred for consistency.

Tripod: For stable, consistent images. Or, a drone.

Reference Markers: Printed QR codes or ArUco markers. Reflective targets (can be made with reflective tape on cardboard). Tennis balls or ping pong balls (bright colors work well).

Measuring Tools: Laser distance meter for scale reference. Long tape measure. Spirit level

Software: Agisoft Metashape ($179 for Standard edition) OR free alternatives like Meshroom, COLMAP, or even WebODM

Process

Prepare the Dish: Place reference markers in a grid pattern across the dish surface. For an 18m dish, aim for markers every 1-2 meters. Include some markers at known distances for scale reference.

Capture Photos: Take photos from multiple positions around the dish, high and low. Ensure 60-80% overlap between adjacent images. Capture both wide shots and detail shots. For best results, take like 100+ photos of the entire structure. Take photos under consistent lighting (overcast days are best).

Process the Images: Import photos into photogrammetry software. Align photos to create a sparse point cloud. Generate a dense point cloud. Create a mesh and texture if desired. Will be very nice in presentations! Scale the model using your known reference distances.

Analysis: Export the point cloud as a CSV or PLY file. Use MATLAB, Python (with NumPy/SciPy), or specialized surface analysis software and use appropriate fitting functions to “fit” the point cloud to an ideal parabola. Calculate root mean square (RMS) error from the ideal surface. Generate contour maps of deviation. More great images for presentations!

Special Considerations for Radio Dishes

Dish Position: Ideally position the dish at zenith or a consistent angle for the full survey.

Reference Frame: Establish the feed support point and dish center as key reference points!

Example Workday Plan

Morning Session: Set up markers across the dish (2-3 hours)

Midday Session: Photograph dish from multiple angles (2-3 hours)

Afternoon/Evening: Process initial results on-site to verify quality (1-2 hours) don’t leave until the software workflow is confirmed!

Follow-up Analysis: Detailed surface error mapping and calculations (1-2 days or more)

This approach has been successfully used by amateur radio astronomy groups and small observatories to characterize dishes of similar size to DSES’s 18m antenna. The resulting data can directly inform the noise temperature calculations and help verify the antenna efficiency value (I believe 69%) we are currently using in our EVE link budget.

For DSES specifically, this could be implemented as a weekend workshop activity that would not only produce valuable technical data but also serve as an educational opportunity for members.

Do you see a way to improve this proposed process? Comment and critique welcome and encouraged.

Below: llustration-of-3D-spatial-reconstruction-based-on-SfM-algorithm.png from ResearchGate. This is an illustration of how a drone might assist with photogrammetry of a large dish surface.

Opulent Voice Protocol Development

Opulent Voice is an open source high bitrate digital voice (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) can also be used terrestrially.

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.

With the modem in an excellent “rough draft” state, with positive results in over-the-air testing, work on the human-radio interface has begun.

Introducing “Interlocutor”

The human-radio interface is the part of the design that takes input audio, text, and keyboard chat and processes this data into frames for the modem. It also handles received audio, text, and data. The target hardware for this part of the design is a Raspberry Pi version 4, and the project name for this part of the radio system is called Interlocutor.

Why Not Just Use the PLUTO for Everything?

Why don’t we use the PLUTO SDR for handling the input audio, text, and data? For two reasons.

First, the field programmable gate array (FPGA) on the device, a Zynq 7010, can handle the modem design, but there isn’t a lot of space left over after it’s programmed to be an Opulent Voice transceiver. The ARM processor on the Zynq 7010 is a dual-core ARM Cortex-A9. This processor is fully up to the task of running many of the functions of an SDR, but experiments with encoding with Opus on the A9 caused some performance concerns.

Second, there are no dedicated microphone or headset jacks on the PLUTO SDR. Everything, a keyboard, monitor, and headphones, would need to be connected through USB. While this is a potential solution, we decided to try separating the two parts of this radio system at the natural dividing line. Namely, the stream of protocol frames that are ready to process into symbols. We do quite a lot of work to prepare the frames, as the voice, control, text, and data are multiplexed in priority order. Voice is encoded with Opus, and there are two different types of forward error correction. By doing all this work on a Raspberry Pi, the frames can then be sent out over Ethernet to the radio. This enables remote operation as well as providing a useful modularity in the design. As long as the modem knows what to do with the received frames, an Opulent Voice signal is created and sent out over the air. The same Raspberry Pi codebase can interface to any Opulent Voice modem, as long as it has Ethernet.
This division of labor also easily enables Internet-only use.

No Replacement for Demonstration

It doesn’t work until it works “over the air”, and Opulent Voice protocol development is no exception. Turning good ideas into actually physically working implementations is the real value of an open source effort. There are always things that are discovered when drawings and sequence diagrams become code and that code is run on real devices.

A Raspberry Pi was set up with Raspian OS. Python was chosen as the language to develop an Interlocutor. A momentary (push) switch was connected to general purpose input and output (GPIO) pin 23 and a light emitting diode (LED) was connected to GPIO pin 17.

The first order of business was to get GPIO input (push to talk button) and output (push to talk indicator light) working. After this, audio functionality was sorted out. A USB headset microphone was connected, the pyaudio library was used, and after some back-and-forth, receive and transmit audio was confirmed present.

Next was installing of opuslib, which handles the encoding of audio with the Opus voice encoder. This was the point where a Python environment was necessary to have, as library management became increasingly complex. Python environments are software “containers” for the all of the custom configurations needed to make interesting things happen in Python. Environments are the recommended way to handle things. After the environment was set up, the next challenge was to restrict Opus to constant bit rate of 16 kbs and to fix the frame length at 80 bytes. This was not as straightforward as one might hope, as direct access to the constant-vs-variable bit rate settings in opuslib did not appear to be available. Eventually, the correct method was found, voice data was sent to a desktop computer across the Remote Labs LAN, and a receiver script in Python played the audio sent from the Raspberry Pi. This was a great “lab call” milestone.

Getting the voice stream established allowed for iterative development. With each new function, voice transmission could be tested. If it stopped working, then it was highly likely that the most recent change had “broken” the radio.

Chat was added and iteratively improved until it was successfully integrated with voice. Voice has a higher priority than text. Text chat messages will not interrupt a voice call. They will be queued up and sent as soon as the push to talk button is released. One can also have just keyboard-to-keyboard chat over the air, similar to RTTY. Having the option to use voice or chat with the same radio and the same user interface is one of the goals of Interlocutor.

Current codebase can be found at

https://github.com/Abraxas3d/interlocutor

Reducing Uncertainty

The protocol specification had control messages, for assembly, acquisition, access, authorization, and authentication, or A5 for short, as the highest priority traffic. These messages could therefore interrupt voice, text, or data communications.

A5 messages can be quite large. If these messages are very infrequent, then voice dropouts might be considered tolerable. However, we don’t really know how often a satellite will do authorization or authentication checks. That is up to the satellite or repeater operator. They may have a policy of anyone being able to use the resource at any time without any checking. Or, they may enforce any number of restrictive policies. There may be policies for emergency communications use, or a lot of A5 traffic for safety or shutdown reasons during mode changes. Since A5 traffic is the highest priority traffic, and since we really don’t know how often these messages will arrive, then we don’t know how much damage to voice calls will happen. Interlocutor development raised this issue. The solution currently being tested reverses the priority level of voice and A5 messages.

This means that an amateur operator could access the communications resource at most once with a voice call, before an A5 message could inform the station that it was not authorized or authenticated. This situation would occur if the satellite or repeater was permissive about access (which is something we do want, because we want people using their radios and talking to other hams) and let the amateur operator transmit first and “asked questions” later.

For example, an operator has been behaving badly on the air or harassing other operators. Their station ID may be added to a block list at the repeater. The repeater checks authentication and authorization, but only after people successfully access the resource. This would catch any blocked operators, but one voice transmission could potentially get through before the second-highest-priority A5 traffic was processed.

An obvious solution would be to do a full system authentication and authorization before any transmission is allowed at all. The downside to doing this is that it adds latency to accessing the satellite or repeater. We should try our very best to not have any worse performance in terms of ease of use when compared to a traditional FM repeater. Access latency is something that we are carefully tracking and monitoring during development, so any time the protocol can be modified to improve either the appearance or the actuality of latency, that is the choice we will make.

Accessibility

Using a Raspberry Pi (or similar computer) for Interlocutor also allows co-development for accessibility requirements. Opulent Voice must be as easy to use as possible. The Python script is currently a terminal program, but is designed to also be able to use an HTML5 interface. This is the second major modularity in the radio system.

The HTML5 interface is not in the code yet. Full functionality through a command line terminal access will be completed first, then the HTML5 interface written to expose all of the configuration and input and output from the terminal program. The goal is exactly the same behavior whether you are using Interlocutor from the command line or from a web browser.

Being able to run a radio using a browser means that the radio functions can be available on a very large number of devices, from ordinary computers using a keyboard or mouse, to screen readers, audio browsers, devices with limited bandwidth, old browsers and computers, and mobile phones and touch devices. It can be used by those with disabilities, senior citizens, and people with low literacy levels or temporary illness.

Our four areas of accessibility for Interlocutor are hearing, mobility, cognitive, and visual. HTML5 interface provides an enormous quantity of leverage in all four of these categories. While it may not be possible to design a perfectly accessible radio, we are committed to designing one as close to perfect as we can get. Accessibility improves the experience for everyone, so it’s more than worth doing.

Hearing

If you can’t hear, then how do you use our radio? First, Interlocutor has keyboard to keyboard or text chat mode built in. As long as you can see the screen and use a keyboard, you can use Opulent Voice. What about the voice traffic? There are several options. An operator may already have a trusted third party speech to text going on. However, since Opulent Voice uses Opus voice encoder, and since the voice quality is quite good, we can include speech-to-text in Interlocutor. There are cloud and local options for the Raspberry Pi, and we’re going to test Whisper https://github.com/openai/whisper as well as Faster-Whisper (fwhisper) https://github.com/SYSTRAN/faster-whisper

If the performance can’t be done with on-board solutions, then one of the cloud-based options will be considered. Speech-to-text would be one of the run-time options for Interlocutor.

All of the controls must be made easy to use without hearing. This means that the HTML5 layout will prioritize simplicity and accessibility and give clear cues about audio status. We will need specific advice here on how to lay out the page.

Mobility

If you have limited mobility, but you can use a browser, then you can operate Opulent Voice. The HTML5 interface will be simple and easy to use for people with limited movement. We understand that we need to support as wide a variety of inputs as possible and not get in the way of or prevent the use of any trusted third-party solutions that the radio operator already has up and running on their computer or device. We will not have keyboard traps in the interface, where you can “tab” in to a configuration setting, but then can’t “tab” back out. Want to take Interlocutor with you? The entire radio system, even as a prototype build, is not heavy or excessively bulky. The parts are all available off the shelf and can be set up all in the same location or in different locations, connected by Ethernet. Interlocutor can be with you wherever you are in your house, and the radio can be installed in a radio room. The push to talk button is on a GPIO pin in the current code base, it provides a
hardware interrupt with minimal latency to the Interlocutor code, and it is very simple design to have a physical button on the radio case. However, this does mean you have to press down on the button as long as you want to talk. Someone with limited mobility may find this not easy or not even possible. A USB foot switch, to give just one example, is a very common way to activate a radio and may be a more accessible inclusion.

Cognitive

Configuration options will stay open as long as necessary for a radio operator to understand and select them. While Opulent Voice is an advanced and technical mode, it should not require the operator to be advanced or technical to fully enjoy it. There will not be any flashing lights or complicated graphics. The vocabulary for configuration will be consistent and simple. Since the code is open source, additional complexity, or an even simpler interface, can be exposed if desired with alternate HTML5.

Visual

Interlocutor must not get in the way or prevent the use of any third-party accessibility technologies that are used for visual impairments. It also must be as accessible as possible on its own. For visual accessibility, high-contrast displays, large buttons, and braille labels are commonly used. A Raspberry Pi in a case doesn’t have a lot of room for Braille labels, but incorporating them into a 3d printed case would be a good start. Some radios include voice prompts for navigation and settings, or integration with screen readers. There are radios that have incorporated braille keys. Part of the process of developing Interlocutor will be identifying what methods can be easily integrated into the code base.

What Happened Next?

What came next? The codebase had quite a bit of functionality. It delivered audio and chat frames, with priority Opulent Voice encoding, over Ethernet. Opus frames are the lowest layer of the protocol stack, and the Opulent Voice headers are the highest. Over the past few days, we installed RTP, UDP, and IP layers. This means that the stream of frames can now be handled by a very large number of existing applications.

With strenuous testing, a decision will be made whether this additional overhead is worth keeping or not. The only way we can make that decision with any confidence is to test the assumptions with real-world use. You can help.

Error correction still needs to be fully implemented, and a COBS encoder/decoder https://github.com/OpenResearchInstitute/cobs_decoder for distinguishing the frame boundaries of the non-Opus data. We are thinking that the division of labor will put this work on the modem side, keeping the Interlocutor focused on Internet data frames.

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/

Revision C 05132025 Efficiently Using Transmitted Symbol Energy via Delay-Doppler Channels — Part IDownload

Please see the above article by Pete Wyckoff, KA3WCA. This is part one of a series about the technical side of modern Earth-Venus-Earth amateur radio communications. ORI is proud to present his work.

For more than 20 years, Peter S. Wyckoff has designed and tested a wide variety of digital communications systems, modems, and antenna arrays, particularly for the satellite communications industry. He graduated from Penn State University with an MSEE in 2000 and graduated from Pitt with a BSEE in 1997. Since graduation, he has been awarded seven U.S. patents, which are mostly about co-channel interference mitigation, antenna array signal processing, and digital communications.

ORI Inner 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.

28 May 2025 – ORI was represented by two volunteers at KiCon 2025, held at University of California at San Diego. The conference is the major North American event for KiCad, a free and open-source software suite for Electronic Design Automation (EDA).

13-23 June 2025 – Michelle Thompson is on the road in Arkansas, USA and will have some free time to meet up with volunteers and supporters.

30 June 2025 – Future Amateur Geostationary Payload Definitions comment deadline.

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.

5 September 2025 – Charter for the current Technological Advisory Council of the US Federal Communications Commission concludes.

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

https://www.facebook.com/openresearchinstitute
https://www.linkedin.com/company/open-research-institute-inc/
https://www.youtube.com/@OpenResearchInstituteInc

Proudly powered by WordPress