Note: Descriptions are shown in the official language in which they were submitted.
Patent Applicant: Aaron M. Suek
Patent Application Title: "Off-road Wireless Tether Switch Monitor with
Communication Integration"
Patent Application Summary:
"Electronic system for monitoring off-road vehicle tether cord/switch state to
detect and alert of conditions where
potential injury may have occurred from the operator being thrown from the
vehicle. The system interacts with the
operator's smartphone via wireless communication and alerts a designated
emergency contact with the operator's
location in the event of a sustained tether disconnection."
1. Patent Description
The electronic system described herein is intended to aid in the detection and
assessment of scenarios where
potentially life-threatening injuries (e.g., spinal injury) may occur after
being thrown off of an off-road vehicle, and
to communicate this potential condition with the operator's location to a
predetermined emergency contact. This
would then allow for further investigation into the potential injury, contact
with other nearby operators, and/or
mobilization of emergency rescue services to the operator's location.
2. General Operational Flow
2.1. A smartphone app for monitoring and communicating with the tether
monitoring system is configured with an
emergency contact's information and other notification preferences (see
section 5.1);
2.2. A tether cord with cap is attached to the vehicle's tether switch; this
switch, in typical form, provides engine
shutdown functionality upon disconnection (out of scope for this patent);
2.3. The wireless communication module, in its implemented form, is paired and
connected to the operator's
smartphone via wireless connection (e.g., Bluetooth) and armed for monitoring
the connected or disconnected
state of the tether cord's cap on the vehicle's tether switch through the
associated smartphone app;
2.4. Upon disconnection of the tether cord's cap, an audible and/or visual
warning is enabled to notify of a
disconnected tether while the system was being monitored, and the module
notifies through wireless
communication to the smartphone that the tether cord cap has been disconnected
from the switch;
2.5. If the operator has not reconnected the tether cord cap to the vehicle-
mounted switch within a pre-specified
time duration, the system identifies this as a potential injury situation
(e.g., thrown from the vehicle), enables
and/or verifies location services (e.g., GPS radio enabled), retrieves the
operator's location, and sends a
message with the operator's location to the operator's pre-specified emergency
contact in the form of a text
message and/or email communication;
2.6. If the operator returns the tether cord cap onto the switch prior to the
pre-specified time duration that would
indicate a possible injury condition, the system will cancel the alarm prior
to sending the communication to the
emergency contact and will continue monitoring for the next disconnect
scenario (step 2.4).
3. Hardware Implementation Options
System implementation may take two primary forms depending on the application.
The first described method
incorporates the hardware, other than the smartphone, as part of the tether
cord and cap assembly. The second
method incorporates the hardware, other than the smartphone, into the
vehicle's electrical and control systems,
either via original equipment manufacturer (OEM) implementation or a
compatible add-on kit.
1
CA 2992778 2018-01-24
VEHICLE-MOUNTED ¨
MODULE GENERIC TETHER CO
TETHER SWITCH GENERIC TETHER VEHICLE-
MOUNTED
EXTERNAL MONITORING,' CORD CAP TETHER
SWITCH
COMMUNICATION \ RD
VEHICLE WIRING FROM
1TNErTeHRENRA LS Wm 01 T DC ul .4 i TEO
4
INTEGRATED SWITCH
t*/ TETHER CORD WITH VEHICLE CONTROL MODULE
WITH __....r¨ 1040
INTEGRAL WIRING FROM INTEGRATED MONITORING AND
.
SWITCH TO MODULE COMMUNICATIONS TO
SMARTPHONE
Fig. 3-1 Modified Tether Cord and External Module Fig. 3-2 Onboard
Monitoring and Communication
Note: As the fundamental operation is via electronic communication and
control, the physical construction attributes
(e.g., form factor of case or specific internal control module used) may vary
considerably in application. As such, it is
the general methods of implementation for monitoring, the control logic
approach, and the associated resulting
communication to the emergency contact that are to subject to this patent.
3.1. Modified Tether Cord and External Module
This option implements a modified tether cord that includes an additional
built-in switch at the cap end. This
switch, herein referred to as the 'cap switch', changes electrical state
('open' or 'closed') as tether cord cap is
connected or disconnected from the vehicle-mounted switch. The cap switch is
connected to a battery-powered
microcontroller module that, when powered on and activated by the smartphone
app, monitors the state of the
cap switch and communicates its status via a wireless connection, on an
ongoing basis, to the smartphone. If a
disconnected state is encountered, represented by a change of electrical state
of the cap switch, while the app
is monitoring the state, a disconnection warning (e.g., audible tone) is
expressed from the external module. This
modified tether cord option is most applicable to retrofit applications where
the vehicle-mounted tether switch
already exists for engine shutdown purposes and no modification to the vehicle
is desired.
3.2. Onboard Monitoring and Communication as Part of Vehicle Electronic and
Control System
The tether switch monitor and communications may be accomplished via OEM
equipment by extending the
capabilities of the onboard electronics (e.g., engine control module). In this
case, a standard, unmodified tether
cord with cap is used. The vehicle-mounted switch state is monitored by one of
the vehicle's onboard electronic
control modules, which subsequently communicates the vehicle-mounted switch
state via wireless connection
to the smartphone. If a disconnected state is encountered while monitoring,
the disconnection warning
originates from the vehicle rather than an external module such as the one
noted in section 3.1.
3.3. Considerations for Hardware Implementation Options
3.3.1. The onboard monitoring and communication system implementation option
utilizes the vehicle's
battery as the power supply for the switch state monitoring system (i.e., no
concern for external battery
charging and eventual replacement), whereas the external module system
requires a separate power
source subject to regular depletion and degradation;
3.3.2. The onboard system option may include the ability to incorporate the
state of other system components
that may decrease the probability of 'false positive' assessment of a
dangerous disconnected tether
state; for example, if the onboard control module has the ability to detect
the state of the vehicle's
ignition switch, it may automatically disable the monitoring system when the
operator manually turns
off the ignition;
2
CA 2992778 2018-01-24
3.3.3. The onboard system option may facilitate OEM upgrading via programming
as part of standard service
and warranty programs, while the external module option may require a hardware
programming port
(e.g., Universal Serial Bus [USI3]) or wireless software upgrading via the
smartphone app;
3.3.4. The onboard system design option may require minimal modification or
extension of the control module
hardware to incorporate the necessary monitoring and communication
capabilities if addressed at the
time of OEM research and design development;
3.3.5. The onboard system option requires factory fitment or aftermarket
upgrade and installation of the
tether switch monitoring and control system, which reduces the options for
existing vehicles not set up
for internal implementation (i.e., limits the opportunity for retrofit
applications) when compared to the
external tether cord cap/switch option;
3.3.6. The onboard system option has an inherent dependence on the maintained
integrity of the vehicle's
electrical system and control module during a crash event in order to
facilitate reliable communication
with the smartphone app; this may be mitigated with the application of robust
components suitable for
sustaining strong impact forces and the possible use of a short-time backup
power source.
4. Hardware Implementation Example
Below is a schematic representation of one implementation option. As the
monitoring and communication may be
accomplished with various components, the following represents just one
example of various possible hardware
configuration options. In this specific example, an external modified tether
cord/cap is used with the following
implementation methodology:
= An 8-pin microcontroller monitors the state of the cap switch;
= Wireless communication is via two-way Bluetooth serial commands from the
microcontroller to a basic
Class 2 (10 m range) Bluetooth slave module, which subsequently communicates
with the smartphone/app;
= 3 x 1.5 V battery cells are used to power the control and annunciation
circuits;
= Audible and visual warning is provided by a low voltage electronic buzzer
and LED, respectively.
eLUETOOTH
CAPABLE
BLUE100 TH
SMARTPHONE
MODULE
Id 5V 32k MICROCONTROLLER
(4.5V) __
V C C* 1 8/41
POW5R
MICRO TO ST
SVik TO I
2 (SER41 ISER-Co 7 RX
_________________________________________________ 36k .. 87 70 MICRo
3 IIN(OUT 4) ON I) 6 ____________________________________ E Tx
C:3
4 IN 3( (KOUT 2) 5
IN4007z, 330 BUZZER
ik
i
0 I
2513904
=
COILED k,
TETHER CORD ______________________________
TETHER CAP
SWITCH
Fig. 4-1 Hardware Implementation Example
3
CA 2992778 2018-01-24
5. Software Functionality
The smartphone application ("app") is critical to the operation of the system.
As most modern smartphones are of
physically rugged design, the hardware has been considered sufficient for
effective communication with the
monitoring system and with the emergency contact during a crash or operator
ejection event, particularly if the
device is kept within enclosed storage during use.
5.1. Operator-Preset Information
The smartphone app, as the main interface, requires input of general
preferential information from the operator in
order to effectively monitor and communicate to an emergency contact. Operator
input may include, but not be
limited to the following basic settings:
a) Approved app permissions ¨ required for the smartphone to connect to
location services, control Bluetooth
and/or other wireless communication functions, and send text messages and/or
emails on behalf of the
operator to the third party emergency contact;
b) Operator's name ¨ to include in the automatic communication to the third
party contact;
c) Emergency contact details and preferred communication method ¨ cellular
phone number for text message
and/or email address as applicable, as well as primary versus backup
communication method in the event of
failed message sending by one method due to network unavailability;
d) Emergency message format and general content not impacted by event data
(e.g., location);
e) Alert delay time ¨ the time between disconnection of the tether cord to the
time that a possible injury
condition is considered to have occurred; the value of this delay would need
to be applicable to the nature
of the vehicle use (e.g., continuous high speed trial riding versus regular
short-time departures for activities
such fence integrity checking where full disabling of monitoring for each
departure may not be practical);
f) Repeat frequency and interval' ¨ if the operator has not reconnected the
switch after the first message is
sent to the emergency contact, should it send an additional number of alert
messages to the emergency
contact, and how often is this this occur;
g) Automatic alert cancellation message format and general content ¨ if the
tether cord cap is returned to the
vehicle-mounted switch and the smartphone is made of aware of such a state
change via wireless
communication after a message has already been sent to the emergency contact,
what message content
should be conveyed to the emergency contact;
h) Depleted battery action2 ¨ whether or not to send a notification to the
emergency contact noting a loss of
battery charge and that the status will no longer be monitored.
'A repeated message with updated location may serve as additional validation
for the third party emergency
contact where an unsafe condition may not or may not be likely if the position
is still changing. For example, the
third party contact may judge a received message with position as a false
positive if repeated messages note
that the operator's position is continually changing while traveling over
terrain known to be flat, which may
indicate a tether cord that was inadvertently disconnected or incorrectly
reconnected without the operator's
knowledge. However, it would not be advised to ignore the aforementioned alert
if an operator's location
specified in subsequent messages is shown to have changed in an area where a
known highly-variable grade in
the terrain may have caused the physical location change. An advanced system
with terrain-type input may be
used to extend the monitoring of false positives for this aspect.
2Depleted battery action applies only to the external modified tether cord
implementation option where an
external battery can be depleted and no longer allow for monitoring of the
tether cord's cap switch.
4
CA 2992778 2018-01-24
= =
5.2. Example Monitoring Logic
The following figure is an example logic block diagram of general operation of
the software and its integration
with the hardware switch for monitoring.
'User downloads and installs app,''
sets emergency contact and delay Logic Diagram Notes
preferences, and powers on the
,... Bluetooth monitoring module. , 1. The wireless communication
interface is shown as
Sluetooth for descriptive purposes only. Actual
implementation would not be limited to this communication
ed
"-Is the smartphone
protocol. This includes the use of the term "Bluetooth
app opened and N
monitoring module" which is intended to represent the
communicating
module. be it external or part of the OEM equipment, that is
with et ____________________________ N
used to monitor the tether cord cap connection state and
the Bluetooth
moniloring module?, communicate to the user's smanphone.
I I
No / ______
Open arm, enable = 2. The logic diagram is meant to depict basic
functionality and
Yes k, _________ Bluetooth and is not Inclusive of
all possible logic inputs and dependencies
I
connect to Bluetooth
(e.g., ignition switch state, battery level, manual intervention
=
,., monitoring module. through app) that may be used for additional and/or
enhanced
' control as applicable Co the method of implementation and
Is the tether cord cap.' connected and the ..,,
app monitoring its -=
connected state? = specific application.
1 I
No , Connect tether cord 'is
cap to vehicle-mounted 151sable local audible
and
tether switch and
visual alarms, send
7A enable monitoring in
L ___________________________________________________ cancellation message to
Yes
the app. i . emergency contact and
,,, restart monitoring. ..,,.
e _____________________ =
Monitoring for disconnected 4 _________________ /
/ ______ Ye state with continuous 2-way
communication. 4¨,
lc _______________________________________________________ .
. _____________________ ,
r -=
Is a repeat message to be
iv sent according to the user's
r \ repeat message/interval
Has a tether cord cap preferences?
disconnected state \ _______ /
, I been detected? .. yes .. No
=
1 idi 4.
Yes No Has the repeat message
interval duration/frequency
elapsed since the last
et ________________ = , ______ e me
Enable audible/Visual was sent?
essag I
...., alert of disconnect r 1
tion yes No
f - arid begin/continue 1 __ le + = ,..,
message delay timer
=.. l Inable full audible/visual
alarm, retriev.aN
current physical location (GPS and/or
cellular location), assemble message =
e
w with user and location information, and
, N send via preferred method (e.g.. SMS
Has emergency
contact message \.. text) to emergency =dee!.
delay timer expired? r __ )
= / w *Y V V
i I , N, =
No Yes Has the primary Has the tether cord
I l,.. __ i communication
method failed? cep been
reconnected?
=. / _______ = ,
Has the tether cord 1 1
I
Yes No
cap been Yes No
reconnected?
if 1. ___ ,
..
1 _____________ 1 Resend message
No Yes with secondary
I communication
method (e.g., email).
= ____________________________________________________ ) __ = .../
r _________________ =
Disable local W
audible/visual alert of Has the secondary
disconnection.
communication
= / = /
method failed?
= / I I
Yes No
Fig. 5-1 Logic Block Diagram Example
CA 2992778 2018-01-24
