Patent Description:
In recent years, there has been rapid development of new communication systems and methods of communicating. The early cellular phones were limited to analogue operation, communicated specifically over a cellular network and allowed for voice communication only. Later, digital operation was introduced and soon thereafter, the keypads were utilized to provide rudimentary text messaging. Modern wireless devices, including cell phones have sufficient bandwidth to enable the transfer of voice signals, image data, and even video streaming. In addition, most cell phones provide network access, such as Internet access through network interfaces such as Wi-Fi, Bluetooth® and WiMax, for example. This allows the cell phones to communicate with other electronic devices.

Satellite communication and satellite phones have also undergone a transformation in recent years. The phones provide similar functionality to cellular phones including voice communication, short messaging service and low-bandwidth Internet access.

In truly mobile situations, such as in an aircraft, communication usually involves a satellite and a satellite network. Data are sent from the mobile location by an onboard satellite communication system. The satellite network then communicates data to a base station directly, or, as is the case more recently, communicate data via the internet to the base station. Such systems are described in https://ipadpilotnews. com/<NUM>/<NUM>/pilot-report-flying-new-iridium-go-satellite-hotspot/, <CIT>, <CIT> and <CIT>. While these communication means are providing ever-expanding capabilities, they cannot always provide reliable communication. This is in part because of the bandwidth available, the size of the data being sent, and the reliability of the system to accurately transform the data. Another deficiency is the ability to meld the technologies together, so that a mobile device can interact with the onboard satellite communication system, thereby accessing satellite-based communications.

It is an object of the present technology to provide a peripheral device, system and method that can reliably and accurately control a satellite communication (satcom) device by sending commands to the device. The peripheral device additionally can transmit text and binary messages to the onboard satellite communication system and then to a recipient device or base station. It is a further objective to provide this service without the use of specific hardware, keypads and screens that are purpose built but rather with a multifunctional peripheral device that is easy to use and has extensible protocols for command controls.

While various exemplary embodiments are discussed and contemplated herein, the present disclosure provides many concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed herein are therefore, merely illustrative of specific ways to make and use the invention as ultimately claimed and are not meant to limit the invention in any way. Accordingly, for the ease of discussion, communication systems, methods and device embodiments are described below, as exemplary embodiments, and the description of specific exemplary embodiments is not intended to limit the exemplary embodiments disclosed herein.

In one embodiment, a system for communicating a plurality of flight data comprising data from ARINC busses and sensors reporting flight conditions, from at least one onboard aircraft flight data monitoring application (<NUM>), between an aircraft and a base station, the system comprising a satellite (<NUM>), the base station (<NUM>) and an onboard satellite communication device (<NUM>) wherein the onboard satellite communications device is programmed to send commands and transfer the plurality of aircraft flight data to the satellite and to receive commands and transfer data from the satellite, and the satellite is configured to transfer data between the satellite and the base station, characterized in that a first programmable peripheral device (<NUM>), which is in the aircraft, is programmed to directly and autonomously control the onboard satellite communications device (<NUM>) in the aircraft without the assistance of an onboard server in response to an anomalous event, the first programmable peripheral device comprising software (<NUM>) and a software messaging tool (<NUM>); and a second programmable peripheral device (<NUM>), which is in the aircraft, the second programmable peripheral device comprising software (<NUM>), an interface to the first programmable peripheral device, and the at least one onboard aircraft flight data monitoring application (<NUM>), the second programmable peripheral device programmed to send and receive commands and data autonomously between the software application and the first programmable peripheral device, in response to an anomalous event.

In the system the first programmable peripheral device further comprises an extensible protocol for data transfer directly to the satellite communications device, including messaging, texting, and Short Message Service (SMS).

In the system the first programmable peripheral device communicates to the satellite communications device sending commands to the satellite communications device and continually sending aircraft flight data to and receiving data from the satellite communications device.

In the system the second programmable peripheral device is a flight data monitoring device.

In the system the first programmable peripheral device further comprises a keypad (<NUM>).

In the system the second programmable peripheral device comprises a plurality of software applications.

