Panbo punts, Garmin grieves
This entry’s title is not about cause and effect; my wind sensor testing may go incomplete, but that has nothing to do with Garmin’s chart problem. And while I had a good time on the water yesterday, even if frustrated by details, the mood in Kansas seemed a bit morose. Imagine the satisfaction of introducing all the free and amazing enhancements in Garmin’s 5.0 marine software (which I was enjoying immensely, as seen above), but then just a few weeks later realizing that there was a processing error in the creation of new and improved Bluecharts that was potentially so bad that you had to recall all the 2009 chart cards sold so far around the world. Ouch!
Fortunately, the g2 Bluechart problem does not effect any built-in charts, so no one has to send back a plotter for reprogramming. But Garmin does want everyone who has a chart card dated March, 2009 to trade it back in for a 2008 card, with a 2009.2 replacement promised at least by late fall (they have to take a hard look at those new data processing routines). Garmin has a FAQ here, and there’s a THT thread going here. And let’s note that Raymarine also announced a bug problem recently, which delayed what is purportedly a major software update for some of its gear. And credit both these companies for going out of their way to make sure I knew about these problems, so that you all would. I think they deserve our sympathies, too; the marine electronics industry isn’t exactly booming, and glitches like these have to hurt.
Now, about my N2K wind system testing. First of all, take a good look at that Garmin screen above. GPS and Heading are coming from the Airmar PB200, and Apparent Wind from Garmin’s own GWS 10 (it was easy to choose any of the five sources on this 5212 or on the GMI10). Note how well the data lines up, even in quite light air. The situation seen below is even tougher; I’m running at 5 knots with 3-4 knots of True Wind on the starboard quarter. I think the level of sensor agreement is pretty remarkable, but there are issues with even a visual comparison. The ST70 wasn’t really useful as I couldn’t tell which sensor it was using and, besides, I don’t think it will calculate True Wind relative to boat with SOG instead of STW. (Raymarine’s software update may deal with these issues, and Gizmo will soon have an N2K paddle wheel transducer.) And I couldn’t get the DSM250 to show True Wind from Maretron’s own WSO100 because to choose sources you apparently have to turn off devices, even if they also offer GPS and Heading (but there may be techniques I don’t yet understand as Maretron’s display and N2KAnalyzer software is getting rapidly more sophisticated). Plus there’s the fact that each display’s default dampening is different.
Besides, as several commenters have suggested, the best way to closely compare sensors is to record all their raw outputs while they experience the same wind and boat motion, and then look for outliers (if you don’t have a wind tunnel for “ground truth”). Having all the data on one N2K bus is part way there, but I don’t yet have the means to collect and analyze that data, and I’m not sure when I will (Intelligent Gateways would help, if they ever materialize). But would I find any meaningful differences? My impression so far is that these sensors all work fairly well — and share data across an N2K network very well — and so the significant differences for users tend to be about installation (cables, bases, terminals, etc.) and the sort of instrument or MFD you’ll need to calibrate/manage the sensor. Other issues of interest include the effects of water on the ultrasonic sensors and how well a multi modal sensor like the PB200 can compensate for mast motion. I’ll attempt to cover all these bases in an article I’m writing for the September issue of Cruising World. But as for comparing wind sensor precision, I’m kicking that can of worms down the road.
“My impression so far is that these sensors all work fairly well”
I’m sure this is what you’ve observed, but I’m also quite skeptical that the results extrapolate to a sailing yacht at sea.
1) There are no sails to create updrafts or unusual flows to your instruments.
2) My experience last year in Penobscot Bay is that the weather is quite benign with essentially no seas and light air. Though perhaps a good dense fog will help explore the question of whether the PB200 is affected by rain.
3) Your “mast” is a bit stubby by sail boat standards.
You need some significant seas and a longer lever to challenge the wind sensors. Based on my experience, the real test of wind direction accuracy is in moderate air, downwind, with a good following sea so that the masthead is rolling around a fair bit. I realize it’s not practical, but putting your test rig on top of an 80′ mast in 12 knots of true wind with 6-8′ quartering seas would quickly sort out the question of which sensor is more accurate.
Your test environment is about as optimal an environment for the instruments as can be found. If you do discover any real performance differences, the non performing sensors must be considered to be very flawed.
While I believe about 80% of recreational vessels are motor craft, I think accurate wind data is probably of much greater concern to the other 20%.
You should check out NavMon, it looks like it will log all the NEMA data for you.
http://www.sailvalis.com/NavMon/#logging
Essentially you’re right, Russ, but note that I have that whole sensor board on a single Ram mount, and I have secured myself behind it and tried to simulate heeling and mast jerk. Also it was somewhat foggy yesterday and there were seas enough to sometimes spin the wind vanes.
By the way, what’s your experience with the Furuno wind sensor?
Actually I did log the data — two ways even (CE2009 and GPSGate) — but it’s in NMEA 0183 format, via the Maretron USB100, so lots of important attributes are stripped out. Like which sensor sent the wind message! Happy to send it to anyone who wants to fool with it, though.
I think it’s hard to simulate the effects of putting a sensor on an 80′ pole in an 8′ sea.
My experience with the FI-501 has been ok but not great. Virtually all of my experience has been at sea in open water where the wind is relatively stable. I had actually planned today to contact support to try to tweak it further.
With respect to wind speed it is fine (though of course I have limited objective data to measure this). Wind direction is another story. There are 3 areas where the wind sensor data is used: 1) FI-50 instrument display, 2) MFD data display, 3) NMEA 0184 feed from MFD to autopilot.
On the FI-50 instruments I have the wind fairly damped (6 on a scale of 0-12) and while it smoothed out the variations, it also introduced a significant lag. And in the “true test” conditions I described in my earlier post it still swings quite widely.
On the MFD there is a graphical display which makes no attempt to be precise – it uses a 20 degree colored band to depict the wind directly. With no damping the wind data digital display will swing 30-90 deg in 1-2 seconds, it’s really raw data and useless. I have the damping set to 20 sec and the data still jumps around +- 15 degrees; I have to mentally average what I’m seeing to use the data.
Furuno could improve the “optics” of this by reducing the screen update rate which appears to be about 10/sec, and dropping the tenths of a degree on direction, both of which contribute to making the data appear very “nervous”.
The 183 feed to the autopilot appears to be the raw data, but damped to the 183 data rate of about 2Hz. It also swings fairly widely, a little worse than the MFD with 20sec damping.
I have an 80′ mast if you need it 🙂
Russ’s comments ressonate strongly with me.
While measuring wind speed seems to be no problem, wind angle measurement on sailboats is terrible.
Quoting from Bobc in regards to a popular wind vane can cup unit “This is sailing’s equivalent of a random number generator and you could reasonably expect to beat it with a damp finger held up in the air and that alone would probably be more reliable over time. ”
Just on a comment re logging 0183 and 2K data streams, Noone seems to do a direct NMEA 2K to PC interface that lets you see the raw 2k data stream, I thought Maretron had plans to release something like that , but instead they released a 2K to 0183 gateway which as you point out removes a lot of useful data
Dave
Testing the accuracy of wind systems would seem to be a two part testing plan. First, is to test the transducers alone to see what the raw data differences are if any. Second, is to see how effective the displays are at dampening the variations and providing usable data. For sailboat autopilot use the display dampening may mean nothing, as the autopilot will likely be seeing the raw data directly from the transducer.
There is a program called CANCapture which will log the raw data, allow it to be played back and provides for graphing as well as creating custom displays for PC use. It was developed for use in industrial SAE J1939 CAN bus systems which is what NMEA 2000 is based on. The company says it is NMEA 2000 compatible. I would buy it myself, but I dn’t have enough NMEA 2000 devices to make it worth while.
Check it out at http://www.cancapture.com/
Dave G
Actually, Dave, the Maretron USB100 can output straight NMEA 2000 data, and does to Maretron’s own software (N2KAnalyzer and N2KView).
The hang up seems to be that Maretron and other gateway developers like Actisense can’t make that feed available, and especially can’t allow messages to be sent back onto the ackbone, until NMEA finishes its “Intelligent Gateway” rules.
Why the Intelligent Gateway hasn’t surfaced almost two years after NMEA said it was ‘almost’ ready, I don’t know. But I am getting ticked off about it.
I can understand not allowing data back onto the network, but why couldn’t Maretron provide the API for reading the net traffic?
I’m traveling this weekend, but have been trying NavMonPC (link in DeepPlaya comment above) on a little net book I acquired and it’s impressive (so is the Asus EEE 10HE, more late). For instance it can play back both the CE2009 and Franson GPSGate log files I collected while testing wind sensors on Friday though their formats are slightly different and they are 10 and 23 megs big. It even does strip wind charts, though, in this case, it’s hard to say what they mean.
Ben, do you know CANalyzer? It’s used in the automotive and aircraft industry, but has an option to also understand the NMEA dialect of CAN:
http://www.vector.com/vi_canalyzer_nmea2000_en,,223.html?sprachumschaltung=1
I have a Garmin 4212 with Vision charts. I love the Garmin however, I would not recommend it for two reasons.
1) The charts in the area I cruise seem to be unreliable. For example in North Florida on the intercoastal waterway from Ponce to St Augustine the charts seem to be progressively off. In St Augustine they seem to be @ 200 yards (!) off. I also had problems in the lower Abacos with the accuracy of the charts. Interesting the old Garmin charts don’t seem to have this problem.
2) Garmin back lighting does not go low enough for safe nighttime operations. It is much too bright and kills your night vision. I have heard they fixed this however, I downloaded the fix and it did not appear to impact the back lighting problem.
In my opinion these are gating problems and would keep me from recommending an otherwise great product and product line.
I have a Garmin GPSMap 4210 and 4 GMI10’s in my installation. The 4210 is definitely too bright at night even at it’s night setting and the lowest backlighting level. The GMI10’s are very good however. The difference is the 4210 has CCFL florescent back lighting and the GMI10’s have LED back lighting. At the Miami boat show in Feb, I talked to the marketing director at Garmin about that and he stated that Garmin is working on the problem and will offer a LED back lighting upgrade for the MDFs. I have been after them ever since to get the upgrade, but it is “still coming”. I am on an e-mail list for updates and still hope to hear something soon.
What am I doing in the mean time? I have found a Loose knit red cloth that I cover the screen with. It is transparent enough to see thru and helps a lot. However to see real detail, you have to lift the cloth, so there goes your night vision.
Bruce
Ben I submitted this some time earlier but suspect that it got lost. I’m in Portland headed your way in the next few weeks. Look forward to meeting you.
Bruce
One of my friends has some queries on the tokimek ecdis EC-8500… I wonder if any of you could throw some light on how to address these?
1) SYNCHRONISING….
I have two ecdis’s connected, though routes when drawn on one ecdis get updated on the other, other items like abort points and no go areas do not get updated using the synchronise option. How do I get ev’thing on one ecdis get updated on the other?
2) HANGING…..
I have been using the ecdis to plot positions, enter route plans etc… now it has begun to hang nearly once daily (this does not hang if I use the ecdis only as a display without plotting positions manually, making marks, etc). Why is this happening?
3) ERROR MESSAGES…
I often get an error “Geometry failure error” – what does this mean?
When this error is displayed for a route, I cannot monitor this route. How do I get around this problem?
4) UPDATING CHARTS….
When updating the charts, I often get a message “Non-critical error” which displays against a few enc cell numbers… what does this mean?
5) CHART REJECTED ERROR MESSAGE…
When updating charts, some charts have not got updated – the message “chart rejected” appears. But I was able to update these cells for one earlier and two later updates.Why does this happen?
For example….
For one Korean ENC The update log shows an update has been reected, though teh next, and next to next got accepted. However, these numbers are not reflected if I view that chart individually. However the chart catalogue shows it updated to the last. Why this discrepancy in numbers?
An Australian enc shows up as “critical error – Invalid sequence of updates”
Could someone please tell me how I could take care of the above errors…
Thanks
Edward Bono