Main menu

Post navigation

NMEA 2000 and the Obverse of Open Source

In discussion of the GPSD project, a commenter suggested that its role might be going away in part because the NMEA 0183 protocol historically used in GPS sensors is being replaced by NMEA2000. So far, this is not true, and the reasons it’s not true are worth a look because they illustrate a sort of flip side of the economic and technological tends driving the adoption of open source and open protocols in the wider technology market.

NMEA0183, the quasi-standard protocol historically used by GPSes reporting over serial and USB links, is horribly badly designed. The awfulness of NMEA0183 and the various proprietary vendor protocols competing with it is a major reason that GPSD fills a need.

One might expect, then, that a major redesign of the protocol would be an occasion to rectify these design failures, and that rectification would trigger a concerted rush to adopt NMEA2000 as players in the GPS market sighed with collective relief. And NMEA, the National Marine Electronics Association, would certainly like you to think this is happening.

In fact, uptake of NMEA2000 has been so poor that there are only a tiny handful of GPS sensors supporting it, all of them tightly coupled to the proprietary physical network specification of the protocol and (so far) used only in specialized marine systems. Uptake in the more general GPS market has been zero; we at the GPSD project have received no requests for NMEA2000 support, and as far as we can tell, the Pacific-Rim companies that produce the bulk of consumer-grade receivers have completely ignored it.

As it turns out, there are actually pretty good reasons for them to ignore NMEA2000. One of the major ones is revealed by a class of products specifically marketed to users of existing navigation software that offer to gateway from NMEA2000 physical networks to USB, translating NMEA2000 packets on the fly to NMEA0183 sentences that existing software can read. The fact that this is possible reveals that NMEA2000 adds little information and little value to the contents of an NMEA0183 stream of navigation data.

Another reason for the specialized gateways: the coupling of NMEA2000 to a proprietary physical network is so tight that there is no standard for shipping it over USB, RS232, Ethernet, or any of the other physical networks commonly used in the general computing market. GPS vendors serving that market would have to be plain nuts to abandon the userbase around those physical networks for a protocol that doesn’t serve them.

Yet a third problem with NMEA2000 (for anyone outside the NMEA vendor cartel, anyway) is that the NMEA2000 specification itself is proprietary and expensive. In theory NMEA0183 was, too, but there’s a difference: enough information about it leaked out, in the days before aggressive IP lawsuits over protocols were common, that conforming to it became easy and a widespread practice. That leakage was assisted by one of the few good things about NMEA0183, the fact that it’s textual and easy to read with a Mark One Eyeball. NMEA2000 “fixes” that; its packet format is unreadable binary goo.

Taken all together, these features of NMEA2000 are a classic case study in how to design an application protocol for as little uptake as possible. Add little or no value to existing protocols, tie it tightly to a specific physical networking scheme, make the specification expensive and proprietary, and make it opaque binary goo.

I’ve often made the point in the past that open source and open protocols grow markets and create opportunities. NMEA2000 sharply illustrates the obverse of this point. All of these major choices were made in the opposite direction from the way we’d do it in the open-source tradition, and the effect is to shrink and lock down the market it addresses.

It’s not clear whether this constitutes a failure on NMEA’s part. The not-very-well-hidden purpose of NMEA is to sustain a technology cartel protecting the major marine-electronics vendors. NMEA2000 probably tightens the NMEA’s control of that particular market; therefore, they may very well not care that they’re getting no adoption elsewhere, not even in parallel vertical markets such as aviation systems.

Back when NMEA2000 was just a heavily-promoted gleam in NMEA’s eye, we at the GPSD project thought for sure we’d have to support it when it actually issued. This didn’t particularly bother us – ho hum, another stupid fscking vendor binary protocol, another reverse-engineering job, another logic path in the autoconfiguring packet sniffer, yeah, so what else is new?

Now it looks like NMEA has done such an effective job of walling off their garden that we’re never going to have to deal with it. It’s not that they’ve locked us out of marine navigation, even, just that the applications that might use GPSD will all be sitting on the near side of those NMEA2000-to-USB gateways.

And in the general-purpose GPS-receiver market that GPSD serves, NMEA2000 is not going to be a factor. Not until and unless it’s decoupled from its physical network, and probably not even then – not enough value-add there for the vendors to move.

The final question NMEA2000 raises, one which has its own open-source implications, is how much NMEA’s retreat into a fortified position is going to cost its vendors in the long run. Is the market for general-purpose GPS sensors declining or growing? We do know that handset GPSes are being rapidly killed off by smartphones, though that in itself affects GPSD very little since the handset users never needed us in the first place; the question is whether GPSes in smartphone-like devices are going to kill off the sort of receiver that has a USB or serial cable hanging off it.

This reflects a larger question about how much tightly-integrated bespoke systems like smartphones and proprietary marine networks linking special-purpose devices are going to replace the sort of general-purpose computers that have serial and USB ports. Open-source software in general (and GPSD in particular) thrives in loosely-coupled systems of general-purpose computers and doesn’t do as well in the sort of world that NMEA and proprietary smartphone vendors want to create.

So the last lesson of NMEA2000, and an encouraging one, is how atypical and archaic it looks in 2010. Binary packets instead of HTTP? Wacky proprietary physical layers? This is not the direction the rest of the Web-enabled, Internet-centric world is moving. And as for GPS sensors with cables, smartphones don’t seem to be inhibiting the pace of new-product launches one iota. If anything, the increasing visibility of location-aware apps on smartphones seems to be driving more demand for standalone sensors. This may seem counterintuitive; why should that be?

I think it reflects a fundamental economic law; when a technology like GPS gets cheap, every use case for it attracts more money and more vendors as people find uses for both loosely-coupled and tightly-integrated versions of it that create new goods and substitute for more expensive old ones. Smartphone GPSes and the sort with cables aren’t in zero-sum competition after all; they’re complementary goods that indirectly stimulate demand for each other. Really we should have known this years ago from observing the demand for handset GPses.

