Patent Description:
Conventional communication devices include radios (e.g., Land Mobile Radios ("LMRs")). Some of the radios have extreme immersion requirements, such as a twenty meter immersion requirement. Such radios have certain components that need maintenance due to fatigue after a certain number of dives at certain pressures and for certain amounts of time.

Prior art can be found in <CIT> which generally relates to an electronic device having waterproof warranty condition judgement system and in <CIT> which generally relates to condition-based maintenance of device.

This document concerns systems and methods for operating a communication device. The methods comprise: transitioning, by a processor, the communication device from a non-dive mode in which dive timing operations of the communication device are disabled to a dive mode in which dive timing operations of the communication device are to be enabled; activating, by the processor, a first timer in response to said transitioning; monitoring, by the processor, states of snap-dome based switches of a keypad provided with the communication device, wherein the states of snap-dome based switches are changed by pressure; activating, by the processor, a second timer (e.g., a dive depth timer) when the snap-dome based switches are simultaneously activated by the pressure; detecting, by the processor, when maintenance of the communication device is needed based on a value of the second timer; and causing, by the processor, performance of communication device maintenance based on the detecting.

In some scenarios, the second timer comprises a clock for tracking an amount of time in which the communication device is immersed in water at given depths during a single immersion event or during a plurality of consecutive immersion events. A detection that maintenance is needed may be made when the value of the second timer is equal to or greater than a threshold value. The threshold value may be selected in accordance with a maximum amount of time at least one pressure sensitive component of the communication device can be immersed in water at given depths without experiencing fatigue, failure or erasure.

As noted above, the second timer comprises a clock for tracking an amount of time in which the communication device is immersed in water at given depths. The first timer comprises a clock for tracking an amount of time in which the communication device is in the dive mode. The second timer may be deactivated when the snap-dome based switches are no longer simultaneously activated, and the first timer may be deactivated when the communication device is transitioned from the dive mode. The first timer and/or second timer can be reset when the communication device maintenance has been performed.

This disclosure is facilitated by reference to the following drawing figures, in which like numerals represent like items throughout the figures.

It will be readily understood that the solution described herein and illustrated in the appended figures could involve a wide variety of different configurations. Thus, the following more detailed description, as represented in the figures, is not intended to limit the scope of the present disclosure, but is merely representative of certain implementations in various different scenarios. While the various aspects are presented in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized should be or are in any single embodiment of the invention.

The terms "memory," "memory device," "data store," "data storage facility" and the like each refer to a non-transitory device on which computer-readable data, programming instructions (e.g., instructions <NUM> of <FIG>) or both are stored. Except where specifically stated otherwise, the terms "memory," "memory device," "data store," "data storage facility" and the like are intended to include single device embodiments, embodiments in which multiple memory devices together or collectively store a set of data or instructions, as well as individual sectors within such devices.

As noted above, conventional communication devices include radios. Some of the radios have extreme immersion requirements, such as a twenty meter immersion requirement. Such radios have certain components that need maintenance due to fatigue after a certain number of dives at certain pressures and/or for certain amounts of time at certain pressures. Currently, there is not a way to accurately keep track of a radio's immersed time at depths capable of material fatigue.

Radios that require maintenance based on time spent at immersed depths due to fatigue of components have no accurate measurement system in place to determine when maintenance is needed. Currently, systems only track the number of times a radio is put in a dive mode. There is no understanding of whether or not the radio was then subjected to any immersion. If immersed, there is no information as to how long the radio was immersed at pressures capable of fatiguing the equipment.

Accordingly, this document concerns implementing systems and methods addressing these drawbacks of conventional radios. More specifically, this document concerns systems and methods for operating a communication device with a dome switch keypad. The dome switch keypad generally provides a pressure switch (e.g., a switch that changes an operational state when hydrostatic pressure of a certain amount is applied thereto). The pressure switch comprises a highly reliable, electrically passive (no power consumption) submersible switch capable of (a) precision triggering in certain depths and (b) deep depth survival. The purpose of the submersible switch is that is uses pressure from water submersion to activate (i.e., change states from an off state to an on state, and vice versa). The submersible switch activation can be accomplished at select depths that cause fatigue of the communication device's components (e.g., a pressure vent, a seal, and/or breathing ports/vents). For example, as shown in <FIG>, the submersible switch of the communication device <NUM> is designed to be activated when it reaches ten meters below the water's surface. This activation at ten meters is repeatable (i.e., the submersible switch is reliable in that it will trigger at ten meters each time it is re-submerged under water). The present solution is not limited to the particulars of this example.

During operation, the communication device <NUM> performs operations to: monitor states of snap-dome based switches of a keypad provided with the communication device; activate a second timer (e.g., a dive depth timer) when the communication device is in a dive mode and/or the snap-dome based switches are simultaneously activated; detect when maintenance of the communication device is needed based on a value of the second timer; and cause performance of communication device maintenance based on the detecting.

