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.

Monday, January 4, 2016

MMDVM Junior

Before I started the MMDVM, I envisaged a project where I had a small-ish box which given a few button pushes, could receive FM, D-Star, DMR, and System Fusion. This would be used in the car while commuting to work and would enable me to listen to all of the repeaters along the route. The callsigns, modes and frequencies would be in a config file, and the buttons would simply cycle through them until I found some activity. I suppose some form of scanning could have been added later.
 
This project morphed into the MMDVM.
 
My original idea was to use a Funcube Dongle Pro, a Raspberry Pi, a DV3000 AMBE board on the Pi, and a simple display also attached to the Pi.
 
Now that I have more experience with the MMDVM and the protocols in question, I am looking at revisiting this project. Instead of the Funcube Dongle I’d now use an AirSpy, but otherwise not much would change. Indeed it could even be used to validate my MMDVM output. I think D-Star and DMR would be simple to get working quickly, System Fusion less so. As far as I know, no one has managed to work out the mapping of the Fusion audio into the format needed for the AMBE3000R chip for all voice modes. I’m sure it will be done soon. For the full MMDVM I only need the details of the FEC for regeneration, but for this project I need to know more.
 
Don’t hold your breath on this. It is just an idea for now, and most of my effort is on the MMDVM.

Supported Hardware

Currently the MMDVM only runs on the Arduino Due. This is an ARM Cortex-M3 processor from Atmel which is clocked at 80 MHz. It has two ADCs and two DACs although only one is used for the MMDVM. It is a well supported platform and the only one I was aware of when I started, this was due to an interesting article in the RSGB’s RadCom about using a Due with a TFT display as a means of visualising the output of a receiver using an FFT. While the code and hardware behind this project was not of interest, the fact that it had enough processing power to perform this task was. A blog entry from M0XPD showed a Due acting as a high performance audio filter, yet again none of the code or hardware was copied, but the idea proved that the built-in hardware could do a suitable job of processing audio with a little amount of analogue electronics.
 
The electronics consists of a few op-amps for low pass filtering and a few switches for controlling the transmitter and LEDs. Or basic testing a couple of resistors and capacitors can be used, but putting such a system actually on-air would be unwise due to unwanted output frequencies particularly from the DAC (the sample rate of 24 kHz could be troublesome).
 
Since the Due development started, I was made aware of the Teensy 3.1/3.2 and later some of the STM32 series of devices. These mostly use ARM Cortex-M4 devices with various peripherals. The Teensy clocks at 72 MHz and the fastest STM32 is 188 MHz! The Teensy is cheaper than the Due, but its USP is its size, it is very small indeed. Wouldn’t it be cool to have a repeater that can fit into the palm of your hand easily barring the RF bits? The STM32s are very very cheap but seem to lack a decent USB serial hardware interface available to any running program. The Teensy can be developed using the same Arduino GUI as the Due while the STM32 can either be developed using MBED with a plethora of GUIs, or with STM32Duino. I am not looking at these platforms explicitly as I am busy with the actual data protocols, but others are. I await their results with interest.

Saturday, January 2, 2016

My first blog posting

Hi Folks

This is my first blog posting for the MMDVM. I'll add more posts later this week outlining various ideas and changes to the code/project as time permits. I'd like to remind people that the primary location for getting information for the MMDVM remains the MMDVM Yahoo! group.

73

Jonathan  G4KLX