Automatic Boat Fender Controller with Navigation System Integration

Abstract

An automatic boat fender controller which integrates with on-board boat navigation systems (commonly called chartplotters) to provide automated deployment and retrieval of boat fenders. Among other benefits, integration of the automatic boat fender controller with chartplotters allows the automatic boat fender controller to access the chartplotter's more accurate on-board GPS providing more accurate control, and allows boat operators to control their boat fenders from the screen of the chartplotter, consolidating boat operation at a central location in the cockpit.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The following patent applications are expressly incorporated herein by reference in their entireties:

[0002] Ser. No. 19 / 016,495

[0003] Ser. No. 18 / 444,444

[0004] Ser. No. 17 / 353,785

[0005] Ser. No. 17 / 229,439

[0006] Ser. No. 16 / 716,074

[0007] Ser. No. 16 / 130,968

[0008] Ser. No. 15 / 709,421

[0009] Ser. No. 15 / 237,603

[0010] 62 / 360,966

[0011] Ser. No. 15 / 178,515

[0012] Ser. No. 15 / 054,125

[0013] Ser. No. 14 / 981,858

[0014] Ser. No. 14 / 929,369

[0015] 62 / 153,193

[0016] 62 / 200,089

[0017] 62 / 165,798

[0018] 62 / 157,857

[0019] 62 / 153,185

[0020] 62 / 148,725

[0021] Ser. No. 16 / 130,968

[0022] Ser. No. 15 / 369,803BACKGROUNDField of the Art

[0023] The disclosure relates to the field of boating, and more particularly to automated deployment and retrieval of protective boat fenders for use while docking boats.Discussion of the State of the Art

[0024] Boating, in a motorized or sail-powered craft, is both a popular recreational activity, the foundation of the seafood industry and used to protect our sea front borders. The operator of the craft must be able to navigate it safely and also to dock it safely; whether at a stationary, land-based dock, next to another boat, or at some other, similar large adjacent object (any and all of which are hereinafter referred to as a “dock”). Because fenders are located on the outer edge of the boat, manual deployment of fenders may involve some risk and discomfort. Boaters may need to lean over the railing to deploy the fenders. A primary risk of personal injury is from slip and fall accidents including falling onto the deck, falling into the water, falling onto a dock, slipping on the boat hull, or falling between the boat and the dock. There is risk of damage to the boat, as well, if the fenders are deployed improperly, for an example at the wrong height. These risks are exacerbated in cases of stormy weather or large waves, where deploying and positioning the protective boat fenders to keep the boat from violently hitting a dock can be especially tricky and dangerous.

[0025] What is needed is a motorized fender positioning system that enables a boat operator to safely and conveniently deploy and retract boat fenders when needed at reduced cost, simple installation and increased reliability. What is further needed is a boat fender positioning system that integrates into the boat's existing navigation systems.SUMMARY

[0026] Accordingly, the inventor has conceived and reduced to practice, an automatic boat fender controller which integrates with on-board boat navigation systems (commonly called chartplotters) to provide automated deployment and retrieval of boat fenders. Among other benefits, integration of the automatic boat fender controller with chartplotters allows the automatic boat fender controller to access the chartplotter's more accurate on-board GPS providing more accurate control, and allows boat operators to control their boat fenders from the screen of the chartplotter, consolidating boat operation at a central location in the cockpit and eliminating concerns that their mobile device will run out of power. More accurate GPS will allow automation to a level that is not feasible otherwise.BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0027] FIG. 1 is a front isometric view of an exemplary embodiment of a solar powered boat fender positioning system that may be referred as automatic fender.

[0028] FIG. 2 is a front isometric view of an exemplary embodiment of a solar powered boat fender positioning system with its front cover removed.

[0029] FIG. 3 is a front isometric view of an exemplary embodiment of a solar powered boat fender positioning system with its front cover and middle panel removed.

[0030] FIG. 4 is a side elevation view of an exemplary embodiment of a solar powered boat fender positioning system showing details of an exemplary mounting system for the power unit.

[0031] FIG. 5 is a front isometric view of an exemplary embodiment of a removable solar power component of a solar powered boat fender system.

[0032] FIG. 6 is an exploded front isometric view of an exemplary embodiment of a removable solar power component of a solar powered boat fender system while the solar is removed.

[0033] FIG. 7 is a front isometric view of another exemplary embodiment of a removable sealed solar power component of a solar powered boat fender system.

[0034] FIG. 8 is an exploded front isometric view of an exemplary embodiment of a removable sealed solar power component of a solar powered boat fender system.

[0035] FIG. 9 is a block diagram illustrating an exemplary system architecture of a control system for a solar powered boat fender system.

[0036] FIG. 10 is a block diagram illustrating an exemplary communication and control setup between a microcontroller and various devices.

[0037] FIG. 11 shows an exemplary application of a solar-powered boat fender positioning system.

[0038] FIG. 12 is a block diagram illustrating an exemplary system architecture of a control system for a solar powered boat fender system with enhanced low-power standby mode.

[0039] FIG. 13 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with navigation system integration and external ethernet adapter.

[0040] FIG. 14 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with chartplotter integration and internal ethernet adapter.

[0041] FIG. 15 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with chartplotter integration implemented on mobile device

[0042] FIG. 16 is a block diagram illustrating an exemplary integration of automatic boat fender controller with a Garmin™ chartplotter.

[0043] FIG. 17 is a block diagram illustrating an exemplary integration of automatic boat fender controller with a Raymarine™-type chartplotter.

[0044] FIG. 18 is an exemplary messaging diagram for integration of automatic boat fender controller with chartplotter.

[0045] FIG. 19 is an exemplary screenshot of automatic boat fender control with chartplotter integration.

[0046] FIG. 20 is an exemplary system diagram illustrating control of boat fender positioning systems directly from a marine chartplotters by installation of a fender control application onto the chartplotter.

[0047] FIG. 21 illustrates an exemplary fender control application connected to one or more boat fender positioning units.

[0048] FIG. 22 illustrates an exemplary operational flow diagram for a fender control application.

[0049] FIG. 23 illustrates an exemplary computer system on which embodiments described herein may be implemented.DETAILED DESCRIPTION

[0050] The inventor has conceived, and reduced to practice, an automatic boat fender controller which integrates with on-board boat navigation systems (commonly called chartplotters) to provide automated deployment and retrieval of boat fenders. Among other benefits, integration of the automatic boat fender controller with chartplotters allows the automatic boat fender controller to access the chartplotter's more accurate on-board GPS providing more accurate control, better automation, and allows boat operators to control their boat fenders from the screen of the chartplotter, consolidating boat operation at a central location in the cockpit. Eliminating the need to control the automatic boat fenders from a mobile device eliminates the concern that the mobile device will run out of power as the plotters are hard wired to the boats power.

[0051] This patent application is a continuation-in-part of the parent application which was directed to solar powered boat fender positioning systems with removable solar panels and low-power standby mode. The present application builds upon that foundation by adding two significant improvements: an enhanced low-power standby mode configuration and a comprehensive system for integrating automatic boat fender controllers with marine chartplotters.

[0052] The first improvement relates to the power management system of the solar powered boat fender positioning device. The parent application disclosed a system using an electrically-controllable switch to disconnect power to the motor block during periods of non-use, reducing leakage current from approximately 70 microamps to 6 microamps and extending standby time from about 42 days to about 387 days. The present application enhances this approach by configuring the electrically-controllable switch to shut off power to substantially all components except for essential modules. Such essential modules may be the Bluetooth and wake-up functions within the microcontroller. This enhanced configuration reduces the total current draw to microamps or lower during standby, allowing the automatic fender system to remain stored for over a year while still being able to receive Bluetooth signals, wake itself up, and operate immediately when needed. The microcontroller includes always-on power connections to a Bluetooth module and / or a wake-up module, while input / output control and other modules receive switchable power that is disconnected during standby. The Bluetooth wake up may be designed using other modules as well such as watchdog modules. This configuration is particularly advantageousers who store their boats over winter in covered docks or warehouses, as the system can remain installed and operational throughout the storage period without battery drain and can be immediately activated via interface such as Bluetooth when needed without any physical access to the device. One may use other interface or communication methods instead of Bluetooth, such interfaces may include and are not limited to Zigbee or WiFi.

[0053] The second improvement disclosed in this application relates to the integration of automatic boat fender controllers with chartplotter systems. Chartplotters is the common name for marine navigation systems on boats, which on larger boats are integrated into the cockpit (or helm, wheelhouse, or bridge) of the boat as a built-in device. Marine chartplotters manufactured by companies such as Garmin™ and Raymarine™ serve as the central navigation hub on modern boats, providing as an example GPS positioning, electronic charts, depth information, tidal data, and other critical navigational information. The boat captain may operate the vessel from the cockpit where the chartplotter is located. However, these devices do not include fender deployment controls, and there are currently no systems for integration of automatic fender systems with chartplotters.

[0054] Integration of fender controls with chartplotters provides several advantages. First, it allows deployment of fenders from the central cockpit location, eliminating the need to access separate devices during docking. Second, it leverages the chartplotter GPS which may provide sub-meter accuracy in less than a second, compared to lesser accuracy over a longer lock period for mobile phone GPS, and which is never shielded from incoming GPS signals by being located below the boat's hard top. Third, it may provide access to chartplotter functions including tidal information for adjusting fender heights at fixed docks, GPS map information for proximity-based deployment decisions, and compass data for deploying fenders on the correct side based on dock location. Fourth, having superior external GPS from the chartplotter enables reliable automation features such as automatically lifting fenders when the boat accelerates beyond a speed threshold, which is difficult to reliably implement with mobile phone GPS due to false readings especially on larger boats. Fifth, offloading automatic fender deployment and GPS tracking to the chartplotter saves mobile phone battery usage even where the mobile phone acts as the automatic fender controller by reducing GPS usage on the phone itself.

[0055] In embodiments where a dedicated automatic fender controller is used, certain mobile phone wireless connectivity limitations can be overcome. For example, Apple™ iOS devices do not support Bluetooth Extended Range Mode, making them unreliable or unusable on larger boats. While Android™-based mobile phones do support Bluetooth Extended Range Mode, the number of devices that can be controlled using that mode is limited. There is a practical limit of five devices in current Android-based devices in that mode. In embodiments where a dedicated automatic fender controller is used, these limitations can be overcome either through software controls (e.g., disabling limits that may be enabled on mobile phones), or through hardware changes such as adding additional Bluetooth chips (transmitters / receivers) to control additional devices, or by using a different wireless technology (e.g., WiFi or Zigbee), etc.

[0056] The invention addresses the different levels of access provided by different chartplotter manufacturers through multiple embodiments. Some chartplotters (e.g., Garmin™ chartplotters) provide limited HTML5 access and lack apk capability. For integration with these systems, an external ethernet adapter and Automatic Fender Controller (AFC) may be used that connects to the chartplotter via ethernet cable and communicates wirelessly with automatic fender units via Bluetooth or some other wireless technology. The fender controller application is then implemented as an HTML5 application accessible through the Garmin™ chartplotter's web browser interface. The ethernet adapter or AFC may receive power from the boat's electrical system or via Power over Ethernet (PoE) if available. The ethernet adapter may be implemented as a separate device, or its functions may be integrated into the automatic fender controller to create a single unified device. In embodiments where a separate ethernet adapter is used, a mobile phone may act as the automatic fender controller.

[0057] Some chartplotters (e.g., Raymarine™ chartplotters) use a more standard operating system such as Android-based operating system that allows installation of applications and includes native Bluetooth connectivity. For Raymarine™ integration, the system can be implemented in multiple configurations. If proper permissions are allowed by the chartplotter manufacturer, the AFC may be implemented as a application running on the standard operating system. In an alternative, fully wireless configuration, a mobile device running the fender controller application communicates directly with the Raymarine™ chartplotter via Bluetooth and with the automatic fender units, requiring no ethernet connections or permanent installations. An Android application package can be installed on the Raymarine™ chartplotter itself, providing deep integration with the chartplotter's functions and native user interface capabilities. Alternatively, an ethernet adapter can be used for installations where Power over Ethernet (PoE) is desired or where more reliable wired connectivity is preferred. The flexibility of the Raymarine™ platform, with the right access level from Raymarine, may enable wireless-only, application only, ethernet-only, or hybrid configurations combining few methods.

[0058] The application shown in FIG. 13 and forward includes detailed system architectures showing various implementation options. A first architecture (FIG. 13) shows an external ethernet adapter separate from the automatic fender controller, suitable for implementations where modularity is desired. A second architecture (FIG. 14) shows the ethernet adapter functionality integrated into the automatic fender controller, creating a single device that connects to the chartplotter and controls the fender units. A third architecture (FIG. 15) shows a mobile device-based implementation suitable for chartplotters with Bluetooth connectivity, providing maximum portability and minimum cost. Specific implementations are disclosed for both Garmin™ and Raymarine™ chartplotters, demonstrating how the general architectures are adapted to the specific capabilities and access methods of each platform.

[0059] The application further discloses a user interface implementation showing how fender control functions may be integrated into the chartplotter display (FIG. 19). The interface includes selection tabs that place fender control alongside traditional chartplotter functions such as charts and sonar, making fender operations as accessible as other primary chartplotter functions. The example interface displays a boat orientation view showing the locations and deployment status of fenders, grouped controls for deploying all fenders on the port or starboard side with single commands, a control for stowing all fenders simultaneously, an indicator showing whether automatic mode is enabled, and access to configuration settings. The interface integrates navigational data from the chartplotter including GPS position, speed, heading, and fender battery status, providing the boat operator with all necessary information in a unified display. The interface demonstrates good human factors engineering with large touch controls suitable for use with wet or gloved hands, intuitive visual status indicators, and persistent display of critical navigational information even while performing fender operations.

[0060] One or more different aspects may be described in the present application. Further, for one or more of the aspects described herein, numerous alternative arrangements may be described; it should be appreciated that these are presented for illustrative purposes only and are not limiting of the aspects contained herein or the claims presented herein in any way. One or more of the arrangements may be widely applicable to numerous aspects, as may be readily apparent from the disclosure. In general, arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it should be appreciated that other arrangements may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular aspects. Particular features of one or more of the aspects described herein may be described with reference to one or more particular aspects or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific arrangements of one or more of the aspects. It should be appreciated, however, that such features are not limited to usage in the one or more particular aspects or figures with reference to which they are described. The present disclosure is neither a literal description of all arrangements of one or more of the aspects nor a listing of features of one or more of the aspects that must be present in all arrangements.

[0061] Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.

[0062] Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more communication means or intermediaries, logical or physical.

[0063] A description of an aspect with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components may be described to illustrate a wide variety of possible aspects and in order to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders, unless specifically stated to the contrary. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the aspects, and does not imply that the illustrated process is preferred. Also, steps are generally described once per aspect, but this does not mean they must occur once, or that they may only occur once each time a process, method, or algorithm is carried out or executed. Some steps may be omitted in some aspects or some occurrences, or some steps may be executed more than once in a given aspect or occurrence.

[0064] When a single device or article is described herein, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described herein, it will be readily apparent that a single device or article may be used in place of the more than one device or article.

[0065] The functionality or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.

[0066] Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, it should be appreciated that particular aspects may include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. Process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of various aspects in which, for example, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.

[0067] The skilled person will be aware of a range of possible modifications of the various embodiments described herein. Accordingly, the present invention is defined by the claims and their equivalents.Definitions

[0068] “Battery” as used herein means a device that stores electrical energy. A battery typically comprises multiple battery cells. Each battery cell generates a certain nominal voltage, about 1.5V for typical battery types such as alkaline, nickel-metal hydride, and lithium-ion type battery cells. These battery cells are connected in series to obtain a desired voltage, and battery cell series can be connected in parallel to obtain additional current at the desired voltage. The term battery includes large-capacity capacitors when used as energy storage to power a solar-powered device.

[0069] “Chartplotter” and “marine navigation system” are used herein to refer to a navigation system for boats. The functions of these systems vary by brand and model, but typically include functions such as global positioning system (GPS) location calculation, maps and charting, course calculation and plotting, and sometimes tidal information. On smaller boats, marine navigation systems may be handheld, including dedictated handheld marine navigation systems and applications operating on mobile devices. On larger boats, marine navigation systems are typically built in to the cockpit of the boat with larger screens and more functionality. The term “chartplotter” is used frequently herein for conciseness.

[0070] “Global positioning system” and “GPS” as used herein mean any form of system that allows for identifying or calculating the location of a device on Earth, typically via triangulation of signals from satellites, but other signals such as WiFi may be used. Without limitation these terms include all satellite-based positioning systems such as the U.S. GPS, Russian GLONAST, and others.