In those or other scenarios, the communication device <NUM> also performs operations to: transition itself from a non-dive mode in which dive timing operations of the communication device are disabled to the dive mode in which dive timing operations of the communication device are and/or are to be enabled; and activate a first timer (e.g., dive mode timer) in response to said transitioning. As noted above, the second timer comprises a clock for tracking an amount of time in which the communication device is immersed in water at given depths. The first timer comprises a clock for tracking an amount of time in which the communication device is in the dive mode. The second timer may be deactivated when the snap-dome based switches are no longer simultaneously activated, and the first timer may be deactivated when the communication device is transitioned from the dive mode. The second timer and/or first timer can be reset when the communication device maintenance has been performed.

Referring now to <FIG>, there is provided an illustration of an illustrative architecture for the communication device <NUM> which is configured for carrying out the various methods described herein for accurately determining when maintenance thereof is needed. Communication device <NUM> can include more or less components than that shown in <FIG> in accordance with a given application. For example, communication device <NUM> may or may not include one or more optional pressure sensors <NUM>. Pressure sensors are well known in the art, and therefore will not be described herein. The present solution is not limited in this regard.

As shown in <FIG>, the communication device <NUM> comprises a communication transceiver <NUM> coupled to an antenna <NUM>. Communication transceivers are well known in the art, and therefore will not be described in detail herein. Still, it should be understood that the communication transceiver can comprise one or more components such as a processor, an application specific circuit, a programmable logic device, a digital signal processor, or other circuitry programmed to perform the functions described herein. The communication transceiver <NUM> can enable end-to-end communication services in a manner known in the art. In this regard, the communication transceiver can facilitate communication of voice data from the communication device <NUM> over a communication network (e.g., a Land Mobile Radio network, a cellular network, and/or other network).

The communication transceiver <NUM> is connected to a processor <NUM> comprising an electronic circuit. During operation, the processor <NUM> is configured to control the communication transceiver <NUM> for providing communication services. The processor <NUM> also facilitates an accurate determination as to when maintenance of the communication device <NUM> is needed. The manner in which the processor facilitates such a determination will become evident as the discussion progresses.

A memory <NUM>, display <NUM>, dome switch keypad <NUM>, optional pressure sensor <NUM>, and Input/Output ("I/O") device(s) <NUM> are also connected to the processor <NUM>. Each of the listed devices are well known in the art, and therefore will not be described herein. In some scenarios, the dome switch keypad <NUM> comprises a dome switch keypad available from Snaptron Inc. of Colorado, USA. As known, a dome switch keypad comprises a plurality of keys each comprising a snap-dome based switch. The snap-dome based switch uses two circuit board traces in conjunction with a metal dome to detect when the respective key is being depressed. Such a detection is made when the metal dome is in contact with the two circuit board traces. When the key is no longer being depressed, the metal dome moves out and away from the two circuit board traces thereby indicating the key's release. Accordingly, each snap-dome based switch is transitionable between an undepressed/deactivated state and a depressed/activated state.

The processor <NUM> may be configured to collect and store data generated by the display <NUM> (which may be a touch screen display), dome switch keypad <NUM>, optional pressure sensor <NUM>, I/O device(s) <NUM> and/or external devices (not shown). Data stored in memory <NUM> can include, but is not limited to, information defining criteria for triggering a dive mode timer <NUM>, information defining criteria for triggering a dive depth timer <NUM>, threshold values, sensor data, switch state data and any other information which facilitates an accurate determination as to when maintenance of the communication device <NUM> is needed.

The processor <NUM> can perform actions involving access to and use of memory <NUM> on which is stored one or more sets of instructions <NUM> (e.g., software code) configured to implement one or more of the methodologies, procedures, or functions described herein. The instructions <NUM> can also reside, completely or at least partially, within the processor <NUM> during execution thereof by the processor. As such, the memory <NUM> and the processor <NUM> can comprise machine-readable media. The term "machine-readable media", as used here, refers to a single medium or multiple media that store the one or more sets of instructions <NUM>. The term "machine-readable media", as used here, also refers to any medium that is capable of storing, encoding or carrying a set of instructions <NUM> for execution by the processor <NUM> that cause such device to perform any one or more of the methodologies of the present disclosure.

The I/O device(s) <NUM> include(s), but is(are) not limited to, a plurality of user depressible buttons, user actuatable knobs (e.g., rotary knobs), sensor(s), microphone(s), speaker(s), camera(s), Light Emitting Diodes ("LEDs"), and/or vibrator(s). The I/O device(s) <NUM> may be used, for example, for entering numerical inputs, selecting various functions of the communication device <NUM>, and/or outputting information (e.g., alerts and notifications that maintenance of the communication device is needed). The depressible buttons of the I/O device(s) <NUM> may be configured as a keypad and may be part of the dome switch keypad <NUM>.

