IE83500B1 - A fluid level measurement system - Google Patents

Description

A fluid level measurement svstem INTRODUCTION Field of the Invention The invention relates to measurement systems for sensing a local parameter such as level of a tank and uploading measurement data to a host system.

Prior Art Discussion In the example of fuel tank monitoring, it is desirable for a fuel distribution company to monitor the level of fuel in a consumer's tank on a periodic basis in order to accurately determine the current level or volume of fuel available to the consumer. It is desirable that this information be relayed to the monitoring centre on a periodic basis and as the volume of fuel available falls below preset limits. A principal reason for installing such a system is that the distribution company can determine the exact amount of fuel in the consumer's tank prior to filling and can schedule their delivery fleet in order to minimise delivery costs and maximise profits by avoiding unnecessary stops and attending to tanks that provide the most economic fuel drop size.

Presently available measurement systems for such applications suffer from some or all of:- being difficult to install, requiring a skilled technician, and/ or being expensive, and/ or requiring considerable maintenance, and/ or providing limited useful information.

European Patent Specification no. EPO7lO82O describes a system having a fluid level detector and coupled by RF with a receiver, which in turn transmits uploads to a remote host. It appears that sample values are transmitted almost immediately from the detector, and that there would consequently be a large number of values many of which may not be required in some applications. Also, it appears that effective RF coupling relies on the receiver listening every IS seconds so that a transmission from the detector is unlikely to be missed. This requires a large duty cycle and power consumption. Also, it appears that considerable downstream data processing would be required centrally.

Therefore, one object of the invention is to provide an improved measurement system to overcome these problems.

SUMMARY OF THE INVENTION According to the invention, there is provided a measurement system comprising:- a measurement unit comprising an interface for interfacing with a measurement gauge or a detector, a processor, and a radiation transmitter; a transmitter unit comprising a radiation receiver for communication with the measurement unit, a processor, and a remote communication interface for communication with a remote host system; means in the measurement unit processor for capturing values from a measurement gauge and for directing transmission of corresponding data to the TU via the radiation transmitter; and means in the TU processor for directing reception of said values and for upload of the values to a host system; characterised in that, the measurement unit processor captures a plurality of readings, the measurement unit comprises a memory; the measurement unit processor stores gauge sample values in the memory and processes them to generate a result for transmission to the transmission unit; and the measurement unit processor discards sample values which are outside of an allowable range.

In another embodiment, the measurement unit processor processes sample values by averaging them to provide the result.

In a further embodiment, the measurement unit or the transmitter unit comprise means for storing measurement results as a history log.

In one embodiment, the measurement unit or the transmitter unit comprise means for comparing the results with alarm ranges.

In another embodiment, the measurement unit or the transmitter unit comprise means for tagging measurement results with an alarm tag if the result falls in an alarm range.

In a further embodiment, the transmitter unit comprises means for transmitting an out—of— schedule upload of an alarm signal to a host if an alarm condition is detected.

In one embodiment, the transmitter unit comprises means for polling the MU for measurement results, in which the transmission unit is a master and the measurement unit is a slave.

In another embodiment, the measurement unit and the transmitter unit comprise means for communicating with each other according to a local communication schedule having a base time and successive intervals.

In a further embodiment, each of the measurement unit and transmitter unit comprise real time clocks.

In one embodiment, the measurement unit and the transmitter unit comprise means for communicating for a session duration which expands to allow for loss of synchronism between the clocks due to clock drift.

In another embodiment, the transmitter unit comprises means for parsing received measurement results for alarm tags, and for automatically uploading an alarm signal to a host system if an alarm tag is detected.

In a further embodiment, the transmitter unit comprises means for activating an upload via the remote interface according to an upload schedule having a stored base time and scheduled intervals.

In one embodiment, the measurement unit comprises means for capturing measurement samples according to a measurement schedule.

In another embodiment, the local communication schedule, the upload schedule, and the measurement schedule are independent of each other.

In a further embodiment, the measurement unit comprises means for capturing a temperature reading and for including said reading with a gauge value.

In one embodiment, the transmitter unit and measurement unit processors comprise means for allowing user programming of operating parameters.

In another embodiment, the transmitter unit processor receives revised parameters from a host and either stores them in a non-volatile memory or transmits them to the measurement unit for storage and use.

In a further embodiment, said parameters comprise frequency of measurement unit uploads via the radiation interface, and number of retries for said uploads.

In one embodiment, the measurement unit and transmitter unit processors comprise means for performing self—diagnostics and for uploading diagnostic data to a data centre.

DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:— Fig. l is a schematic representation of a measurement system of the invention; Fig. 2 is a block diagram of a measurement unit of the system; and Fig. 3 is a block diagram of a transmitter unit of the system.

Description of the Embodiments Referring to Fig. l a measurement system 1 comprises a measurement unit (MU) 2 connected to a gas tank gauge 3. The MU 2 regularly communicates wirelessly with a transmitter unit (TU) 4, which in turn communicates via a PSTN network 5 with a remote host system 6. The host system 6 is accessible via distributed workstations 7 and the Internet 8. The TU 4 may additionally or alternatively use a GSM network 9 for uploads.

The main purpose of the system 1 is to upload tank level data so that deliveries can be scheduled in an optimum manner. The system 1 allows the host company to monitor the consumer’s usage of product over time, building a profile of the consumer’s usage patterns, and to set consumer-specific alarm thresholds that will cause the TU to Contact the host 6.

The host 6 can automatically trigger business actions when alarm thresholds are transgressed. Also, it can determine total product volume stored at consumer sites and better manage inventory control, and optimise delivery schedules and delivery routing, thus avoiding panic deliveries due to stock-outs.

The system 1 is beneficial to consumers because it frees the user of the trouble of monitoring their product and re-ordering and it is non—intrusive and does not interfere with the user’s telephone availability.

