US 5,950,133 AGrant

Adaptive Communication Network

Issue Date:1999-09-07

•5 Claims

•90 Drawing Sheets

Abstract

A dynamic and adaptive communication network for monitoring broadcast messages issued by a population of mobile broadcasting devices and for forwarding broadcast messages to a central station is disclosed. The communication network comprises a grid of monitors for receiving and transmitting messages; and a main monitor of the grid in direct communication the central station; wherein each monitor of the grid receives and stores broadcast messages from broadcast devices within range thereof and monitor messages from predetermined selected monitors of the grid; and wherein each monitor transmits stored broadcast messages to a selected monitor of the grid for forwarding to the central station by way of the main monitor and transmits received monitor messages to the selected monitor of the grid for forwarding to either the central station or a designated monitor.

Metadata

Assignee

Lockheed Martin Corporation

Inventor

William Byron Bledsoe

Application Information

Application Number:US 7440898

Filing Date:1996-11-05

Priority Date:1996-11-05

Art Unit:273

Classifications

IPC:

H04L 1226H04Q 734

Field of Search:

45511.1;439;456;457;561

Patent Drawings (90 sheets)

Description

Background of the Invention

1. Field of the Invention

The present invention generally relates to an adaptive communication network for routing digital messages received within an area of the network from any of a plurality of mobile broadcast devices to a central station, and more particularly, to a dynamic and adaptive communication network which automatically routes digital messages from the mobile broadcast devices to the central station along paths that minimizes the saturation of the electromagnetic spectrum.

2. Background Discussion

The increasing use of mobile communication devices such as, for example, cellular phones, mobile computer devices and digital messaging devices, has resulted in a saturation of the electromagnetic spectrum. As a result, the number of mobile communication devices that can be used within a given area is restricted by the available electromagnetic spectrum.

Summary of the Invention

Accordingly, it is an object of the present invention to provide a communication network for routing digital messages received within an area of the network from any of a plurality of mobile broadcast devices to a central station.

It is a further object of the present invention is to provide a dynamic and adaptive communication network which automatically routes digital messages from the mobile broadcast devices to the central station along paths that minimizes the saturation of the electromagnetic spectrum.

These and other objects, advantages and features of the present invention are achieved, according to one embodiment thereof, by a dynamic and adaptive communication network for monitoring broadcast messages issued by a population of mobile broadcasting devices and for forwarding broadcast messages to a central station, the communication network comprising: a grid of monitors for receiving and transmitting messages; and a main monitor of the grid in direct communication the central station; wherein each monitor of the grid receives and stores broadcast messages from broadcast devices within range thereof and monitor messages from predetermined selected monitors of the grid; and wherein each monitor transmits stored broadcast messages to a selected monitor of the grid for forwarding to the central station by way of the main monitor and transmits received monitor messages to the selected monitor of the grid for forwarding to either the central station or a designated monitor.

Provided in each monitor is a section of memory elements for storing such fixed things as: the controlling software, and a unique identity of the monitor. The memory elements also store such dynamically varying quantities as the identity of neighboring monitors with which the monitor can communicate directly; the neighboring monitor selected to provide a two-way communication link to the central station computer via a central monitor (such neighboring monitor being called the output partner); the neighboring monitors that depend on this monitor to provide them a communication link to the central station computer (input partners); and a list of mobile broadcast devices in the vicinity of the monitor, including the digital message last received from such mobile broadcast devices and signal strength of each. Further each monitor is provided with a computer, which, by executing software programs and interfacing with other monitor circuitry such as the transceiver, is able to achieve all functions of the monitor. The software includes the means for generating and interpreting communication messages that allow each monitor to: 1) participate as one member of a network or grid of monitors that can convey, in bucket brigade fashion, messages between each monitor and a central monitor; 2) gather the digital message and signal strength of the signal emitted by a mobile broadcast device in its vicinity; and 3) re-establish a new communication link to the central station computer if the previous link is lost or if a better link becomes available.

The central monitor(s) communicate, for example, by wire, with the central station computer of the adaptive communication network. The overall objective of the monitor network is transfer messages received from mobile broadcast devices to the central station computer of the communication system, to specify which monitors have recently detected a particular mobile broadcast device, and how strong the signal from that mobile broadcast device was (an indication of how close the mobile broadcast device is to a given monitor). The central station computer of the system then makes use of these data as needed by the particular application, and may include more exact calculation of the mobile broadcast device coordinates based upon triangulation computations in cases where coordinates of the monitor locations are known to the central station computer.

Input partners are distinguished from output partners by the fact that the output partner is one step closer to the central station computer than the given monitor whereas the input partners are one step farther from the central station computer than the given monitor. Therefore, messages headed for the central station computer come from input partners and go to output partners, but not all messages fit into that category.

Messages are sent and received from all neighboring monitors. Also, signals are not stored in memory, only received messages are stored. Messages to be transmitted are formulated in real-time to express the dynamically changing information that needs to be conveyed.

Digital messages issued by mobile broadcast devices and received by the monitor directly from mobile broadcast devices within range of the monitor or from input partner monitors are transmitted to the output partner monitor for forwarding to the central station computer of the central station, and monitor messages issued by the central station and received from output monitors are transmitted, if required, to one or more of the input monitors.

Brief Description of the Drawings

FIG. 1 schematically illustrates the various elements of an adaptive communication network according to one embodiment of the present invention;

FIGS. 2A-2C are typical tree structures illustrating the communication modes of the adaptive communication network of the present invention as well as the mobile broadcast device location function of the central station computer of the present invention;

FIG. 3 illustrates the round-robin multi-tasking organization of the monitor software in accordance with one embodiment thereof;

FIGS. 4A-4B are flow diagrams respectively illustrating the four modes of operation for the monitors and the monitor software organization;

FIG. 5 is a flow diagram illustrating the operational steps of the initialization mode of the monitors;

FIG. 6 is a flow diagram illustrating the operational steps of the distress mode of the monitors;

FIGS. 7A-7G are flow diagrams illustrating the operational steps of the normal cycle mode of the monitors;

FIG. 8 is a flow diagram illustrating the central down mode of the monitors;

FIG. 9 is a flow diagram illustrating the listening mode of the monitors;

FIGS. 10A-10G are flow diagrams illustrating monitor code processing;

FIGS. 11A-11G are flow diagrams illustrating the monitor transmit arrangement;

FIGS. 12A-12C are flow diagrams illustrating the software organization of the central station computer;

FIGS. 13A-13C illustrate the normal cycle mode of the central station computer;

FIG. 14 illustrates the listen mode of the central station computer;

FIGS. 15A-15F illustrate the code processing arrangement of the central station computer;

FIGS. 16A-16E illustrate the transmit mode of the central station computer;

FIG. 17 illustrates flags (parameters) and their meaning;

FIG. 18 illustrates message code meaning;

FIG. 19 provides details about T1 (neighbor list);

FIG. 20 illustrates T2 which is the input partner list;

FIG. 21 illustrates T3 which is the tag table;

FIG. 22 illustrates Monitor T4 which contains the "residual" code14 data;

FIG. 23 illustrates Central T3 which is the actual mobile broadcast device location data maintained by the central station computer;

FIG. 24 illustrates Central T4 which, in the central station computer software, makes up the monitor tree structure;

FIG. 25 illustrates the construction and contents of every type of transmitted message; and

FIGS. 26A-27Q are circuit diagrams illustrating the circuitry of the monitor according to one embodiment of the present invention.

Detailed Description of the Preferred Embodiment(s)

Adaptive Communication Network--General Description

Referring to FIG. 1, the adaptive communication network of the present invention, generally indicated at 11, comprises three basic components: at least one mobile broadcast device 13, a network of monitors 15, positioned at the area to be monitored, and a central station computer 17, in communication with the network of monitors 15. The network of monitors 15 are of sufficient number and distribution as to achieve coverage of an entire area of interest and to achieve the desired degree of location accuracy.

According to one embodiment of the present invention, the preferred communication mode between each of the components of the adaptive communication network 11 is wireless, i.e., using electromagnetic or radiant energy. However, the communication link 16 between the central station computer 17 and the monitor which reports directly to the central station computer 17 (such monitor hereinafter being referred to as the central monitor 15A) is preferably a hardwire communication link, such as, for example, a coaxial (RS232) cable.

