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 !