[0071] “Nominal” as used herein means the nominal rating (e.g., voltage rating, current rating, etc.) of a given electrical or electro-mechanical device. The term nominal means the specified ideal rating for the device and is often called the “name plate” rating as it is the specification placed on the name plate of the device (or in the device's data sheet). The operating values of the device may differ from the nominal rating and may be in a range around the nominal value. For example, the nominal voltage of a battery may be 7.2V, but the operating voltage of a 7.2V battery commonly ranges from a half volt above the nominal voltage to a couple of volts below the nominal voltage.

[0072] “Solar-powered” as used herein means a device is powered in whole or in part by solar panels, whether the solar panels provide power directly to the device or the solar panels charge batteries that provide power to the device, or a combination of the two.

[0073] “Solar panel” as used herein means a device that converts light energy into electrical energy. Solar panels may comprise multiple photovoltaic cells (PV cells, also known as solar cells). Each PV cell generates a certain nominal voltage, about 0.5V for a typical silicon-based battery cell. These PV cells are connected in series to obtain a desired voltage, and PV cell series can be connected in parallel to obtain additional current at the desired voltage.DETAILED DESCRIPTION OF THE DRAWING FIGURES

[0074] FIG. 1 is a front isometric view of an exemplary embodiment of the power unit of a solar powered boat fender positioning system. The power unit 100 of this embodiment comprises a primary housing 200, and a removable solar power component 300. The primary housing 200 is attachable to a structure on a boat (such as a railing), and holds a motor, the electronic control system for the power unit 100, a battery, and a spool for line used to deploy and retract boat fenders. The removable solar power component 300 is attached to the primary housing 200 and is configured to hold a removable solar panel or removable solar panel enclosure.

[0075] The primary housing 200 of this embodiment comprises a front cover 210, a middle panel 220, a rear cover 230, and one or more clamps 240 for attachment of the power unit 100 to a railing or handhold of a boat.

[0076] The front cover 210 of this embodiment comprises a front panel 211 having side panels 212, one or more holes 213 in the side panels for letting out and reeling in line, and one or more screw holes 214 for securing the front cover 210, middle panel 220, and rear cover 230 together using screws or other fasteners. The front cover further comprises extensions 216 with holes 217 for attachment of clamps 240 for attachment of the power unit 200 to a boat railing or handhold. Note that this embodiment comprises two clamps, one on either side of the power unit 100, but only one of the clamps 240 is shown for purposes of clarity in the drawing.

[0077] The clamps 240 of this embodiment are described in detail below herein, but comprise components visible in this drawing of a front bracket 241 with a hexagonal hole for insertion of a nut into which a bolt may be screwed to tighten the front bracket 241 of the clamp 240 and rear bracket (partially shown) of the clamp 240 around the extensions 216 of the front cover 210.

[0078] FIG. 2 is a front isometric view of an exemplary embodiment of the power unit of a solar powered boat fender positioning system with its front cover removed. The power unit 100 of this embodiment comprises a primary housing 200, and a removable solar power component 300. The primary housing 200 is attachable to a structure on a boat (such as a railing), and holds a motor, the electronic control system for the power unit 100, a battery, and a spool for line used to deploy and retract boat fenders. The removable solar power component 300 is attached to the primary housing 200 and is configured to hold a removable solar panel or removable solar panel enclosure.

[0079] The primary housing 200 of this embodiment comprises a front cover 210, a middle panel 220, a rear cover 230, and one or more clamps 240 for attachment of the power unit 100 to a railing or handhold of a boat.

[0080] The middle panel 220 of this embodiment comprises an electronics enclosure 222, a cavity 221 for holding a spool 225 around which line is wound and unwound by a motor, and a hole 223 through which a shaft 251 of the motor is inserted to be attached to the spool 225. The spool 225 comprises outer discs 226 that contain the spooled line and a hole 227 for attachment to the motor shaft 251. The middle panel 220 also comprises columns 224 for attachment of the front cover 210 using screws or other fasteners. The electronics enclosure 222 holds the control system and other electronics for the power unit 100.

[0081] The clamps 240 of this embodiment are described in detail below herein, but comprise components visible in this drawing of a front bracket 241 with a hexagonal hole for insertion of a nut into which a bolt may be screwed to tighten the front bracket 241 of the clamp 240 and rear bracket (partially shown) of the clamp 240 around the extensions 216 of the front cover 210.

[0082] FIG. 3 is a front isometric view of an exemplary embodiment of the power unit of a solar powered boat fender positioning system with its front cover and middle panel removed. The power unit 100 of this embodiment comprises a primary housing 200, and a removable solar power component 300. The primary housing 200 is attachable to a structure on a boat (such as a railing), and holds a motor, the electronic control system for the power unit 100, a battery, and a spool for line used to deploy and retract boat fenders. The removable solar power component 300 is attached to the primary housing 200 and is configured to hold a removable solar panel or removable solar panel enclosure.

[0083] The primary housing 200 of this embodiment comprises a front cover 210, a middle panel 220, a rear cover 230, and one or more clamps 240 for attachment of the power unit 100 to a railing or handhold of a boat.

[0084] The rear cover 230 comprises a real panel (not shown) and side panels 231. In this embodiment, the side panels are thickened to provide sufficient rigidity while having voids 232 to reduce weight. The rear cover 230 houses a motor 250 for winding line on a spool (not shown) attached to the motor's shaft 251 to raise and lower boat fenders and a battery 260 for powering the motor 250 and control system of the power unit 100. The rear cover 230 also comprises screw holes 233 for attachment of the front cover 210 and middle panel 220 using screws or other fasteners.

[0085] The motor 250 of this embodiment is a brushless, direct current, permanent magnet motor, but any suitable type of small motor may be used. In this embodiment, a rotary encoder 252 is used to track the number of full or partial revolutions of the motor shaft 251 in order to determine the amount of line that has been let out from the spool 225. The rotary encoder 252 may likewise be used to track the amount of line that has been reeled in from the spool 225, but in this embodiment full retraction is determined by overcurrent in the motor 250 as detected by the control system monitoring a current meter attached to the motor 250. Using overcurrent in the motor (when the motor is straining at the top of the retraction and unable to reel in the line further) ensures that the line is pulled taut at the top of the retraction.

[0086] The clamps 240 of this embodiment are described in detail below herein, but comprise components visible in this drawing of a front bracket 241 with a hexagonal hole for insertion of a nut into which a bolt may be screwed to tighten the front bracket 241 of the clamp 240 and rear bracket (partially shown) of the clamp 240 around the extensions 216 of the front cover 210.

[0087] FIG. 4 is a side elevation view of an exemplary embodiment of the power unit of a solar powered boat fender positioning system showing details of an exemplary mounting system for the power unit. Here, the power unit 100 is shown from the side with exterior portions of the primary housing 200 and removable solar power component 300 shown, as well as a more detailed side view of the clamps 240.

[0088] The clamps 240 of this embodiment are designed to attach the power unit 100 to a railing, handhold, or similar structure 101 of a boat. In this case, a boat railing 101 is shown in cross-section. In this embodiment, there are two clamps 240, one on each side of the primary housing 200.

[0089] In this embodiment, each clamp 240 comprises a front bracket 241a with a lower jaw portion 243a, a rear bracket 241b with a lower jaw portion 243b, and a single-piece upper jaw 244. The front bracket 241a and rear bracket 241b are clamped either around the extensions 216 via a screw or bolt 247 or, as shown in this configuration, around a short spacer 248 that is the same width as the extensions 216. This affixes the clamps 240 to the primary housing 200. After the clamps 240 are affixed to the primary housing 200, the lower jaw portions 243a-b are placed under the railing 101 and the upper jaw 244 is placed over the railing and secured to the lower jaw portions 243a-b using screws, bolts, or other fasteners. This affixed the power unit 100 to the railing 101 via the clamps 240.

[0090] The clamps are configured to be attached to the primary housing 200 at the extensions 216 on the primary housing 200. In this configuration, while the clamps are still attached to the primary housing 200 at the extensions 216, they are extended backward from the extensions 216 by a long spacer 246 which project the power unit 100 out away from the railing (which is advantageous in situations where the railing is inset from the edge of the boat deck so as to keep the line from rubbing the edge of the boat deck).

[0091] FIG. 5 is a front isometric view of an exemplary embodiment of a removable solar power component of a solar powered boat fender system.

[0092] A primary component that fails in many solar-powered devices are the solar panels themselves. Solar panels have a lifetime of about 15 years, and their performance degrades about 1% each year. Further, on portable solar-powered devices, the solar panels are prone to failure due to impact damage (such as impacts on the solar panels or dropping of the device in which they are installed) causing one or more of the photovoltaic cells in the solar panel to be damaged, rendering the solar panel useless.

[0093] Unfortunately, existing solar-powered devices are not designed for the solar panels to be removable, and so the solar panels cannot be replaced without major refurbishment of the device into which they are installed. A device without removable solar panels must be disassembled, the solar panels must be unglued and / or unsoldered, new solar panels must be glued and / or soldered back, and the device must be re-assembled. Such devices are not considered user-repairable and must be sent back to the manufacturer or to a specialized repair facility to have the solar panels replaced. These repairs and refurbishments are often so costly that it is more economical just to replace the entire device. Thus, removable solar panels would be a major improvement over existing designs for solar powered devices.

[0094] In the case of automatic boat fender positioning devices, using solar power is advantageous in that boats are typically in the sun for long periods of time, so batteries in such a device will be kept charged. Further, using solar power allows such a device to be mounted to the rails of a boat without requiring external power lines running into the boat or otherwise connected to the boat's electrical system, if any. However, the boating environment is harsh and electronic devices often fail due to the constant exposure to the sun and / or the corrosive environment of salt water. Therefore, removable solar panels would be a major improvement for solar powered automatic boat fender positioning devices.

[0095] In this embodiment, the removable solar power component 300 comprises a solar panel housing 310 configured to allow easy installation, removal, and replacement of a solar panel 320 to power the power unit 100 and / or charge the power unit's 100 batteries. The solar panel housing 310 of this embodiment comprises an outer housing 311, a cavity (not shown) for insertion and retention of the solar panel 320, one or more tabs or clips 312 to retain the solar panel 320 in the cavity, and a finger slot 313 for tool-free removal of the solar panel 320 if it needs to be replaced. The solar panel housing 310 further comprises an opening 314 through which wires from the solar panel may be connected to the control system housed in the electronics enclosure 222.

[0096] FIG. 6 is an exploded front isometric view of an exemplary embodiment of a removable solar power component of a solar powered boat fender system. In this embodiment, the removable solar power component 300 comprises a solar panel housing 310 configured to allow easy installation, removal, and replacement of a solar panel 320 to power the power unit 100 and / or charge the power unit's 100 batteries. The solar panel housing 310 of this embodiment comprises an outer housing 311, a cavity 315 for insertion and retention of the solar panel 320 (the cavity 315 of this embodiment having a recessed ledge 318 to hold the outer edge of the solar panel 320), one or more tabs or clips 312 to retain the solar panel 320 in the cavity, and a finger slot 313 for tool-free removal of the solar panel 320 if it needs to be replaced. The solar panel housing 310 further comprises an opening 314, 317 through which wires from the solar panel may be connected to the control system housed in the electronics enclosure 222. The solar panel housing 310 further comprises a raised lip 316 around the opening 314, 317 to prevent water intrusion into the electronics enclosure 222 and drainage holes 318 on the bottom of the solar panel housing 310 to allow any water (whether from leaks or from condensation) inside the solar panel housing 318 to escape. In this embodiment, the joint between the outer edge of the solar panel 320 and the solar panel housing 310 is sealed after installation with silicone adhesive to prevent water intrusion into the solar panel housing 320.

[0097] FIG. 7 is a front isometric view of another exemplary embodiment of a removable solar power component of a solar powered boat fender system. In this alternate embodiment, the removable solar power component 400 comprises the solar panel housing 310 as previously described and a solar panel module 420, configured to allow easy installation, removal, and replacement of the solar panel module 420 to power the power unit 100 and / or charge the power unit's 100 batteries. The components of the solar panel module are shown and described the next drawing.

[0098] FIG. 8 is an exploded front isometric view of an exemplary embodiment of a removable solar power component of a solar powered boat fender system. In this alternate embodiment, the removable solar power component 400 comprises the solar panel housing 310 as previously described and a solar panel module 420, configured to allow easy installation, removal, and replacement of the solar panel module 420 to power the power unit 100 and / or charge the power unit's 100 batteries.

[0099] The solar panel module 420 of this embodiment comprises an upper shell 421 having one or more slots 422, a seal 423 to prevent water intrusion into the solar panel module 420, a glass plate light concentrator 424 for protecting the solar panel 425 from damage and concentrating light into the solar cells of the solar panel 424, a solar panel 425 for generating electrical energy to power the power unit 100 or charge its batteries, a lower shell 426 having one or more tabs for insertion into the slots 422 of the upper shell, one or more holes 428 for drainage and for routing of wires from the solar panel to the control system in the electronics enclosure 222, and a raised lip 429 to keep the solar panel 425 off the bottom of the lower shell 426 to allow any water to drain out of the solar panel module 420 and to allow room for routing of the wires from the solar panel 425 to the holes 428.

[0100] The solar panel module 420 can be easily attached or removed from the solar panel housing 310 by clipping the solar panel module 420 into the one or more tabs or clips 312 of the solar panel housing 310. The entire solar panel module 420 can be replaced or the solar panel module 420 can be easily opened and closed to replace just the solar panel 425 by inserting or removing the one or more tabs 427 of the lower shell 427 into the one or more slots 422 of the upper shell 421. When the solar panel module 420 is closed, the upper shell 421 and lower shell 427 are attached to each other with the seal 423, glass plate light concentrator 424, and the solar panel 425 sandwiched inside.

[0101] FIG. 9 is a block diagram illustrating an exemplary system architecture of a control system for a solar powered boat fender system. The control system 900 of this embodiment has two major improvements over existing control systems for solar-powered devices.

[0102] First, the control system 900 and specifically the boost converter reduces the number of points of failure in the power block 910 of the system by reducing the number of photovoltaic cells required to power devices at a given voltage and reducing the number of battery cells required to power devices at a given voltage. By reducing the number of cells, we increase the size of each cell and therefore their reliability.

[0103] Solar panels may be made up of multiple photovoltaic cells (PV cells, also known as solar cells). Each PV cell generates a certain nominal voltage, about 0.5V for a typical silicon-based PV cell. These PV cells are connected in series to obtain a desired voltage. For example, 24 PV cells will generate a nominal 12V. Additional current at the desired voltage may be obtained by adding more PV cell series parallel to one another (i.e., multiple rows of PV cells series, each PV cell series generating the desired voltage). As the failure of a single PV cell in a series can prevent that series from generating voltage, the failure of a single PV cell in a small solar panel can greatly reduce the voltage and / or current supplied, rendering the solar panel unsuitable for its purpose. Thus, it is advantageous to reduce the number of PV cells required to power a device, so as to reduce the number of potential points of failure in the solar panel.

[0104] Likewise, batteries for solar-powered systems may be made of multiple battery cells. Each battery cell generates a certain nominal voltage, about 1.5V for a typical lithium-ion rechargeable battery cell. These battery cells are connected in series to obtain a desired voltage. For example, 8 battery cells will generate a nominal 12V. Additional current at the desired voltage may be obtained by adding more battery cell series parallel to one another (i.e., multiple rows of battery cells series, each battery cell series generating the desired voltage). As the failure of a single battery cell in a series can prevent that series from generating voltage, the failure of a single battery cell in a small battery (or battery pack) can greatly reduce the voltage and / or current supplied, rendering the battery unsuitable for its purpose. Thus, it is advantageous to reduce the number of battery cells required to power a device, so as to reduce the number of potential points of failure in the battery.

[0105] In this embodiment, the motor 933 is a motor having a nominal (name plate) voltage at 12V, which is a typical voltage for motors used for applications such as the boat fender positioning system described herein. Normally, this would require a solar panel that produces a nominal 12V and a battery that stores energy at a nominal 12V. However, a solar panel with a nominal 12V requires 24 photovoltaic (PV) cells in series, the failure of any one of which will require replacement of the solar panel. A battery storing a nominal 12V requires 8 battery cells, the failure of any one of which will require replacement of the battery. The control system 900 of this embodiment allows for the use for example of a nominal 7.2V solar panel 911 having only 15 PV cells and a nominal 7.2V battery 912 having only 5 batteries, reducing the number of potential points of failure in both the solar panel 911 and the battery 912, extending the average mean time between failures for both the solar panel 911 and the battery 912. The control system 900 does this by using a boost converter 931 (also known as a voltage boost converter) to increase (boost) the 7.2V from the power block 910 to 12V at the motor block 930. Solar panels are made up of multiple photovoltaic cells (PV cells, also known as solar cells). Each PV cell generates a certain nominal voltage, about 0.5V for a typical silicon-based PV cell. These PV cells are connected in series to obtain a desired voltage. For example, 24 PV cells will generate a nominal 12V. Additional current at the desired voltage may be obtained by adding more PV cell series parallel to one another (i.e., multiple rows of PV cells series, each PV cell series generating the desired voltage). As the failure of a single PV cell in a series can prevent that series from generating voltage, the failure of a single PV cell in a small solar panel can greatly reduce the voltage and / or current supplied, rendering the solar panel unsuitable for its purpose. Thus, it is advantageous to reduce the number of PV cells required to power a device, so as to reduce the number of potential points of failure in the solar panel.

[0106] Second, the control system 900 reduces leakage current of the system during periods of non-use by using a low-power, electrically-controlled switch to disconnect the motor block 930 (including among other the current meter and rotary encoder) and additional blocks from power during periods of non-use.

[0107] Leakage current in solar-powered devices is problematic because solar-powered devices are often low-power devices that don't store a great deal of energy in their batteries. Small leakage currents will drain the batteries of such small systems quickly when the device is not in the sun, such that the device may not be usable when it is needed. Leakage currents occur because no components of an electronic system are perfect. For example, dielectric insulators inside capacitors may leak some small amount of current. Leakage current can also occur as displacement current flowing through the capacitance between electrically active components and passive conductive components of an electronic or electromagnetic device, which is common in electric motors. Almost all circuits exhibit some level of leakage current.

[0108] Leakage current can drain batteries over time, which is problematic for systems that have long periods of non-use. In the boating world, for example, boats can often be stored in shelters during winter or in some climates boats can be operated for long periods with little sunlight. Thus, batteries of solar-powered devices on boats used in these conditions can drain due to leakage current, rendering the solar-powered devices unusable until sufficiently charged. Preventing or reducing leakage current in solar-powered devices is advantageous to allow these devices to remain on standby for long periods of time, still ready to use when the standby period ends.

[0109] Leakage current can be greatly reduced by utilizing a lower-power, electrically-controlled switch in the control circuit of the PCB which disconnects power to load components prone to leakage current (motor drivers, motors, etc.) while maintaining power to the controller or some other essential device so that it can be awakened from standby when required. A non-limiting list of electrically-controlled switches includes PN junction diodes, bipolar junction transistors (BJTs), NPN transistors, PNP transistors, field-effect transistors (FETs), metal-oxide-semiconductor field-effect transistors (MOSFETs), silicon controlled rectifiers (SCRs), insulated bipolar transistors (IGBTs), gate turn-off thyristors (GTOs), diode for ACs (DIAC), triode for alternating currents (TRIACs), electrically-controlled dual inline package (DIP) switches, and electromechanical relays. In some embodiments, a transistor is used as the low-power, electrically-controlled switch to disconnect the load components of the device. In some embodiments, the transistor is a field-effect transistor (FET) such as a metal-oxide-semiconductor field-effect transistor (MOSFET), which requires almost no current to disconnect the load components of the device. In this embodiment, the electrically-controlled switch 913 is a power MOSFET designed to operate high-current devices. Power MOSFETs are available for a wide variety of voltages and currents, with very common MOSFETs having specifications of 5-36V and 15-30 A. The MOSFET is operated by the microcontroller (MCU) 922 by passing low-current voltage from one of the MCU's 922 output pins to the base of the MOSFET, allowing a much larger current to pass between the emitter and collector of the MOSFET, powering the motor block 930.

[0110] While many components of electronic systems have leakage current, motor drivers are particularly prone to leakage current. Thus, disconnecting the motor block 930 from the power block 910 during periods of non-use dramatically extends the standby time of the power unit 100 when the motor 933 is not in use and particularly when the solar panel 911 is not producing power to charge the battery 912 (e.g., at night, during cloudy days, when the boat is in a covered storage dock, etc.). As an example, in real-world tests of the embodiment shown here disconnecting the motor block 930 from the power block 910 reduced leakage current from 70 microamps down to 6 microamps, a leakage current reduction of nearly 12 times. Assuming that we wish to keep the battery at or above 90% capacity during standby so that it is immediately available for use without charging when the standby period ends, and assuming use of a 7.2V battery with a capacity of 700 mA, the standby time of the power unit 100 would be increased from about 42 days (1.4 months) to about 387 days (12.9 months). A particular advantage of this embodiment is that users of solar-powered systems no longer have to manually disconnect batteries from their solar-powered devices for periods of use of a year or more. For boaters storing their boats over winter in covered docks, this marks a tremendous improvement over other solar-powered systems.

[0111] The control system 900 of this embodiment comprises a power block 910, a control block 920, and a motor block 930.

[0112] The power block 910 comprises a solar panel 911, a battery 912, and an electrically-controlled switch 913. The solar panel 911 generates electricity from light and provides power to the battery 912, the control block 920, and the motor block 930. As the battery 912 is connected to the same components, the battery 912 also provides power to the control block 920 and motor block 930. In this configuration, some combination of the solar panel 911 and battery 912 will provide power to the control block 920 and motor block 930. When the power required by the control block and motor block 930 is greater than the solar panel 911 can provide by itself, the battery 912 supplies the remainder of the power needed. When the power required is less than the solar panel 911 can provide, the extra power from the solar panel 911 may charge the battery 912.

[0113] As described above, the solar panel 911 and battery 912 of this embodiment are optimized to reduce the number of points of failure in the power block system. The control system 900 of this embodiment comprises a nominal 7.2V solar panel 911 and a nominal 7.2V battery to power a nominal 12V motor. The control system 900 does this by using a boost converter 931 (also known as a voltage boost converter) to increase (boost) the 7.2V from the power block 910 to 12, 18V or the desired voltage at the motor block 930.

[0114] The control block 920 of this embodiment comprises a voltage regulator 921, a microcontroller (MCU) 922, and a wireless transceiver 923. The control block 920 may be always powered by the power block 910. The voltage regulator 921 lowers the 7.2V from the power block 910 down to the operating voltage of the MCU 922 (typically 3.3V or 5V). The wireless transceiver 923 is used to allow communication with external control devices such as mobile phones running applications that allow for control of the power unit 100 (e.g., by having controls for raising and lowering fenders, etc.). The wireless transceiver 923 may be of any suitable type including, but not limited to, WiFi, Bluetooth, etc. The MCU 922 controls the operation of various components and devices of the power unit 100, in this embodiment controlling the wireless transceiver 923, the motor driver 932 (which operates the motor), and the electrically-controlled switch 913. In other embodiments, the MCU 922 may control other components and devices. The MCU 922 receives data from various sensors and devices of the power unit 100, in this embodiment receiving data from the current meter 934 (also known as an ammeter) and from a rotary encoder 934.

[0115] The motor block 930 of this embodiment comprise a boost converter 931, a motor driver 932, a motor 933, a current meter 934 (or ammeter), and a rotary encoder 935.

[0116] The boost converter 931 (also known as a voltage boost converter) increases (boosts) the 7.2V from the power block 910 to 12V at the motor block 930. Boost converters are can be purchased with a variety of input and output voltages, and in other embodiments different voltages may be used for solar panel 911, battery 912, and motor 933.

[0117] The motor driver 932 receives control signals from the MCU 922 and applies the necessary voltage, current, directionality to the motor 933 to implement the control signals. Motor drivers are commonly-available electronic components.

[0118] The motor 933 of this embodiment is a brushless, direct current, permanent magnet motor, but any suitable type of small motor may be used, including stepper motors in some embodiments.

[0119] The current meter 934 is placed in series with the power leads of the motor 933 and is used by the MCU 922 to determine whether the current drawn by the motor 933 is over a specified threshold, indicating that the motor 933 is stalled (e.g., when the line is fully retracted and the boat fender is at the top of its range of motion in its stowed position), in which case the MCU 922 shuts off the motor 933. The rotary encoder 935 is connected to the shaft of the motor and detects the number of full or partial revolutions of the motor shaft 251 in order to determine the amount of line that has been let out from the spool 225.

[0120] In this embodiment, a rotary encoder 935 is used to track the number of full or partial revolutions of the motor shaft in order to determine the amount of line that has been let out from the spool. The rotary encoder 935 may likewise be used to track the amount of line that has been reeled in from the spool, but in this embodiment full retraction is determined by overcurrent in the motor 933 as detected by the MCU 922 monitoring the current meter 934 attached to the motor 933. Using overcurrent in the motor (when the motor is straining at the top of the retraction and unable to reel in the line further) ensures that the line is pulled taut at the top of the retraction. In some embodiments, a stepper motor may be used, obviating the need for a rotary encoder as stepper motors operate in distinct angles of rotation which can be counted by the MCU 922 (i.e., they “step” at a defined angle of rotation for each step).

[0121] FIG. 10 is a block diagram illustrating an exemplary communication and control setup between a microcontroller (MCU) and various devices. In this example, the control system 1060 comprises a power source 1020, a microcontroller 1010, an external interface 1030, and one or more input / output devices 1040a-n. The core of the control system is a microcontroller 1010, which is a small computing device with one or more processors, a memory, communications controllers, and one or more input pins and output pins. Microcontrollers 1010 in this type of application are typically pre-programmed for the intended use. The microcontroller 1010 may have onboard power and / or may be powered by an external power source 1020. The microcontroller 1010 is used to receive input signals at its input pins from one or more devices, make calculations or decisions according to its programming, and send output signals to its output pins to one or more devices. The devices may be any electrical or electronic component or device such as, but not limited to, other computing devices, switches, controls, or sensors.

[0122] The microcontroller 1010 of this example contains an Inter-Integrated Circuit bus (also known as I2C) which allows for fully addressable serial communication with slave devices such as rotary encoders, digital potentiometers, accelerometers, gyroscopes, light sensors, switches, or other devices using common wires for +5 v and ground (for power), a clock signal, and data. In this example, the input / output devices 1040a-n contain a communications controller allowing for I2C serial communications with the microcontroller 1010. However, devices in communication may use any other available means of communication with the microcontroller 1010. Some non-limiting examples of other available means of communication include serial communication protocols such as Inter-Integrated Circuit bus (I2C), Universal Asynchronous Receiver / Transmitter (UART), and Serial Peripheral Interface (SPI); parallel communication protocols such as Small Computer System Interface (SCSI), Peripheral Component Interconnect (PCI), and Integrated Drive Electronics (IDE); wireless communication protocols such as Wireless Fidelity (Wi-Fi), Bluetooth, Radio-Frequency Identification (RFID), and cellular network protocols; or simple high / low or on / off voltage signals on a wire or switch.

[0123] As an example of communication inputs, assume that device A 1040a is a rotary encoder that outputs square-wave signals indicating rotation of the rotary encoder shaft. The signals from the rotary encoder are received by the microcontroller 1010, which counts each change in the signal (typically from low to high, but the reverse is also possible). The degree of rotation of the rotary encoder shaft for each signal change is determined by the resolution of the rotary encoder (e.g., a 10-bit rotary encoder would have 1,024 changes per revolution, with each change representing 0.31062 degrees). In addition to counting the number of changes, the micro-controller can use timers to determine the frequency of changes (corresponding to the angular velocity of the rotary encoder shaft) and changes in the frequency (corresponding to acceleration or deceleration of the rotary encoder shaft). As an example of communications outputs, assume that device B 1040b is a digital potentiometer which contains an I2C controller, allowing the digital potentiometer to be individually addressed as a slave device by the microcontroller, and it resistance to be adjusted electronically, which changes the resistance across the leads of another device, such as a motor.

[0124] FIG. 11 shows an exemplary application of a solar-powered boat fender positioning system. FIG. 11 shows a side 1100 of an exemplary boat fender positioning system set up on a boat with a railing 1101, a deck side 1102, and a rub edge 1103 of a boat above the waterline 1114 (all partial view cutouts). In this embodiment, the solar-powered boat fender positioning system comprises a power unit 100 as described in earlier embodiments above, a line 1108 attached at one end to the spool 225 of the power unit 100 and at its other end to an attachment point 1109 on the boat (in this case the railing 1101), and a fender 1104 having an opening through which the line 1108 passes. In this exemplary embodiment, the opening in the fender 1004 is along the fender's longitudinal axis. Further, a fender 1104 in retracted position (with a dotted line indicating the center hole) is shown, and a line 1108 that passes through the fender's center hole. Line 1108 is attached at one end to a fixed location 1109 of the boat, for example the railing 1109. That fixed location may be the boat cleat, the stanchion or any other boat part. In some cases one may connect that fixed location directly to the boat using a screw, a glue, a vacuum or some other mechanism. The other end of line 1108 may be connected to a spool or winding drum or some other mechanism 225 attached to the power unit 100 which may be attached to the boat railings 1101 with screws or bolts or zip ties or some other attaching mechanism 1107a, b such as clamps 240 as described above. The motor of the power unit 100 is controlled by the MCU 922 to pull up the fender 1104 into a top resting position whereupon, while retracting fender 1104, the power unit 100 may be configured to detect changes in current or other means such as a switch, and is configured to change its operation if change in state is detected for example an overcurrent or change in current state is detected. Fender 1104 is also shown in lower positions, such as 1110 and 1112. These are not additional fenders to fender 1104, but one and the same, in different positions based on line loop extensions as indicated by longer lines loops 1111 and 1113 respectively. The line comes out of the spool or winding drum or another winding mechanism 225 on power unit 100. Further, in some cases state detection (current, switch or other) is based at least in part on a configured current limit. Also, in some other cases an overcurrent condition or change in current state may be caused by a tangle in the line 1108. Furthermore, in yet other cases, upon current change detection, the system attempts to achieve a full retraction to the rest position by reversals of line 1108 movement. In yet other cases, a camera (not shown) with visual recognition software is used instead of or in addition to current sensing. In some cases, if fender 1104 retraction fails after the number of reversals, an alert is provided to an operator. In several of the herein described cases, after the user selects a height, the time to reach said height is changed based on the voltage of the batteries, to compensate for the actual speed of the motor of the power unit 100. Further, in some cases, the system deploys to a previously determined height upon approaching a previously set area for docking. Positioning in this configuration relies on a combination of gravity and friction to change the orientation of the fender from roughly horizontal to roughly vertical. As gravity pulls the fender down by sliding along the line as the line is let out, friction between the line and fender to keeps the fender closer to the point of attachment along the line than to the power unit 100, meaning that the end of the fender facing toward the power unit 100 is lowered more than the end of the fender facing the attachment point 1109. In some aspects flexible tubing (not shown) maybe added to the inside of the fender 1104 or around the line 1108 to better control friction. In some cases end pieces may be added with a funnel shape (not shown) to control friction and / or to improve longevity of fender 1104. In yet other cases, the line 1108 may have a special coating to control friction.

[0125] FIG. 12 is a block diagram illustrating an exemplary system architecture of a control system for a solar powered boat fender system with enhanced low-power standby mode. The control system 1200 of this embodiment has improvements over the control system of FIG. 9 by providing maximum power savings through selective disconnection of power to all components except essential wake-up and communication functions during periods of non-use. Different implementations may change which components are essential to be always power on: for example in one implementation the communication device may be always powered (1242) which in a different implementation even the communication device is powered off during none usage times. In one implementation the communication device may be controlling the switch, in a different implementation the switch will be controlled by a dedicated controller or a simple timer.

[0126] The control system 1200 of this embodiment comprises a power block 1210, a control block 1220, and a motor block 1230.

[0127] The power block 1210 comprises a solar panel 1211, a battery 1212, and an electrically-controllable switch 1213. The solar panel 1211 generates electricity from light and provides power to the battery 1212, the control block 1220, and the motor block 1230. As the battery 1212 is connected to the same components, the battery 1212 also provides power to the control block 1220 and motor block 1230. In this configuration, some combination of the solar panel 1211 and battery 1212 will provide power to the control block 1220 and motor block 1230. When the power required by the control block and motor block 1230 is greater than the solar panel 1211 can provide by itself, the battery 1212 supplies the remainder of the power needed. When the power required is less than the solar panel 1211 can provide, the extra power from the solar panel 1211 charges the battery 1212.

[0128] As described in the embodiment of FIG. 9, the solar panel 1211 and battery 1212 of this embodiment are optimized to reduce the number of points of failure in the power block system. The control system 1200 of this embodiment comprises a nominal 7.2V solar panel 1211 and a nominal 7.2V battery to power a nominal 12V motor. The control system 1200 does this by using a boost converter 1231 (also known as a voltage boost converter) to increase (boost) the 7.2V from the power block 1210 to 12V at the motor block 1230.

[0129] The electrically-controllable switch 1213 in this embodiment provides significantly enhanced power savings compared to the embodiment shown in FIG. 9. In the embodiment shown in FIG. 9, the electrically-controllable switch 913 was configured to disconnect power to the motor block 930 during periods of non-use while maintaining power to the entire control block 920. In the improved embodiment shown in FIG. 12, the electrically-controllable switch 1213 is configured to disconnect power to both the motor block 1230 and to most of the control block 1220 during periods of non-use, while maintaining power only to critical always-on functions within the microcontroller 1240.

[0130] The control block 1220 of this embodiment comprises a voltage regulator 1221, a microcontroller (MCU) 1240, and a wireless transceiver 1223. The voltage regulator 1221 lowers the 7.2V from the power block 1210 down to the operating voltage of the MCU 1240 (typically 3.3V or 5V). The wireless transceiver 1223 is used to allow communication with external control devices such as mobile phones running applications that allow for control of the power unit (e.g., by having controls for raising and lowering fenders, etc.). The wireless transceiver 1223 may be of any suitable type including, but not limited to, WiFi, Bluetooth, etc.

[0131] The microcontroller 1240 of this embodiment is shown in expanded detail to illustrate the internal functional modules that enable the enhanced low-power standby mode. The microcontroller 1240 comprises a Bluetooth module 1242, a wake-up module 1241, a processor 1243, and an I / O control 1244.

[0132] In this example the Bluetooth module 1242 is configured to receive always-on power from the power block 1210, allowing it to remain operational even when the rest of the control block 1220 and the motor block 1230 are powered down. This allows the power unit to receive and respond to Bluetooth signals at any time, enabling remote activation from standby mode without requiring any physical interaction with the device. In a different implementation even the Bluetooth module (122) may be turned off during non operation. The Bluetooth module 1242 communicates with the wireless transceiver 1223 to receive control commands from external devices.

[0133] The wake-up module 1241 is also configured to receive always-on power from the power block 1210. The wake-up module 1241 monitors for wake-up conditions and signals the electrically-controllable switch 1213 to restore power to the rest of the control block 1220 and motor block 1230 when the device needs to operate. The wake-up module may be implemented inside the Bluetooth module or inside some other controller. Wake-up conditions may include, but are not limited to, receiving a Bluetooth signal to deploy or retract fenders, detecting a scheduled operation time, or responding to other programmed triggers.

[0134] The processor 1243 and I / O control 1244 receive switchable power that is controlled by the electrically-controllable switch 1213. During periods of non-use, power to the processor 1243 and I / O control 1244 is disconnected, significantly reducing leakage current and extending battery standby time. When the wake-up module 1241 signals a wake-up condition, the electrically-controllable switch 1213 restores power to the processor 1243 and I / O control 1244, allowing normal operation to resume.

[0135] The processor 1243 controls the operation of various components and devices of the power unit, in this embodiment controlling the wireless transceiver 1223, the motor driver 1232 (which operates the motor), and the electrically-controllable switch 1213. In other embodiments, the processor 1243 may control other components and devices. The I / O control 1244 receives data from various sensors and devices of the power unit, in this embodiment receiving data from the current meter 1234 (also known as an ammeter) and from a rotary encoder 1235.

[0136] The motor block 1230 of this embodiment comprises a boost converter 1231, a motor driver 1232, a motor 1233, a current meter 1234 (or ammeter), and a rotary encoder 1235.

[0137] The boost converter 1231 (also known as a voltage boost converter) increases (boosts) the 7.2V from the power block 1210 to 12V at the motor block 1230. Boost converters can be purchased with a variety of input and output voltages, and in other embodiments different voltages may be used for solar panel 1211, battery 1212, and motor 1233.

[0138] The motor driver 1232 receives control signals from the processor 1243 of the MCU 1240 and applies the necessary voltage, current, directionality to the motor 1233 to implement the control signals. Motor drivers are commonly-available electronic components.

[0139] The motor 1233 of this embodiment is a brushless, direct current, permanent magnet motor, but any suitable type of small motor may be used, including stepper motors in some embodiments.

[0140] The current meter 1234 is placed in series with the power leads of the motor 1233 and is used by the processor 1243 to determine whether the current drawn by the motor 1233 is over a specified threshold, indicating that the motor 1233 is stalled (e.g., when the line is fully retracted and the boat fender is at the top of its range of motion in its stowed position), in which case the processor 1243 shuts off the motor 1233. The rotary encoder 1235 is connected to the shaft of the motor and detects the number of full or partial revolutions of the motor shaft in order to determine the amount of line that has been let out from the spool.

[0141] In this embodiment, a rotary encoder 1235 is used to track the number of full or partial revolutions of the motor shaft in order to determine the amount of line that has been let out from the spool. The rotary encoder 1235 may likewise be used to track the amount of line that has been reeled in from the spool, but in this embodiment full retraction is determined by overcurrent in the motor 1233 as detected by the processor 1243 monitoring the current meter 1234 attached to the motor 1233. Using overcurrent in the motor (when the motor is straining at the top of the retraction and unable to reel in the line further) ensures that the line is pulled taut at the top of the retraction. In some embodiments, a stepper motor may be used, obviating the need for a rotary encoder as stepper motors operate in distinct angles of rotation which can be counted by the processor 1243 (i.e., they “step” at a defined angle of rotation for each step).

[0142] The enhanced low-power standby mode provided by this embodiment dramatically extends the standby time of the solar-powered device by reducing leakage current to an absolute minimum. In the embodiment shown in FIG. 9, disconnecting the motor block from the power block reduced leakage current from 70 microamps down to 6 microamps, a leakage current reduction of nearly 12 times. In the improved embodiment shown in FIG. 12, by additionally disconnecting power to the processor 1243 and I / O control 1244 while maintaining only the minimal current required by the Bluetooth module 1242 and wake-up module 1241, the total leakage current during standby can be reduced to milliamps or even lower. This reduction in leakage current allows for long-term storage of the automatic fender system (even over a year) while still allowing it to receive Bluetooth signals, wake itself up, and operate flawlessly after long-term storage.

[0143] A particular advantage of this embodiment is that users of solar-powered systems no longer have to manually disconnect batteries from their solar-powered devices for periods of non-use of a year or more. For boaters storing their boats over winter in covered docks, this marks a tremendous improvement over other solar-powered systems, as the automatic fender system can remain installed and operational throughout the storage period without battery drain, and can be immediately activated via Bluetooth when needed without any physical access to the device.

[0144] Leakage current in solar-powered devices is problematic because solar-powered devices are often low-power devices that don't store a great deal of energy in their batteries. Small leakage currents will drain the batteries of such small systems quickly when the device is not in the sun, such that the device may not be usable when it is needed. Leakage currents occur because no components of an electronic system are perfect. For example, dielectric insulators inside capacitors may leak some small amount of current. Leakage current can also occur as displacement current flowing through the capacitance between electrically active components and passive conductive components of an electronic or electromagnetic device, which is common in electric motors. Almost all circuits exhibit some level of leakage current.

[0145] Leakage current can drain batteries over time, which is problematic for systems that have long periods of non-use. In the boating world, for example, boats can often be stored in shelters during winter or in some climates boats can be operated for long periods with little sunlight. Thus, batteries of solar-powered devices on boats used in these conditions can drain due to leakage current, rendering the solar-powered devices unusable until sufficiently charged. Preventing or reducing leakage current in solar-powered devices is advantageous to allow these devices to remain on standby for long periods of time, still ready to use when the standby period ends.

[0146] As described herein, leakage current can be greatly reduced by utilizing a lower-power, electrically-controlled switch in the control circuit of the device which disconnects power to load components prone to leakage current (motor drivers, motors, processors, I / O controllers, etc.) while maintaining power to only the minimal components necessary for wake-up functionality (Bluetooth module and wake-up module) so that the device can be awakened from standby when required. A non-limiting list of electrically-controlled switches includes PN junction diodes, bipolar junction transistors (BJTs), NPN transistors, PNP transistors, field-effect transistors (FETs), metal-oxide-semiconductor field-effect transistors (MOSFETs), silicon controlled rectifiers (SCRs), insulated bipolar transistors (IGBTs), gate turn-off thyristors (GTOs), diode for ACs (DIAC), triode for alternating currents (TRIACs), electrically-controlled dual inline package (DIP) switches, and electromechanical relays. In some embodiments, a transistor is used as the low-power, electrically-controlled switch to disconnect the load components of the device. In some embodiments, the transistor is a field-effect transistor (FET) such as a metal-oxide-semiconductor field-effect transistor (MOSFET), which requires almost no current to disconnect the load components of the device. In this embodiment, the electrically-controllable switch 1213 is a power MOSFET designed to operate high-current devices. Power MOSFETs are available for a wide variety of voltages and currents, with very common MOSFETs having specifications of 5-36V and 15-30A. The MOSFET is operated by the wake-up module 1241 by passing low-current voltage to the base of the MOSFET, allowing a much larger current to pass between the emitter and collector of the MOSFET, powering the processor 1243, I / O control 1244, and motor block 1230.

[0147] While many components of electronic systems have leakage current, motors and processors are particularly prone to leakage current. Thus, disconnecting the motor block 1230 and the processor 1243 and I / O control 1244 from the power block 1210 during periods of non-use dramatically extends the standby time of the power unit when the motor 1233 is not in use and particularly when the solar panel 1211 is not producing power to charge the battery 1212 (e.g., at night, during cloudy days, when the boat is in a covered storage dock, etc.).

[0148] FIG. 13 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with navigation system integration and external ethernet adapter 1300. This embodiment provides a system for integrating an automatic fender controller with chartplotters to allow deployment of fenders from a central location on a boat, such as the cockpit where the captain of the boat operates everything else. Chartplotters are the common name for navigation systems integrated into boats. The two primary manufacturers of chartplotters are Garmin™™ and Raymarine™™, so non-limiting examples of integrations with these systems will be described herein. The invention solves several problems in the boating industry related to deployment of fenders by providing centralized control, improved GPS accuracy, reduced battery drain on mobile devices, and access to chartplotter functions for integration into fender deployment decisions.

[0149] The system architecture 1300 of this embodiment comprises an ethernet adapter 1310 and an automatic fender controller (AFC) 1320. The ethernet adapter 1310 serves as an intermediary device that connects to a chartplotter via an ethernet cable and communicates wirelessly with one or more automatic fender units. The automatic fender controller (AFC) 1320 may be implemented as a stand-alone device, or may be implemented as a smartphone, tablet, or other mobile device.

[0150] The ethernet adapter 1310 comprises a wireless interface 1311, a power supply 1312, and an ethernet interface 1313. The wireless interface 1311 provides data communication to and from automatic fender units installed on the boat. The wireless interface 1311 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols. In some embodiments, the wireless interface 1311 utilizes Bluetooth Low Energy with extended range mode to support communication with a larger number of automatic fender units across larger boats.

[0151] The power supply 1312 provides electrical power to the ethernet adapter 1310. In some embodiments, the power supply 1312 receives power from an external source such as the boat's electrical system. In other embodiments, the power supply 1312 may receive power via Power over Ethernet (PoE) through the ethernet interface 1313 if the chartplotter or network switch supports PoE. In yet other embodiments, the power supply 1312 may comprise a battery or solar panel as described in earlier embodiments. The ability to receive power via Power over Ethernet is particularly advantageous as it eliminates the need for separate power connections when the chartplotter or associated network infrastructure provides PoE capability.

[0152] The ethernet interface 1313 provides data synchronization with a chartplotter via an ethernet cable connection. The ethernet interface 1313 enables bidirectional communication between the ethernet adapter 1310 and the chartplotter, allowing the ethernet adapter 1310 to receive GPS data, tidal information, compass and boat direction information, GPS map information, and other navigational data from the chartplotter. The ethernet interface 1313 also allows the ethernet adapter 1310 to send status updates and receive control commands for display on the chartplotter screen.

[0153] The automatic fender controller (AFC) 1320 comprises a wireless interface 1321, a fender controller application 1322, a power supply 1323, and an optional ethernet interface 1324. As noted, the automatic fender controller (AFC) 1320 may be implemented as a smartphone, tablet, or other mobile device, or may be integrated directly into the ethernet adapter 1310.

[0154] The wireless interface 1321 of the automatic fender controller (AFC) 1320 provides data communication to and from the chartplotter. In embodiments where the automatic fender controller (AFC) 1320 is implemented as a separate mobile device, the wireless interface 1321 communicates with the ethernet adapter 1310, which in turn communicates with the chartplotter via the ethernet interface 1313. The wireless interface 1321 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols.

[0155] The fender controller application 1322 provides the software logic for controlling automatic fender units based on chartplotter data and user inputs. The fender controller application 1322 may be implemented in various forms depending on the chartplotter system being integrated with. In some embodiments compatible with chartplotters that provide limited access to their operating systems, such as Garmin™ chartplotters, the fender controller application 1322 is implemented using HTML5 technology. In other embodiments compatible with chartplotters that allow installation of applications, such as Raymarine™ chartplotters which use an Android-based operating system, the fender controller application 1322 is implemented as an APK (Android application package) that can be installed directly on the chartplotter.

[0156] The fender controller application 1322 provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. The fender controller application 1322 receives navigational data from the chartplotter including GPS position, speed, heading, depth, tidal information, and map data, and uses this information to make intelligent fender deployment decisions. For example, the fender controller application 1322 may automatically deploy fenders when the boat enters a geofenced harbor area, automatically adjust fender heights based on tidal information when docked at fixed docks, deploy fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lift fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock.

[0157] The power supply 1323 provides electrical power to the automatic fender controller (AFC) 1320. In embodiments where the automatic fender controller (AFC) 1320 is implemented as a mobile device such as a smartphone or tablet, the power supply 1323 is the battery of the mobile device. In embodiments where the automatic fender controller (AFC) 1320 is integrated into the ethernet adapter 1310, the power supply 1323 may be the same as the power supply 1312 of the ethernet adapter 1310. Optionally, the power supply 1323 may receive power via Power over Ethernet through the ethernet interface 1324 when available.

[0158] The optional ethernet interface 1324 provides an alternative or supplementary connection option for the automatic fender controller (AFC) 1320. In some embodiments, the automatic fender controller (AFC) 1320 may connect directly to the chartplotter or to the ethernet adapter 1310 via the ethernet interface 1324 instead of or in addition to using the wireless interface 1321. The ethernet interface 1324 may also support Power over Ethernet to charge or power the automatic fender controller (AFC) 1320 when it is a mobile device.

[0159] The architecture shown in FIG. 13 is particularly suited for integration with chartplotter systems that provide limited access to their operating systems, such as Garmin™ chartplotters. In such systems, the chartplotter does not have Bluetooth connectivity, so the ethernet adapter 1310 serves as a necessary bridge between the chartplotter and the automatic fender units. The ethernet adapter 1310 connects to the chartplotter via an ethernet cable through the ethernet interface 1313 and provides the wireless communication capability through the wireless interface 1311 that the chartplotter lacks.

[0160] The fender controller application 1322 running on the automatic fender controller (AFC) 1320 implements the control logic and user interface for fender operations. In the case of Garmin™ chartplotters which provide HTML5 access, the fender controller application 1322 is implemented as an HTML5 application that can be accessed through the chartplotter's web browser interface. The HTML5 application communicates with the ethernet adapter 1310 via network protocols to send commands to the automatic fender units and receive status updates.

[0161] In alternative embodiments, the ethernet adapter 1310 functionality may be fully integrated into the automatic fender controller (AFC) 1320, creating a single unified device that connects to the chartplotter via ethernet and controls the automatic fender units via wireless communication. This integration simplifies the system architecture and reduces the number of separate devices that need to be installed and maintained on the boat.

[0162] The system architecture 1300 supports various communication flows. Data flows from the chartplotter through the ethernet interface 1313 to the ethernet adapter 1310, providing GPS data, tidal information, navigational data, and other chartplotter information. This data is synchronized with the fender controller application 1322 either through the wireless interface 1321 (when the automatic fender controller (AFC) 1320 is a separate device) or directly (when integrated). The fender controller application 1322 processes this data and generates control commands for the automatic fender units, which are transmitted through the wireless interface 1321 to the ethernet adapter 1310 and then through the wireless interface 1311 to the automatic fender units.

[0163] Status data flows in the reverse direction, with automatic fender units sending status updates including battery levels, fender positions, and operational states through the wireless interface 1311 to the ethernet adapter 1310, which forwards this information to the fender controller application 1322. The fender controller application 1322 can then display this status information on the chartplotter screen, providing the boat operator with real-time visibility into the state of all automatic fender units from the central control location in the cockpit.

[0164] Power management in this embodiment is flexible and adaptable to various boat configurations. The ethernet adapter 1310 may receive power from the boat's electrical system through the power supply 1312, or may receive power via Power over Ethernet if the chartplotter or network infrastructure supports it. Similarly, the automatic fender controller (AFC) 1320 may be powered by its own battery when implemented as a mobile device, or may receive power from the ethernet adapter 1310 or via Power over Ethernet when such capability is available. This flexibility allows the system to be adapted to different chartplotter configurations and boat electrical systems without requiring specific power infrastructure.

[0165] FIG. 14 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with chartplotter integration and internal ethernet adapter 1400. This embodiment provides a simplified and integrated system architecture compared to the embodiment shown in FIG. 13, wherein ethernet adapter functionality is integrated directly into an automatic fender controller (AFC) 1410 to create a single unified device. This integration eliminates the need for separate ethernet adapter and controller devices, simplifying installation, reducing the number of components that need to be maintained, and providing a more compact solution for boats with limited space.

[0166] The system architecture 1400 of this embodiment comprises an automatic fender controller (AFC) 1410 that integrates all necessary functions for chartplotter communication and automatic fender control in a single device. The automatic fender controller (AFC) 1410 serves both as the interface to the chartplotter and as the controller for one or more automatic fender units, combining the functionality that was distributed across multiple devices in the embodiment of FIG. 13.

[0167] The automatic fender controller (AFC) 1410 comprises a wireless interface 1411, a fender controller application 1412, a power supply 1413, and an ethernet interface 1414. By integrating all of these components into a single device, this embodiment provides a streamlined solution that is easier to install and configure than systems requiring multiple separate devices.

[0168] The wireless interface 1411 provides data communication to and from automatic fender units installed on the boat. The wireless interface 1411 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols. In some embodiments, the wireless interface 1411 utilizes Bluetooth Low Energy with extended range mode to support communication with multiple automatic fender units across larger boats. The wireless interface 1411 in this embodiment performs the same function as the wireless interface 1311 of the ethernet adapter in FIG. 13, but is integrated directly into the automatic fender controller (AFC) 1410 rather than being in a separate device.

[0169] The wireless interface 1411 enables the automatic fender controller (AFC) 1410 to communicate with multiple automatic fender units simultaneously. In some embodiments, the wireless interface 1411 can control a large number of boat fender positioning systems (e.g., 6 or more) by a single system, which is essential for larger boats that require more fenders. This represents a significant improvement over mobile device implementations where only approximately five boat fender positioning systems can be controlled from a single mobile device due to limitations in mobile device Bluetooth implementations when using extended range mode.

[0170] The fender controller application 1412 provides the software logic for controlling automatic fender units based on chartplotter data and user inputs. The fender controller application 1412 may be implemented in various forms depending on the chartplotter system being integrated with. In some embodiments compatible with chartplotters that provide limited access to their operating systems, such as Garmin™ chartplotters, the fender controller application 1412 is implemented using HTML5 technology. In other embodiments compatible with chartplotters that allow installation of applications, such as Raymarine™ chartplotters which use an Android-based operating system, the fender controller application 1412 is implemented as an APK (Android application package) that can be installed directly on the chartplotter. In embodiments connected to chartplotters that have wireless interfaces (such as Raymarine™), the ethernet interface 1414 does not have to be used and data can be transferred to and from the chartplotter using the wireless interface 1411.

[0171] The fender controller application 1412 provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. The fender controller application 1412 receives navigational data from the chartplotter including GPS position, speed, heading, depth, tidal information, and map data through the ethernet interface 1414, and uses this information to make intelligent fender deployment decisions.

[0172] For example, the fender controller application 1412 may automatically deploy fenders when the boat enters a geofenced harbor area, automatically adjust fender heights based on tidal information when docked at fixed docks, deploy fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lift fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock. These automated functions are made possible by the high-quality GPS data and navigational information available from the chartplotter, which is faster and far more accurate than GPS data from mobile phones.

[0173] The GPS of a chartplotter can be located down to sub-meter accuracy in less than a second, while GPS of a mobile phone can only be located down to tens-of-meters accuracy within several seconds (but can be more accurate down to a couple of meters after 10 or more seconds). This improved GPS accuracy enables reliable automation features may be unreliable if implemented with mobile phone GPS. For example, having a better external GPS from the chartplotter provides more reliable functionality for automatically lifting fenders when the boat accelerates beyond some speed threshold. Boaters often forget to lift fenders when they leave the dock, which is a major problem as deployed fenders create drag and can cause boat damage at higher boat speeds.

[0174] Using a phone GPS, the system may not reliably implement automatic lifting because false readings occur, especially on bigger boats that have hard tops and glass surfaces which may interfere with GPS signals. The boat's external GPS from the chartplotter does not suffer from these interference issues, therefore false readings should not occur providing a more reliable level of automation including fully automatic fender deployment and lifting based on reliable position and speed data.

[0175] The power supply 1413 provides electrical power to the automatic fender controller (AFC) 1410. In some embodiments, the power supply 1413 receives power from an external source such as the boat's electrical system. In other embodiments, the power supply 1413 may receive power via Power over Ethernet (PoE) through the ethernet interface 1414 if the chartplotter or network switch supports PoE. In yet other embodiments, the power supply 1413 may comprise a battery, solar panel, or combination thereof as described in earlier embodiments.

[0176] The ability to receive power via Power over Ethernet is advantageous as it eliminates the need for separate power connections when the chartplotter or associated network infrastructure provides PoE capability. This simplifies installation by reducing the number of cables and connections required, and ensures that the automatic fender controller (AFC) 1410 remains powered as long as the chartplotter network is active. In embodiments where Power over Ethernet is not available, the power supply 1413 can be connected to the boat's electrical system or can use an independent power source such as a battery or solar panel.

[0177] The ethernet interface 1414 provides data communication to and from the chartplotter via an ethernet cable connection. The ethernet interface 1414 enables bidirectional communication between the automatic fender controller (AFC) 1410 and the chartplotter, allowing the automatic fender controller (AFC) 1410 to receive GPS data, tidal information, compass and boat direction information, GPS map information, and other navigational data from the chartplotter. The ethernet interface 1414 also allows the automatic fender controller (AFC) 1410 to send status updates and receive control commands for display on the chartplotter screen.

[0178] In this integrated embodiment, the ethernet interface 1414 may optionally support Power over Ethernet to receive power from the chartplotter or network infrastructure, as indicated by the optional power connection shown in the diagram. This optional power capability provides flexibility in how the automatic fender controller (AFC) 1410 is powered, allowing the system to adapt to different boat configurations and available power sources without requiring specific power infrastructure.

[0179] The integration of ethernet adapter functionality directly into the automatic fender controller (AFC) 1410 reduces the total number of devices that need to be installed on the boat, simplifying installation and reducing potential points of failure. Fewer devices mean fewer connections to make and maintain, less physical space required for installation, and reduced complexity in troubleshooting and maintenance. However, for some applications, having a separate ethernet adapter may be preferrable.

[0180] The architecture shown in FIG. 14 allows use with either Garmin™-type or Raymarine™-type chartplotters in a single unit.

[0181] The fender controller application 1412 implements the control logic and user interface for fender operations. In the case of Garmin™ chartplotters which provide HTML5 access, the fender controller application 1412 is implemented as an HTML5 application that can be accessed through the chartplotter's web browser interface. The HTML5 application communicates with the automatic fender controller (AFC) 1410 via network protocols to send commands to the automatic fender units and receive status updates. Since the fender controller application 1412 and the wireless interface 1411 are integrated in the same device, communication is direct and does not require additional wireless protocols between separate devices.

[0182] The system architecture 1400 supports streamlined communication flows. Data flows from the chartplotter through the ethernet interface 1414 directly to the fender controller application 1412, providing GPS data, tidal information, navigational data, and other chartplotter information. The fender controller application 1412 processes this data and generates control commands for the automatic fender units, which are transmitted directly through the wireless interface 1411 to the automatic fender units. This direct path eliminates the intermediate communication steps required in the embodiment of FIG. 13, reducing latency and improving system responsiveness.

[0183] Status data flows in the reverse direction, with automatic fender units sending status updates including battery levels, fender positions, and operational states through the wireless interface 1411 directly to the fender controller application 1412. The fender controller application 1412 can then display this status information on the chartplotter screen via the ethernet interface 1414, providing the boat operator with real-time visibility into the state of all automatic fender units from the central control location in the cockpit.

[0184] The integrated design of this embodiment makes it particularly suitable for permanent installation on boats. The automatic fender controller (AFC) 1410 can be mounted in a convenient location near the chartplotter, connected via a single ethernet cable, and optionally powered via Power over Ethernet, requiring minimal installation effort and creating a clean, professional installation with minimal visible wiring. Once installed, the system provides reliable, long-term operation without the need for battery management or maintenance of multiple separate devices.

[0185] FIG. 15 is a block diagram illustrating an exemplary system architecture for automatic boat fender controller with chartplotter integration implemented on mobile device 1500. This embodiment provides a mobile device-based implementation of the automatic fender controller that can communicate directly with chartplotters having Bluetooth connectivity, such as Raymarine™ chartplotters. This embodiment eliminates the need for ethernet connections and external adapter devices by leveraging the wireless capabilities of both the mobile device and compatible chartplotters, providing a flexible and portable solution for chartplotter-integrated fender control.

[0186] The system architecture 1500 of this embodiment comprises an automatic fender controller (AFC) implemented on mobile device 1510. The mobile device may be any suitable mobile computing device including, but not limited to, smartphones, tablets, or other portable computing devices capable of running applications and supporting wireless communications. This embodiment is particularly suited for integration with chartplotter systems that support Bluetooth connectivity and allow installation of applications, such as Raymarine™ chartplotters which use an Android-based operating system.

[0187] The automatic fender controller (AFC) implemented on mobile device 1510 comprises a wireless interface 1511, a fender controller application 1512, and a power supply 1513. By implementing the automatic fender controller on a mobile device, this embodiment provides a solution that requires no additional hardware beyond the mobile device itself, making it the most cost-effective and easily deployable implementation for boats equipped with compatible chartplotters.

[0188] The wireless interface 1511 provides bidirectional wireless data communication both to and from the chartplotter and to and from automatic fender units installed on the boat. The wireless interface 1511 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols. In typical embodiments, the wireless interface 1511 uses Bluetooth or Bluetooth Low Energy for communication with both the chartplotter and the automatic fender units.

[0189] The wireless interface 1511 performs dual functions in this embodiment. First, it establishes a wireless connection with the chartplotter to receive GPS data, tidal information, navigational data, compass and boat direction information, GPS map information, and other data from the chartplotter, and to send status updates and control information back to the chartplotter for display. Second, it establishes wireless connections with one or more automatic fender units to send deployment and retrieval commands and to receive status information including battery levels, fender positions, and operational states.

[0190] In some embodiments, the wireless interface 1511 utilizes Bluetooth Extended Range Mode for communication with automatic fender units to support communication across larger boats. However, when using extended range mode, mobile devices are typically limited to controlling approximately five boat fender positioning systems due to limitations in mobile device Bluetooth implementations. Bluetooth Extended Range Mode In embodiments where more than five boat fender positioning systems need to be controlled, alternative implementations such as those shown in FIG. 13 or FIG. 14 may be preferred.

[0191] The fender controller application 1512 provides the software logic for controlling automatic fender units based on chartplotter data and user inputs. The fender controller application 1512 may be implemented in various forms depending on the chartplotter system being integrated with. In embodiments compatible with chartplotters that provide limited access to their operating systems, such as Garmin™ chartplotters, the fender controller application 1512 is implemented using HTML5 technology that can be accessed through the chartplotter's web browser interface (provided that the chartplotter allows wireless connections, which Garmins currently do not). In embodiments compatible with chartplotters that allow installation of applications, such as Raymarine™ chartplotters which use an Android-based operating system, the fender controller application 1512 is implemented as an APK (Android application package) that runs on the mobile device and communicates with a corresponding application or interface on the chartplotter.

[0192] The fender controller application 1512 provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. The user interface may be displayed on the mobile device screen, on the chartplotter screen, or on both depending on the implementation and user preferences. In some embodiments, the primary user interface is displayed on the chartplotter screen while the mobile device runs the application in the background, providing a seamless integration where the boat operator controls fenders directly from the chartplotter interface.

[0193] The fender controller application 1512 receives navigational data from the chartplotter including GPS position, speed, heading, depth, tidal information, and map data through the wireless interface 1511, and uses this information to make intelligent fender deployment decisions. For example, the fender controller application 1512 may automatically deploy fenders when the boat enters a geofenced harbor area, automatically adjust fender heights based on tidal information when docked at fixed docks, deploy fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lift fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock.

[0194] These automated functions are improved by the high-quality GPS data and navigational information available from the chartplotter, which is faster and far more accurate than GPS data obtained directly from the mobile device's own GPS receiver. The GPS of a chartplotter can be located down to sub-meter accuracy in less than a second, while GPS of a mobile phone can only be located down to tens-of-meters accuracy within several seconds (but can be more accurate down to a couple of meters after 10 or more seconds). This improved GPS accuracy enables reliable automation features that cannot be implemented using only the mobile device's own GPS.

[0195] Having a better external GPS from the chartplotter provides more reliable functionality and automation that otherwise cannot be implemented with mobile phone GPS alone. For example, the system can automatically lift fenders when the boat accelerates beyond some speed threshold. People often forget to lift fenders when they leave the dock, which is a major problem as deployed fenders create drag and can be damaged at speed. Using only the phone's GPS, the system may not reliably implement automatic lifting because false readings occur, especially on bigger boats that have hard tops and glass surfaces which may interfere with GPS signals. The boat's external GPS from the chartplotter does not suffer from these interference issues, therefore false readings should not occur and the system can provide more reliable automation including fully automatic fender deployment and lifting based on reliable position and speed data.

[0196] The power supply 1513 provides electrical power to the mobile device. In typical embodiments, the power supply 1513 is the rechargeable battery of the mobile device. The mobile device may be charged using standard mobile device charging methods including wired charging via USB or other charging ports, wireless charging where supported, or charging from the boat's electrical system using appropriate adapters.

[0197] One significant advantage of this mobile device-based embodiment is reduced battery drain on the mobile device compared to implementations that rely solely on the mobile device's own GPS. When fender control functions are implemented using only the mobile device's GPS without chartplotter integration, the constant GPS tracking and processing drains the battery of the mobile phone significantly. By receiving GPS data from the chartplotter rather than constantly running the mobile device's own GPS receiver, this embodiment reduces the power consumption on the mobile device, extending its battery life and ensuring that the mobile device remains usable for other purposes.

[0198] However, it should be noted that this embodiment still requires the mobile device to remain powered and running the fender controller application to maintain the connection between the chartplotter and the automatic fender units. If the mobile phone battery is fully drained, the boat owner may not be able to control the automatic boat fender deployment and retrieval system until the mobile device is recharged. For applications where this dependency on mobile device battery life is unacceptable, the embodiments shown in FIG. 13 or FIG. 14 that use dedicated hardware may be preferred.

[0199] The mobile device-based embodiment provides additional benefits specific to its implementation. The use of a mobile device that the boat owner likely already possesses eliminates the need to purchase dedicated hardware, making this the most cost-effective implementation option. The mobile device can be easily carried on and off the boat, allowing the boat owner to use the same device for other purposes when not on the boat. The familiar mobile device interface and application ecosystem makes the system easy to use and update, as updates to the fender controller application 1512 can be delivered through standard mobile application update mechanisms.

[0200] The portability of the mobile device also provides flexibility in how the system is used. The boat owner can choose to mount the mobile device in a fixed location for easy access during docking operations, or can carry it freely and control fenders from any location on the boat where wireless connectivity to the chartplotter and automatic fender units is maintained. This flexibility is particularly valuable on larger boats where the captain may want to control fenders from different vantage points depending on the docking situation.

[0201] The architecture shown in FIG. 15 is particularly well-suited for integration with chartplotter systems that support Bluetooth connectivity and allow installation of applications, such as Raymarine™ chartplotters. The Raymarine™ chartplotter has Bluetooth connectivity, so the automatic fender controller can connect via Bluetooth through the wireless interface 1511 without requiring any ethernet cables or adapters. The Raymarine™ operating system is a version of Android, allowing the fender controller application 1512 to be implemented as an APK (Android application package) that can be installed as a plug-in to the Raymarine™ system.

[0202] In the Raymarine™-type implementation, the APK installed on the mobile device communicates with the Raymarine™ chartplotter via Bluetooth, exchanging navigational data from the chartplotter to the mobile device and control interface data from the mobile device to the chartplotter display. The mobile device also maintains Bluetooth connections with the automatic fender units, sending deployment and retrieval commands and receiving status updates. The fender controller application 1512 running on the mobile device serves as the intermediary, processing chartplotter data to make intelligent fender control decisions and managing the communication with all automatic fender units.

[0203] The system architecture 1500 supports efficient communication flows. Navigational data including GPS position, speed, heading, depth, tidal information, and map data flows wirelessly from the chartplotter through the wireless interface 1511 to the fender controller application 1512. The fender controller application 1512 processes this data according to configured rules and user inputs to generate control commands for the automatic fender units. These control commands are transmitted wirelessly through the wireless interface 1511 to the appropriate automatic fender units.

[0204] Status data flows in the reverse direction, with automatic fender units sending status updates including battery levels, fender positions, and operational states wirelessly through the wireless interface 1511 to the fender controller application 1512. The fender controller application 1512 aggregates this status information and can display it on the mobile device screen and can transmit it wirelessly through the wireless interface 1511 to the chartplotter for display on the chartplotter screen, providing the boat operator with real-time visibility into the state of all automatic fender units from either the mobile device or the central chartplotter display in the cockpit.

[0205] One consideration in this embodiment is the management of multiple simultaneous Bluetooth connections on the mobile device. The wireless interface 1511 must maintain a connection to the chartplotter while simultaneously maintaining connections to multiple automatic fender units. Modern mobile devices generally support multiple simultaneous Bluetooth connections, but the practical limit depends on the specific mobile device hardware and Bluetooth implementation. As noted earlier, when using Bluetooth in extended range mode (coded phy) to support larger boats, mobile devices are typically limited to controlling approximately 5 boat fender positioning systems. For boats requiring control of more fenders, the dedicated hardware implementations of FIG. 13 or FIG. 14 may be necessary.

[0206] The mobile device-based implementation also provides opportunities for enhanced functionality through integration with other mobile device capabilities. For example, the fender controller application 1512 could utilize the mobile device's camera to provide visual documentation of docking operations, use the mobile device's accelerometer and gyroscope to detect boat motion and orientation, or integrate with other marine applications installed on the mobile device to provide a comprehensive boat management solution.

[0207] The flexibility of the mobile device platform also allows for rapid development and deployment of new features and improvements. The fender controller application 1512 can be updated through standard mobile application update mechanisms without requiring any hardware changes or firmware updates to installed equipment. This enables continuous improvement of the fender control system based on user feedback and evolving requirements.

[0208] FIG. 16 is a block diagram illustrating an exemplary integration of automatic boat fender controller with a Garmin™ chartplotter 1600. This embodiment demonstrates a specific implementation for integration with Garmin™ chartplotters, which provide limited access to their operating systems through HTML5 interfaces. Because Garmin™ chartplotters do not have native Bluetooth connectivity, this implementation requires an ethernet connection between the chartplotter and either an external ethernet adapter or an automatic fender controller with integrated ethernet adapter functionality.

[0209] The exemplary integration 1600 shows integration of an automatic fender controller (AFC) 1620 with a Garmin™ chartplotter 1610. The AFC of this embodiment comprises an automatic fender controller (AFC) 1620 and an ethernet adapter 1630, and. This configuration represents the architecture described in FIG. 13 as applied specifically to Garmin™ chartplotter systems. The ethernet adapter 1630 serves as a necessary bridge between the Garmin™ chartplotter 1610 and the automatic fender units, providing the wireless communication capability that the Garmin™ chartplotter lacks.

[0210] The Garmin™ chartplotter 1610 comprises a display 1611, a GPS module 1612, an HTML5 interface 1613, and an ethernet interface 1614. The Garmin™ chartplotter 1610 is a commercially available marine navigation device manufactured by Garmin™ that provides GPS navigation, charting, and various marine navigation functions.

[0211] The display 1611 provides visual output to the boat operator, showing charts, navigation data, and user interface controls. In this embodiment, the display 1611 is used to show the fender controller user interface when the boat operator accesses the fender control functions through the chartplotter. The display 1611 allows the boat operator to control fenders from the central location in the cockpit where the Garmin™ chartplotter 1610 is typically mounted, eliminating the need to access a separate mobile device or control panel for fender operations.

[0212] The GPS module 1612 provides high-accuracy position data for the Garmin™ chartplotter 1610. The GPS module 1612 in chartplotters is significantly more capable than the GPS receivers in mobile phones. The GPS of a chartplotter can be located down to sub-meter accuracy in less than a second, while GPS of a mobile phone can only be located down to tens-of-meters accuracy within several seconds (but can be more accurate down to a couple of meters after 10 or more seconds). This superior GPS accuracy is one of the key advantages of integrating the automatic fender controller with the chartplotter system, enabling reliable automation features that cannot be implemented with mobile phone GPS alone.

[0213] Having a better external GPS from the chartplotter provides more reliable functionality and automation that otherwise cannot be implemented with mobile phone GPS. For example, the system can automatically lift fenders when the boat accelerates beyond some speed threshold. People often forget to lift fenders when they leave the dock, which is a major problem as deployed fenders create drag and can be damaged at speed. Using a phone GPS, the system cannot reliably implement automatic lifting because false readings occur, especially on bigger boats that have hard tops and glass all over which interfere with GPS signals. The boat's external GPS from the chartplotter does not suffer from these interference issues, therefore false readings should not occur and the system can implement the next level of automation including fully automatic fender deployment and lifting based on reliable position and speed data.

[0214] The HTML5 interface 1613 provides the mechanism through which external applications can interact with the Garmin™ chartplotter 1610. Garmin™ provides HTML5 access to its chartplotter devices, allowing applications to be accessed through the chartplotter's web browser interface. This is the primary method for third-party applications to integrate with Garmin™ chartplotters, as Garmin™ provides less access to its devices compared to systems like Raymarine™ that allow full application installation. The HTML5 interface 1613 allows the fender controller application to display its user interface on the display 1611 and to exchange data with the chartplotter.

[0215] The ethernet interface 1614 provides wired network connectivity for the Garmin™ chartplotter 1610. The ethernet interface 1614 enables the Garmin™ chartplotter 1610 to communicate with the ethernet adapter 1630 via an ethernet cable connection. Through this connection, the Garmin™ chartplotter 1610 can transmit GPS data, tidal information, navigational data, compass and boat direction information, GPS map information, and other chartplotter data to the ethernet adapter 1630, and can receive status updates and control interface data from the fender controller application.

[0216] The ethernet adapter 1630 comprises a wireless interface 1631, a power supply 1632, and an ethernet interface 1633. The ethernet adapter 1630 serves as the bridge between the Garmin™ chartplotter 1610 and the automatic fender units, providing the wireless communication capability that the Garmin™ chartplotter lacks. This component is necessary in Garmin™ implementations because the Garmin™ chartplotter does not have Bluetooth connectivity, so connection to the chartplotter must be made using an ethernet cable.

[0217] The wireless interface 1631 of the ethernet adapter 1630 provides data communication to and from automatic fender units installed on the boat. The wireless interface 1631 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols. In some embodiments, the wireless interface 1631 utilizes Bluetooth Low Energy with extended range mode (coded phy) to support communication with multiple automatic fender units across larger boats.

[0218] The power supply 1632 provides electrical power to the ethernet adapter 1630. In some embodiments, the power supply 1632 receives power from an external source such as the boat's electrical system. In other embodiments, the power supply 1632 may receive power via Power over Ethernet (PoE) through the ethernet interface 1633 if the Garmin™ chartplotter or network switch supports PoE. The ability to receive power via Power over Ethernet is particularly advantageous as it eliminates the need for separate power connections when the Garmin™ chartplotter or associated network infrastructure provides PoE capability.

[0219] The ethernet interface 1633 provides data synchronization with the Garmin™ chartplotter 1610 via an ethernet cable connection. The ethernet interface 1633 enables bidirectional communication between the ethernet adapter 1630 and the Garmin™ chartplotter 1610, allowing the ethernet adapter 1630 to receive GPS data, tidal information, compass and boat direction information, GPS map information, and other navigational data from the Garmin™ chartplotter 1610. The ethernet interface 1633 also allows the ethernet adapter 1630 to send status updates and receive control commands for display on the chartplotter screen through the HTML5 interface 1613.

[0220] The automatic fender controller (AFC) 1620 comprises a wireless interface 1621, a fender controller application 1622, a power supply 1623, and an optional ethernet interface 1624. The automatic fender controller (AFC) 1620 may be implemented as a smartphone, tablet, or other mobile device, or may be integrated directly into the ethernet adapter 1630 as described in the embodiment of FIG. 14.

[0221] The wireless interface 1621 of the automatic fender controller (AFC) 1620 provides data communication to and from the chartplotter. In embodiments where the automatic fender controller (AFC) 1620 is implemented as a separate mobile device, the wireless interface 1621 communicates with the ethernet adapter 1630, which in turn communicates with the Garmin™ chartplotter 1610 via the ethernet interface 1633. The wireless interface 1621 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols.

[0222] The fender controller application 1622 provides the software logic for controlling automatic fender units based on chartplotter data and user inputs. For integration with Garmin™ chartplotters, the fender controller application 1622 is implemented using HTML5 technology. The HTML5 application can be accessed through the Garmin™ chartplotter's web browser interface via the HTML5 interface 1613, allowing the user interface to be displayed on the display 1611 of the Garmin™ chartplotter 1610.

[0223] The fender controller application 1622 provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. The fender controller application 1622 receives navigational data from the Garmin™ chartplotter 1610 including GPS position from the GPS module 1612, speed, heading, depth, tidal information, and map data, and uses this information to make intelligent fender deployment decisions.

[0224] For example, the fender controller application 1622 may automatically deploy fenders when the boat enters a geofenced harbor area, automatically adjust fender heights based on tidal information when docked at fixed docks, deploy fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lift fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock. These automated functions are made possible by the high-quality GPS data from the GPS module 1612 and navigational information available from the Garmin™ chartplotter 1610.

[0225] The power supply 1623 provides electrical power to the automatic fender controller (AFC) 1620. In embodiments where the automatic fender controller (AFC) 1620 is implemented as a mobile device such as a smartphone or tablet, the power supply 1623 is the battery of the mobile device. In embodiments where the automatic fender controller (AFC) 1620 is integrated into the ethernet adapter 1630, the power supply 1623 may be the same as the power supply 1632 of the ethernet adapter 1630. Optionally, the power supply 1623 may receive power via Power over Ethernet through the ethernet interface 1624 when available.

[0226] The optional ethernet interface 1624 provides an alternative or supplementary connection option for the automatic fender controller (AFC) 1620. In some embodiments, the automatic fender controller (AFC) 1620 may connect directly to the Garmin™ chartplotter 1610 or to the ethernet adapter 1630 via the ethernet interface 1624 instead of or in addition to using the wireless interface 1621. The ethernet interface 1624 may also support Power over Ethernet to charge or power the automatic fender controller (AFC) 1620 when it is a mobile device.

[0227] This Garmin™-specific implementation provides all of the advantages discussed in earlier embodiments for chartplotter integration. First, it allows deployment of fenders from a central location on the boat, specifically the cockpit where the captain operates all other boat systems including the Garmin™ chartplotter 1610, eliminating the need for crew to move around the boat to deploy fenders manually. The fender controller user interface is accessible directly through the display 1611 of the Garmin™ chartplotter 1610 via the HTML5 interface 1613, providing seamless integration with the chartplotter's existing interface.

[0228] Second, it allows the automatic fender controller to use the GPS module 1612 of the Garmin™ chartplotter 1610, which is faster and far more accurate than the GPS of a mobile phone. Third, this embodiment saves battery life on mobile phones versus mobile phone-only implementations by offloading GPS tracking and processing to the Garmin™ chartplotter 1610. Furthermore, if the mobile phone battery is fully drained, the boat owner can still control the automatic boat fender deployment and retrieval system as long as the Garmin™ chartplotter 1610 and ethernet adapter 1630 remain powered, especially in embodiments where the automatic fender controller functionality is integrated into the ethernet adapter.

[0229] Fourth, this embodiment allows access, if needed, to other functions of the Garmin™ chartplotter 1610 for integration into fender deployment decisions. For example, tidal information from the chartplotter allows for adjustment of fender heights at fixed docks, although most docks are floating docks so this is not necessary for floating docks. GPS map information from the chartplotter shows the location of the boat relative to nearby docks, enabling intelligent decisions about when to deploy fenders based on proximity to docking areas. Compass and other boat direction information from the chartplotter allows for deployment of boat fenders on the side of the boat on which the dock is located, ensuring fenders are positioned correctly for the approach angle.

[0230] Fifth, this embodiment enables control of more fenders than mobile device implementations. With the ethernet adapter 1630 integrated with the Garmin™ chartplotter 1610 system, a large number of boat fender positioning systems (e.g., 6 or more) can be controlled by a single system, which is essential for larger boats that require more fenders. This is a significant improvement over mobile device-only implementations where only approximately 5 boat fender positioning systems can be controlled from a single mobile device when using Bluetooth in extended range mode (coded phy) due to limitations in mobile device Bluetooth implementations.

[0231] Sixth, having the better external GPS from the GPS module 1612 of the Garmin™ chartplotter 1610 provides more reliable functionality and automation that otherwise cannot be implemented with mobile phone GPS. The boat's external GPS from the chartplotter does not suffer from interference issues common with mobile phone GPS, therefore false readings should not occur and the system can implement the next level of automation including fully automatic fender deployment and lifting based on reliable position and speed data.

[0232] The communication flow in this Garmin™-specific implementation follows a defined path. GPS data from the GPS module 1612 and other navigational data from the Garmin™ chartplotter 1610 flows through the ethernet interface 1614 via ethernet cable to the ethernet interface 1633 of the ethernet adapter 1630. This data is then synchronized with the fender controller application 1622 either through wireless communication via the wireless interface 1621 when the automatic fender controller (AFC) 1620 is a separate device, or directly when the automatic fender controller functionality is integrated into the ethernet adapter 1630.

[0233] The fender controller application 1622 processes the chartplotter data and generates control commands for the automatic fender units. These commands are transmitted through the wireless interface 1631 of the ethernet adapter 1630 to the automatic fender units. Status data flows in the reverse direction, with automatic fender units sending status updates through the wireless interface 1631 to the ethernet adapter 1630, which forwards this information to the fender controller application 1622. The fender controller application 1622 can then display this status information on the display 1611 of the Garmin™ chartplotter 1610 via the HTML5 interface 1613, providing the boat operator with real-time visibility into the state of all automatic fender units from the central control location in the cockpit.

[0234] The HTML5 implementation of the fender controller application 1622 is specifically designed to work within the constraints of the Garmin™ chartplotter's HTML5 interface 1613. Because Garmin™ provides less access to its devices compared to systems like Raymarine™, the application must work within the HTML5 framework provided by Garmin™. The HTML5 application communicates with the ethernet adapter 1630 via network protocols to send commands to the automatic fender units and receive status updates. The HTML5 interface allows for a rich, interactive user experience on the display 1611 while maintaining compatibility with the Garmin™ chartplotter's operating system.

[0235] Installation of this Garmin™-specific implementation is straightforward. The ethernet adapter 1630 is connected to the Garmin™ chartplotter 1610 via an ethernet cable between the ethernet interface 1614 and the ethernet interface 1633. The ethernet adapter 1630 is powered either through a connection to the boat's electrical system via the power supply 1632, or via Power over Ethernet if supported. The automatic fender units are paired with the ethernet adapter 1630 through standard Bluetooth pairing procedures. Once installed and configured, the boat operator can access the fender controller user interface through the Garmin™ chartplotter's HTML5 interface 1613 and control all automatic fender operations from the display 1611 of the Garmin™ chartplotter 1610.

[0236] In embodiments where the automatic fender controller (AFC) 1620 is integrated directly into the ethernet adapter 1630 as described in FIG. 14, the system becomes even more streamlined. The integrated device combines all necessary functionality in a single unit that connects to the Garmin™ chartplotter 1610 via ethernet and communicates wirelessly with the automatic fender units. This integration eliminates the need for the separate automatic fender controller (AFC) 1620 device and the wireless connection between the ethernet adapter 1630 and the automatic fender controller (AFC) 1620, reducing the total number of devices and potential points of failure.

[0237] The Garmin™-specific implementation demonstrates how the general architecture of chartplotter-integrated automatic fender control can be adapted to work with specific chartplotter systems that have particular interface requirements and capabilities. By using HTML5 technology and ethernet connectivity, the system works within the constraints of the Garmin™ platform while still providing all of the advantages of chartplotter integration including centralized control, superior GPS accuracy, reduced mobile device battery drain, access to chartplotter functions for intelligent automation, support for larger numbers of fenders, and reliable automation based on high-quality external GPS data.

[0238] FIG. 17 is a block diagram illustrating an exemplary integration of automatic boat fender controller with a Raymarine™ chartplotter 1700. This embodiment demonstrates a specific implementation for integration with Raymarine™ chartplotters, which use an Android-based operating system that allows more control over the chartplotter and its functions compared to systems like Garmin™. Because Raymarine™ chartplotters have Bluetooth connectivity and allow installation of applications, this implementation provides multiple connection options including both wireless and ethernet connectivity, offering greater flexibility than Garmin™-based implementations.

[0239] The exemplary integration 1700 shows integration of an automatic fender controller (AFC) 1710 with a Raymarine™ chartplotter 1720. This configuration can be implemented using the architectures described in FIG. 13, FIG. 14, or FIG. 15 as applied specifically to Raymarine™ chartplotter systems. The availability of Bluetooth connectivity on the Raymarine™ chartplotter 1720 enables wireless communication options that are not available with Garmin™ chartplotters, providing additional flexibility in system configuration and installation.

[0240] The Raymarine™ chartplotter 1720 comprises a wireless interface 1721, an Android OS 1722, a fender control application (APK) 1723, a display 1724, a GPS module 1725, and an ethernet interface 1726. The Raymarine™ chartplotter 1720 is a commercially available marine navigation device manufactured by Raymarine™ that provides GPS navigation, charting, and various marine navigation functions.

[0241] The wireless interface 1721 provides wireless communication capability for the Raymarine™ chartplotter 1720. The wireless interface 1721 may utilize any suitable wireless communication protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BLE), WiFi, or other wireless protocols. The availability of the wireless interface 1721 is a key differentiator of Raymarine™ chartplotters compared to Garmin™ chartplotters. The Raymarine™ chartplotter has Bluetooth connectivity, so the automatic fender controller can be connected via Bluetooth without requiring ethernet cables or adapters in some embodiments.

