Tuesday, December 15, 2015

Tracy Arm

Tracy Arm is fjord about a 25nm long, and located just a little bit south of Juneau.  At it's head, it forks, with tidal glaciers at each end.  At the head of the north fork is the Sawyer Glacier, and at the head of the south fork is the South Sawyer Glacier.  Like many of the fjords and inlets in Alaska, it is too deep to anchor anywhere, so you need to anchor in a cove just before entering the Arm, then make a day trip up and back.  In our slower boat, it's a full day affair, but wow, what a day.

All around the anchorage are ice bergs drifting.  They calve off the glacier faces and drift out into Frederick Sound.  Sometimes they find their way into the anchorage, so you need to be ready to fend them off at any time.


Ice berg hovering outside the anchorage

We had a typical Alaska overcast day, but little to no active rain.

Typical Alaska day


There are dozens of waterfalls emptying into the Arm.   Mist and low clouds add lots of drama






Here is a much bigger berg working it's way out towards the sound.  It's about 200' long.


In the picture below we are approaching South Sawyer Glacier.  In the crotch of the mountains you can see the glacier, and  right along the waterline horizon you can see a wall of ice debris.

South Sawyer Glacier in the distance

And lots of scattered bergs, including a sail boat for perspective.

Bergs and a sail boat in Tracy Arm
As we got closer, look what was coming out.  The down-side of being close to Juneau is the amount of traffic.  You are never even close to being alone in Tracy Arm, but it's still well worth while.  The other unfortunate thing is the plume of smoke from these cruise ships.   That's not a cloud or mist hanging over the water.  That's the ship's exhaust blowing out ahead of it.  The cruise lines claim it's glitter and pixie dust, but we know better.

Cruise ship with a cloud of exhaust.

And here we are getting slowly closer and closer.   We were able to make it through one or two bands of ice, but never closer than around mile from the glacier's face.  It was totally packed with ice.





Below are some shots up close by South Sawyer Glacier

South Sawyer Glacier calving

South Sawyer Glacier


The ice is forever shifting around and on the way out we encountered quite a wall that we had to pick very slowly through.  We had a couple of sail boats right behind us taking advantage of the path that we made.  On the radar below you can see how dense the ice was.

Choked in by ice

Next we went to the north fork to see the Sawyer Glacier, and this time there were no other boats.  What a difference.  We were able to get up very close to the glacier itself, as well as a number of ice flows around it.  Our chart showed us about 3/4nm inland from the face of the glacier, so clearly it has receded a bunch since that chart was last updated.

Sawyer Glacier

The patterns and colors of the rock walls were amazing.  Notice how smooth it has been worn by the glacier as it receded.

Rock wall bordering Sawyer Glacier

Sawyer Glacier

On the way out, we continued to enjoy may more bergs





This last berg had a visitor

Eagle on ice berg

Monday, December 14, 2015

Wrangell to Pybus Bay

June 27 - July 6

From Meyers Chuck we went directly to Wrangell where we tied up at their relatively new South Basin.  The docks are great, but unfortunately it's a mile or so outside of town, so rather inconvenient if you want to explore.  We decided to go by dinghy rather than walk so we could explore the main harbor as well as town.

When you are cruising a particular area, it's very common to find yourself constantly bumping into the same boats over and over again.  The picture below is Atlas, a very brightly colored 85' Northern Marine.  This is the sister ship to the Northern Marine that was recently launched with inadequate ballast and rolled over and sank.  Atlas is proof that Northern Marines, once properly ballasted, are seaworthy boats.  We saw Atlas many times during out trip.

"Atlas", an 85' Northern Marine

After 2 nights in Wrangell we checked, then double checked the tides and currents for Wrangell Narrows, then pushed off to make the trip to Petersburg.   Like a number of the narrows in this part of the world, it floods from both ends and ebbs out both ends, with a split somewhere near the middle.    In an ideal scenario you enter on the flood so you have the current carrying you along, time your arrival at the split point just at slack high tide, then ride the ebb out the other end.  And sometimes you need to adjust this plan so you pass some other spot at slack water in order to avoid otherwise nasty current and turbulence.  And if you can't pass at high slack, then you need to pass at low slack.  In that case, you will be fighting the end of the ebb going in, and fighting the start of the flood going out, but it you time it well, it's not too much lost speed.

