The following are the PBBS and BBS applications currently supported by Outpost.  Click on the BBS Link to see details on each.

Currently, I am aware of a couple of BBS/PBBS implementations that Outpost does not support: TNOS, SNOS, and OpenBCM to name a few.  Support was not included mainly because I didn't know how they look or behave.  To request that they get supported, read on... 

If you access a BBS that is not listed above and its' message listing is different from any of the above listing, provided this BBS is supporting your local emergency communications response efforts, please send me a full session listing as described here.

Using Outpost's Interactive Packet Window, Hyperterm, or any other packet program, manually do the following:

1. Connect to the BBS or PBBS.
2. Send yourself as message on this BBS (SP <yourcall>, etc.),
3. Get a listing of messages addressed to you:  enter the LM command.
4. Retrieve individual messages with the Read command (R ###),
5. Get a listing of bulletin messages (if applicable):  enter LB command.
6. Retrieve one bulletin (R ###),
7. exit from the BBS (usually a "b" for Bye),
8. Cut and paste the entire text from the above session into an email or text file,
9. email it to me at the address below. 

I'll keep you posted on when an update can be delivered, and will need your help to check it out since I will not have access to this BBS/PBBS type.

Return to Top

Outpost relies on a BBS or PBBS as a mail-drop for leaving and picking up packet messages.  You may be interested in using Outpost, but do not have a BBS or PBBS in your area.  Here are 3 possible approaches you may consider for getting a packet environment up and running ...

1. Quickest, easiest, cheapest: identify an existing user with a radio and PBBS-enabled TNC as your mail drop. 

UPSIDE: (i) Take a look at the list of Personal BBSs embedded TNCs from Kantronics, AEA, and MFJ.  There are plenty out there that have sufficient memory for small message passing.  
(ii) A TNC-Radio combo can be easily deployed in a small rugged'ized package, such as to a repeater site. (iii) Most TNCs do offer remote Sysop capabilities so you can configure, command, and control them remotely.

DOWNSIDE: (i) If the TNC is not a KPC3-PLUS, then you can only have one station connect to its PBBS at a time. Others will get a "BBS Busy" message if attempting to connect when someone else is already connected.  (ii) Memory limitation... you will need to make sure that users retrieve and delete messages addressed to them so that you do not run out of memory.  NOTE:  Outpost may not detect that a Out of Memory condition occurred and the user may think that it was posted on the BBS.

2. Quickest, easiest, not so cheap: If you have the funds, I recommend the KPC3-PLUS, with the version 9.1 firmware, and a 512Kb memory upgrade.  However, I have heard that the 512Kb memory module is no longer available.  There may be a commercial substitution out there; if anyone has a pointer, please let me know.

UPSIDE: (i) This TNC supports multiple concurrent connects, and gets you up and running with a quick and easy mail drop that closely resembles a stand-alone BBS. (ii, iii) Same comments as above regarding the small package and remote Sysop control.

DOWNSIDE: same memory limitation as above. You will have to make sure that users retrieve and delete messages addressed to them so that you do not run out of memory.

3. Not quick, not easy, may/may not be cheap: If you had a PC, TNC, and Radio that you could dedicate to a PC-based BBS and the time to work through the configuration, then I recommend looking at the F6FBB or JNOS BBS. To give you a sense of what is involved in configuring a software-based BBS, check out this F6FBB implementation guide for my local county hospital... http://www.outpostpm.org/#Documentation, scroll down to Application Notes, and take a look at the FBB Implementation Guide. This procedure works, and has been confirmed by others.  However, if you deviate from the main equipment and SW setup, you will probably have to read up on all the components, and then plan on spending some shack time to get it to work.

UPSIDE: (i) because it is PC-based, you will not run out of message storage area. (ii) This package may be a good jumping off point for bringing up a multi-node packet network within your Area. For instance, in Santa Clara County, we are looking (April 2008) at deploying 4 F6FBB or JNOS instances with 2 meter user access ports and a 220 LAN backbone. During high packet traffic times, this will help spread out the traffic load.

DOWNSIDE: (i) Think of this as essentially bringing up a server to be accessed by Outpost clients. Depending on the PC, you may need a consider the environment where it will be deployed (dust, temperature, etc). (ii) To really check out your setup, you will need 2 sets of everything... a PC-TNC-Radio combo for the BBS, then another PC-TNC-Radio for your local packet station to connect to the BBS (as well as to test it). (iii) You may need to train up a few more folks as SysOps to help out. (iv) This effort will require a better understanding of a PC and its operating system.

Outpost uses packet bulletin board systems (BBS) as mail drops for exchanging messages between users.  Users post their messages to a BBS using Outpost or some other interactive terminal mode application for other users to retrieve messages addressed to them.

While all BBS perform the same general functions, their individual implementations can be quite different.  BBSs are implemented as a SOFTWARE application that runs on a PC, MAC, Linux, or other platform.  Examples of software-based BBSs are F6FBB, MSYS, and AA4RE to name a few.  BBSs can also be implemented in FIRMWARE and incorporated into a Terminal Node Controller (TNC), such as with the KPC3, MFJ-1270, and PK-232 TNCs.  This type of BBS is typically referred to as a Personal BBS or PBBS.  There are several BBS and PBBS that Outpost supports; see the list below.  For this discussion, the tern "BBS" will be used to refer to both types.

The different BBS implementations were made with the intent for some type of optimization envisioned by the BBS' author.  As a result, each implementation has slight differences in their look, feel, and behavior.  Outpost talks to the BBS by interacting with it in the same manner that you would manually interact with the BBS.  Essentially, it does the following:

• looks for prompts from the BBS to let it know when to send a BBS command
• receives message lists to determine what messages need to be retrieved
• retrieves messages and stores them in Outpost's message database

To do this, Outpost needs to know several things about the BBS: