Santa Clara County 
Office of Disaster Medical  Services
Bulletin Board System Project

This page contains the following sections that describe the ODMS BBS Project... 

Overview
 My interest in BBS applications came about accidentally. 

Packet has been used throughout Santa Clara County (CA) for many years.  Packet is considered essential to the County Emergency Managers because of the fail-safe nature of it and its independence of the existing infrastructure in the event of a disaster.  While intended to pass California RIMS (Regional Information Management System) reports on disaster and activation status, packet has demonstrated its usefulness for passing a variety of list-based traffic that would be impractical for voice channels.

This aspect of packet was also considered very attractive to Santa Clara County Public Health Department, Office of Disaster Medical Services (ODMS).  Their mission is to coordinate preparedness and response to public health threats and disasters.  One of their key constituents are the County Hospitals.

ODMS has been working to put emergency communications in place throughout the hospitals in the county.  With voice communications under control and monthly equipment checks held, their focus has turned to packet as a means for rolling up status and passing detailed messages.

Because of an ease of use requirement, ODMS plans to roll the Outpost Packet Message Manager program out to its 10 participating hospitals.  Unfortunately, the BBS used by the Santa Clara County RACES organization was not an option due to the current user load from participating county cities.

Thus my search for a BBS.

BBS Requirements
A  BBS for the County Hospitals had to meet several requirements to be viable for the County.

Hardware Configuration

  1. Common hardware. The PC would have to be Intel-based to ensure some element of supportability and commonality with the bulk of the processing platforms available on the market. 
  2. Contemporary Operating System. I’ve worked in the DOS world before.  However, you loose the power of the platform particularly if you have more recent hardware. The O/S needs to be Windows 98, 2000, or XP. I’m excluding NT given the administrative overhead that it includes.
  3. TNC. The county purchased KPC-3+’s for all hospitals as the standard TNC. This BBS implementation will need to support the KPC-3+
  4.  Radio Channels. All hospitals will come in on a 2 meter port based on committed radio purchases. A multi-band, multi-port configuration is not required. 

BBS Configuration

  1. Number of Ports. The BBS will need to support up to 14 hospitals, with on average 5 concurrent connections.  My assumption is that random packet usage will generate a sufficient distribution of traffic over the time domain thereby permitting a reasonable level of channel loading.
  2. Support Tactical calls.  This is an equivalent feature to what we do with voice nets… All assigned users have a tactical call sign that can be passed from user to user regardless of the owned FCC Call Sign. This is a BIG WANT since I have not seen this embedded in too many BBSs.
  3. Supportability. The BBS should be stable, documented, and has a known owner (just in case).
  4. Installed Base. This implies there is a community out there that can act as a resource as you are bringing a BBS on line.
  5. Remote support. Remote sysops will be recruited and given training.

Interoperability

  1. Outpost. Given the Hospital’s desire to use Outpost, this seems to be a good idea (!).

What’s not required

  1. Message forwarding. For the moment, all messages originating on the BBS are assumed to be addressed to participating members of the BBS.
  2. Others?

The Solution
 The configuration I have adopted to address the above requirements is:

F6FBB BBS System (www.f6fbb.org)
Per the website, “FBB is a bulletin board software for amateur packet-radio. This software is free of charges. It can be copied or installed only for non-commercial use abiding by the laws.

“This software has been developed to be compiled on different architectures including MS-DOS (DosFBB), Windows 16 (WinFBB-16), Windows 32 (WinFBB-32) and Linux on PC hardware (LinFBB). All these versions have almost the same functionalities. Some differences may happen due to the capabilities of the operating and windowing systems.”

G8BPQ (BPQ) AX25 Networking Package 
(Many sites have it, I found mine at… http://skyscraper.fortunecity.com/digital/3/bpq/)

Per the BPQCODE.DOC file, “This software allows an IBM PC, or similar machine, equipped with suitable Communications hardware, to act as a Node in a NET/ROM compatible AX25 network, and/or to support a multi-user Mailbox [BBS], or other similar applications.

“The switch section of the code supports up to 16 AX25 ports, and the application interface supports up to 64 connections. 

F6FBB Implementation Guide
With this in place, the the attached document describes where I got the software, what I had to do to configure the software, and the testing I performed to verify that the system works.  In includes listing of my configuration files, mark-ups of what I changed and left alone, and some (hopefully) pointers that may help you get your implementation quickly.

Check out my BBS Implementation Guide for a complete description on what I had to do to get this up and running.

Return to Top

General Feedback

Please send any feedback to

Hit Counter

updated:  March 01, 2008