Saturday, December 31, 2016


Finally... the first small batch of the ZUM boards Rev. 1.0.1 are back from the CM.
They have been tested and will be shipping out to people who have been so patient.
The big volume will be early January 2017.
If your name is on my list I will be in contact shortly.
Thanks you for remaining with us !

Wednesday, December 7, 2016



The port of the MMDVM code to the STM32F4 series has taken a major leap forward
As per Jim's email to the MMDVM Yahoo group late last night
Does that guy ever sleep :-)

All the source code is already waiting on github. Andy posted the modified Standard Peripheral Drivers in the Files section of the MMDVM Yahoo group. I just posted a text document detailing how to build the code and program the boards.

To start we have support for the STM32F407 Discovery board and the STM32F446 Nucleo board.

I'm attaching a picture of Andy's setup. He's got it working well on DMR. You can also see that he's included the TCXO board for a more accurate clock. I've been doing my testing on DStar.

The instructions include details for building under Windows, OSX and Linux using gcc. There is also limited support for building the code under CooCox (Win32).


Saturday, November 19, 2016

Mid-November update


Mid-November update


After a few long months of designing, testing and fine tuning, we finally have some concrete things to share with you guys. It might not be exactly the kind of news you were expecting, but we’re confident you won’t be disappointed...

Despite our best efforts, the MMDVM revision 1.2 is still far from completion.

The design we originally envisioned for 1.2 incorporates a really good filter, but it is quite “aggressive” and requires more work, a lot more than we anticipated, both in software and hardware.

You probably noticed the messages some of our rev 1.2 testers exchanged on the Yahoo group over the last few months … We tested and tweaked, and then tested some more but unfortunately it’s just not ready.


A big “Thank you!” goes to all those who helped us design and test this board. We owe you a beer! (or five?!)

We’ll continue to work on the MMDVM revision 1.2 boards, and we hope we’ll find a solution

In the meantime, as a small and well deserved reward for your patience, we’d like to present you a new board: the Rev 1.0.1 board.

We designed the new Rev 1.0.1 board with the following features:

  • 12Mhz TCXO
  • Multi-turn pots
  • RSSI Inputs
  • I2C output (to connect LCD)
  • A serial output (to connect LCD)
  • Additional radio sense and control lines to be used for DR1X conversation
  • Protection diodes on all the radio signals
  • Additional Status LEDs
The PCBs are ready and they’re heading to the CM. However, it is mid-November and the timing is not really great. As the holiday season approaches fast, the deadlines become really fluid… We’d love to tell you that we’ll ship them in 2-3 week but we simply don’t know.
Our best guess is: “December”…
 
Once we get into production we will off course be releasing the schematics (PDF)

Saturday, October 8, 2016

Over the last couple of months we have been struggling to get the MMDVM Rev 1.2 into your hands.
We’ve hit a few roadblocks and that put us behind the original schedule. 

The first batch of boards was ready about a month ago, but unfortunately we had to scrap them due to a manufacturing error. Thankfully, it was just a test run …

We are confident that we’re on the right track this time and we think the first boards will hit the post office mid-November.

We’re sorry about the delays but we don’t want to compromise on the quality of the product. We’ve never failed you in the past and we’re not about to start now.

If you no longer wish to wait for the MMDVM Rev 1.2, we understand and we’d like to ask you to contact Bruce to remove your name from the waiting list.

Thank you for your patience,

The ZUM MMDVM Team

Thursday, August 25, 2016

A very interesting update from Jonathan posted on the facebook page 8/25/2016

After some investigating by some very clever people, it appears that a simplex (DMO mode) DMR system is possible without having to use radios with very fast TX/RX changeover times. Therefore I have started work on such a mode for the MMDVM. This would potentially allow for a tri-mode simplex gateway since D-Star and C4FM already allow for simplex use.
This will use exactly the same hardware as a duplex MMDVM, the same interface boards for example, but with only one FM transceiver instead of two, and of course no need for a duplexer.
I hope to get the first versions available next week. See the MMDVM Yahoo! group for more details.

Tuesday, August 16, 2016

Thursday, August 4, 2016

We’re back with a little update.

Sorry about keeping you in the dark. You know how it is: the family and a full-time jobs leaves us very little time for hobbies. Not to mention the irresistible nice weather (at least up here in Canada)…

That being said, we’re a little bit behind the schedule with the new boards but we’re moving in the right direction.

First of all, the unreleased revision 1.1 that we mentioned at the Dayton Hamvention this year got so many improvements that we decided to launch it as revision 1.2. The change in name won’t affect the end users, but it helps us keep track of the things we do.

Here’s what kept us busy all this time:

•             PCB change from 2 layers to 4 layers (New internal layers for 3.3V and GND)
•             New filters and amps (designed by EB4FBZ)
•             Improved routing of traces
•             Added protection diodes to all external pins
•             Adding one more op-amp in both transmit and receive paths for new filters
•             Added one more radio status and one more control line
•             Added two more status LEDs
•             Added circuitry for both TCXO and crystal for low ppm clock (the boards will ship with TCXO)
•             Corrected long standing connector spacing problem
•             Changed from 270 degree turn trimmers to multi-turn trimmers
•             Changed critical paths to higher quality resistors and capacitors
•             Added solderable jumpers to bypass large bypass capacitors
•             Added external RSSI input connector - goes to ADC pin on Due

Thank you for your patience and continuous support!

Friday, May 20, 2016

Press Release :: MMDVM V1.1 · Better filtering. Integrated clock. Extended connector

We are proud to announce the impending release of the KI6ZUM Zum MMDVM Rev 1.1 board

Features of the new board include: improved filtering by EB4FBZ, integrated clock, new 8 pin connector for additional control lines.

As this board is still a few weeks away and we don’t want to disrupt the amazing things that our fellow hams are doing with the current board, we will be continuing to supply the MMDVM Rev 1.0 boards at a special price of $35.00.

If you already ordered the MMDVM Rev 1.0 board, but instead, you'd like to wait a little longer for the MMDVM Rev 1.1 board, please contact Bruce to inform him about the change as soon as possible. 

If you want to take a look at the new boards, you have a chance to do so at Dayton Hamvention where Guus has graciously allowed us some space at the DVMega booth EH0519.

Thank you for your continuous support,
The MMDVM Team

Wednesday, May 18, 2016

Very cool
First C4FM QSO on VK4TUX mmdvm YSF Reflector


Friday, May 6, 2016

A great Video from Richard on using the MMDVM with the DR1X repeater making it trilingual... D-Star, DMR and Fusion

Friday, April 8, 2016

Tick. tock.... As they say time waits for no man !
the Zum Clock PCB's just arrived
sorry had to make a clock joke after all its Friday smile emoticon
We have decided to offer it in two versions
the kit will be shipping next week the fully assembled and test version in about 2 weeks max
1. Kit ( these are SMD parts)
contains PCB, 12Mhx TCXO 2 caps and the edge connector )
shipped Via Airmail $12.50 USD
2. Fully assembled and tested $18.50USD
shipping extra
Contact me at ve2gzi@gmail.com


Thursday, March 31, 2016

How to turn your DR-1X into a DMR repeater using the MMDVM
By Ian Tulley VK2HK

Nice work Ian , thanks for sharing

Thursday, March 24, 2016

Tick Tock..... Tick Tock...How about a Zum Radio High Stability Tcxo for your DUE ?!... 
more details to follow soon :-)


Friday, March 18, 2016

VK4TUX MMDVM Zum Support packages
Pi 2-3 & Odroid C1 images
Features

Based on
For Pi 2 and 3 Ubuntu Mate 15.10
For Odroid C1 and C1+ Ubuntu KDE 14.0 LTS
Full Graphical interface

Full MMDVM package
MMDVMHost and MMDVMCal full support for the ZUM board.

Also includes the DUE firmware loader which automatically downloads the latest DUE MMDVM code
updates the DUE and restarts it for immediate use

A template file system for Brandmeister Server (DMR) or mode selection (DSTAR/C4FM)

Full support for Ircddbgateway and D-Starrepeater programs including
DV4Mini and DVAP

Contact vk4tux with support queries ; vk4tux@bigpond.com

We have significantly upgraded the website bandwidth to enable faster and more downloads
They are here

Thursday, March 17, 2016

As of today the second batch of MMDVM REV_1.0 Boards are all mailed out sorry for the delays, Paypal invoices will follow shortly !
If you where on the second list and you didn't reply to my emails
your board(s) will shipped to the people on the third list in the coming week !

Friday, March 4, 2016