[0242] The wireless interface 1721 enables the Raymarine™ chartplotter 1720 to communicate wirelessly with the automatic fender controller (AFC) 1710 when the automatic fender controller (AFC) 1710 is implemented as a mobile device as described in FIG. 15. This wireless communication capability eliminates the need for ethernet connections in mobile device-based implementations, simplifying installation and providing greater portability. The wireless interface 1721 can transmit GPS data, tidal information, navigational data, compass and boat direction information, GPS map information, and other chartplotter data to the automatic fender controller (AFC) 1710, and can receive status updates and control commands for display on the display 1724.

[0243] The Android OS 1722 provides the operating system for the Raymarine™ chartplotter 1720. The Raymarine™ operating system is basically running Android, which provides significant advantages for application integration compared to systems like Garmin™ that provide only limited HTML5 access. The Android OS 1722 allows for installation of full Android applications (APKs) that have deeper integration with the chartplotter's functions and can provide richer user experiences than HTML5-based applications.

[0244] The fender control application (APK) 1723 is an Android application package that can be installed directly on the Raymarine™ chartplotter 1720. The APK is software that interfaces with the Raymarine™ system. The Raymarine™ operating system is Android-based, so the APK is a plug-in to the Raymarine™ system. The fender control application (APK) 1723 provides user interface controls that are displayed on the display 1724 and integrates with the Android OS 1722 to access GPS data from the GPS module 1725 and other chartplotter functions.

