Methods and apparatus to analyze recordings in leak detection

Methods and apparatus to analyze recordings in leak detection are disclosed. An example apparatus includes a leak detection sensor to record a plurality of recordings and a memory. The example apparatus also includes a processor to convert one ore of the plurality of recordings to a corresponding one or more spectral representations, calculate a spectral average based, at least in part, on the one or more spectral representations, store the spectral average to the memory, and generate a data packet based, at least in part, on the spectral average. The example apparatus also includes a transceiver to transmit the data packet to another device.

FIELD OF THE DISCLOSURE

This disclosure relates generally to leak detection and, more particularly, to methods and apparatus to analyze recordings in leak detection.

BACKGROUND

Some known leak detectors employ acoustic sensors to detect noise and/or characteristic sounds, which may be indicative of a potential leak. In particular, these leak detectors are usually coupled to a pipe and/or portion of a fluid delivery system and typically utilize amplitude and/or a time-history of acoustic signals to determine a presence of a potential leak. However, many known leak detectors do not analyze and/or characterize waveforms in such an analysis.

In particular, the known leak detectors do not taken into account ambient/environmental noise, which can mask and/or provide false indications of a leak. Further, many known leak detection systems and/or sensors cannot distinguish characteristic noise that may be inherent in a particular system from leak noise(s). As a result, these leak detectors may be inaccurate and/or inherently lack capabilities of characterizing a condition of a respective fluid delivery system.

SUMMARY

An example apparatus includes a leak detection sensor to record a plurality of recordings and a memory. The example apparatus also includes a processor to convert one or more of the plurality of recordings to a corresponding one or more spectral representations, calculate a spectral average based, at least in part, on the one or more spectral representations, store the spectral average to the memory, and generate a data packet based, at least in part, on the spectral average. The example apparatus also includes a transceiver to transmit the data packet to another device.

In some examples, the other device is a remote server or an endpoint coupled to a utility meter. In some examples, the endpoint or remote server is to compare information in the data packet to a baseline spectral average to determine a leak condition. In some examples, the processor is to compare the spectral average to a previously stored baseline spectral average to determine a leak condition.

In some examples, the comparison includes subtracting the previously stored baseline spectral average from the spectral average. In some examples, the processor is to reject one or more of the plurality of recordings or the one or more spectral representations prior to calculating the spectral average. In some examples, the processor is to direct the leak detection sensor to record additional recordings based, at least in part, on the rejection of the one or more of the plurality of recordings.

In some examples, the processor is to update a previously stored baseline spectral average based, at least in part, on the spectral average. In some examples, the example apparatus also includes a battery operatively coupled to the processor and the leak detection sensor. In some examples, the example apparatus also includes circuitry to receive power from an external device.

In some examples, the processor is to select one or more times to record the plurality of recordings based, at least in part, on one or more of a time of day, one or more previous recordings, and one or more previous spectral representations. In some examples, the processor is to transmit the selected one or more times to record the plurality of recordings to an external device.

In some examples, the leak detection sensor includes an accelerometer. In some examples, the transceiver is to receive a known signature, where the processor is to make a comparison based at least in part on the spectral average and the known signature, and the processor is to determine a leak condition based, at least in part, on the comparison. In some examples, a previously stored baseline spectral average is subtracted from the spectral average to make the comparison.

In some examples, the processor is to exit an off power state based upon a supply of power from an external device and to return to the off power state after transceiver transmits the packet. In some examples, the processor is to encode a bias flag into the data packet based, at least in part, on a number of recordings of the plurality of recordings being less than a threshold number.

In some examples, the memory includes non-volatile memory. In some examples, a fluid utility measuring device includes the example apparatus.

The figures are not to scale. Instead, to clarify multiple layers and regions, the thickness of the layers may be enlarged in the drawings. Wherever possible, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

Methods and apparatus to analyze recordings in leak detection are disclosed. Known leak detectors and/or systems often use sound amplitude to determine a presence of a leak in a fluid delivery system. However, many of these known systems cannot distinguish characteristic acoustic measurements and/or noise inherent in a particular system, thereby rendering potential inaccuracies in such systems. Further, known systems may be susceptible to false alarms and/or undetected leaks resulting from environmental and/or background noise.

The examples disclosed herein enable very accurate determination of leak conditions by removing uncertainty typically present in leak detection systems. The examples disclosed herein provide an effective and accurate manner of determining leak conditions and/or a presence of a leak in fluid utility measuring systems by characterizing inherent properties of such systems, which may pertain to environment, implementation and/or typical use. In particular, the examples disclosed herein utilize learning to generate spectral averages (e.g., baseline noise profiles, baseline spectral averages) that are unique to each particular system. Accordingly, these baseline measurements are collected over time (e.g., a few hours, a few weeks, a months, etc.) to fully characterize unique acoustic recordings/signatures inherent for a corresponding system. As a result, the examples disclosed herein account for random, environmental, usage and/or event-related noise.