A battery <NUM> or other power source may be provided for powering the components of the communication device <NUM>. The battery <NUM> may comprise a rechargeable and/or replaceable battery. The battery <NUM> may be recharged via an energy harvesting circuit (not shown). Batteries and energy harvesting circuits are well known in the art, and therefore will not be discussed here.

The communication device architecture shown in <FIG> should be understood to be one possible example of a communication device system which can be used in connection with the various implementations disclosed herein. However, the systems and methods disclosed herein are not limited in this regard and any other suitable communication device system architecture can also be used without limitation. Applications that can include the apparatus and systems broadly include a variety of electronic and computer systems. In some scenarios, certain functions can be implemented in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the illustrative system is applicable to software, firmware, and hardware implementations.

In order to facilitate an accurate determination as to when maintenance of the communication device <NUM> is needed, the communication device uses simultaneous keypad snap-dome activation by hydrostatic pressure to trigger the dive depth counter <NUM>. The processor <NUM> starts the dive depth counter <NUM> when the communication device <NUM> is in a dive mode and buttons of the keypad dome switch <NUM> and/or I/O device(s) is(are) activated by hydrostatic pressure. The dive depth counter <NUM> tracks the amount of time that the communication device <NUM> is immersed below a depth of interest. The tracked amount of time can be viewed by a user via the display <NUM> or other output means (e.g., a digital or mechanical clock component). A user may be alerted or otherwise notified of a maintenance need for one or more fatigued components of the communication device <NUM> when the amount of time exceeds one or more pre-defined threshold values. The dive depth counter <NUM> may be reset once the maintenance of the communication device <NUM> is performed. The dive depth counter information and/or maintenance information associated with the communication device <NUM> may also be communicated to an external device (e.g., a remote server) for further analysis and/or use with other communication devices.

The present solution has many novel features. For example, the present solution uses keypad hardware <NUM> to detect when a communication device <NUM> achieves a depth of interest. This detection is made when snap-domes of the keypad dome switch <NUM> are actuated at the same time due to hydrostatic pressure while the communication device <NUM> is in a dive mode. Additionally or alternatively, the pressure sensor <NUM> can be used to facilitate such a detection. The snap-dome activation force can be designed or customized to specify the depth at which the dive depth counter <NUM> is to be activated.

The present solution provides an intuitive dive counter that leads to accurate maintenance on fatigued communication device parts. Currently, time spent at immersed depths is not tracked by conventional communication devices. The only tracking performed by conventional communication devices is based on when the same enter into their dive modes. Correlating the time spent in dive mode and the time spent immersed in water below a given depth can provide important information about end users that can be used to improve operations and/or architectures of communication devices with immersion requirements.

Referring now to <FIG>, there is provided a flow diagram of an illustrative method <NUM> for operating a communication device (e.g., communication device <NUM> of <FIG>). Method <NUM> begins with <NUM> and continues with <NUM> where an operational mode of the communication device is transitioned from a non-dive mode to a dive mode. The non-dive mode may comprise any operational mode in which dive timing operations of the communication device are disabled and/or power is supplied to I/O devices of the communication device. The dive mode comprises an operational mode in which dive timing operations of the communication device are or are to be enabled. The dive timing operations can include, but are not limited to, the tracking of a total amount of time that the communication device is in a dive mode, and/or the discontinuing the supply of power to I/O devices of the communication device. The operational mode transition can be triggered in various ways. For example, an operational mode transition is triggered in response to a user-software interaction received by the communication device and/or based on sensor data (e.g., sensor data indicating an amount of moisture in a surrounding environment). The user-software interaction may be facilitated by I/O devices (e.g., devices <NUM>, <NUM> and/or <NUM> of <FIG>). The transition of operational modes can be achieved by a processor (e.g., processor <NUM> of <FIG>) via a change of one or more operational mode parameter values stored in an internal memory (e.g., memory <NUM> of <FIG>) of the communication device. For example, one or more operational mode parameter values can be set to zero or one. The present solution is not limited to the particulars of this example.

In response to the communication device's transition into the dive mode, a dive mode timer (e.g., dive mode timer <NUM> of <FIG>) is activated by the processor as shown by <NUM>. The dive mode timer comprises a clock for tracking an amount of time in which the communication device is in the dive mode. Clocks are well known in the art, and therefore will not be described herein.

