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.