In operation, the mobile broadcast device 13 transmits a digital message and one or more of the plurality of monitors 15 detects such digital message transmissions which are issued from the mobile broadcast device 13 in order to determine the current location of the mobile broadcast device 13 and forward a digital message therefrom to the central station as will be more fully described hereinafter. The central station computer 17 collects the digital messages and the mobile broadcast device locations from the network of monitors 15, controls the communication links between the monitors 15, interfaces with a user which operates and monitors the network, and interfaces, for example, with a telephone system or other communication networks including, but not limited to computer networks, satellite communication networks and the like.

The monitors 15 can be arranged within the space to be monitored in a grid-like pattern or even in a random manner. In this regard, the configuration requirements for the monitors 15 include: 1) all monitors 15 in the network must be within communication range of at least one other monitor 15, 2) at least one monitor 15 in the network must be within range of the central station computer 17, and 3) all monitors 15 must be linked to the central station computer 17 either directly or indirectly through other monitors 15 of the network.

More specifically, each mobile broadcast device 13 transmits a radio signal 21 that is modulated with a signal containing the identify of the mobile broadcast device and a digital message to be forwarded to the central station computer 17. By demodulating the received radio signals 21, each monitor 15 of the network is able to determine the identity of those mobile broadcast devices 13 which are within the receiving range of that particular monitor 15.

The radiation level of a radio signal 21 of a particular mobile broadcast device 13 is also chosen low enough that the radio signal 21 of that particular mobile broadcast device 13 will only be received by those monitors 15 which are closest to that mobile broadcast device. The preferred range of the radio signal 21 is therefore dependent on the spacing of the monitors 15.

Many radio receivers in the marketplace provide a dc received signal strength indicator (RSSI) signal that could be measured by an analog to digital converter on the monitor. In this particular embodiment, the signal strength is instead determined in the software by measuring the change in width of the average narrow pulse entering U8 on the RDATA signal line. The pulses become more narrow as the signal strength decreases. The relationship of pulse width to distance is determined experimentally and stored either in the monitor or central station computer memory to convert from signal strength to distance.

Each individual monitor 15 can get a rough idea of how far away a particular mobile broadcast device 13 is by the strength of the received radio signal 21. By calculating the distance of a mobile broadcast device from three or more monitors, the central station computer 17 can determine, by triangulation, the approximate location of each mobile broadcast device 13.

Even if the mobile broadcast device is only "heard" by one monitor 15, the mobile broadcast device's location is then known to be within the general vicinity of that particular lone receiving monitor 15. Therefore, mobile broadcast devices 13 can move anywhere within the area covered by the system 11 and their location can still be tracked by the central station computer 17 as long as the mobile broadcast device 13 is within range of at least one monitor 15.

According to one embodiment of the present invention, the central station computer 17 must know the precise location of each monitor of the network of monitors 15 in the form of X & Y coordinates in order to pin-point the location of mobile broadcast devices 13. When any one or more of the monitors 15 are moved, the network 11 is adapted to automatically adjust itself providing that the moved or new monitor 15 is in range of at least three other monitors 15 that have valid X & Y coordinates; the only user requirement is that the monitor's reset button be pressed, as will be more fully described hereinafter. The user may also be prompted by the central station computer 17 to enter specific monitor location information.

The mobile broadcast devices 13 and monitors 15 don't have to be associated with a precise X & Y coordinate location in alternative embodiments of the present invention where just knowing which monitor 15 has detected a signal 21 from a particular mobile broadcast device 13 may be enough information. In such cases the user may be prompted for an area name instead of coordinates. If the monitor id will suffice as location data, the user prompt for location can be disabled.

The Monitor Network--Communication Requirements

All mobile broadcast device data is forwarded to central station computer 17 by the monitors 15 so that the flow of information forms a tree structure as best seen in FIG. 2A. All links shown are wireless except for the wired link 16 between the central computer 17 and the central monitor 15A. Mobile broadcast devices are not shown in FIG. 2A.

As a system requirement, each monitor 15 is required to be in communication range of at least one other monitor 15, but in most cases it will be in range of more than one other monitor 15, for example, from 2 to 10 other monitors 15. All monitors 15 that are within a given monitor's range are called its "neighbors". In FIG. 2A, monitors A, D, and E are the neighbors of monitor C; therefore they would be included in monitor C's T1 (neighbor list) as is best understood with quick reference to FIG. 19 which provides details about T1 (neighbor list). For a more complete understanding of T1 (neighbor list) please refer to the Descriptions of Tables Found in Monitors, found below.

These neighboring monitors can be classified as input partners (ip's), output partner (op), or neither. Each monitor 15 has to have one (and only one) op in order to forward data to the central station computer 17. In FIG. 2A, the op of monitor C is monitor A. Each monitor can have none or more ip's. For example, in FIG. 2A, monitor B has two ip's: D and F. Typically, one monitor (the central monitor 15A) in the network will have the central station computer 17 as its op. The central station computer 17 dictates how the tree is configured based on information received from the network of monitors 15.

Monitor-to-monitor and monitor-to-central computer communication can occur in two ways: 1) broadcast with acknowledges, i.e., one monitor sends out a broadcast and multiple monitors send back acknowledges (code2's) in a time-staggered manner; all broadcast type messages (except code 16's) are sent from an op to its ip(s), or 2) single destination with acknowledge, i.e., one monitor sends a message to another monitor who sends back an acknowledge. Mobile broadcast device-to-monitor communications consist only of code01 broadcasts from the mobile broadcast devices to the monitors. (Note: Refer to FIG. 18 for code meanings and to FIG. 25 for the content of each message type, i.e., code.)

When a monitor sends a message and the destination monitor does not send back an acknowledge, the monitor will retransmit the message. If the destination monitor continually fails to send back an acknowledge, the monitor will stop trying to send the message. Depending on the situation, this could trigger other events. In FIG. 2B for example, monitor G would notify the central station computer 17 of the communication failure with monitor C. Monitor C would go into distress mode (to be discussed later).

Monitor Software Organization

The following software discussion makes many references to message codes, tables, parameters, and flags. Before proceeding with the discussion, it is appropriate to become somewhat familiar with the messages, tables and parameters, and to make frequent reference to their descriptions as one proceeds through the remaining text.

FIGS. 18 and 25 show the meanings and contents of the various messages, and FIG. 17 shows the meanings of the flags and parameters. The tables and their content are shown in FIGS. 19 through 24 and are described in the following discussion below.

Descriptions of Tables Found in Monitors

T1 List of neighboring monitor addresses. For each entry, the monitor information is recorded in this order: monitor ID, retry count, code 9 inhibit flag, time flag, and signal strength.

T2 List of IP addresses (1 byte each) followed by a status byte which contains: a 2 bit count indicating whether that IP has reported in the last 2 cycles, a flag which indicates whether that IP has sent all of its mobile broadcast device data for the current cycle; and a flag which indicates whether or not an acknowledge of a code0 is expected from this IP.

T3 Table of mobile broadcast devices (also referred to as T12)--consists of mobile broadcast device ID's, digital message to be forwarded to the central station computer, signal strength, and status byte. The LSB of the status byte is the new flag which indicates that the mobile broadcast device is new to area or the signal strength has changed drastically. If the new flag is set then the mobile broadcast device should be included in an outgoing code 14. The next 2 bytes are used for a count which is decremented once per cycle. Every time the mobile broadcast device is detected, this count is set to 3. If this count is ever decremented all the way to zero, it should be removed from the table by the mobile broadcast device processing routine.

T4 (also referred to as T16) This table contains data from incoming partial code 14's. Each entry begins with a monitor ID which is followed by a mobile broadcast device count and a list of mobile broadcast device ID's. If another short code 14 is encountered, it should be combined with data from one of these entries. If a message of optimum length can be constructed from the partial code 14 that has just been received and an entry from t16, the two should be combined and placed in the transmit queue; the associated entry in t16 should be erased.