[0245] The fender control application (APK) 1723 communicates with the automatic fender controller (AFC) 1710 to coordinate fender control operations. The application can send control commands received through the user interface on the display 1724 and can receive status updates from automatic fender units for display to the boat operator. The fender control application (APK) 1723 can also implement intelligent automation logic using GPS data from the GPS module 1725 and other navigational data available through the Android OS 1722.

[0246] The display 1724 provides visual output to the boat operator, showing charts, navigation data, and user interface controls. In this embodiment, the display 1724 is used to show the fender controller user interface provided by the fender control application (APK) 1723 when the boat operator accesses the fender control functions through the chartplotter. The display 1724 allows the boat operator to control fenders from the central location in the cockpit where the Raymarine™ chartplotter 1720 is typically mounted, eliminating the need to access a separate mobile device or control panel for fender operations.

[0247] The GPS module 1725 provides high-accuracy position data for the Raymarine™ chartplotter 1720. The GPS module 1725 in chartplotters is significantly more capable than the GPS receivers in mobile phones. The GPS of a chartplotter can be located down to sub-meter accuracy in less than a second, while GPS of a mobile phone can only be located down to tens-of-meters accuracy within several seconds (but can be more accurate down to a couple of meters after 10 or more seconds). This superior GPS accuracy is one of the key advantages of integrating the automatic fender controller with the chartplotter system, enabling reliable automation features that cannot be implemented with mobile phone GPS alone.

