Maretron IPG100, the missing link, sort of?

... written for Panbo by Ben Ellison and posted on Feb 12, 2011
Maretron_IPG100.JPG

Wow, Maretron just released the IPG100, an "Internet Protocol Gateway" that can take all the NMEA 2000 PGNs on a backbone, turn them into TCP/IP data packets, and serve them out an Ethernet port.  Which means of course that the data can then be routed by cable to a vessel's local network of computers (and other fixed Ethernet gear) and by WiFi to an infinite assortment of onboard mobile tablets, apps phones, etc.  Obvious too is that an IP gateway could also be adept for sending data off a vessel, and commands back, for remote monitoring, troubleshooting, and more.  And Maretron's IPG100 consumes only 0.5 amps of N2K backbone power at most and its $595 price tag includes much more than I've already described.  Or possibly much less, depending on your point of view!...

If you check out the data sheet and manual you can download from Maretron's IPG100 product page, you'll realize that the little box has enough computing power to run the server portion of the company's N2KView monitoring and control system, and thus the IPG100's USB port is meant for the dongle that enables N2KView's floating license scheme.  That make's the IPG a powerful component.  All of a sudden an N2KView boat doesn't need to have a PC running all the time to receive data via Maretron's USB100 either for display or distribution elsewhere.  Now you may well want a PC display when underway, but maybe switch to N2KView on your iPad when you're anchored and hanging around the salon, and then maybe to N2KView on your Android phone when you go ashore.  With an IPG100 all that can be done with just the power it takes to run your boat's N2K backbone and a single N2KView license  (as long as only one of N2KView client app is running at once).
   And while a basic N2KView system is now down to low power and about $1,100 -- which gets you one IPG100 plus one license plus whatever PC, iOS, and Android clients you want -- Maretron has added more interesting options for extending the system.  There's the new MBB100, a $1,295 fan-less black box computer dedicated to running the N2KView client, and the new DSM800, a touchscreen all-in-one also dedicated to N2KView.  Plus Maretron keeps adding sensors that expand the monitoring and control N2KView can do, like the versatile FPM100 fluid pressure monitor, and I know more are coming!  Maretron has been focused on this whole N2KView idea for a long time, a little taste I got last fall suggested how far it's come, and there is no end in sight.
   But here's the rub:  As far as I can tell, the IPG100-based N2KView system has no provisions for sharing IP data with other applications, even though the data starts out as standard NMEA 2000 PGNs, a standard Maretron has supported nicely for all these years.  I can't help but think that a boater who invests in some subset or superset of the system diagrammed below isn't going to be unhappily surprised to find that, say, the PolarView and PolarCOMM programs running on that laptop can't get at the GPS, depth, wind, etc. data that's flowing into it via Ethernet cable or WiFi.  And won't that dissappointment get worse when, say, a sunlight readable, truly multi-tasking Android tablet shows up?
  Now it happens that I heard about the IPG100 late last summer and made the case to Maretron brass that some users will want access to the IP data for other uses, and I believe they were interested, if not sure how it could be done.  They were also apprehensive about the drubbing they might get from some Panbo readers.  So it might be useful if some of the IT types out there suggested ways that data flowing through an IPG100 can be shared with other apps without compromising the integrity of the gateway or the overall N2KView system.  And let's be nice and recognize that Maretron is building quite a flexible, if closed, system here.  And if you're not interested in N2KView, know that we should soon see at least one N2K-to-WiFi gateway -- from Chetco Digital, documents purportedly in the works now -- and I believe there will be more choices in the fairly near future.  


Maretron_NPG100_system_diagram.jpg

Posted by Ben E on February 12, 2011 11:50 AM

Comments

PS Sharp readers may notice that I pegged the IPG100 power needs at a half amp max, but the case label gives it a max LEN rating of 3, which is only .15 amps. I think that's a label error as the datasheet and manual say 10 LEN, and that's what I went with.

Posted by: Ben E at February 12, 2011 12:00 PM | Reply

I was going for the Blue tooth because it draws less power from your pc / pda. I am going to use a NGT-1 iso to work via a bluetooth converter like this one for instance
http://www.antratek.nl/pdf/bluemax05.pdf
Out of the virual com port on your pc is comming n2k data. It is cheaper too.

Posted by: Arno Molenaar at February 12, 2011 2:35 PM | Reply