The system further comprises a plurality of programmable peripheral devices (<NUM>), each programmable peripheral device comprising software (<NUM>), an interface to another programmable peripheral device, and an at least one software application (<NUM>), the plurality of programmable peripheral devices programmed to send and receive commands and data between the software application and another programmable peripheral device.

In the system the plurality of programmable peripheral devices are functionally in a series, and the series of programmable peripheral devices are programmed to send the data from the second peripheral device to the first peripheral device via the series of peripheral devices.

In the system the series is a dynamic series.

In the system the satellite communication device is a satellite communications phone.

The system further comprises a device including a second software application proximate the aircraft.

In the system the first peripheral device and the at least one second programmable peripheral device are self-contained in an onboard communication system.

Dongle: A dongle is a simple device that is directly connected to a port on a satellite communication device in order to provide the hardware to support additional connection options to the satellite communication device. Additional connection options are WiFi or Bluetooth.

SMS: Short Message Service. The primary motivation for the creation and use of SMS language was to convey a comprehensible message using the fewest number of characters possible.

TCP/IP: Transmission Control Protocol (TCP) and Internet Protocol (IP).

ATTN: Attention, a command character to signal a device request. A common use for ASCII control character known as BEL or Bell, hex <NUM>. <NUM> is used to signal attention to a device.

CRC: Cyclic redundancy checksum. A method of ensuring data is intact and unmodified. The CRC word is part of the CRC'ed data.

MSGID: Message identifier, or type a message identifier is assigned to each message defines semantic meaning.

SUBID: Subordinate identifier of the message, further defining the message semantic meaning.

ACK: Acknowledgement byte, specifically in this case we reference the ASCII control character set. ACK, hexadecimal <NUM>. <NUM> (decimal <NUM>).

NAK: Negative acknowledgement byte, specifically in this case we reference the ASCII control character set, NAK, hexadecimal <NUM>. <NUM> (decimal <NUM>).

Wi-Fi: A technology allowing devices to exchange data wirelessly over a computer network, including hi-speed Internet connections. It is any wireless network based on Institute of Electrical and Electronic Engineers (IEEE) <NUM> standards.

Proximate: In the context of the present technology, proximate means that the second peripheral device is outside the aircraft, but close enough to communicate directly with the first peripheral device.

Except as otherwise expressly provided, the following rules of interpretation apply to this specification (written description, claims and drawings): (a) all words used herein shall be construed to be of such gender or number (singular or plural) as the circumstances require; (b) the singular terms "a", "an", and "the", as used in the specification and the appended claims include plural references unless the context clearly dictates otherwise; (c) the antecedent term "about" applied to a recited range or value denotes an approximation within the deviation in the range or value known or expected in the art from the measurements method; (d) the words "herein", "hereby", "hereof", "hereto", "hereinbefore", and "hereinafter", and words of similar import, refer to this specification in its entirety and not to any particular paragraph, claim or other subdivision, unless otherwise specified; (e) descriptive headings are for convenience only and shall not control or affect the meaning or construction of any part of the specification; and (f) "or" and "any" are not exclusive and "include" and "including" are not limiting. Further, the terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted.

To the extent necessary to provide descriptive support, the subject matter and/or text of the appended claims is incorporated herein by reference in their entirety.

Where a specific range of values is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit unless the context clearly dictates otherwise, between the upper and lower limit of that range and any other stated or intervening value in that stated range, is included therein. All smaller sub ranges are also included. The upper and lower limits of these smaller ranges are also included therein, subject to any specifically excluded limit in the stated range.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the relevant art. Although any methods and components similar or equivalent to those described herein can also be used, the acceptable methods and components are now described.

The main components of the communication system for soft wireless dialing and messaging, generally referred to as <NUM>, is shown in <FIG>. A first programmable peripheral device <NUM> connects to the onboard satellite communication system, or integrated aeronautical communications device <NUM>. It has software <NUM>, a software keypad <NUM> and a messaging tool <NUM>. The device is an iPad ®, an iPhone® or an Android® device. The onboard satellite communication device <NUM> generally supports narrow band networking for aircraft requiring text messaging, email, file transmission, internet access and voice communication and therefore it is a data and voice satellite communication device that has the firmware or software in the unit to support the protocol. It need not support voice communication. The connection is a Wi-Fi to serial dongle, which provides an "access point" <NUM> that the mobile device <NUM> then connects to using its built-in Wi-Fi, or is a Bluetooth® to serial dongle, or a Universal Serial Bus (USB) to serial wired connection, or is a Bluetooth or Wi-Fi direct, or any other direct cable connection such as USB or Lightning® with the onboard satellite communication device <NUM> having a modem for this connection. Software or firmware applications <NUM> in the first programmable peripheral device <NUM> communicate to the onboard satellite communication device <NUM> sending commands to the onboard satellite communication device <NUM> using firmware or software <NUM> in the communication device <NUM>. Note that error detection is inherently part of the transmission protocol. The onboard satellite communication device <NUM> communicates with a satellite <NUM>, which in turn transmits via a satellite network <NUM> either directly to the base station <NUM> or via the Internet <NUM> to the recipient device (base station) <NUM> or to a cloud <NUM> and then the base station <NUM>, where the data are decoded. The communication system <NUM> provides the connectivity required for reliable text and binary messaging utilizing a processing device <NUM> with software or firmware <NUM> at the base station <NUM>, to provide the base station applications, and the first programmable peripheral device <NUM> applications communicating with onboard satellite communication system <NUM>. This allows for a user to dial the first programmable peripheral device <NUM>, answer the first programmable peripheral device <NUM>, receive and send 'canned messages' and receive and send general satellite data and SMS.

Both the first programmable peripheral device <NUM> and a second programmable peripheral device <NUM> include applications <NUM>. A shown in <FIG>, a plurality of peripheral devices <NUM> that communicate in a series with the second programmable peripheral device <NUM>, which then communicates with the first programmable peripheral device <NUM>. The series is static, as in the same devices always communicate with one another, or dynamic, as in different devices in the series at different times or different devices within the series being active at different times. As shown in <FIG>, there is a plurality of second programmable peripheral devices <NUM> that communicate with the first programmable peripheral device <NUM>. The communication is bidirectional with both commands and data being sent. Any application <NUM> on the aircraft has data and commands sent through the first programmable peripheral device <NUM>. Any application <NUM> on the aircraft has data and commands sent from the base station <NUM> or a third party through a wireless communication link <NUM>. The wireless communication link is Wi-Fi, a VHF (Very High Frequency) communication link, or an HF (High Frequency) communication link. As shown in <FIG>, the onboard communication system, generally referred to as <NUM>, sends and receives messages and commands without the assistance of an on-board server and without the assistance of a ground-based or cloud-based communication system - in other words, the onboard communication system is self-contained within the aircraft.

A user inputs numbers into the first programmable peripheral device <NUM> using the software keypad <NUM>, as would be known to one skilled in the art. The software or firmware applications <NUM> in the first programmable peripheral device <NUM> include instructions or protocols to instruct the peripheral device to perform a number of functions, including controlling a satellite communication device by sending commands, dialing the satellite communication device, sending data to the satellite communication device, and receiving data from the satellite communication device. By using a first peripheral device to control the satellite communication device, there is no requirement for specific hardware or purpose built screens, but rather, the device relies upon software to control a satellite communication device.

As would be known to one skilled in the art, the first peripheral device would request system information from the satellite communication device in order to connect to it before providing commands.

As would be known to one skilled in the art, the satcom device is used to determine position by communicating with a Global Navigation Satellite System (GNSS) and to then send that data. As the first peripheral device controls the satellite communication device, it therefore controls when the position is determined, when the position is reported, where it is reported to and how it is reported. This includes commanding the satellite communication device to trigger emergency tracking mode.

The trigger for emergency tracking mode can be automatic and determined by preset conditions that the aircraft must meet an excessively high rate of descent. The trigger for this mode is receipt of a message from the base station <NUM>.

The emergency tracking messages contain a code to identify the reason for entering the emergency mode. In addition, relevant information from other systems in the aircraft include fuel remaining or fault indications.