[0248] Having a better external GPS from the chartplotter provides more reliable functionality and automation that otherwise cannot be implemented with mobile phone GPS. For example, the system can automatically lift fenders when the boat accelerates beyond some speed threshold. Boaters often forget to lift fenders when they leave the dock, which is a major problem as deployed fenders create drag and can cause damage at high boat speeds. Using a phone GPS, the system may be not able to reliably implement automatic lifting because false readings occur, especially on bigger boats that have hard tops and glass surfaces which may interfere with GPS signals. The boat's external GPS from the chartplotter does not suffer from these interference issues, therefore false readings should not occur and the system can implement reliable fully automatic fender deployment and lifting based on reliable position and speed data.

[0249] The ethernet interface 1726 provides wired network connectivity for the Raymarine™ chartplotter 1720. While the wireless interface 1721 provides the primary wireless communication capability, the ethernet interface 1726 offers an alternative connection method that may be preferred in some installations. The ethernet interface 1726 enables the Raymarine™ chartplotter 1720 to communicate with the ethernet adapter 1710 via an ethernet cable connection when such a configuration is desired.

[0250] It might be preferable to connect to the Raymarine™ chartplotter via ethernet anyway, so that power to the automatic fender controller can be provided via the ethernet cable where power-via-ethernet is available. Through the ethernet connection, the Raymarine™ chartplotter 1720 can transmit GPS data, tidal information, navigational data, compass and boat direction information, GPS map information, and other chartplotter data to the ethernet adapter 1710, and can receive status updates and control interface data from the fender controller application.

[0251] The automatic fender controller (AFC) 1710 comprises a wireless interface 1711, a fender controller application 1712, a power supply 1713, and an optional ethernet interface 1714. The automatic fender controller (AFC) 1710 may be implemented as a smartphone, tablet, or other mobile device, or may be integrated directly into the ethernet adapter 1710 as described in the embodiment of FIG. 14. In Raymarine™ implementations, the automatic fender controller (AFC) 1710 can communicate with the Raymarine™ chartplotter 1720 either wirelessly via the wireless interface 1721 or via ethernet, providing flexibility in system configuration.

[0252] The wireless interface 1711 of the automatic fender controller (AFC) 1710 provides data communication to and from the chartplotter and potentially to and from automatic fender units. In embodiments where the automatic fender controller (AFC) 1710 is implemented as a separate mobile device, the wireless interface 1711 can communicate directly with the Raymarine™ chartplotter 1720 via the wireless interface 1721, eliminating the need for the ethernet adapter 1710. Alternatively, the wireless interface 1711 can communicate with the ethernet adapter 1710, which in turn communicates with the Raymarine™ chartplotter 1720 via ethernet.

[0253] The fender controller application 1712 provides the software logic for controlling automatic fender units based on chartplotter data and user inputs. For integration with Raymarine™ chartplotters, the fender controller application 1712 can be implemented in various forms. In some embodiments, it is implemented as an HTML5 application similar to the Garmin™ implementation. In other embodiments, it is implemented as an APK (Android application package) that can run on a mobile device and communicate with the fender control application (APK) 1723 installed on the Raymarine™ chartplotter 1720.

[0254] The fender controller application 1712 provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. The fender controller application 1712 receives navigational data from the Raymarine™ chartplotter 1720 including GPS position from the GPS module 1725, speed, heading, depth, tidal information, and map data, and uses this information to make intelligent fender deployment decisions.

[0255] For example, the fender controller application 1712 may automatically deploy fenders when the boat enters a geofenced harbor area, automatically adjust fender heights based on tidal information when docked at fixed docks, deploy fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lift fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock. These automated functions are made possible by the high-quality GPS data from the GPS module 1725 and navigational information available from the Raymarine™ chartplotter 1720.

[0256] The power supply 1713 provides electrical power to the automatic fender controller (AFC) 1710. In embodiments where the automatic fender controller (AFC) 1710 is implemented as a mobile device such as a smartphone or tablet, the power supply 1713 is the battery of the mobile device. Optionally, the power supply 1713 may receive power via Power over Ethernet through the ethernet interface 1714 when available.

[0257] The optional ethernet interface 1714 provides an alternative or supplementary connection option for the automatic fender controller (AFC) 1710. In some embodiments, the automatic fender controller (AFC) 1710 may connect directly to the Raymarine™ chartplotter 1720 or to the ethernet adapter 1710 via the ethernet interface 1714 instead of or in addition to using the wireless interface 1711. The ethernet interface 1714 may also support Power over Ethernet to charge or power the automatic fender controller (AFC) 1710 when it is a mobile device.

[0258] The Raymarine™ implementation offers additional advantages beyond those available in Garmin™ implementations due to the more open nature of the Raymarine™ platform. The Android OS 1722 allows for deeper integration with the chartplotter's functions compared to the HTML5-only access provided by Garmin™. The fender control application (APK) 1723 installed on the Raymarine™ chartplotter 1720 can access system-level functions, provide richer user interfaces, and integrate more seamlessly with the chartplotter's existing applications and features.

[0259] The availability of the wireless interface 1721 on the Raymarine™ chartplotter 1720 provides significant installation flexibility. In the simplest configuration, a mobile device running the fender controller application 1712 can communicate wirelessly with both the Raymarine™ chartplotter 1720 via the wireless interface 1721 and with the automatic fender units, eliminating the need for any ethernet adapter or cables. This provides a completely wireless solution that is easy to install and requires no permanent modifications to the boat.

[0260] Alternatively, for installations where ethernet connectivity is preferred to provide Power over Ethernet or to ensure more reliable communication, the ethernet interface 1714 of the AFC can be connected to the Raymarine™ chartplotter 1720 via the ethernet interface 1726. In this configuration, the ethernet interface 1714 of the AFC serves as a bridge between the chartplotter and the automatic fender units, similar to the Garmin™ implementation but with the added benefit that wireless connectivity is also available as a fallback or alternative.

[0261] The communication flow in this Raymarine™-specific implementation can follow multiple paths depending on the configuration chosen. In a fully wireless configuration, GPS data from the GPS module 1725 and other navigational data from the Raymarine™ chartplotter 1720 flows wirelessly through the wireless interface 1721 to the wireless interface 1711 of the automatic fender controller (AFC) 1710. The fender controller application 1712 processes this data and generates control commands that are transmitted wirelessly to the automatic fender units.

[0262] In an ethernet-based configuration, GPS data from the GPS module 1725 and other navigational data flows through the ethernet interface 1726 via ethernet cable to the ethernet interface 1714 of the AFC. This data is then forwarded to the fender controller application 1712 either wirelessly via the wireless interface 1711 or via ethernet through the optional ethernet interface 1714. Control commands are transmitted from the AFC through the wireless interface 1711 to the automatic fender units which deploy / retrieve each fender.

[0263] Status data flows in the reverse direction in both configurations. Automatic fender units send status updates including battery levels, fender positions, and operational states wirelessly. In the fully wireless configuration, these updates are received by the automatic fender controller (AFC) 1710 and forwarded to the Raymarine™ chartplotter 1720 for display via the fender control application (APK) 1723 on the display 1724. In the ethernet-based configuration, status updates are received by the ethernet adapter 1710 and forwarded through the ethernet interface to the Raymarine™ chartplotter 1720.

[0264] The APK implementation provides advantages for user experience. Because the fender control application (APK) 1723 runs directly on the Android OS 1722 of the Raymarine™ chartplotter 1720, it can provide native Android user interface elements, smooth animations, and responsive touch interactions on the display 1724. The application can also integrate with other Raymarine™ applications and features, such as displaying fender status overlays on navigation charts or triggering fender deployment based on Raymarine™'s own docking assistance features.

[0265] Installation of this Raymarine™-specific implementation offers multiple options. For the simplest installation, a boat owner can install the fender control application (APK) 1723 on the Raymarine™ chartplotter 1720 and install the fender controller application 1712 on a mobile device. The mobile device pairs wirelessly with both the Raymarine™ chartplotter 1720 and the automatic fender units, creating a fully wireless system with no permanent installations required.

[0266] For a more permanent installation, the ethernet adapter 1710 can be connected to the Raymarine™ chartplotter 1720 via an ethernet cable, powered either through the boat's electrical system or via Power over Ethernet. The ethernet adapter 1710 is paired with the automatic fender units, and the fender control application (APK) 1723 on the Raymarine™ chartplotter 1720 communicates with the ethernet adapter to coordinate fender operations. This configuration provides the reliability of wired connectivity between the chartplotter and ethernet adapter while maintaining wireless communication with the fenders.

[0267] The Raymarine™-specific implementation demonstrates how the general architecture of chartplotter-integrated automatic fender control can be adapted to take advantage of the specific capabilities and features of different chartplotter systems. By leveraging the Android OS 1722, Bluetooth connectivity via the wireless interface 1721, and APK application support, the Raymarine™ implementation provides all of the advantages of chartplotter integration including centralized control, superior GPS accuracy, reduced mobile device battery drain, access to chartplotter functions for intelligent automation, support for larger numbers of fenders, and reliable automation based on high-quality external GPS data, while also offering greater installation flexibility and deeper system integration than is possible with more restrictive platforms like Garmin™.

[0268] FIG. 18 is an exemplary messaging diagram for integration of automatic boat fender controller with chartplotter 1800. This embodiment illustrates the sequence and flow of communications between a chartplotter, an automatic fender controller, and boat fender positioning systems during the initialization, operation, and status monitoring phases of the integrated system. The messaging diagram demonstrates how the various components described in earlier embodiments communicate with each other to provide seamless integration of fender control functionality with the chartplotter display and user interface.

[0269] The exemplary messaging diagram 1800 shows communications between a chartplotter 1810, an automatic fender controller 1820, and a boat fender positioning system 1830. The diagram shows the messages exchanged between them to establish communication, request and deliver user interface elements, process user commands, control fender units, and provide status updates. The messaging sequence illustrated demonstrates a typical interaction flow from system startup through user-initiated fender control operations.

