Howdy!

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

I have an applicaction in mind for wireless transmission. It would be
very narrow band and low bit rate (obviously), multicast transmission.
The client side is reciever only.

In this case AX.25 is overkill, as none of the collision management is
required. As I understand it, what I need is modem, a radio, and a OSI
Layer 2 frame type suitable for wireless transmission. Would PPP or
HDLC work as a frame type? Is there something better suited to
narrowband wireless?

I don't really understand the actual signal modulation too well. If I
said I wanted to span a particular frequency range, doesn't that
frequency dictate the amount of asynchronous bits than can be modulated
into it? So the modem would have to be tunable right? It would have to
modulate specific to the spectrum in use. So I'm taking it there is a
standard, or do the modems you guys use have a knob to control the
modulation rate? Say the modem buffers 300 bps on the RS232 port but
only has the spectrum to transmit say 200 bps through the radio? Or am
I running into "why the hell would you do that?" territory?

So what the minimum hardware/software required to drop one ip datagram
onto a wire and get it transmitted in say a 10Khz wide band?

-Matt

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!

In article .com writes:

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

I have an applicaction in mind for wireless transmission. It would be
very narrow band and low bit rate (obviously), multicast transmission.
The client side is reciever only.

In this case AX.25 is overkill, as none of the collision management is
required. As I understand it, what I need is modem, a radio, and a OSI
Layer 2 frame type suitable for wireless transmission. Would PPP or
HDLC work as a frame type? Is there something better suited to
narrowband wireless?

I don't really understand the actual signal modulation too well. If I
said I wanted to span a particular frequency range, doesn't that
frequency dictate the amount of asynchronous bits than can be modulated
into it? So the modem would have to be tunable right? It would have to
modulate specific to the spectrum in use. So I'm taking it there is a
standard, or do the modems you guys use have a knob to control the
modulation rate? Say the modem buffers 300 bps on the RS232 port but
only has the spectrum to transmit say 200 bps through the radio? Or am
I running into "why the hell would you do that?" territory?

So what the minimum hardware/software required to drop one ip datagram
onto a wire and get it transmitted in say a 10Khz wide band?

Several things come to mind.

1. Does it have to be an IP datagram? Does it need error detection?
Error correction? Maximum/minimum size?

2. What sort of data rate can you deal with? Is one bit per second
fast enough? Do you need 10 megabits/second?

3. What sort of coverage do you need? What signal to noise ratio
can you expect? Given the bandwidth you gave, one expects sort
of slow, but...

4. How does it compare to cellular transmissions?

5. How about ATSC (much bigger bandwidth and data rates, but you could
have a bunch of separate PIDs for the different info.)

You need to address several levels of the communications model -- from the
basic modulation, to framing of packets or data, to meaning of the content.

You need to learn more about data communications. There are some good books
out there. Unfortunately, if you want to develop something commercial and
not tell people what you are doing on usenet (a good idea, that), you will
have to learn a bunch, or pay someone who knows a lot about it.

Alan

Howdy,

I'm interested in low level portability. The end-user portion the
transmission standard is expected to be implimented in chips. But the
the data-originator should optimize existing infrastructure. From that
standpoint:

Browser-net-WebServer-Database-net-proxy-radio-wireless-client.


The segment between the database and the proxy really wants to be able
to use IP as a network layer. If I was looking for a one-off solution I
could cronjob an RCP. I would rather have a protocol instead because I
want intercompatability between implimentations.

As a transmission standard I am thinking more layer 2 and up. Bandwidth
usage should scale with the layer 1 medium. I don't need much
band-'width' but would happily encode the bits on whatever frequency is
most appropriate. 56Kbps would be nice but I could probably get away
with 4.8Kbps

The actual frequency range I settled on will be dependent primarily on
associated hardware costs. (on the client side, not the publisher side)
I am guessing the L-band might be servicable considering there are
already buku recievers units built for consumer GPS. Feel free to
enlighten me if I'm totally off the mark there.

This service doesn't compare to GSM or equivilant. The protocol should
not disclude terrestrial transmission, though sattelilte would be
prefered due to fact that the customer base is global, potentially
rural in many cases, and generally atypical of the GSM customer. I do
have unique identifiers (for the data, as well as a client-id) that
must be transmitted. These unique bits are expected to be read by a
chip on the client side.

I am guessing that one of the issues here is that FEC seems to
intigrate layer 4 and layer 1 of the OSI model into a single service.
So wireless transmission and terrestrial transmission are a bit
backwards. On copper, bits are reliable so error correction is mostly
just CRCs. Dropping a frame is rare. With wireless the frequentness of
dropped frames makes heavy error correction and transport control part
of layer one. This makes following the OSI model from a development
standpoint at least a little redundant past layer 1? Am I seeing that
part of the issue clearly?

Thanks for the Ref to the ATSC, that will probably clear up a lot of my
questions. You are correct, I do need to learn more about wireless
communications. That is why I posted here. :-)

I'm guess what I'm looking at is writing a presentation layer protocol,
encapping it in UDP, the proxy then strips the UDP header and reencaps
my protocol into some form of ATSC protocol, which is then dumped into
a modem buffer. Whalla, IP to end user.

(if only it was that easy)

-Matt