PBBS broadcast design BASICS This protocol is designed to allow PBBS messages, particularly @WW messages to be broadcast over noisy HF channels without ACK. DESIGN GOALS 1. Messages should be delivered intact. 2. Receiving systems should remember partial messages, and be able to reconstruct complete messages when all the parts arrive. 3. Block sizes should be as small as possible to allow for good performance on very noisy channels. 4. No compression will be provided by this code. It's assumed that the compression of the underlying BBS will be used. 5. Functions with F6FBB on Linux and Windows 98. 6. The format assumes 8-bit clean path. If the lower levels are not 8-bit clean, then a 'prefixing' system will be used to simulate an 8-bit path. This is to simplify the design and to maximize efficiency on 8-bit paths. PACKET DESCRIPTIONS Packet format. All packet blocks are exactly 16 bytes long. With 1 character to specify both the packet type, and to act as a block start marker. And 2 characters at the end for CRC. There are 13 data bytes. [Packet Type:One byte] Packet Data [Packet CRC (2 bytes)] PACKET TYPES: CALLSIGN PACKET C -- Callsign packet. This packet establishes the callsign for the sending station. Receiving stations should not accept any data until a Callsign packet has been received. The data block ID for each user should be increment whenever he restarts his block numbers. Usually when a completely new set of data arrives. Prefix indicates the data prefix character. Specfify ' ' for no prefixing or the prefix character. The callsign is the sender's callsign. The callsign can be up to 9 characters long. The callsign should be padded with spaces. 'C' [Data block ID:3 bytes](Prefix:1 byte)(Callsign)(spaces) [CRC] DATA PACKET D -- Data packet. This packet contain the main data blocks for the messages. 'D' [Block number:3 bytes]message data (10)[CRC] PACKET MESSAGE BEGIN AND END POINTS Message start and end points will be determined by the normal PBBS message format rules. Below is a typical packet message. As shown, when the receiving code finds an 'SB' it assumes the beginning of a message block. When it finds and '/EX' it assumes the end of a message. When consecutive packets contain both start and end of a message, then that message is assumed to be complete, and output to the mail.in file, which is then read by FBB. TYPICAL PACKET MESSAGE SB PACKET @ NCA < KE6I $751_KE6I Hey, is anybody out there? R:000917/1431Z @:KE6I.#NCA.CA.USA.NOAM #:751 [Berkeley] FBB $:751_KE6I From: KE6I@KE6I.#NCA.CA.USA.NOAM To : PACKET@NCA I just thought I'd send a message to see if anyone in the area is reading this. Maybe to get a little conversation going or something. I've been cleaning up my packet stuff, and installing new hard drives and generally optimizing things over here in Berkeley. Though mostly I'm really busy with work all the time and don't have time for anything. Anyway, if there are any live bodies out there in NCA, send me a message, and I'll try to get back to you. /EX PREFIXING If a non-space character is specified for data prefixing, then the two characters that follow will be HEX digits. For example, with a prefix character of '$' and a channel unable to transmit a 'tab', the following. Cathryn(Tab)Mataga will be translated to Cathryn$09Mataga Any data can be prefixed, including the 'C' packet containg the prefix character itself. RECEIVING PROGRAM STRATEGY Programs receiving data should look for valid blocks for every valid start character that's received. When a valid block is found, skip past that data, store the block and begin looking for valid blocks again. TRANSMITTING PROGRAM STRATEGY Select a random number for the block count. This will reduce the chances of two people sending confusing block numbers, if the channel fades between two transmitters on the same frequency. Allow block numbers to wrap around to 0. ANALYSIS With a block size of 16 bytes, if we have a bit error rate of .001, or 1/1000 bits, then the odds of receiving a packet are (1-.001) ^ 128 = 88% With a bit error rate of .01 or 1/100, then the odds of receiving a packet are (1-.01) ^ 128 = 28% With a bit error rate of .0001 or 1/10000 bits, the odds of receiving a packet are: (1-.0001) ^ 128 = 98% ISSUES 1. Are 2 CRC bytes too many? Can I get away with just one byte here? Do I need more? Possible change: Have one byte for a block CRC, and then do a longer 'per message' CRC. 2. Are 16 byte blocks really going to work? What is a typical bit error rate for an HF channel? 3. Is the data type byte really necessary? Could I just send out the index numbers and the CRC's and let the code on the receive end find the packets. 4. Find the CRC algorithm used in AX25. (Look through linux kernel source maybe.)