So, is there a standard for NMEA-2000 over TCP/IP (or UDP)? For NMEA-0183 we use ASCII streams, but obviously that's not going to work for N2K. I recall that some people were using JSON to carry specific N2K messages, but is there a lower-level mapping that can carry the un-interpreted N2K message?

I want do do something in this area and would rather not re-invent the wheel.

Posted by: Paul at February 12, 2011 3:42 PM | Reply

Ben,
I have been following the Maretron products with just what you describe in mind...connecting the NMEA 2000 to my PC network. It makes no sense to me that I have a USB GPS in my PC to run Rosepoint, and a Maretron USB100 so the same PC can recieve the NMEA 2000 GPS data from the Airmar PB200. I really like my some of my Maretron pieces but find most of it is worse than Microsoft, so close by never completed. The EMS100 Engine monitors show some data but other NMEA2000 interfaces for the same engines have more PGNS. Maretron wants to keep the system closed or at least cripled so you purchase their sensors - for example the Airmar P-79 will not work with Maretron for depth but both are NMEA2000. The Airmar PB200 weather instrument does not show all of the information available on N2KView. The Maretron USB1000 puts the NMEA2000 information on my computer but only for the N2KView software. I have not been a big fan of Garmin but I am now hoping they take the NMEA2000 approach and make it an open system. Maretron seems to want to be the Apple Computer approach which is fine if you want to limit yourself. I have a full NMEA 2000 design for my boat but have stopped installing sensors after the first 8 sensors because of the limitations imposed by Maretron.

Posted by: HenryD at February 12, 2011 6:05 PM | Reply

Henry I agree with you in terms of Maretron's approach to extending the NMEA 2000 network to non NMEA 2000 devices, but I've used Maretron's (and Actisense's) USB Gateways with Coastal Explorer (and other software packages) and can see all of the NMEA 2000 data just fine in all applications.

Until there's a cheaper option for a dedicated low power device to rebroad cast the data to my network, I'll use NavMonPC to serve up additional ports for devices to connect to. It won't be long...

Posted by: Patrick - sv Deep Playa at February 12, 2011 8:36 PM | Reply

I think there really should be no issue with carrying N2K over IP (be that TCP or UDP).

Just like there really does not need to be any translation for NMEA 0183, there doesn't need to be one for NMEA 2000.

NMEA 2000 is a physical protocol (CAN bus) and data packet format. The former is what gets translated - packet data is pulled out of those CAN frames. The latter is just fine as is.

If N2K data (format) is going to be encapsulated in UDP, there is no need to change anything. One data frame becomes one packet.

If it is encapsulated in TCP, there would need to be a simple framing scheme. For compatibility, UDP would be more convenient because no one would need to even agree on framing.

The issue, imho, is not of protocols or even very technical but of someone willing to go that route. Technically, making data available over the network is not particularly different from making the same data available on a USB port, just like Actisense does it.

A production CAN to Ethernet device would cost pennies to assemble. The hard stuff is to invest in the initial design, and NMEA certification.

Posted by: PolarNavy in reply to Paul at February 13, 2011 12:57 AM | Reply

Bits and pieces for clarity:

HenryD, Do you mean that a Maretron dispay won't read depth coming from an Airmar P-79 or won't calibrate it (set transducer depth, etc.)? I've had the latter experience with an Airmar DST800, but would be very surprised if any display couldn't see the depth PGN broadcast by the P-79.

http://goo.gl/Jbq1o

When Patrick says that the Maretron and Actisense USB Gateways deliver "all of the NMEA 2000 data" to his third party charting program, that's not quite right. The Maretron USB100 does pass all N2K data to N2KView and other Maretron software programs, but it only delivers NMEA 0183 translations to third party programs, and only some PGNs are translated.

The Actisense NGT-1 can deliver all N2K PGNs to third party programs, but an Actisense DLL has to be on the PC and supported by the software. I believe that's because there is no standard way to encapsulate N2K data once it's off the CANbus. I think Actisense is working on its own IP gateway, incidentally.

But back to the issue of Maretron's IPG100 providing data for applications other than N2KView. Could a facility be added to the N2KView server or client so that nav data is available to other PC applications?

Somewhat further afield, I've been looking at the manuals for Avia Motor and Avia Sail and notice that those applications can rebroadcast NMEA 2000 data to slave clients, to a virtual port (for Fugawi ENC), or via TCP/IP for iNavX. There is a master PC and some translation involved but is Avia onto something?