Also, as would be known to one skilled in the art, the first peripheral device, in order to function in an acceptable manner, would constantly monitor for data sent from the satellite communication device and regularly query the device for new messages, position, signal strength and notifications such as a new message or text notification, message or text queued, message or text not queued, report transmitted, report queued, report not transmitted.

Further, as would be known to one skilled in the art, as the first peripheral device controls the satellite communication device, when a user wants to send and receive text messages, the first peripheral device controls the placing and receiving of satellite phone calls on the satellite communication device. This would include requesting the start of a call, requesting the end of a call, requesting call status (ringing, calling, idle and the like).

Canned Messages and Form Messages are used as a method to decrease the overall size of transmitted data. Canned Messages allow a single byte to transmit a message based on a lookup table. Form Messages, like Canned Messages, allow several user adjustable fields to be transmitted using a minimum data transmit size. Both Canned Messages and Form Messages require synchronization between the peripheral device <NUM> and the base station <NUM> to maintain a common context for a given message code, or form field. The administration of this synchronization is handled via the base station <NUM>.

A special case of Canned Messages, referred to as Hybrid messages, allow additional user-defined data to be tagged with a Canned Message, like a single-field Form Message.

As a method of decreasing the amount of data transmitted for a customer, binary codes can be transmitted in lieu of including the entire textual intent of a message. Canned messages are administered through the base station and or any peripheral device. The messages are stored and are <NUM> messages, or <NUM> messages, or <NUM> messages or more, or any number between and will be limited by the ability of the user to rapidly and accurately identify and use a specific message.

The first peripheral device firmware or software stores forms. These are upgradeable through a configuration interface. The use of forms allows for compact transmission of several adjustable fields to the base station.

It is up to the peripheral device to maintain a timeout for reception of a response for a given message.

Every messaging transaction must complete (with failure or success) before a new one is initiated.

The first programmable peripheral device <NUM> receives data from another application <NUM> running on a second programmable peripheral device <NUM> and then send it to the satcom13 which communicates with a satellite <NUM>, which in turn transmits via a satellite network <NUM> either directly to the base station <NUM> or via the Internet <NUM> to the recipient device (base station) <NUM> or to a cloud <NUM> and then the base station <NUM>. Another application is to gather and send flight data from the aircraft periodically. These include engine settings, control surface configurations and other monitored aircraft parameters.

The first programmable peripheral device <NUM> receives data messages from the base station <NUM> sent to another application <NUM> running on the second programmable peripheral device <NUM>. The first programmable peripheral device <NUM> removes the proprietary payload wrapper. These data messages originate outside the base station <NUM> and are wrapped and forwarded on behalf of a third party. Notification that a flight plan filing was accepted is sent to a flight plan filing application running on the second programmable peripheral device <NUM>.

An application <NUM> on a programmable peripheral device <NUM>, <NUM> watches the aircraft data busses for anomalous flight conditions, on these conditions being met it autonomously commands the first programmable peripheral device <NUM> to have a notification message sent to the base station <NUM>. This information is forwarded on to interested third parties, such as the airline operator.

The application <NUM> monitoring the aircraft data busses running on the same peripheral device as the first programmable peripheral device <NUM> or it runs on a second programmable peripheral device <NUM> that connects in turn to the first programmable peripheral device <NUM>. The flight data monitoring application is monitoring data on ARINC <NUM>, ARINC <NUM>, ARINC <NUM> busses, or it has its own direct electrical inputs from aircraft sensors or internal GNSS and inertial measurement sensors. These inputs are aggregated together and evaluated against pre-determined rules in order to trigger alert notifications.

An alert would be an excessive airspeed with flaps extended. In order to detect this scenario the programmable peripheral device <NUM>, <NUM> would require an input for the flap position and an input for the airspeed, with appropriate filtering for signal noise. These inputs are evaluated against a pre-programmed table of allowed airspeed and flap position combinations in order to determine whether the current aircraft configuration is within the permitted flight envelope. An excursion from the permitted range is the trigger for the programmable peripheral device <NUM>, <NUM> to command the first programmable peripheral device's <NUM> messaging tool <NUM> to transmit a notification of the exceedance to the base station <NUM>. It will be apparent to one skilled in the art that many other aspects of the flight envelope are similarly monitored for exceedances.

