Raymarine E- and C-Series, the NMEA 0183 limitation
I think the input/output architecture of Raymarine’s C- and particularly E-Series is really quite good. In fact, I’m amazed that the E is still the only system out there offering both NMEA 2000 and Ethernet networking, though the two work together beautifully. But a problem is cropping up. C’s and E’s have only one NMEA 0183 port, but Raymarine keeps adding things you can do with it, mostly recently AIS and Navtex. As the E manual says, “You can connect either AIS or Navtex or other instruments to one display” (emphasis added).
Now, if you have more than one display in your E-Series setup, each can handle a different 0183 input, and the data will be shared across both the Ethernet and NMEA 2000 networks (nice!). But if you only have one E, or a C, well then you may need to investigate the sometimes complex world of multiplexors (referenced at the bottom of this AIS entry). But don’t expect them to multiplex Navtex because apparently that’s not really 0183 protocol anyway. Raymarine tells me that they really wanted to put more 0183/whatever ports in these machines but just couldn’t fit them along with all the other I/O. The limitation might come in to play when, say, choosing between a 2000 or 0183 ultrasonic weather station.
The C series is not very “good” as far a NMEA is concerned.
Once you set the com speed both the input and the output baud rates are the same. AIS requires 38,400 so if you have NMEA 183 listeners requiring 4,800 you are out of luck.
I tried a work around, but it requires one of the NMEA /SeaTalk interfaces which talks and listens at 4800 regardless of the baud rate set on the NMEA ports on the main unit (C series).
What I have found as I try to interface NMEA instruments of as old as 15 yrs or so is that NMEA data is embedded in NMEA sentences and various instruments use various sentence to “look” for the data, or send it out in their chosen NMEA sentence.
So, you just might be able to get the bit of data you are seeking.
And example of this is as follows:
I am using a KVH Sailcomp 103AC for heading info and as a cockpit repeater for BTW, DTW and XTE.
I am also using a B&G NavAid which can repeat up to 12 bits of data, COG, SOG, XTE, BTW, DTW, TTG etc.
Using the C80 at 4800 baud the KVH heading date IS read by the C80. But the B&G will not show TTG. The KVH will not show XTE.
If you connect these instruments through the Seatalk NMEA interface… the B&G will show TTG, but not BTW and CTW and XTE, not sure if the KVH shows XTE as I have not done the test while moving.
Clearly there is something rotten in the state of NMEA.
Brookhouse claims that with their programmable multiplexer you can find the data need, and reformat it so that you can get what you need with software. That remains to be seen.
Right now I am trying to get the AIS to work on the C80, but sv Sarah reports that it is not ready for prime time. (v3.18).
I will try to get a laptop on board and see if I can sort out this sentence nonsense. But this sounds like NMEA 183 is not a language but a series of dialects.
By the way, Raymarine tech support (live) hasn’t a clue about this.
This probably explains why their patriot missile was such a failure and nothing more than a publicity success.
What say you?
Jef
sv Shiva
Contest 36s
Does anyone know if standard NMEA messages, when multiplexed up to 38400, are ignored when the port setting is AIS 38400. If this is the case it is something that Raymarine should fix ASAP.
Cain,
Raymarine says, “Standard NMEA Messages (at 38400 baud ) are received/processed when in AIS 38400 mode.” They also pointed out the Actisense NDC-2 as (another) multiplexer that can mix data coming in at different baud rates.
Perhaps someone who actually “reads” NMEA 183 can explain the deal with data being inside of several NMEA sentences and different comapnies use different sentences… True or not true? If true. Why?
All NMEA sentences look pretty much like:
$xxMWV,096,R,0.00,N,A*1C
The xxMWV is the name of the sentence, the above is wind angle and direction. 096 is angle, can range from 0 to 359. R is reference, can be R = Relative or T = True. 0.00 is wind speed. N is wind speed units, N = knots K = km/hour, M = meters/sec. A*1C is the checksum field.
There are different sentences for different data. I know some companies pass their own propriety sentences via NMEA also, this makes it a pain because the sentences are not mentioned in the NMEA manuals making troubleshooting difficult.
Raymarine, has NO interest in fixing any of their serious NMEA issues, i just spent over 2 hours on the phone with “Winston” and not only he has no clue about interfacing, nor the attitude to help.
what a waste of time and money these instruments are for the “serious” navigator!
astolfo,
Don’t know if this is helpful, but various Raymarine instruments filter nmea sentenances. For example the SGx series autopilots have two NMEA ports that each operate a little different as to which nmea sentances they will accept and which they will send. (for example only one of them will send fast nmea heading information). The nmea ports on the charplotters are the most useful, and take advantage of networking capabilities between charplotters if you have more then one.
I am using a C-80 and a Brookhouse AIS-C multiplexer, connecting a Smart Radio SR-161 AIS, KVH Azimuth 1000 compass, and ICOM M504 DSC VHF radio.
The C-80 is setup @ 38400 to the Brookhouse AIS-C Mux. The Smart Radio AIS connects to the Brookhouse AIS port @ 38400 as well. The KVH is connected to a mux port that does data pacing which discards about half of the 10 sentences per second output from the mux.
On the return side (from the C-80) the Brookhouse mux has a 38400-to-4800 speed conversion buffered output, so the ICOM is connected “full duplex” to the multiplexer at 4800 baud both ways.
No issues so far.
Actually the issue I am having with RayMarine is that I have a DSM300 sounder with speed, temp, and depth transducers connected to the C-80. I also have a Seatalk connection from the C-80 to a ST60+ graphic display.
For some odd reason, the speed on the ST60+ display will only read in Knots. The speed information is coming from the DSM300, through the C-80, and to the ST60+. The C-80 itself is setup to display MPH, and it displays speed on its display in MPH, but seems that the SeaTalk outbound bus from the C-80 will only output speed in kts.
I did talk to RayMarine Tech Support, and they suggested connecting the ST60+ through the NMEA 0183 port rather than the Seatalk port!
While this works OK for speed, unfortunately, depth is not output on the NMEA0183 port.
But to confuse things more, I have a NMEA 2000 network connected to the C-80’s SeaTalk2 port, along with a Lowrance LMF200 NMEA2000 display on the same NMEA 2000 network – and yep, the Lowrance display shows speed in mph and depth.
Seems the C display has a funky interface.
I have a Milltech SR-161 AIS reciever and Maretron NMEA-2000 instruments all connected to a Simrad AP-16 autopilot and a laptop computer running The Cap’n. The computer is set up to read 38400 Baud from the AIS and 4800 baud from the autopilot. Every thing seems to work well except I can’t get the TTG to cross from one to the other.
Bob
i have a problem with a new E80 display whihc have set up for AIS. It works fine, however, periodically the E80 reboots itself, Did the usual simple tests. such as running the E80 at the dock with ALL other electricals OFF.
A tech. came out form the local supplier andf what he told me was that the E80 is rebooting when it gets bad AIS messages from ships.
According to him, Raymarine knows about the problem and is working on it.
Have others experienced this?
Raymarine #($*&#$ !!!
astolfo wrote “Raymarine, has NO interest in fixing any of their serious NMEA issues”
… it’s easy to believe that. I have serious issue with my Sirius module from Raymarine, and they are not taking it seriously.
Since nobody else complained (that the doppler radar information is incorrect over long island sound, showing rain where it isn’t), they are closing my problem out as solved after asking me to reset the unit. This is after I provided pictures.
Once again tonight it happened, Sirius shows a large rain storm with actual precipitation passing thru Huntington, NY, while my crew and I enjoy a striking sunset. When I went to update the Ask Raymarine web-site, I see that George Martin closed out my issue again. I know one obvious question he should have asked me to investigate this further, and he hasn’t asked.
Probably some calibration issue in converting the high res pixels from the source, into low resolution pixels for the E-80, that someone has changed for the worse.
#$)(*$)#(*#)($*
Very fustrating when you provide photographic evidence and they deny their’s a problem. At some point I will succeed, but it must be twice as fustrating when your dealing with NMEA issues that are difficult to document.
For once, Raymarine is innocent, b393capt! The culprit is the weather service that compiles the data. Your unit just puts that picture on the screen. Think of it as a TV set in your living room. If the TV weather guesser’s radar misses your rain shower, don’t blame it on Panasonic or Sony!
Guilty !! of poor customer service.
Perhaps my post was misunderstood. I agree my problem (probably) is in the compilation of the data (specifically I mentioned calibration issue in converting the high res pixels from the source, into low resolution pixels).
If anything, that should raise the seriousness of the technical issue when the source of the problem is a vendor that is causing your product to be unusable to multiple users … but I couldn’t get them to focus on that, or even my problem individual problem, without four contacts. Even now 9 days later, they have not asked me a single follow-up question, including the obvious “has it ever rained on your position while the sirius showed no rain in the area”
I believe the focus on the Panbo sub-thread is that it’s difficult to get Raymarine to appear to care about serious issues, in my case I had agreed entirely given I had photographic evience and ran into issues that they wouldn’t take the problem seriously … I imagine it gets harder when you can’t capture a problem with a picture.
Perhaps Ben can do an industry survey on customer service across the major providers. Perhaps compile from us how many of us are Raymarine, Garmin, etc. users, what we feel our average time to get a first response, our average time to get an answer, and our average time to get a right answer/resolution. % of times our resolution needs a software update, how software updates are handled, etc. Sell the survey to the majors, maybe including a contrast of how the results compare to other industries, and do some follow-up seminars. I would love for Raymarine to get feedback that they would listen too.
… or maybe offer a free subscription of Panbo to customer service managers.
Sandy, I don’t think that displaying sat weather is analogous to a TV signal. There’s a lot of data processing going on, and I recall that Raymarine had already had a problem with bouy wind speeds that they admitted had nothing to do with the (correct) data Sirius was sending.
That wind incident may be on Panbo somewhere but I’m hesitent to search as I’m sitting on my back porch swiping a weak WiFi Internet connection from a neighbor. I bring it up because I had an absolutely horrid Verizon DSL customer service call last night. I spent at least an hour with a guy in India rebooting modems and routers, trying to bypass the router, etc… even though I was pretty sure it was something in their network and kept asking him to check.
You know the end of the story; after all the tedious procedures failed, he put me on hold to talk to his superviser…then told me that, sorry, it WAS a network problem. And I should try to reconnect in 24 hours. 24 hours! Do these people know who I am!
Seriously, prior to last night I would have told you that I’d had excellent luck with Verizon telephone customer service, and that I’d gone some 3 years with no need to call about their DSL service.
I do keep notes on marine electronics customer service, which I often call like a regular joe rathe than getting management involved. But I think trends are very hard to identify.
In any event, Raymarine has great support often. They are quick and accurate with answers to problems they are aware of, but have amazingly poor support when I am the first to report a bug, worse yet when I report a bug on a feature most people don’t use, and hopeless to get a resolution that requires a software change, they just don’t seem to have a mechanism to issue patches.
I especially hate when they close out your trouble without resolution. I am on my 4th page of My Stuff – Questions, on Ask Raymarine, due to having to reopen the same trouble multiple times.
I wish that help desk on-hold messages would mention what times of day and days of the week are likely to have shorter hold times. I also wish there were more technicians lurking on the forums. I’m sure there are ways around the problems that might ensue. Verizon has hit the nail squarely on the thumb with offshore call support reading cookbook solutions. Customer support is supposed to make customers happy, not grind them down to futile surrender.
just wondering if anyone has tried connecting a garmin 5200 to some Raymarine st-60+ instruments. do they run at the same baud rate, speak the same language? and the physical connections as well? thanks!
If I connect a NMEA 2000 Lowrance LMS-525 C Df fishfinder via the correct cable to to my Seatalk 2 port on my Raymarine C80, who also has NMEA 0183 depth signals coming to it( from Tacktick transducer/display), will it display the depth of the 0183 device or the 2000 device on the C80? What will it output to the displays of the 0183 device(Tacktick)?
Rebecca
I have done a small bit of experimentation on this issue. I have an E-80, a Lowrance LMF-400 display, a ST-60 depth instrument and a NMEA2000 depth transducer.
I started with no connection between the E80 and NMEA2000 network. The ST-60 Seatalk depth was being displayed on the E-80 and the NMEA2000 depth on the LMF-400. After connecting the NMEA2000 network to the E-80 both displays continued to show the depth sources that they started with. The LMF-400 displayed more data from the Seatalk network. I then disconnected the NMEA2000 depth transducer. The LMF-400 showed an error for a few seconds and then started displaying the ST-60 depth.
I did not test disconnecting the ST-60 depth, but it seems that each display locks onto the first depth transducer they see. I can do more testing, but I would not be surprised if software versions matter, so my test will probably not be definitive.
Jon
Thanks, Jon. I’m not sure, but I think that your E80 politely does not bridge depth data over to NMEA2000 because it sees that it’s already there. But when it goes away, the E starts sending it. I would have guessed that the E would take SeaTalk2 (N2K) depth over SeaTalk depth, but apparently not so. It would be interesting if you unplugged the the ST-60; hopefully N2K depth would pop up on the E after a pause.
Rebecca, I don’t know the answer to your question, but there’s no harm in experimenting. The Raymarine OS does not let a user choose data sources, but it is pretty good about failing over to available sources. Please let us know what you find.
My experience with the ST60, speed, depth, and NMEA-2000 should translate into similiar functionality for depth and speed in reverse as follows.
I have found that once the ST60 decides that it has a speed source on it’s dedicated transducer terminals, it will transmit that speed source over seatalk and the E-80 will choose that over an NMEA-2000 source. This includes other E-80’s interconnected via ethernet. If the ST60 has no speed transducer connected but has a depth transducer connected, it will transmit only depth and sea tempurature over seatalk and will listen for and display speed that originates from the NMEA-2000 bridged thru the E-80 (again also thru interconnected E-80’s via ethernet)
Stepping back a bit from specific NMEA0183 issues, the root causes of the problems are generally as follows:
1. In general, there are multiple possible sentences for sending the same piece of data (e.g. GLL, RMC, … for position).
2. Talker devices will typicaly only output a subset of all possible messages for the data they produce.
3. Listeners will again typically just read a subset of the available messages.
4. Some pass-through devices will only pass through those messages thatthey understand, rather than all messages received
5. There can be some issues with different version of the NMEA0183 standard developed over the years
6. There can be timing issues, e.g. uploading route and waypoint data from a PC to a chart plotter often fails here
7. NMEA0183 has low bandwidth, so chuck a lot of data through it and using a multiplexer and some messages will be dropped – OK for those that are repeated often, but not for one-off messages such as waypoint arrivals
By the way, although leisure NAVTEX units don’t use NMEA, commercial units such as the Furuno NX-700 and McMurdo NAV-7. THis is supported by our PC Navtex software, but not by any leisure kit as far as I know.
Tim Thornton
Smartcom Software
Hey Jeffery, This is a long shot but you are pretty hard to find and this is the only actual contact that I have found so far. I was thinking about sail boats and you crossed my mind remembering the old days.
Hope to hear from you or maybe that someone who reads this knows you.
Cheers, Chris Willsey