With all this in mind, off we went to transit Wrangell Narrows.   The day was overcast, but not raining, and the clouds added some interest to the sky.



Overcast, but interesting skies

Below is the "WN" buoy marking the entrance to Wrangell Narrows.  As we got closer, you could see the current against the buoy, and the sea slugs piled up on top for a nap.   And if you look real close, you can see one that has climbed up into the superstructure of the buoy.  They are pretty agile creatures, for sure.

"WN" entrance buoy for Wrangell Narrows

Sea Slugs napping

Out passage worked out just as planned which is how I like it.  I do lots of fretting before such a leg, but I'd much rather fret in advance than have a mess while underway.

On arrival in Petersburg we were assigned a slip in their North marina.  The current really flows through there, but we were able to get in without any drama.

Petersburg is quite the place, and reminds me of Gloucester 40 years a go.  There is a non-stop parade of fishing boats coming and going, unloading catch, repairing and re-provisioning, then heading back out again.  It's great to see the industry surviving in this part of the country, where in the North East it is almost entirely shut down.


Typical fishing vessel

After spending a few days in Petersburg, we headed out to Thomas Bay in search of our first glacier, the Baird Glacier.  And sure enough, not long after we got out into Frederick Sound, we spotted our first bergy bit.

Our first ice sighting

First burgy bit

Once inside Thomas Bay we headed over to catch a glimpse of Baird Glacier.  Baird is no longer a tidewater glacier which means there is dry land between the water and the face of the glacier.  As a result, you can't get very close to it by boat.

Baird Glacier, Thomas Bay

Across Thomas Bay the most amazing mist formations kept waving along.

Wavy mist formations

Mist and a fishing boat

Closer view of the Baird Glacier

Later in the day Laurie went out for a kayak run and checked out this out-flowing stream.  It seemed like the perfect place to spot bears, but alas, none were seen.

Searching for bears

And we got another treat of a sun set, though this is probably 10:30 or 11:00 at night.

Thomas Bay sunset

The next day we crossed over Frederick Sound to Pybus Bay where we had arranged to rendezvous with our friends the Goldbergs aboard Duet.  On the way, we spotted some humpback whales and were treated to a great show.






We had a very pleasant couple of days at Pybus, but all good things must come to an end, so boats weighed anchor and went on our ways, the Goldbergs heading south, and us heading north to Tracy Arm.

Thursday, December 10, 2015

NMEA 2000 to NMEA 0183 converter challenges

As part of building my Electronics 2.0 suite I installed two dedicated radars; A 12kw Furuno FAR-2117, and a 4kw Furuno 1835.  I also upgraded to Class A AIS.   The FAR-2117 radar and the Class A AIS are both IMO certified devices, suitable for use on a variety commercial vessels.  Their certification means they comply with very detailed international specifications which, among other things, stipulate the type and quality of instrument data that's required, and how it is interfaced with the devices.

In my case, all my instrument data is on my NMEA 2000 bus (N2K), so this had a number of significant implications:

1) All interfacing is via NMEA 0183, not NMEA2000: N2K is not an allowed interface for IMO certified devices.  Maybe someday it will be, but not currently.  And based on my experience with N2K, I know why.  Up until now, all the navigation data on my boat has been on N2K, so these new devices meant the addition of 0183, and some degree of conversion to get my N2K instrument data over to these 0183-only devices.  So, short of changing out all my instruments to be 0183, the use of N2K to 0183 data converts was the obvious solution, and is the main subject of this article.

2) True Heading in the form of HDT:  These IMO devices have another interesting requirement.  Both require that you feed it ship's heading info, and they both require that you provide True Heading, not Magnetic Heading, and they require it in the form of the 0183 HDT sentence.

