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.

Awesome information!

What I am working on is really the development of a transmission
standard for some data that has some fairly specific requirements. It
is multuser to multiuser, with the server side being internet based and
the client side being simplex wireless. The setup is probably similar
in practice to how pagers are used now, except that there is a custom
presentation layer. Each client recieves more data than does a pager,
but the number of unique clients is far less, say less than 256
different client identities, with potentially thousands of replications
of each identity.

A proxy is at the center of the whole thing sort of like this:

WebBrowser-Internet-WebServer-Database-PresentationLayerConversion-Internet-Proxy-Radio-Wireless-Client

Multiuser write, multiuser read, where the proxy is a basically a
packet stripper. The reciever side does need to be able to
differentiate between different destinations like a pager. So it made
sense to me to just just use IP multicast addresses as wireless client
addresses, and then the proxies could recieve on the same multicast
addresses, manipulate the packet, and bridge it straight onto the
serial interface. Basically I could IP/multicast internationally over
the Internet, and then sprout wireless nodes from regional base
stations without having to do any address conversion.

So the radio/modem buffers the bits, and for a fully variable spectrum
selection I should look at RDFT. Linux would be the obvious choice for
development because of the amount of available driver code.

Tons of great information! I will study it and get back to you!

-Matt

There was a multicast (server to multiuser) protocol developed a few years
ago by John Hansen.

"HamWeb: Rethinking Packet Radio", John Hansen, WA0PTV,
SUNY Fredonia, Proceedings of the 16th ARRL/TAPR Digital
Communications Conference (Baltimore, 1997) pg. 41-47.

He distributed the software on the TAPR website.

-- Tom





"psyshrike" wrote in message
oups.com...
Awesome information!

What I am working on is really the development of a transmission
standard for some data that has some fairly specific requirements. It
is multuser to multiuser, with the server side being internet based and
the client side being simplex wireless. The setup is probably similar
in practice to how pagers are used now, except that there is a custom
presentation layer. Each client recieves more data than does a pager,
but the number of unique clients is far less, say less than 256
different client identities, with potentially thousands of replications
of each identity.

A proxy is at the center of the whole thing sort of like this:

WebBrowser-Internet-WebServer-Database-PresentationLayerConversion-Internet-Proxy-Radio-Wireless-Client

Multiuser write, multiuser read, where the proxy is a basically a
packet stripper. The reciever side does need to be able to
differentiate between different destinations like a pager. So it made
sense to me to just just use IP multicast addresses as wireless client
addresses, and then the proxies could recieve on the same multicast
addresses, manipulate the packet, and bridge it straight onto the
serial interface. Basically I could IP/multicast internationally over
the Internet, and then sprout wireless nodes from regional base
stations without having to do any address conversion.

So the radio/modem buffers the bits, and for a fully variable spectrum
selection I should look at RDFT. Linux would be the obvious choice for
development because of the amount of available driver code.

Tons of great information! I will study it and get back to you!

-Matt

Okay so IP multicast it is? Keep in mind that most public (Internet)
routers deliberately block multicast so you'll probably need to
encapsulate it in something first like and IP-IP tunnel to each of your
transmitter sites.

What is even stranger is that I was involved in a VHF pager project that
needed simultaneous broadcast around an entire state via a low bw
satellite delivery system. I think they also ended up using multicast.

If you want to stay away from multicast, I would suspect that if you
stuck with TCP in the internet portion, then wrote a simple inetd
handler (at the proxy where the transmitter was) to process the data
stream, that would be simplests. Your handler could then so whatever it
likes with data, making it RDFT, save to file and spawn some other
process or whatever. This is the same basic method by which terminal
servers work, encoding something like an RS232 stream inside a TCP
transport then extracting it back to RS232 at the other end again.

It may even be worthwhile setting up a SSH linke to each of your TX
sites, then passing whatever you like over the connection. Good for
security.

Enough waffle from me!

Cheers Bob

psyshrike wrote:

Awesome information!