T5 (also referred to as T17) This is a buffer used to store a code 9 message sent to us from our OP.

T15 Distress queue--Temporary storage of xmit messages to OP while in distress mode.

FIG. 3 illustrates the round-robin multi-tasking organization of the monitor software. Task1 (main) includes the higher level functions of the monitor software as will be more fully discussed hereinafter with particular reference to FIG. 4A. Task2 is a foreground task which allows user some diagnostic functions. In the central monitor 15A, task2 also is used to process mobile broadcast device related messages sent to it from central (ie, codes 2, 0a, 15, and 19). Task3 processes the data stream received from the RF antenna and puts any viable messages in the receive queue.

Referring to FIG. 4B, Taskswap is commonly used by many other routines so it is shown here for ease of reference. Taskswap is a misnomer caused by design changes; task-swapping is actually handled by interrupts. Taskswap does temporarily turn off multi-tasking to prevent corruption of shared resources used by listen and transmit.

Taskswap is used by distress, normalcycle, and central down as described below.

The function of taskswap is to allow any messages in the receive or transmit queues to be processed until both those queues are empty and the transmit state (p22) is zero. The transmit state is zero when a monitor 15 is not engaged in a communication session with another monitor 15. A session includes any and all messages between multiple monitors 15 necessary to make up a logical transfer of information.

In general, when taskswap is called, it will execute until the airwaves in a monitor's vicinity become quiet and all of that monitor's sessions have ended.

Monitor Operation Modes

Referring to FIG. 4A, there are four modes of operation for the monitors 15: 1) initialization (entered on power up or reset), 2) distress (involves communication failure with op), 3) normalcycle (mobile broadcast device data forwarding mode), and 4) central down (central computer failure).

When a monitor 15 is initially installed in the network 11, the monitor 15 will go from the initialization mode to the distress mode to the normal mode. From the normal mode, the monitor 15 is adapted to go to either central down or distress. From central down, the monitor 15 is adapted to go only to normal. From distress, the monitor 15 is adapted to enter either normal or central down. The only way a monitor 15 can go to initialization is by being reset.

Initialization Mode

Referring to FIG. 5, upon power up or reset, the initialization mode is entered. Monitor initialization (Main state 0) performs the following key functions: 1) turns on system clock (real time interrupts); 2) initializes (empties) tables and queues; 3) puts code16 (distress msg) in xmit queue; 4) puts code1c (reset msg) in distress queue; and 5) causes main to go into distress mode.

In the initialization mode, all low level initialization as well as the clearing of system parameters and data structures takes place. Also a code16 (distress broadcast signal) is put into the transmit queue of the monitor and a code1c (reset signal) is put into the distress queue (for later transmission). Now the monitor 15 enters the distress mode.

Distress Mode

FIG. 6 is a flow diagram illustrating the operational steps of the distress mode (Main state 1). The purpose of the distress mode is to handle situations in which a monitor 15 has no way of forwarding its data or its descendants' data to the central station computer 17. Descendants of a monitor 15 include all the monitors who's data must travel through it in order to reach central. This includes the monitor's ip's, their ip's, and so on. In FIG. 2A, for example, monitors D, F, and G are all descendants of monitor B.

A monitor 15 in distress mode lets the central station computer 17 know of its situation by sending it a distress signal. The distress signal is sent to the central computer via the other monitors that are in the vicinity of the monitor that is in distress mode. There are two types of distress signals: a code9 (partnership request) and a code16 (distress broadcast). The code9 is sent to a single destination while the code16 is a broadcast type message.

There is a code9 inhibit flag associated with each neighboring monitor listed in a monitor's T1 (neighbor list). A cleared code9 inhibit flag indicates that the associated neighbor is a candidate for sending a code9 to. In response, the central computer is programmed to determine which monitor would be the best op for the monitor in distress. Then the central computer sends a code0a (partnership grant) to the distressed monitor via the proposed op.

There are 3 "sub-modes" within the distress mode. When a code9 (partnership request) is sent from an op to its ip, the ip enters Dist1. Dist2 is entered if communication with op has failed and the op happened to be central; this can only happen for central monitor. Dist3 is entered in all other cases when a monitor loses communication with its op.

Dist1 is a special case of distress mode in that it may allow the monitor to return to normalcycle without getting a new partnership grant. An op will only send a code9 to an ip if the op has unsuccessfully attempted to obtain a partnership grant by sending code9's to all of its non-ip neighbors first.

Referring to FIG. 2B, the monitor who's perspective is being described (monitor who received a code9 from op) will be monitor A. Monitor C (op of monitor A) has gone into distress because it lost communication with its op (monitor G). The type of distress which monitor C is in is dist3. Monitor C first sends a code9 to the first non-ip monitor (monitor F) in its T1. If a timeout condition occurs with no partnership grant occurring, monitor C will set the code9 inhibit flag for that tried monitor and monitor C will send a code9 to its next non-ip neighbor listed in T1 which would be monitor E.

So far the code9's that have been issued contain lists of neighboring id's excluding the op and ip's. When another timeout occurs with no partnership grant occurring, monitor C will start sending code9's to ip's. (This is assuming all non-ip monitors have been tried.) This is how we get to a situation where a code9 is received by an ip (monitor A) from an op (monitor C). The code9 will contain a complete listing of all monitors from monitor C's neighbor list.

Upon receipt, monitor A will set the code9 inhibit flags in its neighbor list for all monitors whose id's are also found in the code9 list and then it will enter dist1 of distress mode. The setting of these flags prevents monitor A from sending code9's on routes which have already been tried and who failed to yield a partnership grant. Monitor A will also set the code9 inhibit flags that correspond to its own ip's (H and I).

Now monitor A will attempt to send its own code9 to monitors in T1 that still have their code9 inhibit flags clear. The code9 which was received from monitor C will be temporarily stored in T17. Every time a timeout occurs with no partnership occurring, monitor A will set the code9 inhibit flag for the tried monitor in T1.

If a partnership grant results, monitor A will send the code9 it received from monitor C (now residing in t17) to its new op. If, on the other hand, all code9 inhibit flags in t1 of monitor A become set without a partnership grant occurring, monitor A will send a code1A back to monitor C. Then monitor A will return to normalcycle as will be more fully described with particular reference to FIGS. 7A-7C.

When monitor C receives the code1A, it will set the code9 inhibit flag for monitor A in its neighbor list. Monitor C will then attempt to get a partnership grant by sending the code9 to monitor D. If that fails it will try monitor B. If all of the code9 inhibit flags in t1 of monitor C become set with no partnership grant occurring, monitor C will simply start the polling process over by clearing all code9 inhibit flags in its T1.

When distress is entered from initialization and the monitor is not the central monitor 15A, dist3 will be executed. To simplify discussion, the monitor who's perspective is being described will be called monitor A as seen in FIG. 2C.

The first event will be the transmission of the distress broadcast message which was placed in the transmit queue during initialization. All monitors who are in range will detect this message and will send a code2 (acknowledge) back to monitor A. Those monitors will send code2's in a time-staggered fashion as to avoid collisions. As monitor A detects these messages being sent to it, it begins recording the senders' id's and signal strengths in the neighbor list (T1). (Actually, any transmissions that a monitor "hears", at any time, causes it to record the sender's id & signal strength into its neighbor list regardless of who the message was addressed to.

The main purpose of the neighbor list is so that a monitor can keep track of all other monitors that it is in range of. This table is occasionally cleared of monitors who are no longer being heard from.

After monitor A has collected data into its neighbor list, it will send out a code9 (partnership request) to one of the newly detected neighbors (monitor B for example). This message will contain a list of monitor A's neighbors along with their signal strengths. Normally ip's are excluded from the list but at this point monitor A has no ip's anyway. It is the job of monitor B to forward the code9 to its op who will send it to its op until ultimately it reaches central.

The central station computer 17 will then choose one of the monitors listed in the message as an op for monitor A. Central station computer 17 bases this decision on which one of the monitors 15 can most easily take on additional mobile broadcast device data traffic. For this example, lets say the central station computer 17 decides that monitor C is the best choice to become the op of monitor A.

