DMR messaging and positions without a network
Derby Raynet has been using a DMR repeater for a few events now. This has improved clarity in noisy control environments and having a second time slot available when more privacy is required is a great advantage. However, we have not been making use of the additional digital features available.
It is common to share APRS like information (position and SMS style messages) over Internet linked DMR repeaters through one of the networks. The networks convert this data, and send it to APRS-IS, which can then be easily viewed on a map. For emergency scenarios or charity events in isolated areas we aim to create our own independent networks to provide redundancy when possible, so try to avoid relying on this.
We could achieve this with our own microwave network (e.g. ARDEN) between control and the repeater(s), however provisioning microwave links will require additional setup and planning, plus may limit the locations for the repeater.
Our Solution
The solution Derby Raynet is currently experimenting with is to send all position beacons and messages over our DMR repeater to a talk group (rather than private calls as used normally for D-APRS beacons), this results in the position beacons or messages being re-broadcast by the repeater and can be received by anyone in range.
To make this useable in Control we are working on a DMR receive only modem so that this data can be used on phones, tables or laptops.
The development is split into four parts:
- Data capture - receiving the data from the repeater on 70cm, and extracting the bytes.
- Data conversion - converting the DMR bytes into usable info.
- Data sharing - allowing multiple devices to use the data.
- Display - presenting a map with positions and messages to users.
Data capture
Receiving the data (capturing it) has gone through a number of options so far. The first trial was with a minor modification to the DSD software and a RTL stick, this proved it could be done, but was not sensitive or reliable enough.
We then experimented with modifying the OpenGD77 firmware in a TYT MD-UV380. This modification allowed any data on the current channel to be streamed to a USB serial interface. We successfully used this on our Ashgate High Peak Trail Walk. I should say a big thank you to the team who created and maintain the OpenGD77 firmware, the small firmware modification would not be possible without their hard work.
This was the first time most of the club members had seen it working, and it encouraged a lot of further discussion. The repeater coverage results, as seen below will also help planning in the future:
Figure 1: Section of map showing weak and good repeater coverage areas with darker lines following footpath, data received with a modified TYT MD-380uv.
We may continue down this route and try using an MD-9600 for both control operations and this purpose, plus it may be possible to further improve it to allow transmission as well. Currently the modified code is very much a hack and is not good enough to share.
Our latest trial is with a MMDVM board. This is still early, but as of yesterday this seems to be working. We have modified the firmware to provide a DMR user mode option which allows the board to listen to a DMR repeater output, and provide the data over a serial port. The code is simpler, and performance seems good, and we should be able to have one hardware platform for both D-APRS and APRS, the downside is that it requires an additional receiver, and probably can’t be used to transmit data.
Data conversion
Version 1 of the DMR converter was written in dotnet, and was able to decode:
- D-APRS Anytone beacons.
- D-SMS Anytone messages.
- DMR Current talking user ID.
This conversion was, and still is basic, providing the minimum needed.
This code is now undergoing a rewrite in golang to improve performance and create a more complete implementation of the spec using existing dmr libraries.
In parallel with this we are also using another dotnet app to convert APRS UI frames into the same format so that we can support both technologies.
The Raspberry Pi was also setup to use a GPS as its time source, and operate on a read-only file system, with logs written to a USB stick.
Data sharing
In order to share the converted data and make it available to an app we are publishing all of the converted data to a Mosquitto MQTT topic.
This means that the easy to read data can be shared with multiple devices, and is not lost when a device either goes to sleep, or moves out of range.
Below you can see how the system looks:
Figure 2: System Diagram.
Data display
For the last few events we have been testing the Event Comms app. This is purpose designed for Raynet use and allows checkpoint locations, expected open/close times, assigned marshals, and routes to be combined in one app, and shared with team members. It also allows live messages, position reports and on air talker information to be displayed and logged by consuming the MQTT messages created above.
Figure 3: Example Event Comms screen on a Chromebook.
This is all experimental, and development is continuing. Our current focus is to productionise the code so that we can make it more widely available. If you would like to be involved let us know.
In the future we are hoping to:
- Publish manually logged entries back to a MQTT topic, to allow syncing to other devices, plus provide redundancy in the event of a device failing.
- Document the MQTT message structure used by Event Comms.
- Integrate Lora APRS or Meshtastic for more tracking options.
- Investigate transmit options either with OpenGD77 or MMDVM.
- Test and extend support for other non Anytone rigs.
- Complete testing and release the Event Comms Android app to the Google Play Store (then maybe other platforms).
- Record the audio streams and enable playback in the app.