In addition to measurement of the product level stored at the consumer site the system 1 performs extensive self diagnostics in order to assure the company that the devices are working correctly and will be available when needed. These diagnostic features include gauge/ transducer validation, radio quality analysis, battery voltage monitoring and alarming, battery used capacity monitoring and alarming, and PSTN availability analysis.

Since the field devices MU and TU are dependent on reliable radio and PSTN communications in order to deliver timely data, they perform a number of retries in order to recover from a loss of communication. One feature is that they accurately track the clock drift between the MU and the TU so that they remain synchronised. Also, short—term and long—term recovery strategies are employed in order to re-establish radio communication between the MU and the TU, and to establish a PSTN connection to the host 6.

The MU 2 is battery powered and no external power supply is required. The primary functions of the MU are to take a set of measurements over time and store for delivery, and validate the measurements to ensure that gauge readings are correct. It reports the measurement set to the TU over the radio link on a scheduled basis, and monitors and reports its own device status to the TU. The MU has a range of 200m, and there is no external antenna.

The MU takes its readings as defined by a measurement timetable configured by the user.

This allows different timetables to be used for different classes or categories of consumers.

The measurement timetable is independent of the radio communication schedule, but it is logical to configure the timetable so that a consistent set of results is available when radio communication is due.

When interrogated by the TU, the MU delivers all entries that are present in its store and then Up to 32 readings may be taken and retained by the MU in its reading store. deletes the delivered entries. The reading store is a circular buffer that holds the most recent reading. Thus, if 32 readings exist in the store and a new reading is taken, the oldest will be overwritten. This ensures that the most recent readings are available for delivery.

The measurement timetable contains 6 entries, specifying the hour of the day at which the measurement should be taken. The MU must take at least one entry per day and all entries are taken on the hour. In the event that a reading must be taken at the same time that radio communication is scheduled, the MU will take the reading first and then begin radio communication.

Each reading taken by the MU is made up of a number of gauge samples. The user can specify how many samples are contained in the sample set used to construct one reading.

Each sample is taken at user-defined intervals before the reading result is required. Each sample in the sample set is validated to ensure that it falls within the allowed gauge range. A faulty reading from a gauge will be eliminated from the sample set and will not affect the result. A measurement of the temperature is recorded with each recorded level reading.

The MU communicates to its controlling TU on a scheduled basis as defined by the RF communication schedule chosen by the user. The MU acts as a slave in all communication with the TU and does not make any attempt to initiate communication.

The TU 4 is fitted close to the consumer’s telephone socket and within radio range of the MU 2. The TU is battery powered and so no external power supply is required. The primary functions of the TU are to interrogate the MU and accept its results, and check all received results for alarm breaks. It reports on alarm limit breaks to the host 6, and reports the measurement set to the host 6 on a scheduled basis. Also, it monitors and reports its own device status and those of its MU(s) to the host 6.

Referring to Fig. 2, the MU 2 comprises an ADC 10 for receiving analog measurement signals from the gauge 3 and converting them to digital format for processing. The ADC l0 is connected via a bus ll to a microcontroller 12, an EEPROM 13, and a clock (RTC) 14.

Power is provided by a 3.6 V lithium battery 15, typically providing power for more than five years. A magnetic switch 16 is connected to the power control circuit 17, allowing the user to power on the device for test purposes. The microcontroller 12 is a multi—purpose microcontroller unit with embedded flash running at 8MHz. The microcontroller includes the program code and volatile RAM, and uses the EEPROM for non-volatile memory.

Three serial buses are implemented in software, 21 SP1 bus to control the ADC 10, an IZC bus to control both the RTC 14 and the EEPROM 13 and finally an RS232 to control a radio section 18. The EEPROM 13 shares the 12C bus with the RTC 14. The RTC 14 gives the date and time accurate to a hundredth of a second. The ADC 10 is an 8-bit serial ADC having an internal voltage reference. The radio transceiver 18 performs bi—direction communication. It operates at a frequency of 868.35 MHZ in the license free ISM band.

The mode of operation chosen is OOK (on/ off keying) at 2.4 Kbps. This device can operate reliably for up to 250 meters in free space. Power management circuit is performed by a number of devices, the microcontroller, RTC, and an analogue switch.

Referring to Fig. 3 the TU 4 architecture mirrors that of the MU 2 to a large extent. A radio receiver 30 is connected to a microcontroller 31, in turn connected to a PSTN modem 22 for remote communication with a host system. The modem 32 is operated at its maximum speed of 2400 bps. The modem IC can monitor the telephone line and detect when another device is in use to its line. The line can then be returned to the customer. The TU 4 also comprises an EEPROM 33, an ADC 34 for monitoring battery level and ratio signal strength, and a real time clock (RTC) 35. A magnetic switch 36 and a battery 37 are connected to a power control circuit 38.

MU Operation The MU 2 is programmed with a Radio I.D. that is used during radio communication. This is a two~byte code consisting of a Group ID and a Node ID providing 65535 unique radio addresses. The sensor 3 on the fuel tank is coupled magnetically with a float gauge fitted inside the tank, and provides a visual indication of the tank level and an electrical signal to the MU 2. The MU 2 logs the sensor reading at predefined times and periodically transmits the level history to 21 TU 4 using radio frequencies. The system 1 eliminates fluctuations in the sensor reading due to temperature expansion of the fuel or to friction within the sensor workings by taking a number of sensor samples over time and averaging them to produce the logged level.

This gives the advantage that bad readings due to a disconnected or intermittently defective gauge can be eliminated.