http://www.fugawi.com/web/products/avia.htm


Posted by: Ben E at February 13, 2011 8:25 AM | Reply

Sadly reading the manual at 1.7.7, on page 7, Maretron is using encrypted data so it will be only be useful with N2kview. Its a closed proprietary system.

I agree with Paul that an open system should use UDP though the raw CAN packages would need a little framing. In particular one needs to know which device the package relates too, like which GPS unit if there is more than one etc. Also a timing word would be useful so the age of the data is known, this would help detect out of date data if a device locked up briefly.

The problem with TCP is the amount of bandwidth required to do all the housekeeping, particularly all the acknowledgements. I did a system for a police force monitoring 25 transmitters. At a one second scan rated the system administrator got upset, we ended up using a 5 second scan rate.


Tedgo

Posted by: Anonymous at February 13, 2011 9:12 AM | Reply

I think the main issue is that development for a product like that is expensive, certification process is long and market - relatively limited to those users that have N2K systems (%), have interest in seeing N2K data on a computer (% of the above), have interest in non-navigaton N2K data such as engines etc. (navigation data can be more than adequately translated by N2K to N0183 devices, there is absolutely nothing lost) etc.

By that point, whoever develops the system would need to recover the cost, so closing it is not surprising.

That said, I applaud Actisense for going the other route and providing essentially an open system. As far as network goes, if there is a computer available, I would think forwarding N2K data as brought in by Actisense gateway, would be quite easy.

Posted by: PolarNavy at February 13, 2011 9:18 AM | Reply

Well, let's not forget that N2KView can control stuff -- switches, water makers, etc. -- from on or off the vessel. Doesn't that sort of thing need to be secure? What I'm wondering about is some sort of doorway for the simpler needs of other apps. It could even be one-way I suppose.

Posted by: Ben E in reply to Anonymous at February 13, 2011 9:27 AM | Reply

Having used two way unsolicited UDP packages in industrial control I see no real problem with security.

For instance one software package on a ipad could monitor all the navigation devices and display then in the cockpit. Another piece of software could monitor all the boats system information relating to the engine, air conditioning, water and fuel levels and display them appropriately.

With UDP any number of software packages running on any number of computers can listen into the UDP stream without effecting Ethernet bandwidth. Each software package listens only for the UDP packets it is interested in and ignores the rest.

When it comes to control, like switching the water maker on and off, one can use a simple protocol. The software monitoring the boat systems, say, would issue a UDP packet which is translated into an appropriate CAN package by the gateway device. The water maker responds with an acknowledgement and status information which again is broadcast over UDP for all to see.

For security the control functions would only be permitted on certain computers with a simple password function.

When it comes to wider security, that is you don't want the boat next door to switch your water maker on and off, then you use secure wifi.

It would also soon become apparent that you need two Ethernet systems, one for the boat and one for the Internet entertainment. This would be essential if you had radar data over Ethernet.


Tedgo

Posted by: Anonymous at February 13, 2011 10:46 AM | Reply

Maretron could make a driver that takes the data from Ethernet, creates a virtual serial port and converts the PGNs into 0183 sentences output through this virtual serial port. This would allow all legacy navigation software to work with the new IPG100.

In the mean time I'm thinking about an iPad on the bulkhead as our clock and weather station :)

cheers,
Nick.

Posted by: Nick at February 13, 2011 11:17 AM | Reply

Ben, yes you are correct, I was less than specific on the capabilities of the Maretron USB100 and the Actisense NGT-1. In fact, I think the Maretron marketing which describes that the USB100 is an NMEA 2000 gateway is disappointing.

One thing I'd like to add to your comment about the Actisense requiring a driver, is that it seems as though many software developers are supporting that driver, whereas I'm not sure if that is in Maretron's plans. It might be, but I wonder how they could do that for free or open sources programs.

Here's the Actisense compatibility list: http://www.actisense.com/HTML/Products/Gateways/NMEA_2000_PC_Gateway_1/Software.htm

This is a great thread though, I think it shows that the market wants more openness and interoperability over closed or proprietary systems.

-p

Posted by: Patrick - sv Deep Playa at February 13, 2011 1:19 PM | Reply

Ben,

