60csxuser

Hi Red9 and Moun10Bike, Regarding my original issue 1: - I tried switching between Course Pointer and Bearing Pointer, but it made no difference as to which route waypoint the unit selects as next waypoint. - I verified with another Garmin (eTrex) that it indeed does select WP2 as the next waypoint, just as my 60CSx does and Moun10Bike says. BUT I still don't regard that as a logical way of working, at least not for marine navigation. In my world a route is a safe path through rocky waters. And this includes the first route leg. Thus the unit should guide me to WP1 to begin with. At least unless it unambigously can conclude that I've already passed WP1 or a subsequent waypoint. In my previous units, (Philips AP Mk 5 and Magellan 315) as far as I can remember, the unit guides me towards WP1 in the route (basically by creating a "Leg 0" starting at the present position when the route is activated). I tried a workaround by first activating the route and then making a GoTo to the route WP1. That almost did the trick, but unfortunately the unit in this case when reaching WP1 does not auto-advance to WP2. A manual recalculate is necessary. It would seem logical that in this case the unit would auto-advance when reaching WP1, since it "knows" that the route continues from WP1 (it even shows up on the map display). Regarding my original Issue 3, entering a predefined route which has a common start and end point: I've now made several tries with varying results. It has selected as next waypoint either the closest WP, the destination WP or WP2, but never WP1 as I would like. I don't know if this is affected by turning the unit of and on or if some other magic is involved. The usage for me is in our weekly sail races where I'd like to enter the race course in advance as a route, and then just sail it using the GPS as navigation display but without having to touch the GPS at any waypoint. Again, with my previous GPSes this has worked flawlessly, but on this one I have so far not been able to figure out how to do it. So if you have a solution I'd be happy to hear it, even if it would mean changing to some other GPS brand. So my wishes to Garmin at this point are two: a ) when approaching a GoTo WP and a route is active starting from that WP, do auto-advance onto the route. b ) when activating a closed route and the start/end point is the route WP closest to the present position, always assume that the user wants to navigate the whole route.

In my case I was definitely closer to point 1 than point 2 when activating the route, and still the unit selected point 2 as the next waypoint. I did make another test where I located myself in the middle of the route and then started navigation. In this case it selected the closest waypoint (number 4 of 7, or something like that) as the next one to go to. This is actually acceptable. BUT in the case that point 1 is the closest one, the unit should definitely select that one as the next waypoint.

Your description is correct, matching what I tried to say. Your test is interesting. It seems the unit works correctly in your case ( i.e. guides you first to Point 1). But are you using off-road or follow-the-roads navigation? I use off road mode. Thanks to the poster who verified the same behavior as my unit shows. Thanks also to those pointing out the autozoom feature. I had missed that one.

Hi, I've found some quite disturbing issues when using my 60CSx for real world marine route navigation in our rocky waters. I wonder if some of you have also experienced them, or if I'm possibly making some user errors, so your comments are welcome. 1. I've created a new route at home with a number of waypoints (easy enough). The problem is that when I activate the route, the GPS does not point me to the 1st waypoint in the route, but to the second waypoint! This is extremely odd, none of my previous GPSes have behaved in this manner. It is as if the GPS presupposes that I'm located at the 1st waypoint when I activate the route. This is of course not always the case. Potentially dangerous! 2. Creating a closed route (e.g. with the same start and destination waypoint) has its problems. Adding the same waypoint the second time can not be done from the map, only via the waypoint list. 3. In addition, when activating this kind of route, it selects the destination waypoint as the next waypoint, and not the start waypoint as it should. The net result is that the route navigation won't start! Even the workaround solution, i.e. making separate pseudo-start and destination waypoints close to each other, is not always working. The reason being that when activating the route, the GPS seems to select as "next waypoint" the one closest by. And if I happen to be closer to the pseudo-destination waypoint than to the pseudo-start waypoint, the GPS locks to it and thinks I've arrived at the destination 4. In some cases, when approaching a route waypoint the GPS automatically zooms out its map for the next route leg. This is not safe at all if navigating a narrow channel. In practice the user has to attend to the GPS to set the right zoom level again, which means slowing down the boat. I'm using the off road guidance method with auto route leg transition. The latest SW version is installed. Comments are welcome. By the way, I've not found any help to these issues in the manual.