3) Fast Heading (10hz or more):  Autopilots and radars require a fast heading source to perform well.  10hz is really the minimum, but some products can accept up to 40hz.  Without fast heading, radar overlay is imprecise, and the radar's ARPA function won't work well.  And without fast heading, your autopilot will not steer the boat as well.

4) NMEA 0183 running at 38,400 baud:  The fast heading rate described above is important, but the increased data rate can become a problem on 0183, overloading its normal 4800 baud data speed.  The HDT sentence alone at 10hz will consume about half of an 0183 channel capacity, leaving room for perhaps one other sentence.  And if you want to provide HDT at 20hz or 40hz, it will overload the channel.  As a result, it's preferable to run 0183nchannels that carry any form of fast data (heading, rate of turn, position) at 38,400 baud rather than 4800 baud.  In fact, the FAR-2117 requires that you run at that speed when operating in IMO mode.  In addition to the fast heading, AIS data is guaranteed to overload a 4800 baud channel, so all 0183 AIS data is always run at 38,400 baud.

5) Ability to select data sources:  I have equipped my boat with a number of redundant components where I feel the device is essential to safe travel.  As a result, I have a satellite compass/GPS that provides high precision heading and position data.  It is my primary heading sensor and my primary GPS.   As backup, I have a conventional GPS sensor and a magnetic rate compass.  If any part of the sat compass/gps fails, I can keep running with the backup device.

Interfacing the radars and AIS requires more data than just the items above, but it turned out to be the hardest part of the puzzle.

In my efforts to put together something that worked as desired, I tried 5 different N2k to 0183 converters.  These were:

AMEC NK-80
AMEC NK-80



Simrad AT10 & AT10HD
Simrad AT10 and AT10HD


Furuno IF-NMEA2K2

Furuno IF-NMEA2K2


Actisense NGW


Actisense NGW


The only other N2k to 0183 convert that I know of on the market is the Furuno IF-NMEASC which is designed to work in conjunction with their SC-30 sat compass.  It has quite a few capabilities, but is large and significantly more expensive that all the others, so I did not pursue it very far.

Here are the challenges that I ran into:

Source Selection

None of the converters have controllable N2K data source selection.  So with two GPS sources on the N2K bus, there is no way to tell any of the converters to use the Sat Compass instead of the backup GPS, and no way to force a switch over to the backup.  The converters will all pick a source on their own and you have no control over it.  And it's up to them to switch to a backup source if the primary fails, including whether they switch over at all.  Only Actisensse documents that they select the highest priority (lowest node address) N2K source, so at least you know how it will behave.  For everything else you just need to test and see how it works, make sure it does what you want, and hope it continues to do so consistently.  Through experimentation, I confirmed that the Furuno converter works the same way as the NGW.

The NK80 doesn't do source selection at all, but rather translates everything on the N2K bus regardless of who it comes from, and sends it to the 0183 side.  At first I really liked this device until I discovered what it was doing, or not doing in this case.  This is extremely broken and creates all sorts of crazy problem if you have multiple sources of data on the N2K side.  For example, say you have two heading sensors.  They will never read exactly the same value, and could easily differ by a couple of degrees.  The NK80 will generate 0183 heading sentences for both sensors as the N2K data comes in, creating 0183 sentences that reflect one sensor's value, then the other, then back again, etc.  And device listening to the data on 0183 will think your boat is twisting back and forth when it isn't.  Just imagine how your auto pilot might respond to this.   The same is true with GPS data, and everything else.  And, not only does it produce seemingly erratic data on the 0183 side, but it generates double the traffic for every pair of devices that you have.  Once I figured this out, the NK80 went from the top of my list to off the list, and I returned it for a refund.

 HDT at 10hz, 38,400 baud

The Simrad AT10 only operates at 4800 baud, and only transmits heading at 1 hz, so it was off the list.

The Simrad AT10HD is specifically designed for fast heading, so will produce data at 10hz.  But the only data is produces is heading - nothing else.  This is partly because it also only operates at 4800 baud so don't have the bandwidth to send anything else.  I need 38,400 baud, so this device was out too.