I cannot get my N2KView to show any depth from an Airmar P-79. Gemeco has advised me to unmount the sensor, tape it to a pole and hang it over the side. Which I will do as soon as possible - when the ice melts.
Gemeco sent me the following information concerning using N2KView and the P-79.
"Unfortunately the N2K view system may be limited on what you can configure with any sensor other than one sold through Maretron. When Maretron supplies an Airmar sensor they imbed it with their own signature and the software opens up some options for user configuration. Without the signature I believe you will only be able to view the depth reading, not adjust or offset it. "

Henry

Posted by: HenryD in reply to Ben E at February 13, 2011 9:46 PM | Reply

I am glad to hear about these new releases. The FPG Looks useful, but the IPG is more exciting, as it addresses a major issue that I have had: the USB100/N2KServer combo is quite unstable, at least on WinXP. On multiple machines, I've had to work around server failures and USB issues that result in hardware lock-ups.

Moving the server to firmware makes sense to me, especially as I feel that in general Maretron is better at developing for embedded devices than for computers or mobile devices. For that reason it's a shame that they are still holding their sensors' data hostage. And I have to say that I find the notion that they were "unsure" how to expose that data unconvincing; as multiple Panbots have pointed out, UDP -- hardly a new protocol -- is well suited to distributing rapidly changing data to multiple devices. Waiting for a N2K-over-Ethernet standard to emerge is unnecessary; Actisense went the proprietary DLL route with good success, and Maretron could freely define a UDP messaging standard which other vendors would surely write to, given their leadership in the N2K space.

Henry, what you quote Gemeco as saying makes no sense. The depth PGNs are an N2K standard and don't vary from device to device (not to mention that Airmar is the manufacturer of every N2K transducer on the US market, regardless of whose name is on the box). Furthermore, if you want to configure a Maretron sensor and don't have N2KView, you can use their free N2KAnalyzer, which includes a DSM250 emulator.

/afb

Posted by: Adam at February 14, 2011 2:58 AM | Reply

Thanks, Adam; I think you identified the primary purpose of the IPG100. Maretron is building a hell of a monitoring and control system, though I think there are more sales possible if the system can also support other applications. I will make my case in Miami, where I am headed today.

PS We're getting confused about Henry transducer. Gemeco didn't say that Maretron couldn't read depth from it, just that Maretron gear won't calibrate it. The no-depth issue is an unknown problem, hence the tape-to-a-stick test.

Posted by: Ben E at February 14, 2011 10:52 AM | Reply

I can’t decide if this is exciting or *almost* exciting.

On the one hand, having an IGP100 would simplify my current setup and greatly reduce power consumption. Right now I’m using a Mac Mini (booted to Windows) and a Maretron USB100 to run the cheap version of N2Kview, with an iPhone as the display. It works well and looks slick, but the Mac draws some 80 watts (around 7 amps) and of course requires many steps to start up and shut down properly. Replacing the Mac Mini with an IGP100 would (if it works properly) give me the same functionality but with far less power consumption… and it would turn on and off automatically with the other instruments.

On the other hand, what will I do when I want to start controlling switches and breakers via NMEA2000? Actually, that’s exactly what I want to do now. I know that Maretron sells a more expensive version of N2KView that has this as an additional feature, but the price is far too high – try $2,500 more than my current, relatively inexpensive setup. Frankly, it’s not worth it.
So perhaps I’ll wait. Actually, maybe I’ll try something different. Last night I created my own touchscreen interface on the iPhone and iPad using TouchOSC… in 30 minutes… for free. I then spent about an hour cut-and-pasting a few lines of Arduino code to turn those iPhone commands, transmitted to the Arduino over WiFi, into physical actions via an ultra-cheap Arduino controller. Right now those “physical actions” are just 12V relays, but I wonder if I couldn’t issue NMEA2000 commands almost as easily via a CANBus adapter. The total cost for my touchscreen-enabled, WiFi-enabled, ultra-low-power boat control system? $80. It might be $150 by the time it’s done, but that beats $2,000 and I get more features. Additionally, my quick demo project can currently control non-NMEA2000 devices. My initial experiment was designed to run my bow thruster, windlass, courtesy lights, and electric winches.

While it’s true that few if any people are willing to write code before going sailing, even if it’s really simple code, there is a point to all of this. With wireless networking, touchscreens, and tiny computers everywhere, it really isn’t that difficult to make things talk to each other anymore – and it shouldn’t be so expensive. The leisure marine industry can dramatically increase their sales volume by getting those prices down.