The system 1 also provides a history of logged levels to the host 6. A log of the most recent measurement results can be retained in the MU 2 for transmission to the TU 4, and a log of the most recent 32 measurement results can be retained in the TU 4 for onward transmission to the host 6. This provides a history of logged values taken at pre-determined times to the data centre, eliminating any loss of data due to interrupted radio or telephone transmissions. This gives the advantage that delayed transmission will not result in loss of data, and that a complete profile of the consumer's usage can be built up.

Also, the system 1 provides a temperature measurement with each result value. Each level measurement record includes a reading of the outside temperature at the time of recording.

This gives the advantage that the data centre is provided with the data to determine any correlation between temperature and usage, and that the actual temperature rather than forecast temperature is available.

All measurements are compared with alarm levels preset by the user, each measurement being tagged with its alarm level and any escalation in alarm level will result in an alarm call to the host 6. This alarm call is independent of the scheduled call—in time. Five separate measurement alarm levels and three device diagnostic alarms are used, each of which can be separately enabled or disabled. This gives the advantage that the interval between scheduled calls can be extended, knowing that the device will call in when any exceptional condition OCCUIS.

The system 1 allows the user to set the operating parameters of the radio communications these being written to EEPROM of either unit. The user may program the devices to communicate on the radio interface at predefined intervals and program the devices to make a number of retry attempts in the case of radio failure. This allows the user to define how quickly measurement results are available for communication to the data centre and the effort to be expended in overcoming any temporary radio failures. This has the advantage that the user can choose suitable operating parameters for different classes of consumer or installation.

Also, the system 1 allows the user to set the operating parameters of the telephone communication. The user may program the TU 4 to communicate on the telephone interface at predefined intervals and program the device to make a number of retry attempts in the case of a failed connection. This allows the user to define how often measurement results are relayed to the host 6 and the effort to be expended in overcoming any temporary loss of communication (e.g. line in use).

All operating parameters may be changed by the host 6 by sending the appropriate command at the next call—in. This allows one to change the operation of the system without revisiting the site, e. g. the time of the next call—in can be adjusted based on the criticality of the existing level measurement.

The units 2 and 4 exchange a time record over the radio interface that allows them to remain in synchronisation and minimise activity that would otherwise occur due to clock drift. The system progressively learns the ‘normal’ clock drift and adjusts to minimise this drift, thereby minimising unsynchronised activity ensuring that each activity is completed in the shortest possible duration. This has an advantage that clocks closely remain in synchronisation and device activity, especially radio retry activity, recovery from breaks in the radio path, does not require extended device activity.

The system 1 provides diagnostic information to the data centre about the system itself.

Each device maintains records about its own performance. The MU 2 forwards this to the TU 4 and the TU 4 forwards both sets of performance information to the host 6. The information sent to the host 6 includes device status, battery status, radio status and telephone call status. Any alarms associated with device status result in an immediate call to the host 6. This has the advantage that the host 6 is informed immediately if there is a risk that the devices will cease to report data and can take appropriate action. Also, the system 1 provides a timely warning of impending battery loss to the data centre. The devices maintain a counter of accumulated current consumption and provide an alarm call to the host 6 when the current consumption exceeds an alarm threshold. This provides the advantage that the user is given the opportunity to schedule any device or battery replacements in an orderly manner and this activity can be conducted at scheduled delivery time.

Further, the system provides installation personnel with a fast and efficient installation and test procedure. The MU 2 and the TU 4 include test sequences that may be activated by installation personnel using a magnetic switch. One test sequence supports the use of a separate radio strength tester tool that allows the radio strength from the transmitter location to receiver location to be checked and a suitable installation position to be identified. A second test sequence obtains readings from the gauge, transmits them over radio and telephone to the data centre, and accepts test results from the data centre. These test results can be displayed on the installer’s test tool.

The advantage of this procedure is that suitable locations for radio performance can be easily found, and that the complete functionality of the system from gauge through to the host 6 is tested and verified before the installer leaves site.

The system automatically attempts dialling on PSTN with and without common private exchange prefixes. During test mode, the receiver can attempt to call to the data centre using the programmed number, and if a connection cannot be established, attempt to call using a prefix such as "9". When a connection is established, the prefix is stored in memory for future use. This has the advantage that installation personnel do not need to predetermine whether the installation site requires the use of a dialling prefix to obtain an outside line.

The memories of both the MU and the TU can be used to store fresh configurable settings in response to host 6 downloads. For the MU, the settings are transmitted over the air from the TU. This allows excellent versatility. The following parameters are set at manufacture and may be re—configured from the host.

Measurement Alarm Limits Two high alarm and three low alarm limits can be enforced by the MU. If any measurement result exceeds these limits, the MU attaches an appropriate alarm flag to the measured value before sending to the TU. Each of these limits can be individually enabled or disabled, and can be set to any desired value.

Radio Communication The MU communicates to its controlling TU on a scheduled basis as defined by the RF communication schedule. The RF communication schedule determines how often devices engage in scheduled radio communication and the number of retries to be used if communication could not be established at the scheduled time. The MU acts as a slave in all communication with the TU and does not make any attempt to initiate communication.

TU Operation The TU is programmed with a Radio I.D. that is used during radio communication. This is a two-byte code consisting of a Group ID and a Node ID providing 65535 unique radio addresses. The TU also contains a list of all MUs that may be attached. Each TU is configured with a unique SysremID that is used to identify itself to the office database. This may be any unique 20 character string.

Radio Communication The TU interrogates the MU on a schedule as demanded by the RF communication schedule. When communication is due, the TU will wake and begin to interrogate its MU.

The TU acquires all new measurements since the last communication, the MUS device status and then instructs the MU to return to sleep.

All measurements accepted by the TU are checked for alarm breaks. Only alarm breaks that result in a more critical status will result in an alarm call to the Office. If the alarm status has improved no alarm call to the office will be made. Two high and three low alarm limits can be applied to each MU.

