The Bench

The Vysion displays are up and running on a few boats now, and all who have used them are quite happy. They are highly visible, can be almost infinitely customized, and have several features not found on any other display.

We now have a demo program available that can be run on any PC. It requires a source of Ockam data to run properly. If you have the OckamSoft 4.07 driver installed on the PC, you can place it in simulator mode, and the Vysion program will read the data. It can also read live data that is pitched over UDP broadcast from an Ockam system (like from a 051L LANBridge or the OckamSoft driver).

The demo program requires registration, which uses the usual Ockam unlock key exchange. The operating time is limited, but is variable and determined by us when the registration key is issued. Typical allowances have been in the range of 2 weeks.

Write to me, Dan Chesson, at the "repairs" email address to obtain a link to download the demo application.

Comments (0)

So what’s new here at Ockam? A few things…

First, the new Vysion system has now been installed on a few boats. We’ve encountered some growing pains with these, but that’s the price to pay for bleeding-edge technology! We continue to improve the system, and all involved seem to be pretty happy with the results. I’ve even heard from other boats racing against the boats with the Vysion displays, and all remarks have been very positive. One person remarked that he could easily read the Vysion display on the boat… from another boat over 100 feet astern in direct sunlight! There’s even an example program that simulates the Vysion output that you can install here (please use Internet Explorer for this link) or download a zip file here for later use.

We continue to refine the DeWiggler program. There are many refinements for the program now. One major refinement is that there are many "flavors" of DeWiggler available. There is the original Analyst version, which requires collection of data to be sent to Ockam for analysis and report generation. This can produce corrections for compass, boat speed, and wind inputs. There is a sub-version of analyst that produces reports for just compass and boat speed, the test for which can be done under motor (no crew required). There is also an "instant gratification" version avaialble: DeWiggler Realtime. This version can produce corrections for all the same things as the Analyst version, except for Upwash Slope. These corrections are available immediately after running the tests. There is no human to judge the validity of data, so this test may not produce as good results as the Analyst version, but it is still much improved over the initial results that one can expect from a regular human-only calibration. Finally, there is now a tack analysis program available. This program analyzes the boat’s performance during tacks, and allows the crew to determine areas of inadequacy that might be addressed to improve racing performance.

Our 051L LANBridge continues to gain momentum. There are now several boats with this interface installed. Data input to a PC is much simpler, and now multiple computers can read the instrument data without the hassle of a distributing multiplexer! We have also been involved in some very advanced (for a boat) network architecture, and have created a telemetry system using a 051L LANBridge with some additional hardware. Can hacking another boat’s instrument system be too far off?

We are working on an updated version of the venerable 001 CPU. We were forced to twilight production of the popular CPU after many years of production due to difficulty in obtaining parts in reasonable quantities. Initially, we believed that the T1 CPU would adequately address demand for an Ockam system, as the T1 has easily outsold the 001 since its introduction. However, there is still the cadre of older boats with the 001 system that need support, and now many sport boats are looking for the performance of an Ockam system without the processing features of the T1. We are currently developing the new CPU, and are hopeful for a spring 2010 release.

We would love to hear from you if you have any questions or comments regarding these new developments… drop us a line!

Comments (0)

The story of one boat having calibration problems was recently relayed to us. The crew was having difficulty obtaining reasonable numbers from their instrument system, so they began to "calibrate" the instruments. I used quotes because what they were doing was not actually calibration, but fiddling and guessing. After a race or practice, they would talk over the numbers they saw while sailing, and then adjust the instrument according to what they thought they should be. They were getting frustrated because the instruments would constantly show inconsistent numbers, and needed adjustment after every race. The instruments became worse than useless - they became unnecessary weight and a source of frustration and distraction.

There have also been cases where we have been told that the instruments must be wrong, since the driver knew he could go faster than that or the boat couldn’t possibly sail like it did in the conditions indicated by the instruments. After much discussion where we made the case that the instruments need to be calibrated correctly, the crew went ahead and adjusted the calibrations to reflect what they thought were the correct calibrations. This of course created false data which in turn led to bad decisions, and many poor finishes. If I recall correctly, it also led to one boat being sold in frustration. The new owner of said boat calibrated the instruments correctly, and was very happy with the results.

The hazards of engaging in this behavior should be obvious. Anyone trained in science can tell you that forcing the data to fit your own perception or assumption leads to incorrect conclusions. Pilots are very familiar with this - there have been many documented crashes where the pilot chose to follow perception rather than hard instrument data and pranged the aircraft (often with fatalities). A well-calibrated instrument system may sometimes give odd figures, but these may be indications of conditions that can give an advantage when recognized, such as wind shear.

The numbers used for calibration should not be created by guessing or by the T-LAR method (that looks about right). We have a well-established routine for calculating the calibration numbers. The Ockam System Manual contains a detailed step-by-step process for manually calibrating the instruments. It even has work sheets that guide the user through the whole process - what I call the "plug and chug" method. The numbers are plugged into the various formulae, and the then the answers are chugged out. However, some people are simply frightened by math, and avoid doing this. I think this is a bit ridiculous, since the math used is no more advanced than what you might use to balance your check book.

Some people insist on using a professional calibrator, but their services are not necessary to produce good calibrations. A dedicated amateur can produce results as good as a professional. The difficulty in using professional calibrators is that they are hard to find and difficult to schedule. They also tend to charge for their services and expenses. In my opinion, only the largest or most specialized boats really benefit from their services. Some calibrators are also professional sailors, so it may be possible to get a "two-fer" when hiring one, and have them sail in an important regatta. Not everyone can afford to do this, though.

The DeWiggler program can also produce excellent calibration data. I’ve written previously about what DeWiggler can do, and some of the information we’ve gleaned from the results. DeWiggler is probably the least intensive method of running the calibrations. The computer program is set up and run, and it guides the user through the entire calibration process. Depending on the version used (Realtime vs. Analyst), results may be available immediately, or in a few weeks. Not every boat has a computer available to run the DeWiggler program, but those that have run the program have been extremely happy with the results.

Even with good calibration, it is possible to fudge the numbers to produce the desired result. One top-level sailor would adjust the polar data weight during practices so he wouldn’t have to push the boat (and himself) every day sailing. He would make it appear as if they were always hitting or exceeding the performance numbers by de-rating the polar data (i.e., the boat did not have to go as fast to reach the theoretical speed). It didn’t really matter in the end, as he and his crew did quite well. However, anyone of lesser talent would have just been cheating themselves by not measuring performance honestly. How can you improve your performance if you don’t know what you’re doing wrong?

An excellent white paper has already been written on the politics of calibration, and is available on our web site. It discusses the types of personalities encountered on boats with problematic calibrations, and has suggestions on improving the situation.

Comments (0)

We’re entering the second year of public release of DeWiggler, and there is now enough data to make some general conclusions. Probably the single most important conclusion gleaned from the data analysis concerns the compass.

The first half of the DeWiggler tests calibrate the boat speed (V_s) and compass heading (M_s), so it is referred to as the V_sM_s test or "viz-miz." This test only requires motoring around in a pre-defined pattern (no sails), so it has been performed more than the other half. This test also has the greatest initial effect on the operation of the instrument system. That is, only if the apparent wind calibrations aren’t too far off. Using previously valid or the default wind settings are usually a good start.

From the data gathered, the median value of existing compass peak-to-peak deviations was 6 degrees. The interesting discovery was that on compasses with deviations above the median, no amount of compensation would sufficiently remove the error. The error was thus due to the installation area, and not the lack of automatic compensation. To correct the problem on these compasses, it is necessary to move the compass location to eliminate the source of error, and then re-run the automatic compensation.

For instance, one boat had horrible deviation values, and no amount of compensation was removing that error. The compass was moved, and the compensation improved immediately. The owner spoke to the builder and designer, and found out that steel reinforcements had been embedded in the fiberglass under the original location of the compass! There was no external evidence of this to alert the installer, so the only way to really discover this was by examining the quality of data from the compass with DeWiggler.

An aside on installing compasses: I find that using a hand-bearing compass to scout installation locations works pretty well. By moving the compass in and out of the proposed installation area, you can see the deflection caused by any ferrous materials in the area. If the compass needle moves a lot, that is probably not a good location.

It is important to remove as much deviation as possible, as any compass deviation is completely carried into the wind direction figure calculated by the instrument system. That means that 10 degrees of deviation will create a 10 degrees error in the wind direction.

For the complete analysis of the first season’s DeWiggler results, see the document at http://www.ockam.com/dewiggler/DeWigglerReport.pdf

We have also thought about how DeWiggler is used. There are likely to be some refinements in the coming months, especially in regards to changing calibrations before a race. It’s been well-noted that racers get really nervous about changing things just before a big regatta, so some changes in DeWiggler will be made to reduce the jitters caused by changing the calibrations. Also as previously mentioned, the V_sM_s test is by far the easiest portion of the DeWiggler test suite to perform. There is now separate pricing to run only the V_sM_s test.

Comments (0)

I realize I have been remiss in not discussing our newest software product here: DeWiggler! "What is DeWiggler?", you ask. It’s just about the biggest break-through ever in automated calibration! It removes the tack-to-tack difference, or "wiggle", in calculated wind direction. It does this by providing very accurate calibration values for the parameters upon which wind direction is dependent.

Calibration has traditionally been done manually, with a human noting and calculating the numbers. This takes a bit of artistry to determine what is good data and what is bad data. Sometimes it’s obvious, like when there is too much or too little wind or the waves are too high. Other times, it’s a bit more difficult, like when there is a lot of wind shear throwing off the tack-to-tack wind angles. Most people can do the boatspeed and compass calibration reasonably well, but sometimes the wind calibrations take more than one try to get a good value. This of course can make life difficult, because getting everyone’s schedule together to go out for a calibration run can be pretty impossible. Add the variable weather conditions to this problem, and a racing program might not find the time to do all the calibrations. And it’s nigh impossible to calibrate during races, because everyone is focused on other duties.

Older methods of automated calibration were not much better. They still had the scheduling problems of manual calibration, and they relied on a person to initiate and end the calibration run - this required that the person operating it knew when to begin and end (it’s not always obvious).

DeWiggler solves a lot of these problems. While running, it guides the user through the process rather than relying on the user to guide the program. It tells the helmsman what course to steer, how much distance is left on the leg, and how long to stay on a tack when sailing. Best of all, it can remain running during a race to collect data, so that there are as many data points as possible for the largest sample size!

There are two main parts to DeWiggler: the boatspeed & compass calibration, and the wind calibration. The first part is best accomplished under motor, as it requires that the boat is steered to specific courses over a specific distance. It checks the direct boatspeed and compass readings against GPS data, subtracts the effect of current, and produces a compass offset and boatspeed calibration correction. On the T1 processor, a file can simply be copied to the CF card for the complete compass offset correction.

The second part calculates the wind calibrations. The best part of this is that if the program is left running during a race, it will monitor the wind readings for the entire race, throw out the bad data (like that collected during the pre-start), and produce calibration values from that data. This even allows enough data to be collected to compute a good upwash slope value - something that is typically pretty hard to do manually! It also can analyze tacking performance.

When calibrations were done manually, it was considered a good calibration if the wind direction solution only had a tack-to-tack error of less than 5 degrees, with 3 degrees or less being ideal. For those boats that have completed the DeWiggler calibration, tack-to-tack errors have been consistently less than 1 degree on the first try! This was considered a very difficult proposition when calibrating manually, but it has become the expected norm with DeWiggler.

DeWiggler also can assist with setting the correct calibrations. It can determine the current calibration values set in the system, determine if the screw settings are correct (and if they match the current settings), and then guide the user to set the screw values to the newly calculated values. It really makes the calibration process as painless as possible.

The program is free to download, install, and run. The user is charged only when an analysis of the data is done. The analysis can be purchase through our web store, a servicing dealer, or direct from Ockam. Please see our DeWiggler web page (also linked from the main Ockam page) for more information.

Comments (0)

Ever hear someone talking about hitting their targets at the post-race party, and wonder why they were shooting at people? They’re not trying to shoot the competition, they’re just using polar plots of the boat’s performance to judge how they are performing against the boat’s potential in the conditions.

Many people are familiar with polars as the table and graph documents that detail the boat’s performance in a variety of wind speeds at wind angles from dead downwind all the way up to in irons (at least the good polars cover this range). It’s not very convenient to whip out some sheets of paper while racing, so the better instrument systems (Ockam included) can compute and display polar performance information on the fly. This may seem like overkill to win a race, but all the best racing programs use polars. To paraphrase a recent sailing forum post: "How do you recognize people who use polars? They’re standing up front with the trophy in their hand."

I’ll not go into the nitty-gritty details of plotting polars - that’s covered pretty well elsewhere. However, there are a few important details that are worth noting.

First, everyone should be aware that polars use true wind angles and speeds. This is what the boat "sees" as the basis for its speed, as true wind is independent of the boat’s motion through the water (unlike apparent).

Almost all polar sets, or at least the initial model runs, assume optimal conditions. This means that there is no accommodation for bad sails, bad trim, bad driving, bad weather, or bad luck. If you have old sails, it should be pretty obvious that you will not be reaching your polar targets. For those people inexperienced with the use of polars, it may not be as obvious that bad weather will also prevent you from reaching your polar targets. If you have to reef, or if you are pounding through waves, the boat will not be driving to its potential speed for the given wind speed.

A boat isn’t precluded from having more than one polar file. Many high-end programs will have the initial prediction file from the designer as a basis for starting measurement, and then also build a file from observed performance. One aside: building a polar file from observed performance can be difficult since it’s hard to winnow out bad data. Performance analysis is typically done off the boat much after the race, so it can be hard to determine when the boat is responsible for a particular data point, or if an external factor is at work (e.g., bad helming, collision avoidance, weather, etc.). A good alternative polar file built from observed data can provide a way to compensate for weather and sea state. It takes a lot of concerted effort by the person doing the analysis and a large data set in a wide range of environmental conditions to provide a good foundation for analysis. Some boats also have multiple rig or sail configurations that strongly affect performance, and require separate polar files for different configurations. The Ockam system has always allowed for the use of several polar files. On the 001 CPU with 037 Performance Index, there was a hardware switch to set the desired polar file. On the T1 CPU, the polar file can be selected with a software command.

Another detail that should be obvious, but really isn’t: you need good instruments to use polars effectively. Your instruments must measure the boat and its environment accurately and precisely to give you a good idea of the actual performance. This means that you must have instruments with reproducible results, and must have any measurement errors corrected (i.e, calibrate the instruments). The more astute reader will have realized that since true wind is the basis for polar performance, then good calibration of the instrument system is a must. Some instrument systems have no capability for calibration, and are completely unsuitable for using polars. Imagine driving a car with a speedometer that worked differently each time you drove - bad instruments are like that. It’s pretty impossible to know how well you’re doing from day to day if you don’t have reproducible results.

It may not be completely obvious, but GPS-based SOG should NOT be substituted for speed through the water! "Why?" you ask… SOG does not take into account any current. Those of you who have sailed in foul current (such as The Race in Long Island Sound) know how frustrating it is to trim the sails perfectly in good wind, only to make 1.0 knot headway over the ground. Now imagine if your polar performance was based off SOG. Assuming you have decent wind speed and a good point of sail, the polar performance would show you making some paltry low percentage of your expected performance! There would be much gnashing of teeth, since it seems like you’re doing everything correctly and not making any speed. However, if you use speed through the water, it will at least show that you are making the best speed through the water possible for the wind conditions. The Race is an extreme example, but it illustrates the point that current can significantly affect your speed over ground, thus rendering SOG a poor indicator of performance.

Resolving wind speed and angle to predicted performance can be a problem if you have a very coarsely granulated polar file. In the past, the Ockam system required very strict data ranges to provide polar information through the 037 Performance Index. Wind angles had to be provided from dead downwind (180 degrees), all the way up to extreme pinching (ideally around 15 degrees) in 2 degree increments. Winds speeds were provided from 0 to 25 knots in 0.5 knot increments. These rather strict requirements were due to the limited processing power of electronics back then. Remember when 33 MHz processors with 16-bit busses were the leading edge for PCs? More powerful processors have opened the door to better functionality; the more powerful processor in the Ockam T1 has loosened the requirements for the polar files. It can interpolate values with far less data points than before. However, the polar file shouldn’t be too sparse on data points if any sort of accuracy is desired. Data points every 10 degrees and 5 knots are a good minimum standard for the T1 processor, but higher data resolution is always better. Areas of the performance plot that have large changes in a small region should have data point higher resolution to capture the predictions accurately.

For most instances of simple performance comparisons, polar plots that cover the range from close-hauled to dead down wind will suffice. When using VMC sailing and Wally, having more information past close-hauled becomes important. VMC sailing becomes especially important when going to a mark that is not directly in line with the wind (typically some sort of distance race). It becomes even more important if the wind is shifting over time, such as is found in almost every distance race. The performance information for the region above close-hauled allows computation of the possible VMC benefit of sailing both above and below the rhumbline. This allows comparison of the distance advantages between sailing on a conventional rhumbline course and sailing off the rhumbline (either above or below) at the fastest VMC speed. Without the data above close-hauled, possible advantageous sailing is eliminated from the calculus of the fastest route! That would be like only allowing your trimmers to adjust sails while on only one tack, and hobble you from your possible best performance.

Sailing with polar performance comparison can induce a lot of headache, and has a pretty steep learning curve. Many people simply don’t have the time to fully comprehend all the nuances of using the performance analysis with their instrument systems. However, many of the more common functions can be easily incorporated into the tactician’s tool kit with a little study and practice.

Comments (0)

For those of you out there that use Expedition to fulfill your racing software needs, there is an update available that addresses a funny bug when communicating to the Ockam system (especially T1 processors). It seems that during the background housekeeping that goes on during a graceful software shutdown, Expedition can send commands that set all the calibrations to 0.00, causing some math headaches (multiplication by zero, for instance) when the system runs without Expedition. This usually manifests as ridiculously high windspeeds, or absurdly low boat speeds. A reset of the T1 processor returns the system to normal operation.

We believe that this problem only affected Expedition installs newer than v5.1, but if you are experiencing these symptoms, try updating your Expedition installation to resolve the issue, especially if you are using AutoCal tables in Expedition. I have personally only spoken with four separate boats having this issue, so I do not believe the problem to be widespread. As usual, only the earlier adopters felt the growing pains.

Many thanks to Nick White for his quick and capable resolution for Expedition!

Comments (0)

Did you ever notice how some boats seem to have strange instrument readings only in certain conditions? Like having boatspeed be off by a half knot only when going between 4 and 6 knots, or the wind readings being off only at certain apparent wind angles? A lot of times, the instruments are actually working correctly, but the peculiarities of the boat’s shape moving through a fluid (either water or air) affect the motion of that fluid, and produce unavoidable local transitory effects on the sensors. These local effects then give rise to the anomalous instrument readings.

So how do you compensate for these local transitory effects? Short of redesigning the boat or moving the sensors, you can use AutoCal tables. AutoCal tables produce correction factors for an instrument reading in certain ranges. For instance, the 0.5 knot error between 4 and 6 knots could be removed by using an AutoCal table.

An important thing to note is that AutoCals should be used as an adjunct to good calibration, not a replacement! The base calibrations should be refined to the point where it is nearly impossible to remove additional errors before resorting to AutoCal tables. AutoCals were developed in response to the need by high-end racing yachts to remove that last bit of error from the calibrations to produce the best instrument readings possible. Keep in mind that many of these programs have one or more people devoted entirely to keeping the electronics in superb operating conditions, so they often reach the limits of the base calibrations.

In days of yore, the AutoCals were done externally to the system processor by an attached PC. The PC would run a piece of software (like OckamSoft) that looked at the instrument readings, and then send a correction factor when warranted. This of course introduces another potential point of failure in the instrument system, which tends to make it a bit more delicate - not something that’s particularly desirable on a boat. With the introduction of the T1 Tryad processor, it became possible to run AutoCal tables internal to the processor and eliminate the need for the external PC sending correction factors. The AutoCal tables are stored on the internal CompactFlash memory card, along with other system information. The only problem with this is that it is difficult to change AutoCals on the fly, as the system needs to be shut off to remove the CompactFlash for file transfer. Another thing to note is that the external PC is still required. It’s best to test and qualify the AutoCal tables using the external PC before moving the AutoCal tables to the T1’s internal CompactFlash memory card.

However, many of the high-end programs demand quicker and easier changes to the AutoCal tables, so we’ve developed a quicker method. This new method allows you to create an AutoCal table and download it directly to the internal memory on the T1, without the need to turn off the system and remove the ComapctFlash! For the end user, this new "live edit" method uses an Excel spreadsheet with a line graph to visually build an AutoCal table. There’s also an API for use by other navigational programs to incorporate this flexibility into their own structure - there will probably be at least one program incorporating this feature in the near future. You can download the end user utility here. Note that this live edit capability requires an update to the T1 firmware to operate correctly.

We also have a "Robocal" program that’s been sitting quietly waiting for a nibble. It helps you determine the correct base calibration for your instrument system using a PC connected to the Ockam data stream. If anyone is interested, write me at dan@ockam.com and I’ll send you a copy to try.

Comments (0)