Bulletins from the Pacific Packet Radio Society - page 166

quite as reliable. Retransmissions are likely to be required because of packet collisions but FEC would not help here because a collision would likely wipe out more than 3% of a packet and FEC would automatically cause an overhead increase of 100 to 200% on every packet.

I don' t know much about the AX-25 protocol yet but I am awaiting your Level 1 document. I am a little concerned over the name of the standard because it sounds a little like the X-25 commercial standard which I studied to see if it was applicable to the Amateur Radio Packet environment in 1979 as well. I concluded that it was unsuitable but had a few good ideas in it. I don't think that any standard for Amateur Radio could come from the X-25 protocol. Even if some ideas come from the protocol, it will have to be quite a bit different from X-25 and so shouldn't be named after it. I think more and better ideas are found in the DoD Transmission Control Protocol document that you provided me than in X-25.

Karl's statement about the " ... recent adoption of the AX-25 standard for radio-amateur packet radio ... " is quite a bit premature in my opinion. I have not had an opportunity yet to review it and I would not like to see any protocol adopted until it was implemented first - even my own proposal which was published in 1981. There are many problems with protocols which only show up after they are tried out in real conditions. To my knowledge the only agreement made among the various groups was to use the HDLC/SDLC frame and FCS, bit oriented protocols and variable length packets. As yet, there has been no agreement as to the layout of the data contained in the frame or in the address or even the control field to my knowledge.

73, Doug, VE7APU/3

FILE QST.83.02.08.0.n6fqr

To: Packeteers
From: Bill Danielson, N6FQR
Subject: Downloading of VADCG board

I have modified my VADCG board to be downloadable. The modification is upward compatible in the software sense, that is, the current TIP/LIPM software HEX files will run as is. The board contains 16K bytes of RAM usable for program/data.

I also added a counter that interrupts the CPU every 1/1200 of a second. To maintain compatibility with the current VADCG board, this interrupt is hardware disabled when the board is booted and must be enabled by an OUTPUT instruction. The idea here was to use it to do such things as force out data in host mode, etc.

Downloading works as follows: When booted the EPROM resides at location 0000-07FF and there is RAM at 8000-87FF. The rest of the RAM resides in its normal locations, that is, 0800-3FFF. The hardware is set up so that if the VADCG issues a certain OUTPUT

Click for Original Graphic Image of this page.