Central computer 17 informs the pair of monitors via a code0a (partnership grant). This message will be sent to monitor C via monitor C's op and other parents. (Parents of a monitor include all monitors which link it to central including the op. For example, the parents of monitor B include monitors C, G, and central monitor. Monitor C will then send the code0a to monitor A. Now monitor A is officially the ip of monitor C and monitor C is officially the op of monitor A.

Although this relationship is established among monitors A & C, central station computer 17 does not know if the partnership grant it issued ever successfully reached monitors A & C. Monitor A must verify the partnership by sending a code0d (ip added) back to central station computer 17 through monitor C and its parents. When the code0d is received by central station computer 17, central station computer 17 records the partnership into its data structure.

Now that monitor A has an op, it will leave distress mode and enter normalcycle mode. Monitor A will then be able to process and forward mobile broadcast device data. Monitor A will also be able to take on ip's of its own.

As monitor A is leaving distress, all messages in the distress queue are transferred into the transmit queue. In this scenario, this means the code1c (reset) placed in the distress queue during initialization is now eligible for transmission. This message is sent to central station computer 17. When central station computer 17 receives this message, it will prompt the user for X & Y coordinates if necessary.

If this is not a new monitor but instead one which has just been moved, the central station computer 17 is programmed to purge its mobile broadcast device data base of all references to this monitor. Because the monitor has probably been moved, the mobile broadcast devices which used to be in its vicinity must be disassociated from it. The dist2 mode of distress will be entered if communication fails with the op and the op happens to be central station computer 17.

As previously noted, there is typically only one monitor in the network 11 which has central station computer 17 as its op, although there can be more than one if desired. Such monitors are referred to as central monitors 15A. Each central monitor 15A communicates with its op (central computer 17) through a serial communications port instead of airwaves. This means that collisions with other messages are not possible so all messages between the central monitor 15A and central computer 17 should be successfully transferred. If they are not, it is assumed that there is some problem with central station computer 17 or the communications link itself.

This type of failure will cause the central monitor 15A to enter dist2 which simply puts a code18 (central down broadcast) in the transmit queue. Central down mode is then immediately entered.

Normal Cycle

Referring to FIGS. 7A-C, the main purpose of normal cycle (Main state 2) is to collect and forward mobile broadcast device data. Other functions include ip list and neighbor list maintenance and providing a link by which more remote monitors can communicate with central.

As can be best seen in FIG. 7A, once entered, normalcycle will synchronize itself with other monitors using p24 and p26. Then a period will occur where the monitor 15 will primarily be listening for mobile broadcast device transmissions 21. After this time is up (p24>p26), T1 will be processed.

FIG. 7B shows how t1 will be processed only after the expiration of a given period of time. If p24 is on a given time interval, t1 processing will search for and delete any monitors 15 in T1 which have not been detected in the given time interval. This is determined by whether or not the time flag in the t1 entry for a given neighboring monitor is set.

Next, T12 processing will occur. This is shown broken down in FIG. 7C. T12 contains mobile broadcast device information on mobile broadcast devices 13 which have been detected in the given monitor's vicinity. New mobile broadcast devices 13 (or old mobile broadcast devices 13 whose signal strength has changed, i.e., which have moved significant1y) are included in a code14 (s) which will be constructed to an optimum length. If flag7 is set, all mobile broadcast devices in the vicinity will be included in code14 (s). Any residual mobile broadcast device data remaining will be left in code14 format and will be stored into t16.