That means that, ultimately, NMEA has made the wrong bet. They’ve chosen to be the big frog in a small pond. It means that GPSD is going to continue to have devices to reverse-engineer and a role to play for the foreseeable future. And, more generally, it assures us that the sort of loosely-coupled computer systems in which open-source software has a starring role will continue to attract increasing investment.

78 thoughts on “NMEA 2000 and the Obverse of Open Source”

I don’t know the history (googling didn’t turn up anything quickly) but I wonder if NMEA2000 was designed with automotive uses in mind? The CAN bus is widely used through the automotive industry and other embedded apps. Perhaps their thinking was a little different: seeing that GPS chips were becoming ubiquitous they opted to create a protocol that’s more suited to a limited computing environment.

From that perspective, potentially it’s a “punt” on trying to improve the protocol for something like GPSD. As you noted, no new data is output with NMEA2000. Perhaps they envisioned receiver manufacturers using CAN methods to extract the data and then come up with their own USB or RS232 messages.

>I don’t know the history (googling didn’t turn up anything quickly) but I wonder if NMEA2000 was designed with automotive uses in mind?

Pretty clearly not; the NMEA2000 message inventory is totally wrong for that. But I think they did choose CAN in order to avoid the NRE for designing a new physical-layer network that’s tolerant of industrial conditions. Of course, they could have used a ruggedized version of USB, but might have left the technology and the market too open for their taste.

Do they get anything at all useful out of their tight physical binding? What on Earth do they need that can’t run across a bytestream? An entire several-dozen-bytes-per-second bytestream, of the type that may have stressed computers in the late 1950s?

Notice they are NMEA2000 compatible devices. I’m willing to bet they don’t have x86’s running in them. From that perspective, bytestream computing gets expensive because it could be the difference in using a cheaper micro for the product.

JB, if you asked I’m sure they would hand you an elaborate line about the special needs of marine and industrial networks – physical layer tolerance for temperature extremes, salt and corrosive vapors, vibration resistance in the connectors, etc.

JB, if you asked I’m sure they would hand you an elaborate line about the special needs of marine and industrial networks – physical layer tolerance for temperature extremes, salt and corrosive vapors, vibration resistance in the connectors, etc.

Yes, and for their market, they would probably be right. For the electronics and cabling sold with the boat, as with a car, you need it to work for and last the warranty period, at least.

CAN is probably actually an excellent choice for a boat-area-network, and for GPS attached to that network. You can mount the GPS top-side where it has the best position for antennas, and not need any special cables that are not already being used for boat control. CAN is proven technology that is cheap, rugged, and robust in an electrically and physically harsh environment.

I agree the whole trying to lock up the spec thing is ridiculous, but this happens in general purpose computing, too — SD cards, for example, where they only relented and published a redacted version of the spec after that much had already been reverse-engineered.

You’re absolutely right in that you probably won’t have to directly deal with NMEA 2000 for a very long time, because the laptop probably sits in the dry cockpit and plugs into the CAN network through a USB converter, so it’s no big deal.

Perhaps you haven’t been exposed to this market, but you can get embedded microcontrollers from at least 20 different vendors that can talk CAN, starting at well under a buck, and they’re all high-reliability, to try to take some of the huge automotive market. The actual CAN transceivers are practically a zero-cost adder; GPS vendors can probably tackle the CAN and USB markets with a single design these days, and the money they have to pay for a license is peanuts, so they don’t really care that you can only directly interface with the USB version. I could be wrong, but I don’t see that these people are really walling themselves off.

Of course, they could have used a ruggedized version of USB, but might have left the technology and the market too open for their taste.

USB can only go 5 meters tops before you need a repeater/hub, and it’s single-master, not a network. The PID is not very well protected; just some bit inversions. Some of the messages only have a 5 bit CRC. I don’t think you could really “ruggedize” it without completely changing it. OTOH, I don’t think they have altered CAN in such a way that current controllers won’t work for NMEA 2000 — they’ve just changed the messages AFAIK.

Going with CAN for this, if it’s intended purely as a boat-area network, is easily defensible. A lot of folks have put a lot of time, effort, and money into making CAN a reliable data transport for very harsh environments both physically and electrically. Economies of huge scale also come into play because every car manufactured for sale in the US in the last several years has been required by law to use CAN for their computer interfacing. This makes CAN hardware dirt cheap. Why wouldn’t NMEA leverage that?

If that’s the scope of NMEA2000, then no, it’s not going to displace GPSD – because it addresses a different problem set.

It’s good to see the other commenters here correct/educate you about CAN. CAN is not the enemy (a variant of it is used to read out the speed of the memory on your DIMMs, and there are open source projects that connect into CANbus architectures.

As others have correctly noted, USB is not a good architecture for a network of sensors and controllers. You could have picked Ethernet and made an argument (you would have lost that argument, but it would have taken a while). Picking USB just shows how little you know about some segments of the industry. Not all the world is a PC.

Yes, NMEA is attempting to put themselves in a position to collect rents for access to the space. They’ve trademarked the term “NMEA 2000″, you you cant even claim compatibility without paying them for (and passing) their testing.

> if you asked I’m sure they would hand you an elaborate line about the special needs of marine and industrial networks

Eric, how many boats do you own? How many industrial (machine control) networks have you designed?

@Gary> “As you noted, no new data is output with NMEA2000.”
Um, no. Unfortunately there are all sorts of new proprietary PGNs coming from the brand name manufacturers.

@esr> I’m also curious about your title. Generally the side of a coin with the larger scale image will be called the obverse (especially if the image is a single head).

Finally, the growing presence of NMEA2000 is only one of the challenges I outlined for GPSD, and, given it’s inherent limitation to the marine marketplace, the least significant of the set. You may wish to re-read what I wrote, “marine units that talk NMEA-0183 are going away in-favor of NMEA-2000″.

GPSD’s other challenges:

1) While the mass market for GPS devices is moving to cell phones (especially ‘smart phones’), GPSD has no presence in the phone market.
Thus, GPSD has no presence in the single largest growing segment of GPS devices.

