TMS320C6713-DSP Based FSK Modem with Timing, Frequency

TMS320C6713-DSP Based FSK Modem with
Timing, Frequency, and Phase Synchronisation
Kandeepan Sithamparanathan
Leif W. Hanlen
Wireless Signal Processing Program
National ICT Australia
Wireless Signal Processing Program
National ICT Australia
Abstract— In this paper we present a Texas Instruments
TMS320C6713- DSP based communication testbed, designed
for testing algorithms, channel measurements and performance
analysis of digital receivers. The testbed is used to implement
a frequency shift keying (FSK) modem with synchronisation
capabilities at the base band. The modem operates at a data
rate of 600bps with a sampling frequency of 48 KHz. Here, we
present the design and architecture of the modem, and some
results obtained using Matlab.
Manual
Input
Control
panel
Text input
Characters to
binary
timer
timer
Forward Error
Correction
Frame data
Disk
I. I NTRODUCTION
The Texas Instruments TMS320— series DSP platforms
are well known in terms of fast prototyping and use through
academia and industry. In this paper we outline a particular
application of the TMS320C6713-DSP platform for use as
an acoustic FSK modem. The modem is designed as an
introductory tool and teaching aid, for undergraduate and
postgraduate students. The students are introduced to the DSP
through a simple collection of matlab scripts, which permit
pseudo-realtime transmission and reception of signals through
an acoustic medium. Application of daughter boards will
allow direct application of the DSP to cm-wave (2GHz) radio
frequency applications.
For the purpose of this paper we outline the implementation
of a simple binary frequency-shift-key acoustic modem. The
modem operates at a sampling frequency of 48kHz, and has
carrier frequencies of 4kHz and 8kHz. The BFSK modem uses
Matlab to perform base-band processing and the DSP to act
as a software-define modulator.
Matlab Transmit System
Binary
data on
disk
DSP
DSP
sampled
data
Matlab Receive System
Correlator
Decoder
Display
timer
timer
Fig. 1. Matlab interface. Processes are riven by timer objects, which are
controlled centrally through a graphical user interface. Processes controlled
by timers do not require
II. M ATLAB I MPLEMENTATION
The intention of the Matlabtm interface of the testbed is
to encourage fast implementation of the communication tools
onto the DSP platform. We have deliberately avoided “add-on”
software such as simulink, Matlab toolboxes and the DSP’s
own Matlab interface for the following two reasons:
1) They are not universally available, particularly for students using edcuation versions of Matlab software.
2) The simulink-style boxes tend to limit the functionality
of the DSP platform to a well-developed subset of DSP
uses.
While choosing to not use the complete gammit of toolboxes
etc, may seem to limit the applicability of the tools, it is our
hope that we may more easily find a balance between ease of
use, and realistic flexibility in terms of testbed implementations.
The Matlab interface is described in figure 1. The modem
comprises basic aspects of common communication systems
– character to binary conversion, buffering (achieved on disk)
some minor forward error correction and correlation decoding.
The objective of the modem is not to provide a novel FSK system, but through its simplicity facilitate further development
by students.
At its core, Matlabtm is a script-based language. Although
newer instantiations, such as the real-time toolbox provide
some process-based applications, the majority of code written in Matlabtm is linear. The initial process model for the
matlab modem was to use while(true)...end language
constructions, however these were replaced with timer objects.
The Matlab timer object is defined as a standard inclusion
in Matlab 5 and above, and allows functions to be activated
outside the normal linear operation of a matlab script. With
sufficiently small (low complexity) functions, and timer periods of 0.1–0.5 seconds, the modem appears to run in real
time. The advantages of the timer-based over the continuous
while(true)...end loops are two-fold: the processes can
be arbitrarily timed – faster or slower – and may be run
asynchronously. The asynchronous component of the timer,
allows to user to stop and start the simulation easily from a
main control window.
A. Transmitter
The transmit side of the modem uses a simple bitstream,
saved in a text file for the DSP o read. The file is controlled
through a semaphore [1] based system. The current arrangement requires both the DSP and the Matlab code to open a
locking file which contains a single text character which may
be in one of two states – read and write – which prevents
over-writing of data.
The bit stream is re-generated through the use of a small
Matlab function which is called through the use of a timer
object. The file is then read by the DSP code, which creates
a BFSK sequence of samples.
B. Packet structure
The modem has no feed-back channel – so repeat requests
are not possible. The data frames are designed to be robust
against erasure.
The modem uses a series of frames, with a fixed number of
bits. We have used 17 bits per frame, described as follows:
header
z
p0
|
p1
}|
{
p2 p3 f0 f1 d0
{z
} | {z } |
parity
frame num
d1
...
{z
data
d9
}
C. Receiver
The receiver side of the Matlab code consists of three timer
controlled processes:
•
•
•
detect The detector uses a correlator (matched filter)
system to match the received FSK samples to known
frequency sinusoids. This provides soft data outputs,
which are given to the decoder.
decode The current decoder uses a simple nearest
neighbour threshold test to determine the bit value. The
structure of the matlab system is designed to allow
arbitrry decoders to be “plugged in” and replace the
threshold test.
display The display function provides simple output
for the data, including a constellation diagram, real-time
detector output along with bit error results.
Fig. 2.
Awesome photo
ACKNOWLEDGEMENT
National ICT Australia is funded through the Australian
Government’s Backing Australia’s Ability initiative, in part
through the Australian Research Council. L. Hanlen has adjunct status with the Australian National University.
R EFERENCES
[1] W. H. Stallings, Operating Systems, 4th ed.
Jersey 07458: Prentice-Hall, 2001.
Upper Saddle River, New