[0270] The chartplotter 1810 represents the marine navigation device that serves as the central display and control interface for the boat operator. The chartplotter 1810 may be a Garmin chartplotter accessed via HTML5 interfaces through an ethernet connection, a Raymarine chartplotter accessed via Android application packages with Bluetooth or ethernet connectivity, or any other suitable marine chartplotter capable of displaying custom applications and communicating with external devices. The chartplotter 1810 provides the display on which the fender control user interface is presented to the boat operator, and serves as the primary input device through which the operator issues fender control commands.

[0271] The automatic fender controller 1820 represents the control logic and communication interface that coordinates between the chartplotter 1810 and the boat fender positioning systems 1830. The automatic fender controller 1820 may be implemented as a separate mobile device running a fender controller application, as functionality integrated into an ethernet adapter, or as an application running directly on the chartplotter in the case of Raymarine systems with Android operating systems. The automatic fender controller 1820 maintains communication with both the chartplotter 1810 and the boat fender positioning systems 1830, translating user interface interactions on the chartplotter into control commands for the fender units and translating status information from the fender units into display updates for the chartplotter.

[0272] The boat fender positioning system 1830 represents one or more automatic fender units installed on the boat. Each boat fender positioning system 1830 comprises a power unit with a motor, spool, microcontroller, solar panel, battery, and wireless communication interface as described in the parent application and the enhanced low-power standby embodiments of the present application. The boat fender positioning systems 1830 receive control commands to deploy or stow fenders, execute those commands by operating motors to wind or unwind line, monitor their operational status including battery levels and fender positions, and transmit status updates back to the automatic fender controller 1820. A typical boat installation may include multiple boat fender positioning systems 1830, such as port forward, port aft, starboard forward, and starboard aft units, all of which communicate with the automatic fender controller 1820.

[0273] The messaging sequence begins with step 1810 in which the automatic fender controller 1820 establishes bi-directional communication with all boat fender positioning systems 1830. This initialization step occurs when the automatic fender controller 1820 starts up or when the system is activated. The automatic fender controller 1820 uses wireless communication protocols such as Bluetooth or Bluetooth Low Energy to discover and connect to all boat fender positioning systems 1830 that have been previously paired with the system. In embodiments using Bluetooth Low Energy with extended range mode, the automatic fender controller 1820 may establish connections with fender units located throughout the boat, even on larger vessels where distances can exceed standard Bluetooth range.

[0274] The establishment of bi-directional communication in step 1810 ensures that the automatic fender controller 1820 can both send control commands to the boat fender positioning systems 1830 and receive status updates from them. This bi-directional capability is essential for the integrated system to provide real-time feedback to the boat operator through the chartplotter display. The automatic fender controller 1820 may query each boat fender positioning system 1830 for its current status including battery level, fender position, and operational state, and may store this information for subsequent display on the chartplotter 1810. The use of the enhanced low-power standby mode disclosed in this application ensures that boat fender positioning systems 1830 remain responsive to connection requests even after long periods of storage, as the Bluetooth module and wake-up module maintain power during standby.

[0275] After the automatic fender controller 1820 has established communication with the boat fender positioning systems 1830, the messaging sequence proceeds to step 1820 in which the chartplotter 1810 requests a user interface app from the automatic fender controller 1820. This request occurs when the boat operator navigates to the fender control function on the chartplotter, such as by selecting a FENDERS tab from the selection tabs on the chartplotter display. The request for the user interface app may be implemented differently depending on the chartplotter platform. For Garmin chartplotters that use HTML5 interfaces, the request may be an HTTP GET request to retrieve HTML, CSS, and JavaScript files that define the user interface. For Raymarine chartplotters that use Android application packages, the request may be a launch command to start an installed APK application.

[0276] In response to the request in step 1820, the automatic fender controller 1820 proceeds to step 1830 in which it provides code and design elements to the chartplotter 1810. The code and design elements constitute the user interface application that will be displayed on the chartplotter to enable fender control. For HTML5 implementations on Garmin chartplotters, the code and design elements include HTML markup defining the structure of the user interface, CSS stylesheets defining the visual appearance, and JavaScript code implementing the interactive behavior and communication with the automatic fender controller 1820. For Android implementations on Raymarine chartplotters, the code and design elements may include Android UI components, layouts, and activity definitions that integrate with the Raymarine operating system.

[0277] The code and design elements provided in step 1830 implement the user interface features illustrated in FIG. 19, including selection tabs for navigation between different chartplotter functions, a chart view showing the boat's position, a data view displaying navigational and fender status information, a boat orientation display showing fender locations and deployment status, controls for deploying port side fenders, controls for deploying starboard side fenders, controls for stowing all fenders, an auto mode indicator, and a settings control. The design elements ensure that the fender control interface maintains visual consistency with the existing chartplotter user interface, providing a seamless integrated experience for the boat operator.

[0278] After receiving the code and design elements in step 1830, the chartplotter 1810 proceeds to step 1840 in which it starts the app and establishes a connection to the automatic fender controller 1820. Starting the app involves rendering the HTML user interface in the case of Garmin chartplotters or launching the Android application in the case of Raymarine chartplotters. Establishing the connection to the automatic fender controller 1820 involves setting up a communication channel through which user interface events can be transmitted to the controller and through which status updates can be received from the controller. This connection may use HTTP requests for HTML5 implementations, WebSocket connections for real-time bidirectional communication, or Android inter-process communication mechanisms for native Android implementations.

[0279] The establishment of the connection in step 1840 completes the initialization of the integrated fender control system. At this point, the chartplotter 1810 is displaying the fender control user interface, the automatic fender controller 1820 is connected to both the chartplotter 1810 and the boat fender positioning systems 1830, and the system is ready to respond to user actions. The boat operator can now see the current status of all fenders displayed on the chartplotter, including which fenders are deployed, which are stowed, the battery levels of each fender unit, and other status information. The operator can also access the various controls provided by the user interface to manually deploy or stow fenders or to configure automatic deployment settings.

[0280] When the boat operator interacts with the user interface displayed on the chartplotter 1810, such as by touching a deploy port side control or a stow all fenders control, the messaging sequence proceeds to step 1850 in which the chartplotter 1810 sends a command to the automatic fender controller 1820 based on the user action. The command transmitted in step 1850 encodes the operator's intent, such as deploy all port side fenders, deploy all starboard side fenders, stow all fenders, deploy a specific individual fender, or change a configuration setting. The command may also include parameters such as the desired deployment height for fenders or the speed threshold for automatic stowing.

[0281] Upon receiving the command from the chartplotter 1810 in step 1850, the automatic fender controller 1820 processes the command and determines which boat fender positioning systems 1830 need to be controlled to execute the operator's intent. For example, if the operator selected deploy port side, the automatic fender controller 1820 identifies the port forward and port aft fender units. The automatic fender controller 1820 then proceeds to step 1860 in which it sends commands to the appropriate boat fender positioning systems 1830.

[0282] The commands sent to the boat fender positioning systems 1830 in step 1860 are transmitted via the wireless communication interface, typically using Bluetooth or Bluetooth Low Energy protocols. Each command specifies the desired action such as deploy to a specific height, stow to the fully retracted position, or report current status. The boat fender positioning systems 1830 receive these commands through their wireless interfaces, which remain powered even during standby periods due to the enhanced low-power standby mode that keeps the Bluetooth module active. Upon receiving a command, a boat fender positioning system 1830 activates its wake-up module to bring the microcontroller out of standby, closes the electrically-controllable switch to provide power to the processor and motor block, and executes the commanded action.

[0283] As the boat fender positioning systems 1830 execute the commands received in step 1860, they proceed to step 1870 in which they track their status. Tracking status involves monitoring various parameters including the current position of the fender as determined by the rotary encoder measuring motor shaft rotations, the battery voltage and remaining capacity, the motor current to detect stall conditions when the fender reaches the fully retracted position, and any error conditions such as line tangles or obstructions. The microcontroller in each boat fender positioning system 1830 continuously monitors these parameters and maintains an updated status record that can be transmitted to the automatic fender controller 1820.

[0284] The messaging sequence then proceeds to step 1880 in which the boat fender positioning systems 1830 send status updates to the automatic fender controller 1820 for display on the chartplotter 1810. These status updates are transmitted wirelessly via the Bluetooth interface and may be sent periodically at regular intervals, in response to status query commands from the automatic fender controller 1820, or when significant status changes occur such as completion of a deployment or stowing operation. The status updates include information such as current fender position (deployed or stowed), battery level as a percentage of full charge, Bluetooth connection status, and any error or warning conditions.

[0285] Upon receiving the status updates from the boat fender positioning systems 1830 in step 1880, the automatic fender controller 1820 processes and consolidates the information from all fender units and forwards this information to the chartplotter 1810 for display to the boat operator. The chartplotter 1810 updates the user interface to reflect the current status, such as changing the visual indicators on the boat orientation display to show which fenders are deployed and which are stowed, updating the battery percentage displayed in the data view, and updating the Bluetooth connection status. This continuous cycle of status updates ensures that the boat operator always has current and accurate information about the state of all fender units displayed on the chartplotter.

[0286] The messaging sequence illustrated in FIG. 18 demonstrates how the integration of automatic fender control with chartplotter systems provides a seamless user experience. From the boat operator's perspective, controlling fenders through the chartplotter is as simple as selecting the FENDERS tab, viewing the current status of all fenders, and touching controls to deploy or stow fenders as needed. Behind this simple interface, the messaging sequence coordinates communication between the chartplotter 1810, the automatic fender controller 1820, and multiple boat fender positioning systems 1830 to translate user intent into physical fender movements and to provide real-time feedback on fender status.

[0287] The messaging diagram also illustrates how the system architecture supports the key advantages of chartplotter integration. By establishing the initial connection between the automatic fender controller 1820 and all boat fender positioning systems 1830 in step 1810, the system enables control of ten or more fenders, overcoming the limitation of mobile device implementations that can typically control only five fenders in extended range mode. By delivering the user interface app to the chartplotter 1810 in steps 1820 and 1830, the system enables centralized control from the cockpit where all other boat systems are operated. By continuously tracking status in step 1870 and sending updates in step 1880, the system provides the boat operator with complete visibility into fender system status without requiring access to a separate mobile device.

[0288] The messaging sequence further supports intelligent automation features enabled by chartplotter integration. Although not explicitly shown in the diagram, the automatic fender controller 1820 can also receive navigational data from the chartplotter 1810 including GPS position, speed, heading, tidal information, and map data. When auto mode is enabled, the automatic fender controller 1820 uses this navigational data to make intelligent deployment decisions without requiring explicit user commands. For example, the automatic fender controller 1820 can monitor the boat's GPS position and automatically send deploy commands to the boat fender positioning systems 1830 when the boat enters a geofenced harbor area. Similarly, the automatic fender controller 1820 can monitor the boat's speed and automatically send stow commands when the boat accelerates beyond a configured threshold, preventing the common problem of forgotten deployed fenders.

[0289] The bi-directional nature of the communication established in step 1810 allows for reliable operation of the integrated system. The ability to send commands from the automatic fender controller 1820 to the boat fender positioning systems 1830 enables responsive control where fenders deploy or stow immediately upon receiving commands. The ability to receive status updates from the boat fender positioning systems 1830 enables the operator to verify that commands were executed successfully and to monitor the ongoing state of all fender units. Without bi-directional communication, the operator would have to rely on visual inspection to determine whether fenders were actually deployed or stowed, which defeats the purpose of having an integrated control system.

[0290] The messaging sequence is designed to be robust and resilient to temporary communication failures. If the connection between the automatic fender controller 1820 and a boat fender positioning system 1830 is temporarily lost, such as due to interference or the fender unit moving behind an obstruction, the automatic fender controller 1820 can retry sending commands when the connection is reestablished. The status updates sent in step 1880 include sequence numbers or timestamps that allow the automatic fender controller 1820 to determine which status information is most current and to detect when status updates have been missed. The chartplotter 1810 can display connection status indicators to alert the operator if communication with any fender unit has been lost.

[0291] The implementation of the messaging sequence varies depending on the chartplotter platform and system architecture. For Garmin implementations using an external ethernet adapter, the connection between the chartplotter 1810 and the automatic fender controller 1820 in steps 1820 through 1850 uses ethernet and HTTP / WebSocket protocols, while the connection between the automatic fender controller 1820 and the boat fender positioning systems 1830 in steps 1810, 1860, 1870, and 1880 uses Bluetooth wireless protocols. For Raymarine implementations with native Bluetooth support, all communication may use wireless Bluetooth protocols, or a hybrid approach may be used with ethernet for chartplotter communication and Bluetooth for fender unit communication.

[0292] The messaging diagram represents a typical operational sequence, but variations are possible depending on specific use cases and system configurations. For example, the chartplotter 1810 may request the user interface app in step 1820 multiple times if the operator navigates away from the fender control interface and then returns to it. The automatic fender controller 1820 may send commands to the boat fender positioning systems 1830 in step 1860 either individually to each fender unit or as broadcast messages to groups of fender units, depending on the command. Status updates may be sent from the boat fender positioning systems 1830 at varying frequencies depending on activity level, with more frequent updates during active deployment or stowing operations and less frequent updates when fenders are stationary.

[0293] FIG. 19 is an exemplary screenshot of automatic boat fender control with chartplotter integration 1900. This embodiment illustrates an exemplary user interface implementation that demonstrates how fender control functions may be integrated into a chartplotter display, providing the boat operator with centralized control of automatic fender units from the cockpit where the chartplotter is typically located. The screenshot shows how navigational data from the chartplotter and fender control functions are presented together in a unified interface that allows the boat operator to monitor both navigation information and fender status simultaneously.

[0294] The exemplary screenshot 1900 comprises a screenshot 1910 and an automatic fender control interface 1920. The screenshot 1910 represents what a boat operator would see on the display of a chartplotter when accessing the fender control functions. This integrated presentation allows deployment of fenders from a central location on the boat, specifically the cockpit where the captain operates all other boat systems, eliminating the need for crew to move around the boat to deploy fenders manually or to access a separate mobile device or control panel.

[0295] The screenshot 1910 comprises selection tabs 1911, a chart view 1912, a position indicator 1913, a data view 1914, and an automatic fender control interface 1920. These components work together to provide a comprehensive interface that combines traditional chartplotter navigation functions with the new automatic fender control capabilities.

[0296] The selection tabs 1911 provide navigation between different functions of the chartplotter. In this embodiment, the selection tabs 1911 include HOME, CHART, SONAR, and FENDERS options. The HOME tab returns the user to the chartplotter's main screen. The CHART tab displays traditional navigation charts. The SONAR tab provides access to sonar and depth sounding functions. The FENDERS tab, which is the focus of this invention, provides access to the automatic fender control interface 1920. The inclusion of the FENDERS tab alongside the traditional chartplotter functions demonstrates the seamless integration of fender control into the chartplotter system, making fender operations as accessible as other primary chartplotter functions.

[0297] The chart view 1912 displays a navigation chart showing the boat's current position and surrounding geographical features. In this embodiment, even when the FENDERS tab is selected to access fender control functions, the chart view 1912 remains visible in the interface, allowing the boat operator to maintain situational awareness while controlling fenders. This split-screen or overlay approach ensures that navigation information remains accessible even while performing fender operations, which is particularly important during docking maneuvers when both navigation and fender deployment must be managed simultaneously.

[0298] The position indicator 1913 marks the boat's current position on the chart view 1912. The position indicator 1913 is updated in real-time based on GPS data from the chartplotter's GPS module, providing accurate and continuously updated position information. The high-quality GPS data from the chartplotter enables the intelligent automation features of the fender control system, such as automatically deploying fenders when the boat enters a geofenced harbor area or automatically lifting fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock.

[0299] The data view 1914 displays numerical data about the boat's current state and fender system status. In this embodiment, the data view 1914 shows position exemplary coordinates (47.2529 degrees North, 122.4443 degrees West), speed (2.3 knots), heading (045 degrees True), fender battery status (87 percent), and Bluetooth connection status (Connected). This data is obtained from the chartplotter's GPS module and other sensors, as well as from status updates received from the automatic fender units. The combination of navigation data and fender system status in a single view provides the boat operator with all necessary information for safe and effective docking operations.

[0300] The automatic fender control interface 1920 comprises a boat orientation display 1921, a boat orientation indicator 1922, a deploy port side control 1923, a deploy starboard control 1924, a stow all fenders control 1925, an auto mode indicator 1926, and a settings control 1927. These controls provide comprehensive functionality for both manual and automated fender operations.

[0301] The boat orientation display 1922 provides a visual representation of the boat as viewed from above, showing the locations of automatic fender units and their current deployment status. In this embodiment, the automatic fender control interface 1920 shows four fender positions 1921: Port Forward, Port Aft, Starboard Forward, and Starboard Aft. This top-down view helps the boat operator quickly understand which fenders are deployed and which are stowed, and assists in planning fender deployment based on the approach angle to the dock.

[0302] The automatic fender control interface 1920 shows the deployment status of each fender position using visual indicators. In this embodiment, the automatic fender control interface 1920 uses filled circles 1921 to indicate deployed fenders and open circles to indicate stowed fenders. A legend explains that a filled circle symbol means deployed and an open circle symbol means stowed. In the state shown, the Port Forward and Port Aft fenders are deployed (shown with filled circles), while the Starboard Forward and Starboard Aft fenders are stowed (shown with open circles). This visual representation provides immediate status information without requiring the boat operator to read text, allowing for quick assessment of fender deployment status during busy docking operations.

[0303] The deploy port side control 1923 is a button or touch control that, when activated, commands all fenders on the port side of the boat to deploy. This grouped control simplifies fender deployment by allowing the boat operator to deploy all fenders on one side with a single action rather than having to deploy each fender individually. This is particularly useful when approaching a dock on the port side, as the operator can quickly deploy all necessary fenders with one command.

[0304] The deploy starboard control 1924 is a button or touch control that, when activated, commands all fenders on the starboard side of the boat to deploy. Like the deploy port side control 1923, this grouped control simplifies fender deployment by allowing the boat operator to deploy all fenders on one side with a single action. The availability of separate port and starboard deployment controls allows the system to deploy fenders on the appropriate side of the boat based on the approach angle to the dock, which is one of the intelligent automation features enabled by integration with the chartplotter.

[0305] When integrated with chartplotter navigational data, the system can automatically determine which side of the boat to deploy fenders based on compass and boat direction information relative to dock location shown on GPS maps. For example, if the chartplotter shows that a dock is located to port of the boat's current heading, the system can automatically activate the deploy port side control 1923 when the boat enters a geofenced area around the dock, or can present a recommendation to the boat operator to deploy port side fenders.

[0306] The stow all fenders control 1925 is a button or touch control that, when activated, commands all fenders on all sides of the boat to retract to their stowed positions. This control provides a quick and convenient way to stow all fenders after leaving a dock. People often forget to lift fenders when they leave the dock, which is a major problem as deployed fenders create drag and can be damaged at speed. The stow all fenders control 1925 addresses this problem by providing an easy one-touch solution for retracting all fenders.

[0307] When integrated with the high-quality GPS data from the chartplotter, the system can further address the problem of forgotten fenders by automatically activating the stow all fenders function when the boat accelerates beyond a configured speed threshold. Having a better external GPS from the chartplotter provides more reliable functionality for this automation that otherwise cannot be implemented with mobile phone GPS. Using a phone GPS, the system cannot reliably implement automatic stowing because false readings occur, especially on bigger boats that have hard tops and glass all over which interfere with GPS signals. The boat's external GPS from the chartplotter does not suffer from these interference issues, therefore false readings should not occur and the system can implement fully automatic fender stowing based on reliable speed data.

[0308] The auto mode indicator 1926 shows the current status of the automatic fender deployment mode. In this embodiment, the auto mode indicator 1926 displays AUTO MODE: OFF, indicating that automatic fender deployment features are currently disabled and fenders must be controlled manually using the deploy port side control 1923, deploy starboard control 1924, or stow all fenders control 1925. When auto mode is enabled, the auto mode indicator 1926 would display AUTO MODE: ON, and the system would automatically deploy and stow fenders based on configured rules and chartplotter data.

[0309] The automatic fender deployment features enabled when auto mode is active include automatically deploying fenders when the boat enters a geofenced harbor area, automatically adjusting fender heights based on tidal information when docked at fixed docks, deploying fenders on the appropriate side of the boat based on compass and boat direction information relative to dock location shown on GPS maps, and automatically lifting fenders when the boat accelerates beyond a configured speed threshold upon leaving a dock. These automated functions are made possible by the high-quality GPS data and navigational information available from the chartplotter.

[0310] The settings control 1927 is a button or touch control that, when activated, provides access to configuration settings for the fender control system. The settings accessible through the settings control 1927 may include options for pairing with automatic fender units, configuring geofenced areas for automatic deployment, setting speed thresholds for automatic stowing, adjusting fender deployment heights, configuring tidal adjustment parameters, enabling or disabling auto mode, and other system configuration options. The settings control 1927 provides access to the full range of customization options that allow boat owners to adapt the fender control system to their specific boat configuration and operational preferences.

[0311] The user interface shown in FIG. 19 demonstrates how the fender controller application provides user interface controls for deploying and lifting fenders, pairing with automatic fender units, monitoring battery status of automatic fender units, tracking position status of fenders, and other control and monitoring functions. All of these functions are accessible through the chartplotter display, providing centralized control from the cockpit where the captain operates all other boat systems.

[0312] The integration of navigational data in the data view 1914 demonstrates a major advantage of chartplotter integration: access to other functions of the chartplotter for integration into fender deployment decisions. The position coordinates shown (47.2529 degrees North, 122.4443 degrees West) are obtained from the chartplotter's GPS module, which is faster and far more accurate than the GPS of a mobile phone. The GPS of a chartplotter can be located down to sub-meter accuracy in less than a second, while GPS of a mobile phone can only be located down to tens-of-meters accuracy within several seconds (but can be more accurate down to a couple of meters after 10 or more seconds).

[0313] The exemplary screenshot 1900 demonstrates how the automatic boat fender control with chartplotter integration solves the problems identified in the background of the invention. By providing centralized control from the cockpit through the chartplotter interface, the invention eliminates the need for crew to move around the boat to deploy fenders manually, reducing the risk of slip and fall accidents. By leveraging the chartplotter's superior GPS, the invention enables reliable automation using a more accurate GPS device that prevents the common problem of forgotten deployed fenders. By connecting the system to the boat's on-board power or to Power over Ethernet (PoE), the problems with mobile phone battery drainage are alleviated. By using a dedicated automatic boat fender control device, limitations of mobile phone wireless hardware can be overcome, allowing control of a larger number of fenders at greater distances. By integrating with the chartplotter's navigational data, the invention enables intelligent deployment decisions based on boat position, speed, heading, and proximity to docks. By providing clear status information for all fender units, the invention ensures that the boat operator has complete visibility into the fender system state during critical docking operations.