The Actisense NGW is attractive because you have some control over what data it translates and what data it doesn't.  So rather than blasting everything over to 0183, you can filter out and only send what you want.  It can also operate at 38,400 baud, so seemed pretty interesting.  But what I discovered is that it will only send heading at 1 hz, and can't do it at 10hz.  That was a killer.  Also, it won't send HDT, only other forms of heading sentences.  That was a second killer.

That left me with a single device - the Furuno IF-NMEA2K2.  It supports HDT, does so at 10hz, and can operate at 38,400 baud.  You can't control or filter which data gets sent, but it is the one and only converter that meets the basic needs.

True Heading

On N2K vessel heading info is carried in PGN 127250, Vessel Heading. It includes the heading reading and a flag that tells you whether it's magnetic or true.  It also optionally includes the current magnetic variation.

A sat compass or a gyro compass outputs true heading, so when sent on N2K this would be indicated in the PGN.  All the 0183 converters that are able to product HDT (regardless of speed) will only do so if they receive a true heading in the Vessel Heading PGN.  If they receive a magnetic heading, even if it includes variation information, they all produce HDG.  I was told by one NMEA committee member that it's considered bad form to ever take one form of data, convert it, and re-transmit as another form.  I suppose it makes sense to preserve the source and accuracy of the original data.  Apparently it's fine for a display device to combine data when presenting, so when you switch your plotter heading between true and magnetic heading, it's just the presentation than is changing.  Or when you display ground wind vs apparent wind, you are just changing the presentation.  The raw data on the bus is still represented faithfully in its original form.

The upshot of this is that the converter will only generate HDT using my Sat Compass which outputs true heading.  It will not product HDT from my rate compass since it reports magnetic heading.  And none of the converters will combine magnetic heading and variation to create HDT, even though technically they could.  This left me with no way to use a rate compass as a backup heading device.

True Heading (HDT) from a rate compass?
To me it's essential to have a backup heading source and to be able to switch to it easily.  And it wasn't looking like any N2K rate compass would work.  And I also wasn't about to buy a second sat compass.  So I started researching rate compasses that also have 0183 interfaces and I found something interesting.  The Furuno PG500R is 0183-only, and if you feed it GPS info that includes Variation data, it will put out HDT.  And I also found the Maretron SSC200 which is a bit of a hydrid.  It has an N2K interface, and if there is a source of Variations on N2K as presented in PGN 127258 Magnetic Variation, then the SSC200 can be configured to output HDT on its 0183 port.  Since all my GPS data is on N2K, the SSC200 was a perfect fit.  No matter which GPS was in use, Variation would be present on the N2K bus, and the SSC200 would be my second source of HDT.   And it can run at 38,400 baud.  Perfect!

As a little aside, there was some debate about True vs Magnetic Heading in the comments section after this article on Panbo, and they continued in the comments for this article here on MVTanglewood.com.  My comments there were a direct result of my experience as reported in this article, and I still think what I said about True Heading on N2K is correct; The only N2K device I've found that will transmit True Heading in the Vessel Heading PGN is a  Sat Compass.  All forms of magnetic compasses that I have seen and in all the literature that I can find report Magnetic Heading, not True Heading.  Many of those devices also include a GPS (like the Airmar 200WX mentioned by Ben Ellison in one of the comments, as well as the GH2183) or can be fed GPS data (like the SSC200) and will consequently also include Variation is the Vessel Heading PGN thereby allowing a recipient to calculate True Heading.  But the heading value itself is Magnetic.  As a result, none of the 0183 converter will generate HDT from that data.  With no HDT, you can't satisfy the data feed requirements of a Class A AIS device.  You can get HDT from various 0183 sources, but the only way to get it from N2K via a converter is from a sat compass.  But..... if anyone has an example to the contrary, by all means speak up.

Controlling Data Source Selection
At this point I had all the requisite data, but unlike N2K, you can't just connect up one port for all the data and call it a day.  The radars and AIS have restrictions on which data can be paced on which ports.  Heading is generally segregated out on a dedicated port.  Then another port or two are available for other data like GPS, Nav data, etc.  Then another for AIS.

