D-STAR on the Raspberry Pi: the PiGMSK Board
Although there is nothing that would keep you from connecting your Mini-Hotspot board
to your Raspberry Pi (RPi) mini computer through its USB ports, this
does mean extra cabling and clutter.
Many people started to wonder if it would be possible to "do something"
with the so-called GPIO connector on the system, which is
intended for user experimentation with all kinds of I/O devices and the
The GPIO connector (which is the big pin-head connector on the RPi's
lower right hand corner, next to the yellow video connector) carries a
number of signals which interact directly with the RPi's ARM processor.
As shown on the left, we find a power supply (both 5V as well as 3.3V),
general I/O pins (for connecting LEDs, switches and so on), a standard
serial port (the "serial console" used by Linux, but Linux can be told
not to use the port itself, freeing it for other use, such as connecting
a GPS device for example) plus to complete serial buses: I2C and SPI.
All in all, that's quite a bit of I/O to play with, so maybe there is a
way to use this for our D-STAR project, indeed!
A board designed for connecting it directly to the Raspberry Pi
should obviously follow a number of guidelines to make it work. Some of
fit neatly on top of the RPi itself, using the
GPIO connector and the two available screw-holes for support.
Ideally, the boards should have the exact same size.
follow the RPi's power usage, which means running
everything at 3.3V, provided by the board's own on-board regulator,
which in turn draws from the RPi's 5V system. This avoids
overloading the RPi's 3.3V power system.
where needed, take care in avoiding as much
interference as possible
Since we have three very usable I/O buses (serial port, I2C port and SPI
port) and also a handful of general-use I/O pins, we should design in a
such a way that either our board uses up all of the available resources,
or we implement stacking, where multiple of our boards can be mounted on
top of eachother, or, in some cases, where some other board is mounted
on top of our board. This obviously means watching component sizes and
Since we already have a "known to work" board design (the well-known
Mini-Hotspot board, revision C, also known as the "Blue Board"), we use
that as the basis for a new one, specifically for the RPi....
and here it is!
Code-named PiGMSK for now, this is a 3D rendering of the board as
it is now under testing in real life.
Fitting exactly on top of an RPi system, it uses the GPIO connector for
both power and support. Two holes for additional mounting support are
present to ensure a robust pairing with the system. The board is
available in two variants: one with a regular GPIO connector mounted
(as shown), and one where the GPIO connector is a stacking connector,
so, a socket at the bottom side of the board, and pins at the top side,
so another board can be mounted on top.
Though a small board by looks, supported features are quite impressive:
basic design from Mini-Hotspot Rev.C,
updated for direct-connect to RPi and several other design changes
that make the board more into its time.
stackable I/O expansion board for
Raspberry Pi, using its GPIO connector for both I/O as well as
power. An onboard 3.3V regulator is used.
serial port (using 3.5mm stereo jack)
which can be configured for either TTL or RS232 levels, connecting
to the RPi's serial port for use a serial console, for connecting a
GPS device, or....
DC switching power supply to allow the
entire stack to be powered from a single DC supply (6 .. 27V)
through the standard 2.1mm DC jack, or the PWR pin on the DB9 radio
connector. You can use the radio's 12V supply to power everything,
and no extra cabling needed!
extra LEDs on board which can be driven by
the RPi-based software
support for mounting a micro RF transceiver
board (various designs) to create a very small but full-featured
node without the extra cables!
The board uses the SPI bus to communicate with the RPi system. A
jumper selects between the system's CE0 and CE1 select lines, so you
could stack two of these boards onto a single RPi system, each using one
of the available selects.
the software side, this board obviously uses a (very) different method
to communicate with the host (the RPi) system. The details of that,
however, have been hidden in the API implementation (the shared library,
"libnode-armv6l.so") so programs can continue to use that API, for both
the USB version of the board as well as this new SPI version of the
In other words, the API has not changed with this board, other than some
extra smartness that deals with how to select the proper interface (USB
or SPI) and the details of that connection (USB ID, SPI slave device
number and so on.)
Watch this page for updates as we get ready for its release !