PSTN Communication Scheduled communication to the host occurs according to a configured PSTN communication schedule. The TU can dial two different numbers in order to contact the host 6. If a call cannot be connected to the host, the TU will make a number of retries at regular intervals. When a call is established, the TU identifies itself using its unique SystemID. This code is unique in the host. The host then interrogates the TU for all measurements stored in memory. When these have been delivered to the host, they are deleted from the T U’ s memory. The TU monitors battery voltage and battery capacity used, clock drift, radio packets transmitted and received, and radio status. These are reported to the host 6 when measurements are reported and are used to determine the status and availability of the individual devices.

Up to 6 measurements may be taken per day by the MU. The measurement result times specify at which hours measurement results will be composed. If a measurement result time is specified as 255, then no measurement result is taken at that time.

Samples Per Measurement The accuracy of the measurement can be affected by temporary loss of signal from the gauge.

This depends on the gauge type used and is not a function of the MU hardware. The MU takes a number of sample measurements at intervals specified by the Sample Interval and validates these before composing the measurement result. Each sample is checked to ensure that it is within the allowed sample range (the range covered by the gauge) and if it is outside these limits it is removed from the sample set. The remaining samples are averaged in order to produce the measurement result. If the resulting sample set contains no entries, the measurement will report 0.

Sample Interval The Sample Interval allows the samples in the set to be spaced over time. This reduces the probability that the entire set is made up of erroneous samples. If the sample set is spaced over a long period of time, this can also help to eliminate the changes in the measurement associated with expansion/contraction of the product with temperature and to smooth the results.

Alarm Limits Each measurement is compared against three low alarm limits by the MU or by the TU, as configured by the host 6. If any one of these is newly broken, then an alarm flag will be set in the device. The measurement is tagged with this alarm flag. Each measurement is also compared against two high alarm limits. If any one of these is newly broken, then an alarm flag will be set in the device. The measurement is tagged with this alarm flag.

Measurement Schedule Definition The following data items are included in the measurement schedule.

Measurement Result Time These specify the time in hours that the six measurement results will be composed. The allowed range is 0 to 23. Setting this value to 255 will result in no measurements being taken.

Samples per Measurement Specifies how many samples will be used to compose the measurement. The allowed range is l to 10.

Sample Interval The interval (in minutes) between successive samples. The allowed range is l to 240. Any measurement schedule that specifies a Sample Interval * Samples per Measurement that is longer the minimum duration between successive Measurement Result Times will be rejected by the MU.

Low Alarm Limit Specifies the LowLow Alarm Limit that gauge measurements are compared against. Any gauge measurement that falls below this limit is tagged with the LowLow Alarm flag. The allowed range is O to 255.

Lou/Low Alarm Limit Specifies the LowLow Alarm Limit that gauge measurements are compared against. Any gauge measurement that falls below this limit is tagged with the LowL0w Alarm flag. The allowed range is 0 to 255.

LowL0wLow Alarm Limit Specifies the LowLowLow Alarm Limit that gauge measurements are compared against. Any gauge measurement that falls below this limit is tagged with the LowLowLow Alarm flag. The allowed range is O to 255.

High Alarm Limit Specifies the High Alarm Limit that gauge measurements are compared against. Any gauge measurement that rises above this limit is tagged with the High Alarm flag. The allowed range is O to 255.

HigliHzgh Alarm Limit Specifies the HiglzHz'glz Alarm Limit that gauge measurements are compared against. Any gauge measurement that falls below this limit is tagged with the HighHigh Alarm flag. The allowed range is 0 to 255.

Measurement Procedure The MU will power on at a time to take a measurement sample. The MU powers on, takes a sample from the gauge, and stores the sample in its non-volatile measurement sample memory. The MU contains sufficient memory to hold 10 samples. It also powers on at a time to compose a measurement result. In this case the MU will power on, take a sample from the gauge and store the sample in its non—volatile measurement sample memory. The MU composes its measurement result and stores it in its non—volatile measurement result memory.

Composing the measurement result The MU compares each sample with the allowed range of the gauge and if any sample values fall outside its allowed range, it is marked as bad. The MU calculates the average of all samples that are not marked as bad, producing the measurement result. The measurement result is stored in the MU's non-volatile measurement result memory. If all samples have been marked as bad, the MU uses the most recent sample as its measurement result.

In addition to the averaged gauge reading, the MU measures the temperature at the time of the measurement result and stores this temperature with the result. The measurement result is timestamped with the date and time (to the nearest minute).

Checking against alarm limits The measurement result is checked against the configured alarm limits and an alarm status flag is set. This alarm status flag is stored along with the measurement result. To eliminate transient alarms caused by expansion or contraction due to temperature changes, a deadband is implemented around each alarm limit. The deadband is defined as 4% of full-scale. The following procedure is used to set the alarm flags :- — If an alarm limit has been transgressed the alarm flag is set.

— In order to clear a low alarm flag the value must rise 4% above a low alarm limit.

- In order to clear a high alarm flag the value must fall 4% below a high alarm limit.

— Only the highest priority alarm flag is retained and stored.

Storing the measurement results Each measurement result is stored in the MU's non—volati1e memory. This memory contains position for 32 measurement results. The following sub-items are stored as part of each ITICRSUICIIICIII I€S1llt I- - Date (Year, Month, Day) — Time (Hours, Minutes) — Temperature — Gauge Level - Level Alarm Status When the measurement result memory is full any new measurements will overwrite the oldest measurement in the queue, ensuring that the most recent 32 measurement results are available.

Radio Communication Radio communication occurs according to a schedule downloaded into both the MU's and the TU's configuration memory. This schedule is termed the RF Communication Schedule.