Posted by: Jeff Shukis at February 14, 2011 12:48 PM | Reply

Jeff, my thoughts exactly. Before we leave on our upcoming cruise I'm going to lay in a stock of Arduino parts to experiment with. Unfortunately CANBus is significantly more complicated than just outputting voltages. I would love to see a bare N2K, er, CANBus-controller-on-a-chip that came as an empty vessel as far as PGNs were concerned but handled addressing and the low-level packet stuff and could be hooked to an Arduino for some good ol' serial in-and-out.

On the other side of the coin I hope Maretron sees the benefit of adding user-customizable modules to N2KView: pick some data sources, maybe do some basic math on them, then plot the data on a gauge/bar/time-series graph. If users could upload their modules to an area of Maretron's site, the "ecosystem" that developed around the product could be a significant market multiplier.

Posted by: Adam in reply to Jeff Shukis at February 14, 2011 1:38 PM | Reply

Henry, I also could not see Depth on my Maretron instruments from a old standard horizon dpth sensor connectoed to thenetwork via an Actisense 0183 to 2000 gateway. The problem was the Depth was only beieng seen as depth from the transducer. If I choose to see view that I could but no other depth stats were being seen.


Jeff and Adam, check out this post in the Arduino forum where a guy lays out the chips to build a NMEA 2000 connector shield.

http://arduino.cc/forum/index.php/topic,50893.msg366296.html

-=p

Posted by: Patrick - sv Deep Playa in reply to HenryD at February 14, 2011 1:57 PM | Reply

Paul, you asked about N2k over ethernet. We gave some thought to this when desiging OpenSkipper, and ended up with options to both send N2k over UDP, and also to send N2k within an 0183 text stream over TCP (using the standard AIS 0183 encoding). This latter approach has the advantage of easier compatibility with existing schemes, including mixed 0183/N2k systems, and provides a straight forward upgrade route for developers. This format is documented on our wiki, http://sourceforge.net/apps/mediawiki/openskipper/index.php?title=Main_Page. Would appreciate any feedback Panbo readers have on this. Andrew

Posted by: Andrew at February 14, 2011 1:58 PM | Reply

Thanks for the link Patrick!

It turns out that the hardware is easy. There are CANBus Arduino shields that include the chips required. It's the software that's the problem. There exists a CANBus library for Arduino, but I don't know how much work it would take to mold it into an NMEA2000 library.

Posted by: Jeff Shukis in reply to Patrick - sv Deep Playa at February 15, 2011 12:31 AM | Reply

I've heard from Maretron and have two pieces of good news:

* The IPG100 label is correct and its manual is wrong. It only uses 3 LEN max, a mere .15 amps.

* Even better, Maretron and Airmar are working together (wow) so that DSM250 displays and N2KAnalyzer will be able to configure Airmar N2K transducers. The software upgrade is expected in 30-45 days. And, Henry, I have a list of specifics and setting an offset on the P79 is on it.

Posted by: Ben E at February 15, 2011 1:02 AM | Reply

All developments sounds good but what I want;
I have a totally Garmin N2K setup for my new sailing yacht.

I know the iMux, Digital Yacht iAIS and Seamate Light.
But they are all NMEA 0183 and they are just for ONE wireless iThing.
This Maretron IPG100 isn't open, I don't want to have a computer and the software N2KView on board (expensive and overkill).

I want a (plug and play) wireless N2K solution so that I can use 2 or more iPads/iphones on board.
It is not necessary that they communicate 2-way. Just receiving board-data is enough. So that I can use iNavx or other navigation apps.

Is there somewhere a good simple solution or did someone hear about a brand who is coming with a good solution?

Posted by: André at February 15, 2011 4:54 AM | Reply

I think Maretron is missing an opportunity, at least initially.

It's certainly reasonable to want to have an encrypted data scheme for N2KView for a variety of technical and marketing reasons. But there is no technical reason the device can't spit out both an encrypted data stream, and an open standard data stream. N2K is pathetically slow compared to Ethernet, putting out two Ethernet streams from one N2K stream won't make a dent in the bandwidth available on Ethernet or in the processor doing the translation.

Maretron doesn't need anyone's permission on the Ethernet side of the equation, NMEA doesn't even acknowledge Ethernet's existence. By limiting themselves to just their proprietary data stream they are missing an opportunity to make themselves the standard setters and de facto hub of third party N2K apps.

