The Hawaiian ZigZag race is a personal favorite for me.  It’s a long sprint through warm waters that bring back great memories.  This year, I was excited to test the Delay Command Checker software (DCC) during the race.

The DCC software surprised me both by how easy it was to use and by how many useful or time-saving features it offered.  DCC fit right in with my routing software.  That said, it would work well [perhaps providing even more benefits] for SOTP skippers

Starting out, I filled out this form.

Immediately, DCC created

1) polar files for both QT and Expedition.
2) a ‘gpx’ file of the course that I could import into either QT or Expedition.
3) the latest grib file for the race.

Getting all of this with one click is a huge reduction in my pre-race effort compared to the prep required without DCC.

But that ‘one click’ won’t work
— if you don’t have this page filled out correctly
— if you aren’t registered in the race
or
—  if you aren’t connected to the internet.
Kipper includes a well-written user guide with the DCC software download.  It will be worth your time to read it.

Before the Start

The wind shadows caused by high volcanoes on Hawaii, Maui, and Kaui are easy to recognize by the blue wind arrows to the west of those islands.

What isn’t as easy to see is what happens on the east side of these islands.

The volcanoes act like mid-channel rocks in a fast flowing stream.  The “Trades” slow down as they approach the obstructions.  They dam up and flow around, and often over, the volcanoes.
This produces swirls and eddies.  Even with a 0.5º  resolution GRIB  we still see the effects of this turbulence.

But that’s OK.  This is something for the router to puzzle through.

The Initial Routing

A common belief is that routers take the fun part out of sailing. You just route, and then mechanically translate what the router recommends into  delayed commands (DCs).

That certainly isn’t my experience.

Rather, when you get the router’s first recommendation, the fun is just starting.  You have to translate a route that can’t be sailed (well, not sailed quickly anyway) into a set of DCs that will keep you competitive.
The first leg of this year’s ZigZag proved no exception.

Exped recommended a route with two tacks to the first mark — this over a simpler one-tack route. Given the variability in both TWS and TWD forecast in the GRIB, I was willing to go with Exped’s recommendation.

But all Exped gave me was the shape of the route, not the details.  Exped shamelessly cut the corners on both tacks.  This presents two problems:

1. Since the ‘corners’ are fuzzy, it isn’t clear exactly where to tack.
2. From experience, I know that once Exped cuts a corner, the timing of subsequent routing segments is suspect.

In the past, that meant I needed to hand sail most of the beat toward the first mark.  But Kipper’s Delayed Command Checker (DCC) software was giving me another option in this race.

The DCC path

This is the graphic that DCC generated for javakeda.

And here is what I had to do to make that happen:

1. I used Kroppyer’s SPINNACER software to decide what TWA I would use for max VMG when on a beat.
2. I entered DCs for the first two legs of the beat using the max VMG TWA.
3. For the third leg, I entered an initial DC at max VMG, but modified that twice en-route to reflect changes in TWS and TWD. Exped was recommending a course at the mark that was a close-reach — a few degrees off of a max VMG beat.
4. Then I tinkered with the timing of the tacks to make the path come close to the mark.
5. Finally, I tweaked the two course adjustment DCs and the rounding DC to fine-tune the course.

Steps 1-4 took place in the time between the WX and the race start.
Except for final adjustments to the rounding DC, Step 5 was complete before the second tack.

Rounding the Mark

In theory, DCC is accurate to the second — yielding perfectly timed course changes within a SOL server jump … but beware.

The assumption is that the server jumps are evenly spaced — and we know that doesn’t happen.

The assumption is that there is no rounding error, and we know that isn’t true.

So despite the exquisite rounding path shown in this map detail image, during the minutes leading up to the rounding I deleted the rounding DCs and executed them by hand.

My take on the accuracy of DCC is this:
If you want DCC to round a mark using DCs, you need to leave a cushion.  In most cases one server jump is enough.  But the longer you have been on auto-pilot, the larger the cushion you will need.

To Maui

From the first mark to the Hawaii Hali mark javakeda dropped from 1st place to 24th.  I was able to recover 11th at the Koho’olawe rounding.
The loss in ranking and distance was due to skipper error plain and simple.
Basically, I didn’t properly weigh the strong winds forecast for the north side of the Maui channel.   Instead I opted to sail the shorter southerly route … and it cost me.

To Molokai and Oahu

Javakeda rounded Koho’olawe at 0700utc (midnight, local time).
It was time for me to set DCs for the night. I would be getting up in 3.5 hours for the WX.  Sleep before the WX was an absolute necessity.

The issue was whether I could round the east end of Molokai using DCs.

The rounding is guarded by a small island SSE of the rounding point.

Threading this needle was a non-trivial challenge.

I set an approach cc-based DC of 360º.
Once past the guarding island, I switched to a course of 003º to clear the point on Molokai.
Then, with a 15-second cushion, I set a course of 304º to head for better winds to the northwest.

This worked.
But I don’t see how I could have timed these DCs without the NCC software.

There are two other tracks visible in this screenshot, and it looks like both of those boats BBQd for a while on the east end of Maui.
I don’t see a need to identify those skippers in this post.  They know who they are.

Up and Around Kauai

Once past Barber’s Point on Oahu, the course to the north end of Kauai was pretty much a straight shot at 308ºT or thereabouts — depending on your position after Barber’s Point.

Going over the top and down the back of Kauai was another story entirely.

Exped recommended a course that went north, and then channeled west before gybing toward the western Kauai coast.

This image shows three  views of the same route.
On the right is the recommended route from Expedition.
On the left is the route actually being followed in real time.
In the center is the DCC path that links the two.

I saved this image during the race because I felt it illustrated how the DCC software provided a bridge between the router recommendation and SOL client commands.

The Cross

The winds in the channel between Kauai and Niihau showed greater pressure to the east.

A tight rounding of the west side of Kauai offered the possibility of speeding down the east side of the channel and then gybing in an attempt to cross boats to the west before they could clear the southern end of Niihau.

Both longreacher and javakeda followed this plan.

For longreacher, the cross was easily executed and gave him an easy sail to the finish for the win.
(Well done!)

The cross was much closer between javakeda and hirilonde.

javakeda was just able to get position and pinch hirilonde off against the southern point of Niihau.

Once past Niihau I again went to SPINNACER — this time using the VMC calculator to determine javakeda’s quickest heading to the finish line.

Overall Evaluation of DCC

There is no doubt in my mind that using DCC made a critical difference and got javakeda on the podium.

Without it, I would have been lucky to make the top ten.
If I hadn’t been able to round the east end of Molokai cleanly, I would have been lucky to make the top twenty-five.

This is very useful software that will improve your performance in SOL races.