RF Communication Schedule Details Radio Base Time Radio communication operates on a scheduled basis. The schedule is governed by the Radio Base Time and the Radio Scheduled Interval. The first radio communication is attempted at the configured Radio Base Time and all subsequent communication attempts take place at Radio Base Time + N * Radio Scheduled Interval .

Radio Scheduled Interval The Radio Scheduled Interval dictates the interval between radio communication attempts.

The interval is selected from an allowed set [l,2,3,4,6,8,l2,24,48,96 hours] of interval times that ensure that the first daily attempt is made at the same time each day.

Radio Maximum Duration These receivers will remain powered for a session duration (normally 20 seconds). TU acts as the At the scheduled time each unit will wake and power its radio ready to receive. master in all communications and is the first unit to transmit a request. The TU continually sends its requests for a session duration (normally 20 seconds) or until it gets a response.

Once the TU receives a response it regards the sessions as having been established and communication proceeds normally.

If the communication session could not be established (and the time—synch message delivered), a number of retry attempts will be scheduled. These retry attempts will operate with the same session duration. All subsequent communications will operate with an expanded session duration. The session duration is expanded by 8 seconds per day. Thus on day N, the communication attempt will start at the scheduled time but will continue for 20 + (N * 8) seconds. The session duration will continuously expand each day up to a maximum duration as set by the Radio Session Duration. Once communication has been established all units will revert to the initial 20 second session duration. If no response is received to a request, the request is continuously sent until a response is received or the Radio Session Duration is exceeded. If a radio session has not been completed successfully then each participant in the radio session will schedule retries. The MU determines that the radio session is complete when it receives an endCommunications command and has transmitted the response. The TU determines that the radio session is complete when it receives a response to the endCommunications command . As a response is not acknowledged, the MU sends the response to this command 4 times to increase the probability that the TU will receive the response correctly and a graceful termination of radio communication is achieved.

Radio Retry Attempts If a communication does not succeed at the scheduled time, then this number of retry attempts will be made at the retry intervals.

Radio Retry Interval This parameter defines the interval between the start of each radio retry attempt.

RF Communication Schedule Definition The following data must be included in the RF Communication schedule Radio Base Time Specifies the date and time of the first ever radio communication attempt. Any valid date and time after 1 Jan 2000 is allowed.

Radio Scheduled Interval The interval between scheduled radio communications. values are [1, 2 , 3 , 4, 6 , 8, 12,24, 48,96 hours].

Specified in hours and allowed Radio Maximum Duration The maximum duration that the radio session duration can expand to. Specified in minutes.

Allowed values are l,2,3,4 minutes.

Radio Retry Attempts.

Specifies the number of retry attempts to make if scheduled communication is not successful.

Allowed values are 0 to 23.

Radio Retry Interval Specifies the interval, in hours, between the start of each radio retry attempt. Allowed values are l to 24.

If the Radio Retry Attempts * Radio Retry Interval exceeds the Radio Scheduled Interval the RF Communication Schedule will be rejected by the TU or MU.

Radio Identification Details Each TU or MU device identifies itself on radio by a Group and Node number. Each number can range from 1 to 250, providing 250 * 250 different radio identifiers. Any pair of MU and TU devices must have matching Group numbers before they can communicate.

The TU must address the MU explicitly by its Group and Node number before the MU will respond. The MU will respond to any Node that addresses it explicitly.

All packets transmitted on radio are prefaced by routing information that includes :- Group Must match the destination's Group number Source Node Responses will be directed to this node.

Destination Node An destination node.

All devices receiving a packet check the Group and Node addresses and will respond only if they match those that are configured in the device.

Use of Global Radio Identifiers Global addresses are provided for use by test, configuration, installation and maintenance tools. The following addresses are reserved for these tools :- Group Node 0 0..255 25l...255 O..255 Any device receiving a command from one of these source addresses will respond to that address.

Radio Identification Definition Radio Group Specifies the radio group number that the device belongs to. The numbers 1 to 250 are allowed for use by any TU or MU device. The Radz'o Group must be identical in devices that will communicate together on radio.

Radio Node Specifies the radio node number of a particular device within the radio group. The numbers 1 to 250 are allowed for use by any TU or MU device. The Radio Node must be different in devices that will communicate together on radio.

Radio Communication Procedure Both the TU and the MU are configured with identical RF Communication Schedules. Both devices will then power—on together to enable radio communication. Due to some clock drifts within the devices, the devices may not power on perfectly in synchronism. The TU acts as master in the radio communication, sending requests that the MU should respond to.

The MU will respond with a packet containing a positive acknowledgement and optional response data or with a negative acknowledgement. If the TU does not receive an acknowledgement, it will repeat the command until some acknowledgement is received or the Session Duration has been exceeded. If the TU has completed its list of commands within the Session Duration it sends an endCommunication packet and waits 2 seconds for a response. If the TU receives a response to the endCommunication packet, it schedules next radio communication for the next scheduled time. If the TU does not receive a response to endCommunication, it schedules next radio communication for the next retry time or the next scheduled time, depending on which is earlier. On receipt of the endCommunications packet the MU sends its response 4 times, schedules next radio communication for the next scheduled time, and powers off. If the MU does not receive an endCommunication request within the Session Duration , it schedules next radio communication for the next retry time or the next scheduled time, depending on which is earlier.

Determining the Session Duration At the beginning of each scheduled communication, both the TU and the MU examine the time of the last successful communication. The time of the last successful communication is used to expand the Session Duration, by 8 seconds per day, up to a maximum duration specified by the Max Radio Duration parameter. This allows a differential clock drift of 8 seconds per day between TU and MU. At the end of each successful communication attempt, both the TU and MU update the time of the last successful communication.

Scheduled Radio Communication Dialogue During each scheduled radio communication, the TU sends the following commands:— — setTime Synchronises the MU's clock with the TUs clock.

