I've used the IPG100 too, and it does give you the ability to have N2K PGNs on your IP network, but there are very limited options for actually consuming that data. As twistedtree mentions, you can use their iPad app, or N2KView, their PC application.
All of the other solutions out there that I am aware of send 0183 data over a TCP or UDP port, which when you think about it is pretty disappointing. Just going through the inventory in my head of all of the various mobile and PC apps that I can think of, and other than Maretron's and Coastal Explorer+Nemo, I can't think of a single one that doesn't use the older NMEA 0183 protocol.
That's an interesting question - why haven't we seen the move to N2K for any gateways? There are a ton of additional types of data that N2K can deal with that 0183 never was designed for. Strange...
SignalK is the only thing I can think of that is gathering from many networks and presenting things as a stream that isn't just 0183. It can output JSON and other types of data, which aren't really end user protocols, but still gives it tons of flexibility.
Until Navionics, iNavX, and <insert your mobile app here> starts looking at supporting NMEA 2000 PGNs, I don't think these gateways will get any more interesting or feature-ful.
I think there are a few reasons for this.
First and probably foremost is that there is no standard for N2K over IP. That's a real impediment to an app developer who wants to utilize N2K PGNs to display data, etc. A standard for this has been "coming soon" for a very long time - probably 5-10 years - called OneNet. I attended a seminar on it at METS and it is supposedly in final review prior to release. That will open up a lot of doors, but may still be slow to take off.
The other impediment to N2K flourishing is that it's not really an open standard, and let me be really specific about what I mean by that because it seems to put some people into a tizzy when I say it.
The N2K spec can be licensed by anyone who wants to sign up. That's an open door. There is a fee involved, but you need to buy pretty much every standard of any kind that I have encountered, with the exception of IETF RFCs for all the IP protocols. The Ethernet & wifi standards (all the 802 standards) need to be purchased, but the IP protocols that run on top of it are open to anyone to download, read, and participate in the process. The point is that having to pay for the spec is not a big deal, and is a common practice.
What's unique about N2K is that the license includes a confidentiality clause that binds you to secrecy about the contents and workings of the standard. This is above and beyond the normal copyright that any document carries that protects against blatant reproduction.
So even though the door is open for anyone to license the standard, once you step through the door, you can't reveal what's inside, or how it works. This totally puts the kabosh on any sort of open professional or academic discussion, and blocks anyone who might want to write a paper or book, like some sort of how-to. Ethernet, IP, and countless other standards have scores of books written about them, leading to an educated and conversant pool of engineers, and a thriving market. No such books can be written about N2K, and it leaves people like me to figure it out by observation and reverse engineering. That would be no way for someone to build a product, even if they wanted to.
There have been a couple of N2K code bases developed via reverse engineering (actually, maybe only one), including the one that's used for SignalK. A big part of the excitement around SignalK was that it is completely open, enabling the sort of flourishing market found elsewhere. But in all frankness, SingnalK strikes be as a total belly flop. It doesn't seem to have gone anywhere.
Another impedament is that building an N2K gateway is a lot more complicated than building an 0183 gateway. An 0183 gateway just spits out sentences. You can spit them over RS422 (NMEA 0183), spit them over UDP, or nearly anything else. And on the computer side, it's just a serial data stream. Couldn't be simpler.
But N2K utilizes CanBus which has a whole datalink management structure to it. There are management and housekeeping PGNs to sort out addressing, who can do what, etc. etc. Any give implementation needs to decide which functions are handled by the interface and drivers, and what is handled by the app using the interface. Things like reporting what PGNs a device can send becomes very complicated because the gateway doesn't know what the apps are capable of. So who answers when asked? And what if there are multiple apps using the same interface at teh same time, like CE and TimeZero? Are they distinguishable by other devices on the network such that the AP knows which autopilot messages to listen to? These are all solvable, but every vendor does it differently. What's missing is a standard programming interface like Sockets for TCP that provides a standard way for apps to use an interface.
Meanwhile, the usual suspects of electronics vendors would love to get you hooked on their total, integrated systems, so nobody really has much incentive to do anything about this. The advice I hear all the time to "buy everything from the same vendor" is exactly what they want to hear.