A post from Jim Ki6ZUM the designer of the current MMDVM Zum board... in response to the demise of the Ardunio Due...platform and a replacement platform
I'm very please to see all the interest and enthusiasm for the STM options. As I mentioned in an earlier post, there's been a lot of work going on in the background. I too would like to be able to sunset our reliance on a discontinued board.
The Mbed environment is not my favorite platform, especially because it uses an online compiler. Lately I've been having a lot of trouble with the difficult "error 230" which basically means you are out of luck compiling until you come back later. I also haven't had a lot of luck exporting the project so I can use an offline compiler. I've also spent quite a bit of time trying to work around the the issues with how they do ADC. I gave up quite a while ago.
I'm attaching a couple of pictures to show how I've been doing my testing. The first one just shows that I've using an STM32F4Discovery board that I jumper to a Papa prototype board, and connect to the PC via an FTDI adapter. Getting the VCP interface has been fruitless so far.
The second picture is an early prototype of a Pi adapter board. It is using the STM32F405 chip. It was originally designed when I thought that the Pi Zero was going to become easily available soon. I'm afraid the Pi Foundation isn't putting a lot of effort into producing them now that they've released the Pi 3. It is a bit of a problem in that I can't actually buy any new Pi boards at the moment from any of the official US distributors.
Based on the feedback so far on the boards from Bruce, it doesn't look yet like there will be too many hardware changes to the basic MMDVM radio interface design. There are a few other changes that will be included in the next Pi prototype, including probably abandoning the Zero footprint.
For those who would like to help get the STM code working, I'd recommend looking at the F4Discovery board. It is cheap and it works well. It is a fairly new board so I'm confident it won't be discontinued any time soon.Since we are a long way away from being able to offer the Pi boards for sale, you'd need to use the Discovery board with an existing MMDVM board (similar to the attached picture). A lot of thought and testing has gone into the selection of the F405 chip, but I'm open to discussion about other parts.
As far as software development goes, I have several failed attempts with various development environments. I'll try to publish soon some of what I've managed to get working.


Thursday, March 3, 2016

Latest update from Jonathan....

Status - 3 March 2016.
Things are moving on nicely. A number of repeaters have opened up with the MMDVM, usually as DMR only, and I think many more are on their way. I would imagine that the number of MMDVM systems could top the 100 mark within a few months.
For the most part development is now slowing down, due to the various elements reaching maturity. So here is the status of each major component:
D-Star. This is pretty well complete and some serious bugs squashed within the last few weeks. The host D-Star repeater is simpler than the D-Star Repeater, but that’s fine by me as the original repeater software has become rather large to say the least. It’s possible/probable that some of the extra functionality of it will migrate over to the host, but I’ll be careful about which parts.
DMR: This has been the most fun to implement, lots of interesting and varied techniques to learn and use. The DMR side is pretty well complete. The only known missing part is the regeneration of ¾ rate data, so if anyone can give me some pointers as to how to progress I’d appreciate it. I can probably do the encoding, but decoding has me baffled.
Fusion: This is a mess. The more time I spend with it, the less enamoured with it I become. The host is RF only, and I don’t see that changing in the foreseeable future. Fusion has some great ideas, but most of it is pretty poor, and doesn’t lend itself to network transportation, unless you exclude VW mode, which would be a shame. I consider Fusion to be a curiosity! Any help in regenerating the audio would be appreciated. I think I have the callsign part correct, but I’m not sure.
Modem: Apart from supporting the STM32 series of chips, the only enhancement planned is to allow the MMDVM to co-operate with another repeater controller to form a multi-mode repeater (i.e. FM + MMDVM). This will include adding two new pins, one would be an MMDVM “I am busy” pin, and an input from the other controller to say that it is busy and the MMDVM should not operate. In later boards these pins will be added, but in the interim I have a quick and dirty solution. For a DMR only MMDVM, you can use the transmit out line to lock out the other controller, and I will add a compile option to allow the currently unused COS input to be used as the MMDVM lockout input.
Display: I will add support for other displays in due course, it’s a matter of identifying suitable ones that are cheap. The currently selected Hobbytronics display isn’t cheap, I know, but it fits the bill nicely. I am sure others will too.
Jonathan G4KLX

Wednesday, March 2, 2016