The examples disclosed herein utilize a leak detection sensor, which may be utilized as an acoustic sensor or a pressure sensor, to record or measure multiple recordings (e.g., recording signatures) that are converted to spectral representations and, in turn, the spectral representations are used to generate spectral averages.

According to the examples disclosed herein, the leak detection sensor is to record or measure recordings that are converted spectral representations to generate a spectral average of the recordings. In particular, a current spectral average (e.g., a recent spectral average, today's spectral average, etc.) may be generated, for example. In turn, the current spectral average may be packaged or encoded into a data packet that is transmitted to be compared to a baseline spectral average to determine a leak condition. In some examples, this comparison occurs at a remote server. In other examples, this comparison occurs at the leak detection sensor itself.

In some examples, recordings may be recorded during a defined or known time period (e.g., within a certain time of installation) to define the aforementioned baseline spectral average such that baseline characteristics of an individual system (e.g., a node of a utility system, a utility system, a utility measuring system) are determined. In particular, the plurality of baseline recordings may be averaged by canceling and/or reducing noise present in the plurality of baseline recordings. These determined baseline characteristics are factored into leak determination(s), thereby greatly increasing accuracy thereof.

In some examples, the current spectral average is compared to a known signature (e.g., a known leak signature), which may be downloaded and/or received via a network. In such examples, determination of the leak condition may be at least partially based on this comparison between the known signature and the current spectral average. For example, the signatures and/or a database of the signatures may be stored in non-volatile memory corresponding to the leak detection sensor. In particular, the database may be referenced when analyzing/comparing the current spectral average.

In some examples, adaptive sampling/recording is performed by the leak detection sensor to vary a data acquisition mode of the leak detection sensor. In particular, a polling rate, a power use mode and/or power provided (e.g., an amount of power) to the leak detection sensor may be varied based on parameters related to a current recording and/or a difference between the current spectral average and the baseline spectral average. For example, an amplitude and/or a significant shift from the baseline spectral average may trigger a change in a power mode of the leak detection sensor.

Additionally or alternatively, a polling rate (e.g., a scan rate) of the leak detection sensor may be varied based on the current recording (e.g., the current recording exceeds a threshold amplitude) and/or the current spectral average. Additionally or alternatively, operation and/or parameters (e.g., power use mode(s), polling rates, etc.) of the leak detection sensor may be varied based on a time of day (e.g., the leak detection sensor is triggered from 1 am to 4 am based on lack of external noises during that time, etc.). In some examples, the leak detection sensor transmits a determined time of day to an external device (e.g., the leak detection sensor transmits the determined time of day to an endpoint so that the endpoint may “wake” the leak detection sensor).

Additionally or alternatively, the data acquisition mode and/or recording parameters may change within a session as a pattern is detected (e.g., a step change from past historical recordings) within the session to the current recording. Additionally or alternatively, factors such as pipe diameter, material, fluid pipe content, whether the pipe is carrying fluid or gas, and/or temperature (e.g., environmental temperature, pipe temperature, fluid temperature, etc.) varies an operating mode of the leak detection sensor (e.g., polling rate, sampling rate, signal filtering, recording method, etc.).

As used herein, the term “recording” refers to a measured or recorded signal or time-history that corresponds to a time period (e.g., a pre-defined time span). Accordingly, the term “recording” may be stored temporarily (e.g., in random access memory) or in a tangible medium, and may be represented or characterized over a frequency domain, for example. As used herein, the term “spectral average” refers to an averaged signal waveform.

As used herein, the terms “current recording” and “current spectral average” refer to a signal, plurality of signals and/or averaged signals defined or computed subsequent to a baseline characterization period. As used herein, the terms “baseline recording” or “baseline spectral average” refer to a signal, plurality of signals and/or averaged signals defined or computed during a known time period and/or during a learning time period (e.g., a time period around an installation time period).

FIG. 1is a schematic overview of an example utility measuring system100in which the examples disclosed herein may be implemented. According to the illustrated example ofFIG. 1, the utility measuring system100is to characterize and/or monitor a condition of a utility delivery system (e.g., a utility fluid delivery system, a utility delivery node, etc.)101. The example utility measuring system100includes a sensing module102that is coupled to a pipe103(of the utility delivery system101) and includes an analysis module104, and a first bi-directional communication link106that communicatively couples the sensing module102to an endpoint (e.g., a utility measuring endpoint, a communication endpoint, a utility endpoint, etc.)108. The example utility measuring system100also includes a second bi-directional communication link110that communicatively couples the endpoint108to a server (e.g., a remote server, a data collection facility, etc.)111. The example server111includes a head end (e.g., a server gateway, etc.)112and a remote server114, both of which are coupled together via a connection116, such as a file transfer protocol (FTP) in this example.

In this example, the first bi-directional communication link106is implemented as a wired cable and the second bi-directional communication link110is implemented as a radio frequency (RF) link. However, any appropriate communication link and/or server/network topographies may be utilized to implement (e.g., a wired or wireless implementation thereof) the communication connections/links106,110,116instead.

To characterize a condition (e.g., a baseline or current/operating condition) of the fluid delivery/utility system101, the sensing module102of the illustrated example utilizes a sensor to record or measure (e.g., acoustically measure) multiple recordings (e.g., time-domain recordings) from a section or portion of the fluid delivery/utility system101to define a spectral average, for example. According to the illustrated example, the spectral average is generated based on converted spectral representations of the recordings.

In this particular example, the sensing module102is coupled to a pipe of the fluid delivery/utility system101. According to the illustrated example, and as will be discussed in greater detail below in connection withFIGS. 3-9, the analysis module104performs averaging of known or baseline recordings to define a spectral average (e.g., a baseline spectral average) that may be used in comparisons with current recordings and/or current spectral averages to determine a leak condition of the fluid delivery/utility system101, for example.

In some examples, the analysis module104packages or encodes the current recordings, spectral representations and/or spectral average(s) (e.g., for later transmission to the remote server114) into a data packet. Additionally or alternatively, the analysis module104controls parameters of the sensing module102based on current recording measurements (e.g., a measured amplitude of a current recording) or averages. For example, the analysis module104may direct an increase or increase of a polling frequency and/or control a power mode of the sensing module102based on the measurements (e.g., an increased polling frequency based on a sudden increase in amplitude of the measurements).

To transmit the recordings, the spectral representations, the spectral averages and/or determined condition(s) to the example server111(e.g., to the server111for later analysis), the sensing module102transmits the aforementioned data packet to the endpoint108via the bi-directional communication link106and, in turn, the endpoint108transmits this data packet to the server111via the bi-directional communication link110. In some examples, the head end112then forwards the data packet to the remote server114. In particular, the data packet may be utilized and/or analyzed at the remote server114, which may be located at a utility control center/facility, to convey a condition of an overall utility node/network and/or direct maintenance crews for repair work need, for example.

In some examples, the analysis module104is implemented on the endpoint108or the server111. In some examples, operational functionality of and/or analysis that is at least partially performed by the analysis module104is distributed across the sensing module102, the endpoint108and/or the server111(e.g., a distributed analysis/computation topography). Additionally or alternatively, in some examples, the endpoint108is integral with the sensing module102. In some examples, the sensing module102includes circuitry to receive power from the endpoint108and/or other external device.

FIG. 2is a transparent view illustrating the example sensing module102of the example utility measuring system100ofFIG. 1. The sensing module102of the illustrated example includes a housing202, the bi-directional communication link106, a coupler (e.g., a pipe clamp)204and a pipe fitting (e.g., a pipe clamp, a coupling section, etc.)206that is coupled to the pipe (e.g., a utility pipe, a water pipe, etc.)103. According to the illustrated example, the coupler204aligns, secures and/or couples the sensing module102and/or the housing202to the pipe fitting206so that measurements or recordings related to the pipe103and/or the overall fluid delivery/utility system101may be performed or directed by the sensing module102.

In operation, fluid generally flows along a longitudinal length of the pipe103and through the pipe fitting206in this example. In turn, the example sensing module102records and/or analyzes data (e.g., spectral data) related to this fluid flow to characterize an operating condition of the utility delivery/consumption system101. As a result, data associated with this recording, which may be in the form of a data packet (e.g., a spectral data packet, a packet that includes compressed data), is transmitted to the endpoint108ofFIG. 1. The communication link106of the illustrated example provides power to the sensing module102and may be used to provide commands to and/or control operation of the sensing module102. In some examples, the sensing module102may be directed by the endpoint108, the head end112and/or the remote server114to increase a polling/sensing rate and/or enter a low power mode, for example.

In some examples, the housing202is substantially environmentally sealed (e.g., hermetically sealed). Additionally alternatively, the housing202may be sealed to the coupler204in some examples. In other examples, the sensing module102is directly coupled to the pipe103or is defined in the fitting206.

FIG. 3is an exploded view of the example sensing module102shown inFIGS. 1 and 2. The sensing module102of the illustrated example includes a removal grommet302, the housing202, the communication link106, a lid306, a circuit board (e.g., a printed circuit board)308that includes the analysis module104, a sensor310, a housing portion312, a mechanical coupler or fastener314and a mount assembly316, which is to be coupled to the coupler204shown inFIG. 2via the fastener314in this example.

According to the illustrated example, to measure or record recordings/data associated with fluid delivery operation, the sensor310, which is implemented as an acoustic sensor in this example, is operatively coupled to the pipe fitting206and/or the pipe103. In this example, the sensor310records and/or measures recordings corresponding to the fluid delivery/utility system101. In this example, the sensor310records vibration signals (e.g., vibrations, vibration recordings, vibration waveforms, processed vibration signals, sound, etc.) to be used in characterizing a leak condition of the pipe103and/or the respective fluid delivery/utility system101. In particular, the example sensor310may record at least one recording based on a pre-defined or designated time period. In some examples, the recording may be converted (e.g., transformed) to a spectral representation to characterize the vibrational and/or acoustic signal over a frequency domain (e.g., relating amplitude of the vibrational and/or acoustic signal to frequency). In particular, the recording may be converted from a time-domain sample to a frequency domain.

In this example, to characterize, analyze and/or determine a leak condition, circuitry of the circuit board308, which includes the analysis module104shown inFIG. 1, receives a plurality of baseline recordings measured at the sensor310. In turn, the circuit board308utilizes this plurality of baseline recordings to be converted to corresponding spectral representations for generating a baseline spectral average and/or baseline noise signature. Such a process is described in detail below in connection withFIG. 6. In this example, the baseline spectral average is transmitted to the remote server114as a first data packet.

In this example, the sensor310also measures current recordings subsequent to the generation of the baseline spectral average and, in turn, converts the current recordings to respective spectral representations that are used to generate a current spectral average, which is also generated using the process described below in connection withFIG. 6. In particular, the current spectral average may be generated and stored over a periodic basis (e.g., every day, every week, etc.). In this example, the current spectral average is transmitted to the remote server114as a second data packet. According to the illustrated example, the current spectral average is then compared to the baseline spectral average by the remote server114to determine the leak condition.

Additionally or alternatively, the current spectral average is compared to a known signature (e.g., a known leak signature), which may be characterized in the time domain or frequency domain. In particular, this known signature may correspond to an expected spectral signature based on a known parameter. For example, a square wave in the time domain may be representative a spinning disk of a utility water meter. In another example, a pronounced 60 or 120 Hertz (Hz) in the frequency domain may indicate electrical/power noise. Additionally or alternatively, the known signatures may take into account geometry (e.g., diameter, cross-sectional profile, length etc.) and/or material(s) (e.g., plastic, metal, etc.) of pipes. In some examples, the circuit board308stores the aforementioned known signature, which may be received and/or downloaded from the remote server114. Additionally or alternatively, the baseline spectral average is subtracted from the current spectral average prior to making this comparison. In some examples, the current spectral average is compared to historical spectral averages and/or recordings.

In examples where the determination of the leak condition is performed solely at the circuit board308, to transfer the determined leak condition so that appropriate actions may be taken (e.g., service related actions), the circuit board308transmits data associated with the determined leak condition to the end point108via the communication link106. In some examples, the circuit board308encodes and/or compresses this data to be included in a data packet for transmission.

While the sensor310of the illustrated example is described as a vibrational sensor in this example, the sensor310may be implemented as any other appropriate sensor type such as a pressure sensor, a sound sensor and/or a temperature sensor, for example, may be used. In some examples, the sensor310includes an accelerometer, which may be implemented as piezo-electric accelerometer, a micro-electromechanical system (MEMS) device, a ceramic accelerometer, or any other appropriate type of accelerometer, etc. In some examples, the sensor310is integral with the circuit board308.

FIG. 4is a plot400representing example signal acquisition and analysis in accordance with the teachings of this disclosure. In particular, adaptive sampling of obtaining recordings that is performed by the sensor310to enable the circuit board308to generate a spectral average a spectral noise signature), which may be used to define a baseline spectral average or a current spectral average, over different recording session types is demonstrated. Further, the example plot400also illustrates example sensor initiation that may be implemented in the examples disclosed herein. In the view ofFIG. 4, a legend401representing signal recording classifications and a time scale402representing a time of day are shown.