The triggered notification message contains a payload defined by the flight data monitoring peripheral. The message also contains an event code uniquely identifying the type of exceedance that was detected.

Upon command the first programmable peripheral device <NUM> queues the message for transmission and negotiate with the satcom <NUM> via the existing connection (either WiFi, Bluetooth, serial, USB or Ethernet). The satcom <NUM> adds identifying information and an error detection footer to the notification message before dispatching it via the satellite network to the base station <NUM>. The satellite ground station relays the notification message to the base station <NUM> where it is decoded and recorded into a database.

Upon receipt of a notification the base station <NUM> checks its internal table of rules for handling notifications to determine further action that may take place. A rule exists to trigger an email notifying the operator of a flap overspeed event. There are many options for actions that can be taken upon receipt of the exceedance notification, including email notification, SMS notification, popup in a website, and automatic forwarding to a third party web service.

An application on the second programmable peripheral device <NUM> commands the first programmable peripheral device <NUM> to open a new data connection to stream flight data to the base station <NUM>.

The Streaming Flight Data Application (SFDA) is running on the first peripheral device or it is running on a second programmable peripheral device that is connected to the first programmable peripheral device <NUM> via an interface including WiFi, Bluetooth, or cable. The SFDA commands the first programmable peripheral device <NUM> to open a long lived satellite data connection and continually transmit flight data over it. The flight data is sourced from the aircraft's ARINC <NUM>, <NUM> or <NUM> busses, or is based on internal sensors of the second peripheral device <NUM> such as GNSS receiver or an inertial measurement unit, or directly via electrical inputs sampling voltage or current or counting pulses.

The flight data are aggregated together from the above mentioned sources and time stamped by the SFDA before being sent to the first programmable peripheral device <NUM> for relay to the base station <NUM>. The first programmable peripheral device <NUM> maintains the stream connection to the base station <NUM> and inserts additional messages into the stream that are split out by the base station <NUM>. In this way the there is no interference with messaging functions of the first programmable peripheral device <NUM>.

When the flight data stream is received at the base station <NUM> it is recorded to a log file, as well as scanned for noteworthy events. The data stream is forwarded on to a third party, such as the aircraft operator or the engine manufacturer. By decoding the data stream from the aircraft a near real time representation of the current aircraft state can be presented. The manner of this presentation takes the form of time series graphs, tabular data or a reproduction of the aircraft instrument panel.

Control of the flight data streaming is either via messages relayed to the SFDA by the base station <NUM> and first programmable peripheral device <NUM>, or autonomously by the SFDA when it detects an anomalous event. The SFDA starts streaming data to the base station <NUM> via the first programmable peripheral device <NUM> upon detecting an engine fault. Alternatively, a maintenance operator uses his ground terminal to send a command to the SFDA on the aircraft to start streaming data.

An application <NUM> on the second peripheral device <NUM>, such as a flight plan filing application, autonomously commands the first programmable peripheral device <NUM> to send a message to the base station <NUM>. A flight plan message for forwarding onto the air traffic system is sent.

The Flight Plan Application (FPA) on the second programmable peripheral device <NUM> accepts input from the pilot to define the flight plan. When the pilot is satisfied that the correct plan is entered he can submit it to the Air Traffic System (ATS). In order to deliver the flight plan to the ATS the FPA commands the first programmable peripheral device <NUM> to use the messaging tool <NUM> to send a flight plan message to the base station <NUM>, via the satellite communication device <NUM>. Upon receipt of the message the base station <NUM> forwards the flight plan to the ATS for filing. The ATS generates a response to the flight plan filing and this response is relayed to the base station <NUM>. The base station <NUM> in turn sends the flight plan response to the satcom device <NUM> which delivers it to the first programmable peripheral device <NUM>. The first programmable peripheral device <NUM>, expecting the response, then sends the flight plan response to the FPA, which displays it to the pilot.

An application on the second programmable peripheral device <NUM> commands the first programmable peripheral device <NUM> to send a message to the base station <NUM> to request a weather report for a given airport or location. The first programmable peripheral device <NUM> resides on the same peripheral device <NUM> or on a second programmable peripheral device <NUM>.

