DM-1 GMSK Smart Modem

Since all D-STAR activity requires the presence of a modem handling the GMSK modulation of the data into the radio transceiver, the function of the DM-1 is indeed a very important one.

Its very first incarnation was based on ideas found on websites of several people (see the Links page) but it was quickly decided that creating a single PCB for both the modem-side as well as the application side would be undesirable, and thus the two parts of the design were separated, and the DM-1 was born:

The various parts of the modem can be clearly seen here.. the connector to the radio (using the more or less standard RigExpert pinout), the analog front-end built around an RC4558 op-amp, the CMX589AP4 GMSK modem chip from CML, and the local AVR ATmega CPU for handling the bit-counting.

Interconnection to the main CPU board is through the dual-row pin headers on the side of the board.. power, control signals, RS232 I/O, I2C, all those are present there. This setup also allowed for the design of a higher-power CPU card later on, based on the LPC-2138 ARM from NXP (formerly Philips), as we kept the pin headers the same in function.

However, about a week before the project's official announcement and presentation at the Dutch Annual HAM Radio Show (Dutch: "Dag van de Radio Amateur") on October 25th of 2008, testing the modem on another transceiver (the Kenwood TM-V7) showed that this would never work... a major show-stopper!

For the presentation, I switched back to the transceiver I knew was working with it (an Icom IC-2800H), and started thinking about how to solve the problem that stuck out its ugly head.  Not all transceivers are the same, and it turned out that there was no standard as far as the signal levels on the "data" connectors was concerned.. both at the AC and DC levels.  The GMSK chip wants about 0.9V AC (audio) on top of a 2.5V DC bias, and this was hard to achieve on some transceivers, and impossible on others...

Anyway, after the presentation some tests were done to check that the problems were indeed related to the signal levels on the radio side, and those tests confirmed the suspicion... both AC as well as DC levels on the radio port had to match those needed by the modem, or else things simply would not work.

Several of the simple solutions were tested (most of them aimed at isolating the radio side from the modem side, thus avoiding the clash of signal levels), and it was eventually decided that the best solution would be as was stated in the chip's datasheet, where it is stated that the modem is best connected to the radio using DC coupling, using the proper level-adjusting circuitry.

Now... although Digital Engineering is not a real problem here, doing anything scary such as analog is a whole different story.... it's not my field, and whoa, how to solve this (obviously analog) problem?  I was lucky enough to have a friend who is fluent in analog things, so... enter the analog people.

The solution that was created basically did a three-step level adjustment on the RX path (DC-down, AC-gain, DC-up), and a one-step adjustment on the TX path, using a single quad-port chip and, of course, the usual suspects such as capacitors and resistors. The end result can be seen in the picture below.

The basic setup is still the same, and the new analog front-end can be clearly seen in the upper side of the PCB, just below the radio connector.  The four potmeters are for setting the DC correction value, and the AC gain, on both TX (left) and RX (right) paths.

This is the board that is still present in the DT-1 prototype, and it works really well, so the analog engineer was right in his decision to stay with DC coupling. Several minor problems were soon fixed, and then it was time to go and fix the software (again)

From a software design perspective, the modem is simply a slave device on a communications bus, and the controlling system (usually the master on that bus) is responsible for setting up and initializing the modem for use in any mode of operation.

In this case, two such buses were used, being a standard serial port interface (through the interconnect into the CPU card), as well as an I2C interface to the host processor. On the I2C bus, the modem is simply an addressable slave, and the master can configure it by reading values from and writing values to its configuration registers.  After the initialization phase, the modem will simply raise an interrupt to the host if something interesting happened (such as received data), at which point the master will then use the usual method of accessing registers to handle the situation.

The serial port interface is similar, but also very different. Serial ports are very good for debugging as well, so I wanted to be able to use it as a bus (similar to the I2C interface), as well as a debugging port using a CLI, and this without the need for re-compiling code.

Connecting a terminal emulation program to the serial port would show output like the following:

DUTCH*Star DM-1 GMSK Modem V1.1.18SA (Rev C)
Copyright 2008,2009 MicroWalt Corporation

Initializing TWI Master.. OK.
Board revision #02
Initializing CMX589A..

which looks like any other serial device, right?

This de default mode, where the modem will output debug information when needed, but input is restricted to commands according to its Framed-Mode Command interface- this is nothing more than the I2C-based register system, embedded into the serial data stream in the form of command/reply packets, which are then enclosed in framing headers (and a CRC) to make sure that they are received in good order.

To enter the debug CLI mode, we just type three consequtive @-characters within half a second. This will open up the CLI as shown below:

ENTERING CLI

:

and hereafter, the modem runs in CLI mode, where a variety of commands can be entered to configure, test and/or use the modem. The two most important commands to remember would be Q, to exit the CLI and go back to command mode, and U, which starts the Firmware Update mode.

Firmware updates?

Yes. It was expected that the firmware would be improved over time, so an easy method of updating the modem's firmware was added to the design specification in an early phase. The microprocessor used (an AVR ATmega from Atmel) runs with a Boot Loader, which always starts up first when the system is powered on, and the Boot Loader can then decide (or, be told, through the U command in CLI mode) that it must download a new firmware image from the user, using the X-Modem protocol, which is readily available in most terminal emulation programs.

With all this progress in place, it was almost getting time to start thinking about how the standalone version of the modem should be implemented. Obviously, the basics would be the same as the one shown above (known as the embedded variant of the modem), but some things would have to be given some extra thought:

For example, the analog front-end depends heavily on the stability of the DC power supply, and with USB, the supply voltage is far from stable. Also, the DC correction voltage for the radio interface might need more than 5 volts, so some method of changing voltages was also required In addition to providing it as a negative voltage, by the way.)

The USB connection was designed around FTDI's FT232RL chip (a fairly new all-on-chip USB serial port controller), and that had the advantage that there was also a PowerUp signal available, so if the PC wishes, it can shut the modem completely.

In the end, a new power supply system was designed, which first switches the USB power source (which van vary between 4.2 and 5.0V) to a stable 10.0V.  This is then switched back to 5.0V for powering the modem itself, and also to a stable -10.0V for use as a DC correction voltage for the radio interface. In the picture above, the USB chip can be seen to the left of the USB connector, and the power supply components can be seen in the section above it.

As a test, circuitry was added to get rid of the manual adjusting to the radio voltages, by adding two electronically-driven potmeters (the two chips in the lower-right corner), and some chips which would connect an analog input port of the processor to one of the voltages to be measured.  Sadly, this didn't work as planned (the potmeter chips could not handle the negative correction voltages, amongst other things) so for now, this plan was dropped. In the prototype unit, the potmeter chips have been replaced with regular potmeters in a rather funny way. It works, though!

To allow for later addition of speed-selection logic (the GMSK modem chip can handle more speeds, but it has to be programmed for that, and some external components must be changed for that), the board layout was cleaned up (a lot, even) and now approaches final state. The only really important difference is that the radio connector was changed (again) from a 6-ppin MiniDIN connector, to a standard 9-pin D-SUB connector, as this is easier to deal with by most people.

In the new design, the space in the lower left corner is reserved for the upcoming Speed Select feature.

What remains now, is testing of the firmware, and that is happening at rapid pace. The first live QSO's have already been logged, and the modem seems to have no problem with RX or TX to the local repeater, nor to the locally available D-STAR equipment.

What can not yet be tested is the audio capability- even though the CODEC connector is present on the PCB, and the design of that board is already done, the absence of AMBE chips currently does not allow me to test this feature. Instead, the PC-based supporting software was used for the QSO, where the audio conversion was handled by a DV Dongle connected to the PC's other USB port.

Although not really intended to be the final setup, it did work fine, and it did result in some interesting features in the support software, such as a DV-to-WAV (and back) audio converter, much in the spirit of the 'every downside has its upside' saying, by a famous Dutch soccer player. :-)

Pictures of the prototype setup are below. Click on a picture to see a (much larger) version in a new window or tab.

The modem itself, actively receiving, with the DV Dongle on top of it handling the audio conversion. Both are connected to an USB hub, and then to the PC.

Do we have any volunteers for designing a front panel? :)

 

 

 

 

Here is a top shot of the modem, without its cover.  The kludge with the replacement-potmeters can be clearly seen, and also several patches to the board to fix issues or to change a feature.

 

And lastly, a picture of the complete test setup:

The PC is running the support software, which controls the modem itself, and the DV Dongle (for audio support, see above). It also runs client program, which connects to the modem software (using a (local) network connection), and which acts as the user-side of the system.. it implements the usual functions such as callsign setup and selection, RX/TX switching ("PTT"), audio support to the PC sound card, and, in this case, it also talks to the transceiver (seen in the far left) to set its frequency and such- the program is a special version of the program mentioned here.

For real-world testing, the ICOM IC-92 HT is present, as well as an IC-2820 (not seen in picture), and of course the local D-STAR repeater.

 

Updates will be posted here as they happen, so watch this space for more !

 

Main Page   Products Page   Previous Product   Next Product

E-mail our Webmaster | Copyright © 2008-2015 DUTCH*Star | Last change: 07/01/15