If Maretron spits out an unencrypted data stream, third party app developers will be all over it and drive demand for the device. And everyone who buys the device, will also have the encrypted data stream, making them a potential customer for future Maretron products.

And by the way, Furuno could do the same thing since their MFDs have both N2K and Ethernet ports, and plenty of processing power; no need to buy another box like the IPG100. I'm less familiar with Raymarine and Garmin, but with both ports it's open to anyone to set the standard for unencrypted PGNs over Ethernet.

This glass is very much half full; time to top it up! Maretron? Furuno? MaxSea? Who wants to define the future?

Posted by: Russ at February 15, 2011 10:33 PM | Reply

(Re N2K being carried in 0183 messages)

Andrew, I was thinking about doing just that, using the standard Encapsulation message type. For those who don't know, these start with "!", and are used (for example) for the AIS !AIVDM and !AIVDO messages.

About the only disadvantages are the slight coding/decoding complexity and bandwidth expansion, but as long as you aren't trying to run these through a slow serial port this isn't a big deal. I wouldn't want to design a new system around this, but for integrating some N2K capabilities in a legacy or mixed system this has some advantages.

Ultimately I don't care how we do it, but an open standard (or commonly adopted practice) for N2K over TCP/UDP would sure be nice.

I'm going to look at the link you mention -- it sounds like we are on the same wavelength.

Posted by: Paul at February 16, 2011 2:06 AM | Reply

Found this wireless solution on internet. Has anyone experiences with this brand, does it work?

SeaGauge - Wireless NMEA 2000 Wi-Fi Adapter (Stand-alone)

http://www.digitalmarinegauges.com/index.php?page=shop.product_details&flypage=vmj_softy.tpl&product_id=46&category_id=20&vmcchk=1&option=com_virtuemart&Itemid=78

Posted by: André at February 19, 2011 11:17 AM | Reply

There are a number of existence proofs of N2K over TCP - Raymarine does it between plotters, as does Furuno, and now Maretron, and probably all the others. There are also people who broadcast AIS data over TCP for all the on-line AIS map programs. Technically it's not rocket science, though there are some interesting issues in how you map CAN device addresses across disparate networks - but nothing that hasn't been solved many times before in other contexts.

The process of standardizing this is pretty straight forward. You write an RFC (Request For Comments) and submit it to the IETF (Internet Engineering Task Force). That's where all IP standards are established including the email we use every day, HTTP that we are using on this web site, etc, etc. The ideal RFC is a collaborative work from several key interested parties. Maretron, Furuno, Raymarine, and Garmin would be an ideal collaborative to establish such a standard.

If this were done then devices could be connected together via ethernet just as they are today with the CAN bus that underlies N2K. The above vendors would be doing themselves and the industry a great service if they did this.

Posted by: Peter at February 19, 2011 5:58 PM | Reply

I would go for a new protocol: NMEA 2000 CANBus packet wrapped as UDP/IP. I'd stick as close as possible with the current NMEA/CANBus format.

This would be delivered as an open source, cross platform DLL (probably written in C programming language) with well-defined API. Much like Actisense is doing...but open source.

This would allow any developer to add NMEA2000/Ethernet functionality to their applications by using a common DLL and API that would build community support and positive traction to the project.

Ideally, NMEA should be driving this initiative (the specifications aspect of it at least) or should have a kind of veto over decisions if not actively involved.

If it's open source and NMEA approved/sponsored, then we will get help from lots of contributors at no cost.

Posted by: David at May 24, 2011 1:23 PM | Reply

Probably stating the obvious but I would think that Maretron would only take an open approach if they can figure out a way to replace their revenue stream from DSM250, DSM800 and N2KView generally.

They would be left with their transducers and gateways which at current Maretron pricing, the competition would soon erode their margins. My take is that Maretron has no choice but to hold their existing strategy because the volume of sales available in the current market just isn't big enough to support their overhead and deliver a fair and reasonable profit.

In my mind the IPG100 is a good solution provided that it can also support commands from an Idevice.

Now if Actisense were to deliver a NMEA-2000 to Wifi internet gateway at a reasonable price (say under $300), I would expect to see a plethora of Android/Idevice apps emerge. At that stage, I would think that Maretron might need to look at changing their position.

Posted by: outbackgary at June 4, 2011 7:08 PM | Reply

Leave a comment