2) the OS makers for these cell phones all have their own APIs for accessing GPS data. CoreLocation on iOS (and now MacOS X), android.location (http://developer.android.com/guide/topics/location/index.html) on Android, Symbian Python applications use the positioning module to get information from both built in and external Bluetooth GPS receivers, and GeoClue / Qt Mobility on MeeGo.

None of these are GPSD-based.

3) GPSD is changing in ways that break compatibility with existing programs that use it. It remains to be seen how much ‘uptake’ there is by the applications that use GPSD.

and, finally,

4) NMEA is attempting to move the world away from the 0183 ‘standard’ to NMEA 2000. This will, likely, eventually close the top half of the marine market to GPSD unless GPSD gets some CAN-interface work done, as well as elementary ability to process the ‘known’ PGNs.

Jezus: Garmin’s boat communication system uses 100Mbps Ethernet. They don’t call it that because they don’t want to support J. Random Shit connected to their network, but that’s what it is. So not only might esr not have lost that argument after a while, he probably wouldn’t have lost it at all.

You can always use a trademark truthfully. You can claim that you are compatible with NMEA2000.

esr: Jezus is right about boat networking. RS-232 is a major major headache. NMEA2000 is a vast improvement. Connectors carry power and are sealed against water. It’s not “a line”, it’s harsh reality.

On the other other hand, I know of no PC interface to NMEA-2000. They translate it into serial NMEA over USB. So yeah, at least until there’s hardware to let a PC talk natively to NMEA-2000, gpsd can successfully ignore it.

One of the things I think is interesting about this is to consider it in the broader context of what you have argued in the past and in your many writings. Your public argument has often consisted of “use open source because it has a positive benefit to your business”, and you have avoided arguing “use open source because hiding your source code, or putting your data in jail is immoral” the latter argument being left to the scruffy one from Boston. (BTW, I am pretty sure you believe the second argument too, though you might use a different word that “immoral.”)

Yet, NEMA believes that closed source is better for them in this case, or perhaps they believe closed source is better for them right now, and they might have judged correctly. This should be understood in the context of what “better” means. There are various definitions of “better”, such as more usable, more widely adopted, more flexible and so forth. But there are other definitions of “better” too, such as more profitable, more satisfying for members of my constituency, more able to maintain the putative importance of my organization, or more likely create difficulty for my competitors.

I don’t know much about the particulars of NEMA, or gps protocols, so I don’t know if they judged rightly here, or whether their judgment was based on lack of fully considering the alternatives. However, I thought the more general point worth making. I agree that organizations often have a visceral desire to lock it down, but it is not always the wrong decision, for some values of “better.”

Everyone should feel free to apply their own chosen moral code to the various possible values of “better.”

Nice strawman, there. Of course CAN is not the enemy, but organizations like NMEA often are. And as Russ Nelson points out, the reasons for bespoke “industrial” networking like CAN are historical, not technical.

>Unfortunately there are all sorts of new proprietary PGNs coming from the brand name manufacturers.

Sure are, most of them irrelevant to navigation – stuff like water temperature and salinity sensors, engine RPM monitoring, fish-finder sonar, etc.. About the only new class of data interesting to GPSD’s userbase is magnetic compasses and accelerometers. (I’ve picked up a fair amount of knowledge about the data flow on boat systems as a side effect of researching AIS gear.)

>I’m also curious about your title. Generally the side of a coin with the larger scale image will be called the obverse (especially if the image is a single head).

I’m surprised you’re unaware of the word’s pre-numismatic history. It originally referred to the side of a shield facing the bearer, and has long been used in ways that are ambiguous between “reverse of” and “side facing the observer”. I used it with that ambiguity in mind.

>You may wish to re-read what I wrote

You know, Lizzard, it isn’t all about you.

>it remains to be seen how much ‘uptake’ there is by the applications that use GPSD.

Actually, that question is already answered. We’re seeing 100% migration in the dozen or so client projects we keep an eye on. It’s not like they had much choice, really; they all know very well they don’t want to be down in the muck that GPSD handles for them, and we haven’t really got any competition.

There has only been one even semi-serious effort to compete with GPSD, a project called Gypsy that booted up because the founder thought the splint annotations in the GPSD code were too ugly. (No, I’m not joking or exaggerating.) Near as we can tell it’s stalled out and moribund – no commits in six months. I don’t think its founder had any clear idea of what he was facing; the amount of domain knowledge and experience that would be required to even nearly duplicate what GPSD does is immense.

>This will, likely, eventually close the top half of the marine market to GPSD unless GPSD gets some CAN-interface work done, as well as elementary ability to process the ‘known’ PGNs.

The blocker here is really the capability to get CAN packets onto some network medium that a PC can talk to. If we had access to test-load bits and a description of the known PGNs, it would be a SMOP no different than what we usually do about vendor binary protocols. Here’s how that works: when and if there’s actual demand, someone will show up on our mailing list with a use case and a test load, and one of our three senior devs will bring up a CAN driver in less than a week.

I’m not claiming that you don’t need a good rugged electrical standard for a boat or anything else. What I find bizarre is that the standard is integrated? (If it is.) Bits are bits, in the end; there’s high quality and low quality and fast and slow ways to transmit them but there’s no really good engineering reason to bind such a small, slow stream to any particular physical protocol right in the spec. (As compared to something like Firewire when it was first proposed, since the entire purpose was to be a very high-speed protocol and the physical details actually mattered to its core use case.)

> You can always use a trademark truthfully. You can claim that you are compatible with NMEA2000.

Point in fact, you can’t, at least not in this instance.

You may be confused by “fair use” rights. The Lanham Act permits a non-owner of a registered trademark to make “fair use” or “nominative use” of a trademark under certain circumstances without obtaining permission of the trademark owner.

