Article: 51254 of rec.radio.amateur.digital.misc From: Bob Bob Subject: Re: Newbie, questions on AX.25, theory, hardware etc. References: <1145754480.504270.195250@i40g2000cwc.googlegroups.com> Message-ID: <9e9rh3-d9k.ln1@p400bob.personal.cox.net> Date: Sat, 22 Apr 2006 22:38:16 -0500 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. Article: 51255 of rec.radio.amateur.digital.misc From: "TOM" References: <1145754480.504270.195250@i40g2000cwc.googlegroups.com> <9e9rh3-d9k.ln1@p400bob.personal.cox.net> <1145831401.326705.315720@e56g2000cwe.googlegroups.com> Subject: Re: Newbie, questions on AX.25, theory, hardware etc. Message-ID: Date: Mon, 24 Apr 2006 02:08:24 GMT 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 news:1145831401.326705.315720@e56g2000cwe.googlegroups.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 > Article: 51256 of rec.radio.amateur.digital.misc From: Bob Bob Subject: Re: Newbie, questions on AX.25, theory, hardware etc. References: <1145754480.504270.195250@i40g2000cwc.googlegroups.com> <9e9rh3-d9k.ln1@p400bob.personal.cox.net> <1145831401.326705.315720@e56g2000cwe.googlegroups.com> Message-ID: Date: Sun, 23 Apr 2006 22:00:43 -0500 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! > Article: 51257 of rec.radio.amateur.digital.misc From: larson@w6yx.stanford.edu (Alan Larson) Subject: Re: Newbie, questions on AX.25, theory, hardware etc. Date: Tue, 25 Apr 2006 03:38:17 +0000 (UTC) Message-ID: References: <1145754480.504270.195250@i40g2000cwc.googlegroups.com> In article <1145754480.504270.195250@i40g2000cwc.googlegroups.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