The next major function of normalcycle will be to send its accumulated mobile broadcast device data (now in xmit queue) to its op. At approximately the same time it will be receiving mobile broadcast device data from its ip's. Once all ip's have reported (sent in their code12's) or a timeout occurs, residual mobile broadcast device data (if any) from t16 will be combined into a code14 and sent to op. Then the monitor 15 will send its own code12 to its op. Then another mobile broadcast device transmission reception period will occur.

As noted above, mobile broadcast device data is forwarded to central station computer 17 in a code14 which tells the central station computer 17 the digital message associated with each mobile broadcast device, which mobile broadcast devices 13 are being detected by which monitors and at what signal strengths. Signal strength indicates the distance a mobile broadcast device 13 is from the associated monitor 15 receiving a radio signal 21 from the mobile broadcast device 13.

A monitor 15 will send in data to the central station computer 17 for a given mobile broadcast device 13 when a mobile broadcast device 13 enters the vicinity (communication range) of that monitor.

A monitor 15 will send its own mobile broadcast device data every cycle that the above criteria is met. In the present system 11, all monitors 15 will be synchronized so that their cycles always begin at the same time. When a monitor 15 along with all of its descendants has sent all of its mobile broadcast device data, it will issue a code12 (all mobile broadcast devices 13 reported message) to its op. If a monitor 15 and its descendants have no mobile broadcast device data to report, it still sends a code12 to its op.

When an op has sent all of its own mobile broadcast device data along with its ips' mobile broadcast device data and received code12's from all of its ip's, it will send any "residual" mobile broadcast device data it may have accumulated followed by a code12 to its op and so on until the central computer 17 receives all of the mobile broadcast device data. The monitors attempt to send code14's of an optimum length; this creates residual mobile broadcast device data which is temporarily stored. When more residual mobile broadcast device data is encountered (ie. from ip's), a monitor 15 will attempt to combine this data with the stored residual mobile broadcast device data to create a code14 of optimum length. However, if code12's are received from all ip's, the monitor 15 will send its residual mobile broadcast device data "as is" followed by a code12 to its op. This is because at the point when code12's have been received from all ip's, no other mobile broadcast device data will be received from ip's until the next cycle.

If all of a monitor's ip's haven't sent in their code12's, a timeout condition will occur and the monitor will give up on those ip's for the current cycle.

If an ip fails for 3 consecutive cycles to send a code12 to its op, that op will assume that the partnership has ended and will send a code0e (ip deleted) to the central computer 17. If the former ip has been re-routed (another op assigned to it), the central station computer 17 will ignore this code0e. If the former ip hasn't been re-routed, the central station computer 17 will expect to receive a code9 (distress signal) from the former ip. If the code9 is not received in a certain amount of time, the central station computer 17 will attempt to assign the former ip a new op based on information it already has. If these measures continue to fail and a code9 is never received, the central station computer 17 will assume that the monitor is malfunctioning and will inform the user of the situation.

Central Down Mode

When central down is entered, the airwaves will be monitored until a central up broadcast is detected. This is done by repeatedly calling taskswap until f23=0 as best seen in FIG. 8. Next taskswap will be repeatedly called until a request for all mobile broadcast devices is detected. When f7=1, all mobile broadcast devices will be included in code14 (s) and placed in the transmit queue. The control will be passed back to normalcycle.

Referring to FIG. 8, when a central monitor 15A loses communication with the central station computer 17, the monitor 15A will first enter dist2 and then go into central down mode (Main state 3). The central monitor will broadcast a code18 to ip's who will then broadcast code18's to their ip's and so on until all descendants have received the code18. This causes all monitors 15 in the tree to go into central down mode.

While in central down mode the monitors 15 don't initiate communication with their op's but will acknowledge messages sent to them from their op's.

When the central station computer 17 is re-booted, it will issue the central-up message (code 19) to its IP(s) (central monitor 15A). The central monitor(s) 15A will then retransmit the message to its IP's and so on. After some delay, the central station computer 17 will begin polling monitors 15 individually with code15's (requests for all mobile broadcast devices). Monitors 15 must hear and respond to this code15 before they go back to the normal cycle mode.

The central station computer 17 retains knowledge of the network tree by saving a copy of it to disk every time it is modified. Partnership grant messages (code 0a's) and request for all mobile broadcast devices (code 15's) are stored in an unverified command message queue. This queue is saved to disk every time a message is added to it and before a message is actually issued.

When a partnership grant is verified, the tree is modified accordingly (which causes the tree to be copied to disk). Then that message is removed from the unverified command message queue (which causes the queue to be saved to disk). Partnership grants are considered verified when a corresponding code0d (ip added) is received by the central computer 17. Also, the central station computer 17 knows when a code15 reaches its destination because it will receive a code14 from that monitor 15.

This code14 will be different than the usual code14 in that it will have a cleared flag in its status byte (See the code14 breakdown in FIG. 25). This cleared flag will indicate to the central station computer 17 that the code14 is in response to a code15 (request for all mobile broadcast device messages).

These measures allow the network 11 to be restored to conditions which are exactly the same as they were before the central station computer 17 failed.

System Operation

Referring to FIG. 9, after initialization, the monitors 15 are programmed to listen. The first action of listen is to decrement the traffic parameter (p1) if it is not already zero. The traffic parameter (sometimes called "busy" parameter) is loaded with a count when a message destined to another monitor 15 is found in the receive queue. Theoretically, when the traffic parameter reaches zero, that particular session should be over. When p1=0, transmit is allowed to send out messages.

The primary function of listen is to retrieve the next message from the receive queue and process it. As can be seen, many conditions may affect the way a message is processed. Once a message is processed, it is removed from the receive queue. If it is a message that requires an acknowledge to be sent back, the other monitor's ID is placed in p2. This will cause transmit to send an acknowledge to that monitor 15.

Some of the code-processing subroutines shown in FIG. 9 are shown broken down into detail in FIGS. 10A-10F in which monitor code processing is shown. FIG. 10A depicts the operation of broadcast processing. The purpose of this routine is to relay to the ip's any broadcast messages received from the op. As with all acknowledgeable codes, the id of the source is copied to p2. This allows transmit to acknowledge the broadcast which was just received.

After this occurs, transmit will send out the broadcast to the ip's. Notice that all acknowledge flags in T2 are cleared in this routine. This allows the monitor to keep track of which ip's have acknowledged if a retransmit is necessary.

FIG. 10B shows code2 processing. This is related to broadcast processing in that it sets and examines the acknowledge flags which were cleared in broadcast processing. If no acknowledges are expected however, no actions are performed and the routine terminates.

Code0a processing is shown in FIG. 10C. If this message relates to a partnership not concerning us, it is simply passed on to the next monitor 15 in the routing list. (The routing list is a listing of monitor ID's through which a message must pass in order to get to its destination. Routing lists are used in non-broadcast messages which are sent in a direction away from the central computer 17. This routing list is modified every time the message is passed to the next monitor.) Notice that whether or not the routing list is empty, the source of the message is copied to p3e. This is because if a code0d results from this code0a, then the monitor who originally sent the code0a shall be the op.

If the message has a specific monitor 15 listed as the destination address and only one ID in the routing list, then the message specifies the specific monitor 15 as the new op of the monitor who's ID is in the routing list.

If the message has the specific monitor 15 as the destination address and an empty routing list, then the specific monitor 15 is the target of the partnership grant. When this happens the specific monitor records the source address (sending monitor's ID) as the new op. The specific monitor 15 then places a code0d to the new op in the transmit queue.

Code0d's occur as a result of code0a's. FIG. 10D illustrates how a code0d is processed. If the source of the message is not an ip (listed in T2), then it is added to T2. The monitor level (called sensor level in FIGS. 19-24) for a given monitor 15 is defined as the number of "generations" descended from that monitor. If it has no input partners, its level is 1. Otherwise, its level is 1 higher than the highest level of any of its input partners.

If the monitor level (s1), which is in the message is greater than p36, then it is copied into p36. This value minus one is then copied into this monitor's entry in T2. P36 plus one is then placed into the code0d which is to be sent to our op. The monitor level of a monitor 15 is a scale factor used to determine how long it can wait on its ip's to send their code12's before it must give up on them and send its own code12 to its own op.

This mechanism is necessary to insure that all mobile broadcast device data is reported to the central station computer 17 in the same cycle that it originated.

Notice that p3e is copied to p0b near the end of this routine. This allows for cases when multiple partnerships are granted by a single code0a issued from the central station computer 17. The central station computer 17 considers the partnership grant verified only when it receives the resulting code0d. The code0d always originates from the last monitor to receive the code0a. Therefore, if the code0d never returns back through the same path of the code0a (which would be the only path logically possible), then the grant has failed and the monitors who didn't receive the code0d will keep using their old op's if they had one. This will cause the central station computer 17 to re-issue a partnership grant.

Code0e processing is shown in FIG. 10E. There are two purposes of the code0e. One is for the updating of monitor level values. A value that may be updated is the receiving monitor's p36. Another value that may be updated is the monitor level value of the sender as listed in T2 of the receiving monitor. This allows monitor levels to be reduced whenever possible which allows for more efficient operation. The second purpose of the code0e is to inform the central station computer 17 that a partnership has been broken and what two monitors 15 are involved.

Code14 processing is shown in FIG. 10F. Most of the time when a code14 is received from an ip, it is already of optimum length so it will simply be forwarded to the next monitor. If it is shorter than the optimum length, this routine will attempt to lengthen it to the optimum length using residual code14 data from T16. If a resulting message of optimum length is not possible, then the code14 just received will be stored into T16.

If it is stored into T16, it may not be stored as it was received; instead it may be combined with another partial code14 which was already in t16. If a timeout occurs as dictated by p36, all data from t16 will be combined into a code14 and sent out even though it will be shorter than the optimum length.

Referring to FIGS. 11A-11G, flow diagrams are provided illustrating the monitor transmit arrangement. Monitor transmit has three different states: 1) state 0--uncommitted (not waiting on an acknowledge); 2) state 1--awaiting acknowledge (also known as retry); and 3) state 4--broadcast mode (awaiting acknowledges from multiple sources).

State 0 is shown in FIG. 11A. While in this state, the monitor can initiate a session by sending a message (xmit0talk) or it can close a session by sending a code2. Sending a code2 is the highest priority when state0 is entered; note that p2 is checked immediately upon entry. Also note that f9 and p1 must be checked first to avoid collisions with transmissions from other devices.

State 1 is shown in FIG. 11B. This state is entered from state 0 after an acknowledgeable message is sent out. Transmit will remain in this state as it waits for the destination device to acknowledge the message that was just sent to it. When a certain time elapses with no acknowledge occurring (p24>p2e), the message will be retransmitted. After the message has been retransmitted a certain number of times (retrylim), the monitor 15 will assume the communication path to that device to be unusable.

At this point, the retrymaxsrvc subroutine will be executed. First the ID of the destination monitor 15 will be removed from T1. If the destination ID equals the op ID, the state of main will be set to 1 (distress mode) and the message will be put into the distress queue. Finally, the message will be removed from the xmit queue and transmit will be returned to state 0.

If on the other hand, the destination device does send back an acknowledge, listen will remove the message from the transmit queue and set f17. As can be seen at the top of transmit state 1, this will cause transmit to change back to state 0.

If while in transmit state 0, xmit0talk is entered and the destination device is 0 (meaning a broadcast message), transmit will go into state 4. State 4 is shown in FIG. 11G. Broadcast messages are handled differently when they are re-transmitted. An example of a broadcast message is code0 in FIG. 25. As can be seen, there is a list length and monitor ID list in the message.

When the first message is transmitted, the list length is zero. This lets all ip's know that they each must send back an acknowledge. If all ip's don't acknowledge, the monitor will reconstruct the message using a list length and a list of ID's who didn't acknowledge the first broadcast.

When this message is transmitted, only the monitors listed in the list will send back acknowledges. As is the case with state 1, state 4 will stop trying after a retry count maximum has been reached.

Central Station Computer Software Organization

FIG. 12A shows the round-robin multi-tasking organization of the central station software. Task1 (cmain) includes the higher level functions of the monitor software as mentioned in this document. The "c" in cmain and other central words is used to draw a distinction between similar central and monitor words. Task1 is shown broken down in FIG. 12-b. Task2 is the forth interpreter. Task3 monitors the rs232 port. Task3 puts mobile broadcast device related messages in the receive queue and displays others to the CRT.

Tasks 2 and 3 are not illustrated here because knowledge of them is not necessary for a system level understanding; documentation on these tasks can be made available however if needed.

Ctaskswap (FIG. 12C) is commonly used by many other routines so it is shown here for ease of reference. Unlike the taskswap used in the monitor software, ctaskswap actually performs task swapping. This occurs when the word "pause" is executed. The function of taskswap is to allow any messages in the receive or transmit queues to be processed until both those queues are empty and the transmit state (p22) is zero. The transmit state is zero when the monitor is not engaged in a communication session with the central monitor 15A.

Central Station Computer Normal Cycle

(cmain state 1)

Referring to FIGS. 13A-13C, the basic operation of normal cycle in the central station computer 17 is very similar to that of the monitors 15. That of the central station computer 17 is not as complicated, since the central station computer 17 only has one ip in the present embodiment and doesn't have an op to report to. The complexity of the central station computer's software lies in the table 3 processing and the clisten software.

Central Listen

The job of the central station computer listen software is to direct execution to the code processing routine corresponding to the message received. Referring to FIG. 14, when entered, central listen will first check to see if anything is in the receive queue. If nothing is there, central listen will be exited. If the receive queue is not empty, the xmit state (p22) is checked. If it is 01 and the message retrieved from the receive queue is a code2, f17 is set and the code2 is removed from the receive queue. If p22 is 01 and the message is not a code2, it will be discarded.

If p22 is clear, the code number will be examined and execution of the corresponding subroutine will occur. Because processing for codes 12 and 16 is simple, they are shown in FIG. 14. The other code processing is shown in FIGS. 15A-15F.

Code Processing

Referring to FIG. 15A, Code9 processing will first check to see if a code0a has been sent recently to this monitor. If one hasn't been sent recently, the message is checked to see if the distressed monitor 15 is the central monitor 15A. In such a case, a code0a will be issued immediately to central monitor 15A. Otherwise, the neighbor list in the code9 message will be examined to find out which one would be the best op for the monitor in distress. When an op candidate has been chosen, a code0a is constructed accordingly and then placed in the transmit queue.

When the central station computer 17 issues a code0a, a resulting code0d should occur. The processing for a code0d is shown in FIG. 15B. T4 is first searched to see if the monitorID has ever been placed there before. If it hasn't, a new entry is created. If the ID is already there, measures will be taken to disassociate that monitor from its old op. Last of all, the new partnership is recorded in T4. This is called a treeupdate and is shown in FIG. 15C. Treeupdate will update all #handled and load-level values affected by the new partnership. (Note: T4 is the actual tree structure.)

The #handled for a given monitor 15 is defined as the number of descendants of that monitor. The load level for a given monitor 15 is defined as the sum of the #handled for that monitor plus the #handled by its output partner. It is a measure of expected traffic congestion/delays, and the smaller its value, the more attractive this monitor becomes as a potential output partner for its neighbors.

FIG. 15D shows the processing for a code1c. This routine will clear all mobile broadcast device references to this monitor from t3 (mobile broadcast device data base). Old location data will be invalidated as the user is prompted for new coordinates.

The code0e processing in FIG. 15E does the opposite of code0d processing; instead of a partnership being recorded into t4, one is removed.

The function of code14 processing in FIG. 15F is to record mobile broadcast device data from the message into t3.

Central Transmit

Central transmit is simpler than monitor transmit because all messages are of the single destination type. State 0 and state 1 (FIGS. 16A & 16 B) are still used although they are simpler. Because messages are sent via the rs232 and not over the airwaves, p1 and f9 are not used. If the transmit retry maximum is reached, the only explanation is an rs232 break.

In such a case the user is informed of the condition as shown in FIG. 16C. In cxmit0talk (FIG. 16D), the message is sent and then all associated parameters are set. FIG. 16E shows sendmsg. This routine is very similar to the monitor version; depending on the code number, the current time may be inserted into the message just before it is sent out.

FIG. 17 illustrates Flags (parameters) and their meaning. Many of the flags and parameters listed in FIG. 17 are common to both central and the monitors. Some are used by one device but not the other. Flags are values which are either 0 or 1 while parameters can be any value from 0 to ffff(hex) if needed. Many parameters were skipped because the need for them disappeared during development.

FIG. 18 illustrates Message Code meaning. The messages in FIG. 18 have the same meaning for all devices. Some devices don't use certain messages. For instance, the central station computer would never send out a code16 since it doesn't have a distress mode. FIG. 25 shows the actual format of these messages.

Notes on tables: The number of bytes used to store a parameter in a certain entry is not always indicative of the number of bytes required by that parameter. For instance, in T1 and T2, 2 bytes are used to store the monitor ID's even though monitor ID's are only one byte in length. Offsets listed in tables are in hexadecimal notation.

FIG. 19 illustrates T1 which is the neighbor list and is used by the monitors 15. All numbers appear in hex. The purpose of T1 is to allow a monitor 15 to keep track of which monitors 15 are in its vicinity. When a monitor 15 goes into distress mode, the monitor Id's along with their signal strengths are copied from this table into the code9 message. A monitor ID from this table which has its code9 inhibit flag clear will be chosen as the destination of the code9 message.

Another way T1 is used is to prevent messages from being sent out to destinations which don't exist; this prevents wasted air time. Before a message is sent, T1 is searched for the destination ID. If the ID is not found, the message is not sent and is deleted from the transmit queue.

FIG. 20 illustrates T2, which is the input partner list. Its function is to help a given monitor to keep track of its ip's. Using this table, a monitor 15 knows when to issue a code0e and it knows when to re-transmit a broadcast message.

FIG. 21 illustrates T3 which is the mobile broadcast device table. The information in the code 14's is based on this data. If flag7 has been set, data for all mobile broadcast devices with their signal strengths are sent out in code 14's. If flag7 is clear, only data for entries that have their new flags set will be included in the code 14's.

FIG. 22 illustrates Monitor T4 which contains the "residual" code14 data mentioned previously. There are three of these elements in T4. When a partial code14 is received from an ip, the monitor will attempt to build a code14 of optimum length from the newly received partial code14 and one from this table. If one of optimum length cannot be built, the newly received code14 will be stored in one of these entries.

FIG. 23 illustrates Central T3 which is the actual mobile broadcast device location data maintained by the central computer 17. Up to three monitor ID's are stored for each mobile broadcast device 13 since that is the amount needed for triangulation. For many applications triangulation is not necessary and only the most recently reporting monitor ID is relevant.

FIG. 24 illustrates Central T4 which, in the central computer software, makes up the monitor tree structure discussed with particular reference to FIGS. 2A-2C. When the central computer 17 receives a code9, it uses this structure to determine which ID listed in the message would be the best op for the monitor 15 which is in distress mode. Table 4 is also used to store a monitor's physical location.

Mobile Broadcast Device Signal

As noted above, each of the mobile broadcast devices 13 periodically sends out a radio signal 21 containing as a minimum the mobile broadcast device's unique identification code and if required, such further digital data as is to be forwarded to the central station computer 17. According to one embodiment of the present invention, the radio signal 21 at a minimum comprises a message containing a leader to allow the receiving monitor's AGC to adjust, plus a code identifying the radio signal 21 as a mobile broadcast device identification signal, plus a 48 bit identification code unique to the mobile broadcast device, plus an 8 bit cyclical redundancy check (CRC) code which can be used by the receiving circuitry of the monitor to verify the transmission of the radio signal is error free.

Monitor Circuit

Each monitor contains a radio receiver that can receive and decode radio transmissions from mobile broadcast devices as well as from other monitors, yet discard noise signals and other radio signals that may be present in the area. Each monitor also contains a transmitter for sending messages to other nearby monitors via radio waves.

In the case of messages from mobile broadcast devices, the monitor extracts and validates the identification code contained in the message. The monitor contains a microprocessor and memory with software that enables the monitor to store and process data received from other monitors or from mobile broadcast devices. The monitor stores in its memory a list of the mobile broadcast devices it has been hearing recently, along with the signal strength of each mobile broadcast device. When a message arrives from anywhere, the monitor first validates the message by comparing the CRC code and checking it against the received CRC codes stored in memory.

If the message is valid, the monitor then checks the message type and proceeds accordingly. If the type indicates the message is from a mobile broadcast device, the mobile broadcast device ID is extracted and compared with the identification codes already in memory. If the identification code is already in memory and the signal strength has not changed significantly, no further processing of the message is necessary. However, if the mobile broadcast device is a "newcomer" or if its strength has changed significantly, the memory is updated accordingly, and the monitor sends a special message to its "output partner" (DOP) monitor specifying the new status of this mobile broadcast device.

That output partner, which is also a DOP monitor, will forward that information to its associated output partner or DOP monitor, and the information continues being relayed from one monitor to another until it reaches the monitor that ties directly to the central computer. That monitor is slightly different than other monitors in that its software is modified to forward messages over its RS232 port to a central computer. Software in the central computer then uses this incoming information to update its data base.

Besides keeping track of mobile broadcast devices in its own vicinity and reporting that status, each monitor must also serve as a relay station, forwarding incoming radio messages from other monitors to the appropriate destination. Radio communication between monitors is governed by a complex protocol as explained above.

Detailed Description Of Monitor Circuitry Receiver

Referring to FIG. 26A, a 50 ohm antenna is connected by an optional 50 ohm coax cable to connector J1, to match the impedance expected by the ASH receiver U5. The ASH receiver U5 has been chosen in this case to simplify the circuitry, but any number of other radio receivers would also suffice. The antenna is typically an omni-directional horizontally polarized antenna such as a loop. The weak RF signal from the antenna is fed to ASH receiver U5 which essentially discards all signals except 303.825 Mhz, which is the frequency transmitted by the mobile broadcast devices 13 and monitors 15 in the system 11.

There is nothing magic about the chosen frequency for this system. That frequency was chosen in this application primarily because the ASH receiver was available for that frequency. All transmitters and receivers in this system 11 must obviously be designed for the same radiated frequency however, in order to make radio intercommunication possible.

U5 has an analog output at U5 pin 2, which is the AM detector output. When 303.825 Mhz radiation is detected, this output rises 0.3 volts or so above its no-signal level, which is typically about 2.1 volts. This particular receiver can easily be saturated by excessive background noise. Provision has been made for the monitor 15 to measure the dc level of this signal (labelled RSSI) to recognize the presence of excessive background noise, should that occur.

This analog output is ac coupled through C5 to a comparator input U5-3. The digital output of the comparator appears on U5-7. The threshold level of the comparator can be adjusted from 0 to about 25 millivolts by the value of R7. The end result is that U5-7 is high while the 303.825 Mhz signal is present at the antenna, and thus reproduces the on-off keyed modulation present in the antenna signal. C4 and C9 are capacitors recommended by the manufacturer of U5 to filter the 3 volt dc power supplied to U5 pin 1 and the internally generated bias at U5 pin 6. Since the output at U5 pin 7 is only 3 volts, Q1 is used to boost that signal to 5 volts for driving the 5 volt CMOS logic. R6 and R4 have large values to minimize power consumption.

This high impedance circuitry has slow rise and fall times, which are speeded up by Schmidt trigger U1:C to reduce power consumption of succeeding circuitry.

Miscellaneous Circuitry

C7 and C8 provide local filtering of the 5 volt VCC power. R5, C3, and C6 are a decoupling circuit to prevent U3 and U4 from introducing noise onto the 5 volt power. The function of diode D3 is to supply the heavy inrush current drawn by U3 and U4 as they are being powered up. U2 is a CMOS version of the popular 555 timer circuit. Associated components R3 and C1 cause it to supply an output square wave signal operating at approximately 64 Khz. That signal is used as the clock to PAL (Programmable Array Logic) circuits U3 and U4.

PALS

The PALs are programmed with the following logic:

The signals reaching the receive antenna from other components of this system arrive in short bursts lasting a small fraction of a second. While no such message signal is present, the received signal will just be noise. It would be a waste of time for the Motorola 68HC11 microprocessor (U8) to deal with this noise. The main purpose of PAL U3 is to recognize noise, and prevent it from reaching the 68HC11. The PAL generates an ENABLE signal, which is false during noise, and true during legitimate messages. That ENABLE signal gates the DATA.sub.-- IN signal to produce the RDATA signal that goes to the 68HC11.

W0 through W2 compose a Gray code counter with W0 being the least significant bit. A Gray code counter is one in which only one bit at a time changes states. The binary counting sequence for this particular counter is 000, 001, 011, 010, 110, 111, 101, 100. Logic for this particular counter is such that when the counter reaches the 100 state, it will remain there until the RSETW signal occurs, which will return it to the 000 state. It is referred to as the "width" counter, for it is used to measure the width (time duration) of pulses. 0C0 and 0C1 compose another Gray code counter called the "occurrence" counter. It counts the pulses yielding a width count of less than 7. The count sequence of 0C0 and 0C1 is 00, 01, 11, 10, where 0C0 is the least significant. A pulse is considered good if it gives a full scale width count, and is otherwise considered bad. The ENABLE signal is set by P3, an external signal indicating the arrival of 8 consecutive good pulses. The ENABLE signal is reset by the occurrence counter reaching state 10, which means 3 bad pulses were found in a group of 7 or less.

U4 is miscellaneous logic. C0-C4 divide the clock frequency by 32 to provide a nominal 2 Khz clock (TCLOCK) for the Manchester data provided by the CPU. P0-P3 count the SYNC pulses. Both counters are standard binary counters.

Processing of Received Signal

The output of U1:C has been described earlier as being the cleaned up digital data stream from the radio receiver U5. This signal enters U3 and is named DATA.sub.-- IN. From that signal, U3 with the help of U1:A, U1:B, D1, D2, R1, R2, and C2 produces a signal named SYNC that is the same as DATA.sub.-- IN except that its edges have been shifted enough to align them with positive edges of the clock. A separate patent application is being filed on this unique synchronizing approach, which eliminates metastability using standard components.

From SYNC, U4 generates a signal named EDGE that is sort of a one-shot pulse occurring on each positive transition of SYNC, but lasting only one clock period. That EDGE pulse is used to advance the pulse counter comprising P0 through P3. That counter is reset by the RESET signal generated in U3. While ENABLE is true, the counter counts upward until it either reaches 8 counts or 3 bad pulses arrive. While ENABLE is false, the counter always counts to 8 before resetting.

The RDATA signal, which is essentially the received signal with noise removed, is fed directly to a timing input on the 68HC11. The 68HC11 contains circuitry that is able to record the time of arrival of each transition of the waveform, and the processing software is able to retrieve the desired information by analyzing these times of arrival.

Transmit Signal Processing

The previously discussed TCLOCK signal, which runs at nominal 2 Khz, is fed to pin 24 of the 68HC11, where it serves as the clock signal for the synchronous serial peripheral interface circuitry inside the 68HC11. The software loads data in parallel form 8 bits at a time into a shift register inside the 68HC11, and that data gets shifted out on U8 pin 22 (signal TDATA), which presents a new bit on each positive edge of TCLOCK.

If the software stops loading parallel data, TDATA enters a static 0 state because the serial input to the transmit shift register is pin 23, which is grounded through R16. TDATA is fed to U4 pin 23. The logic inside U4 generates signal XMIT, which is identical to TDATA except that all high to low transitions are delayed by one clock cycle. This deliberate lengthening of positive pulses is intended to compensate for the transmitter radio frequency oscillation building up more slowly than it decays. The XMIT signal is the modulation input to the radio frequency transmit circuit to be discussed later.

We have chosen to use Manchester encoded data, but the Manchester encoding is done in software before loading it into the shift register. Similarly, the Manchester decoding in the receiver is done by software. In the case of mobile broadcast devices, the Manchester encoding is done within the PAL. Therefore, a different type of encoding could be achieved by simply revising the software and the logic inside the mobile broadcast device PAL, if desired.

FIG. 26B of the monitor schematic illustrates the voltage regulators, the transmit circuit, and a microprocessor with associated memory, address decoding, etc., plus an RS232 port of the monitor.

The voltage regulators are for deriving V+ and VCC and +5V from either an AC voltage source or a 6 volt battery. VCC is nominally 5 volts dc, whereas the VRI output is nominally 3 volts dc. The regulator circuitry is quite conventional, and consists of voltage regulator integrated circuits VR1, VR2, bridge rectifier BR1, components C18 through C20, C23 through C31, R25 and R27. The capacitors are provided to make the dc voltages steady and stable. R25 and R27 are chosen to make the VR1 output 3 volts nominal. BR1 converts the optional AC input to a dc signal.

The transmit circuit comprises Q2, a 303.825 Mhz SAW resonator Y2, and components R20 through R22, R24, R26, R28, C17, C21 C22, and L1. L1 is an antenna. The circuit sends out a 303.825 Mhz radio signal amplitude modulated by the XMIT signal.

Microprocessor U8 is the heart of the remaining circuitry. It is a Motorola 68HC11 microprocessor but New Micros has had its ROM memory preprogrammed with a proprietary FORTH compiler. Thus all of the programming is done in the FORTH language. U8 also contains a built in analog to digital converter, which reads the ASH voltage (filtered by R30 and C32) on pin 47, and battery voltage +6V on pin 43 via divider R84/85. It also contains built in time circuits which are programmable to record the time of arrival of + and - edges of the RDATA signal arriving on pins 32 and 33. This makes it possible for the software to decode the incoming signal. The signals PA0 through PE7 are input or output ports most of which can be programmed for a variety of possible uses. It also contains a UART to be discussed later. It also contains the circuitry discussed earlier for generating TDATA.

Crystal Y1, C10, C11, and R8 constitute the standard circuit recommended by the manufacturer of U8 to provide the 8 Mhz clock signal which controls all time in U8. R10 connects 5 volts to pins 18 and 19 of U8 to prevent IRQ and XIRQ interrupts. J2 R9, and R29 allow the microprocessor to be operated in any of its four operating modes, although only one of those modes is normally used. (Normally, on J2, pin 1 is jumpered to pin 2 and pin 5 is jumpered to pin 6.)

U11 is a 32 kilobyte EPROM (erasable programmable read only memory) containing all of the application software. U12 and U13 are 32 kilobyte RAM (read and write memory) used for storing temporary data such as what mobile broadcast devices are in the area. The microprocessor has only 64 kilobytes of address space, so these memory devices to some degree overlap memory that is inside the microprocessor. However, the microprocessor is smart enough to ignore external memory for those addresses where it has internal memory. Also, output port pin 28=PA6 selects U12 or U13 as the external RAM. Address bit A15 low selects EPROM, A15 high selects RAM. The data bus of these memory chips is bi-directional and feeds into ports PC0 through PC7.

The microprocessor also multiplexes the least significant address lines onto this port, so those address bits must be latched somewhere. Eight bit register U10 serves that purpose. U7, U9, and U1:D provide the gates necessary to enable reading or writing of the memory chips. LV1 is a low voltage detection circuit. Its open collector output generates a reset by pulling the RESET signal low when the circuit is first powered up or if a power failure occurs. The RESET signal causes microprocessor U8 to restart the software at its beginning. When no reset is called for, the not RESET line is held high by pullup resistor R11.

Microprocessor U8 contains circuitry to generate synchronous full duplex UART type serial data transfers on pins 20 and 21. However, the voltage levels are not proper for RS232 operation. U6 is provided to convert between the 5 volt levels used by the microprocessor and the .+-.8 volt levels required by RS232. The 8 volt supplies required for this are built into the U6 chip. However, the manufacturer of component U6 requires external capacitors C12 through C15 in order for its internal circuitry to function. Timing for the RS232 signals is also provided internal to the microprocessor, and the baud rate has been pre-selected by the ROM software provided by the manufacturer of U8.

Although the present invention has been described with particular reference to its preferred embodiments, it should be understood that many variations and modifications will now be obvious to those skilled in that art, and it is preferred, therefore, that the scope of the invention be limited, not by the specific disclosure herein, but only by the appended claims.

Claims

What is claimed is:

1. A dynamic and adaptive communication network for monitoring broadcast messages issued by a population of mobile broadcasting devices comprising: a central station for receiving messages and for adaptively configuring the network based on information contained in received messages; a grid of monitors for: 1) receiving broadcast messages from the mobile broadcast devices and forwarding the broadcast messages, in a bucket-brigade fashion, to the central station, 2) receiving and forwarding central station messages, in a bucket-brigade fashion, from the central station to a given monitor, 3) transmitting, forwarding and receiving monitor-to-monitor messages transmitted from one monitor to a destination monitor of the grid, and 4) transmitting and forwarding monitor-to-central station messages, in bucket-brigade fashion, from one monitor to the central station; wherein each monitor of the grid has one or more neighboring monitors each of which is within communication range therewith, neighboring monitors comprising one of input partner monitors for transmitting messages and output partner monitors for receiving messages; wherein the central station, based on information received from messages forwarded by the grid of monitors, dictates how the grid will be configured for communication such that each monitor is assigned, by the central station, only one output partner monitor and one or more input partner monitors; and a main monitor in direct communication with the central station and the grid of monitors; wherein each monitor of the grid receives and stores at least one of broadcast, central station and monitor messages from any one of its assigned input partner monitors; and wherein each monitor transmits received broadcast messages to its output partner monitor for forwarding to the central station by way of the main monitor and transmits received monitor or central station messages to the output partner for forwarding to either the central station or a designated monitor.