Where this really comes into play is with data source selection for heading and GPS.

For heading, the sat compass heading info gets converted from N2K to 0183 by an IF-NMEA2K2.  The Sat compass puts out true heading on N2K, so the converter produces HDT as desired.  Because there is only one source for true heading on N2K, I don't have to worry about the converter selecting the wrong N2K source.

My second heading source originates as 0183 coming from the SSC200 compass.  To control which of the two gets fed to the radars and AIS, I just used a good old fashion switch.

For GPS source selection, I relied on the automatic source selection in the IF-NMEA2K2.  I confirmed that my sat compass always takes on a lower address (higher priority) than the standard GPS, so the converter always selects the sat compass, and fails over to the GPS if the sat compass fails.  I have tested this by disconnected and reconnecting sensors to confirm everything switches as expected.

That's quite a twisting and winding road, isn't it?  Here's a table that attempts to summarize the various converters.  Hopefully it will make it easier to pick an appropriate on for whatever needs you have.


N2K Source selection 38,400 Baud HDT output 10hz Heading Selectable translation AIS Support
AMEC NK-80 none (1) yes yes yes (2) yes yes
Simrad AT10 automatic no yes no no no
Simrad AT10HD automatic no yes yes (3) no (3) no
Furuno IF-NMEA2K2 automatic yes yes yes no yes (4)
Actisense NGW automatic yes no no yes yes (4)








Notes:






1) Indiscriminately translates PGNs from all sources creating a mixture of data

from all sources on 0183.



2) Actual data rate is the sum of the data from all sources, so two 10hz N2K heading

sources will result in 20hz of mixed heading data on 0183

3) AT10HD only translated heading and noting else.

4) Supports a specific AIS mode and only translates AIS data in that mode


And if anyone is a real glutton for punishment, here's the schematic for Electronics 2.0.  Note that it includes all the nav equipment, not just what's covered in this article.  It's also a continuous work in progress, so might be slightly out of date in one area or another.


Monday, December 7, 2015

NMEA 2000 Instances - there is more than one

Back in this article on NMEA 2000 I talked about Instances in N2K.  That led to a debate with Panbo's Ben Ellison about my understanding of N2K Instances, and we never really resolved it.  More recently, like yesterday, the topic came up again on Panbo in this discussion about Simrad MARPA performance, a topic that I originally published here.  Ben commented that I had never corrected my N2K article, so I went back and re-read it to see what I had wrong.

I can see how the article could have been better written (that's usually the case with my prose), but I couldn't find anything that was incorrect.

Then, also spurred out of the debate on Panbo about Simrad MARPA, Kees Verruijt posted a comment on my blog saying that he also thought I misunderstood Instancing.  Kees is the guy behind CANboat which is an open source N2K decoder, so definitely worth listening to carefully on the topic.  His comments cause the light bulb to finally go on in my head.

It turns out we were talking about two different things.  NMEA 2000 includes two types of Instancing; Device Instancing and Data Instancing.  They are similar, yet different.  I had been talking about Device Instancing and Kees was talking about Data Instancing.

With this new illumination, I have placed a note in my original article making it clear that I was talking about Device Instancing.  Now, the purpose of this article is to explain the difference between the two, along with where and how each is used.

So what is the difference between a Device Instance and a Data Instance, where is each used and for what purpose, and why should I even care?  Well, read on....

First, some reference material is worth noting.  As I have mentioned in the past, the N2K spec is secret, only accessible to those who buy it, and when you buy it, you also agree to maintain it's secrecy.  I have never seen or read the spec, so am left to observation, reverse engineering, publications that are publicly accessible, and discussion that I have had with a variety of NMEA committee members, including some vendors.  As a result I can't guarantee the accuracy of this, but I have made every effort to use credible published information, and concrete observations of actual N2K data traffic to piece together my view of how all this works.  I welcome corrections and additions - that's how I got as this far in the first place.

Here are a couple of very useful publications that have been a great source of info for me.

NMEA 2000 Past, Present, and Future, by Steve Spitzer, Lee Luft, and David Morschhauser

NMEA 2000 PGN Field List, published by NMEA

Data Instances:

In some PGNs there is a field know as a Data Instance that is used to distinguish similar data coming from different sensors.  This is typically used when one N2K device can have multiple sensors connected to it, but it can also be used to differentiate similar data sent from different N2K devices.  It is important to note that a Data Instance number is always carried in the same PGN as the data itself.  As a result, the data is self-describing.

Here are two examples of its use:

1) This first example illustrates how a data instance can be used to distinguish data coming from multiple sensors connected to the same N2K device.  Maretron's TMP100 temperature device can sense and send data for 6 sensors.  It does so using PGN 130312, Temperature.  The data fields in this PGN are