According to the illustrated example, a first example recording session404is shown over a portion of the time scale402. A signal plot (e.g., a measured plot, a measured recording, a recorded section, etc.)406of recording measurements is characterized by its regions or portions406a,406band406c. In the region406a, the signal plot406exhibits relatively flat behavior. As can be seen in the region406bofFIG. 4, the signal plot406decreases and crosses a threshold (e.g., a set point) and/or threshold range, and generally levels out and/or flattens along the region406c. Accordingly, a corresponding recording mode408shows an increase in polling of the sensor310(e.g., an increased data acquisition rate of the sensor310) based on a transition from the region406bto the region406c, for example. In this particular example, an amplitude above a threshold level triggers a recording session to begin and subsequent movement across one or more thresholds causes a polling rate to vary.

A second example recording session410involves a signal plot412remaining within a threshold range and, in turn, a polling frequency shown in a corresponding recording mode414does not change, in contrast to the example recording session404. In this example, approximately 10-20 recordings (e.g., sixteen recordings) are needed to develop the spectral average and/or noise profile. However, any appropriate number of samples may be used since the appropriate number of recordings can be dependent on application or use.

A third example recording session420shows a signal plot422having corresponding noisy regions422aand422b. In this example, a corresponding recording mode424indicates noisy recordings426, both of which are discarded/rejected. Accordingly, to obtain a proper number of recordings in this example, the sensor310is directed to measure and/or append recordings428based on the deletion of the noisy recordings426.