[0314] FIG. 20 is an exemplary system diagram illustrating control of boat fender positioning systems directly from a marine chartplotters by installation of a fender control application onto the chartplotter. The figure depicts an exemplary system 2000 for controlling deployment and retrieval of boat fenders directly from a chartplotter using a fender control application. As with other embodiments herein, this integration allows boat operators to manage fender positioning from a central location at the helm where chartplotters are typically installed, rather than requiring manual deployment of fenders at the boat's edge where safety risks are heightened.

[0315] In this embodiment, a fender control application 2100 is installed on a chartplotter 2020 that features a wireless interface and application support. Chartplotter 2020 comprises an operating system 2022, display 2024, GPS module 2025, and wireless interface 2020. Chartplotters of this type are widely used in marine navigation and typically include Android-based or proprietary operating systems that may support third-party applications. In this embodiment, fender control application 2100 is installed (e.g., directly via a mobile device, via a desktop computer through the Internet, etc.) on a chartplotter 2020. The fender control application 2100 operates on the chartplotter and provides controls on the display of the chartplotter which may be used to control boat fender positioning systems / devices directly from the chartplotter without the need for an external automatic fender controller box.

[0316] Operating system 2022 provides the software platform upon which fender control application 2100 executes. In embodiments where chartplotter 2020 uses an Android-based operating system, operating system 2022 may support installation of Android Package (APK) files that contain fender control application 2100. Operating system 2022 manages communication between fender control application 2100 and hardware components including display 2024, GPS module 2025, and wireless interface 2020. Bidirectional communication paths connect operating system 2022 to these hardware components, allowing fender control application 2100 to receive position data from GPS module 2025, render user interface elements on display 2024, and transmit commands through wireless interface 2020.

[0317] Display 2024 presents visual information to boat operators and receives touch input for controlling system functions. Display 2024 renders user interface elements generated by fender control application 2100, including controls for deploying fenders, retracting fenders, configuring fender positions, and monitoring fender status. Display 2024 typically comprises a touchscreen interface that allows operators to interact with fender control application 2100 using gestures such as taps, swipes, and button presses. In addition to fender control interface elements, display 2024 may simultaneously present navigation charts, GPS position information, and other chartplotter functions, allowing boat operators to monitor fender status without interrupting navigation tasks.

[0318] GPS module 2025 determines geographic position of chartplotter 2020 and, by extension, position of associated boat. GPS module 2025 provides position data to fender control application 2100 through operating system 2022. Position data from GPS module 2025 enables location-based automation features, including automatic fender deployment when approaching designated docking locations, geofenced areas that trigger fender deployment, and position logging for docking maneuvers. GPS module 2025 in chartplotters typically provides superior accuracy and faster position acquisition compared to GPS receivers in mobile phones, with sub-meter accuracy achievable in less than one second. The chartplotter GPS is especially more accurate compared to mobile GPS operated under hard top cruisers. This enhanced GPS performance supports more reliable automation of fender deployment based on vessel position relative to harbors, docks, and other designated locations.

[0319] Wireless interface 2020 establishes wireless communication between chartplotter 2020 and automatic fender units mounted on boat. In embodiments using Bluetooth Low Energy (BLE) communication, wireless interface 2020 comprises Bluetooth transceiver hardware and associated firmware for establishing BLE connections with multiple automatic fender units. Wireless interface 2020 transmits commands from fender control application 2100 to fender units, including deploy commands, retract commands, position adjustment commands, and configuration parameters. Wireless interface 2020 also receives status information from fender units, including current fender position, battery charge level, and operational state. Communication through wireless interface 2020 may utilize coded PHY (physical layer) extensions to BLE protocol, extending communication range to support larger vessels where fender units may be positioned at significant distances from chartplotter 2020 at helm. Wireless interface 2020 enables control of multiple automatic fender units from single chartplotter interface, with embodiments supporting control of ten or more fender units simultaneously.

[0320] Fender control application 2100 executes on operating system 2022 and provides user interface and control logic for automatic fender deployment system. Installation of fender control application 2100 onto operating system 2022 occurs as a one-time installation process, indicated by dashed lines in FIG. 20. Once installed, fender control application 2100 resides persistently on chartplotter 2020 and launches automatically or upon user request. Fender control application 2100 comprises user interface components for rendering fender status displays, control buttons, configuration screens, and location services integration on display 2024. Communication interfaces within fender control application 2100 manage data exchange with GPS module 2025 for position-based automation and with wireless interface 2020 for transmitting commands to and receiving status from automatic fender units.

[0321] In operation, boat operators interact with fender control application 2100 through display 2024 to deploy or retract fenders as docking situations require. Commands entered through display 2024 pass through operating system 2022 to fender control application 2100, which processes commands and transmits corresponding control signals through wireless interface 2020 to automatic fender units. Position data from GPS module 2025 flows continuously to fender control application 2100, enabling automation features such as triggering fender deployment when vessel approaches pre-configured docking locations or automatically retracting fenders when vessel speed exceeds configured thresholds indicating departure from dock. This centralized control arrangement eliminates need for boat operators to manually deploy fenders at boat edge where fall risks and other hazards are present, particularly during adverse weather conditions or high-traffic docking situations.

[0322] Integration of fender control with chartplotter 2020 provides several advantages over mobile phone-based control approaches. Chartplotter 2020 remains powered continuously when vessel electrical systems are active, eliminating concerns about mobile phone battery depletion during extended boating sessions. GPS module 2025 in chartplotter 2020 provides faster position acquisition and improved accuracy compared to mobile phone GPS receivers, particularly in challenging environments where satellite signals may be partially obstructed. Display 2024 in chartplotter 2020 typically offers larger screen area and better visibility in bright sunlight compared to mobile phone displays, improving usability during daytime docking operations. Wireless interface 2020 in chartplotter 2020 may support extended-range BLE communication modes, enabling reliable control of fender units on larger vessels where distance between helm and fender mounting locations exceeds typical mobile phone BLE range limitations. These advantages make chartplotter-integrated fender control particularly suitable for vessels equipped with modern marine electronics where chartplotters are already installed as primary navigation instruments.

[0323] FIG. 21 illustrates an exemplary fender control application connected to one or more boat fender positioning units. The figure depicts an exemplary system 2100 comprising fender control application 2110 and boat fender positioning system 2120, illustrating how software components executing on a chartplotter, mobile device, or external automatic fender controller box communicate with hardware components of automatic boat fender deployment systems.

[0324] Fender control application 2110 comprises software components that execute on a host device such as a chartplotter, mobile device, or external automatic fender controller box to provide user interface functionality and control logic for automatic fender deployment. Fender control application 2110 includes configuration screen 2111, status display 2112, user interface commands 2113, GPS / location services 2114, and wireless interface of device connected to fender control application 2130. These components work cooperatively to provide comprehensive control and monitoring capabilities for automatic fender deployment systems.

[0325] Configuration screen 2111 provides user interface elements for configuring operational parameters of fender control application 2110 and connected boat fender positioning systems 2120. Through configuration screen 2111, boat operators may define geofenced areas that trigger automatic fender deployment, set fender deployment heights for different docking scenarios, configure speed thresholds for automatic fender retraction upon departure, establish pairing relationships between fender control application 2110 and individual boat fender positioning systems 2120, and adjust communication parameters for wireless connections. Configuration screen 2111 may present controls for naming individual fender units to facilitate identification in multi-fender installations, setting preferred deployment positions for port-side versus starboard-side docking situations, and configuring alert preferences for low battery conditions or mechanical faults in boat fender positioning systems 2120.

[0326] Status display 2112 presents real-time operational status information for connected boat fender positioning systems 2120 to boat operators. Status display 2112 renders visual indicators showing current deployment state of each fender unit, including whether fenders are fully retracted, partially deployed, or fully deployed. Battery charge levels for each boat fender positioning system 2120 appear on status display 2112, alerting operators to units requiring recharging or battery replacement. Current fender position information derived from position encoding reader 2123 displays on status display 2112, indicating precise height or extension of each fender relative to boat hull. Wireless connection strength indicators on status display 2112 inform operators of communication quality between fender control application 2110 and boat fender positioning systems 2120, warning of potential connectivity issues before they affect control operations. Error conditions such as motor stalls, line tangles, or mechanical obstructions detected by boat fender positioning systems 2120 generate alerts displayed prominently on status display 2112.

[0327] User interface commands 2113 comprise software modules that process operator inputs from touchscreen interactions, button presses, or other input mechanisms and translate these inputs into control commands for boat fender positioning systems 2120. When boat operators interact with fender control application 2110 to deploy fenders, retract fenders, or adjust fender positions, user interface commands 2113 receive these interactions and generate corresponding command messages. User interface commands 2113 may support individual fender control, allowing operators to deploy or retract specific fenders independently, or group control modes that operate multiple fenders simultaneously with single operator action. Preset position commands accessible through user interface commands 2113 allow operators to recall frequently-used fender configurations such as port-side docking setup or starboard-side docking setup with single button press. Emergency retract commands processed by user interface commands 2113 override automated deployment logic and immediately retract all fenders when operators encounter unexpected docking situations requiring rapid fender removal.

[0328] GPS / location services 2114 provide geographic positioning functionality to fender control application 2110, enabling location-based automation features for fender deployment. GPS / location services 2114 interface with GPS hardware in host device, whether chartplotter-integrated GPS module 2025 as described in FIG. 20 or mobile phone GPS receiver. Position data from GPS / location services 2114 enables geofencing capabilities where fender control application 2110 automatically triggers fender deployment when vessel enters predefined geographic areas corresponding to harbors, marinas, or specific docking locations. GPS / location services 2114 calculates vessel speed from sequential position readings, enabling automatic fender retraction when vessel speed exceeds configured threshold indicating departure from docking area. Location logging functionality within GPS / location services 2114 records positions where fender deployments occur, allowing operators to review docking history and refine geofence boundaries for improved automation accuracy. Integration with chartplotter navigation systems through GPS / location services 2114 allows fender control application 2110 to access active route information and anticipate upcoming docking locations based on planned navigation routes.

[0329] Wireless interface of device connected to fender control application 2130 manages wireless communication between fender control application 2110 and wireless interface 2125 of boat fender positioning systems 2120. Wireless interface 2130 implements communication protocol stack for Bluetooth Low Energy (BLE) connections in embodiments using BLE wireless technology, establishing pairing relationships with boat fender positioning systems 2120 and maintaining active connections during operation. Command transmission through wireless interface 2130 converts high-level fender control commands from user interface commands 2113 into wireless protocol messages suitable for transmission to wireless interface 2125. Status message reception through wireless interface 2130 receives position updates, battery status, and error conditions from boat fender positioning systems 2120 and forwards this information to status display 2112 for presentation to operators. Connection management functions within wireless interface 2130 handle discovery of available boat fender positioning systems 2120, automatic reconnection after communication interruptions, and concurrent management of multiple simultaneous connections to control multiple fender units from single fender control application 2110 instance.

[0330] The exemplary boat fender positioning system 2120 of this embodiment comprises hardware and firmware components that execute fender deployment commands received from fender control application 2110. Boat fender positioning system 2120 of this embodiment comprises a configuration screen 2121, a motor controller 2122, a position encoding reader 2123, a processor 2124, and a wireless interface 2125. These components coordinate to provide autonomous fender deployment and retraction with precise position control and status reporting capabilities.

[0331] Configuration screen 2121 within boat fender positioning system 2120 stores configuration parameters that govern operation of motor controller 2122 and other system components. Configuration screen 2121 may be implemented as non-volatile memory storage accessible to processor 2124, retaining configuration settings through power cycles. Parameters stored in configuration screen 2121 include motor speed settings that determine deployment and retraction velocity, current limit thresholds that prevent motor damage during stall conditions, calibration data associating position encoder readings from position encoding reader 2123 with physical fender positions, and wireless pairing information establishing authorized connections with fender control application 2110. Factory default settings stored in configuration screen 2121 provide baseline operational parameters, while user-modified settings received from configuration screen 2111 of fender control application 2110 through wireless interface 2125 allow customization for specific vessel requirements.

[0332] Motor controller 2122 drives motor that spools and unspools line for deploying and retracting boat fenders. Motor controller 2122 receives direction commands from processor 2124 specifying whether to operate motor in deployment direction or retraction direction. Speed control within motor controller 2122 adjusts motor velocity according to configuration parameters from configuration screen 2121 and position feedback from position encoding reader 2123, implementing smooth acceleration and deceleration profiles that prevent shock loads on fenders and mounting hardware. Current monitoring capabilities in motor controller 2122 may detect overcurrent conditions indicating motor stall due to line tangles, mechanical obstructions, or end-of-travel limit conditions. Upon detecting overcurrent condition during retraction operation, motor controller 2122 halts motor operation and signals processor 2124 that fender has reached fully retracted position. generated by In some embodiments, motor controller 2122 may use pulse-width modulation (PWM) drive signals to provide efficient motor operation with minimal power consumption, extending battery life in solar-powered embodiments of boat fender positioning system 2120.

[0333] Position encoding reader 2123 determines current position of fender by monitoring rotation of motor shaft or spool that winds and unwinds deployment line. Position encoding reader 2123 may comprise rotary encoder attached to motor shaft, generating pulse sequences as motor rotates during fender deployment and retraction. Processor 2124 counts pulses from position encoding reader 2123 to calculate number of motor shaft rotations, correlating rotation count with length of line deployed or retracted. Calibration data in configuration screen 2121 establishes relationship between encoder pulse count and physical fender position, accounting for spool diameter and line thickness. Position information from position encoding reader 2123 enables precise fender positioning at user-specified heights, supports intermediate position holds during deployment or retraction sequences, and provides feedback to processor 2124 for closed-loop position control. In embodiments using stepper motors rather than brushless DC motors with separate encoders, stepper motor step counting provides position information equivalent to dedicated position encoding reader 2123, as stepper motors inherently track shaft position through commanded step sequences.

[0334] Processor 2124 coordinates operation of components within boat fender positioning system 2120, implementing control logic for autonomous fender deployment in response to commands from fender control application 2110. Processor 2124 may comprise microcontroller unit (MCU) with integrated memory, timers, and communication peripherals suitable for embedded control applications. Firmware executing on processor 2124 receives deployment commands from wireless interface 2125, interprets command parameters specifying target fender positions, and generates motor control signals to motor controller 2122 for executing commanded movements. Position control loops within processor 2124 continuously monitor position feedback from position encoding reader 2123 during motor operation, halting motor controller 2122 when fender reaches commanded position. Error detection logic in processor 2124 monitors for fault conditions including motor stalls, position encoder failures, wireless communication losses, and battery undervoltage situations. Status reporting functions within processor 2124 periodically transmit current position, battery voltage, and operational state through wireless interface 2125 to fender control application 2110 for display on status display 2112.

[0335] Wireless interface 2125 of boat fender positioning system 2120 establishes wireless communication with wireless interface 2130 of a device on which fender control application 2110 is installed, receiving control commands and transmitting status information. Wireless interface 2125 implements Bluetooth Low Energy protocol stack in embodiments using BLE communication, maintaining persistent connection with paired fender control application 2110 instance during operation. Command reception functions within wireless interface 2125 decode incoming deployment commands, retraction commands, position adjustment commands, and configuration update messages, forwarding decoded commands to processor 2124 for execution. Status transmission functions within wireless interface 2125 encode current fender position from position encoding reader 2123, battery charge level, error conditions, and operational state into wireless protocol messages for transmission to wireless interface 2130. Low-power operation modes in wireless interface 2125 reduce power consumption during idle periods between command transmissions, extending battery life in solar-powered boat fender positioning systems 2120. Extended-range BLE modes using coded PHY physical layer extensions enable wireless interface 2125 to maintain reliable communication with fender control application 2110 over distances exceeding standard BLE range, accommodating larger vessels where fender units mount at significant distances from helm-mounted chartplotters.

[0336] Communication flow between components illustrated in FIG. 21 demonstrates integrated operation of software and hardware subsystems. When boat operator interacts with configuration screen 2111 or issues commands through user interface commands 2113, these inputs propagate through fender control application 2110 to wireless interface 2130, which transmits corresponding messages to wireless interface 2125 of boat fender positioning system 2120. Processor 2124 receives commands from wireless interface 2125 and orchestrates motor controller 2122 operation while monitoring position encoding reader 2123 feedback. Status updates generated by processor 2124 flow back through wireless interface 2125 to wireless interface 2130 and appear on status display 2112, completing bidirectional communication loop between operator interface and physical fender deployment mechanism. GPS / location services 2114 operates independently within fender control application 2110, triggering automated deployment sequences through user interface commands 2113 when location-based conditions specified in configuration screen 2111 are satisfied.

[0337] FIG. 22 illustrates an exemplary operational flow diagram for a fender control application showing initialization sequence, command processing logic, connection management, and parallel operation threads for controlling multiple boat fender positioning systems. The figure depicts exemplary fender control application operation 2200 comprising startup procedures, permission verification, connection establishment, user interaction handling, command queuing, status monitoring, and error recovery mechanisms that coordinate to provide reliable control of automatic fender deployment systems.

[0338] Operation of fender control application begins with startup 2210, which initializes application components and prepares system for user interaction. During startup 2210, fender control application loads configuration parameters from persistent storage, initializes user interface components described in FIG. 21 including configuration screen 2111 and status display 2112, and establishes connections to hardware interfaces such as GPS / location services 2114 and wireless interface 2130. Startup 2210 may include verification of software dependencies, loading of saved fender configurations and geofence definitions, and initialization of command queue 2216 data structures. Upon completing initialization tasks, execution proceeds from startup 2210 to check permissions 2211.

[0339] Check permissions 2211 verifies that fender control application has obtained necessary operating system permissions for accessing hardware resources required for operation. On mobile platforms such as Android or iOS, check permissions 2211 confirms that user has granted location access permissions enabling GPS / location services 2114 to function, Bluetooth permissions allowing wireless interface 2130 to communicate with boat fender positioning systems 2120, and storage permissions permitting application to save configuration data and operational logs. If required permissions have not been granted, check permissions 2211 prompts user to approve permission requests through operating system permission dialogs. On chartplotter platforms where permission models differ from mobile operating systems, check permissions 2211 may verify hardware availability rather than explicit user permissions. After confirming all necessary permissions are available, execution advances from check permissions 2211 to connect to boat fender positioning systems 2212.

[0340] Connect to boat fender positioning systems 2212 establishes wireless communication links between fender control application and one or more boat fender positioning systems 2120 installed on vessel. During connection establishment at step 2212, wireless interface 2130 initiates scanning for available boat fender positioning systems 2120 within wireless communication range, identifying systems by unique device identifiers or names configured during initial pairing. For each boat fender positioning system / device 2120 discovered during scan, wireless interface 2130 attempts connection using stored pairing credentials from configuration screen 2111. Successful connection establishment enables bidirectional communication between fender control application and wireless interface 2125 of each boat fender positioning system / device 2120, allowing transmission of commands and reception of status updates. Upon establishing connections to all configured boat fender positioning systems / devices 2120, or after timeout period if some systems remain unavailable, execution proceeds from connect to boat fender positioning systems / devices 2212 to user action decision point 2213.

[0341] User action decision point 2213 determines whether boat operator has initiated any interaction with fender control application requiring processing. Fender control application monitors for user actions including touchscreen interactions with status display 2112, button presses commanding fender deployment or retraction, configuration changes entered through configuration screen 2111, and selection of preset fender positions. If user action has occurred, indicated by yes path from decision point 2213, execution proceeds to update parameters 2221. If no user action has occurred, indicated by no path from decision point 2213, execution continues to lost connection decision point 2223. This decision point 2213 implements event-driven processing model where application remains in waiting state until user input or system events require attention, minimizing power consumption and processor utilization during idle periods.

[0342] Update parameters 2221 processes user actions detected at decision point 2213, translating user interface interactions into commands or configuration changes for boat fender positioning systems 2120. When user action comprises deployment command, retraction command, or position adjustment command, update parameters 2221 invokes user interface commands 2113 to generate appropriate command message specifying target fender position and affected boat fender positioning systems 2120. Generated commands pass to enqueue command 2214 for placement in command queue 2216. When user action comprises configuration change such as modifying geofence boundaries, adjusting deployment heights, or updating wireless pairing settings, update parameters 2221 stores modified configuration in configuration screen 2111 and transmits configuration updates to affected boat fender positioning systems 2120 for storage in configuration screen 2121. After processing user action, execution returns from update parameters 2221 to user action decision point 2213 to await subsequent user interactions or system events.

[0343] Lost connection decision point 2223 monitors communication status with boat fender positioning systems 2120, detecting wireless connection failures that prevent command transmission or status reception. Wireless interface 2130 continuously monitors signal strength and message acknowledgment from wireless interface 2125 of each connected boat fender positioning system 2120, identifying connection losses when acknowledgment messages cease arriving or signal strength falls below operational threshold. If connection loss has occurred to one or more boat fender positioning systems 2120, indicated by yes path from decision point 2223, execution proceeds to reconnect 2224. If all connections remain active, indicated by no path from decision point 2223, execution continues to wait / process command 2222. This monitoring function ensures fender control application detects and responds to communication failures promptly, preventing accumulation of undelivered commands in command queue 2216 when boat fender positioning systems 2120 become unreachable.

[0344] Wait / process command 2222 retrieves commands from command queue 2216 and initiates transmission to appropriate boat fender positioning systems 2120 through wireless interface 2130. When command queue 2216 contains pending commands, wait / process command 2222 dequeues next command and transmits it through wireless interface 2130 to wireless interface 2125 of destination boat fender positioning system 2120. Command transmission includes target position specifications, movement speed parameters, and command sequence identifiers for tracking acknowledgment. After transmitting command, wait / process command 2222 awaits acknowledgment from boat fender positioning system 2120 confirming command receipt and initiation of requested operation. When command queue 2216 is empty, wait / process command 2222 enters waiting state until new commands arrive from enqueue command 2214 or timeout period elapses. Execution proceeds from wait / process command 2222 to status verification 2215 for monitoring command execution progress.

[0345] Reconnect 2224 attempts to reestablish wireless communication with boat fender positioning systems 2120 that have lost connection, as detected at lost connection decision point 2223. Reconnection procedure at step 2224 initiates new wireless scanning through wireless interface 2130 searching for previously-paired boat fender positioning systems 2120 that have become unavailable. Upon locating disconnected boat fender positioning system 2120, reconnect 2224 attempts connection establishment using stored pairing credentials. Successful reconnection restores bidirectional communication allowing transmission of queued commands from command queue 2216 and reception of status updates through status display 2112. If reconnection attempts fail after configured retry count or timeout duration, reconnect 2224 generates alert notification on status display 2112 informing boat operator of persistent connection failure requiring attention. After completing reconnection attempts, execution returns from reconnect 2224 to connect to boat fender positioning systems 2212 to verify connection status of all configured systems before resuming normal operation.