Fair use may be asserted on two grounds, either that the alleged infringer is using the mark to describe accurately an aspect of its products, or that the alleged infringer is using the mark to identify the mark owner. One of the most visible proofs that trademarks provide a limited right in the U.S. comes from the comparative advertising that is seen throughout U.S. media.

Those are CAN bus, not NMEA 2000. I repeat: I know of no PC interface to NMEA-2000. Next time, object to the thing I wrote, not the thing you imagined I wrote. Please go back and read what I wrote again so that you can reply more effectively.

And my first name very clearly has two L’s in it. No excuse for poor spelling.

AND, yes, you can claim that you are compatible with NMEA-2000. The text you quoted does not contradict my assertion. I think your big brain is overheating.

Fair use may be asserted on two grounds, either that the alleged infringer is using the mark to describe accurately an aspect of its products, or that the alleged infringer is using the mark to identify the mark owner.

Wouldn’t both cases potentially apply to a claim of compatibility with NMEA2000?

the alleged infringer is using the mark to describe accurately an aspect of its products

“One aspect of my software library product that gives it an advantage over competitor libraries is that it is compatible with NMEA2000″ (assuming you are 100% compatible or you can water the statement down in the same way that advertising always does)

the alleged infringer is using the mark to identify the mark owner

“This product is compatible with many protocols released by NMEA (who have released NMEA-0183 and NMEA2000)”.

AND, yes, you can claim that you are compatible with NMEA-2000. The text you quoted does not contradict my assertion.

Mr. Nelson is correct here, Lizzard. Just as Linux can claim to be (mostly) POSIX-compliant, without claiming POSIX certification, a software program could claim compatibility with NMEA-2000 as long it was true, without claiming NMEA-2000 certification and using the logo, etc. All the chest puffing in the world isn’t going to change that fact. Another example: Samba claims compatibility with WIndows and CIFS, but it doesn’t use the “Made for Windows” logo, sticker, etc.

@esr:

One of its core techniques – the autoconfiguring packet sniffer – is an original invention that would probably be patentable, if I were of such mind. Which I’m not.

What about having a defensive patent? What happens if some big company decides that it’s going to do something similar and patent it and then start suing anyone using GPSD as part of their hardware product? You may have provable pre-existing art, but it doesn’t matter if the companies decide to settle out of court. Just a thought. The SCO case raised my patent radar big time.

Yet, NEMA believes that closed source is better for them in this case, or perhaps they believe closed source is better for them right now, and they might have judged correctly.

I don’t know what the right words are for this, but it’s not really “closed source” — at least, not in the sense of a company like Microsoft that won’t share at all. It’s not even really source code, and it’s freely available to anybody who pays. This historical model is the same as ANSI, the IEEE, the EIA, ITU, ISO, etc. Historically, none of these standards were free, though, for example, ITU has experimented with giving people a few free documents a year (haven’t looked to see if they still do), and IEEE now gives out some specs. Things like USB are anomalies; Intel viewed that it was better from a pure marketing perspective to open it up. Things like the Internet RFCs come from a different background, but typically only describe the software layers in any case.

Shoot, if you want “official” C, in theory, you have to pay ISO for the standard. Even the full set of NMEA 2000 specs includes some that they have to pay ISO for. And although TCP/IP protocols are described by RFCs, if you want 802.11 specifications, you used to have to pay the IEEE, although I think some of these are free now.

So, historically, hardware people got together and designed specs, and these organizations are, in some ways, the equivalent of the academic peer-reviewed journals. Money to support them has to come from somewhere, and historically, a lot of it has come from the sale of specifications. Disintermediation is starting to happen, but it’s a slow process.

But, unless somebody knows something about NMEA that I don’t, the specifications are copyrighted, but are not trade secrets. Unlike, say SD cards, I don’t think you have to sign an NDA to get a copy of the specification, and just like with C or Verilog or JTAG or whatever, I think you could write a book explaining things about the specs.

So, it’s no fun to have to have all the major contributors on an open source project needing to spend money for the specs, but it’s (IMO) a completely different situation than with closed source software.

@Jeremy:

Bits are bits, in the end; there’s high quality and low quality and fast and slow ways to transmit them but there’s no really good engineering reason to bind such a small, slow stream to any particular physical protocol right in the spec.

But, the whole point is to define a (preferably single, standard) way for disparate marine equipment to interoperate — surely, that requires physical transport of the bits?

JonB: What Russel(l) said was, “You can always use a trademark truthfully. You can claim that you are compatible with NMEA2000.”

My question: “How do you know, unless you understand the spec, and you’ve tested things?

I don’t think anything keeps anybody from getting a copy of the spec (except money). I’m sure that some level of testing will happen if somebody ever decides to make the claim, because that somebody’s reputation is on the line. If it doesn’t work, well, people tell little white lies all the time. NMEA certainly won’t care, as long as you don’t use the word “certified” or their logo:

NMEA 2000® is a registered trademark. NMEA 2000 can only be used by
authorized license holders. NMEA 2000 Standard is a Copyrighted Work
and is protected under all of the copy right laws and treaties. There is a
NMEA 2000 Pending Logo which may be used while products are under
development. The time frame is 6 months for the “Pending” usage. Since
the marine electronics industry has embraced “Certification,” the words
NMEA 2000 “compliant” or “works with” NMEA 2000 will not be
recognized as NMEA 2000 products.

>What about having a defensive patent? What happens if some big company decides that it’s going to do something similar and patent it and then start suing anyone using GPSD as part of their hardware product?

Prior art and abuse of patent. Nobody even remotely sane would ever want to get into a public pissing match with me over something like this; I’m way too well known and I’m known to have lots of allies and favors I could call in. They’d be utterly outclassed by the coalition I could put together; their troubles would only start with being crucified in the press.

Generally the side of a coin with the larger scale image will be called the obverse (especially if the image is a single head).