- GetMeasurements Retrieves the measurements stored in the MUs memory. - endCommunication Terminates the dialogue The TU repeats the getMeasurements command until all measurements have been received from the MU.

During the dialogue the TU retrieves the following information from the MU device:- - 0 to 32 measurement records containing :- — a time-stamp of the time the measurements were composed, the temperature at that time, the averaged level measurement at the time indicated by the time—stamp, and - the alarm status associated with the level measurement.

- MU device status at the time of receipt of the endCommunications response containing:- - the battery current consumed, a mAHrs counter indicating current consumed, — the battery voltage, indicating the state of the devices battery, - the MUS device clock drift, in which the MU uses the TU’s time as a reference clock and calculates its own drift from the times delivered by the TU, - the MU's alarm status, indicating whether the MU has any detectable hardware or software error, - the number of packets received by the MU since the last endCommunications response, and - the number of packets transmitted by the MU since the last endCommunications I‘€SpOI'lS€.

If any configuration commands have been downloaded from the host 6 to the TU, the TU may relay these to the MU during the radio dialogue. The TU may change the time at the MU, the measurement schedule, the measurement alarm limits and/ or the measurement alarm mask. The TU may not change the MU’s Radio ID or Radio Schedule.

TU Information Storage The TU stores all measurements received from the MU in its non—volatile memory. It can store up to 32 measurements, and if the 32 locations have been used, the most recent measurements overwrite any older measurements that may exist.

The TU stores one copy of the MU device information in its non-volatile memory, overwriting any MU device information that may already be contained there. This device information is time-stamped by the TU with the time of its receipt.

The TU maintains a copy of the time difference between itself and the MU. This time difference is changed when the TU receives a new time from the control centre and has not yet delivered the updated time to its MU. The TU accumulates these time changes, and uses this time difference when computing the time for the next radio communication, ensuring that time changes delivered to the TU do not cause it to lose communication with its MU.

During the radio dialogue, the TU increments its own transmit and receive counters and, at the end of the dialogue it stores these in non-volatile memory for later transmission to the host 6.

Parsing for Alarms The TU checks all measurement alarm flags retrieved from the MU and will make an alarm call if the alarm status has deteriorated. An alarm call will not be made if the alarm status has improved. An alarm call will be made if :- Alarm status was Alarm Status is now Normal High, HighHigh, Low, LowLow, or LowLowLow Low High, HighHigh, LowLow or LowLow LowLow High, Highl-Iigh or LowLowLow LowLowLow High or HighHigh High HighHigh, Low, LowLow, or LowLoWLow HighHigh Low, LowLow, or LowLowLow Other measurement alarm transitions will not result in an alarm call being made to the host 6. The TU checks the device data received from the MU. If any new device alarm has been raised an alarm call will be made to the host 6. If the radio communication was not successful, the TU checks the time of the last successful radio communication. If the Failure Tolerance time has been exceeded, the TU marks the MU's radio status as faulty and makes an alarm call to the control centre. If the radio communication was successful, the TU stores the current time as the time of the last successful radio communication.

PSTN Communication PSTN communication occurs according to a schedule downloaded into the TU‘s configuration memory. This schedule is termed the PSTN Communication Schedule.

PSTN Base Time PSTN communication operates on a scheduled basis. The schedule is governed by the PS TN Base Time and the PS TN Scheduled Interval The first PSTN communication is attempted at the configured PSTN Base Time and all subsequent communication attempts take place at PS TN Base Time + N * PS TN Scheduled Interval. Alarm calls, discussed below, can operate outside of this schedule.

PSTN Scheduled Interval The PSTN Scheduled Interval dictates the interval between PSTN communication attempts.

The interval is selectable in the range from 1 day to 31 days.

PSTN Maximum Duration At the scheduled time the TU will wake and attempt to dial to the control centre. If the line is free and a connection is made a call duration of from 10 to 20 seconds can be expected. If the line is in use or no connection is made to the control centre, the TU will remain awake for the duration specified by PSTN Maximum Duration in its efforts to contact the host 6.

Once contact has been established with the control centre, the TU will remain on—line and attempt to complete the call, even if the PS T N Maximum Duration is exceeded. To prevent the TU from remaining connected forever, the TU implements two fixed timeout timers :- (a) Loss of carrier, if carrier is lost for more than 5 seconds (b) Connection timeout, once connected the TU enforces a 10 seconds interval between requests from the control centre, if the interval between requests exceeds this time, the TU will hang up.

If the communication session is established and completed successfully, (the TU receives an endCommunication message from the host 6), the next communication session will be scheduled for the next scheduled time. If the communication session could not be established or completed successfully, the next communication session will be scheduled for the next retry time.

PSTN Retry Attempts If a communication does not succeed at the scheduled time, then this number of retry attempts will be made at the retry interval intervals.

PSTN Retry Interval This parameter defines the interval between the start of each PSTN retry attempt.

When all retries have been attempted and successful communication could not be established the TU will programme the next call attempt for the scheduled time on the next day. Thus the TU will make ( PSTN Retry Attempts + l ) total attempts each day, until communication is successful. Once successful, the TU will revert to calling according to the configured PSTN schedule.

Phone Numbers The TU stores two phone numbers that will be called to establish communication with the control centre. (Phone NumberA and Phone Number B). At each connection attempt, the TU will first try on Phone Number A, if no connection is made it will try on Phone Number B, and then cycle between numbers until a connection is established and the dialogue with the control centre is successful.

PSTN Communication Schedule Definition The following data must be included in the PSTN Communication schedule PS TN Base T ime Specifies the date and time of the first ever PSTN communication attempt. Any valid date and time after 1 Jan 2000 is allowed.

PS TN Scheduled Interval The interval between scheduled PSTN communications. Specified in days and allowed values are l to 31 days.