- SID
- Temperature Instance
- Temperature Source
- Actual Temperature
- Set Temperature

Each time the device sends this PGN, it comes from the same device (mode address) and includes the Instance Number for the particular sensor.  With 6 sensors active, it will send 6 PGNs, one for each sensor.  These Data Instance numbers are manually assigned when the device is first installed, and must be unique for each sensor.  For a device listening to these PGNs and displaying a particular temperature, it needs to be programmed with the correct instance number so it knows which PGN to display and which to ignore.

Note that if there is only one device on the network sending these PGNs,  a listening device can ignore which device address the data is coming from and only pay attention to the Data Instance inside the PGN when deciding whether to display the data or not.  That brings us to the next example.

2) This example shows how a Data Instance can be used to distinguish data from two different devices.  A rudder indicator is typically mechanically connected to a single rudder, so can only report the data for that rudder.  It would do so with PGN 127245, Rudder.  This PGN has the following fields:

- Rudder Instance
- Direction order
- Reserved bits
- Angle order
- Position- Reserved bits

If you have two rudder sensors, either redundantly connected to the same rudder, or connected to a second independent rudder, each device would need to be configured with a different Rudder Instance.  A device listening to this PGN would be programmed with the desired Rudder Instance so it knows which PGNs to listen to, and which to ignore.   The device displaying data can ignore which device address the PGN is coming from, and discriminate solely based on the Rudder Instance number contained in each PGN.

Additionally, looking back at example #1, even if there are multiple temperature devices on the network, each sending the temperature PGN for multiple connected sensors, as long as all the sensor Data Instances are unique, a listener can continue to ignore which device address the PGN came from and display data solely based on the Data Instance inside the PGN.

So you can see how Data Instances can be used to distinguish similar data coming from different sensors, regardless of whether it is coming from the same or different devices.  You can also see how the Data Instance must be programmable in both the transmitting device and the listening device so the correct data can be picked out and displayed.

The big restriction with Data Instances is that not all PGN types support it.  Many PGNs can only represent data  from a single sensor sent from a single N2K device.

Examples of PGNs with no Data Instance are:

PGN 127250, Vessel Heading
PGN 127251, Rate of Turn
PGN 128259, Speed, Water Referenced
PGN 128267, Water Depth
PGN 129025, Position, Rapid Update
PGN 129026, COG, SOG, Rapid Update
PGN 129283, Cross Track Error
PGN 129284, Navigation Data
PGN 129285, Navigation Route/AP Data
PGN 130306, Wind Data
The full family of AIS and DSC PGNs

As a result, most of the primary navigation data represented in these PGNs and coming from multiple devices has to be distinguished in some other way.  The solution to this in N2K is to distinguish this data based on the identity of the device sending the data, and that leads us to the Device NAME and the Device Instance.


Device NAME and Device Instance Number:

A device's NAME uniquely identifies it on the bus.  So anybody who wants to pick out data from a particular device can do so based on the device's NAME.

Here's a quick quote from one of the above publications:

"NAME is the contents of the data field of the Address Claim message and must be unique for every device on the network. It consists of sub-fields containing codes for device function, instance numbers for multiple devices of the same type, manufacturer code, and a unique number assigned by the manufacturer. The latter, like a serial number, must be unique for every device of the same type produced by a manufacturer. During the address claim process, claims on the same address are won by the device whose name has priority."