Yes, in the domain of coins, that is the primary meaning of the word “obverse“:

1 : the side of a coin or currency note bearing the chief device and lettering; broadly : a front or principal surface2 : a counterpart having the opposite orientation or force ; also : opposite 13 : a proposition inferred immediately from another by denying the opposite of what the given proposition affirms

It seems to me that ESR’s usage falls within definition 3, with some 2 flavor as well.

When someone uses a word with multiple definitions, to choose one of the definitions and declare that it doesn’t apply, and therefore the person who used that word did so incorrectly, or their argument is somehow invalid, is intellectually dishonest. It is of a piece with the standard Leftist fallback position: “My side has good intentions, and our opponents hate ${VictimClass}.” As proof, they decide what we “mean” when we use words that admit of multiple meanings (most English words do). Language doesn’t work that way.

>It seems to me that ESR’s usage falls within definition 3, with some 2 flavor as well.

Interestingly, I was actually unaware of formal usage 3. I was being more metaphorical to similar effect.

I conjecture that usage 3 is primarily historical, like the elaborate terminology surrounding Aristotelian syllogisms in scholastic logic; no blame to Lizzard for not knowing it. I, on the other hand, was at one time a logician and thus probably should have.

Jezus: well, yes, that IS the question, isn’t it? So when the manufacturer claims compatibility any charges of incompatibility fall on them, not the trademark-holder. And that’s all that trademarks are designed to do: protect trade. Hence the name “trademark”. Forstår du me?

Autodesk takes its proprietary DWG file format VERY seriously. Bottom line is, you can’t make software that consumes or produces DWG files unless you pay their royalties and are not considered a competitive threat. The term DWG is trademarked by Autodesk; claiming DWG compatibility without authorization will land you in court. Autodesk does litigate trademark cases relating to the DWG mark; all of the companies they’ve sued so far have settled, and publicly acknowledged Autodesk’s rights to the DWG mark. Autodesk embeds a string with the trademarked names “Autodesk” and “DWG” in it, so you’re infringing just by implementing DWG without authorization.

In short, the big boyscan and will use trademark law this way. And if you’re Joe Open Source , it won’t take much for them to stop you just by breaking your bank.

@ESR: “That means that, ultimately, NMEA has made the wrong bet. They’ve chosen to be the big frog in a small pond”

Why have they made the wrong bet? The M in NMEA stands for “Marine”. Why should they care whether their standards are well suited for applications outside of their industry. They exist to look after the interests of the Marine Electronics industry, and you can’t really fault them for exactly doing that.

> Prior art and abuse of patent. Nobody even remotely sane would ever
> want to get into a public pissing match with me over something like this;
> I’m way too well known and I’m known to have lots of allies and favors I
> could call in. They’d be utterly outclassed by the coalition I could put together;
> their troubles would only start with being crucified in the press.

Autodesk takes its proprietary DWG file format VERY seriously. Bottom line is, you can’t make software that consumes or produces DWG files unless you pay their royalties and are not considered a competitive threat.

As of AutoCAD 2007, Autodesk implements what is known as “TrustedDWG” technology. The difference between a TrustedDWG and an “untrusted” DWG is that TrustedDWG files contain the text string “Autodesk DWG. This file is a Trusted DWG last saved by an Autodesk application or Autodesk licensed application.” If AutoCAD does not see this string, it will warn the user of “stability problems” when attempting to open the file. Only Autodesk applications and applications which use Autodesk’s licensed RealDWG library can legally do this. If you put the magic text string into an unlicensed product, you will be sued for trademark infringement. Autodesk sued the Open Design Alliance over precisely this issue, and ODA settled with Autodesk on Autodesk’s terms.

> Only Autodesk applications and applications which use Autodesk’s licensed RealDWG library can legally do this.

That’s their position, but it’s probably legally unsupportable. A hidden string in a data file (or the program that writes the data file) is unlikely to be a trademark infringement, and to the extent it’s copyright infringement, it is fair use for interoperability.

That’s their position, but it’s probably legally unsupportable. A hidden string in a data file (or the program that writes the data file) is unlikely to be a trademark infringement, and to the extent it’s copyright infringement, it is fair use for interoperability.

I checked into it some, and as things stand now you’re right. The ruling in Sega vs. Accolade seems to suggest that using trademark law to prosecute people who reverse-engineer for interoperability is a big no-no.

But anyone who wishes to test this with DWG files would find themselves up against Autodesk’s legal team, the same team that successfully invalidated the first-sale doctrine for software. They could probably venue-shop and loophole their way to a favorable ruling on the trademark issue too.

>> I’m confused. Why would anyone purchase the 0183 specification from NMEA when
>> you’ve documented everything for free?
>
> Would that it were everything. Far from it; it’s just what I could find out.

NMEA-0183 is a large spec and encompasses much more than just GPS equipment. It also defines sentences for sonar, autopilot, compasses, gyro’s and timekeepers among others. Part of the sentences are a 2 character sequence that identifies the sending device. I have a copy of an unofficial spec with 34 such identifiers and the document makes a point to say it is far from complete. So if someone needs to work with say, a “velocity sensor” or a “turn rate indicator,” an official spec would be required.

I wonder. If a program embedded the following within the files it generates:

This file was last saved by $Software. For full interoperability with other software, the string
“Autodesk DWG. This file is a Trusted DWG last saved by an Autodesk application or Autodesk licensed application.”
is required. The inclusion thereof within this file does not represent any endorsement, affiliation, or license from any company for $Software. It is quoted here verbatim solely for compatibility.

could any judge find that the trademark was infringed, given the explicit disclaimer that $Software is not in any way affiliated with the mark holder?

If not, have I just violated a trademark, and if they send a cease-n-desist to ESR and he doesn’t wipe out my use of the offending words, has he, as well?

How freaking hard would it be to generate a block of text that does not include the trademarks, so that some completely separate program could come along and change it later? That separate program would never be packaged as part of the software, but everyone who used it would know where to find the handy utility that fixes the files.