Heh, nice thread In my boat, a Philips AP-navigator Mk7 (a 1995-vintage GPS black box which upgrades an even older AP-navigator Mk 5 (originally a Decca-system navigator). Still works and has features that todays units lack Handheld: Garmin GPS II (sold), Magellan 315A (lost), Garmin GPSMAP 60CSx (trying to learn it )

Hi again, after some serious headscratching I'll try to comment TracknQ's post. Remember that a traditional barometer measures the ambient pressure, but is calibrated according to the local elevation (1 mb/27 feet) to indicate sea level pressure. So in a stationary situation one expects that the difference between ambient pressure and barometer reading stays constant, and = 2.8 mb for TracknQ's 75-ft elevation (when properly manually calibrated). I make the basic assumption that the ambient pressure reading of the 60CSx comes straight from the sensor (with some basic dampening) and is not influenced by calibrations, GPS altitude etc. So it can be highly trusted, except for local pressure disturbances such as opened windows. In the first two screenshots the pressure difference is 6 mb, so obviously something is wrong. Remember my "barometer bug" suspicion? The barometer plot shows the same jumpiness as mine, a hint that it is affected by the GPS-altitude (the bug). I guess the unit was in "variable elevation" mode? The 6 mb pressure difference implies an elevation of 162 feet. This jibes with our previous assumption that the GPS device's map datum parameters have a local error that places the sea level lower than it actual level, increasing the elevation the unit "sees". The track log's 2-foot differential may indicate that the pressure was steady during TracknQ's walk. No problem here. In the next two screenshots the ambient pressure change during the night was 1016-1012.6 = 3.4 mb corresponding to a -92 ft elevation difference. Lo and behold, 75 ft + 19 ft equals 94 ft, which is close enough! No problem here either. The final four screenshots show an ambient-barometer pressure difference of 5.2 mb, again different from the 2.8 mb that corresponds to 75 ft elevation, and a hint that the GPS-altitude is again messing up the readings (the "barometer bug"). In order to check this I made a small experiment with my 60CSx. I manually calibrated it to my elevation, 25 m (82 ft) with auto-calibration off and in the Variable elevation mode. The barometer indicated 996.8 and the ambient was 993.8, perfectly according to the 27 ft/mb formula. Within 30 minutes the barometer reading had changed to 995.7 while the ambient stayed constant. (Such a barometer fall of 2 mb/hour would in the real world belong to a hefty stormy weather). In fact this was caused by the "barometer bug". Interestingly, the indicated elevation stayed constant at 25 meters. Setting the unit in Fixed elevation mode instantly returned the barometer reading to the original 996.8, implying that in this mode we don't have the bug. Now we can try to understand the logics of the 60CSx. For some reason unknown to me, in the Variable elevation mode the barometer reading is affected by GPS-altitude even if "auto-calibration" is off (the "barometer bug"). The visible effect of this is that GPS-altitude fluctuations change the indicated barometer pressure while keeping the indicated elevation constant, in effect "moving the sea-level reference". Whereas changes in the ambient pressure due to weather change the indicated elevation while keeping the "sea-level reference" constant. Complex, yes! Hopefully this explanation has not caused an even higher level of confusion.... The practical conclusion so far: Trust the barometer reading only when in the Fixed elevation mode. Actually this makes great sense, as any barometer applications I can think of are either stationary or move only horizontally (such as a ship on the seas). edit:typo

Hi TracknQ, This is the link to the posting: http://regex.info/blog/2006-04-16/179 . As to your very interesting "creep" table. Google was kind to me and found this site which gives an on-line barometer plot from Honolulu Airport. As far as I can decode it, the pressure variations are not very strong (within 5 mb) but fairly quick. For example, the pressure rises 1,5 mb in 2 hours from 04:00 to 06:00 UTC on the 27th. Assuming your walk was 2 hours, this pressure rise corresponds to a change of 41 feet in the indicated elevation. Your "auto-cal off" results show lower elevation "creep" than that, so I'd be inclined to explain the "creep" with the pressure variation. You might want to compare your future results with the air pressure variations plotted at that site and see if your barometer plot matches theirs, in which case you may use it to correct your elevation plots. As to the "GPS auto-cal on" results, one reason could be if the GPS map datum parameters happen to have a local error which puts the GPS-defined "sea level" below the actual sea level. I'm not familiar enough with the auto-calibration workings, but one guess is that it strives to "pull" the device's elevation reading towards the one indicated by the GPS altitude. And if the GPS map parameters give wrong data about the local sea level elevation, this may result in the "creep" you see. You might want to give the GPS time to calibrate itself for one hour or so before starting your walk and see if it makes any difference. This link may be of use.

Hi, I agree it would be excellent to have a detailed description by Garmin (not only for the altimeter by the way). You are probably right that autocalibration may be good when moving. Problem is, it seems it's not so good when stationary. I've thought about if it's possible to devise a way to suppress autocalibration, or at least give a warning, in situations that it does more harm than good. One possibility might be to utilize the fact that ambient pressure usually changes slowly while GPS altitude varies much more rapidly. For example, even in a quick ambient pressure change (weather stormfront) the corresponding altitude change rate is slow, less than 1.5 fpm (foot per minute) while in my NMEA recordings the GPS altitude change rate is in many cases 500 fpm or even more. So in theory, if the GPS detects it's more or less stationary, it should disregard quick changes in GPS-altitude, while if it's moving, quick changes should be recorded. But to implement this in a reliable automatic feature is probably easier said than done As to the bug suspicion, I presume the main intended use of auto-calibration is to enhance the accuracy of an elevation plot. So in the elevation plot it's OK to use it. But to me, a barometer is a barometer and should not show anything else than pressure variations. At least I can't think of other barometer applications than stationary and 2D (sea navigation).

Garmin 60CSx altimeter testing, Part 2... with a surprise This time the altimeter auto-calibration was off and the altimeter manually set to an elevation of 28 metres. The altimeter was left in the Variable elevation mode (more on that later). The test was run for slightly more than 12 hours (21:18 to 10:05). This time the GPS was located close up to the window glass. Also, it was connected to the PC with only the NMEA serial cable. In the previous test also the USB cable was connected to power the GPS. I have a hunch that the cable connection might slighly degrade the GPS reception due to additional electrical noise entering the GPS via the cable. Anyway, the reception conditions improved because the GPS-altitude track, as recorded over the NMEA link by OziExplorer, collected only 3157 data points and the "virtual travel distance" was only 13.95 kilometres this time. The track recorded by the unit itself contained 722 data points. Let’s again start by looking at the ambient pressure plot. The Garmin shows a 1002.7 mb high at 01:42, a 1002.1 mb low at 05:10 and rises through 1002.8 mb at 10:00. The Vaisala plot shows a 1003.8 mb peak at 01:50, a 1003.3 mb low at 05:30 and 1003.8 mb at 10:00. The differences in the pressure changes between both devices are thus around 0.1 mb, which is good enough for practical use. (Note that the absolute pressure values differ by around 1 mb, I assume this is due to the difference in elevation between the two sites). Next then the elevation plot. The following Excel plot again shows the NMEA-logged GPS elevation data in dark blue. The violet colored line is a 10-point rolling average and the blue line is a 50-point rolling average of the GPS elevation data. The yellow line is the Garmin’s elevation plot, in this case non-auto-calibrated. The yellow line as well as the Garmin screencapture show an elevation variation of around 10 metres, which corresponds very well to the 1-mb pressure variation. Also the timing of the highs correspond to the lows in the pressure, so this shows the Garmin’s altimeter works as it should. The GPS elevation data shows slightly less scattering than the previous plot, although it still is jumpier than I’d expect. Finally the Garmin’s barometer plot and today’s surprise. The plot was as jumpy as yesterday’s GPS-auto-calibrated version. And comparing the plots, for example the peak at 07:36 and dip at 08:20 fit reasonably well with the Excel GPS altitude plot, so it seems clear these jumps come from the GPS altitude. The remedy came when I changed the setup from ”Variable elevation mode” to ”Fixed elevation mode”. Then the plot changed and showed the same smooth curve as the ambient pressure plot, with the reading differing by 3.1 mb which corresponds close enough with the 28 metres elevation value I used in the manual calibration. But this seems like a clear bug in the 2.70 software in the auto-calibration off mode. Apparently the unit stores the GPS auto-calibration values in any case, and then erroneously applies them to the barometer plot, if the unit is set to variable elevation mode. That’s at least how I understand it. I wonder if this is the same ”2.70 Bug” reported in another thread? Any comments? Anyway I’m considering the following further tests. One is to do a long term (at least 48 h) test of the altimeter (without auto-calibration) to check for possible long term drift. The second is to drive a fixed route several times and compare the in-motion elevation accuracy with and without auto-calibration. I have a hunch that stationary testing of the GPS-altitude accuracy is not very useful, at least in my case with a limited view of the satellites. Hopefully that would improve in a drive test.

Hi, The standard formula is that the ambient pressure decreases 1 millibar for each 8 metres (27 feet) of altitude increase. This also means that if the ambient pressure varies due to the weather patterns, the altitude reading will change. See this link for which pressure changes are typical for different types of weather. What this means, as far as I understand so far, is that a stationary GPS receiver can work quite well as a barometer, which is of great interest for weather watchers. But according to my experiments so far (see other thread) if GPS auto-calibration is enabled, the GPS-altitude deviations will typically cause more altitude errors (especially in the total ascent sum, because of the up/down jumping) than the ambient pressure variation. Either way, obtaining a really accurate altitude reading is difficult. With GPS auto-calibration disabled, you need to find a sufficiently accurate reference barometer. Fortunately the nearest airport always has one. Or then you take a trip to the seashore and calibrate the device there. With GPS auto-calibration on, a very long averaging period is probably needed to smooth out the momentary errors in GPS altitude. Unfortunately the 60CSx does not offer an in-built averaging function. In addition, even if you would get the "real" GPS altitude, there is the question of the accuracy of the map datum parameters. The map datum parameters define the Earth as an ellipsoid with a certain shape, which is only a more or less accurate approximation of the actual shape.

Hi, I looked at your .pdf file and specifically the ambient pressure plots. There was a 1.4 mb pressure drop in around three hours. (A windy day?) Assuming the readings were not influenced by local errors (for example changes in the air streams from the airconditioning), science says this will cause a ~36 ft increase in your measured altitude.

Garmin 60CSx altimeter testing Hello there! Inspired by the posts about the Garmin 60CSx altimeter I decided to investigate its behavior a little further and compare it with the GPS altitude data. Thanks to this forum, I first installed the 2.70 software update and got rid of the altitude bugs reported earlier. First an short introduction to pressure altimeters. A traditional aircraft altimeter works by converting the ambient pressure to an altitude value using the fact that ambient pressure decreases around 1 mb (millibar, sorry for my metric units) for each 8 metres (27 ft). Before each flight it must always be reset according to the current barometer setting, in order to show correctly the altitude above sea level. As the barometer reading, i.e. the ambient pressure at sea level, is constantly changing with the weather, this resetting must be redone frequently (every hour or so). In the 60CSx, this resetting is according to an internet posting done automatically by using the GPS altitude as an reference and making the adjustment every 15 minutes. In this first test the altimeter was in auto-calibration mode and in the variable elevation mode. The GPS was stationary near a window with a view to the northeast. Satellite reception was medium (see screenshot). The real altitude of this location is around 25-30 metres (75-90 ft) above sea level. The test was run for around ten hours during the night (22:16-08:58). GPS altitude was recorded via the NMEA interface and OziExplorer. Ozi was configured to record a track point every time the position changed 5 metres . This resulted in a track with 4591 track points (and a travel distance of 44 kilometres). The 60CSx "Barometric" altitude was recorded by the unit's own track log. This track contained 1120 track points. As a reference I used the 48-hour ambient pressure plot available from the website of Vaisala Inc., a manufacturer of industrial weather sensors, located about 10 km (6 miles) away. Initial conclusions Let’s start with the ambient pressure plot and compare it with the Vaisala data (at the end of their 48h plot). To my eyes they are quite similar, with the exception of the Garmin’s -2 mb dip at 22:59 and 1 mb peak at 23:40 respectively. I have no explanation for this peak but it is possible that it is caused by a draught from an open window or similar local pressure variation. The Vaisala data shows a pressure variation of around 2.5 mb during the test. This means that a traditional pressure altimeter would have shown an altitude variation of around 20 metres (61 ft). Next comparison is the altitude. On the following Excel graph I have plotted the GPS altitude in dark blue. As you can see the data points are quite scattered, so I also plotted the rolling 50-point average (violet) which looks somewhat better. The yellow line is the altitude data as recorded by the Garmin altimeter. It seems quite clear that the Garmin uses the GPS data in smoothed form to adjust its altimeter reading. In this case the GPS altitude varies quite much, so the benefit of the altimeter is mainly to dampen the variations from a 200-metre (610 ft) range to a 50-metre (150 ft) range. The altimeter plot also managed to suppress the erroneous GPS altitudes seen at around 05:30, which went as high as 18000 feet. The GPS intermittently lost satellite contact during that time. This Garmin’s screen capture of the elevation (altitude) is a little misleading since it plots elevation over distance, not time. So the nice long flat part of the graph actually only represents 1.5 hours out of the 10-hour measurement period. I subsequently found out that the Garmin can also plot elevation over time, I will use that next time. Finally we have the Garmin’s barometer plot. I’ll have to retest this as I have problems making sense of it. I theory a higher pressure should correspond to a lower altitude, but the comparison with the Excel altitude plot is not simple. So far the conclusion about 60 CSx altimeter errors is that the altimeter with automatic calibration showed up to 50 metres (150 ft) variation during the test. If the auto-calibration mode would have been off, the variation would have been slightly better, around 30 metres (90 ft) (the main error due to the mysterious dip and peak in the ambient pressure plot) but in that case an initial manual calibration would have been necessary. In this mode also the natural pressure variation will introduce errors. For example, the Vaisala archives showed several recent days with a sustained pressure change gradient of 0.5 mb/hour, which during e.g. an 8-hour period would introduce a 32 m (105 ft) altitude error. Comments are welcome, both on the results and if there is something to refine in the methodology. My plan is to test next time with auto-calibration off, and also try to see if a better GPS satellite view would improve the GPS altitude data, which to me seems less accurate than expected.