Hi Matt

One of my favourite topics, not necessarily as an expert though!

One of the big killers for any radio circuit is what to do when the data
doesnt get through. Pretty well all commercial systems employ forward
error correction in the outgoing signal. How much FEC is used depends on
how bad the circuit *can* get. AX25 handles the issue by doing a full
packet retransmit and the HDX action and paclen can kill throughput
pretty badly if it has to happen a lot. There have been a plethora of
(amateur) modes more recently than packet that employ FEC at the
transmitted level.

Assuming you dont need to run IP I guess the best code for multicast
might be the Wyman/RDFT stuff that runs under such pgms as Digtrx. (A
SSTV pgm that says the RDFT stuff is a "digital mode") In it simplest
form you encode a binary file into a sound/wav output, add some (start
tone) headers and the transmit away. One of the command line arguments
to encoding is the amount of FEC added to the output. The receive end
decodes the wav file back to the binary file. The interface is a pretty
simple DOS or Linux CLI function that you can add your own code to.
There is of course a bit more to it that I will elaborate on if you are
interested. OBTW the data rate on a 2.4khz SSB channel is between about
300 and 900 bits per second depending on FEC selected. It can also
repeat missed blocks if you setup a kind of handshaking. I have
personally played with the code to get a better rate on a 2m FM channel.
The test I ran had 1.5x the rate working without probs.

The main RDFT/Wyman site is;
http://www.svs.net/wyman/examples/hdsstv/index.html
and some more info at;
http://www.tima.com/~djones/rdft.htm

As I said it isnt meant for UDP/IP

If you have to send UDP/IP packets have a look at the soundmodem/flexnet
system (Windows and Linux). You can use the RDFT code in that as well
(They call it newpsk). I dont have the URL handy sorry.

You can also of course get stuck into the GPL s/w for the slower
keyboarding style modes like PSK,MT63 etc. Such techniqes as simple FEC
and data interleaving might work for you. I personally want to play with
some very narrow bandwidth stuff on 2m (like 50Hz) to a mobile and will
probably look at modifying something already available. (The challenge
here will be allowing for the phase noise and Doppler...) if you want to
look at source code you might like to review gMFSK at;

http://gmfsk.connect.fi/index.html

It is written for Linux but I am sure you'll be able to find the useful
parts. Likewise this isnt meant for UDP/IP.

Both of the above are meant for PC sound card interfacing


But back to your original questions!

The first kind of packet data modes were FSK (frequency shift keying).
The more recent ones tend to be PSK (phase shift keying). The RDFT stuff
for example is 8 PSK carriers in the "normal" voice bandwidth.

If you use regular AFSK packet to a receive only system it cant correct
errors by retransmission as it wont know to do so. You need FEC in
whatever you send.

PPP gets upset if you use half duplex. A lot of IPCP etc pckets also fly
down/back the link and are part of the "is it still working can you hear
me?" system. You would also get into a huge mess if the headers were
damaged in transit. You can FEC the payload easily but not the headers.
I guess you could encapsulate it in a RDFT style FEC stream but why
bother if the s/w is already around the sticks IP inside of it. I have
heard that SLIP is a good alternative to this so you might just get away
with applying your RS232 port to a modem, thence to the radio. The lack
of FEC would still kill you though. There maybe code that exists to do
this but I havent checked.

You can think of a radio data stream as having a fixed rate that sends
in synchronous bursts. There always has to be a buffer between the
sender and radio/modem. There tends to be an agreed standard like the
original AX25 rates of 300 and 1200 bits per seconds. RDFT also has a
fixed rate but the soundmodem drivers allow you to set a number anywhere
you like between two limits. The tones/shift (in the case of FSK) and
phase shift (PSK) are also agreed upon.

Hope this hasnt confused too much and is useful to you.

Does your app really need IP transmissions? That can be a real bear if
you dont turn off all the other stuff that flies out the port (like
ARPing etc) What platform are you writing for?

Cheers Bob W5/VK2YQA East Texas.

Reply address is valid.

psyshrike wrote:

Howdy!

I've touched wireless systems before but not enough to be dangerous. My
background is in software and IPv4.