Date: August 2025

For this first update, we are going to cover work done over the last several months.

DVRef.com

Maintaining the hosts files for reflectors has been an ongoing challenge for MMDVM. Numerous requests come into the to add or update reflectors. Most of the work has been done by Jonathan G4KLX. Occasionally, these are submitted as Pull Requests which reduces that burden significantly.

Through a team effort DVRef.com was created. This is a self-service portal that allows reflector operators to add, update, and delete reflectors on their own. They are now the source of record for host files used by MMDVM, Pi-Star, and WPSD. DVRef.com manages MREF, URF, DMR (none Brandmeister), NXDN, P25, and YSF reflectors.

This service has reduced the burden on all three projects and given reflector operators better control over their reflectors. DVRef has added more fields to the tables to help users understand who is responsible for each reflector and how to get more information about the organization. This project has helped the community in a significant way.

MQTT

MQTT, or Message Queueing Telemetry Transport, is a system were services can publish information and subscribers can retrieve the information. Sources can post information to the server, or Broker, without concern for where the information is being consumed. Subscribers (one or more) can subscribe to the information and receive it as it becomes available.

This makes it very easy for a process to post information asynchronously (meaning the process doesn’t get blocked) and MQTT will deliver to another process, on the same computer or a different computer, or several different computers.

Why is this important for MMDVM? Before MQTT the main loop in MMDVM was managing the displays directly. Meaning the loop would send information to the screen and wait for the screen to respond before continuing the loop. This could cause delays that were enough to affect audio (causing drop outs). Moving to MQTT for this moved the display code outside the main loop in MMDVM and allows it to be handled in a separate process, a process that could be blocked and not affect the processing of audio packets.

MQTT also opens many other doors. For example, your display no longer needs to be attached to your hotspot. It could be a different device, a desktop computer or a mobile device. Consider taking advantage of this for a hilltop repeater, or a group of repeaters. You could create a central dashboard for all of your repeaters.

MQTT was also implemented for logging, for all the same reasons as for the display. Just like for the display, you can subscribe to the logging topic and get the log stream delivered to your client. Again, think about hilltop repeaters.

You should know this only allows you to retrieve these streams from the time you subscribe, there is no history available. But, you could create your own database and store both streams locally.

Currently this work is in the “mqtt” branch of Master. We have not moved it into Master yet because it would break WPSD and Pi-Star. We will merge this into Master when the platforms are ready to use MQTT. In the mean time, you can build from the MQTT branch and run it locally. You can start work on your own displays and consoles

Transcoder

We haven’t talked about this project very much, but is has great potentional and it is functional at this point. We are working on a transcoder, an any mode to any mode transcoder. You will be able to connect this to the USB port on your hotspot and get anything from anything transcoding in real-time. We have this working now on prototype hardware graciously provided by ZUMRadio at no cost to the project. ZUMRadio is still finalizing the hardware, but the intended format is a thumb drive sized module that will plug into a standard hot spot. We plan to have this available for display and demonstration at Pacificon in October 2025.

The transcoder software will consist of an MCU and either one AMBE 3003 or two AMBE 3000 modules. We are looking at this hardware for cross-mode operations, for example D-STAR to P25. The firmware can be found in the MMDVM-Transcoder repository. The other component of this project is the cross-mode software. This sits between MMDVMHost and the gateways. When in cross-mode, MMDVMHost sets up the cross-mode software for the input mode and output mode and starts sending packets. The cross-mode software uses the transcoder as needed to convert packets from one mode to the other. The software for the cross-mode software can be found in the MMDVM-CrossMode repository.

You won’t see this software on your hotspot until it is supported by WPSD and Pi-Star. As you can imagine, the configuration page will be fairly complicated.

ST Micro WL33

Most of the hotspots on the market use the ADF7021 chip to generate RF. It has been a great chip, but Analog Devices has marked it for end-of-life. In conjunction with ZUMRadio we started looking at the STMicro WL33. This is an STM32 processor with RF generation capabilities built in. It sounds like a perfect match for a hotspot and a great replacement for the ADF7021.

ZUMRadio once again designed and built a few prototype boards (at no cost to the project) and our developers went to work. After several weeks of work and a good amount of support from STMicro, we are not seeing the results we were hoping for. We are not planning to put a lot more time into this chip, although there are a few things left to try and we are waiting on some responses from STMicro.

We will continue to work on alternatives to the ADF7021, like the SX1255.

Our Supporters

• ARDC – Provides the grant that makes this work possible
• ZUMRadio – Ongoingly provides prototype and production hardware at no cost
• Martin Alcock VE6VH – A contributing developer that made significant progress on the WL33 project

You can be a supporter as well. Go visit our Open Collective page, there you can make monthly or one-time donations. While ARDC has been our primary supporter, every dollar helps to make MMDVM better. Your support dollars are important.