Data communication system with communicating and recharging docking apparatus for hand-held terminal5317691Abstract In an exemplary embodiment, portable data devices can be coupled with a local area network at any of a multiplicity of points and integrated into the system. The preferred system is highly flexible and closely adaptable to changing needs of an individual user. For example, unitary multiple docking devices each receiving a plurality of hand-held computerized data terminals may be chained in a series to a single primary controller which may have a further LAN channel including an auxiliary unit which may supply charging power to a further series of multiple docking devices, added to the system as needed. A preferred auxiliary unit is capable of handling two-way communication without the provision of a direction control line in the channel. A preferred LAN system may have unitary printed circuit boards or other rigid network pathways provided with multiple docking receptacles. The control for the LAN system will automatically establish identities for randomly added devices. Claims I claim as my invention: Description BACKGROUND OF THE INVENTION
______________________________________
Primary Port (J6)
Pin Number Signal Name
______________________________________
1 V+
2 +RS-485
3 -RS-485
4 V+
5 Direction
6 N.C.
7 GND
8 GND
9 N.C.
Secondary Port (J7)
1 N.C.
2 +RS-485
3 -RS-485
4 N.C.
5 Direction
6 N.C.
7 GND
8 GND
9 N.C.
______________________________________
Each of the RS-232 ports are fifteen pin D-sub male connectors, with pin assignments as follows:
______________________________________
Pin Number Signal Name
______________________________________
1 N.C.
2 -TXD
3 DTR
4 -RXD
5 DSR
6 RTS
7 CTS
8 GND
9 N.C.
10 N.C.
11 TRXCO
12 TRXCI
13 RTXCO
14 RTXCI
15 N.C.
______________________________________
The LCD display 221 may be a two line by sixteen character format. The keyboard may be a sixteen position four row by four column matrix. Depression of the keys may result in positive tactile feel. Environmentally the assembly may resist exposure to moisture. The AC line cord my be removable from receptacle 230. The disc drive associated with loading slot 224 may comprise a 3.5 inch half-height unit capable of an unformatted capacity of one megabyte per disk (720 KB formatted). An optional two megabyte per disk drive is available. Exemplary Controller Circuit, (FIG. 30) A discussion of the functional blocks of the exemplary controller circuit of FIG. 30 is presented in the following paragraphs. Microcomputer 500, (FIG. 30) The microcomputer 500 may be a type 80C186, some applicable features being as follows: 16 bit external bus Clock generator Two independent DMA channels Programmable interrupt controller Three programmable 16-bit timers Programmable memory and peripheral chip select logic Programmable wait-state generator Local bus controller Additional detailed information is available in the Intel 80C186 user's manual. The microcontroller memory map of TABLE A on the following page gives the general organization of various functions within the memory space by way of example.
TABLE A
__________________________________________________________________________
Controller Memory Map
__________________________________________________________________________
##STR1##
##STR2##
__________________________________________________________________________
Since the application software may reside in RAM component 501 and in removable disk storage, board level EPROM component 502 may only provide boot functions and diagnostics. This approach allows a stable well tested EPROM to be released with the system without future updates. A socket is preferably provided for easy access. All application programs execute from RAM (e.g. 501, FIG. 30A). This memory space is a maximum of 768K (see memory map in TABLE A). All application programs are retained on the removable 3.5 inch disks and are booted to RAM on power up. This allows RAM to be volatile, eliminating the need for optional battery back-up in some cases. Two 85C30 SCC's, SCC1 and SCC2, FIG. 30B, may be used for host and terminal communications. The four channels may be configured as synchronous or asynchronous, RS-232 ports. One of the four communication ports may be software configured for RS-485 LAN communications. Real-time clock component 550 may be a Motorola type MC146818. This device is power backed-up to maintain accurate time during power interruptions of various durations depending on the backup options. When an external battery is not used, a capacitor maintains memory and time for up to two weeks. The battery option may extend clock operation for more than three months. Along with internal registers for time, date and other data, the MC146818 provides fifty bytes of general purpose battery backed-up RAM. SYNC/ASYNC interface component 560, FIG. 30B, may comprise ports A, B, C and D as shown at the right in FIG. 30B. For synchronous protocols, transmit and receive clock lines are available. The controller or connecting device may generate the clocks and is selected by a direction signal from the microprocessor and use of one of two possible cables between the host and controller. Autoanswer modems may be connected to this port, and autodial may be initiated using Hayes commands. The LAN interface component 570, FIG. 30B, may consist of primary and secondary channels. Each channel is driven by an RS-485 transceiver. The primary channel can drive twenty-four logical units or transceivers. Multidocks connect directly to the controller using the primary channel with the use of cables. The secondary RS-485 channel connects to additional multidocks using cables and an APU (FIGS. 29-29A) for charging. The RS-485 or the fourth RS-232 port is selectable through software (485SEL). This allows communication with four RS-232 devices (e.g. host and three modems) and also devices directly connected to the RS-485 LAN. A LCD interface 571 may be a self contained module with data lines, read/write strobe and two control lines for enabling the module (PCS4) and controlling power to the device. Keyboard interface 572 may strobe the four columns of the 4.times.4 matrix and detect corresponding key closures on one of the four rows. Keyboard activity may be interrupt driven using INIT3. Debounce key rollover will be handled in the firmware keyboard driver. Once the interrupt is detected the key code may be read from the keyboard interface. The chip enable signal may be PCS5. The 3.5 inch disk drive controller 573 may be an Intel type 82072 high integration floppy disk controller with built-in analog data separator. This provides the interface requirements to the 3.5 inch disk drive of network controller 200. Five DMA sources may be logically "ORed" to the two available DMA request inputs of the DMA controller of microcomputer 500. The software may keep track of the active device within each group "ORed" to the specific DMA channel. A list of the DMA sources and their respective grouping is listed below. SCC Port A (LAN)=DRQ0 Disk Controller=DRQ1 The interrupt source and type of interrupt to the processor 500 may be as listed below.
______________________________________
Source Interrupt Type
______________________________________
Manual Reset NMI
SCC Channels A, B, C, D
INIT0
Disk Drive Controller
INIT1
Keyboard INIT3
______________________________________
A DC/DC converter 581, FIG. 30B, may provide logic power. It may be designed to operate over a wide input voltage range of thirteen to twenty volts. The converter is board resident and allows the use of a relatively inexpensive single output power supply used also for charge voltage to the multidocks on the primary channel. A linear regulator 582 may be powered by the plus fifteen volt power supply and provide plus twelve volts to the disk drive. A back-up battery is indicated at 583 and may consist of a 3.6 volt, three-cell nicad battery pack with a 500 amp-hour capacity. A self oscillating buzzer 584 may be enabled under microprocessor control. Charge voltage and input power to the controller board may be provided by a single output power supply. Output voltage may be in the range from not less than fifteen volts to not greater than twenty volts. The supply may be capable of sourcing 7.0 amperes and may current limit before 8.0 amperes. Software Discussion The Network Controller 400, FIG. 28, may provide high-speed LAN communications for directly connected hand-held terminals via a communications protocol known by the initials NPCP (Norand Portable Communication Protocol). The Network Controller may provide both synchronous and asynchronous communications support for devices which are remote to the host site. This support may include auto-dial and auto-answer capabilities. The Network Controller may provide communications support for existing TTY and ADCCP devices of Norand Corporation. The Network Controller may support an existing file transfer protocol for hand-held computers of Norand Corporation which consists of a single upload session followed by a single download session. The Network Controller may provide a migration path to a file transfer protocol which may require multiple uploads and downloads. The file transfer system implemented by the Network Controller may provide a migration path for full-duplex Network Controller to Network Controller communications. A mechanism may be provided to chain Network Controllers, either directly or over switched lines. The chaining mechanism may be used to provide additional RS-232 ports at a host site or to establish a session with a controller at a remote site. The Network Controller may provide the host with a method for initiating a communications session with a specific terminal (not necessarily a hand-held data terminal). The Network Controller may provide a method for "broadcasting" a file or files to multiple terminals. The Network Controller may provide a method for storing user files on the system. The Network Controller may provide a method for downloading files requested by hand-held data terminals, independently of a host computer. The Network Controller may provide a method for downloading files to hand-held data terminals under the direction of a host computer. The origination of the file may be transparent to the hand-held terminal. Communication ports on the Network Controller may be software configurable. The Network Controller may provide the user with an easy-to-use interface for changing configuration parameters. System Configuration The Network Controller may be configured through a menu driven program using the keyboard and display. The following examples represent some possible system configurations. ##STR3## Network Controllers at the host site may be configured with four RS232 ports, or with three RS232 ports and one RS485 port. The RS485 port is used if hand-held computers are in a LAN at the host site. One of the RS232 ports is used for communication with the host, and the remaining RS232 ports are used for remote communications. Currently, the host port data-link protocol must be transparent point-to-point bisynchronous or asynchronous with (optional) parity checking. The host port may be configured at speeds up to 19,200 bps. Local Network Controller to remote Network Controller configurations: ##STR4## Several options are provided for support of remote sites. Network Controllers at remote sites have one RS232 "host" port, for communications with a "host" Network Controller, and one LAN port. The communications link to the host controller can be manually configured to use either ADCCP or a TTY extension as the data-link protocol. ADCCP ports on a host controller may communicate with either remote controllers configured for ADCCP or with ADCCP terminals in Multi-quad Lockboxes. TTY ports on a host controller may communicate with 4300/4400 terminals, 101/121/141 terminals or other TTY devices of Norand Corporation. The host controller determines if a remote device is a Network Controller or an ADCCP/TTY device, when the connection is made. The host may dynamically configure RS232 ports on a Network Controller as either ADCCP or TTY ports when the port is activated. This facilitates the use of a single port for synchronous communications to remote Network Controllers and asynchronous communications to TTY devices. Information on 4300/4400 terminals which may operate on the network of FIGS. 28, 39 and 40, for example, and other exemplary details are found in the following pending applications: (1) Cargin, Jr., Kelly, Fischer, Gibbs, Boatwright and Durbin application for patent entitled "HAND-HELD COMPUTER TERMINAL" U.S. Ser. No. 07/339,330 filed Apr. 14, 1989, now abandoned (2) Miller, Koenck, Walter, Kubler, Cargin, Jr., Hanson, Davis and Schultz applications for patent entitled "DATA CAPTURE SYSTEM WITH COMMUNICATING AND RECHARGING DOCKING APPARATUS, AND MODULAR PRINTER AND HAND-HELD DATA TERMINAL MEANS COOPERABLE THEREWITH" (2a) U.S. Ser. No. 07/346,771 filed May 2, 1989, now abandoned (2b) U.S. Ser. No. 07/347,602 filed May 3, 1989, now abandoned (3) Miller, Traeger, Kubler, Cargin, Jr., Hanson, Davis and Schultz applications for patent entitled: "DATA COMMUNICATION SYSTEM WITH COMMUNICATING AND RECHARGING DOCKING APPARATUS FOR HAND-HELD DATA TERMINAL" (3a) U.S. Ser. No. 07/347,298 filed May 2, 1989, now abandoned (3b) U.S. Ser. No. 07/347,849 filed May 3, 1989, now abandoned The entire disclosure of each of these pending applications including the drawings and Appendices is hereby incorporated herein by reference in its entirety. Software interface The Network Controller maintains sessions between the host computer and hand-held computers of Norand Corporation (or other devices) on logical channels As used here, "channel" consistently refers to a logical data channel and "port" refers to the physical link, which may contain one or more logical channels. Data from the Network Controller to the host is identified by channel number and record type. With the possible exception of an initialization record, data from the host is sent in response to a "channel request" from the Network Controller and is identified by record type only. (Record types "0" to "5" are, for the most part, compatible with NI315/NI311 record types). Logical Channels--Data transfers to/from the host computer are on logical channels. The logical channel identifier field, which precedes data to the host, consists of a 1-byte "controller channel" followed by a 1-byte "terminal channel". Controller channels may contain terminal channels ranging from "1" to "9". Controller channels range from "0" to "9". New controller channels are opened each time a secondary controller--with multiple "terminal" ports--connects to the "host" controller. An identification record is sent to the host when a new controller channel is opened. The identification record contains a location identifier for the new controller, port information, and a channel number for the controller. Note: Only one controller channel is required, to the host, if no secondary controllers have multiple terminal ports. Data transfers for secondary controllers can occur on the primary controller channel (e.g: "0"). In this case, the host could treat the 2-byte channel identifier as a single field and avoid double indexing, or, optionally, the channel identifier could be reduced to a 1-byte field. Records from the Network Controller to the host computer. Records from the Network Controller are always preceded by a channel identifier, followed by a 1-byte record type. Network Controller record types are: 0--UPLOAD DATA--Upload data records contain "upload" data from hand-held terminals. The host is guaranteed that the data from (or to) a terminal is contiguous on a logical channel. 1--END-OF-SESSION--End-of-session records are sent after each hand-held session completes, to indicate the status of the communications session. 2--DATA REQUEST--Data request records are used to request data from the host computer. The host may respond with a data record, a file directive or an end-of-data record. 3--INACTlVE STATUS--Active/Inactive status records are sent by the controller when the host port is inactive. An inactive status record indicates that no terminals are currently active on the channel. 4--ACTIVE STATUS--Active/Inactive status records are sent by the controller when the host port is inactive. An active status record indicates that a terminal(s) is currently active on the channel. 5--ACTIVATE REQUEST--Activate request records are used to obtain the information from the host which is necessary to activate the specified channel. Activate requests are sent for a physical port whenever the port is disconnected and include the status of the previous activate request for the port. The host may respond with an auto-dial activation record, an auto-answer activation record, or with a deactivate record. Auto-answer activation records may include a "timeout period" specified in minutes. If the timeout period expires, the port will be deactivated and a new activation request will be generated for the port. This feature will allow a port to be toggled between auto-answer and auto-dial. Note: Modem configuration information is only required for modem types not supported by Norand. Note: The activate request record replaces the NI311/NI315 phone request record. 6--SPECIAL REQUESTS--Special requests are used to prompt the host with an extended set of Network Controller requests. The host must examine a "subtype" filed to determine the type of special request. Currently, two subtypes of special requests are required: 1--FILE REQUEST--File requests are sent to the host computer each time a Network Controller is brought-on-line. The host may respond to a file request with a one of several possible file directives or with an end-of-data record. File requests/directives can be used to load and maintain files stored on the Network Controller diskette and in RAM. The controller will send file requests to the host until the host responds with an end-of-data record. The file request option may be turned on or off with a flag in the initialization record. 2--CONNECTION REQUEST--Connection requests are sent to the host to allow the host to establish a communications session with a specific device or terminal. The connection request includes a field to identify the location of the Network Controller which generated the request. The host may respond with a device identifier (terminal ID) to establish a session or may respond with an end-of-data record. The connection request option is enabled with a flag in the initialization or activation record. If the option is turned on, the host will be prompted with a connection request: 1) at the beginning of a session with a Network Controller, 2) after each end-of-session record is sent, and 3) after a fixed time period expires with no activity on a channel. An end-of-session always follows a connect request, either after the request fails or after the terminal session completes. Note: Inactive status records will not be sent to channels with connection requests enabled. 7--DIRECTIVE STATUS--Directive status records are sent to the host computer to supply the host with completion status information for an outstanding host directive. The directive type is included in the status record. 8--IDENTIFICATION RECORD--A Network Controller may be configured with the keyboard to send a location identifier to the host computer or host Network Controller. If the identification record is enabled it will be the first record sent in a communications session. The identification record is required for remote Network Controllers. The identification record includes a location ID, port information, the number of non-host "terminal" ports on the controller. If this number is greater than one: 1) another "controller channel" will be opened to the host, 2) the identification record will be forwarded to the host on the new channel, 3) an initialization record will be expected, from the host, on the channel. Records from the host to the Network Controller. Records are sent from the host to the Network Controller in response to channel requests from the controller, with the exception of the first initialization record. Host record types are: 0--DOWNLOAD DATA--Download data records are sent from the host to the controller in response to download requests, and connection requests. 1--END-OF-DATA--End-of-data records may be sent from the host to the controller in response to data requests and special requests. The end-of-data record indicates that no data exists for the type of request specified. 2--INITIALIZATION RECORD--The initialization record is used to configure the host/Network Controller communications session. The initialization record is sent at the beginning of a communications session with a controller. For remote controllers, the initialization record is sent in response to an identification record. 3--AUTO-ANSWER ACTIVATION RECORD--Auto-answer activation records are sent in response to an activation request and may include optional modem and port configuration parameters. An auto-answer activation record may also include an optional timeout parameter, which contains the maximum number of minutes that the controller should wait for a connection on the port. After the timeout has expired, the port will be deactivated and another activation request will be sent to the host. Note: The auto-answer activation record replaces the NI311/NI315 "cancel-auto-dial" record. 4--AUTO-DIAL ACTIVATION RECORD--Auto-dial activation records are sent in response to an activation request and include a phone number and may include optional modem and port configuration parameters. Note: The host can use activation records to dynamically change port type (e.g. ADCCP to TTY). 5--DEACTIVATE (for one minute)--Deactivate records may be sent by the host computer to deactivate a channel requesting activation, for one minute. 6--HOST DIRECTIVE--A host directive may be sent by the host in response to a special (file or connect) request or data request from the Network Controller. The host directive contains a "subtype" field. The host will receive a status after the directive has completed, either normally or abnormally. Currently, five subtypes of host directives are required: 1--FILE UPLOAD DIRECTIVE--An upload request can be used to upload a user file stored on the disk of the controller which generated the file request. For example, this feature can be used to obtain the directory of user files on the controller disk. After the requested file is uploaded the controller will sent another file request to the host. 2--LOAD DIRECTIVE--A load directive may be sent in response to a file request, to download a file to the controller which generated the file request. The load directive must include a directory entry which specifies the file name, date, size, etc. After the load directive has been sent, the controller will send data requests for file data until the host responds with an end-of-data record. The data will be written to a file on disk, with the name specified. Existing files with the same name will be overwritten and excess space will be recovered. After the file has been successfully written, a status field will be set to indicate that the file is in a defined state and is available for use. 3--DELETE DIRECTIVE--A delete directive may be sent in response to a file request to delete a data file on the Network Controller. A delete directive will fail if the file is in use. 4--DOWNLOAD DIRECTIVE--A download directive may be sent in response to a data request and is used to download a file which exists on a controller's disk to a terminal on the attached LAN. The terminal which receives the download data should not be able to distinguish between "download directive data" and data from the host. 5--CONNECT DIRECTIVE--A connect directive may be sent in response to a "connect request" from the Network Controller to enable the host to connect to a specific terminal on the LAN. The connect directive must contain a terminal identifier. Remote Network Controller interface "Remote controllers" can be configured for connection to a "host controller", through any of the four ports, over either a switched or non-switched line. The connection will be synchronous and will use ADCCP for data-link control. The controller will acknowledge an ADCCP poll (SNRM) directed to its destination address. The remote controller will then send an identification record which will include the logical location of the controller (for customer use) and a control byte with a device identifier. Remote Network Controller record types are identical to the record types for a local Network Controller. If the remote controller is configured for multiple terminal ports, the host controller will open a new channel for the remote controller and will simply pass all data through, to the customer's host computer. If the remote controller is configured for a single LAN port, the host controller can, optionally, intercept identification and activation records, and can pass data through on existing channels to the host. Remote controllers will default to auto-answer mode Auto-dialing with a remote controller: Controllers in a remote "depot" can be configured to auto-dial a phone number(s) at the host site. A primary and alternate phone number may be entered with the keyboard, along with an associated dial time, number of retries, retry wait time, failure threshold, modem type, and minimum number of terminals. The primary phone number will first be dialed after the dial time is reached and the minimum number of terminals are connected. The minimum number of terminals will default to one, and must be non-zero. If the dial time is zero, the primary number will be dialed as soon as the minimum number of terminals are connected. The controller will retry the primary number after the wait time has expired and at least one terminal is connected. Retries will continue until the retry count is exceeded or the failure threshold is reached. If the failure threshold is reached the alternate phone number will be used for the next call. Remote controllers will default to auto-answer mode. ESTABLISHING COMMUNICATIONS SESSIONS WITH TERMINALS OF NORAND CORPORATlON A. NON-LAN TERMINALS. This category of terminals includes existing TTY and ADCCP terminals of Norand Corporation, and 4330/4400 terminals on an RS232 interface. Non-LAN terminals may respond to a poll from the host (or host controller) with one or more upload data blocks, and then receive zero or more download blocks from the host. The host, typically, identifies the terminal by an identifier in the upload data and associates download data with the identifier. Note: Support for booting 3.times./4.times. terminals in a non-LAN environment is currently undefined. B. LAN TERMINALS. LAN terminals are attached to a high-speed RS485 multi-drop link on the Network Controller. The Network Controller determines what logical terminals are attached to the network, and is responsible for maintaining a current terminal table. The terminal table must include a LAN address and an associated terminal name, which does not need to be unique and can be a "wild card" name. The name of a terminal can be fixed or can be set by a customer. For example, the terminal name can be a function of a bakery route ID, or can be hard-coded in the firmware of the device supporting the terminal. 1. HOST-TO-TERMINAL SESSIONS. Host-to-terminal sessions can be initiated in one of two ways: a) LISTEN-ANY (MYID, YOURID)--In this mode a controller application identifies itself and will listen to any terminal trying to connect to "myid". After a successful connection, a terminal name is returned in "yourid". "Myid" could be hard-coded in the software/firmware of the controller and terminal. b) OPEN-SPECIFIC (MYID, YOURID)--In this mode a controller application will attempt to connect to a terminal specified by "yourid". Open-specific requests are generated when the host responds to a connect-request with a terminal ID. The host and terminal must agree on the terminal ID (e.g. "yourid") used to make the connection. After a terminal connects, the controller simply provides a link between the host and the terminal. In a single session, the terminal can send zero or more upload records to the host, and then the host may send zero or more download records to the terminal. Nothing prevents a terminal on the LAN from having additional uploads and downloads or from establishing multiple sessions. 2. CONTROLLER-TO-TERMINAL SESSIONS--The Network Controller will provide a continuous application which will attempt to communicate to devices on the LAN, whether or not the host is connected. The application will be provided for the purpose of downloading data files from the system disk to terminals on the LAN. This facility could be used to load HHC's with operating system files or a kernel program, for example. The application will issue a listen-any (myid, yourid) and will establish sessions with terminals attempting to connect to "myid". The terminal can optionally send a list of the names of files to download. If the terminal does not send a list of download files, the controller application will scan a data file directory for "boot" files and will download those files to the terminal. The host computer will be provided with facilities to maintain data files kept on the controller. In addition, a facility will be provided through the controller keyboard and display which allows the user to load data files from a 31/2 inch MS-DOS diskette. The host will receive no status information for controller-to-terminal sessions. Using this option while the host is in session may result in contention for a file. STORE-AND-FORWARD FILE TRANSFER SUPPORT The Network Controller will provide the host computer with the facilities to maintain data files on the Network Controller. (Refer to the section describing file requests and host directives.) In addition, a facility will be provided to allow the user to load data files from a 31/2 inch diskette. All data files will be written to the Network Controller system diskette, and will be read into RAM during the controller's boot cycle. An entry for each data file will exist in a data directory file. The fields in the directory entries are primarily under host control and are intended for version control. The directory entry will include a type field, which may be used to connect the file to a specific application (i.e. a boot application). Data files which do not have an entry in the directory file will be deleted during the boot cycle. Host file maintenance will occur after the host session has been established, and before communications begin on any of the other Network Controller ports. The host is responsible for examining the data file directory, via a "directory file request", and ensuring that all data files are current. After normal communications begin, the host may direct that any data file be sent to a terminal requesting a download, by sending a download directive which contains directory information for the file. A task will run continuously on the Network Controller and will open two types of NPCP "listen" sessions. The first type will simply send "boot type" files to LAN terminals which connect to it. The second session will read a list of files from terminals which connect to it and then attempt to download those files to the terminal. The user is responsible for ensuring that any necessary files are in a defined state on the Network Controller. EXAMPLE TELECOM SESSION--The following example is a step-by-step representation of a host to Network Controller communications session. It is important to remember that any logical sequence of steps will proceed in a "single-file" order on a logical channel, but that steps from different logical channels can be interspersed on the host port. 1. The host opens the communications port to the Network Controller. 2. The Network Controller sends an (optional) identification record to the host. 3. The host sends an initialization record to the Network Controller. The initialization record configures the controller and enables file requests. 4. The controller sends a file request to the host. 5. The host responds by sending an upload directive to the controller to upload the directory file. 6. The controller sends a directory of the data files on disk to the host, followed by the directive status. 7. The controller sends another file request to the host. 8. The host responds by sending a file "load" directive to the controller. 9. The controller determines that the load directive is acceptable, opens the respective file, and sends a data request to the host. 10. The host sends a data record to the controller. 11. The controller sends a data request to the host. 12. Steps 10 and 11 may be repeated any number of times. 13. The host sends an end-of-data record to the controller. 14. The controller closes the file, updates the status of the file in the file directory, and sends a directive status to the host. 15. The controller sends another file request to the host. 16. The host sends an end-of-data record to the controller. 17. The controller sends an activation request for the LAN port and each of the remote ports (ports 2 and 3). 18. The host responds with an auto-answer activation record for the LAN port and port 2, and an auto-dial activation record for port 3. Port 2 is configured to be asynchronous and port 3 is configured to be synchronous. Connection requests are enabled for the LAN port. 20. A connection is established with a remote controller on port 3. 21. The remote controller sends an identification record to the host (via the local controller). 22. The host sends an initialization record to the remote controller, which enables file request processing. 23. The remote controller sends a file request record to the host, and file request processing proceeds as with the local controller. 24. The remote controller sends an activation request, for its LAN port, to the host. 25. The host responds by sending an auto-answer activation record to the remote controller. 26. The remote controller sends an upload data record, from a terminal on its LAN port, to the host. 27. Step 26 can be repeated any number of times. 28. The remote controller sends a download data request to the host. 29. The host responds with an end-of-data record. 30. The remote controller sends a session status record from the terminal to the host. 31. Activity switches to the local LAN, and the local Network Controller sends a connect request record to the host. 32. The host responds with a connect directive to establish a session with a specific terminal. 33. The terminal is located and a directive status is sent to host which indicates that a session is established. 34. The local controller sends an upload data record, from the terminal to the host. 35. Step 34 can be repeated any number of times. 36. The local controller sends a data request record to the host. 37. The host responds by sending a "download file directive" to the controller. 38. The controller opens the specified file, and downloads the entire file from the controller (RAM) disk to the terminal active on the LAN channel. 39. The controller sends a "directive status" record to the host to indicate that the file was downloaded successfully. 40. The controller sends the next data request record, for the channel, to the host. 41. The host responds by sending a download data record. 42. Steps 40 and 41 or steps 40, 37, 38 and 39 may be repeated any number of times, until the host sends an end-of-data record. 43. The host sends an end-of-data record for the channel. 44. The controller sends an end-of-session record, from the terminal active on the channel, to the host. 45. The controller sends another connection request to the host. 46. The host responds by sending an end-of-data record to the controller. 47. The controller randomly establishes a session with another terminal on the LAN. 48. A communications session proceeds on the channel as in steps 34 through 44. 49. The controller determines that no terminals are available on the remote auto-dial port (port 3), deactivates the port and sends an activation request record, for the port, to the host. The activation request contains a status field which indicates why the port was deactivated. 50. The host responds by sending an auto-answer activation record to the controller, which re-configures port 3 as an auto-answer, asynchronous port. The port is now capable of answering calls from single 4300/4400 terminals (not in a LAN) and existing TTY devices. 51. The controller receives an upload data record from a 4300/4400 terminal on port 2. 52. The controller transfers the data to a host channel and sends the data on to the host. 53. Steps 51 and 52 may be repeated any number of times until the 4300/4400 has finished uploading data. 54. The controller sends a download data request, for the 4300/4400 terminal, to the host. 55. The host responds by sending a data record. 56. Steps 55 and 56 may be repeated 0 or more times. 57. The host sends an end-of-data record for the 4300/4400 terminal. 58. The controller sends the end-of-session record from the terminal to the host. Once set, activation parameters remain in effect until they are specifically reset. Default activation parameters are contained in a configuration file on the controller's disk. Enabling connection requests will probably be the exception, rather than the norm. If connection requests are not enabled, connection requests will not be generated and terminal sessions will be established in a way similar to that used in Norand's existing protocol converters (e.g. The controller will accept upload data from any terminal, and pass the data on to the host. The host will use information in the upload data to associate download data with the terminal) Description of FIG. 31 FIG. 31 illustrates exemplary logic for component 600, FIG. 30A. Inputs PCS0 and PCS1 are identified at 601 and 602 in FIG. 31, and corresponding inputs are apparent in FIG. 30A, which emanate from bus 604. Input DCDRQ designated 606 in FIG. 31 will be seen to originate at the disk drive controller 573, FIG. 30A. Inputs 611, 612 and 613 of FIG. 31, designated DRQB, DBQC, DBQD, are apparent at the right of component 600, FIG. 30A. Output signal lines 615 and 616, FIG. 31, are shown to be connected to the microcomputer 500, FIG. 30A. Outputs 621 and 622, FIG. 31, are seen in FIGS. 30A and 30B to be associated with bus 624 and to lead to the respective serial communications controllers SCC1 and SCC2, FIG. 30B. Input 626, FIG. 31, is seen in FIGS. 30B and 30A to originate at serial controller SCC1. Description of FIGS. 32A and 32B FIGS. 32A and 32B show a preferred implementation of the auxiliary power unit (APU) shown at 421 in FIG. 28, and an earlier implementation being shown in FIG. 29. In accordance with the present invention, the auxiliary power unit of FIGS. 32A and 32B enables the expansion of the LAN system beyond the initial twenty-four docking units. The device provides power for an additional twenty-four hand-held computer terminals, so that the batteries may be recharged during the communication process. The APU circuitry of FIGS. 32A and 32B also provides for a bi-directional repeater for the RS-485 communication signals. A commercially available LAN configuration can be expanded to a maximum of seventy-two docking units utilizing one network controller 400, FIG. 28, twelve multi-dock systems such as illustrated in FIGS. 23-27 and two auxiliary power units as represented in FIGS. 32A, 32B. The connector arrangement as shown at 450, FIG. 21, on the back panel of the network controller and corresponding connectors at the back of the APU unit 421, FIG. 28, simplify the configuration of systems and allow flexibility in routing of external interconnecting cables. The APU circuitry of FIGS. 32A and 32B is unique because the repeater circuit is bi-directional and does not require an external signal to determine the direction of data (such as provided by direction control line 431, FIG. 29). An energy detection circuit comprised of components 32-U6A and 32-U6B, FIG. 32B, automatically determines which side of the repeater circuitry of FIG. 32A is receiving the data, and enables the repeater circuit for that direction. The enable control lines are indicated at 633, 634, FIGS. 32A, 32B. At that time, the repeater circuit for the opposite direction is disabled. Once data activity stops, both repeater circuits are disabled. The energy detect circuit of FIG. 32B then monitors both sides of the APU repeater circuit for data activity and reactivates one or the other of the two repeaters as required. By way of example, the respective components of FIGS. 32A and 32B may be of the following types:
______________________________________
32-U6A, 32-U6B, FIG. 32B
Multivibrator
e.g. 74HC123
32-U2, FIG. 32A Bus Repeater
e.g. Type 75178B
32-U3, 32-U4, 32-U5, FIG. 32A
Bus Repeater
e.g. Type 75177B
32-REG1, FIG. 32B Regulator
e.g. LM317T
______________________________________
Description of FIG. 33 FIG. 33 illustrates the circuitry for the RS232 interface components 560 for ports B, C and D of FIG. 30B. FIG. 33 specifically shows the interface for port D wherein the signal CLKSELD shown at input 650 at the left in FIG. 33 originates from a latch 651, FIG. 30A, and is transmitted via bus 652, FIGS. 30A and 30B. Component 654, FIG. 33, may be a driver/receiver, for example MAX 235. Description of FIGS. 34A, 34B and 34C In FIGS. 34B and 34C, the RS232 interface component for port A, FIG. 30B, is indicated at 660 and corresponds with the other interface components such as 654, FIG. 33. Thus, bus 652, FIGS. 30A and 30B, supplies the signal CLKSELA at input 662, FIG. 34A. Port select component 664, FIG. 30B, may be implemented as shown at 666 and 667 in FIG. 34A, these components being quad multiplexors, e.g. type 74HC157. The 485SEL signal for input 670, FIG. 34A, originates at latch 651, FIG. 30A, and is transmitted by bus 652. The RS485 interface component 570, FIG. 30B, may be implemented as indicated at 675, FIG. 34B, and component 675 may be a differential bus transceiver, e.g. type 96176. Description of FIGS. 35A and 35B FIGS. 35A and 35B illustrate an exemplary implementation of the power supply components 581 and 582, FIG. 30B. The input at line 680, FIG. 35A, may be between 13 volts DC and 20 volts DC and the output 681, FIG. 35A, may supply plus twelve volts to the disk drive component, while output 682 may supply plus five volts. By way of example, component 690, FIG. 35B, may be a plus modulator, e.g. type UC494AC. By way of example, the plus twelve volt output at 681 may be supplied by a regulator component 692, e.g. a voltage regulator type UA7812UC. Description of FIGS. 36A, 36B and 36C By way of example RAM controller 700, FIG. 30A, may be implemented as shown at 701, 702, FIG. 36B. Coupling of these components to address bus 710 is indicated in FIG. 36A. FIG. 36C shows a regulator 36-REG1, e.g. type LM317LZ, which is coupled via line 712, FIGS. 36C, 36B, with a plus three volt regulator 36-REG2, e.g. type 581230. The input to components 701, 702 such as VBB1, VBB2 and plus five volts (+5V) have suitable banks of capacitors associated therewith and the same is true of other voltage inputs throughout the preferred embodiment of a network controller. The showing of these capacitor banks has been omitted since this is a matter of routine for those skilled in the art. FIG. 36C also shows a RAM chip select signal at 714 (RAMCS). Other connections between FIGS. 36C and 36B are indicated at 716 and 718. Description of Exemplary Microprocessor And Related Circuits (FIGS. 37A-36F) In FIG. 37A, the address bus 710 on a complete sheet of engineering drawings would be shown as leading to the sixteen bit inputs (A1-A16) of two EPROM chips (each 64 K.times.8, e.g. 27C512). Such circuitry for implementing component 800, FIG. 30A, is a matter of routine for one skilled in the art, and need not be further described. The data from the EPROM 800 (e.g. D0-D7) is supplied to bus 801 (e.g. as signals DB0-DB7 and AD8-AD15). The RAM component 810, FIG. 30A, may be implemented as twenty-four CMOS SRAM chips, 32K.times.8, e.g. PD43256C. Address bus 710 would supply inputs (e.g. A1-A15), while components 701, 702, FIG. 36B would provide respective select signals (e.g. RCE0, RCE23). A further description of an implementation of component 810 is unnecessary since such circuitry is well within the routine skill of the art. In FIG. 37A, the control and data bus 820 is shown which is associated with outputs (AD8-AD15) of the EPROM chips implementing component 820. For convenience of compact illustration of the circuitry, this bus 820 is shown offset to the right in FIG. 37D. FIG. 37D also shows a bus part 820A offset to the right from the corresponding bus part 820A of FIG. 37. Otherwise, vertical lines of FIG. 37D are in alignment with the corresponding vertical lines (i.e. 831, 832) in FIG. 37A. Horizontal lines 841-852 in FIGS. 37A and 37B are in horizontal alignment and have been numbered for convenience of correlation of these figures. In an actual engineering drawing, a vertical bus segment 820B is shown by the same vertical lines. Thus segments 820C in FIGS. 37C and 37B are identical segments (rather than being connected between the figures). This same procedure has been followed with respect to bus segments 820D, 820E in FIGS. 37E and 37F. Thus, in an actual engineering drawing the lines of bus segment 820B, FIGS. 37B and 37C, would be in direct alignment with and would connect with the two lines of bus segment 820D, FIGS. 37E and 37F, and bus segment 820E of FIG. 37F would be superimposed on and part of bus segment 820E of FIG. 37E. Horizontal line 861 has been numbered in FIGS. 37B and 37C to assist in correlating these figures. Horizontal line 862 has been numbered in FIGS. 37A and 37E, and the horizontal bus segments 870 have been designated at the bottom of FIG. 37A and near the top of FIG. 37E. Bus segment 880 has been labeled as a vertical segment in FIG. 37B and as a horizontal segment in FIG. 37E, these segments being in alignment in the present patent drawings. Vertical bus segments 820G have been designated in FIGS. 37B and 37E since these segments are in vertical alignment in the patent drawings. Horizontal lines 881 through 886 have been designated in FIGS. 37E and 37F to assist in associating these figures. Exemplary components for the circuitry of FIGS. 37A through 37F is as follows:
______________________________________
37-U42, FIG. 37A Buffer,
e.g. 74HC241
37-U28, FIG. 37A D-Type Positive-
Edge-Triggered
Flip-Flop
37-U5, FIG. 37B Microprocessor,
e.g. Type 80C186
37-U6, 37-U7, 37-U8, FIG. 37C
Octal Latch,
e.g. 75HC573
37-U30 JK Flip-Flip,
e.g. Type 74HC112
37-U38, FIG. 37E CMOS Clock,
e.g. Type MC146818P
37-U26 Programmable Logic
"LANPAL"
(Type PALC22V10H)
37-U32, 37-U27 Bus Transceiver,
e.g. 74HC245
______________________________________
Description of FIGS. 38A-38E In order to assist in correlation of FIGS. 30A, 30B with the exemplary implementation of FIGS. 38A-38E, the communications bus has been designated 624 in the detailed implementation. FIG. 38A shows components 901 and 902 for implementing serial communications controller chips SCC1 and SCC2. The address bus has been designated 710 in FIGS. 30A, 30B and FIGS. 38A, 38B and 38E. Data bus 607, FIGS. 38A and 30B, has been designated with the same reference numeral in FIGS. 38A, 38B and 38E. The vertical line between FIGS. 38A and 38C has been designated 905, and the horizontal lines between FIGS. 38C and 38D have been designated 911-920. The horizontal lines between FIGS. 38D and 38E have been designated 921-928. Component 930, FIG. 38B, may represent an implementation of the keyboard interface 572, FIG. 30A. Component 940, FIG. 38E, may represent a detailed circuit for disk drive controller 573. Exemplary type numbers for the major components in FIGS. 38A, 38B and 38E are as follows:
______________________________________
Components 901, 902, FIG. 38A
Serial Communica-
tions Controller,
e.g. Type 85C30
38-U24, FIG. 38B Octal Latch,
e.g. Type 74HC573
930, FIG. 38B CMOS Keyboard
Encoder,
e.g. Type 74C923
940, FIG. 38E Controller,
e.g. Type 82072
______________________________________
Description of FIG. 39 FIG. 39 illustrates components corresponding to those of FIG. 29 but discloses the conception of utilizing energy detect circuits 951 and 952 for eliminating the need for the direction control line 431, FIG. 29. An exemplary detailed implementation of the teachings of FIG. 39 has been shown in FIGS. 32A and 32B, and reference is made to the section headed "Description of FIGS. 32A and 32B" for further discussion of this development. Description of FIG. 40 FIG. 40 is an extension of the system of FIG. 28, and illustrates how the system may be progressively expanded with the use of auxiliary power units such as 961 and 962, for example to include one or more further multidock units such as those indicated at 971-974 and 981-984. This will serve to illustrate the manner in which the auxiliary power units of FIGS. 29, 32A, 32B and 39 may be utilized to chain further multidock units beyond the power supply capacity of the LAN controller 400. In this example an auxiliary power unit such as 961 is connected to a connector such as indicated at 312 in FIG. 25 (where connector 311 is closer in the chain to the primary LAN channel 425 of LAN controller 400). Similarly, an auxiliary power unit might be added as indicated in dash outline at 985 after multidock 974 in the primary chain, whereupon four more multidock arrangements such as that of FIGS. 6, 7, 8, 10, 11 and 23-27 could be added as needed. As indicated in FIG. 40, with the addition of an auxiliary power unit 962 in the secondary channel 426, up to four multidock units for example, may be added in a secondary chain. Description of FIG. 41 For the sake of a specific example, FIG. 41 indicates schematically the conductor paths which may be carried by each of the multidock printed circuit boards such as printed circuit boards 301 and 302 in FIGS. 25 and 26. For the example of three docking receptacles per printed circuit board, each printed circuit board such as 990, FIG. 41, may have three docking receptacle coupling locations 991, 992, 993. For the case of a printed circuit board of a multidock, (e.g. 301, FIG. 25), which is closest to the LAN controller 400, FIGS. 28 and 40, its end connector (e.g. 311, FIG. 25) would be connected to the LAN input terminals 994 of a printed circuit board such as 990, and its connector terminals 995 would receive one end of a flex cable such as 303, FIG. 25. Where the printed circuit board was to be located in a multidock more remote from the LAN controller 400, (e.g. printed circuit board 302, FIG. 25), the other set of terminals 996 would receive the end of a flex cable such as 303, FIG. 25, and the LAN output terminals 997 would be connected to the pin positions of an adjacent end connector, (e.g. connector 312, FIG. 25). The LAN input and output terminals 994 and 997 may be designated as follows:
______________________________________
Terminal Designation
Number(s) (FIG. 41)
______________________________________
1 CHG
2 +485
3 -485
4 CHG
5 DIR
6-11 GND
12-15 CHG
16 SPARE
______________________________________
The terminals 995 and 996 would then have the following designations in FIG. 41:
______________________________________
Terminal
Number(s) Designation
______________________________________
1-4 CHG
5-8 GND
9 +485
10 -485
11 DIR
12 SPARE
______________________________________
By way of example, the following tables will explain the interconnections of FIG. 40, having reference to the LAN controller example of FIGS. 34A, 34B, 34C, the auxiliary power unit of FIGS. 32A, 32B, and the multidock printed circuit board terminal designations of FIG. 41. Table A shows the connections between controller 400, FIG. 40, and multidock 411, for example. Table B shows the connections between multidock 987, FIG. 40, and auxiliary power unit 961, for example. Table C shows the connections between auxiliary power unit 961, FIG. 40, and multidock 971. Table D shows the connections between the secondary channel of LAN controller 400, FIG. 40, and the auxiliary power unit 962.
TABLE A
______________________________________
Connections Between
400 and 411, FIG. 40
LAN CONTROLLER MULTI-
Primary Channel DOCK LAN
Output (FIG. 34C) INPUT
Terminal Designation
Designation
Number (FIG. 34C)
(FIG. 41)
______________________________________
1 +15 V CHG
2 +485 +485
3 -485 -485
4 +15 V CHG
5 DIR DIR
6 -- --
7 GND GND
8 GND GND
9 -- --
______________________________________
Of course, with the auxiliary power units of FIGS. 32A, 32B and 39, the conductors on the printed circuit board 990 labeled "DIR" would be unused, and would be omitted. A unique feature resides in the construction of multiple ports of a local area network as shown in FIGS. 25, 26 and 41, whereby ports 991, 992, 993, for example, are coupled to rigid conductive signal pathways such as "+485", "-485" in FIG. 41 formed directly on rigid printed circuit boards such as 302, 302, FIGS. 25 and 26. Such rigid pathways may be associated with LAN inputs such as 994 or 996 and LAN outputs such as 995 or 997, and extend continuously therebetween. Instead of separate rigid printed circuit boards 301 and 302 constructed as shown in FIG. 41, a single rigid printed circuit board may be used per multidock, in which case, there might be six coupling locations such as 991, 992, 993, per unitary printed circuit board, and the terminals such as 995 and 996 and any associated extra pathways could be omitted. In FIGS. 25, 26 and 41, rigid power pathways "CHG" and "GND" traverse each printed circuit board from end to end e.g. for the case of two boards per multidock, from 994 to 995, or from 996 to 997, and e.g. for the case of a single unitary rigid printed circuit board per multidock, from LAN input 994 to LAN output 997. Summary With Respect to FIGS. 31-41 With the foregoing description, and the detailed circuitry shown in FIGS. 31 through 38E, a preferred embodiment of the circuitry for implementing FIGS. 28, 30A, 30B, 39 and 40 will readily be understood by those skilled in the art. Of prime importance is the preferred implementation for the auxiliary power unit as described with reference to FIG. 39, the flexibility of expansion of the docking capacity as shown in FIG. 40, and the LAN multiport arrangement of FIG. 41. Description of FIGS. 42 and 43 FIG. 42 is a plan view of the solder side of a printed circuit board such as 301 or 302 and thus corresponds with FIG. 26 except that conductive paths are physically shown. FIG. 43 shows the opposite side of the printed circuit board from FIG. 42, and the electrical connections shown conceptually in FIG. 41, are shown as physical conductive paths in FIGS. 42 and 43. In order to assist in correlating FIGS. 42 and 43 with FIG. 41, reference numerals 990 through 993, 995 and 996 from FIG. 41 have been applied in FIGS. 42 and 43. The connectors such as 311 and 312, FIGS. 25 and 26, are coupled to the conductive paths on the printed circuit board via hole patterns 1021 and 1022, FIGS. 42 and 43. In an actual embodiment, each socket of connector 311 is connected with a respective hole of a pattern such as pattern 1021 by a wire which extends axially of the socket at one end and curves through ninety degrees so that its opposite end extends axially through a hole of the pattern and is soldered in place. Thus hole pattern 1021 represents potential LAN input terminal positions to be coupled with an input connector such as 311, and hole pattern 1022 may serve as LAN output terminal positions to be coupled with an output connector such as 312, FIG. 25. The corresponding hole patterns in FIG. 26 have been designated 1021A, 1021B and 1022A, 1022B to assist in correlating the figures. The network conductive data paths between terminals of the end connectors 996 and 995 may be traced as follows: network terminal 996-1, FIG. 43, copper strip sections 1031, 1032, FIG. 43, through hole 1033, FIGS. 42 and 43, copper strip 1034, FIG. 42, through hole 1035, copper strip 1036, network terminal 995-1: and network terminal 996-2, FIG. 43, copper strip 1041, through hole 1042, copper strip 1043, FIG. 42, through hole 1044, copper strip 1045, FIG. 43, and network terminal 995-2. The various branch data paths to contact sets 991-993 may be traced as follows: from network terminal 996-1 and network data path segment 1034, FIG. 42: branch path 1051, FIG. 42, and contact 991-1; branch path 1052, FIG. 42, and contact 992-1: and branch path 1053, FIG. 42, and contact 993-1. From network terminal 996-2 and network data path segment 1043: direct engagement with contact 991-2, FIG. 42 From network terminal 996-2 and network path segment 1045, FIG. 43: through hole 1061, branch path 1062, and contact 992-2 through hole 1063, branch path 1064, and contact 993-2 The branch data paths to the hole patterns 1021 and 1022 are as follows: From network data terminal 996-1 and network data path segment 1031, FIG. 43: branch data path 1071, FIG. 43, to hold position 1021-1. From network data terminal 996-1 and network data path segment 1034, FIG. 42: branch data segment path 1072, FIG. 42, through hole 1073, branch data path segment 1074, FIG. 43, to hole position 1022-1. From network data terminal 996-2 and network data path segment 1045, FIG. 43: branch data path segment 1081, FIG. 43, to hole position 1021-2: and branch data path segment 1082, FIG. 43, to hole position 1022-2 The network power supply paths between connector positions 996-3 (CHG) and 996-4 (GND) and positions 995-3 and 995-4, respectively, are via network power supply paths 1091, FIG. 43, and 1092, FIG. 42. Branch power supply paths from network path 1091 to the various contacts such as 991-3 are via through holes 1093, 1094 and 1095. Branch power supply paths from network path 1092 are apparent at 1096 and 1097, FIG. 42, for the leftmost contact of set 991 and for the middle two holes of the four-hole row of hole pattern 1021. Corresponding power supply branch paths for contact sets 992 and 993 and for hole pattern 1022 are apparent in FIG. 42. A network direction control pathway is indicated at 1098, FIG. 42, and may be coupled with branch paths such as 1099 (at the right in FIG. 43), when required, e.g. via through holes such as 1101 and 1102. Discussion Re Claimed Subject Matter FIG. 23 shows a series of docking receptacles 101-106 which are shown in greater detail in FIG. 7. Preferred details of each docking receptacle will be understood from the description of FIGS. 1-6, for example. The docking receptacles have respective sets of docking terminals which are engaged with contact means 471-476, FIG. 26, of the printed circuit boards 301, 302, FIGS. 25-27. The docking terminals may be formed by spring fingers 470, FIG. 27, which include protrusions 998, FIG. 27, for engaging the respective contact means 471-476, FIG. 26. Protrusions 998 correspond with protrusion 63, FIG. 3, and contact mounting block 999, FIG. 27, may be identical to contact block 70, FIG. 3. Thus, the docking connectors 461-466, FIG. 25, may each correspond identically with the connector assembly of FIG. 3, and may be associated with a respective docking receptacle 101-106, FIG. 23, as shown in detail in FIG. 5. Referring to FIG. 41, the sets of docking terminals at coupling locations 991, 992 and 993 may comprise data coupling terminals as represented at +485 and -485 in FIG. 41. Thus for an array of contact regions such as shown at 64 in FIG. 3, the third contact region from each end may provide a data coupling terminal. In a specific implementation, these terminal positions +485 and -485 may connect with correspondingly located external contacts 80 in FIG. 2, and such contact pads 80 (i.e. the third and tenth such contact pads 80 in FIG. 2) may be connected with the data lines of the third figure of the incorporated application Ser. No. 07/339,330 (i.e. RS485 DATA+ line ninety-seven and RS485 DATA- line ninety-eight of the incorporated third figure.) The docking terminals such as represented at 991-993, FIG. 41, may further comprise power supply terminals such as CHG and GND, FIG. 41, which may contact the outermost pads 80, FIG. 2. The outermost pads 80 (i.e. contact positions number one and number twelve) may connect with a line designated CHARGE in the third figure of the incorporated application Ser. No. 07/339,330 (line number one hundred seven) and with the power ground of the terminal. Referring to the sixth figure of the incorporated application Ser. No. 07/339,330, the outermost pads 80 may be connected with the CHARGX line (designated forty-three in the incorporated sixth figure) and with the BATT- lines associated with the negative side of the terminal main battery (designated by reference numeral twenty-eight in the incorporated sixth figure). The printed circuit boards of each multidock such as 411, 412, 1007, 987, 971-974 and 981-984, FIG. 40, may correspond with the printed circuit boards 301, 302, FIGS. 25-27. Each such printed circuit board may be configured as represented in FIG. 41, so as to provide continuous strips of electrically conductive material (e.g. copper) extending between respective terminal positions of connectors 994,996 at one end of each board and respective corresponding terminal positions of connectors 995,997 at the opposite end of each board, to provide network conductive path means. The network conductive path means are then coupled with each set of docking terminals via branch conductive path means such as branch data path means represented at 1006, 1007, FIG. 41, and branch power path means 1008, 1009, and which physically may include contacts 471-476, FIG. 26, at the opposite side of boards 301 and 302 from the network conductive strips, and through conductors extending through the boards 301 and 302. In FIGS. 34B and 34C, the lines from terminals A and B of differential bus transceiver component 675 are designated 1011, 1012, and lead to primary channel terminals 1014 and secondary channel terminals 1015, FIG. 34C. The multidock 411, FIG. 40, may have its first printed circuit board (such as 301, FIGS. 25-26) connected with terminals 1014, FIG. 34C, via a connector at position 450, FIG. 21, a suitable cable, and connector 311, FIG. 25. The printed circuit board 301 may then provide rigid conductor network paths as represented in FIG. 41, extending adjacent the sets of docking terminals at 461, 462, 463 from the end adjacent connector 311, FIG. 25, to the end adjacent flex cable 303, FIG. 25. The printed circuit board 302 provides rigid conductor network paths as represented in FIG. 41 from the end adjacent flex cable 303, FIG. 25, to the end adjacent connector 312, FIG. 25. The secondary channel connectors 1015, FIG. 34C, may connect with an auxiliary power unit, e.g. at connector positions 1021, FIG. 32A. A second printed circuit board such as 302 of a multidock such as 987, FIG. 40, may have its connector 312 coupled via a suitable cable with the LAN Input indicated at 1022, FIGS 32A and 32B. The LAN output 1023, FIG. 32A, would then connect with a connector such as 311, FIG. 25, of a multidock such as 971, FIG. 40. The use of equipment such as represented in FIGS. 21, 23-27, 32A, 32B, 34A-34C, 39, 40 and 41, enables a user to progressively increase docking capacity as needed e.g. by extending the network conductive path means with the use of further identical printed circuit boards, and to maintain a neat, orderly and reliable system of interconnections. Any component of the system is readily removed an | ||||||