The Device Instance is a number that is part of the device's NAME.  Here is the whole makeup of the NAME field:

- Self configurable: Always "1"
- Industry Group: Always "4" for Marine Industry
- System Instance: Used with multiple bridged networks
- Device Class: Code for different classes of devices
- Reserved: Always "0"
- Device Function: Code for different device functions
- Device Instance: Here it is. It's the combination of an upper and lower part, default value zero.
- Manufacturer Code:  Number identifying the manufacturer.
- Unique Number: Always unique for any combination of Manufacturer, Device Class, and Device Function.

Continuing on, you can see that for certain key navigation devices (Position Sensors, Heading sensors, Depth sensors, Autopilot controls), the only way to select which sensor you want a chart plotter to us is to tell it which device on the network it should listen to.  And we know that the device's NAME is what uniquely identifies each device.  Now all we need is a way to tell the plotter which device NAME to listen to for each type of data (position, heading, depth), but that's easier said than done.
Unlike a Data Instance that is contained in every PGN making the PGNs themselves self-describing, the NAME field is only returned in the ISO Address Claim PGN 060928, and that is only sent when the network goes through its self-configuration process or when specifically requested.  In practice, it only gets sent when the network powers up or when there is a configuration change like the addition or removal of a device.

All the PGNs that we need to filter/distinguish only contain the node address of the device that sent it, plus of course the data.  So we need a way to correlate device NAMEs with node addresses.  Knowing that, a receiving device can use or reject data based on the "sent from" node address in the PGN.  With a little translation from node address to NAME, the PGNs once again become self-describing.

Creating the correlation between NAME and node address requires a little work.  The device NAME only appears when the network reconfigures, so you have to pay attention, catch them all, and remember which node address corresponds to which NAME.  Essentially you need to create a map of the network.  Once you do that, the listener knows which node address to listen to if it wants data from a particular NAME device.  It's a little convoluted, but it works.

How this device selection (source selection) gets presented to an operator varies from manufacturer to manufacturer.  Here are some examples that I have encountered:

1) Some listening devices do not provide any user control over which device they listen to.  Instead, the device decides on its own which device to select as a source.  N2K has the notion of priority of devices, and once the address claim process is complete, higher priority devices have lower node addresses.  Much of the time this works, but I have seen cases where what I would consider to be a lower priority device like a standard GPS took on a lower address number than a higher priority device like a Sat Compass/GPS.  So if you have a device that depends on this approach, it's worth carefully checking your device addresses to be sure you will get the expected behavior.

All of the N2K to 0183 convert devices that I have seen do device selection on their own with no provision for configuration.  This includes the Simrad AT10 and AT10HD, Furuno IF-NMEA2K2 and IF-NMEASC, the Actisense converters, and the AMEC NK80.  Actisense says explicitly that they select the lowest address device, so at least you know how it will behave.  The Simrad and Furuno devices do not say how they perform device selection.

The AMEC NK80 is totally whacko and does not select any one device, but rather translates all relevant PGNs from all devices.  So if you have two GPSs on N2K, you will get GPS info alternately from each GPS on the 0183 side.  That's very, very bad, so don't use that device if you have multiple N2K data sources.

2) Furuno presents the text device name which comes from PGN 126996, Product Information, followed by a number which I believe is the unique number from the NAME field.  But I have not verified that.  What I do know is that they show multiple devices in a unique way so you can pick which one you want to use.  And because they use the text device name e.g. HS70, or GP330, or DT200, it's pretty easy to figure out which you want to use.

3) Simrad also uses the text device name from the Product Info PGN, but when the Device Instance Number isn't zero they append the number to the name.  So an NSO that is Device Instance zero will be displayed as "NSO", and one with Device Instance 2 will display as "NSO-2".  It is not consistently done, but I have seen cases where Simrad automatically assigns Device Instance Numbers to like devices so they are easily distinguished.  I made a habit of always assigning unique Device Instance numbers when I had more than one of any given device.  So my multiple follow up levers were FU80-1, FU80-2, etc.  The NSO and NSS products have a page where you can change the Device Instance number on any device.  Lots of other vendors have the same capability, and they use some standard configuration PGN to make the change, but I don't know the details.