[0346] Enqueue command 2214 receives commands generated by update parameters 2221 or automated deployment triggers from GPS / location services 2114 and places these commands in command queue 2216 for subsequent transmission to boat fender positioning systems 2120. Command queuing at step 2214 implements first-in-first-out (FIFO) ordering ensuring commands execute in sequence they were generated, preventing conflicting commands from executing simultaneously on same boat fender positioning system 2120. When multiple boat fender positioning systems 2120 require simultaneous control, such as deploying all port-side fenders together, enqueue command 2214 creates separate command queue entry for each affected system, allowing parallel execution through fender operation thread 2220. Priority mechanisms within enqueue command 2214 may elevate urgent commands such as emergency retract requests ahead of routine position adjustments in command queue 2216, ensuring safety-critical operations execute without delay from queued routine operations.

[0347] Status verification 2215 monitors execution progress of commands transmitted to boat fender positioning systems 2120, receiving status updates through wireless interface 2130 from wireless interface 2125 and updating status display 2112 with current operational state. Status messages received at step 2215 include current fender position from position encoding reader 2123, motor controller 2122 operational state indicating whether deployment or retraction is in progress, battery charge level, and error conditions detected by processor 2124. Status verification 2215 compares reported position against commanded target position to determine when deployment or retraction operations complete successfully. Upon detecting completion of commanded operation, status verification 2215 updates status display 2112 indicating successful command execution and removes completed command from tracking structures. Error conditions reported through status verification 2215 trigger alert notifications on status display 2112 and may initiate retry attempts for failed operations. After processing status updates, execution returns from status verification 2215 to user action decision point 2213 to continue monitoring for user interactions and system events.

[0348] Command queue 2216 maintains ordered list of pending commands awaiting transmission to boat fender positioning systems 2120. Command queue 2216 accepts commands from enqueue command 2214 and provides commands to wait / process command 2222 for transmission. Data structure implementing command queue 2216 stores command parameters including target boat fender positioning system 2120 identifier, commanded fender position, movement speed, and timestamp indicating when command was generated. Queue depth monitoring within command queue 2216 tracks number of pending commands, generating warnings when queue depth exceeds configured threshold indicating potential processing delays or communication bottlenecks. Command timeout mechanisms in command queue 2216 remove commands that remain undelivered beyond configured timeout duration, preventing execution of obsolete commands after circumstances change. Thread-safe access controls in command queue 2216 implementation ensure multiple fender operation threads 2220 can safely enqueue and dequeue commands concurrently without data corruption.

[0349] Fender operation thread 2220 executes in parallel for each connected boat fender positioning system 2120, enabling simultaneous control of multiple fender units without blocking main application execution flow. Each instance of fender operation thread 2220 manages communication with single boat fender positioning system 2120, monitoring command queue 2216 for commands destined for its associated system. When command targeting specific boat fender positioning system 2120 appears in command queue 2216, corresponding fender operation thread 2220 retrieves command through wait / process command 2222 and transmits it through wireless interface 2130 to wireless interface 2125. Parallel execution through multiple instances of fender operation thread 2220 allows deployment of port-side fenders to proceed concurrently with deployment of starboard-side fenders, reducing total deployment time compared to sequential processing. Each fender operation thread 2220 maintains independent connection monitoring through lost connection decision point 2223 and initiates reconnection through reconnect 2224 specific to its associated boat fender positioning system 2120 without affecting communication with other systems. Status updates received through each fender operation thread 2220 pass to status verification 2215 for display on status display 2112, allowing boat operators to monitor all fender units simultaneously from unified interface.

[0350] Operational flow through exemplary fender control application operation 2200 demonstrates robust control architecture supporting multiple concurrent fender units, automatic error recovery, and responsive user interaction. Following initialization through startup 2210, check permissions 2211, and connect to boat fender positioning systems 2212, fender control application enters continuous monitoring loop alternating between user action decision point 2213 and lost connection decision point 2223. User interactions trigger command generation through update parameters 2221, placement in command queue 2216 through enqueue command 2214, transmission through wait / process command 2222, and verification through status verification 2215. Connection failures detected at lost connection decision point 2223 initiate automatic recovery through reconnect 2224, minimizing disruption to fender control operations. Parallel execution through fender operation thread 2220 instances enables efficient control of multiple boat fender positioning systems 2120 simultaneously, supporting vessels equipped with numerous automatic fender units across port and starboard sides.Exemplary Computer System for Computer-Implemented Aspects and Embodiments

[0351] FIG. 23 illustrates an exemplary computer system on which embodiments described herein may be implemented, in full or in part. This exemplary computer system describes computer-related components and processes supporting enabling disclosure of computer-implemented embodiments. Inclusion in this exemplary computer system of well-known processes and computer components, if any, is not a suggestion or admission that any aspect or embodiment is no more than an aggregation of such processes or components. Rather, implementation of an aspect or embodiment using processes and components described in this exemplary computer system will involve programming or configuration of such processes and components resulting in a machine specially programmed or configured for such implementation. The exemplary computer system described herein is only one example of such an environment and other configurations of the components and processes are possible, including other relationships between and among components, and / or absence of some processes or components described. Further, the exemplary computer system described herein is not intended to suggest any limitation as to the scope of use or functionality of any embodiment implemented, in whole or in part, on components or processes described herein.

[0352] The exemplary computer system described herein comprises a computing device 10 (further comprising a system bus 11, one or more processors 20, a system memory 30, one or more interfaces 40, one or more non-volatile data storage devices 50), external peripherals and accessories 60, external communication devices 70, remote computing devices 80, and cloud-based services 90.

[0353] System bus 11 couples the various system components, coordinating operation of and data transmission between, those various system components. System bus 11 represents one or more of any type or combination of types of wired or wireless bus structures including, but not limited to, memory busses or memory controllers, point-to-point connections, switching fabrics, peripheral busses, accelerated graphics ports, and local busses using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) busses, Micro Channel Architecture (MCA) busses, Enhanced ISA (EISA) busses, Video Electronics Standards Association (VESA) local busses, a Peripheral Component Interconnects (PCI) busses also known as a Mezzanine busses, or any selection of, or combination of, such busses. Depending on the specific physical implementation, one or more of the processors 20, system memory 30 and other components of the computing device 10 can be physically co-located or integrated into a single physical component, such as on a single chip. In such a case, some or all of system bus 11 can be electrical pathways within a single chip structure.

[0354] Computing device may further comprise externally-accessible data input and storage devices 12 such as compact disc read-only memory (CD-ROM) drives, digital versatile discs (DVD), or other optical disc storage for reading and / or writing optical discs 62; magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices; or any other medium which can be used to store the desired content and which can be accessed by the computing device 10. Computing device may further comprise externally-accessible data ports or connections 12 such as serial ports, parallel ports, universal serial bus (USB) ports, and infrared ports and / or transmitter / receivers. Computing device may further comprise hardware for wireless communication with external devices such as IEEE 1394 (“Firewire”) interfaces, IEEE 802.11 wireless interfaces, BLUETOOTH® wireless interfaces, and so forth. Such ports and interfaces may be used to connect any number of external peripherals and accessories 60 such as visual displays, monitors, and touch-sensitive screens 61, USB solid state memory data storage drives (commonly known as “flash drives” or “thumb drives”) 63, printers 64, pointers and manipulators such as mice 65, keyboards 66, and other devices 67 such as joysticks and gaming pads, touchpads, additional displays and monitors, and external hard drives (whether solid state or disc-based), microphones, speakers, cameras, and optical scanners.

[0355] Processors 20 are logic circuitry capable of receiving programming instructions and processing (or executing) those instructions to perform computer operations such as retrieving data, storing data, and performing mathematical calculations. Processors 20 are not limited by the materials from which they are formed or the processing mechanisms employed therein, but are typically comprised of semiconductor materials into which many transistors are formed together into logic gates on a chip (i.e., an integrated circuit or IC). The term processor includes any device capable of receiving and processing instructions including, but not limited to, processors operating on the basis of quantum computing, optical computing, mechanical computing (e.g., using nanotechnology entities to transfer data), and so forth. Depending on configuration, computing device 10 may comprise more than one processor. For example, computing device 10 may comprise one or more central processing units (CPUs) 21, each of which itself has multiple processors or multiple processing cores, each capable of independently or semi-independently processing programming instructions. Further, computing device 10 may comprise one or more specialized processors such as a graphics processing unit (GPU) 22 configured to accelerate processing of computer graphics and images via a large array of specialized processing cores arranged in parallel.

[0356] System memory 30 is processor-accessible data storage in the form of volatile and / or nonvolatile memory. System memory 30 may be either or both of two types: non-volatile memory and volatile memory. Non-volatile memory 30a is not erased when power to the memory is removed, and includes memory types such as read only memory (ROM), electronically-erasable programmable memory (EEPROM), and rewritable solid state memory (commonly known as “flash memory”). Non-volatile memory 30a is typically used for long-term storage of a basic input / output system (BIOS) 31, containing the basic instructions, typically loaded during computer startup, for transfer of information between components within computing device, or a unified extensible firmware interface (UEFI), which is a modern replacement for BIOS that supports larger hard drives, faster boot times, more security features, and provides native support for graphics and mouse cursors. Non-volatile memory 30a may also be used to store firmware comprising a complete operating system 35 and applications 36 for operating computer-controlled devices. The firmware approach is often used for purpose-specific computer-controlled devices such as appliances and Internet-of-Things (IoT) devices where processing power and data storage space is limited. Volatile memory 30b is erased when power to the memory is removed and is typically used for short-term storage of data for processing. Volatile memory 30b includes memory types such as random access memory (RAM), and is normally the primary operating memory into which the operating system 35, applications 36, program modules 37, and application data 38 are loaded for execution by processors 20. Volatile memory 30b is generally faster than non-volatile memory 30a due to its electrical characteristics and is directly accessible to processors 20 for processing of instructions and data storage and retrieval. Volatile memory 30b may comprise one or more smaller cache memories which operate at a higher clock speed and are typically placed on the same IC as the processors to improve performance.

[0357] Interfaces 40 may include, but are not limited to, storage media interfaces 41, network interfaces 42, display interfaces 43, and input / output interfaces 44. Storage media interface 41 provides the necessary hardware interface for loading data from non-volatile data storage devices 50 into system memory 30 and storage data from system memory30 to non-volatile data storage device 50. Network interface 42 provides the necessary hardware interface for computing device 10 to communicate with remote computing devices 80 and cloud-based services 90 via one or more external communication devices 70. Display interface 43 allows for connection of displays 61, monitors, touchscreens, and other visual input / output devices. Display interface 43 may include a graphics card for processing graphics-intensive calculations and for handling demanding display requirements. Typically, a graphics card includes a graphics processing unit (GPU) and video RAM (VRAM) to accelerate display of graphics. One or more input / output (I / O) interfaces 44 provide the necessary support for communications between computing device 10 and any external peripherals and accessories 60. For wireless communications, the necessary radio-frequency hardware and firmware may be connected to I / O interface 44 or may be integrated into I / O interface 44.

[0358] Non-volatile data storage devices 50 are typically used for long-term storage of data. Data on non-volatile data storage devices 50 is not erased when power to the non-volatile data storage devices 50 is removed. Non-volatile data storage devices 50 may be implemented using any technology for non-volatile storage of content including, but not limited to, CD-ROM drives, digital versatile discs (DVD), or other optical disc storage; magnetic cassettes, magnetic tape, magnetic disc storage, or other magnetic storage devices; solid state memory technologies such as EEPROM or flash memory; or other memory technology or any other medium which can be used to store data without requiring power to retain the data after it is written. Non-volatile data storage devices 50 may be non-removable from computing device 10 as in the case of internal hard drives, removable from computing device 10 as in the case of external USB hard drives, or a combination thereof, but computing device will typically comprise one or more internal, non-removable hard drives using either magnetic disc or solid state memory technology. Non-volatile data storage devices 50 may store any type of data including, but not limited to, an operating system 51 for providing low-level and mid-level functionality of computing device 10, applications 52 for providing high-level functionality of computing device 10, program modules 53 such as containerized programs or applications, or other modular content or modular programming, application data 54, and databases 55 such as relational databases, non-relational databases, and graph databases.

[0359] Applications (also known as computer software or software applications) are sets of programming instructions designed to perform specific tasks or provide specific functionality on a computer or other computing devices. Applications are typically written in high-level programming languages such as C++, Java, and Python, which are then either interpreted at runtime or compiled into low-level, binary, processor-executable instructions operable on processors 20. Applications may be containerized so that they can be run on any computer hardware running any known operating system. Containerization of computer software is a method of packaging and deploying applications along with their operating system dependencies into self-contained, isolated units known as containers. Containers provide a lightweight and consistent runtime environment that allows applications to run reliably across different computer architectures, operating systems, and environments.

[0360] The memories and non-volatile data storage devices described herein do not include communication media. Communication media are means of transmission of information such as modulated electromagnetic waves or modulated data signals configured to transmit, not store, information. By way of example, and not limitation, communication media includes wired communications such as sound signals transmitted to a speaker via a speaker wire, and wireless communications such as acoustic waves, radio frequency (RF) transmissions, infrared emissions, and other wireless media.

[0361] External communication devices 70 are devices that facilitate communications between computing device and either remote computing devices 80, or cloud-based services 90, or both. External communication devices 70 include, but are not limited to, data modems 71 which facilitate data transmission between computing device and the Internet 75 via a common carrier such as a telephone company or internet service provider (ISP), routers 72 which facilitate data transmission between computing device and other devices, and switches 73 which provide direct data communications between devices on a network. Here, modem 71 is shown connecting computing device 10 to both remote computing devices 80 and cloud-based services 90 via the Internet 75. While modem 71, router 72, and switch 73 are shown here as being connected to network interface 42, many different network configurations using external communication devices 70 are possible. Using external communication devices 70, networks may be configured as local area networks (LANs) for a single location, building, or campus, wide area networks (WANs) comprising data networks that extend over a larger geographical area, and virtual private networks (VPNs) which can be of any size but connect computers via encrypted communications over public networks such as the Internet 75. As just one exemplary network configuration, network interface 42 may be connected to switch 73 which is connected to router 72 which is connected to modem 71 which provides access for computing device 10 to the Internet 75. Further, any combination of wired 77 or wireless 76 communications between and among computing device 10, external communication devices 70, remote computing devices 80, and cloud-based services 90 may be used. Remote computing devices 80, for example, may communicate with computing device through a variety of communication channels 74 such as through switch 73 via a wired 77 connection, through router 72 via a wireless connection 76, or through modem 71 via the Internet 75. Furthermore, while not shown here, other hardware that is specifically designed for servers may be employed. For example, secure socket layer (SSL) acceleration cards can be used to offload SSL encryption computations, and transmission control protocol / internet protocol (TCP / IP) offload hardware and / or packet classifiers on network interfaces 42 may be installed and used at server devices.

[0362] In a networked environment, certain components of computing device 10 may be fully or partially implemented on remote computing devices 80 or cloud-based services 90. Data stored in non-volatile data storage device 50 may be received from, shared with, duplicated on, or offloaded to a non-volatile data storage device on one or more remote computing devices 80 or in a cloud computing service 92. Processing by processors 20 may be received from, shared with, duplicated on, or offloaded to processors of one or more remote computing devices 80 or in a distributed computing service 93. By way of example, data may reside on a cloud computing service 92, but may be usable or otherwise accessible for use by computing device 10. Also, certain processing subtasks may be sent to a microservice 91 for processing with the result being transmitted to computing device 10 for incorporation into a larger processing task. Also, while components and processes of the exemplary computer system are illustrated herein as discrete units (e.g., OS 51 being stored on non-volatile data storage device 51 and loaded into system memory 35 for use) such processes and components may reside or be processed at various times in different components of computing device 10, remote computing devices 80, and / or cloud-based services 90.

[0363] Remote computing devices 80 are any computing devices not part of computing device 10. Remote computing devices 80 include, but are not limited to, personal computers, server computers, thin clients, thick clients, personal digital assistants (PDAs), mobile telephones, watches, tablet computers, laptop computers, multiprocessor systems, microprocessor based systems, set-top boxes, programmable consumer electronics, video game machines, game consoles, portable or handheld gaming units, network terminals, desktop personal computers (PCs), minicomputers, main frame computers, network nodes, and distributed or multi-processing computer architectures. While remote computing devices 80 are shown for clarity as being separate from cloud-based services 90, cloud-based services 90 are implemented on collections of networked remote computing devices 80.

[0364] Cloud-based services 90 are Internet-accessible services implemented on collections of networked remote computing devices 80. Cloud-based services are typically accessed via application programming interfaces (APIs) which are software interfaces which provide access to computing services within the cloud-based service via API calls, which are pre-defined protocols for requesting a computing service and receiving the results of that computing service. While cloud-based services may comprise any type of computer processing or storage, three common categories of cloud-based services 90 are microservices 91, cloud computing services 92, and distributed computing services 93.

[0365] Microservices 91 are collections of small, loosely coupled, and independently deployable computing services. Each microservice represents a specific computing functionality and runs as a separate process or container. Microservices promote the decomposition of complex applications into smaller, manageable services that can be developed, deployed, and scaled independently. These services communicate with each other through well-defined application programming interfaces (APIs), typically using lightweight protocols like HTTP or message queues. Microservices 91 can be combined to perform more complex processing tasks.

[0366] Cloud computing services 92 are delivery of computing resources and services over the Internet 75 from a remote location. Cloud computing services 92 provide additional computer hardware and storage on as-needed or subscription basis. Cloud computing services 92 can provide large amounts of scalable data storage, access to sophisticated software and powerful server-based processing, or entire computing infrastructures and platforms. For example, cloud computing services can provide virtualized computing resources such as virtual machines, storage, and networks, platforms for developing, running, and managing applications without the complexity of infrastructure management, and complete software applications over the Internet on a subscription basis.

[0367] Distributed computing services 93 provide large-scale processing using multiple interconnected computers or nodes to solve computational problems or perform tasks collectively. In distributed computing, the processing and storage capabilities of multiple machines are leveraged to work together as a unified system. Distributed computing services are designed to address problems that cannot be efficiently solved by a single computer or that require large-scale computational power. These services enable parallel processing, fault tolerance, and scalability by distributing tasks across multiple nodes.

[0368] Although described above as a physical device, computing device 10 can be a virtual computing device, in which case the functionality of the physical components herein described, such as processors 20, system memory 30, network interfaces 40, and other like components can be provided by computer-executable instructions. Such computer-executable instructions can execute on a single physical computing device, or can be distributed across multiple physical computing devices, including being distributed across multiple physical computing devices in a dynamic manner such that the specific, physical computing devices hosting such computer-executable instructions can dynamically change over time depending upon need and availability. In the situation where computing device 10 is a virtualized device, the underlying physical computing devices hosting such a virtualized computing device can, themselves, comprise physical components analogous to those described above, and operating in a like manner. Furthermore, virtual computing devices can be utilized in multiple layers with one virtual computing device executing within the construct of another virtual computing device. Thus, computing device 10 may be either a physical computing device or a virtualized computing device within which computer-executable instructions can be executed in a manner consistent with their execution by a physical computing device. Similarly, terms referring to physical components of the computing device, as utilized herein, mean either those physical components or virtualizations thereof performing the same or equivalent functions.

Claims

1. A boat fender control system comprising:a fender control application installed on, and executing on, a computing device comprising a memory, a processor;a display connected to the computing device;a wireless interface connected to the computing device;wherein the fender control application comprises instructions which cause the computing device to:connect to one or more boat fender positioning devices via the wireless interface;show on the display a status of one or more of the one or more boat fender positioning devices along with one or more controls for operating the one or more boat fender positioning devices;receive a user interaction with one or more controls of the one or more controls shown; andtransmit control commands through the wireless interface to operate one or more of the one or more boat fender positioning devices according to the user interaction.

2. The system of claim 1, wherein the computing device is a marine navigation system and the display and wireless interface are both integrated into the marine navigation system.

3. The system of claim 1, wherein the computing device is a mobile phone and the wireless interface is integrated into the mobile phone.

4. The system of claim 3, wherein:the display is integrated into the marine navigation system; andthe connection to the display from the mobile phone is via the wireless interface.

5. The system of claim 1, wherein:the computing device is an external automatic fender controller;the wireless interface is integrated into the external automatic fender controller; andthe display is integrated into the marine navigation system.

6. The system of claim 5, wherein:the external automatic fender controller further comprises an ethernet adapter; andthe marine navigation system is connected to the external automatic fender controller via the ethernet adapter.

7. The system of claim 6, wherein the external automatic fender controller controls the display via the ethernet adapter using HTML protocols.

8. The system of claim 6, wherein the marine navigation system provides power to the external automatic fender controller via Power over Ethernet (PoE).

9. The system of claim 5, wherein the external automatic fender controller comprises a plurality of wireless interfaces.

10. The system of claim 1, wherein fender control application uses global positioning system (GPS) information from the marine navigation system to operate the one or more boat fender control devices.

11. A computer-implemented method for controlling boat fenders, comprising the steps of:installing a fender control application on a computing device comprising a memory and a processor, wherein a display and a wireless interface are connected to the computing device; andexecuting the fender control application on the computing device wherein the fender control application comprises instructions which cause the computing device to perform the steps of:connecting to one or more boat fender positioning devices via the wireless interface;showing on the display a status of one or more of the one or more boat fender positioning devices along with one or more controls for operating the one or more boat fender positioning devices;receiving a user interaction with one or more controls of the one or more controls shown; andtransmitting control commands through the wireless interface to operate one or more of the one or more boat fender positioning devices according to the user interaction.

12. The method of claim 11, wherein the computing device is a marine navigation system and the display and wireless interface are both integrated into the marine navigation system.

13. The method of claim 11, wherein the computing device is a mobile phone and the wireless interface is integrated into the mobile phone.

14. The method of claim 13, wherein:the display is integrated into the marine navigation system; andthe step of connecting the display to the computing device comprises connecting to the display from the mobile phone via the wireless interface.

15. The method of claim 11, wherein:the computing device is an external automatic fender controller;the wireless interface is integrated into the external automatic fender controller; andthe display is integrated into the marine navigation system.

16. The method of claim 15, further comprising the steps of:providing an ethernet adapter in the external automatic fender controller; andconnecting the marine navigation system to the external automatic fender controller via the ethernet adapter.

17. The method of claim 16, further comprising the step of controlling the display via the ethernet adapter using HTML protocols.

18. The method of claim 16, further comprising the step of providing power from the marine navigation system to the external automatic fender controller via Power over Ethernet (PoE).

19. The method of claim 15, wherein the external automatic fender controller comprises a plurality of wireless interfaces.

20. The method of claim 11, further comprising the step of using global positioning system (GPS) information from the marine navigation system to operate the one or more boat fender positioning devices.

Images