But anyone who wishes to test this with DWG files would find themselves up against Autodesk’s legal team, the same team that successfully invalidated the first-sale doctrine for software.

Yeah, I’m aware of the “Trusted DWG” stuff and this history surrounding Autodesk’s legal history. I wouldn’t say everything was totally settled on Autodesk’s terms. The trademark angle won’t work because Autodesk basically lost the ability to trademark DWG and anything containing DWG since the USPTO ruled that DWG was a file format and that the term was descriptive, rather than something that can be trademarked.

I suspect that if the USPTO doesn’t give Autodesk its trademark back ODA will either reneg on their agreement with Autodesk or they’ll sue Autodesk for anticompetitive behavior or some other antitrust-type angle.

Autodesk is the Microsoft of CAD: they’ve enjoyed a virtual monopoly in the PC CAD market. But they won’t last long; a big chunk of their customer base is moving to SketchUp, Google’s attack-from-the-bottom CAD system that has some of the same high-end features found in the workstation CAD market (CATIA, NX, etc.), first and foremost being support for parametric solids and dynamic components.

It’d be real nice to open source do well here, but the sad fact is that there are simply not enough open source developers competent in 3D CAD system design because, like desktop audio and video, it’s viewed as a ‘hard problem’. I’d like to change that, but I don’t even know where to begin, to be honest.

> I wonder. If a program embedded the following within the files it generates…

Without knowing anything about the file format, I cannot comment on whether this could be done in a reasonable fashion or not. It depends on how the file is parsed, and in any case the standard parser could be modified quickly to start producing warnings on this again.

No, the right answer is, if anybody cares, to spend the money on the lawyers, do your own forum shopping, and sue Autodesk before you ship something that uses their format. In fact, since there is this open source project, it would be trivial for someone to want to create software using it to create a “genuine controversy” with Autodesk. Autodesk would claim in court documents that there wasn’t a genuine controversy, but you can bet your bottom dollar they’d fight it tooth and nail like it was.

Something for an up-and-coming lawyer to think about, if he wants to make a name for himself.

That means that, ultimately, NMEA has made the wrong bet. They’ve chosen to be the big frog in a small pond. It means that GPSD is going to continue to have devices to reverse-engineer and a role to play for the foreseeable future. And, more generally, it assures us that the sort of loosely-coupled computer systems in which open-source software has a starring role will continue to attract increasing investment.

As Jay pointed out, I think the issue here is that you have the idea that NMEA cares about the non-Marine market at all.

NMEA is not trying to solve the “using-a-GPS-with-your-computer issue”.

They’re trying to solve the “make the systems on your boat work together every time, all the time” issue.

NMEA is not trying to make sure that everyone using GPS loves NMEA, or that every GPS speaks NMEA-2000, or that nobody has to use GPSD; they don’t give a damn about any of that. What they’re doing, and quite successfully, is making sure that every marine GPS system speaks the same protocol and uses the same robust, proven, salt-and-water-tolerant bus. And that every other piece of boat-attached electronics that you care about does the same thing, compatibly.

In other words, while you believe they should go after the entire market with the new protocol, they disagree, and are concerned only with marine applications. Wait, what does NMEA stand for again? Oh, right…