2. A communication network according to claim 1, wherein each monitor of the grid is assigned a unique identity for identifying the monitor as a unique individual of the grid and an address indication the location of the monitor in the grid.

3. A communication network according to claim 2, wherein the central station includes means for determining, based on information contained in messages received by the central station, the input partner monitors of the grid that are be authorized to send messages to a selected monitor of the grid and each monitor includes means for storing the identity of the input partner monitors of the grid authorized to send messages thereto.

4. A communication network according to claim 3, wherein the central station includes means for determining, based on information in messages received by the central station, the only output partner monitor to which the selected monitor sends messages and each monitor includes means for storing the identity of the output partner monitor to which the selected monitor sends messages.

5. A communication network according to claim 1, wherein each monitor of the network comprises: A) a message transmitting and receiving device for transmitting and receiving monitor messages or central station messages from neighboring monitors of the communication network and for receiving broadcast messages from mobile broadcast devices within range of the monitor; B) a memory device for storing: a) a unique identity of the monitor, b) a list of the unique identities of each neighboring monitors within range of the monitor, c) the unique identity of each input partner monitor from which the monitor receives messages, d) the unique identity of the output partner monitor to which the monitor sends messages, e) broadcast messages, monitor messages and central station messages, f) a signal strength of each of the broadcast messages received from a mobile broadcast device, g) significant changes in signal strength of each of the broadcast messages, h) an acknowledgement signal to acknowledge receipt of a message from an input partner monitor, and I) a distress signal indicating that the monitor has not received acknowledgement of receipt of a message sent to the output partner monitor; and C) a computer for: 1) measuring the signal strength of each broadcast device message received by the monitor, 2) determining significant changes in the signal strength of each broadcast message, 3) forwarding the broadcast message, signal strength, significant changes in signal strength to the storage device, 4) periodically causing all broadcast messages, associated signal strength and significant changes stored in the memory device to be transmitted to the output partner monitor by the message transmitting and receiving device, 5) forwarding monitor messages received from input partner monitors to the output partner monitor by the message transmitting and receiving device, 6) causing the acknowledgement message stored in the memory device to be transmitted to the output partner monitor, for forwarding to the input partner monitor, by the message transmitting and receiving device upon receipt of a message from the input partner monitor, 7) determining if an acknowledgement signal has been received from the output partner monitor in response to messages transmitted thereto, and 8) for sending a distress signal to all neighboring monitors within range of the monitor if an acknowledgement signal is not received from the output partner monitor; wherein, broadcast messages issued by broadcast devices and received by the monitor directly from broadcast devices within range of the monitor or from input partner monitors are transmitted to the output partner monitor for forwarding to the central station, and wherein, central station messages issued by the central station and monitor-to-monitor messages receive from input monitors are transmitted, if required, to the output monitor.

Patent Citations (2)

Patent	Date	Inventor	Cited By
US5423067	1995-06-01	Manabe
US5710764	1998-01-01	Yoshimura et al.

Abstract

Patent Drawings (90 sheets)