There is nothing quite like dropping the hook in a secluded anchorage and retiring to the aft sundeck to enjoy the sights and sounds of life on the water. When the wind is calm and the water's surface turns to glass the tranquility is magical and I can't imagine a more peaceful setting. While cruising on Sea Gator, we have enjoyed many serene nights at anchor.
But anchoring out does have one drawback. If you asked me or Pat what we fear most about life aboard, we would both say dragging our anchor in the night. Sinking, or rough seas, or ramming an expensive yacht while docking are all events we dread but they wouldn't be at the top of our list. There's something sneaky and underhanded - and very alarming - about your boat moving while you're innocently snoozing.
So, dragging an anchor while sleeping is something we strive to avoid. It only happened to us once, but that once was certainly enough. I won't go into all the details but we were lucky because there were only two other boats nearby and they were both upwind of us and in a very large anchorage. The winds that night were greater than forecast, but we failed to take advantage of the swing room we had anyway. We all learn through our mistakes and, fortunately, we did not let that mistake deter us.
During that single anchor drag event, we were using the anchor drag feature on our Garmin GPSMAP 76C handheld GPS unit. In addition to our less-than-stellar anchoring technique that night, there were two other problems:
First, the Garmin unit was placed at the lower helm station where satellite signal strength was acceptable. Satellite tracking was sporadic in our aft stateroom where I would have liked to keep the device.
Second, when the Garmin unit issued its alarm it did so only momentarily, never to beep again as Sea Gator helplessly dragged her anchor hundreds of yards while we were oblivious. I later learned that a continuous audible alarm was available through a firmware upgrade to the Garmin unit. Obviously, others had complained to Garmin about the inadequacy of this unit's alarm. Given the distance from our stateroom to the lower helm and the blowing wind, I'm not sure we would have heard a continuous alarm that night anyway, but it would have been better insurance than the single cricket-like beep.
Not long after that difficult night, I began thinking about a better anchor alarm. I know that many GPS chartplotters include an anchor drag alarm feature. But we are navigating with our handheld unit and a laptop connected to a fixed GPS receiver on our radar arch. We like the simplicity of our current configuration, and adding more sophisticated and expensive electronics just to gain a better anchor drag alarm is overkill. I firmly believe in keeping things simple and minimizing the number of components that may fail.
I certainly did not undertake an exhaustive search of all the possible commercial devices available on the market today. "Why not?," you ask. There are several reasons but foremost is my preference to build rather than buy. There is great personal satisfaction in making something of my own design with my own hands. And the entrepreneur within clings to the notion that the next creation will be the killer application that everyone needs!
The purpose of this article is to document the process of building our standalone anchor alarm. From the initial concept to experimenting and prototyping through the final build, I'll describe how I created the device. Since the finished product is essentially just a little black box with some cute buttons, this article will also serve to remind me why that box's innards took five month's of evenings and weekends to build.
Perhaps the ideas, concepts, tools, or techniques may inspire other electronic hobbyists, tinkerers, and do-it-yourselfers to jump right in and create something.
My primary goal was to create a simple and reliable device that would wake us if Sea Gator dragged her anchor - that is if she moved - in the night. I envisioned a simple user-friendly interface requiring minimal instructions to operate and an audible alarm when the device moves beyond a specified distance.
The device should be portable so we can take it to the foredeck while anchoring to easily mark the position of the anchor, and place it on a nightstand in our stateroom afterward.
Simple geometry shows that marking the position of the anchor itself is far better than marking the position of the boat after anchoring, as some commercial applications do. You'll agree that it is simpler to determine the radius of the circle which represents the boat's swing around her anchor, than to determine an acceptable distance across and beyond that circle from a point on the circumference. The former approach also allows tighter tolerances and therefore more accuracy.
I want the device to show (1) the latitude and longitude position of the anchor and (2) the current position of the boat and (3) the distance between the two.
Number (3), the distance between the two, should equal the length of rode (that is anchor chain + line; let's say 100' for this example) plus 40 feet for the approximate length of Sea Gator (at night, the alarm would be near the stern in our aft stateroom) plus an additional 30 foot error factor for the customary 10 meter accuracy of the GPS. Totalling an alarm distance of 170 feet.
Ergo, the alarm should sound if the device's current position moves more than 170 feet from the position of the anchor.
By comparison, our handheld Garmin GPS does not graphically nor numerically show the anchor position nor does it show the distance between the anchor and current position, leaving us to depend upon the faith that we correctly marked the anchor position- which we lack.
I wanted the device to be self-contained so it would not rely on other hardware or software. This is important because if the external device fails or the instrument breaker powering an external GPS receiver is inadvertently turned off, our device would have no position data and would suddenly be useless.
It should have a flexible power supply using either batteries, 12VDC, or AC power with a transformer and the power requirements should be minimal. It should tolerate the loss of external power and run uninterrupted on its internal batteries. If all power is lost, the last anchor position should be preserved.
The device should also support an external antenna for better GPS satellite tracking and, last but not least, it should be inexpensive to build.
Listing the design goals is a great first step with any new project. But are the goals practical and attainable? I did not know and I had plenty to learn.
I earn my livelihood by designing and developing software. As a hobby I dabble in basic electronics. So I had some ideas about the required components.
I began by sketching an example of an anchor alarm appliance (see the sketch, above). My initial concept showed a device the size of a typical alarm clock with an LCD screen in front and control buttons on top.
I knew small LCD (liquid crystal display) screens were available in various dimensions. A four-line LCD with 20 characters per line would work. I found the LCD (photo, right) with a serial interface for $30. The first two lines would show the latitude and longitude of the current position and the anchor's original position. The third line would show the distance between the two positions in nautical miles. The fourth line would show the anchor alarm distance in nautical miles and the on/off state of the alarm.
Obviously, the anchor alarm would need GPS (global positioning system) position data. While I could use our existing fixed mounted GPS receiver or even the handheld unit for position data, doing so would require the anchor alarm to rely on an external component. And that would violate my design goal to create a self-contained device. I knew GPS chipsets were readily available so I searched the Internet and found the GPS receiver shown (photo, below right).
This EM-408 GPS module from USGlobalSat is based on the popular SiRF Star III chipset, which is used in many commercial GPS products including many of Garmin's offerings. The module has the following features:
The GPS receiver's small size, low power requirements, built-in antenna, and support for an external antenna made it a good candidate for the anchor alarm. At only $60, I purchased one to begin testing, knowing I wouldn't break the bank if it proved unsuitable.
Next, I listed what the anchor alarm device should do when it is powered on:
How will I instruct the device to accomplish all these tasks? By programming a microcontroller with appropriate instructions. Oh yes. The software instructions, or firmware, are embedded in the microcontroller.
To a guy who works with software daily and is a hardware novice, microcontrollers are fascinating devices (see a typical specimen, right). They are small and powerful - and inexpensive, costing only a few dollars each. I can design and develop firmware enabling the microcontroller to perform any number of tasks that not long ago would have required extensive discrete electronic components.
Here is a definition of a microcontroller from Wikipedia:
Although I have done only basic experimenting with microcontrollers, I knew that a microcontroller would be at the heart of the anchor alarm device. The microcontroller will receive position data from the GPS receiver and send screen data to the LCD. The microcontroller will also monitor the status of the device's buttons which will be used to mark the position of the anchor, increase and decrease the alarm distance, and turn the alarm on and off. I outlined the device's components with the block diagram, right.
As you can see in the diagram, the device will need a power supply which must provide both 5VDC and 3.3VDC. In addition to the GPS receiver and LCD, I'll also need EEPROM (electrically erasable programmable read-only memory) for non-volatile storage of settings such as the last anchor position and alarm distance.
I've also sketched in a FPU (floating point unit). I don't yet know whether the microcontroller software will require any floating point calculations or even whether the microcontroller is capable of such math. Dedicated FPUs are available for this task if necessary.
While programming professionally for over 25 years I accumulated many programmer's tools. Tools for programming PCs are normally specific to the underlying microprocessor. So, programming a Windows PC and an Apple PC require different tools. This also applies to various microcontrollers.
Most of my current tools are for programming Windows-based PCs. I'll need new tools for this project's microcontroller. But which specific microcontroller? I must first choose the device for this project.
My introduction to microcontrollers came last summer when I purchased an Arduino board for experimenting. The Arduino is an open-source electronics prototyping platform with its own IDE (integrated development environment). My Arduino uses an ATmega8 microcontroller, which is an 8-bit RISC (reduced instruction set computer) microcontroller in Atmel's AVR line.
There are many AVR 8-bit microcontrollers widely used by electronics hobbyists and professionals and there are a number of online support forums dedicated to AVR microcontrollers. The capabilities of these devices are impressive, so I decided to build my development environment for AVRs.
To create the firmware for the anchor alarm I need two tools. First, I need a development environment to write the software and convert it into instructions for a specific AVR microcontroller. Second, I need a hardware programmer to transfer the software to the AVR microcontroller.
To encourage developers to create products using their microcontrollers, Atmel offers a free IDE called AVR Studio, which supports the open source WinAVR suite of tools for AVR development. WinAVR includes compilers for the C and C++ programming languages, which are widely used with almost every programmable device from microcontrollers to mainframes.
I'll use the C language to create my firmware. For the hardware programmer, I purchased Atmel's AVR STK500 starter kit ($85), which is supported by AVR Studio. The STK500 (see picture, above right) interfaces with a PC running AVR Studio using a serial cable and it includes sockets to program 8-, 20-, 28-, and 40-pin AVR microcontrollers.
With my AVR tools in hand and a few AVR microcontrollers, I was ready to begin prototyping the anchor alarm.
A common practice when working with a new programming environment is to create a "Hello World" application, which simply writes "Hello, World!" on a display device. This effort helps to learn how to create a program with a new programming language or IDE.
In microcontroller programming, the closest thing to a Hello World program typically blinks an LED since most embedded projects do not have a display device. But I had an LCD so I began by developing routines to display text on the LCD.
Doing so requires using the microcontroller's USART (universal synchronous asynchronous receiver/transmitter) for serial communication with the LCD. Similar communication will be used with the GPS receiver.
There are important timing issues when using a USART so it is critical to choose a compatible clock source for the microcontroller. The clock source determines the speed at which the microcontroller runs. Many posts to AVR discussion forums involve problems with serial communications so I had already learned a great deal from others' mistakes.
Because I would be using two USARTs, one for the GPS receiver and one for the LCD, I chose a USART-friendly 7.3728 MHz external crystal as the clock source for the ATmega162 microcontroller I selected. The ATmega162 is capable of running at speeds up to 16 MHz but 7.3728 MHz should be more than sufficient for my tasks. The ATmega162's non-volatile memory includes 16K bytes of programmable flash and 512 bytes of EEPROM.
With my test code successfully displaying data on the LCD, my next task was to learn how to read and write to the chip's EEPROM. EEPROM is non-volatile memory that I will use to maintain device settings such as the last marked anchor position and alarm distance setting. I developed several general purpose procedures following examples I found online, which allow me to save and read EEPROM data any time my program needs these features.
So far I have made good progress programming the AVR microcontroller and I've created a good base of software that will be used in the final version of the anchor alarm.
My next task was to decipher the digital I/O (input/output) capabilities of the AVR. Specifically, I will connect the anchor alarm's user-interface pushbuttons to separate pins on the AVR microcontroller and create the necessary software to react to a button press.
In theory, it is quite simple. Push a button and the voltage on the microcontroller pin changes from low (ØVDC) to high (+5VDC) or vice versa. Your software need only periodically poll the button pins and detect the voltage change to know when a button has been pressed.
In practice, it turns out to be more complicated. When you press the button or flip a switch on or off, the mechanical switch contacts actually bounce on and off rapidly several times within a short period (around 5 to 30 milliseconds - a millisecond is one thousandth of a second) before settling on the open or closed state. Simply polling the switches for a change of state will yield unpredictable results. The solution is to use one of the microcontroller's hardware interrupts.
An interrupt is a signal from the microcontroller indicating the need for attention to an external event. There are interrupts for digital I/O lines and timer interrupts that can be set to run specific software called an interrupt handler.
I used a timer interrupt, which constantly interrupts our software at a specific time interval, and I wrote software to debounce the button state in the timer's interrupt handler. I used a timer interrupt of about 10 ms and polled the buttons each time in the interrupt handler. If the button state stayed the same for three interrupts or 30 ms then I accept it as the new button state.
Whew! If you followed that description you should consider a career as an embedded systems programmer. Email me.
With sufficient software routines in place to test it was time to start prototyping the hardware components.
The STK500 exposes the microcontroller's pins through headers making it simple to connect hardware. The STK500 also provides a +5VDC power supply, which I used to power a solderless breadboard.
I added four buttons to the breadboard which are connected to the microcontroller's I/O pins on the STK500.
The GPS receiver requires +3.3VDC so I added a voltage regulator IC and filtering capacitors to my breadboard. I also added a buzzer connected to an output pin.
Finally, I connected the LCD and GPS receiver to the separate power supplies on the breadboard and to the ATmega162's dual USARTs via the STK500 headers. I connected an external GPS antenna to the MMCX connector on the receiver. The photo, above right, shows my first prototype.
My next task was to obtain GPS position data from the GPS receiver. Before I connected the receiver to the breadboard as shown in the picture above, I first connected the receiver to the RS-232 (COM1) port on my laptop using a level converter to convert the receiver's TTL signals to RS-232. I then used the free SiRFDemo program running on my laptop to test the GPS receiver and capture several minutes of the receiver's output messages for inspection.
Satisfied that the receiver was working properly, I connected it to the breadboard and began writing software to capture position data with the microcontroller.
I already had serial communication routines using the USART of the ATmega162 chip, which I used to send data to the LCD. However, communication with the GPS receiver is bidirectional. I must send configuration commands to the receiver and read position data from the receiver. So, I had more code to write.
I enabled the interrupt that occurs when a character is received from the USART and I wrote an interrupt handler to add the character to a circular queue. An interrupt handler must be fast so its only task is to add received characters to the end of the queue. Other code will pull characters out of the front of the queue.
The SiRF Star III chipset used by the EM-408 GPS receiver supports a subset of the NMEA-0183 marine electronics standard as defined by the NMEA (National Marine Electronics Association). For position data, I initialized the receiver to use the NMEA protocol and communicate at 4800 baud, 8 data bits, no parity and one stop bit. I then request that the receiver send the GGA sentence once every second.
The NMEA standard defines a number of output sentences with time, position, course, and speed data. For the anchor alarm I only need position data so the GGA sentence has all I need.
Following is an example GGA sentence...
$GPGGA,161229.487,3723.2475,N,12158.3416,W,1,07,1.0,9.0,M, , , ,0000*18
...and a description of its format:
|Message ID||$GPGGA||GGA protocol header|
|N/S Indicator||N||N=north or S=south|
|E/W Indicator||W||E=east or W=west|
|Position Fix Indicator||1||0 = invalid, 1 = valid, 2 = differential|
|Satellites Used||07||Range 0 to 12|
|HDOP||1.0||Horizontal Dilution of Precision|
|Age of Diff. Corr.||second||Null fields when DGPS is not used|
|Diff. Ref. Station ID||0000|
|<CR> <LF>||End of message termination|
I added software to detect the <CR><LF> end of message characters and when they are encountered to check the message ID. If this is a GGA sentence and the position fix field indicates a valid fix, the software parses the latitude and longitude from the message and displays it on line one of the LCD. Later, I decided to display the UTC time and the number of satellites used on the LCD so I also parsed these fields from the message.
Earlier I described the button debouncing software I wrote to correctly detect a button press. Now I needed to write the code to actually do something when a button is pressed.
I added four buttons to the breadboard prototype.
Initially, I envisioned one button to turn the alarm on and off, another button to mark the position of the anchor, and two buttons to increase and decrease the alarm distance. I decided that it would be all too easy to inadvertently bump the anchor mark button and lose the current position of the anchor. I pictured myself rowing the dinghy out to the approximate location of the anchor to mark its position again. To avoid that scenario, I decided that pressing the two distance set buttons simultaneously could be used to mark the anchor position. That freed up one of my buttons which I used to set the backlight brightness of the LCD.
The image at right shows the button configuration on the finished anchor alarm:
Right, this picture shows the LCD screen of the finished anchor alarm:
With the buttons identified and the LCD screen layout complete I can move along and write even more software. I still need to calculate and display the distance between the current position and the anchor's position. The NMEA data provides latitude and longitude in degrees and minutes. The first step is to convert to decimal degrees:
To convert DDD MM.MMM to DDD.DDDD:
Now, with latitude (Y-axis) and longitude (X-axis) of both positions in decimal degrees I calculate the distance between two points on a plane:
The formula to calculate the real distance between two points on a geode is more complicated, but let's not worry about the curvature of the Earth between our two positions. So using plane geometry is adequate and simpler. Finally, I convert the distance in decimal degrees back to degrees and minutes and display the distance in minutes (i.e. nautical miles):
To convert DDD.DDDD to DDD MM.MMM:
With the distance calculations complete I can now assemble the complete firmware for the ATmega162. When the device's power is turned on the software begins by initializing the LCD, displaying a splash screen (version number and www.boathooked.com) and initializing the GPS receiver. Next, it retrieves the last anchor position, current alarm distance setting and last LCD backlight setting from non-volatile EEPROM and updates the LCD screen.
The software now enters its main processing loop where it will run until the device is powered off:
The main processing loop now checks for a completed NMEA sentence from the GPS receiver. If a GGA sentence is complete, the latitude, longitude, fix status, UTC time, and number of satellites is parsed from the sentence. If it is a valid fix and the horizontal dilution of precision (a measure of the quality of the fix) is within acceptable limits, the position is displayed on the LCD, the distance to the anchor is calculated and displayed, and the UTC time and number of satellites are displayed. If the calculated distance exceeds the alarm distance, the alarm buzzer is sounded.
Earlier I said that I was fascinated with microcontrollers. Now, I am also amazed at the power these little devices offer. After completing all of the required software described above, I only used half of the 16K bytes of flash RAM on the chip and I did not need a separate floating point unit.
Up to this point, my first prototype's breadboard has been tethered to the STK500 relying on its 5VDC power supply and its headers, which expose the I/O pins on the microcontroller. The ATmega162 and its crystal oscillator also reside in sockets on the STK500 where I have been updating and testing my software using AVR Studio.
My next task was to move everything to a single breadboard, which would serve as a true prototype for the final circuit board.
One of my original design goals was to support flexible power sources. I wanted the device to operate with its own internal batteries so we could hang it over our bow flag while anchoring. When the unit is brought inside I wanted to plug it into one of the 12VDC wall outlets available throughout Sea Gator. Since we don't use an inverter, we only have 110VAC power at anchor while running our generator. Nevertheless, I wanted to support 110VAC power sources. An inexpensive transformer (i.e. wall wart) can be used in this case.
Next, I calculated the power requirements of the anchor alarm's components (LCD, GPS, microcontroller, etc.) and estimated that a single 9V battery could only power the device for 30 to 60 minutes if the LCD's backlight was on its brightest setting. Not wanting to feed the device a steady supply of batteries, I decided to use a 9V rechargeable battery and add the necessary circuitry to recharge the internal battery when connected to external power.
I added the power supply circuitry to the new breadboard first. I used two voltage regulator ICs to obtain both 5 and 3.3 volts from the 9V rechargeable or any 7-24 VDC external power source. Consequently, if the external power is lost, power is supplied from the 9V battery without interruption so we can simply unplug and take it to the foredeck when anchoring.
The picture above shows my second breadboard prototype.
You see that I added the ATmega162 to the breadboard along with the crystal and the buzzer then I connected the LCD and EM-408 GPS board. I connected the microcontroller's digital I/O pins to a polarized male header that will be used to connect the buttons on the anchor alarm cover plate (see below).
One of the remarkable features of the AVR and many other microcontrollers is the ability to program and reprogram the chip while it is embedded in a device. This ISP (In-System Programming) feature means I can make any necessary changes to the anchor alarm's firmware and reprogram the device in a matter of minutes. A single 6-pin connector is all that is required to connect an AVR hardware programmer to the circuit to reprogram. I added the ISP connector to the breadboard above.
The STK500 includes an ISP connector to program target systems. I certainly want the ability to update the anchor alarm's firmware while we are cruising on Sea Gator but the STK500 is a bit large for my briefcase. I purchased Atmel's AVRISP mkII programmer (above right) for $35. This tiny programmer connects to my laptop with a USB cable and it is supported by the AVR Studio software so reprogramming the anchor alarm is a breeze. It's comforting to know I can change the anchor alarm's firmware at any time without removing and reinserting the microcontroller.
With my breadboard prototype working properly it was time to begin building the final anchor alarm.
First, I needed to select a project enclosure. I had been periodically reviewing the multitude of options available in the DigiKey catalog. But I found the endless options overwhelming and a hindrance to selection. I returned to my local Radio Shack and selected a 6x3x2" plastic project box.
I cut an opening in the box's lid for the LCD and I used epoxy to add nylon standoffs to secure the LCD to the lid. Next, I added the buttons (momentary switches) and female connector to the lid and a label with graphics to identify the button functions. I prefer nice tactile momentary switches but I had these other switches in my parts bin and they get the job done.
While I wanted to create a custom PCB (printed circuit board) for this project (as I had for the Water Level Gauge), I was running out of time. I decided to build the circuit board using stripboard. Given that the anchor alarm is a prototype and a proof of concept this seemed wise. If the prototype is a success, later I will use the EAGLE Layout Editor to design the PCB then send the design out to a professional board manufacturing service.
I first cut a piece of stripboard to fit the project enclosure, cutting notches around the lid standoffs. I used epoxy to secure nylon standoffs to the box and added holes to fasten the board.
Next, I transferred the complete circuit from the breadboard to the stripboard adding connectors for the external power, internal battery, LCD, GPS, buttons, and buzzer. I added a 40-pin DIP socket for the microcontroller instead of soldering it directly to the board. With ISP I can change the firmware at any time but the socket is a backup should I ever need to replace the microcontroller.
You will notice a hefty heatsink on the left of the finished board, shown above left. We expect to have the anchor alarm active long before we enter an anchorage to ensure it has acquired the GPS satellite signals. I calculated the main voltage regulator IC may need to dissipate over two watts if the external power supply exceeds 14 volts, which is likely as we approach an anchorage with engine alternator output active. The datasheet for the main voltage regulator shows that two watts exceeds its internal power dissipating capability so I added an external heatsink.
With my circuit board complete, I returned to the project box and cut holes, then installed an on/off switch, buzzer, external DC power jack, and GPS antenna connector. I used the lid of a salt shaker to mark hole patterns in the back and top that I drilled for ventilation.
I added a 9V battery clip to hold the internal rechargeable battery, then I inserted the ATmega162 in its socket then fastened the circuit board in the box. I attached the LCD to the box lid and connected it and the buttons to the circuit board. You can see the inside of the box in the picture, above. Only the GPS and its antenna remain unconnected. I connected these just prior to installing the box lid.
Finally, I added an aluminum handle that will also be used to slip the device over our bow flag during anchoring so we can accurately mark the position of the anchor without risk of the device (and the five months of work it represents) disappearing into Davy Jones' locker.
Right, see the finished anchor alarm complete with handle.
The on/off switch and buzzer are located on the top of the alarm.
Connections for external power and GPS antenna are found on the back, photo below left.
O.K. Now that I've built this thing, will it work?
The first field trial occurred in Wyoming. Stepping outside, I turned on the anchor alarm and after the satellites were successfully acquired I marked the position of our porch as the anchor.
Next, I set an anchor alarm distance of 0.020 nautical miles (120 feet) and turned the alarm feature on. Carrying the alarm, I began walking across our pasture until the alarm went off.
Pat repeated the test with similar results. We could see the calculated distance between the "anchor" and our current position updated every second on the LCD. As soon as that distance reached or exceeded the set alarm distance the audible alarm sounded continuously.
About a month after the Wyoming field trial I turned on the anchor alarm while Sea Gator was docked at La Marina in Florida. I immediately noticed two features I programmed but had since forgotten about:
First, the calculated distance between the current position and anchor showed OVFLW on the LCD, which is an abbreviation for "overflow." This was as I designed (apparently), since the distance between my Wyoming office and La Marina exceeds 9.999 nautical miles, which is the maximum distance the anchor alarm will display.
Next, I noticed the number of satellites displayed was preceded by a "W". I had included this feature to identify when the WAAS (Wide Area Augmentation System) was in use for the last fix. WAAS uses a network of ground-based reference stations to monitor the GPS satellites and send correction data back to the satellites for broadcast. A WAAS-enabled GPS receiver can use the correction data when calculating position data to significantly improve accuracy. I had enabled the WAAS feature of the SiRF Star III chipset in the EM-408 GPS module but this was the first time I had a fix that used WAAS. It feels good to know that the satellite data the GPS is receiving is as good as it gets.
A few weeks later, upon the occasion of our first anchorage of the season, I brought the anchor alarm to the upper helm station. We were several miles out from our destination so we had time to experiment. Pat wondered aloud, what onerous task would she have to add to her anchoring duties? I showed her how to simply push the UP and DOWN distance buttons simultaneously to mark the anchor position. Three quick audible beeps would confirm the position had been marked.
Tinkering with the device, she marked a trial position. I activated the alarm and it immediately sounded since we were underway and we had quickly surpassed the previously set alarm distance. After inactivating the alarm we watched the distance continually increment showing over three nautical miles, before we neared the anchorage and turned our attention to piloting duties. When we arrived at our chosen spot, Pat hung the device over the bow flag's mast and just before lowering the anchor she marked the position. BeepBeepBeep! Simple enough.
See Pat's perspective of the operation in Sea Gator's travelogue In Our Own Backyard.
After we were securely anchored (anchor secure, rode played out, kellet and chafing lines secured, everything ship-shape), I brought the alarm to our stateroom where I positioned the GPS antenna on top of our ceiling hatch's screen, bundling the extra length of wire on the handle (photo, right). I set the alarm distance and enabled the alarm.
In Wyoming with the antenna on my office window sill, I rarely saw more than five or six satellites used for a fix. Perhaps that explains why the distance between anchor and current position fluctuated wildly with the device completely stationary on my desk. I envisioned adding running averages over some period of time to minimize the variations. But at anchor in Florida, I consistently see 9-12 satellites with WAAS and very little variation in distance.
Yippee! It works.
As I write this, we've been anchored now for five days and the anchor alarm has worked flawlessly. It shows good satellite reception with the WAAS accuracy bonus and we've noticed distance variations of 0.001 to 0.004 nautical miles (6 to 24 feet). That's plenty accurate for our needs. I let out more rode ahead of expected winds and simply bumped up the alarm distance to accommodate the larger radius. Through 15 to 20 knot winds, I was reassured that I would have an immediate warning if we began to drag our anchor. As the sun went down and the wind kicked up, we could rest relatively easy.
While I am thrilled with Sea Gator's newest safety feature, I've already noted a few ideas for improvement:
Now that I've gone through all of this effort, I fully expect an astute reader to point out how the functions of our anchor alarm are easily provided by an off-the-shelf product.
That's o.k. As I said earlier, this project was more about learning something new and creating something that didn't already exist than it was about comparing the myriad commercial solutions currently available. But feel free to pass on your solution to the anchor drag problem. Use the email link on the Contact Us page to send me your comments.
Of course, the obvious solution is to not drag an anchor in the first place so we should all review our ground tackle and anchoring techniques to avoid the problem. The anchor alarm is just insurance to help us recover from such an episode.
The anchor alarm proved worthy, and therefore worthy of modifications and improvements. See Rick's February 2009 article Anchor Alarm - The Sequel for an update.
In response to popular demand, a limited number of anchor alarms are now available for purchase at Rick's cost for materials + users' feedback and comments. See Anchor Alarm - Purchase Information for details.
The Portable Anchor Alarm User's Guide (PDF 400 KB) has detailed operating instructions and specifications.
In response to popular demand a limited number of Rick's portable GPS-based anchor alarms are now available.
See Anchor Alarm - Purchase Information for details.