(I mean, look at this diagram from the Wikipedia NMEA article. Now, you could probably rig up a “yachtLAN” using ethernet, perhaps over fiber to prevent corrosion, but that’s still not obviously superior in durability to SAN. And then there’s the question of how they’re going to talk to each other; it’s not obvious that IP is the answer.

The NMEA2000 protocol, SAN, and DeviceNet stuff seem to have been designed from the ground up [admittedly not all TOGETHER] to solve exactly this sort of semi-industrial problem; perhaps the dedicated and specialized approach is actually superior from the user point of view in this case.

I know I’d prefer the NMEA/SAN/DeviceNet setup for vital boat functionality over “just use commodity ethernet and some IP and hack together a server to coordinate it all with a web interface” or whatever the immediate “open” alternative is. [An eventual "open" system might well match and then exceed the NMEA and SAN combination, but it ain't here yet, and boats still need electronics right now.]

And in any case, NMEA2000 is still going to be an improvement over the old vendor-specific proprietary industrial networks.)

They’re a trade association of marine equipment manufacturers, obviously. NMEA got create the defacto standards for the GPS market largely because the earliest application for civilian GPS use was, in fact, as replacement/supplement for LORAN.

With GPS converging with smartphones, at least for car and handheld GPS use, it seems there would be room to create a protocol to compete with or entirely replace NMEA. Maybe this is what GPSD aims to do?

@esr: But would it have maximized their profits? Right now the chinese GPS vendors are effectively locked out of the Marine market. The stand-alone GPS unit is functionally a short-term market in the consumer space as smartphones are eating that market so it’s not a good bet for expanding profits, Garmin all but owns the recreational aircraft market and the automobile market is pretty much tied up as well and high-end Aerospace is also tied up. Exactly what market would NMEA members net their increased profits from? NMEA itself isn’t interested in profits, it exists to enable its members to make money.

What I’m seeing here is that NMEA has functionally blocked anybody from getting into the Marine market without joining up. Given that its members are mostly dedicated to the Marine market and would not be in a position to grow outside of it (based on the board members companies, they’re all small to midsize businesses) I’d say they’ve pretty effectively done exactly what they set out to do.

The only way I could see an open protocol changing things is if it was promoted by a major maker (Garmin would be the only likely candidate) from outside NMEA looking to disrupt the market. But Garmin’s already got their own robust bus protocol from their Aircraft business.

> It’s not a question of belief or disbelief on my part, but of what would have maximized their profits.

The bulk of the guts of the GPS is being commoditized as we write.

You can already by a no-name GPS receiver for your car online for $55.00. Profit on that is probably $5.00, maybe less, maybe even negative. Let’s call that the “Nokia” strategy. If you can sell a higher-quality boat GPS for $1000, but at $850 profit, maybe that’s the “Apple” strategy. Maybe if you’re Apple, you’re just buying the same chips as everybody else, but selling good industrial design into a niche market. Or maybe, since your designers are sitting around anyway, you sell into the Apple market as well as the Dell/HP market…

The thing is, if you’re manufacturing/selling a high-end boat, you want all the gadgets to work together. It’s probably like cars where the add-ons are very excessively priced, so there’s enough money there sloshing around to slosh plenty to the electronic instrumentation designers. And, if any of those designers whined about the price of specs, the boat manufacturer would find a different, more serious, instrumentation company.

Would it be nice if the RFQ from a boat manufacturer specified that the GPS must support GPSD? Sure, but that only solves a small piece of the puzzle. Could open source solve the whole puzzle? Sure, but the boat manufacturers don’t want to be in the software business at all, and the boat equipment vendors want to maintain their rents by being in the proprietary software business. And the customers? If somebody splashes out half a million on a boat and really wants to hack on it, what’s a couple of thousand for specs?

Nothing changes, unless one of the equipment manufacturers decide that they can increase market share (or decrease support costs) if they fully document their interfaces (which is most probably perfectly legal if they don’t reproduce the NMEA docs). This is most likely to be a new market entrant. Then the others will follow, and the lack of a copy of the official specification becomes moot.

The stand-alone GPS unit is functionally a short-term market in the consumer space as smartphones are eating that market so it’s not a good bet for expanding profits

I think this premise is false. Reread the original post and my remarks on complementary goods.

Technological convergence of two product types doesn’t necessarily mean that one of the product types goes away. For example, we were promised convergence between TVs and PCs and the Internet in the 1990s. Did the convergence never happen? No, it happened. TVs got more computer-like and set-top boxes became more PC-like and PCs got software that could turn them into set-top boxes, cheap broadband proliferated and the Internet got YouTube, Hulu and Netflix. These devices and services are complimentary rather than competing and they help drive each other’s sales.

Similarly, GPSes will get more features found in smartphones, and smartphones will get more features found in GPSes, but I also doubt we’ll see either product category disappear any time soon, for much the same reasons.

>It’d be real nice to open source do well here, but the sad >fact is that there are simply not enough open source >developers competent in 3D CAD system design because, >like desktop audio and video, it’s viewed as a ‘hard >problem’. I’d like to change that, but I don’t even know >where to begin, to be honest.

The basic problem is that CAD is probably the largest vertical market software. Vertical Market Software being software that is used by a specific industry for specific purposes.

While nearly everybody has a use for a word processor, not everybody has a use for CAD. Beyond CAD it gets so specialized that the pool of developers experienced in the problem area can be counted on two hands.

I myself program CAD/CAM metal cutting software with specialized functions for the HVAC industry (Heating, Ventilating, and Air Conditioning). I doubt there is more than a dozen competent programmers in the nation who know how to code everything you need for HVAC ductwork and fittings.

Most efforts outside of my industry wind up only covering a metaphorical tenth of what you need.

Mind you isn’t that hard but the knowledge is so specialized and much of it learned through experience. None of it really written down anywhere where a person could learn. Plus ethically I can’t get really contribute much to a open source project as pretty much all my HVAC knowledge was gained on company time.

The CAD situation is better than my own HVAC/Metal Cutting industry as it is the most commonly used vertical market software. But when you start digging you find there a lot of specialized areas that only a handful of people posses knowledge about.

In my opinion the best way for open source to gain traction in these vertical markets is for the hardware to go open source and require the use of open source libraries and software to use.

I think it is safe to say most of us involved in these industries care more about producing actual physical machines. We don’t want or need the treadmill that Microsoft and other proprietary companies put us through. We need to able to buy equipment not just next years but ten years from now. And if it an improved product work with the older stuff. By equipment I am including software as well as hardware. Open Source does a good job of maintaining compatibility. Plus it helps maintenance as we can poke and measure everywhere in the system.

Y’all are mostly ignoring the real benefit of NMEA-2000: the connectors. First, it carries power to the device. Second, it’s a bus so you can hang all sorts of things off it. That encourages people to buy more. Third, the connectors seal very very well against salt water. If you haven’t had to deal with it, you have no idea how bad water can be. Then add salt to it. Now you have something that will rot away pretty much everything made out of metal, including stainless steel.

If you haven’t had to deal with it, you have no idea how bad water can be. Then add salt to it. Now you have something that will rot away pretty much everything made out of metal, including stainless steel.

I grew up in Detroit, where they use copious amounts of salt on the road everytime the snow flies, and I live in Florida. And, like Jay Maynard, I fix my own cars. Ever see the undercarriage of a Michigan car older than about 5 years? You’re right, the use of stainless steel doesn’t help. At all. Believe me, no one appreciates a saltwater-proof connector like me!

>The stockmarket disagrees with you. look what happened after the iPhone and Android started shipping

Well, duh. Garmin is exposed because it collects a lot of its revenue from handset GPSes. That’s exactly the market smartphones do cut into – unlike the market for cheap GPS mice, which are complementary goods. Do try to keep up.

>You seem to be saying that the market for GPS ‘mouse’ devices will continue, but the market for automotive GPS devices is over. Correct?

Market for GPS mice will continue, check. I’m not actually certain about automotive GPSes; the category that seems doomed by smartphones to me is handset GPSes of the sort carried by hikers and geocachers. Automotive GPSes might survive by, for example, moving to larger displays than are practical in a handset and having voice-activated controls.

Automotive GPSes might survive by, for example, moving to larger displays than are practical in a handset and having voice-activated controls.

If they go HUD (project the imagery on the windshield right above the driver’s instrument cluster, or perhaps even with some of the info traditionally shown on the dash itself — my GPS already shows my speed on it), integrate the voice nav. into the sound system (automatically mute the music a bit when speaking the directions) they’ll differentiate themselves from what a dash-mounted smartphone can do.

On the other hand, for them to go that route, they would pretty much have to become integrated devices of some sort, effectively no longer being a stand alone GPS unit anyway wouldn’t they?

I suppose you could have it as an external device with some interface cable to the car’s systems, but if you’re doing that, the question becomes what problem is solved by that solution that isn’t equally solved with the appropriate mobile phone solution?

You could have a separate device projecting the display on the windshield, but it would have to be able to talk to the radio and tell it to reduce volume somehow, and hey, might as well share the speakers. More recent car radios have plugins for ipods/MP3 players and such, so it might not be that big of a deal to do.

Is there that big a market for GPS mice? I certainly don’t see many in use, the only ones I’ve seen on a regular basis are attached to cameras for geotagging and that functionality is moving inside the camera (it’s already a selling feature for P&S’s and Sony’s now offering a not-quite DSLR with the feature, the SLT-A55, I epxect Nikon, traditionally the biggest GPS supporter in the Camera world, to go to internal GPS in the next generation of DSLR’s). I’m sure there’s a fair bit of specialist applications and I’d expect those applications to be uncommonly popular for GPSD use but the majority (and profit centre) of the market remains handheld consumer devices. The ‘bigger market’ where the profits are is simply going to disappear, the specialist markets will likely endure but aren’t a serious profit centre for anybody.

The consumer market for GPS’s is mostly split between handheld units and automotive units. And handhelds are going to evaporate as smartphones take over that market, if only due to the aility to have free map upgrades.

@Morgan Greywolf: PC/TV convergence happened. The TV in most households today is little more than the display device for a computer, typically a gaming console (PS3 or XBox), sometimes something else (Apple TV, Roku). The form hasn’t converged because of ergonomics, not tech.

Er….what makes you think I need GPSD to survive? Sure, it’s a fun project, but it’s not like there aren’t plenty of other problems calling for my attention. Systems architects with my level of skill and experience don’t exactly grow on trees.

No, I’m extrapolating from the fact that handset GPSes didn’t kill off mice. Instead, these two product categories seemed to stimulate demand for each other. What I think is going to happen is that GPS-equipped smartphones will raze the handset market to the ground, but that the GPS mouse market will continue to flourish alongside smartphones just as it did alongside handset GPSes.

Well, as long as laptops are an important product category, anyway; if and when they die off, or laptop makers start integrating GPS chips onto motherboards, the mass market for GPS mice will collapse. I think laptops growing onboard GPS support as a standard feature is more likely; the odds on that will only increase as the come under competitive pressure from GPS-equipped smartphones and tablets.

What becomes of GPSD at that point is an interesting question. Data’s got to get off the GPS chipset somehow, and barring some sort of elaborate and difficult-to-standardize memory-mapping scheme you’d more or less have to treat it as a byte-stream virtual device, /dev/gps. In that future GPSD adapts with barely a glitch. It doesn’t care in any deep way whether it’s reading a serial port, a USB port, a TCP/IP socket, or even a UDP packet stream; in fact these are all real-world use cases right now, and adding a virtual /dev/gps to that list would be nothing remarkable.

Would a port of GPSD to Android phones for their GPS be possible, or worthwhile? The reasons I could see to do that rather than use Android’s provided API is a.) if you want to run preexisting software that uses GPSD, or b.) if the provided API sucks. I’m not sure if either would ever really apply.

