<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Project on Derby Raynet - M0YDY</title><link>https://derbyraynet.gitlab.io/tags/project/</link><description>Recent content in Project on Derby Raynet - M0YDY</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Sat, 07 Feb 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://derbyraynet.gitlab.io/tags/project/index.xml" rel="self" type="application/rss+xml"/><item><title>Another DMR data and audio offline integration update</title><link>https://derbyraynet.gitlab.io/posts/2026-02-07-dmr-logging-update/</link><pubDate>Sat, 07 Feb 2026 08:00:00 +0000</pubDate><guid>https://derbyraynet.gitlab.io/posts/2026-02-07-dmr-logging-update/</guid><description>&lt;p>On our offline DMR logging, tracking and recording project there has been further cleaning of the software and a small architecture change over the last month, slightly delayed due to dependency changes in the app used to view the data.&lt;/p></description></item><item><title>DMR data and audio offline integration update</title><link>https://derbyraynet.gitlab.io/posts/2025-12-20-dmr-logging-update/</link><pubDate>Sat, 20 Dec 2025 00:00:00 +0000</pubDate><guid>https://derbyraynet.gitlab.io/posts/2025-12-20-dmr-logging-update/</guid><description>&lt;p>As mentioned before we have been working to fully integrate DMR position, messaging and audio into a single logging solution for Derby Raynet Control to use during events without needing any complex infrastructure or being dependent on the Internet.&lt;/p>
&lt;p>Since the last update we have overcome most of our issues and are now working on reliability and scaling improvements.&lt;/p>
&lt;p>Previously we could &amp;ldquo;listen&amp;rdquo; to the repeater over RF at control and decode the data side of DMR (messages, position reports and on air caller information), we have recently made progress in a number of areas in order to add audio recording and searching capability.&lt;/p></description></item><item><title>DMR tracking update</title><link>https://derbyraynet.gitlab.io/posts/2025-07-02-dmr-tracking-update/</link><pubDate>Wed, 02 Jul 2025 16:13:00 +0100</pubDate><guid>https://derbyraynet.gitlab.io/posts/2025-07-02-dmr-tracking-update/</guid><description>&lt;h2 id="using-digital-aprs-data-to-find-coverage-problems">Using Digital APRS data to find coverage problems&lt;/h2>
&lt;p>During the Ashgate Sparkle event last month our Sweep walker was sending position beacons at a fixed interval over our portable DMR repeater, with this data being recorded at control.&lt;/p>
&lt;p>Since these position reports where received on our regular repeater channel instead of via a different mode and band we can use this as a repeater coverage indicator. Using a new update to the Event Comms application we have been able to generate real coverage stats for our repeaters coverage.&lt;/p></description></item><item><title>DMR messaging and positions without a network</title><link>https://derbyraynet.gitlab.io/posts/2025-05-16-dmr-messaging-without-a-network/</link><pubDate>Sun, 25 May 2025 00:00:00 +0000</pubDate><guid>https://derbyraynet.gitlab.io/posts/2025-05-16-dmr-messaging-without-a-network/</guid><description>&lt;p>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.&lt;/p>
&lt;p>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.&lt;/p></description></item></channel></rss>