In some examples, a recording session is initiated based on a measured amplitude exceeding a threshold (e.g., an absolute peak amplitude in the time domain may be utilized). In some examples, when periods pertaining to relatively low amplitude measurements (e.g., quiet periods) are subsequently followed up with a relatively large amplitude signal, a recording session is initiated.

In some examples, if a recording session ends up noisy and/or faulty (e.g., the recordings426), configuration data and/or operating parameters of the sensor310(shown inFIG. 3) may be adjusted by the circuit board308to increase a probability of less-noisy signals measured at the sensor310, for example. In some examples, indication of a faulty recording session and/or incomplete recording data (e.g., a lower number of recordings than a requisite number, a disconnect, etc.), may trigger a bias flag to be transmitted (e.g., added or encoded to a data packet that is transmitted).

In some examples, if a recording session is successful, the associated data and/or recording session data is converted to and/or analyzed within the frequency domain to define at least one spectral representation. Additionally or alternatively, associated spectral energy is examined and may be weighted to an array of the following values: [−1 0 1], for example. In particular, for the spectral energy measurements with central tendencies (e.g., falling within expected statistical bounds), the corresponding spectral representation and/or recording is given a weighting value close to 0 (e.g., a value of 0). Accordingly, higher spectral energy recordings and/or corresponding spectral representations may be weighted with a positive value while, in contrast, lower spectral energy recordings and/or corresponding spectral representations may be weighted with a negative value.