Next in <NUM>, the states of a keypad's snap-dome based switches are monitored by the processor. As noted above, each of the snap-dome based switches of the keypad (e.g., dome switch keypad <NUM> of <FIG>) has two states: an undepressed or deactivated state; and a depressed or activated state. If the snap-dome based switches are not simultaneously activated [<NUM>:NO], then method <NUM> continues with <NUM>. If the dive mode needs to still be active [<NUM>: YES], then method <NUM> returns to <NUM>. The determination of <NUM> as to whether or not the dive mode needs to still be active can be based on time information (e.g., has a pre-defined period of time passed since transitioning to dive mode), user-software interactions (e.g., a user uses a button or widget to turn off dive mode), and/or sensor data (e.g., sensor data specifying an amount of moisture in a surrounding environment that falls below a threshold value). In contrast, if the dive mode does not need to still be active [<NUM>:NO], then method continues with <NUM>-<NUM>. <NUM>-<NUM> involve: transitioning the communication device back into the non-dive mode; and deactivating the dive mode timer. Subsequently, <NUM> is performed where method <NUM> ends or other processing is performed (e.g., return to <NUM>).

If the snap-dome based switches are simultaneously activated [<NUM>:YES], then method <NUM> continues with <NUM>-<NUM>. <NUM>-<NUM> involve: activating a dive depth timer of the communication device (e.g., dive depth timer <NUM> of <FIG>); and monitoring the states of a keypad's snap-dome based switches. The dive depth timer comprises a clock for tracking an amount of time in which the communication device is immersed in water at given depths (e.g., depths greater than or equal to ten meters) during a single immersion event or a plurality of immersion events. Clocks are well known in the art, and therefore will not be described herein. When the keypad's snap-dome based switches are no longer simultaneously activated [<NUM>:NO], the dive depth timer is deactivated as shown by <NUM>.

Next in <NUM>, a determination is made as to whether the dive depth timer value is greater than or equal to a threshold value. The threshold value is selected in accordance with the maximum amount of time at least one pressure sensitive component of the communication device (e.g., pressure sensitive component <NUM> of <FIG>) can be immersed in water at given depths (e.g., ten-twenty meters) without experiencing fatigue (e.g., mechanical deformation or material wear and tear), failure (e.g., material rupture, puncture, rip, tear, etc.) or erasure (e.g., electronic component erasure or loss of functionality). The pressure sensitive component(s) can include(s), but is(are) not limited to, a pressure vent, a seal, and/or a breathing ports/vent.

If the dive depth timer value is less than the threshold value [<NUM>:NO], then <NUM> is performed where method <NUM> ends or other processing is performed (e.g., return to <NUM>). In contrast, if the dive depth time value is greater than or equal to the threshold value [<NUM>: YES], then <NUM> is performed where the processor performs operations to cause the communication device maintenance to be performed. These operations can include, but are not limited to, causing an output of an indicator indicating a need for communication device maintenance, causing software to be loaded from a local non-volatile memory device to a volatile memory device, and/or causing software to be downloaded from a remote site to the communication device. The indication can include, but is not limited to, an auditory indication, a visual indication and/or a tactile indication. For example, the indication comprises emitted light, an electronic message (e.g., a displayed text message or icon), a sound, and/or a vibration.

The dive mode timer and the dive depth timer are reset when the communication device maintenance has been performed, as shown by <NUM>. Upon completing <NUM>, <NUM> is performed where method <NUM> ends or other processing is performed (e.g., return to <NUM>).

As evident from the above discussion, the present solution enables users of communication devices to track immersion times at depths of interest (e.g., depths equal to and greater than ten meters) to properly schedule maintenance of components that fatigue due to extreme hydrostatic pressures of surrounding water. The present solution also limits uncertainty of dive capabilities and protects communication devices from water ingress throughout their life cycles. The present solution also provides a means to track data of fielded communication devices to understand the actual use thereof in dive situations.

The described features, advantages and characteristics disclosed herein may be combined in any suitable manner. One skilled in the relevant art will recognize, in light of the description herein, that the disclosed systems and/or methods can be practiced without one or more of the specific features. In other instances, additional features and advantages may be recognized in certain scenarios that may not be present in all instances.

Claim 1:
A method (<NUM>) for operating a communication device, comprising:
transitioning (<NUM>), by a processor, the communication device from a non-dive mode in which dive timing operations of the communication device are disabled to a dive mode in which dive timing operations of the communication device are to be enabled;
activating (<NUM>), by the processor, a first timer in response to said transitioning (<NUM>);
monitoring (<NUM>), by the processor, states of snap-dome based switches of a keypad provided with the communication device, wherein the states of snap-dome based switches are changed by pressure;
activating (<NUM>), by the processor, a second timer when the snap-dome based switches are simultaneously activated by the pressure;
detecting (<NUM>), by the processor, when maintenance of the communication device is needed based on a value of the second timer; and
causing (<NUM>), by the processor, performance of communication device maintenance based on the detecting.