The application <NUM> commands the first programmable peripheral device <NUM> to initiate the request. The first programmable peripheral device <NUM> will then package the request to include any additional data including the requested airport code or the requested location. The first programmable peripheral device <NUM> automatically includes this location data if a GNSS receiver is available. The first programmable peripheral device <NUM> then instructs the satcom 13to forward the data package on to the base station <NUM>.

The base station <NUM> may then responds directly or forward the request to a third party system and await its response. The response will then be forwarded back to the satellite communication system and on to the first programmable peripheral device <NUM>. The first peripheral device <NUM> will then unpack the message and pass any relevant content back to the application <NUM> on a second programmable peripheral device <NUM>.

An application <NUM> on the second programmable peripheral device <NUM> (in this case <NUM> a flight data monitor and recorder) for monitoring retardant tanks on an air tanker commands the first programmable peripheral device <NUM> to send a data message indicating the volume of retardant and location of a drop to the base station <NUM>. The first programmable peripheral device <NUM> resides on the same peripheral device <NUM> or a second programmable peripheral device <NUM>.

The application <NUM> monitors inputs or signals to determine if a drop or fill event has occurred. This includes tank volume, tank door signals, tank switch signals or even signals from the tank or bucket controller. When this signal change is detected, the application <NUM> gathers related parameters including internal GNSS and inertial measurement sensors and form a data payload. In some instances, additional information such as retardant type, coverage levels, outside air temperatures and other measurements are included with the payload.

This payload is passed to the first programmable peripheral device <NUM> for transmission to the base station <NUM>. The application <NUM> directly commands a first programmable peripheral device <NUM> to package the payload with additional information. This information includes GNSS data or any other sensor data available.

Upon receipt of the payload, the base station <NUM> applies preconfigured rules for parsing and translating the data into engineering units. The base station <NUM> also checks its internal table of rules for handling the data to determine further action that may take place. A rule exists to trigger an email notifying the operator of a drop event. There are many options for actions that may be taken upon receipt of the data, including email notification, SMS notification, display and notification in a website, or automatic forwarding to a third party web service.

The present system is used to send commands to any aircraft data monitoring device and to receive data from the aircraft data monitoring device. In some instances, the second peripheral device is an aircraft data monitor, such as a flight data recorder, an engine sensor or a temperature sensor, as would be known to one skilled in the art.

The second peripheral device is a smartphone, headset or smartwatch connected to the first peripheral device via a short range wireless connection, other than cellular (WiFi or Bluetooth). The second peripheral device in this scenario contains an application that allows a user to initiate or answer voice calls on the satellite communication device. The audio data for the voice call is transferred between the satellite communication device, the first peripheral device and the second peripheral device so that the user uses the satellite communication device for a phone call while not directly connected to it. In effect the second peripheral device becomes a remote wireless handset for the satellite communication device.

Claim 1:
A system for communicating a plurality of aircraft flight data comprising data from ARINC busses and sensors reporting flight conditions, from at least one onboard aircraft flight data monitoring application (<NUM>), between an aircraft and a base station, the system comprising a satellite (<NUM>), the base station (<NUM>) and an onboard satellite communication device (<NUM>) wherein the onboard satellite communications device is programmed to send commands and transfer the plurality of aircraft flight data to the satellite and to receive commands and transfer data from the satellite, and the satellite is configured to transfer data between the satellite and the base station, wherein a first programmable peripheral device (<NUM>), which is in the aircraft, is programmed to directly and autonomously control the onboard satellite communications device (<NUM>) in the aircraft without the assistance of an on-board server in response to an anomalous event, the first programmable peripheral device comprising software (<NUM>) and a software messaging tool (<NUM>); and a second programmable peripheral device (<NUM>), which is in the aircraft, the second programmable peripheral device comprising software (<NUM>), an interface to the first programmable peripheral device, and the at least one onboard aircraft flight data monitoring application (<NUM>), the second programmable peripheral device programmed to send and receive commands and data autonomously between the software application and the first programmable peripheral device, in response to an anomalous event.