hi, late coming into this party. I do see some familiar names (Hi Russ). I’ve spent the last couple of days hacking some Java code to read NMEA data files from a GPS logger, and stumbled into this while searching for details on the spec (which sucks, BTW).

I’ve got a key (I think) observation that is relevant to all this “standard” and “trade association” stuff. Perhaps you folks have talked about it in the past. Historically, “standard” are anti-competitive. To use an example that is at least a century old, look at grades of steel. Steel is a commodity, and nearly anyone can make it. Making “good” steel is a much bigger challenge, and making a lot of good steel at decent prices is fairly challenging. So the good-ol-boys at the big steel companies invented standard grades, which they could deliver on, and that upstarts could not. Sure, the members of the club will compete, but not against the upstarts.

Just like Oracle sends reps to the equivalent SQL standards meetings to try to bend the standard to what they have implemented. Folks old enough to remember Posix should also remember that the NIS&T was shocked that HP passed the Posix-compliance suite with MP/x which was not at all a unix-like operating system.

NMEA wants standards that only its members can meet. It may be stupid of them to define the protocols over the wire from an engineering viewpoint, but they are not an engineering organization.

I’m curious that no one has looked inside an Andriod to see of gpsd is running under the covers. After all, the handset makers want to be able to swap out chipsets.

NMEA 2000 defines the physical layer for one outstandingly good reason: The only interface between two manufacturer’s devices is the physical layer. If you do not have compatible physical layers, the devices can’t talk to each other, no matter how compatible the upper layer is.

With NMEA 2000, you know that every device on your ship can plug into the bus. You never have to ask: Is this device sending TTL level or RS232 or RS422? Is it 4800 baud (the standard for NMEA 0183) or something else (implemented by some devices)?

NMEA 2000 also uses one of the features of the physical layer. In CAN, packets have priorities, and high priority packets get on the wire before low priority packets from other devices. You don’t have that in any of the de-facto physical layers of NMEA 0183 (there is only one in the standard). You also don’t have it in Ethernet, though you can fake it by using gigabit ethernet to carry megabit traffic.

You don’t find much call for the priority system in small yachts, but I’ve seen discussions of using the NMEA 2000 CAN bus for engine and steering control. You might well want packet priorities on a container ship. (Assuming they can be bothered to install any instrumentation or controls systems at all — shipping is well know for trying to minimize costs by cutting as many corners as possible, but that’s a different issue.)

None of this makes NMEA 2000 any easier to deal with, but it makes sense of why they would do that.