I've got to agree with Jose here. AX.25 works pretty well on VHF, but falls apart on HF. But AX.25 is a link-layer protocol, not the whole suite of stuff that got crammed into a TNC. AX.25 may have been derived from the X.25 landline protocol, but using the obsolete landline modem under it is the real problem.
Tacking "some kind of FEC" onto the current 300-baud FSK modem that is generally used in the TNC's implementation (but has little to do with AX.25 other than being a common physical layer to hook it to) is a bit of an oversimplification. But using a carefully designed FEC layer on top of a more appropriate baseband signal -- then hooking it up to the AX.25 link layer and whatever else goes on top of that -- that sounds like a quite reasonable approach. In fact, putting ALL of the TNC (soft Z80, I/O ports, as well as a re-designed physical layer) into an FPGA, then running the existing TNC firmware on the soft CPU, sounds quite workable. A drop-in replacement TNC for BBS, etc. operation -- which could support both "new" and "old" modems. Rud Merriam wrote: > Again, AX.25 is not suitable for many reason so a new standard is needed. > > It is based on X.25 that assumes a reliable link which is obviously not the > case with RF. Simply tacking some kind of FEC onto AX.25 will not suffice. But putting an appropriate type of FEC to make the link "reliable enough" should suffice. Maybe viterbi-encoded data with a Reed-Solomon code on top of it (such as is used in satellite links). > AX.25 includes message routing which is inappropriate for that level of > protocol. Which doesn't have to be used. The "connect to xyz via abc and def" was more of a hack to get by until something better came along. One shouldn't be digipeating on HF, anyway. Use it for point-to-point and that's it. 73, Paul / K9PS