PS TN Maximum Duration The maximum duration of the PSTN connection attempts. Specified in minutes. Allowed values are l,2,3,4 minutes.

PS TN Retry Attempts.

Specifies the number of retry attempts to make if scheduled communication is not successful.

Allowed values are 0 to 23.

PS TN Retry Interval Specifies the interval, in hours, between the start of each PSTN retry attempt. Allowed values are l to 23.

If the PS T N Retry Attempts * PS TN Retry Interval exceeds the PS T N Scheduled Interval the RF Communication Schedule will be rejected by the TU or MU.

Phone Number A Specifies the first phone number to dial when attempting communication. The phone number is a 16 character string, in which the following characters are allowed: ['0‘...'9', ',', 'w']. The ',‘ character specifies that a short waiting period (l50ms) be inserted between dial tones. The ‘w’ character specifies that a long waiting period (2secs) be inserted between dial IODCS.

Phone Number B Specifies the first phone number to dial when attempting communication. The phone number is a 16 character string, the following characters are allowed ['0‘...'9', ‘,', ‘w’]. The ‘,’ character specifies that a short waiting period (l50ms) be inserted between dial tones. The 'w’ character specifies that a long waiting period (2sees) be inserted between dial tones.

PSTN Identification Details Each TU device identifies itself on PSTN by either its SerialNumber or by a SystemID which is programmable by the user. The SerialNumber is programmed into the device at production and is not changeable by the user. The SystemID may be configured in the TU by commands over the radio or PSTN protocols. The user may change this using special tools via the radio protocol or the host 6 may download a special identifier that it has associated with the device.

The host 6 can retrieve either or both the SerialNumber and the SystemID from the TU using the PSTN protocol. Any combination of these can act as a key into the host database.

This allows the user to choose a database key that is logical for their database structure and does not restrict the format of that key to the format of the devices serial number.

PSTN Identification Definition SystemID Customer-specific system identification number resident in the TU configuration memory.

The SystemID is a 20 character string composed of up to 20 ‘printable’ characters.

PSTN Communication Procedure The TU will then power at the appointed time to attempt communication with the control CCHUC.

Making the phone call Before going off—hook, the TU checks that the phone line is free and available for use. If a parallel telephone apparatus is off—hook, or if a ringing tone is detected, the TU will not go off-hook, but will wait for the line to become free. If the PS TN Maximum Duration expires before the line becomes free, the TU will schedule any configured retries and power off.

Once off-hook, the TU waits for a dial-tone and dials the configured Phone Number A. If a busy tone is detected or if the control centre does not answer and connect within 20 seconds, the TU will dial the configured Phone Number B. The TU will alternate between phone numbers until a connection is established.

Once a connection with the host 6 is established, the TU will expect to be polled within 10 seconds. If the host 6 delays more than 10 seconds before sending its first command or between commands, the TU will terminate the call by hanging up. If the modem carrier is lost for more than 5 seconds and cannot be re-established, the TU will terminate the call by hanging up.

The host 6 acts as master in the PSTN communication, sending requests that the TU should respond to. The TU will respond with a packet containing a positive acknowledgement and optional response data or with a negative acknowledgement. If the host 6 does not receive an acknowledgement, it may repeat the command until some acknowledgement is received.

On receipt of the endCommunications packet from the control centre, the TU sends its response, schedules the next PSTN communication for the next scheduled time and powers off. If the TU does not receive an endCommunication request, it schedules next PSTN communication for the next retry time or the next scheduled time, depending on which is earlier.

Scheduled PSTN Communication Dialogue.

During each scheduled PSTN communication, the host 6 may send the following commands:— — getSystemID Retrieves the TU's SystemID. - setSystemlD Sets the TU's SystemID to the new value in the command. - getSerialNumber Retrieves the TU's and MU's serial numbers. — getTime Retrieves the current time from the TU's clock. - setTime Synchronises the TU's clock with the control centre's clock. — getPSTNStatus Retrieves statistics about PSTN call attempts.

- GetDeviceStatus Retrieves TU and MU device information.

- GetRadioStatus Retrieves statistics about the radio link between TU and MU.

— GetMeasurements Retrieves the measurements stored in the MUS memory. — endCommunication Terminates the dialogue.

During normal communication the host 6 should repeat the getMeasurements command until all measurements have been retrieved from the TU.

If configuration needs to be checked or changed the control centre may send any of the following commands :- - getDeviceID Retrieves the radio ID of the TU. — getRadioSchedule Retrieves the TU/ MU radio schedule — getPSTNSchedule Retrieves the TU's PSTN schedule — setPSTNSchedu1e Sets the TU's PSTN schedule - getMeasurementSchedule - setMeasurementSchedule Retrieves the MU's measurement schedule Sets the MU's measurement schedule — getAlarmMasl< Retrieves the list of alarm types that are enabled/ disabled in the TU. — setAlarmMask Sets the list of alarms that are enabled/ disabled in the TU. - getPendingCommand Gets information on any commands that are pending TU/ MU radio comms.

During normal communication the control centre should repeat the getMeasurements command until all measurements have been retrieved from the TU.

During the dialogue the data centre retrieves the following information from the TU device:— — O to 32 measurement records containing :- a time—stamp of the time the measurements were composed the temperature at that time the averaged level measurement at that time the alarm status associated with the level measurement.

— MU device status at the time of the last complete TU/ MU radio communication - the battery current consumed, a mAHrs counter indicating current consumed and therefore implicitly the current remaining. - the battery voltage, indicating the state of the devices battery. - the MUs device clock drift. The MU uses the TUs time a reference clock and calculates its own drift from the times delivered by the TU. — the MU's device alarm status, indicates whether the MU has any detectable hardware of software error — the number of packets received by the MU since the last endCommunications response - the number of packets transmitted by the MU since the last endCommunications response — TU device status at the current time - the battery current consumed, a mAHrs counter indicating current consumed and therefore implicitly the current remaining. - the battery voltage, indicating the state of the devices battery. — the TUs device clock drift. The TU uses the data-centre's time a reference clock and calculates its own drift from the times delivered by the data—centre. - the TU's device alarm status, indicates whether the TU has any detectable hardware of software error - the number of radio packets received by the TU since the last endCommunications response TU since the last — the number of radio packets transmitted by the endCommunications response The system provides many benefits to the distribution company. A profile of the consumer's usage pattern can be built up over time allowing more accurate prediction of their future consumption pattern. An accurate inventory of fuel stored and of unused storage capacity at consumer premises is always available allowing the distribution company to more accurately predict their own purchasing requirements and the timing of bulk purchases. The consumer is relieved of the requirement to periodically read the tank level since this is available at the monitoring centre, allowing the distribution company to proactively schedule deliveries rather than react to consumer orders. Consumer run—outs can be avoided, eliminating expensive emergency deliveries. The distribution company can determine whether any fills have occurred that do not correspond with their own delivery records. consumption patterns, such as under leak conditions, can be highlighted.

The invention is not limited to the embodiments described but may be varied in construction and detail. For example, the system may be used for upload of any other appropriate type of measurement data such as electricity meter reading or oil tank level data. For example, the MU may be a gas meter reader which monitors pulses and increments a totaliser. At predefined times the current total count is sampled and recorded by the MU in its reading store. At predefined intervals, the MU communicates over radio with a nearby TU, delivering the recorded readings and reporting its own operational status. The TU checks the recorded readings for alarm limit breaks and may immediately deliver them to the host or store them for later scheduled delivery. Such an MU is an intrinsically safe device and may be used on all meters that provide a pulse output.

Adaptors are available to provide the required pulses. It requires no external power and is battery powered providing in excess of 5 years of battery life under normal usage conditions. Its radio allows it to communicate over distances in excess of 200 meters (free- field). Also, such an MU may incorporate the features of the MU 2 not associated with level measurements.

Also, the interface between the TU and the host 6 may be Via GSM 9 as shown in Fig. 1.

Alternatively, GPRS or CDMA interfaces may be used. In any of these cases, many of the features of the TU 4 described above apply.

Also, unusual

Claims (1)

1. Claims A measurement system comprising:— a measurement unit (MU, 2) comprising an interface (10) for interfacing with a measurement gauge or a detector, a processor (12), and a radiation transmitter (18); a transmitter unit (TU, 4) comprising a radiation receiver (30) for communication with the measurement unit, a processor (31), and a remote communication interface (32) for communication with a remote host system (6); means in the measurement unit processor for capturing values from a measurement gauge and for directing transmission of corresponding data to the TU (4) via the radiation transmitter (18); and means in the TU processor (31) for directing reception of said values and for upload of the values to a host system (6); characterised in that; the measurement unit processor (12) captures a plurality of readings, the measurement unit (2) comprises a memory; the measurement unit processor (12) stores gauge sample values in the memory and processes them to generate a result for transmission to the transmission unit (4); and the measurement unit processor (12) discards sample values which are outside of an allowable range. A system as claimed in claim 1, wherein the measurement unit processor (12) processes sample values by averaging them to provide the result. A system as claimed in any preceding claim, wherein the measurement unit or the transmitter unit comprise means for storing measurement results as a history log. A system as claimed in any preceding claim, wherein the measurement unit or the transmitter unit comprise means for comparing the results with alarm ranges. A system as claimed in claim 4, wherein the measurement unit or the transmitter unit comprise means for tagging measurement results with an alarm tag if the result falls in an alarm range. A system as claimed in claims 4 or 5, wherein the transmitter unit comprises means for transmitting an out-of—schedule upload of an alarm signal to a host if an alarm condition is detected. A system as claimed in any preceding claim, wherein the transmitter unit comprises means for polling the MU for measurement results, in which the transmission unit (4) is a master and the measurement unit (2) is a slave. A system as claimed in any preceding claim, wherein the measurement unit and the transmitter unit comprise means for communicating with each other according to a local communication schedule having a base time and successive intervals. A system as claimed in claim 8, wherein each of the measurement unit and transmitter unit comprise real time clocks (14, 33). A system as claimed in claim 8 or 9, wherein the measurement unit and the transmitter unit comprise means for communicating for a session duration which expands to allow for loss of synchronism between the clocks due to clock drift. A system as claimed in any of claims 6 to 10, wherein the transmitter unit comprises means for parsing received measurement results for alarm tags, and for automatically uploading an alarm signal to a host system (6) if an alarm tag is detected. A system as claimed in any preceding claim, wherein the transmitter unit comprises means for activating an upload via the remote interface according to an upload schedule having a stored base time and scheduled intervals. A system as claimed in any preceding claim, wherein the measurement unit comprises means for capturing measurement samples according to a measurement schedule. A system as claimed in any of claims 8 to 13, wherein the local communication schedule, the upload schedule, and the measurement schedule are independent of each other. A system as claimed in any preceding claim, wherein the measurement unit comprises means for capturing a temperature reading and for including said reading with a gauge value. A system as claimed in any preceding claim, wherein the transmitter unit and measurement unit processors comprise means for allowing user programming of operating parameters. A system as claimed in claim 16, wherein the transmitter unit processor receives revised parameters from a host and either stores them in a non—volatile memory or transmits them to the measurement unit for storage and use. A system as claimed in claim 16 or 17, wherein said parameters comprise frequency of measurement unit uploads via the radiation interface, and number of retries for said uploads. A system as claimed in any preceding claim, wherein the measurement unit and transmitter unit processors comprise means for performing self-diagnostics and for uploading diagnostic data to a data centre. A measurement system substantially as described with reference to the drawings.