In some examples, root-mean-square (rms) data associated with the recordings is analyzed and/or examined. In such examples, if the rms variance is low, a minimal change in signal amplitude may be determined. Additionally or alternatively, summing a combination of spectral weighting as well as rms variance may indicate a value indicating data fit quality (e.g., a “goodness” of fit).

In some examples, recording times and/or time period(s) of the day to record are selected based on a time of day, one or more previous recordings and/or one or more previously generated spectral representations. In such examples, the selected recording times (e.g., time of day) may be transmitted to an external device (e.g., so that the external device may trigger the leak detection sensor310and/or the sensing module102to turn on).

Any aspect described above with respect to any of the example recording sessions404,410and420may be used in collecting recordings and/or developing spectral representations to generate spectral averages that pertain to a baseline (e.g., known condition) spectral average or a new/current spectral average (e.g., today's spectral average from 2 am to 4 am, etc.). In particular, the collected and/or sorted recordings may be processed using any combination of the techniques described above to generate the aforementioned averaged recordings.

In some examples, fault-indicating recordings indicating abnormal operation, improper installation and/or misplacement of the sensor310and/or the sensing module102trigger a warning and/or flag to indicate that the recordings obtained are faulty and/or may result in generation of faulty spectral representations and/or averages. Additionally or alternatively, these fault indicating recordings may trigger a reset of the sensor310and/or the sensing module102.

FIG. 5is a graph500representing a signal recording comparison that may be implemented in the examples disclosed herein. In particular, this comparison may be performed by the remote server114or the circuit board308. According to the illustrated example, the graph500shows an example comparison of a baseline spectral average to a current spectral average (e.g., recordings averaged within the last day). According to the illustrated example ofFIG. 5, the graph500includes a legend501, a horizontal axis502, which indicates an acoustic amplitude, and a horizontal axis504that indicates an acoustic frequency in hertz (Hz). In this example, the current spectral average and the baseline spectral average are characterized, compared and/or analyzed in the frequency domain.

In the example graph500ofFIG. 5, a current spectral average plot506is shown in relation to an averaged baseline spectral plot (e.g., an acoustic profile corresponding to the pipe103ofFIGS. 1 and 2)508. In this example, a difference between current spectral average plot506and averaged baseline spectral plot508is used to determine a leak condition of a corresponding fluid delivery system. In other words, a significant difference, variance and/or a degree to which the current spectral average plot506and the averaged baseline spectral plot508differ may indicate an overall condition of the fluid delivery system his example, the averaged baseline spectral plot508is subtracted (e.g., via a spectral subtraction) from the current spectral average plot506to determine this difference.

In some examples, the difference between the current spectral average plot506and averaged baseline spectral plot508is determined and/or calculated by taking an integral of a difference between the current spectral average plot506and averaged baseline spectral plot508(e.g., an integral average of the differences). In other words, sum areas of the current spectral average plot506and averaged baseline spectral plot508may be subtracted from one another to determine the difference. Additionally or alternatively, overall shapes of waveforms corresponding to the current spectral average plot506and the averaged baseline spectral plot508are compared to one another to determine this difference.

In some examples, the difference between the current spectral average plot506and the averaged baseline spectral plot508is determined by quantifying a maximum numerical difference in amplitude. In particular, the maximum difference at a certain frequency between the current spectral average plot506and the averaged baseline spectral plot508may be selected to determine a leak condition, for example.

Additionally or alternatively, at least one peak and/or characteristic shape of the current spectral average plot506is tracked as it shifts over time (e.g., while generally retaining aspects of its characteristic waveform) and this shift is taken into account when comparing the current spectral average plot506to the averaged baseline spectral plot508. In such examples, spectral tracking can be effective at tracking peak and/or waveform shifts based on edges of the current spectral average plot506that are clearly defined in the frequency domain.

In some examples, time-domain recordings corresponding to the averaged baseline spectral plot508and/or the current spectral average plot506are processed/transformed with a fast Fourier transform (FFT) for later characterization and/or comparison.

FIG. 6illustrates an example result of an averaging process that may be implemented in the examples disclosed herein. In particular, the example ofFIG. 6demonstrates how multiple recordings that are converted to spectral representations can then be averaged to generate a spectral average, which may correspond to either a baseline spectral average or a current spectral average. In other examples, the recordings and/or spectral representations may be normalized (e.g., amplitudes represented as ratios of one) instead of averaged.

As can be seen inFIG. 6, spectral representations602,604and606are shown, which correspond to first, second and sixteenth recordings, respectively, in this example. An averaged frequency plot602a, which corresponds to the first spectral representation602, is similar and/or identical to the averaged frequency plot602abecause there have not yet been any other samples to average with.

A second averaged frequency plot604acorresponds to an average including the spectral representation602and the spectral representation604. However, in this example, not enough measurements have been taken to generate a fully-defined baseline spectral noise average.

A third averaged frequency plot606acorresponds to sixteen recordings, which include the spectral representations602,604and606, as well as additional spectral representations not shown. According to the illustrated example, the third averaged frequency plot606aexhibits a relative flat region608and a well-defined peak610(between 300 and 400 Hz) that is disposed between portions of the flat region608. As a result, the corresponding spectral average is well-defined (e.g., fully-defined).

Accordingly, the third averaged frequency plot606amay be used as an averaged baseline spectral average to be compared to a current spectral average to determine a leak condition. Alternatively, the third average plot606amay define the current spectral average that is compared to another baseline spectral average. In this example, taking a significant and/or requisite amount of recordings enables noise (e.g., environmental noise, random noise, etc.) to be effectively canceled out and/or smoothed out. In other words, the randomness of multiple recordings and/or their associated spectral representations effectively removes random noise from inherent or characteristic system noise, thereby enabling very accurate baseline or known scenario characterization. While sixteen recordings/signatures are described in this example, any appropriate number of recordings may be used based on accuracy needs and/or inherent characteristics of a respective fluid delivery system.

In some examples, different recordings and/or associated spectral representations are weighted differently. In particular, a recording, which may be associated with a known baseline time period, historical and/or older in time, may have a greater weighting factor than later added recordings, for example. In some examples, similar recordings and/or associated spectral representations are grouped together (e.g., assigned a particular number based on similar amplitudes and/or waveforms), thereby defining grouped recordings or representations. Additionally or alternatively, these grouped recordings or spectral representations are designated a number or label (e.g., 127) that can be incremented based on increasing amplitudes (e.g., 127+1). In these examples, these grouped recordings or spectral representations may be averaged or normalized together to define a grouped spectral average.

FIG. 7is a schematic overview of the example analysis module104ofFIG. 1that may be used to implement the examples disclosed herein. The example analysis module104of the illustrated example includes a spectral signal calculator702, which includes a spectral signal pre-processor704, and a spectral signal analyzer706and a condition comparator708.

The example analysis module104also includes a recording or signature storage709and an encoder/transmitter710that is communicatively coupled to the spectral signal calculator702via a communication line714. Further, the example encoder/transceiver710is communicatively coupled to the condition comparator708via a communication line712. Also, the sensor310ofFIG. 3is shown communicatively coupled to the spectral signal pre-processor704via a communication line716. Further, the encoder/transceiver710is communicatively coupled to the endpoint108via a communication line718.

To obtain a requisite amount of recordings (e.g., time-domain recordings) to be converted to associated spectral representations to sufficiently define or generate a spectral average, the sensor310of the illustrated example provides a plurality of recordings to the spectral signal pre-processor704so that each recording of the plurality of recordings is converted to a respective spectral representation. In turn, the spectral signal pre-processor704determines whether the spectral representations and/or the recordings meet noise and/or waveform requirements and collects a requisite number (e.g., 10-20, 100, 1000, etc.) of the recordings from the sensor310that are needed to generate a well-defined spectral average (e.g., a current spectral average, a baseline spectral average). Additionally or alternatively, the spectral signal pre-processor704directs and/or controls operating parameters of the sensor310. For example, the spectral signal pre-processor704may control a polling frequency and/or power consumption mode (e.g., a low power mode, etc.) of the sensor310based on at least one recording and/or an associated spectral representation. Accordingly, the spectral signal pre-processor704acts as power controller of the sensor310in these examples. Additionally or alternatively, the sensor310is to exit an off power state based upon a supply of power from an external device (e.g., the endpoint108) and to return to the off power state after a data packet is transmitted, for example.

To generate the spectral average/signature, the example spectral signal analyzer706averages multiple spectral representations by performing averaging techniques shown and described in connection with the example ofFIG. 6. In this example, the spectral signal analyzer706receives multiple spectral representations of recordings that have been sorted and/or pre-processed by the example spectral signal pre-processor704to generate the spectral average. Additionally or alternatively, these pre-processed recordings, the respective spectral representations and/or the generated spectral average is stored in the recording storage709and retrieved therefrom (e.g., retrieved to be packaged with a later measured current spectral average).

To determine a leak condition and/or operational status, the condition comparator708of the illustrated example compares the current spectral average to the baseline spectral average. In this example, this determination is based on a degree to which the current spectral average varies from the baseline spectral average. Once this leak condition has been determined, the condition comparator708transmits the determined leak condition and/or a packet containing the current spectral average to the encoder/transceiver710which, in turn, forwards this data to the endpoint108ofFIG. 1. In some examples, the baseline spectral average is updated to be the current spectral average. For example, similar consecutive current spectral averages and/or significant differential changes in current spectral averages may cause this update to occur.

In some examples, the current spectral average is compared to a historical recording and/or spectral average to determine the leak condition. Additionally or alternatively, a previously saved recording is retrieved from the recording storage709and/or spectral data packets are retrieved or transmitted for leak condition determinations.

In some examples, overall energy of a spectral average may be taken into account for leak condition determination. In such examples, seasonal variations, noise variations, etc. may be taken into account.

Additionally or alternatively, in some examples, known signature(s) are stored in the recording storage709and may be retrieved and transmitted (e.g., transmitted upon request, etc.). In such examples, the condition comparator708compares the known signature to the current recording, spectral representation and/or spectral average. The known signature may be selected from the storage709based on one or more operating parameters, which may include, but is not limited to, pipe diameter, pipe structure, pipe material(s), overall utility delivery design parameters, etc.

While an example manner of implementing the example analysis module104ofFIGS. 1 and 7is illustrated inFIG. 7, one or more of the elements, processes and/or devices illustrated inFIG. 7may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example spectral signal pre-processor704, the example spectral signal analyzer706, the example condition comparator708, the example encoder/transmitter710and/or, more generally, the example analysis module104ofFIGS. 1 and 7may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example spectral signal pre-processor704, the example spectral signal analyzer706, the example condition comparator708, encoder/transmitter710and/or, more generally, the example analysis module104could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example, spectral signal pre-processor704, the example spectral signal analyzer706, the example condition comparator708, and/or the example encoder/transmitter710is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example analysis module104ofFIGS. 1 and 7may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIG. 7, and/or may include more than one of any or all of the illustrated elements, processes and devices.

A flowchart representative of example machine readable instructions for implementing the analysis module104ofFIG. 7is shown inFIG. 8. In this example, the machine readable instructions comprise a program for execution by a processor such as the processor912shown in the example processor platform900discussed below in connection withFIG. 9. The program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor912, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor912and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated inFIG. 8, many other methods of implementing the example analysis module104may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

The example method ofFIG. 8begins as the leak detection sensor301that has been coupled to an installation (e.g., a previously installed installation) that is currently being operated. In this example, the installation is being used as a node in a utility network and/or system to provide fluid (e.g., water or gas) to utility customers and a baseline spectral average has already been calculated and uploaded to the remote server114by the analysis module104.

In this example, the spectral pre-processor704determines whether a session (e.g., a recording session, a characterization session, etc.) should be active (block801). If the session is to be active and/or continue (block801), control of the process proceeds to block802. Otherwise, the process ends (e.g., the recording session is not continued or initiated).

According to the illustrated example, it is then determined whether recordings are to be added and/or obtained (block802). In particular, the spectral signal pre-processor704and/or the spectral signal analyzer706may determine whether the recordings are to be obtained. This determination may be based on whether a new spectral average is needed (e.g., whether a spectral average of the today's recordings is desired) or whether a new baseline spectral average should or needs to be defined. If additional recordings are to be added (block802), control of the process proceeds to block804. Otherwise, the process proceeds to block816.

If at least one additional recording is to be added/obtained (block802), a recording is made (block804). In this example, the sensor301records a time domain signal/recording and/or characteristics in the time domain.

According to the illustrated example, time domain statistics of the recording are computed by the spectral signal pre-processor704, for example (block806). For example, numerous quantitative attributes of the recording such as peaks and/or signal patterns, for example, in the time domain may be recorded and/or characterized. In some examples, data associated with these time-domain characteristics is stored in the recording storage709for later transmission (e.g., encoded in a packet along with the spectral average data).

A spectral representation of the time-domain recording is computed/calculated by the example spectral signal analyzer706and/or the spectral signal pre-processor704(block808). In other words, the time domain signal recording is converted into a frequency domain recording via a transformation. In this example, this conversion occurs via an FFT analysis of the time domain signal, thereby defining a spectral representation. In some examples, a power spectral density calculation is used. In some examples, wavelet filtering is performed.

Next, the spectral representation and/or data associated with the spectral representation is saved (block810). In this example, the spectral representation is saved onto the recording storage709.

In some examples, a recording counter (e.g., a counter to record a number of recordings) is incremented (block812). In such examples, the counter is used to determine whether a minimum number of recordings have been obtained (e.g., 16 recordings, 50 recordings, etc.).

According to the illustrated example, recording parameters of the sensor310may be updated and/or varied (block813). In particular, the spectral signal pre-processor704and/or the spectral signal analyzer706of the illustrated example may vary a polling frequency and/or power draw mode of the sensor310based on at least one incoming current recording and/or its associated spectral representation.

In some examples, this polling frequency may be varied based on a pipe configuration (e.g., diameter, material, coupling implementation), type of environment (e.g., residential, valve, industrial, commercial, etc.), or any appropriate environment. Additionally or alternatively, sensor310is directed to perform measurements at a defined time period (e.g., a few minutes, a few hours, a few days, a few months, etc.) after certain events and/or daily use patterns.

In some examples, a return/transmit recording status is transmitted by the encoder/transceiver710, for example (block814) and the process returns to block801.

In some examples, recordings and/or associated spectral representations are selected and/or sorted (block816). In particular, the spectral signal pre-processor704of the illustrated example may remove noisy spectral representations and/or append newer spectral representations. Additionally or alternatively, spectral representations are grouped by similarity (e.g., a similarity in peak amplitude and/or waveform shape, etc.).

According to the illustrated example, session/current spectral data and/or average is computed and saved (block818). In particular, a spectral average of the converted spectral representations is generated and/or computed.

In some examples, the baseline spectral average is compared to the current session spectral average to determine a leak condition (block820). In particular, the condition comparator708and/or the remote server114may perform this comparison. In this example, the baseline spectral average is subtracted from the current session spectral average. In other examples, an integral average between the current spectral average and the baseline spectral average may be used. In some examples, this comparison is at least partially based on a known spectral signature that is stored in the signature storage709. Additionally or alternatively, differences (e.g., numerical differences) in amplitude peaks at respective frequencies and/or frequency ranges are compared.

In some examples, the spectral average is compared to a known signature from a database (block822). This comparison may be performed to determine a leak condition. In particular, the database may be stored on the recording storage709and/or the remote server114.

In some examples, the collected spectral average data is compressed (block824). In such examples, the spectral signal analyzer706and/or the spectral signal pre-processor704may perform the compression. For example, an A-law compression algorithm may be used. Additionally or alternatively, the collected spectral average data is grouped with other recordings and/or categorized into a known group of recordings/spectral representation to save disk storage space some examples, the compression may be performed to reduce necessary transmissions to the endpoint108, thereby saving power and/or battery use.

According to the illustrated example, a data packet is encoded, computed and/or generated (block826). In this example, the encoder/transceiver710packages the current spectral average for later transmission. In particular, the current session spectral average is encoded into a data packet. Further, other attribute information and/or characteristics such as time-domain characteristics may be encoded into the data packet. In some examples, temperature data (e.g., a time-temperature history) is also encoded into the data packet for additional analysis at the remote server114. In some examples, a bias flag is also added to the data packet when there are a number of recordings or spectral representations below a threshold number.

In some examples, the recording storage709stores the data packet (block828). For example, the data packet may be stored for later transmission and/or to be combined with other data later and/or for later transmission when the leak detection sensor is turned on.

According to the illustrated example, the data packet is transmitted (block830) and the process ends. In particular, the example encoder/transceiver710transmits the aforementioned data packet to the remote server114via the endpoint108.

FIG. 9is a block diagram of an example processor platform900capable of executing the instructions ofFIG. 8to implement the analysis module104ofFIGS. 1 and 7. The processor platform900can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device.

The processor platform900of the illustrated example includes a processor912. The processor912of the illustrated example is hardware. For example, the processor912can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

The processor912of the illustrated example includes a local memory913(e.g., a cache). The example processor also includes the example spectral signal pre-processor704, the example spectral signal analyzer706, condition comparator708and the encoder/transceiver710. The processor912of the illustrated example is in communication with a main memory including a volatile memory914and a non-volatile memory916via a bus918. The volatile memory914may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory916may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory914,916is controlled by a memory controller.

The processor platform900of the illustrated example also includes an interface circuit920. The interface circuit920may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices922are connected to the interface circuit920. The input device(s)922permit(s) a user to enter data and commands into the processor912. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

The processor platform900of the illustrated example also includes one or more mass storage devices928for storing software and/or data. Examples of such mass storage devices928include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions932ofFIG. 8may be stored in the mass storage device928, in the volatile memory914, in the non-volatile memory916, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture provide an effective and power-efficient manner of accurately determining a leak condition by generating a spectral average based on organizing and/or analyzing multiple recordings (e.g., multiple baseline recordings). In particular, the generated spectral averages that are not affected by ambient and/or inherent noise characteristics of corresponding systems (e.g., utility systems) and may be compared to a current recording to determine the leak condition. The examples disclosed herein also enable adaptive data sampling, which can reduce power consumption, especially in battery-run devices such as some remote sensors (e.g., remote acoustic leak detection sensors) to obtain recordings.

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent. While the examples disclosed herein are shown in relation to utility metering systems, any of the examples disclosed herein, including the example processing and/or analysis techniques, may be used in any appropriate application(s).