4) Maretron, takes a different approach.  When you select a data source for display, you aren't presented with a list of named devices.  Instead you are asked for an Instance number.  One thing that is confusing is that they don't say which Instance Number they want (Data or Device), and sometimes they use one and other times they use the other.  For data that comes in a PGN with a self-contained Data Instance like Temperature PGN 130312, they want the Data Instance of the particular sensor.  For data that comes in a PGN that does not contain a Data Instance like Vessel Heading PGN 127250,  they want the Device Instance.

So a Device Instance is a number that can be used to help distinguish one device from another on an N2K bus.  I'd like to emphasize that it can be used, but it is not the only way to distinguish devices, and in fact it's not the preferred way, and can be quite flawed if not used correctly.

Assuming you use their N2KAnalyze tool for configuration, they have some features than make this a bit easier in some cases.  For example, you can add a text label to each temperature sensor.  Then, on N2KView when you look at the drop-down to select the instance number, it shows the label next to the Data Instance number.  That helps guide you.  But not all devices support labels, so when I want to pick the Device Instance number to select which depth sensor I want to display, I am just presented with a list 253 number to pick from.  I have a book with all my boat's info, and among other things I keep track of all my N2K devices and their Device Instance Numbers, plus all the Data Instance numbers where that's applicable.  But to make a configuration change to N2KView, I need to dig out the book and look up the Device Instance number.

As you can see, the ONLY way to select a data source with Maretron is via the applicable Data Instance or Device Instance.   You can't click on "HS70" or "GP330" to choose your position sensor.  Instead, you need to assign each a unique Device Instance Number, keep track of that assignment, and use that number to select your position sensor.

Referring back to this article, my complaint was that the infrastructure to select devices based on Device Instances is incompletely implemented and enforced.  The N2K standard requires that Device Instance Numbers be programmable.  It doesn't say how, but there needs to be a way.  Maretron depends on this mandatory feature for their device selection, which although I don't like the approach, is still a valid design.  However, vendors frequently do not provide a way to program the Device Instance, even though it's required.  And when asked, they don't understand why anyone would care because in their view you should be doing device selection based on the device NAME, not the Device Instance number.  In fact, NMEA says that any network should work with all Device Instances set to zero.  And, the NMEA 2000 Certification process does not test for the ability to configure the Device Instance, so products become fully certified whether they implement it or not.  To me, this problem reflects an unclear standard and inadequate certification process, so shame falls squarely on the NMEA 2000 Standards Committee.  But that's the subject of the other article, not this one.

Hopefully I have cleared up the ever-so-confusing topic of  "Instancing" in N2K.


Friday, December 4, 2015

Meyers Chuck

I know, I'm way behind posting.  Like 6 months behind.  No excuses.  That's just the way it is.

June 26, Meyers Chuck, AK

Our next stop was Meyers Chuck, not far from our last anchorage in Port Stewart.  En-route, we were treated to a nice visit and show by a pod of about 6 orcas.  We found ourselves paralleling them for a while, and one large male (identifiable by the long, straight dorsal fin) kept himself between us and the rest of the pod.  Then, he came right over and cut across our bow to check us out, then returned to the pod.

Orca coming over to check us out

Orca pod paralleling us

Later that day we pulled into Meyers Chuck.  Any chance you are wondering what a "Chuck" is?  We were, so we looked it up.  It's a bay or cove that has two entrances at high tide, and only one at low tide.  In other words, one of the passes is dry at low tide.  You learn something new every day.

Tanglewood anchored at Meyers Chuck

Meyers Chuck is an interesting little community, with emphasis on "little".  I'd guess 25 people or so, but that's just a guess.
Meyers Chuck, late afternoon

Meyers Chuck, late afternoon

Meyers Chuck, late afternoon

That evening we were treated to a very nice sunset.  This is the pass that dries at low tide.

Meyers Chuck sunset