Raymarine SeaTalk-SeaTalkNG converter, nice
What’s yellow, white, and blue, and will help a lot of boats integrate older Raymarine SeaTalk1 instruments and sensors into SeaTalkNG/NMEA 2000 networks? Well, check out the new SeaTalk-STng converter above, which retails for $95 and is also putting the Plus in Ray’s new Raystar 125 Plus GPS. The manual PDF can be downloaded here, and I think it will please a lot of people who’ve messed with this stuff. Those yellow connectors above let you not only adapt a mini network of up to five SeaTalk devices — like ST40 and ST60+ displays and their transducers, and/or a LifeTag wireless MOB system — to a SeaTalkNG backbone, but also power them…
Now Ray’s ST70 multifunction color instrument (which I first tested in early 2008) includes a similar ability to convert SeaTalk data, but this new standalone converter offers more system design flexibility, especially if you don’t want an ST70. It may also offer new ways to avoid the expense and added complication of Raymarine’s various transducer adapter pods, though it’s also nice to see that ST70s can now directly manage certain of Airmar’s smart N2K sensors.
Unfortunately Raymarine has not published a list of standard N2K PGNs supported by the SeaTalk-STng converter, but the manual cites the following types of data: “Instrument and environment (Depth, Speed, Wind etc.); MOB (Man Overboard); GPS; Heading; Navigation Data (Waypoint information); and Rudder angle.” {Manual, link above, now has a long translation list.}
My experience with the ST70 was that it understood standard PGNs fairly well, even to an ironic extent, and I hope to soon update that experience as I’ve got my mitts on a ST70 3.0 firmware update that Raymarine will be making public soon. In fact, some of the good news picked up in a meeting with Raymarine and FLIR yesterday was about how Raymarine is streamlining its firmware coding and distribution process. You can hear more good news — like an increased R&D budget — if you stick with this MadMariner podcast with FLIR’s Andy Teich.
It’s a bit of a good news / bad news announcement.
The good news is that Ray is finally providing some basic backwards compatibility and a bridge between their two networks. The bad news is that it reinforces their commitment to the SeaTalkNG proprietary cabling system, rather than industry standard N2K cabling.
I now have a boat with N2K, 183, SeaTalk, SeaTalkNG and Ethernet cabling. Marine electronics interconnection is a sorry situation that holds back the purchase of new equipment by all boaters. Once again I would like to suggest that when the mfgs make it easier to integrate new equipment into the boat, we’ll buy more equipment. This product helps a little, but while driving further down a proprietary road that I have no desire to travel.
The Raystar 125 has a bad rep up here in BC,many failures.The standard joke is Raymarine included the Led (the dreaded flashing red)cuz they knew it would fail at some time.
Hopefully the nmea2000 version is more reliable.
It is still too expensive and inferior to other gps receivers,the Garmin 17x for example.
Any idea when this will be available?
I have been experimenting with data bridging–trying to get data to a set of ST60 Maxiviews from my NMEA 2000 bus. First with a Simrad AT10 connevted to a Raymarine NMEA 0183 to Seatalk converter. This worked, but SOG did not make the transition.
Next I tried the bridging built in the ST70s–which work well, but now this ST70 resets every time it powers up.
A dedicated converter is the way to go…
For $95 we get a seatalk to N2K converter, plus a mini N2K network including terminators and power cord.
I would have expected a “1” or a “2” in front of that $95, as the individual parts sans converter for competing cable system with a five port hub would be about $200 street price ($119 starter kit + $72 micro multiport)
Sweet !
I was wondering if this converter could also be used to send data from my new A50 (using ST-ng) to my ST7001+ Autopilot and may be even my RL80CRC which are all Seatalk 1.
Anyone that tried that yet?
A seatalk to seatalkNG converter is nice, but what about a seatalk to n2K converter. Actually Raymarine needs to start with a clean slate and redesign their entire line to be fully NMEA 2000 compliant, then sell a converter that allows old Raymarine equipment to connect to the new stuff. Then they may have a fighting chance to compete with the new kids on the block (iPad aps, Comar, Digital Yacht, etc, etc) who so far have left Raymarine in their dust.
Rick, Almost all Raymarine MFDs are NMEA 2000 certified:
http://www.nmea.org/content/nmea_standards/certified_produ.asp?a=1
And while I don’t know why the ST70 instrument isn’t certified, I know that it displays many standard N2K PGNs coming from other manufacturer’s devices just fine. I’ve also seen how Ray’s wind sensor adapter produces standard wind PGNs. In other words, the SeaTalkNG protocol is not as different from NMEA 2000 as you seem to think.
The cabling and connectors isn’t all that different either. I believe that you could cut a blue STng backbone cable in half, put male and female DeviceNet connectors on the raw ends, and incorporate that SeaTalk-STng converter above into a standard N2K backbone, with power and data flowing either way without a problem (with large networks, where impedance becomes a issue, possibly excepted).
But all that said, Raymarine has plenty of work to do to catch up in terms of N2K. It’s the only one of the big four MFD manufacturers that won’t let you see what devices are hooked up and choose between redundant sources. And I’m surprised it hasn’t yet developed its own native N2K sensors, or at least added calibration support for more Airmar or other maker’s native N2K sensors.
I suspect the ST70s are not certified as they support daisy chaining.
FYI, I have no idea why, but I have found that connecting each ST70 directly to the N2K bus really cuts down of the “spontaneous reboots” the ST70s are famous for…
I have a boat full of Beneteau-installed ST60+ gear plus a growing set of owner-installed NMEA2000 devices. Right now, the Raymarine E120 MFD bridges everything, but that means that the E120 needs to be on every time I want to “see” the ST60 data on the NMEA2000 network – even when I’d prefer to have that data available directly, such as when I’m running Maretron N2KView down below and don’t need the E120.
If this new device lets me publish the ST60 data directly onto the NMEA2000 (not STng) network and cut the wind/depth/speed/temp SeaTalk connection to the E120 – without loss of features or performance of course – then I’m going to buy. Of course I’ll eventually get rid of all non-NMEA2000 sensors (get with the program Raymarine) but this would be a good step forward.
I did note in the Raymarine manual that this *does not* work with SeaTalk autopilots, so for now I’ll still have at least one SeaTalk connection into the E120.
So will this work in a NMEA2000-cabled network or is that magic extra wire in STng required?
Ben, with all due respect, I think Russ hit the nail on the head. Whether Raymarine’s (or anyone else’s) proprietary system “displays many…PGN’s just fine” , or whether or not you “believe that you could ” splice their network into an N2K network, is SO not the point. Customers want one standard, and they want products certified to meet that standard. Anything else leaves the door wide open to incompatabilities among devices, and finger-pointing between manufacturers about why things don’t work. I’ve been down that road too many times. While this device may offer some limited help, they would be better served providing a product that converts all their versions of SeaTalk data (and connectors)into N2K. We passed over replacing existing ST-60 Tridata instruments with ST70’s, in favor of the upcoming Furuno RD-33, for this very reason.
It is what it is, Grant. I’ve pushed hard for standards and interoperability that work, but here we are. I too suspect that the Furuno RD-33 is going to be a great instrument display, but let’s not forget that Furuno is going its own way with NMEA 2000 too. (See entries on Furuno CAN Bus.) And Simrad.
The point I’m trying to make, and have seen hand’s on, is that cables and connectors don’t mean as much to a successful system as the ability to read and manage standard N2K data. Or even using proprietary data to accomplish tasks NMEA hasn’t written PGNs for yet, though that’s only going to happen within a manufacturer’s system.
I’m all for you, Russ, and others pushing marine electronics companies to do better with NMEA 2000 and interoperability, but I’m hoping that Russ doesn’t again bring up the idea of starting fresh with NMEA 2XXX, because I just don’t think that’s remotely possible in anything like the near future.
Well, I’m all for maintaining the ability to “read and manage standard N2K data”, I’m just saying that until the manufacturer guarantees this in terms of NMEA certification, it’s esentially meaningless to the potential customer – because we can’t depend on it to work or be supported if it doesn’t. I appreciate you reporting this anecdotally when you discover it – but to me it’s kind of a “bonus – if it works” situation – certainly nothing I’d design my system around.
The current situation, with multiple, multi-million $$ corporations producing new product thats non-complaint with the standards of their OWN member organization can only be described in one word – pathetic. Either upgrade the standards (with backwards-compatability), or figure out a way to inovate within the current protocol. I’m sure there’s all kinds of excuses why this is too difficult – none of which matter a dang bit to the customer.
Ben Russ
Firstly the raymarine convertor does handle all the legacy situations. But there has always been issues with raymarine convertors this stems from raymarines woeful closed shop mentality when it comes to protocols.
As to Nmea 2k woes we ain’t seen nothing yet wait till n2k tries to extend outside an instrumentation network all hells about to break loose IMHO .
Sorry to burst the bubble, but this device (or using an ST70 instrument) should not be used to bridge Seatalk1 networks to NMEA2000 networks. You can use if to tie to a Raymarine SeatalkNG network, but as written in the Raymarine SeatalkNG Reference manual:
“Limitations when SeaTalk(1) products are connected
If SeaTalkng and SeaTalk(1) products are used together, do NOT connect an NMEA2000 backbone, as this product combination could compromise the integrity of the NMEA2000 system.”
-Earl
Earl, I think that’s just CYA patter. How exactly would PGNs converted from another protocol compromise an N2K system (assuming they’re formatted and broadcast properly)?
I wonder why they limited it to only 5 SeaTalk devices? It seems like a totally artificial limitation that required extra coding to enforce. SeaTalk is a bus and is normally connected to all devices on a boat, which is usually more than 5. As long as it can handle specific SeaTalk messages and transmit them on STng and vice-versa, I do not see any reason why the software should care how many devices there are.
It is as if they want to force people to break up their SeaTalk network into different sub-networks and interconnect it all with STng, of course requiring the purchase of one of these for each sub-network. While this might be a good network design, and could be recommended, why enforce it?
I think that one thing to be careful of is possible data loops–where data goes from N2K to Seatalk and back to N2k. Might not be too bad if the Seatalk devices were just repeaters, but I can see where problem might arise where data starts being “seen” from multiple sources.
I need to get my hands on one to test the 5-device limitation, if it will crash the converter because of data, or if it is a conservative power limitation that Ray stuck on there in case you are powering 5 SeaTalk devices from the ST-NG backbone. If so, that could be overcome by creating a dual-power feed SeaTalk network, which is outlined in their manuals.
Grant if you’re thinking on using the rd33 in place of st70 on a raymarine system you are going to be disappointed. There’s no proper seatalk to n2k outthere and the situation is worse for seatalk to nmea0183. How will you connect in the rd33 into the existing system . I suspect you have toinstall a new n2k network
The thing is raymarine never really bought into open systems. They always maintained a closed approach and refused to share info. This attitude has extended into seatalkng which to some extent allows ray to claim n2k cpmpatibilty but actually it’s another seatalk in the making.
PA-RO-CHIAL [puh-roh-kee-uhl]–adjective
1.of or pertaining to a Raymarine product.
2. of or pertaining to protecting a little piece of eroding turf
3. very limited or narrow in scope or outlook; provincial: parochial views; insular, isolationist.
Use parochial in a Sentence
“I would buy more Raymarine stuff it it just would play nice with others, but it’s so parochial, insular and isolationist that it might infect others with it’s paranoia.
Gents, how about specific examples? What specific standard NMEA 2000 PGNs won’t make it into SeaTalkNG devices, and what specific SeaTalk data won’t make it into standard PGNs when converted by ST70 or the new SeaTalk-STng translator? Otherwise I think you’re just adding confusing prejudice to an already confusing situation. (Raymarine could help here with specific translation results.)
I think Ben is correct. I have a system with NMEA 0183, Seatalk, Seatalk HS and NMEA 2000. The primary data backbone is NMEA 2000 (Using Maretron mid cable.) I have old ST60 Maxiviews and a Raymarine autopilot working with ST70s, but also with Maretron, Airmar, Floscan, Actisence and Furuno displays and devices mostly playing nice with each other.
The ST70s are not the most stable of instruments–with radom rebooting and the occasional reset. I have also had to learn about capacitance and reflection on the NMEA 2000 backbone.
Translating PGNs is not one of the issues, however. (That doesn’t mean that all displays will have screens for all PGNs.)
Sorry to report that I have some behind the scenes server trouble and can’t post a new entry. I’m hopeful it will be fixed soon.
1) As much as I hear the complaints about Ray’s cabling being non-standard, I believe Raymarines approach to cabling is innovative in several ways and a good choice for many situations. Their tiny connectors make the cable easier to snake thru cable runs, the ability to daisy chain simplifies wiring, lighter weight cable and shorter cable runs (daisy chaining) combine to lower weight, and, as the color coding makes them virtually self documenting in terms of backbone vs drops. For the drops to my Raymarine components I used a combination of pre-made E-series cables from Maretron and SeaTalkNG cables (easy to snake thru my boat) with the end replaced with a Maretron field installable connector to mate with the backbone.
2) Raymarine offers a spur cable with a female end that allows you to plug non Raymarine NMEA-2000 devices into their cabling scheme.
http://www.blueheronmarine.com/Raymarine-A06045-Seatalk-NG-To-NMEA-2000-Female-Adapter-Cable-5376
Such a cable would be a good compliment to this converter for anyone starting their NMEA-2000 network with a non-raymarine N2K device like an Airmar H2183 solid state compass.
https://panbo.com/archives/2009/11/airmar_h2183_improves_situational_awareness_feature_on_raymarine.html
SeaTalkNG cable also contains heavier gauge power wires than standard N2K micro cable does. It’s the equivalent of Maretron’s Mid size cable, I think, and hence, like Mid, can carry 12v further without debilitating voltage drops. Discussion of these issues here:
https://panbo.com/archives/2009/03/nmea_2000_power_problem_part_2.html
But note too that there’s also an adapter cable to put SeaTalkNG devices onto a standard micro or mid backbone:
http://www.blueheronmarine.com/Raymarine-A06046-Seatalk-NG-To-NMEA-2000-Male-Adapter-Cable-5962
Apologies to anyone who’s gotten error message when trying to post a comment. Panbo is fixed now and a new entry will go up soon.
This has been a fun Ray-roast, and it points out that Raymarine’stroubled past is not exclusively attributable to market conditions: some engineering decisions have limited their market too.
Ben, again with all due respect, I can hardly believe we’re having this debate. You state that cable and connectors don’t mean as much as the ability to translate N2K data. That may be true in an absolute sense – but why would any consumer/designer choose products that require manual fiddling or expensive adaptor cables to integrate into an industry-standard N2K system? (I realize that “industry-standard” is a bit of a joke here, but isn’t that SUPPOSED to be the idea?) Especially when the manufacturer specifically states, as Earl pointed out, to NOT connect their system to a NMEA 2000 backbone – Their CAPS, not mine. You can surmise all you want that this is “CYA patter”, but the bottom line is there is no way I’m spending my money, or my customers, on products that are clearly designed contrary to standard and specifically advertised to be non-compliant. I’m surprised you don’t seem to appreciate that stance.
If you wish to “prove” the manufacturers are underestimating their own products capabilities, that’s great – just don’t expect folks to break out their wallets until the manufacturers themselves are willing to stand behind their own stuff. I can’t very well complain to tech support that “Well, it’s supposed to work – I read so on Panbo”!
“…may be true in an absolute sense…”
Actually, Grant, where it may be true is in the real world sense. With all due respect, I think you’re playing the role of absolutist here, and it won’t work well in an industry like marine electronics, which is essentially “cottage” size. 75% of the major system manufacturers (3 of 4) are out of spec with approved NMEA 2000 cabling/connector rules in some way or other, and it used to be 100%!
If you limit your customer’s choices only to interfaces you can absolutely guarantee, they will be very limited indeed. And, yes, they often do want to mix, say, older Raymarine instruments and sensors with another manufacturer’s N2K displays, usually because they already have the former and want the latter. Or a Simrad 0183 or SimNet ap with a Raymarine MFD and ST70s. Etc. Etc. I know one installer who tries hard to present all the possibilities to a client and then to be very explicit on the work proposal about what may not work well.
At any rate, Raymarine is sending up two SeaTalk-STng converters and some ST40 displays and sensors so that I can test them in several configurations. I expect to see a decent level of interoperability. On the other hand, Ray just issued a software bug report stating that a RayStar 125 GPS connected to the converter (i.e., the Plus kit) “causes an intermittent erroneous Speed Over Ground (SOG) value to be displayed on the connected MFD’s and instruments.”
Ray is working on a bug fix, but note that this problem has nothing to do with cabling or interoperability, etc. And I believe any marine electronics manufacturer could have shipped a product with a bug like this. Cottage industry; it is what it is.
It’s difficult to see how companies that range from $150M – $3B in a market well over $1B, can be considered “cottage” sized. There are certainly many “cottage” size companies in marine market (Spectra Watermakers for example), but it is disingenuous to suggest that Raymarine, Garmin, Furuno and Simrad are among them.
But suppose these companies really were small, with resource constrained R&D budgets, struggling to produce a quality product that was well differentiated from the competition. Why wouldn’t such a company embrace industry standards, and invest it’s precious resources in developing product characteristics that were truly innovative, instead of just different?
The consolidation going on in marine electronics is not because they are victims of a bad market, it’s due to either bad management that made bad decisions on where to spend their resources (Raymarine squandered a huge amount of money after it’s IPO), or they had engineering staffs incapable of real innovation. They are the GM’s and Chryslers of the marine world.
The comments posted above are from customers crying out for reliable interconnection and interoperability, not a band aid (which is apparently limited and buggy) like the product which tops this thread. It is a reasonable request.
Russ, I couldn’t agree more. And as much as I appreciate Panbo and respect the experience and insight contained herein, I have about zero tolerance for excuses about lack of standards compliance. No other tech industry would even dream of producing new product that was out of compliance with it’s own member protocols. Ben, I understand well that customers would prefer to have new equipment backwards compatible with their existing gear (0183 etc), and there are plenty of “cottage” sized solutions that are designed to enable this. That in no way excuses the “Big 4” from continuing to introduce new systems that go their own way and ignore their own “industry standard”. We need to stop making excuses for this nonsense, the sooner the better. Like Russ said at the very beginning of this post, a new device that merely allows one proprietary system to communicate backwards with an older proprietary system of the same manufacturer is hardly cause for celebration.
Grant;
To be fair, Raymarine’s prohibition on connection of a SeatalkNG backbone to an NMEA2K backbone is mentioned only in the context where the SeaTalkNG is already connected via a bridging device or cable to SeaTalk 1. I’ve just re-read the ST-NG manual to make sure that this is the case. If there are any other warnings about interconnection in that document I’ve missed them (again).
Sometime in the next couple of weeks I intend to extend a ST-NG backbone with some Garmin NMEA2K cable and connectors in order to integrate a Garmin 750S plotter. I’ll report here on the success or failure of this configuration.
The only thing that I think is poor on Raymarine’s part is their unwillingness to provide field installable connectors.
Grant, I’m quite curious about how you intend to express your “zero tolerance.” Are you going to leave marine electronics behind? And what exactly do you think I should be doing about this situation? Is there any other site that actually discusses the nitty gritty issues of N2K interoperability? Have you ever read about these issues in a boating magazine article (that I didn’t write)?
Sorry, I simply can’t get as agitated as you seem to be; I’ve seen too much N2K progress in the real world. Nor can I agree that the SeaTalk-STng converter just “allows one proprietary system to communicate backwards with an older proprietary system”; that’s an extreme glass-half-full characterization that I think we’ll see gutted in the testing I do in the next week or two.
Russ, the worldwide marine electronics market seems to be not much more than a billion dollars. And that’s really not much, especially when you consider how amazingly fragmented the customer base is. (I think that my local health care conglomerate is equal to at least 1/20th of the worldwide ME business in terms of gross revenue, and it only covers one county in Maine.) I’d really like to know what niche technology market is truly analogous to ME, but it sure as hell is not computers, or cell phones, or anything remotely like those.
Ben – I think Grant, or any other commenter is entitled to their opinion. Characterizing his opinion as “extreme” does not encourage an exchange of opinions and information which I think is the beneficial goal of this forum. If you don’t want to hear your reader’s opinions, turn off the comment facility.
For the sake of discussion, let’s accept your asssertion that the ME market is small and fragmented. It only further supports my point that management should spend their devlopment dollars wisely, rather than reinventing the wheel.
I believe that if you surveyed ME customers the results would show a lack of willingness to pay a premium for a SeaTalkNG connector overa a generic N2K connector. I believe that customers are buying RayMarine products in spite of the SeaTalkNG connectors, not because of them.
SeaTalkNG required an expenditure in design, tooling, more expensive supplier cost due to being the sole customer, higher inventory levels because there is no other source for the connectors and all the other costs that accompany a proprietary part. All of that money could have be spent on innovation, rather than trying to replace a commodity connector. In my opinion, the choice to develop a connector, instead of spending that money on real innovation that would motivate customers to pay a premium, contributed to their de facto bankruptcy.
Fair enough, Russ. I apologize for “extreme” and retract it. But I stand by the opinion that seeing SeaTalkng as proprietary only is half-glass-full thinking.
Dan made some good points about the SeaTalkNG cable and connectors above, but I think you have a good point about wasted resources.
Roy, you are quite correct, that is the only scenario that I see in the ST70 manual that the product is incompatible with an N2K backbone (when also connected to SeaTalk components). However, I suspect that installations containing both Seatalk and SeatalkNG components are more common than not. To my mind, it still represents a design bias to RayMarine’s own network as opposed to providing solutions that interface their current and past technologies to the current N2K standard.
Ben,
It seems as though I have touched a nerve on this, so I’ll attempt to answer your questions and let you have the last word. As far as expressing my zero tolerance – no, I do not intend to leave ME behind. If you read that statement over again, you’ll see that I was referring to the “excuses about lack of standards compliance”. I don’t think there IS an excuse for introducing new products in 2010 that are designed and advertised as non-compliant with industry-association standards supposedly adopted at the turn of the century. If you believe there is a good excuse for this, so be it. As far as what you should be doing about these issues – I think you are doing great work investigating and reporting what works and what doesn’t, and I would not presume to advise you on what to do further. Our difference of opinion, as near as I can tell, centers on what OTHERS (the “Big 4”) should be doing – I’m completely unimpressed; you appear to feel the current situation is reasonable and not worthy of a lot of critique. Are there other sites that discuss N2K operability? Have I read a magazine article on the subject that wan’t written by you? Quite possibly yes to both questions, but I would certainly not challenge you as an authority on this subject, which appear to be what these questions are getting at. I apologize if you felt offended in some way.
As far as whether my characterization of the subject product is an extreme “glass half-full” view – I will try one last time to clarify the point. Whether this characterization is “gutted in testing” is really immaterial to me – not to impune the value of your testing. Unless and until manufacturers design, build, test, certify, and support their product to N2K standard, then I can’t get behind supporting this behavior by spending $$$$ on their equipment, whether or not you can get it to work in testing. More importantly than that, I don’t want to deal with the inevitable and costly issues that are bound to arise when using equipment whose OWN MANUFACTURER says is not guranteed to be compatible, whatever you may discover to the contrary. I believe there are plenty of products of all types, that ARE certified and supported to N2K standards, and are a better choice than rolling the dice with those that are not. Call me crazy.
It would be interesting to see what a reader poll would show, regarding the state of N2K in 2010. Are most of us happy with the progress thus far? Are the large manufacturers doing a good job supporting their own NMEA standards? Does it matter if a product meets N2K standards, as long as it can be shown to function in the field? This is probably more trouble than you’re interested in taking, but I suspect the results may surprise you.
Respectfully,
Grant,Ben, Russ et al,
Ben is right and wrong. Hes right in that device interoperability has come along way and that more talks to more then ever before. But, really whats wrong is the N2K standard and NMEA. Firstly the standard is so behind the technical curve. secondly NMEA really is a small national organisation really a North America manufactuers grouping. It took way to long to agree the standard, cant really enforce that standard ( witness Furunos CanBus 2000 nonsense) and has allowed connector variants to proliferate.
When you couple this with the fact that interoperability is not what the BIG 4 see as too important, you get the state we are in. I beleive it will a actually get worse as other companies bring products to bear. ( digital switching, DC control etc).
SO if you want absolutism, you will be waiting a long time, N2K by its nature will always have the problem of “Device a sort of works with Device B”. Even the Big 4 cant get their own stuff to interoperate at times, look at the Furuno GP33, as Ben points out it actually doesnt work with Furunos NN3D, as it cant detect or handle active waypoints that it didnt setup.
This industry based around these standards will always be like this, get used to it, its all we have,
DAve
Dave- I’d like to suggest a counterpoint to passively resigning ourselves to the status quo. I believe that the product managers and engineers at these companies are constantly thinking about and/or actively designing new products and entire generations of products. As professional mariners, dealers, installers, and individual DIY boaters we have a say in these new products.
First, we have this forum provided by Ben and we know the manufacturers read it. Tell them what you like, dislike, and would like to see in the future. I think they are listening.
Second, vote with your wallet. Shun the products and companies that aren’t going in the direction you’d like, and purchase and encourage those that are. Money talks.
Third, join NMEA and volunteer on a committee. I wonder if now is a good time to join the gateway committee? Anyone here on that committee ? Looking for volunteers?
Grant, I’m not sure a response from me is necessary given that your argument has compelled a regular and outspoken N2K critic like Dave to counsel moderation 😉
Dave,
I agree that NMEA and N2K are not all that they should be. That doesn’t mean the association and the standard cannot evolve and improve. The only thing holding that back is exactly what you stated – ” interoperability is not what the BIG 4 see as too important”. The market has a way of changing that attitude when it IS shown to be important to the consumer. I further disagree that “N2K by its nature will always have the problem of “Device A sort of works with Device B”. While there is plenty of room for improvement in the standard, I’ve seen no evidence that N2K certified devices on an N2K network suffer from some kind of inherent flaw in the spec, which is what you seem to be suggesting. The problems occur when manufacturers inovate outside of the spec, either because the features they want to incorporate aren’t allowed (i.e. daisy-chaining), or a willful desire to keep their technology proprietary and non-functional with other manufacturers. Neither of these, in my view, is an acceptable behavior. Innovation is great; but if you’re constrained by your own member standard, improve the standard – don’t deviate from it. Your example about the Furuno GP-33 that “actually doesnt work with Furunos NN3D” is another red herring – this has zero to do with N2K, and in fact is just a software feature of NN3D that has not been enabled yet, as Ben stated in the article.
I’m not sure how advocating for inter operability standards compliance in the ME industry makes one any more of an “absolutist” than a consumer expecting his new 802.11N Wi-Fi adaptor will actually work with his existing 802.11N router – but I guess that’s just too much to expect for some folks. Personally I’d like to think the marketplace will continue to drive improvement in this area – ir we don’t all just “get used to it”, as you suggest.
Grant, I fear that you’re overly optimistic about how closely companies in other industries adhere to the relevant standards. I work in the computer database industry and have done associated standardization as my primary career activity for the last 25 years.
I share your fervent desire for standards-conforming products, as well as your observation that implementers can save large amounts of R&D budget if they’d only take the nearly free gift of interface designs that have been standardized. Unfortunately, there is not a single database system on the planet that conforms 100% to the SQL standard…which was first standardized in 1986 and has gone through several major revisions/updates in the following years. The same is true of XQuery, another query language (for XML data), although that standard is much younger.
Just a little perspective…
Thanks for the perspective Jim. I’m not famailair with SQL database standards, but I’m sure what you say is accurate. You don’t indicate whether these deviations actually result in operational issues or if they’re just transparant to the end-user. In any event, mistakes and/or deviations in other arenas hardly consititue a justification in this industry – in my opinion.
Dear Ben,
You mentioned you have the ST70 3.0 firmware. Do you know when Raymarine will post this? What is your experience with the installation?
Thanks
Don
PS: I have N2K sensors, displays, multiple power feeds, mixed cabling, just about every vendor, etc….ie every nightmare alluded to in the discussion above. Nonetheless, I am pretty clueless as to what everyone is talking about above since my system functions as a very pleasant dream. Gee whiz…
I sent in a couple of ST70s for repair. (They no longer saved settings.)
They were returned with firmware V 3.03. So far, not much difference. Menu graphics are jazzed up. Nice new screen colors. There is a new rolling road screen.
I haven’t checked to see if they now do fuel remaining/range calculations.
The best feature is the ability to establish zones and adjust colors/brightness for single displays or zones from one display. (Handy when you want to dim the cockpit displays at night. Previously they all would have to be done individually.)
What I am really hoping is that these prove more stable. Too soon to tell…
Donald, I was not able to update ST70 myself, even though I eventually tried it on an N2K backbone that only had it, an E140W, and a good power supply on it. The problem may have been that it was a very early production model, but I know that Jeremy A also had problems updating his ST70s. (Multiple attempts to update the ST70 did not hurt it, though; so I believe it’s safe to try it yourself when Ray makes the software available.)
I’ve done a fair bit of testing with the SeaTalk-to-STng Converter, and so far so good. Compass heading and wind coming from ST40 displays is turned into valid PGNs that are understood by all the displays on Gizmo’s backbone, as is the output of the Raystar 125 (except for glitch in its altitude value, which hardly anything can display anyway).
In terms of cabling, I’ve usually been using the converter like a three plug multiport, simply dropped into a standard N2K backbone. Works fine, as does running an N2K or STng backbone through it. Soon I’ll add ST40 speed and depth data, and report on the whole deal here.
Raymarine sent me the new code. I tried it on a couple ST70s and it does work. 🙂 Not so lucky with the code for the ST70 pilot.
I have set up a dedicated ST ng network that only has the e series and ST70 unit to be upgraded. The upgrade takes a minute or so. I would not try this on an active network.
On a related front, I am finding that my N2K error traffic is way down with the upgraded units. Obviously a good thing.
Thanks Ben and Jeremy,
I tried contacting Raymarine with regard to availability of the firmware update for the ST70’s without response so far.
Jim and Grant:
My business is in the residential automation industry and I think that you can apply that “prespective” to the whole electronics industry.
A very wise lady (and I wish I could remember her name so I could give her proper credit) wrote in a magazine article that I read sometime back in the 1980’s – “The thing I like about standards is that there are so many of them to choose from.” Just look at how many different types of connectors there are to carry the same exact type of signal.
I suspect that Raymarine makes as much (or more)profit selling proprietary cables as they do selling equipment.
Al
I have been messing around with this converter since it first came out, trying to use it to provide data to a set of legacy ST60 maxi views.
The problem I have been having is that the wind direction data would sometimes be correct, and sometimes be off by 90 degrees or more. I have tried each firmware upgrade hoping the problem would be resolved, but even with the latest (V 1.11) the data was still off.
I finally sent the unit in for repair, but of course, on the Raymarine test bench, everything checked out OK.
This sent me back to by NMEA2000 set up. I think I have found the problem and will share it here in case anyone else runs into the same issue.
I have a Airmar PB200 that transmits wind data to the bus. As the PB200 includes a compass and GPS, it can also transmit ground and true wind along with apparent wind.
Seems my PB200 was transmitting ground wind direction and the converter can’t tell one from the other. So my ST60 displays would swing back and forth from apparent wind to ground wind.
I have shared this with Raymarine, but can’t seem to get them to understand what I am talking about. (So don’t expect a firmware fix anytime soon.)
Not a big deal as the fix is simple enough: Disable ground wind in the PB200 using Airmar’s Weathercaster software and let each instrument calculate its own ground wind.
Jeremy, did you option your ST60 Wind Display as a repeater (as opposed to default of master) while installing the PB200 ?
Your symptoms sounds identical to a situation I encountered after installing the PB200, which didn’t involve N2K or converters. The solution was also to set the PB200 to output apparent wind only, and let my Raymarine suite make the conversions.
Since then I came across a quick reference guide for calibrating ST60+ wind displays and noticed a master vs repeater mode. Seems that when a PB200 is installed, the ST60 display that is now sans sensor, should be optioned as a repeater?
“Dec 2005 documentation ST60+ Wind & Close Hauled Instrument – In a SeaTalk system, each instrument can be either a master or dedicated repeater unit. A master instrument is directly connected to a transducer (the device that provides the raw data), and provides data and control appropriate to its function, to all other equipment on the SeaTalk network. A repeater instrument is not directly connected to a transducer but displays information provided by other requipment in the SeaTalk network.” — From Raymarine Web-site.
The ST60 MaxiViews are all repeaters. When I tested a ST60 wind, I had it set as a repeater. (Also saw the same issue with a ST60 graphic.) Disabling all wind data but apparent in the PB200 looks like the it solves the issue.
Thanks, Jeremy and Dan. I think you’ve saved me a ton of fiddling and work.
I’ve just ripped out an old Cetrek AP, Compass and GPS and installed a 200WX (the new version of the PB200), a Garmin 740s, an Actisense NGT-1 (2000 to USB), a Garmin DeviceNet cable & tees network and have a stack of legacy ST60 Wind, Speed and Depth. I had a 85001 Seatalk-to-0183, but the Garmin won’t bridge the Airmar Wind to the ST60. So I’m going to order the Converter kit and get everything onto and off from the 2000 net.
The next project which should be interesting is installing NMEA 2000 based Evolution Autopilot which arrives on Thursday. Extremely innovative and state of the art. The challenge will to integrate the Seatalkng bits with the DeviceNet Garmin/Airmar/Actisense NGT-1 bits.
I think that I’m going to install it as follows (a linear picture, as it were):
NavPod at the wheel
STng Terminator -> P70 Autopilot controller -> STng to DeviceNet Female -> Garmin Tee (stub directly into the 740s) -> 6m Garmin DeviceNet cable ->
ST60 stack on the front cockpit
-> Garmin Tee (stub end -> a Raymarine Male DeviceNet to STng adapter -> the STng-to-ST1 Converter -> ST 60 stack) -> 2m Garmin DeviceNet Cable ->
Under the starboard berth
-> Garmin Tee (stub end -> a Raymarine Male DeviceNet to STng adapter -> ACU200 Evo AP Control Unit) -> Garmin Tee (stub end -> EV1 AP 9 axis Sensor) -> 2m Garmin DeviceNet Cable ->
NavStation
-> Garmin Tee (stub end -> 12V Power) -> Garmin Tee (stub end -> Actisense NGT-1) -> Garmin Tee (stub end -> DMK WiFi Box) ->
Along the hull and up the 65′ mast
-> 30m Airmar WeatherStation (including terminator at top of mast) -> Aimar 200WX WeatherStation
Whew! Hope that isn’t too confusing!
I’m concerned that the EV1 with its “3-axis digital accelerometer, 3-axis digital compass and 3-axis gyro digital angular rate sensor” will interfere with the functions of the 200WX, so I queried Raymarine the following questions:
1) On the Seatalk1 to Seatalkng Converter, can you please indicated which specific NMEA 2000 PGNs can be sent FROM the ng network TO the ST1 network and and FROM the ST1 network TO the ng network?
2) On the Evolution Autopilot, can you please indicated which specific NMEA 2000 PGNs can be sent FROM the Evolution AP system TO the the NMEA 2000 network (and non-Raymarine chartplotters, i.e, Garmin) and and FROM the NMEA 2000 network TO the Evolultion AP?
3) Finally, are any proprietary PGNs or messages being used between the EV-1 and the ACU-200, or are they NMEA 2000 standard PGNs? If standard, then what are they?
I’ll let everyone know. Ben, if you haven’t looked at this Evolution AP, a review would be great!
Michael, I installed the Raymarine EVO sensor on Gizmo about two weeks ago! It will be a while before I try the ACU-300, but I can tell you now that the EVO is delivering stable, accurate heading info to everything on the boat’s main N2K network, without calibration. That includes Garmin 741 & 7212, Furuno TZT, and many instrument displays. The EVO delivers the Attitude PGN as well as Heading, but so far only the Maretron DSM can show the Pitch, Roll, and Rate of Turn info that’s there. (I’m pretty sure that Furuno RD33 would too but it’s on Gizmo’s SimNet.)
So I think your Garmin 740 will see EVO heading, in fact will give you a choice of EVO or WX200 heading. But Raymarine gear is still not good at multiple N2K data sources in my experience, so it’s possible your P70 and/or ST60’s will get confused about heading or true wind. You are installing a bit of an experiment, I fear, but if there problems I think you could buy or borrow an Acitsense or Airmar bridge and use Airmar’s WeatherStation software to turn off the WX compass output.
Thanks, Ben. I hope that it’s not too much of an experiment, because it will be an expensive one :).
I have used the Actisense NGT to turn on and off various WX outputs and it works fine. I think that I will turn True Wind off as Jeremy recommended and maybe Heading and let the Raymarine EV1, ST60 and hopefully the P70 do its thing and calculate True Wind from Apparent Wind, Heading and GPS-based COG.
Raymarine Tech Support, while helpful and willing to contact their Engineering Department, unlike Garmin, are VERY ignorant about NMEA 2000 Transmit and Receive PGNs for their various pieces of equipment (the Seatalk to NG Converter is been out for 4 years for gosh sakes!). The EVO AP however is VERY clear in the Installation Manual about its Transmit and Receive PGNs, so maybe they are getting better…
Well, everything is installed and I must say that even I am surprised and pleased:
Took everyone’s suggestions, turned off all GPS, Heading, Attitude (Pitch & Roll) on the 200WX using an NGT-1, connected everything – the Raymarine SeaTalk-STng converter (connected via SeaTalk1 to my ST60 stack) and EV-200 Autopilot system (p70, EV-1 and ACU-200) , the Actisense NGT-1 USB, the DMKYacht WiFi Box, and the Garmin 740s, AIS-600 and VHF-200 to the NMEA 2000 backbone, then held my breath and fired it all up.
EVERYTHING WORKED. The ST60 saw the Wind from the 200WX, everything else saw the SOW and Depth from the ST60s, the Garmin saw everything from everything else and the Evolution Autopilot saw the Tracking info from the 740s for flawless autopilot tracking of a course created on the fly.
Negatives: although the Evo says it doesn’t need a rudder reference, I think that SF Bay will demand one. There is a Rotary Reference ($250 value included in the kit at no extra charge!) so that will definitely get installed. On a 35 kph sail between San Francisco and Sausalito it kicked out several times, but I think that’s due to excessive weather helm causing excessive current draw on the hydraulic ram; when I backed off the sheet (it’s a huge single sail Nonsuch) it worked fine.
The other challenge was exactly halfway through wiring and tying down the backbone, I had two male DeviceNet connectors staring at each other in the middle. Sooo,I took one of the cut off female cables and added a Maretron field installable connectors and voila it worked perfectly and saved 8 hours of work rewiring half of the backbone. Lesson to others: make SURE that all of your connectors are facing the right direction particularly when you are using quasi- backbone spur devices like the 200WX or even the STng instruments like the p70
Thanks to all for your suggestions and help. And thanks to NMEA 2000 which let me mix and match the best system possible.
I have a Furuno Navnet 3D network with a SC-30 Satelite Compass.
I want my Raymarine autopilot EV-400 package to receive HDG (heading) from Furuno SC-30.
I’m using this Raymarine SeaTalk-SeaTalkNG converter kit, and manage to get waypoint data from Furuno MFD12 to my autopilot, BUT: – no Heading !
Anyone ?
I recommend calling Raymarine tech support or using the forum I’ve heard good things about: http://raymarine.ning.com/
But I’m afraid what you’ll learn is that the EV Sensor Core tightly integrates heading and other motion info with the autopilot processor and can not use another heading source. I believe that the Garmin autopilots are also limited to their own included heading sensors and there may be other manufacturers who have limited such flexibility for purportedly better AP performance.
Also, I don’t understand how the SeaTalk-SeaTalkNG converter is working for you. I think you should be able to use premade adaptor cables to put the EV-400 and Furuno gear on the same NMEA 2000 network. That should give the EV waypoint data and the Furuno a choice of EV or SC-30 sourced Heading and other data.
By the way, I’ve found the EV1 to be a very good heading source on Gizmo, no calibration needed, but it looks like you will be able to compare it to the probably even better SC-30.
Sorry, my mistake …
I wrote: “I’m using this Raymarine SeaTalk-SeaTalkNG converter kit”, BUT:
Of course I’m using a NMEA2000 Spur cable from my Furuno MFD12 to my Raymarine Backbone network where the ACU-400 is connected.(The SeaTalk-SeaTalkNG converter has nothing to do with my problem…)
My SC-30 is connected via my DRS4D radar ti the MFD12.
I’m very disappointed about my new autopilot when sailing dead downwind in very large seas. It’s not fast enough !
I need to take over and steer manually.
So I hope the SC30 will do the job better….?
I suggest that you question your assumptions, Regina, and contact Raymarine. You’ve got an autopilot with a very good AHRS built in that is doing good work for many users. See if Ray can help you make it work better on your boat.
https://panbo.com/archives/2014/06/raymarine_2014_science_cadence_ireverywhere.html
Greetings, I’ve tried to make sense of the above discussions, but not sure if they apply to my case. I am installing all new B&G instrumentation on my boat connected via N2k. However, I still have Autohelm (Raymarine) instruments (ST 50+’s – multi, wind, depth, compass) on bulkheads that I would like to keep there and display data from my new sensors and B&G instrument. I don’t see how to do this with the converter at the top of the page (I don’t see that the seatalkng pin configuration matches the N2k configuration). Please enlighten me. Thanks, JP
Hi JP. I think the Converter will work for you, but you’ll also need a SeaTalkNG to DeviceNet Male adapter cable. Your current SeaTalk network will plug into one white connector on the Converter and the Adaptor cable will plug into the other white connector. The Blue STng backbone connectors and the yellow power connector will not be used.
In other words, the Converter will be installed as a single device on your new B&G N2K network, and your old ST instrument displays will receive data converted into SeaTalk protocol. More info here and I recommend double-checking my advice on the Raymarine support forum.
https://www.raymarine.com/view/index-id=400.html
https://www.amazon.com/Raymarine-SeaTalkng-DeviceNet-Adapter-Cable/dp/B0193C1QEY
https://forum.raymarine.com/
Thank you, Ben, I shall try that and report.
Another option/comment? I understand that Actisense has a N2k to NMEA183 converter. On my boat I have several NMEA183-Seatalk1 bridge boxes (from Autohelm). One in particular seems to convert the compass (Raytheon heading sensor) which “trasnsmits magnetic compass heading data to equipment that is NMEA183 compatible” such as autopilot systems (I have an ST6000 autopilot controler). So I could also use the Actisense converter and feed the output to the 183 to seatalk bridge?
To be clearer: I have an Autohelm type 300 computer controlled by the ST6000
I have migrated to a NAC3 autopilot computer but I was thinking of keeping the Autohelm set up as a back up
JP, I think that SeaTalk was an improvement on NMEA 0183 in the sense that it can multiplex more data. So while the Actisense NGW-1 is a powerful tool, you may encounter issues trying to push much data from N2K to 0183 and then to ST. Again, Actisense and/or Raymarine may have advice.
https://www.actisense.com/products/nmea-2000-gateway-ngw-1/