Yes we know that some people have been having "issues"
with the JST-6 connector. smile emoticon :-)
When the next batch of boards ships around 12th March
we will be including a small cable (see picture below) free of charge.
This might slightly increase the mailing cost for people that are ordering multiple boards.
I want to be fair and am offering the same to the people that have already been shipped boards , Please contact me at ve2gzi@gmail.com

Sunday, February 28, 2016

Now this is pretty cool
Adrian VK4TUX has written a script that will automatically download the latest MMDVM firmware 
Stop the Due, re-program it and restart the Due ...... Right Now its running on the Odroid XU4 but he will be making it available in the coming weeks on the C1+ and various RPI images


Friday, February 26, 2016


Second day and he is up and running !!, Look out world the MMDVM Wave is coming


Thursday, February 25, 2016

Eric VE2NBZ
has the first Zum MMDVM up and running in Canada 
Good Work Eric 

Monday, February 22, 2016

Adrian got his... the rest are as they say "in the mail" today and tomorrow 
Paypal invoices will be a bit delayed for the "other" work reason :-(


Sunday, February 21, 2016

Gent's , I am contacting people that are on the first list of boards.I have emailed everybody and heard from 98% of you for mailing addresses
There are a few that I have emailed and I have re-emailed if I don't hear from the people that I have emailed twice then some of the lucky people on the second list will be getting there boards.. not trying to be mean... just fair !

Tuesday, February 16, 2016


C4FM repeater working on the MMDVM... Great work guys !


Thursday, February 11, 2016

Good evening Gentlemen !
Boards are back from rework and they look great all the mistakes are fixed ..
I will be getting them out next week sorry for the delay 
but I am getting Married this weekend !

Tuesday, February 9, 2016

Very Cool Richard...
Sorry I did clean up the digikey cart and I added alternates for the out of stock cap


Friday, January 29, 2016


The Friday NOT so funny Picture....
So I got the boards back yesterday and this is the result !
Can you see the problem ?......needless to say back to the CM for re-work .... Sorry guys ! ,this is going to add a few more days to the lead-time :-(

Wednesday, January 20, 2016


I have been asked for a block diagram of what it will take to built a basic DMR repeater based on the MMDVM board.. so see below thanks to Chris for putting it together.


Please do remember that there is still a lot of active testing and experimenting going on with the code.

Tuesday, January 19, 2016


Just a quick note about  the boards
for the first build I have less than 20 units (Assembled and tested) left available if any body still wants one let me ASAP. 
I should have them back from the CM next week !
I have the unpopulated PCB's and will start shipping these later this week to people that have requested PCB's only so expect a email from me shortly.

Monday, January 18, 2016

Wow this is coming along in Leaps and Bounds
Latest code from Jonathan listen to the quality No drop outs
Uber Cool Jonathan !!!!!


Friday, January 15, 2016

Adrian having a successful QSO using the latest firmware
Great work guys !!!!
If you are bit impatient ( Like me ) skip to about 1:10min


Wednesday, January 13, 2016

Thanks everybody for emailing me and letting me know that you would like a board,

Just to let you know the first production run is a little more than 50% sold !
Please if you emailed me about a board and didn't get a reply email me again
( I was seriously swamped ) but I think I got back to everybody
Remember we will NOT be taking any money till we ship boards
and we will be in contact with you before we ship just to make sure you still want it


If you want either a PCB or a fully assembled unit email me ve2gzi@gmail.com

Tuesday, January 12, 2016



A very cool Video from Adrian VK4TUX
showing how much progress has been made...

So what exactly is going on...
Adrian has the MMDVM plugged into two radios set up as a repeater one for Tx and one for Rx
the radios are a Motorola CDM1250 and a Yaesu FT7900E
its is being controlled by a Odroid XU4 running Jonathans DMR controller software and linked to the Brandmesiter Network

Right now he can only listen as more work is needed on the Tx side this is truly amazing such giant strides are being made.


Monday, January 11, 2016




Hello
as most of you have probably guessed Jim Mclaughlin (KI6ZUM) and I Bruce Given (VE2GZI) 
have been teasing you with various posts in the past few weeks.

Well we have been working together for a little while and are proud to announce the that we will be producing the MMDVM REV 1.0 for the Due

We should have boards back in about 2.5 to 3 weeks
initial costs will be 
MMDVM Rev 1.0 fully assembled and tested $40.00USD ( Airmail additional but will be cheap )
MMDVM Rev 1.0 PCB not assembled airmailed anywhere $10USD

Please drop me a email at ve2gzi@gmail.com if you are interested in being added to the waiting list
payment will be by Paypal and you will be invoiced when the units ship

Best regards
Bruce Given
VE2GZI

Silence is Golden

When receiving via the Internet into a repeater the problem of how to handle network drop-outs occurs. The transport mechanism of choice for streaming is UDP which does not guarantee delivery, but delivers data in a timely manner. Perhaps more importantly, unlike TCP it will not stall waiting for a lost frame, it will just continue. From the users’ point of view it is probably better to have a small gap in the audio than to have it stop until the lost frame has been retried and received then continue. This delay could be considerable fraction of a second.
 
With D-Star which has frames that contain 20ms of audio, a lost frame is for the most part not a big deal. What is important is how to handle it. A few years ago I did some tests and determined that for gaps of 40ms or less, it is OK to repeat the last 20ms of audio to fill the time. It sometimes sounds a little odd, but not too bad. A gap longer than that is better served by silence as the repeated sound really starts to grate if held for too long. This approach has been is use for a number of years and seems to sound reasonable.
 
DMR uses blocks of 60ms of audio in each frame, made up of three times 20ms of audio. Therefore audio will be lost in multiples of 60ms which is an appreciable gap. So what to do about infilling the audio when a frame is lost?
 
There are  three potential approaches: repeat the last 60ms as-is, or take the last 20ms of audio and repeat that, or simply insert silence. If we follow the D-Star method then the second option would be the way to go and then follow with the silence option if the gap is loner.
 
Recently the local Hytera DMR repeater was relaying a talk group and somewhere along the line, there was some network loss. In order to fill in the lost frames I think it repeated the last 60ms audio a few times and it sounded horrible. I hope I can do better.
 
There are other complications to infilling gaps also. For example a gap is explicit if you have received block 2 and block 4 appears, you know that block 3 is missing and can do something about it. The more complex case is when a complete loss of data happens, which you hope is temporary, and you have to infill for a while. Firstly you can’t simply wait for 60ms (in the case of DMR) and if no frame appears introduce a new one. Experience has shown that sometimes frames are delayed by quite a while, but will eventually appear and in the correct order. Therefore any infilling can’t be too aggressive otherwise you ignore real data, but it can’t be too relaxed as audio will be lost and/or the transmitter will switch off in the case D-Star and System Fusion.
 
What has struck me is that compared to DMR or System Fusion, the D-Star air interface does seem very simple and even under engineered, but working on it for the past seven years has taught me a lot, and that is feeding through into my DMR and System Fusion work. I would not have had the confidence to have considered this project before.

Big pile of parts off the Contract Manufacturer
stay tuned more announcements coming today

Thursday, January 7, 2016

Networks and history

As you know, the MMDVM will support three data protocols, D-Star, DMR and System Fusion. Each is quite different in many ways, but what they do share is the in-built support for networked repeaters. Unlike FM where EchoLink and IRLP were late to the game, relatively speaking, and standalone FM repeaters were and are well established, the digital modes have known little else. This integration is much less clunky than anything on FM, with things like callsign routine (D-Star), reflectors (D-Star and DMR), talkgroups (DMR), and other good stuff.

This has only been possible, for the most part, by the use of open protocols. When I say open, I mean that the details of the protocol have been published and the developers have been available for discussion and in some cases changed things in the face of experience. This is not to say that the infrastructure of the system needs to be open source, the model of a closed open system (or is that open closed system?) works well and I’m not going to get onto my soap box and demand that ircDDB release all of its source code or else. As long as the protocol is open and published, I’m fine with that.

Now to a bit of ancient history. Back in 2009 when I started with D-Star, there was only one network, G2. This was the official Icom system, it offered callsign routing, add-ons added D-Plus and D-PRS. The custodians of G2 were, by the time I got up to speed on these things, somewhat reticent about allowing homebrew systems onto their network. This was mostly caused by the actions of one developer who wrote a very fine clone of G2 but through his testing which verged on the malicious, and toxic personality, managed to alienate all who dealt with him, myself included. The net effect was that the official G2 network was closed to homebrew systems and that was that. It was a reasonably large network, but things were about to change. A group of Germans started up the Open G2 network, using Icom software for the servers, just like the official G2 network but fixed to work properly, and the homebrew G2 clone mentioned above. The reflector system of choice was DExtra rather than D-Plus.

This network grew to be a significant fraction of the size of the official network, with my repeater software being heavily used. Yay!

In 2010 ircDDB was created, to do what G2 did, but much better. As one user said: ircDDB is a Ferrari compared to the G2 horse and cart, or something like that anyway. I was tasked with writing the official gateway software which after many years of development now supports D-Plus, DExtra, DCS, CCS7, D-PRS, D-RATS, localised voice announcements, DTMF control. AMBE regeneration, and other bits and pieces that I have forgotten about! The ircDDB network and the allied QuadNet system now account for many thousands of systems dwarfing the official G2 network which still continues.

I had the pleasure of meeting the official G2 guys and Robin AA4RE of D-Plus fame at Dayton in 2014, and found them to be excellent people. The damage had been done by our toxic developer above and it’s a shame that I wasn’t on the scene earlier, D-Star history may have been different.

 Also at Dayton I got interested in DMR properly and started planning some form of implementation. This would probably have become the MMDVM a year earlier than what actually happened but my private life took an interesting turn, Hi Liana! Radio went onto the back seat as I found domestic bliss

Back to networks. The DMR world feels like a re-run of the G2 debacle. In 2014 I met the DMR-MARC guys at Dayton, there was no other DMR network in existence at the time, and they made it very plain that nothing other than a pure bona-fide Motorola system would ever be allowed onto their network. They were rather aggressive on that point I thought, it didn’t help that the same people then went on to say that they ran my D-Star software and loved it! They didn’t see the irony of what they were saying, history was potentially repeating itself with them as the losers.

The first open closed DMR network was DMR+, the people behind this are the people behind DCS and CCS7 In the D-Star world. Shortly afterwards the BrandMeister network was started up. There is rivalry between the two, and I do not intend to choose one side over the other, I have cordial relations with both. They are both implementing my Homebrew DMR protocol to allow homebrew systems complete access to their networks at the same level as Motorola and Hytera systems. This is a big win for lovers of open systems and I commend both groups for their attitude.

Onto System Fusion. This is the most depressing as well as the one with the most possibilities. The official Wires-X network from Yaesu is very very closed, and I am sure any attempt to build some form of homebrew interface would be rebuffed, this is a shame as we amateurs have shown ourselves to be consistently capable of produce good robust systems more capable than the official offerings.

So let’s write that one off. I see no unofficial network emerging, which means that the System Fusion support in the MMDVM will be RF only initially. Fusion allows a number of audio modes, all mutually incompatible, but gets around this by decoding the audio to PCM before moving it around their network. This is clever in that it gets over the incompatibilities but also defeats one of the great strengths of digital voice system, using digital end-to-end for the best quality audio.

The field is open for an open closed, or even an open open network for System Fusion. I’m all ears, who’s going to be first?

Levels and Deviation

One of the aims of the MMDVM is to ensure that setting it up should be easy. For example set up a repeater and then play traffic through it, set the levels so that the traffic is audible on the desired mode, and the levels for the other modes should also be correct. As specified each data mode has a fixed set of deviations associated with it. Therefore the relationships between each is fixed and that is how it will be in the modem. Getting these levels right is not easy though.
 
For example on my old IC-E92D I can have the D-Star being transmitted with a wide range of deviations and it still receives perfectly. The newer ID-51a are not so lenient, but I don’t have one of those. Last night I heard my first DMR through the MMDVM, it was only for a few seconds, but it was there J However the levels probably were borderline and I wasn’t able to reproduce it, I think that my CS700 has pretty tight filters. I suspect that level setting will become a bit of an issue in the future. I’d imagine a tool using something like an AirSpy or similar could come to the rescue ultimately for setting things up.
 
I’m still at the stage of experimenting with the relative levels within the MMDVM, and I hope that further on-air testing elsewhere will enable the correct relative levels to be set once and for all.
 
So what of the levels. D-Star uses GMSK with a 2.4 kHz overall deviation and that fits into a 12.5 kHz channel very nicely. DMR uses 3.888 kHz overall deviation and still fits into a 12.5 kHz channel, it has to, it’s a commercial standard and must operate within a much tougher regulatory framework than we amateurs. But what of System Fusion? The spec says it has an overall maximum deviation of 5.4 kHz, which does not fit into a 12.5 kHz channel. It may be fine for the American 15 kHz channels but not our bandplans. Putting two closely sited System Fusion repeaters on adjacent 12.5 kHz channels and expecting happiness is not on the cards. There was some talk of banning System Fusion in Germany because of this, but I don’t know what the outcome was. Yaesu said that the deviation couldn’t be reduced. Hmmmm, let’s see.
 
Despite a lot of obfuscation within the specification, the modulation method and constants for System Fusion turn out to be the same as for DMR. Obviously the content of the messages are complexly different, but it’s all C4FSK (C4FM is a Yaesu-ism) which is sent over the air. So if DMR can live within tighter limits then why can’t System Fusion? Only Yaesu can answer that.
 

Tuesday, January 5, 2016

DMR

Unlike D-Star and System Fusion which are relatively straightforward, DMR being a TDMA based system has raised some interesting challenges in its implementation. It is not that the transmitter at the repeater end (hereafter called a BS, that’s DMR spec speak) needs to quickly go from TX to RX and back again in less than one millisecond, that’s the domain of the user radio (MS in DMR spec speak). The BS TX stays on all the time, pumping out data continuously just like the other data modes mentioned.
 
The challenge is more subtle, and it concerns the receiver side of the BS. In fact there are two challenges, but they are related:
 
When the BS TX is off, the MS TX will send wake up messages. Unlike D-Star and System Fusion, all MS TX messages have no bit synchronisation, they just start transmitting their data immediately and embed a nice synchronisation pattern in the middle of their 27.5 millisecond transmission, which is good of them. Therefore the challenge is to find this pattern without much warning, and do so accurately. I had one solution, the problem is it the Due ran too slowly to be usable, oops. My second solution meant that I stored 27.5 ms worth of undecoded data and looked for the synchronisation pattern in the middle of it. I then went back to the beginning of the buffer and decoded all of it. It seems to work too. That is what I call the DMRIdleRX as it’s only used when the BS TX is off and the modem is in the idle mode. This means that it is listening for all data modes simultaneously.
 
Once the transmitter is on, all transmissions from the MSs (two slots, up to two MSs) are going to be contained within a 28.5 ms window, and not all of them will contain any form of synchronisation pattern either. The trick is now one of accurate timing, of the receiver knowing where it is relative to the transmitter and that is the problem. I use queues between the protocol engines (DMR in this case) and the bit that actually puts the data out to the electronics and onto the radios. These queues (implemented as ring buffers) can have more or less data in them depending on the speed of the protocol engine. Hopefully on transmit they don’t run out of data as that would cause the transmitter to go silent, and on receive it’s big enough to handle the delays in later processing. Therefore the synchronisation between what is being transmitted and being received has to established, however it won’t be a simple time delay of so many microseconds, it could be variable.
 
My answer was to have a separate set of queues parallel to the ones mentioned above, that are the same length, and contain synchronisation information. Every time a sample is transmitted, it is taken from its queue and sent out, and a receive sample is read and put into another queue at the same time. My synchronisation queues go through the same process, although the data doesn’t appear to the outside world, so that the synchronisation data has the same delay as the combination of the transmitted and received samples. That way I can establish an accurate timing mark, it doesn’t matter where it is, as long as it is completely consistent. The job of finding the incoming transmission is a simplified version of that used for the DMRIdleRX above, but with a more restricted range. When there is no synchronisation pattern then the timing information is used to work out where the signal is, luckily a frame with synchronisation data is received every six frames so it can’t drift too far.
 
Did you notice a sleight of hand above? I mentioned 27.5 ms and then 28.5 ms. This is because a DMR transmission is 27.5 ms in length, but can be up to one millisecond late before being ignored, giving an overall window of 28.5 ms to receive it. This extra one millisecond is made up of any inaccuracy in the MS, and propagation delay. Assuming the MS is accurate, then it would all be propagation delay, so what does that mean? Radio waves travel at the speed of light in free space, about 300,000 kms/s. That’s 300 kms in one millisecond. This delay affects the transmission from the BS to the MS as well as the MS to the BS, so in order for the one millisecond limit to be reached, the MS can only be 150 kms away from the BS. I am sure most BS implementations allow a bit more than that, but ultimately there is a limit somewhere in the BS. It is for this reason that GSM mobile phones also have a range limit even though the base station is still audible. DX operating via DMR is going to be a limited pastime.