FEC may be applied by the modem, a layer 1 device. Layer one actually encompasses many sublayers, as are channel coding, modulation and radio channel frequency.
AX.25 does not specify the modem. That is a pretty common confusion (I also suffered it as a beginner), because it may not be too intuitive to separate layers of the OSI model when we speak about "packet". Of course, it may have different sublayers within a single layer too. Layers are abstractions that help define models. AX.25 just rules the way layer 2 forms frames and how the upper layers shall be handled. The decision about packet modulation was made because 300 baud modems were easily available second hand in 1982. AX.25 is based on X.25, a working professional protocol, conceived for wired networks, and which does not specify a modem. The choice of such a modem is abominable nowadays under the light of the advances made in more than a quarter of a century. FCC set the requirements for AX.25, specially regarding identification when packet radio was accepted in the USA and it became a worldwide de facto standard, as many others. The VADCG protocol was not accepted innthe USA because it did not identify callsigns, even when it was used succesfuklly in Canada. But actually, any other protocol may be suitable for data transfer, as when wired networks began using Frame Relay, that does not impose any link reliability features, and rather leaves that to TCPIP or any other higher level protocol that uses the link. But, is actually such a change really necessary? And obtaning conformity from the FCC and other national telecommunications administtrations around the world for the new protocol? I read the AX.25 v2.2 draft many years ago, and so far, it has not been adopted. Is it really necessary after all? I really do not understand Graham's proposal: a narrow band spread spectrum system? I really need some more clarification about this. My experience with Chip64 has been awful, and in general, too short symbol time is only useful under the absence of multipath. I agree with Patrick in many points. An acceptable FEC rate for traffic is no less than 1/2, the same as SCS does. Memory ARQ is time proven. I have no experience with Throb, but it is true that you must backoff a lot with OFDM, usually no less than 6 dB, and up to 18 dB with 6200 carriers. At the end, it also requires a large transmitter with lots of headroom. Compression due to non linearity generates errors right at the transmitter, and MFSK is certainly not sensitive to amplitude compression due to non linearity. Training sequences are not only used by 110A, ATSC does use it too, and I believe that the edge that RFSM provides is also due to the use of training sequences for channel estimation and adaptive equalization. Military modems also use it. In the chinese DMBT digital TV standard it is left as an option to the decoder designer. About convolutional coding, my PTC-II uses it successfully, of course, it has a dedicated processor, a very different situation from a PC running Windows. Constraint length may be 7 or 9. Sharing the channel, or not, has pros and cons for each situation. There is space under the sun for both. Today, I was reviewing an old article written by James Miller, G3RUH, "SHANNON, CODING AND THE RADIO AMATEUR", which I downloaded from the AMSAT-NA site http://www.amsat.org/amsat/articles/g3ruh/105.html some time ago, which is pretty illustrative about coding. It might also be interesting to visit the AE4TM site to get familiar with the SCS boxes and pactor. Also, it may be interesting to review the PTC's user manuals, available from www.scs-ptc.com, Downloads section, specially the BASICS, chapter 15 on manual36 and manual38 for the PTC-II. All of that may be useful to get acquainted with them, just as a reference. Just in case, I don't mean to offend anyone with my recomendation, but I feel this may be interesting reading for quite a few members of this list. 73, Jose, CO2JA --- Rud Merriam wrote: > For one reason because AX25 is an abomination. It packs to many protocol > layers into one format and does not provide any FEC. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > > > -----Original Message----- > From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Graham > Sent: Tuesday, August 05, 2008 7:30 PM > To: digitalradio@yahoogroups.com > Subject: [digitalradio] Re: Has anyone looked into FPGA-based digitalmodes? > > > Packet, Pax or ARQ FAE, at least to be able to share the frequency > (collisions must be managed), > > Why not take the final step and code a narow band spread spectrum > packet system ..using very narrow bandwith short packet bursts based > on the ax25 system .enhanced by spread sprectrum . the system could > fit inside the bandwith taken by one of the 'narrow' multi tone > systems ? > > > G .. > > > > --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]> > wrote: >> Hello all, >> >> For my small experience about ARQ modes, it seems to me that: >> >> * a modern ARQ system does not really need a synchronous scheme as > in Pactor >> (with obligation to permanently exchange frames). It must be > asynchronous as >> Packet, Pax or ARQ FAE, at least to be able to share the frequency >> (collisions must be managed), >> >> * I don't think a powerful coding is really necessary. I think a > ratio of >> 1/2 (one information byte received for two bytes transmitted) is > sufficient >> (as in ARQ FAE or ALE DBM). Big block codings as in JT65 or Olivia > with >> ratio of 1/5 or less would be exagerated and will decrease > drastically the >> characters throughput. I don't think convolutional codings are > conveneint >> for ARQ modes as you must introduce a relatively big delay before > deciding >> what was the received characters. These codings are more > convenient for >> continuous modes (as in PSK63F), >> >> * an "ARQ memory" is absolutly necessary. You can forget coding but > you >> can't forget this tool. It is equivalent to a repetition coding and > it >> permits to reduce drastically the number of retries, >> >> * if you have an "ARQ memory" the minimum S/N is not given by the > message >> itself but by the possibility to detect the frame. If you detect > the frame, >> you will be sure to decode it (directly or through one or two > retries). >> This means that you could do a system very quick and also sensitive > in the >> same time (if you accept the number of necessary retries). > Practically, the >> minimum S/N will be determined by the speed of transmission of the > frame >> prefix (in ARQ FAE , for 50 bauds the minimum S/N is about -13 dB. > This >> means that for 500 bauds it would be -3 dB and for 5 bauds it would > be -23 >> dB). The speed prefix transmission must be independant from the > message >> speed transmission, >> >> * if I would want to do a very quick ARQ mode (but I'm on very slow > modes at >> the moment), I will prefer a THROBX modulation (a choice of 2 > carriers over >> n) than an OFDM, this because the maximum power transmitted is very > low if >> you want to keep linear (1/sqrt(n) if n is very big). >> A configuration with a mean power/peak power below 1/3 is not a > good >> configuration. >> I would switch from a non coded transmission (good conditions) to a > coded >> transmission (bad conditions) according to ionospheric conditions > (as >> determined on frames reception). A predetermined (i.e known) > sequence as in >> 110A to determine the channel transfert function would be perhaps >> interesting. >> >> * I think MFSK modulations are better than PSK modulations. >> >> * Doing a very quick ARQ mode is not very "fun"... Doing a system > able to >> permit exchange between several Hams would be much more fun. >> >> 73 >> Patrick >> > > > > ------------------------------------ > > Announce your digital presence via our Interactive Sked Page at > http://www.obriensweb.com/sked > > Check our other Yahoo Groups.... http://groups.yahoo.com/group/dxlist/ > http://groups.yahoo.com/group/contesting > http://groups.yahoo.com/group/themixwgroup > Yahoo! Groups Links > > > > > ------------------------------------ > > Announce your digital presence via our Interactive Sked Page at > http://www.obriensweb.com/sked > > Check our other Yahoo Groups.... > http://groups.yahoo.com/group/dxlist/ > http://groups.yahoo.com/group/contesting > http://groups.yahoo.com/group/themixwgroup > Yahoo! Groups Links > > > -- MSc. Ing. Jose Angel Amador Fundora Profesor Auxiliar Departamento de Telecomunicaciones Facultad de Ingenieria Electrica, CUJAE Calle 114 #11901 e/ 119 y 127 Marianao 19390, Ciudad de la Habana, Cuba Tel: (53 7) 266-3445 Email: amador at electrica.cujae.edu.cu
