Jump to content

Explorist Bug/enhancement List Firmware-5.2.03


D0T-C0M

Recommended Posts

Lets me first start off by saying that this is NOT a Magellan bashing thread. It IS a thread that will compile a buglist/Enhancement list that users on this forum would like be fixed or implemented with this latest e500/600 firmware (5.2.03) and latest e400 firmware (4.2.02). If you haven't yet updated, the general consensus is that this firmware is stable with serveral bugs and issues from the old buglist fixed. The latest firmwares can be downloaded from Magellan's site here

 

The ExploristXL firmware (9.1.05) has less fixes from the old buglist but should be coming in the future. Seeing that the firmwares for the explorist 400,500 and 600 at this time differ from the XL, mainly in feature set, this thread will be mostly based on 400,500,600 models because the XL is still in its infancy and will probably change in the near future in order to catch up to the older explorist models and should logically become identical at some point in time. Therefore we will assume that the XL will have the same features in the future as the current 400,500,600 firmware has and not document the differences in the buglist here.

 

Bugs and enhancements that are common to all Explorists will still be posted. If someone wants to start a separate buglist thread for the XL model, feel free to do so.

 

Magellan is definately watching this thread so PLEASE if you wish to have something added please post it, but AT LEAST reply stating which items your are experiencing (if any). Hopefully as a group we can help Magellan to troubleshoot the issues we are having.

 

Sorry if the text is very small, I'm am posting an image of the list because I can only edit this thread for a certain amount of time after which I can no longer update the list. By adding an externally linked image I can update it indefinately.

 

Again please post which issues you are having or post issues that are not listed.

 

IMPORTANT: THIS THREAD USES IMAGES THAT ARE CONTINUALLY BEING UPDATED BUT USE THE SAME IMAGE FILENAME. THIS MEANS THAT AFTER OPENING THIS THREAD YOU MUST CLICK THE REFRESH BUTTON ON YOUR BROWSER'S TOOL BAR TO REFRESH THE IMAGES. FAILING TO DO THIS WILL RESULT IN YOU HAVING AN OLD IMAGE(S) LOADED FROM YOUR BROWSER'S CACHE AND YOU WILL NOT SEE THE NEW UPDATED IMAGE(S).

 

For easier viewing, hardcopies of the word documents that generated the image lists below can be found here (ExploristBugList5203.doc) and (ExploristEnhancements5203.doc)

 

ExploristBugList5203.JPG

 

ExploristEnhancements5203.JPG

Edited by D0T-C0M
Link to comment

I started the thread so that feedback may be posted. Please be patient as my time is limited during this busy time of the year but rest assure I will compile the feedback given here and update the first thread.

 

PS as much as possible please try to keep the discussion on topic, which is reporting bugs and suggestions to add features/enhancements. I would perfer that you start a new thread if you wish to discuss/debate the issues in detail.

 

Merry Christmas and have a Happy New Year.

Edited by D0T-C0M
Link to comment

May I start?? :P

 

"Card utility" menue seems to be preliminary:

- "Check card" option reboots unit

- Select and delete file option is missing

(I didnt't check the format option)

 

"Projection" is only half the way: you cant calculate distance and direction of two points.

 

Feature enhancement: Geocache-Symbols: Additional Symbols for Micro cache and Unknown cache needed

 

Merry Christmas to everybody!

Edited by DocW
Link to comment

Well While I have some time I want to suggest a few changes to the geocache function.

 

First I like the idea of the found button but there's no unfound button is case you've selected a geocache by error.

 

Second I would like the geocache limit to be at least 500 with full comments.

 

Third I would like to see the hint field increased so that the hints aren't cut off.

 

Forth I would like to see a place to store notes for each geaocache so that we can go paperless. This would be very functional when doing several caches in a trip.

 

----------------------------------------------------------------------------------

 

As part of NorthernPenguin's suggestion in the old buglist thread, Can turn off POI and Geocache names, but the urban parks still clutter the screen with their names.

Edited by D0T-C0M
Link to comment

I said I was going to wait 2 weeks to install the new firmware, but I decided to install it on my eXplorist 400 tonight since the temperature will be warm enough for caching tomorrow. BTW, the 400 firmware is v4.2.02, so some slight nomenclature differences.

 

Anyway, I noticed that when I go to Menu > About, there is no storage usage given for my 512MB SD card at the bottom of the screen. It'll tell me that 56% of my internal memory is used, but nothing about the SD card. It just shows an empty bar with no percentage reading. I don't have much on the card, but the GPSr should tell me something, even if it's just "0%" I don't mind that too much, but it is a potential bug or something that needs enhancement.

Link to comment
Thanks for the heads up, I've modified the first thread while I still can to reflect this

My enhancement request to to have two distinct powersave modes: one for operation on batteries and another for operation on external power. When on external power in the daytime, I would normally keep the background light on high. The powersave options should include all items that accelerate battery loss. That would mean adding beepers, for one, to the power management options.

 

While you are changing version numbers, remember the XL has very different firmware - many items from the original list have not yet been implemented (such as waypoint projection, street route to point-to-point - for a couple.) The XL help about shows version 9.1.05.

 

Also the XL does show capacity in use of both the internal memory and the SD card.

Link to comment

Seeing that the firmwares for the explorist 400,500 and 600 at this time differ from the XL, mainly in feature set, this thread will be mostly based on 400,500,600 models because the XL is still in its infancy and will probably change in the near future in order to catch up to the older explorist models and should logically become identical at some point in time. Therefore we will assume that the XL will have the same features in the future as the current 400,500,600 firmware has and not document the differences in the buglist here.

 

Bugs and enhancements that are common to all Explorists will still be posted. If someone wants to start a separate buglist thread for the XL model, feel free to do so.

Edited by D0T-C0M
Link to comment

Well I've taken the unit out and made a couple more observations, this time with the Canada TOPO map active.

 

- Switching from DirectRoute to Topo didn't cause me too much delay getting my sat lock going on the topo map.

 

- Performance when using Topo is MUCH improved. With the topo-lines and POI data turned on, the unit kept up with me through urban areas with lots of detail and I was travelling at speeds from 5kph to 120kph, never lagged behind me. This was a real problem with the topo contour lines enabled under the original firmware.

 

- Thankfully the true-serial NMEA hidden menu is still there so I can connect this thing to my ham radio. Would be nice if this could be picked from the standard 'communication mode' menu, but I suppose that since one needs to build a serial inverter to use this feature, Magellan probably does not want to deal with it at their help-desk/support line

 

- I would concur with the others: We need an unfound option, and we need to be able to add more data fields to the map screen. I'm willing to go for a small font option for that, but I'd like to be able to track more than two pieces of data on that screen. I really liked the 'data' screen on my wife's eTrex for that stuff.

 

- I don't really care about geocaching hints or notes fields in the explorist as my PDA handles that for me, but I suppose it would be nice during the winter months to not rely on a touchscreen that's meant for indoor use.

 

- I still really dislike having my screen cluttered with the names of urban parks. The green shading is plenty for me and I can move the cursor over to it if I want to know the name of it. (DirectRoute NA) Chances are, if I care about the name, I've selected it as a destination in DirectRoute.

 

- I'd like some sort of indicator, maybe on the data screen with the 'charging' or a small icon on the map screen that indicates the backlight is on full - I get tricked during the day sometimes when the bright sunlight obscures the presence of the backlight until the "LOW BATTERY" indicator comes on.

 

- I'll *finally* get the unit out to do some geocaching tomorrow, I may be posting some more observations after that exercise.

Link to comment

My old list does still have a lot of points missing in the actual firmware:

http://forums.Groundspeak.com/GC/index.php...dpost&p=1649122

 

At this time i am tired of checking every point of our wishlist.

I invested a lot of hours the last months for testing and making a wish list.

 

Sorry, that i do not want to reconfigure the list at this time.

 

Life is beautiful and because buggeling the old EX600 firmware did take so much time for, i prefer to change to GPSMAP 60 CSX. It looks good.

 

Maybe there is anywhere outside who wants do do the job (comparing old list with new one, add features...)

 

For me it takes too much time. (and i do not know, if it will ever be heared)

 

The old list is from AUG 16 2005. - a long time ago for a technical instrument.

 

I admire DOT-COM for beeing so patient. He is doing a job, normaly magellan should do.

Link to comment

Sorry freeday that you feel frustrated like this. While I agree that everything on the old list isn't addressed but realisticly you cannot expect every enhancement to be implemented. We must rejoice that the major and most of the minor bugs seem to be fixed and work hard to let magellan know which features or additions we as a group really want added. For me most of my issues were addressed except for the geocache issues I mentioned in this thread as well as the routing issues. For me personally if these points were addressed, I'd be a satisfied customer, if they address the majority of the other issues I'd be a fanboy for the company LOL. Prior to this last firmware I was frustrated like you were and had Garmin come out with the 60CSX, I'd of probably jumped ship but Magellan surpassed my expectations with this last firmware and did a great job even if it was a long time coming. We must stay the course and continue here and hopefully the next firmware will be even better.

Edited by D0T-C0M
Link to comment

One of my Explorist-owning friends pointed out that all streets names on the map are now written horizontally rather than aligned with the proper road.

 

That seems kind of silly to me to have the text of a road written horizontally if the road is vertical. Did the old firmware line them up properly?

 

Jamie

Link to comment

Ok I tested this out. In my city, name of the main streets (shown in a thick yellow or red line on the map) is is written horizonatally but the all the side streets(shown in single black lines) are written in the same direction as the side streets is. The street name text only appears when zoom in enough for the street name to appear. This is affected by the setting of map detail you have selected in the map detail options. In bigger cities I would imagine where there are more main steets shown with a thick yellow or red line, the more street names will show horizontally.

Edited by D0T-C0M
Link to comment

I'm wanting to give the update a try, sounds great, but without some way of reloading the original firmware I think I'll wait a couple weeks and let you guys guinea pig it.

 

It would be nice if Magellan would post the original firmware(s) also in case a goback is needed. Props to all you brave souls.

Link to comment
I'm wanting to give the update a try, sounds great,  but without some way of reloading the original firmware I think I'll wait a couple weeks and let you guys guinea pig it. 

 

It would be nice if Magellan would post the original firmware(s) also in case a goback is needed.  Props to all you brave souls.

The firmware is stable, you won't need to go back. The new firmware is much much better than any of the older ones.

Edited by D0T-C0M
Link to comment

I'm gonna jump in here with a LONG comment. I upgraded my 600 on the 22nd and ran out and did eight caches on the 25th. (Thanks to Magellan for the email notification of the update!) Some of this stuff is described as fixed in the list of changes, but I thought it was worth some detailed comments.

 

BOTTOM LINE: I HIGHLY recommend updating your 600 to this release. Right away. It's very stable, and there are a LOT of improvements.

 

The update went smoothly, once I overcame a faulty USB hub issue (not any fault of the 600 or firmware). (By the way, if your eXplorist/USB/PC connection is flaky, check your USB hub... it sorta worked but I was attributing the problems to the 600, until the firmware program refused to start the update, which forced me to spot the real problem.)

 

BACK UP YOUR SETTINGS FIRST! BACK UP YOUR SETTINGS FIRST! BACK UP YOUR SETTINGS FIRST! BACK UP YOUR SETTINGS FIRST! BACK UP YOUR SETTINGS FIRST! You WILL lose all your POIs and track logs during this update. Guaranteed. So copy them all to your PC first, and then copy them back afterwards. Be sure to follow the other instructions on the update page.

 

MUCH faster locking times. The unit seemed to take a few seconds longer to BEGIN locking on to GPS satellites, but once it started, it had seven or eight locked in and the map showing my position in about 1/3 the time as the previous load. Less than 60 seconds to lock on after a five hour break. In that case, when it first came on, one of the bars was immediately green, meaning it had ephemeris data for one satellite still in memory - but only one. So this was a cold start, and it still only took a minute. This is a big improvement - all my starts used to be several minutes, even if it was only off for five minutes. Quite a few of my power-on starts were under 45 sec on Sunday. (I WAS used to firing up my 600 and getting five miles down the road before I had a position!)

 

The map display prefs have a number of additional options - geocache icons and names are separately selectable. You can turn off found caches (see above). Also waypoint names and icons are separately selectable. The names don't appear until you zoom in to 0.8 mile range; the caches appear waaaay further out (at least 50 miles before I gave up). (I still haven't figured out how to list found caches from the screen... guess I can download the .fnd file over USB. Maybe I can export one from GSAK to hide ALL found without manually marking each one...)

 

Zooming in and out is smoother - the redraw time is the same, but if you click the zoom button AGAIN while it's redrawing, it gives up on the redraw and zooms immediately. This is a HUGE improvement; before I had to wait for each redraw to almost complete before I could zoom again.

 

The Goto Already Exists menu has been largely expanded. You have several new options: cancel goto, continue, new goto, delete POI, edit POI, view on map. I was skeptical about this, but once I started using it, I found it to be very well implemented.

 

There is one HUGE fix in my opinion: if you cursor over a POI and select Goto, it USED to set the goto at the exact cursor location, even if you selected Goto the POI instead of the Goto Cursor option. (On several hunts that led me to look a couple hundred feet away from the actual waypoint, until I knew about that bug.) That has been corrected - it now goes correctly to the POI if you select that option. YAY YAY YAY!

 

The screen blank-then-update while cursor scrolling still happens - but it's MUCH faster. Another huge improvement.

 

The screen no longer goes (and stays) full bright on the "approaching waypoint" alarm. A great change if you cache or navigate after dark and like the dim screen setting - or you prefer the dim screen to save battery. On one occasion on Sunday it did seem to reboot itself at some point when I wasn't looking - it lost my Goto and went full bright again.

 

I'm not sure if it's new or not; maybe I just never saw it before. There are new icons for letterbox caches (blue envelope) and for virtuals (the little ghost icon). Kind of ironic - now that virts are disappearing from GC.com...

 

Cursor scrolling seems to have picked up a multi-speed feature - I don't recall it before - where if you keep scrolling it steps up the scrolling speed several times. Not certain if it's a change, but I like it.

 

The Select Item dialog (when you cursor over an item and hit OK) seems improved. If there are a lot of clustered items, you now get a scrollable list of possibilities, rather than whatever item it stupidly assumes you wanted out of the jumble(like some road or body of water). Much nicer. No more zooming in just so you could get that one item in question. Too bad they didn't apply that to the Goto dialog as well.

 

The Track Log feature was and still is GLACIALLY slow. With the original version, it could take five or more minutes to get past the "retrieving file" menu. That does NOT seem to be improved. Drat. So far that's the only real gripe I have.

 

I'm VERY happy to report one HUGE bug fix. I use my 600 with a laptop hookup (USB for NMEA data transfer) and mapping software (USAPhotoMaps). Previously, whenever I disconnected the 600 to head out into the woods, it would never reconnect properly: I had to power-cycle the 600 before it would talk to the PC again. Well, they fixed that. It now properly reconnects with no glitches. Hooray!

 

The text entry on-screen keyboard has been slightly rearranged - I think one fewer letters per line. Probably good - a bit less left-right scrolling required. I'm a pattern-sensitive person - I remember positions of items on menus and work by memory as much as by sight, so it will take me a few weeks to get used to this change.

 

The much-mentioned "wander" in coords / zero points is still there. The unit seemed quite stable in its position for minutes at a time - then suddenly re-zeroed in a new location 30 feet away. Not sure that's a 600 fault - could easily be the GPS signal.

Link to comment

My requests for the next update…

 

Get rid of that AWFUL five-minute long wait for going into the track log menu.

 

How about varying size markers for varying size traditionals?

 

Let the cursor wrap up AND down on the text entry keyboard. Currently you can wrap from top to bottom, but not vice versa.

 

Save the screen brightness setting between power cycles.

 

Offer a screen brightness OFF option, not just bright/moderate/dim. In the middle of the day, I don't need any backlight. Why make me waste battery life on it?

 

I second (and third and fourth) the motion to increase cache listings to more than 200. How about 1000? GC exports up to 500 in pocket queries. That seems a reasonable minimum.

 

However many caches are in the loaded geocache file, if the number displayed is less than the file, contains please notify me.

 

Provide the option to filter out disabled caches.

 

How about some filtering options for cache or terrain difficulty or cache type? (I know it's possible to filter using GSAK etc. but it would be preferable to have that ability onboard the 600, so I don't have to build and upload a set of overlapping waypoint files for a single geographical area.

 

I know this is a big request, but why not directly support GPX files? Oh, and along with it, allow me to see the entire listing, not just position and cache type/size and truncated hints? GPX files are basically the geocaching standard now; why make us translate them and truncate most of the useful information? If I have a 512Mb SD card installed, let me fill it with GPX files and show them directly, please. Seems to me we're only talking about extracting data from an XML file anyway – and computers are good at that, and the eXplorist is just a purpose-built computer with a GPS chip. Can't be THAT much harder than handling the native file format, really, aside from stripping HTML data from the description. (It would be fun to be able to hack the software myself, for tricks like this…)

Link to comment

Great thread.........

Enhancement on "Found" option: Ability to edit the information. Currently if you find a cache at 2pm for example but wait until you get home to send it to "found" it shows the date and time of when you "sent" it rather than actually found it. I realize this is more of a practice and discipline thing but it would still be convenient to be able to edit the detail.

Edited by CondorTrax
Link to comment
There is one HUGE fix in my opinion: if you cursor over a POI and select Goto, it USED to set the goto at the exact cursor location, even if you selected Goto the POI instead of the Goto Cursor option. (On several hunts that led me to look a couple hundred feet away from the actual waypoint, until I knew about that bug.) That has been corrected - it now goes correctly to the POI if you select that option. YAY YAY YAY!

I cannot agree with this observation: I excplicetly tried out this behaviour: If selecting a POI/Geocache with the cursor on the map, you still get this annoying offset.

 

But I observed two another improvements today:

1, approaching alarm during street routing: The distance on which the first beeps are sounded are speed dependant. Driving on the Autobahn >100kmh the alarm was sounded 1,25km before the exit, driving on a highway it was sounded roughly 600m. I never experienced this before

 

2. multiple streets with the same name in one town: It works!! After entering the street name and entering the town's name a new selection box came up, which listed all all parts of that town with this street.

Link to comment
if you cursor over a POI and select Goto, it USED to set the goto at the exact cursor location, even if you selected Goto the POI instead of the Goto Cursor option. (On several hunts that led me to look a couple hundred feet away from the actual waypoint, until I knew about that bug.) That has been corrected - it now goes correctly to the POI if you select that option.

I cannot agree with this observation: I excplicetly tried out this behaviour: If selecting a POI/Geocache with the cursor on the map, you still get this annoying offset.

Try again... and I will try again too. I also explicitly tried this out because it's been bugging me so much. I deliberately selected a slightly offset cursor position and hit the Goto button, and the resulting Goto pointed right to the cache location. Hmmm. Maybe this is an inconsistent feature - sometimes works, sometimes doesn't? Needs more testing, apparently. I REALLY hope you're wrong. ;-) (Maybe it's a basemap versus routing thing? I don't have any routing software installed...)

 

But I observed two another improvements today:

1, approaching alarm during street routing

This also seems to be the case with the default basemap. I noticed an approach alarm about 500 feet away while driving up to the cache, but only 100 feet (my setting) while walking up.

Link to comment
Goldenhawk.  DO you have a LOT of track files on your gps.  I do, about 60.  Until I put them in individual folders, It took forever to get all the track info to desplay, sometimes 15 minutes.  Now it goes fast, with just one track file in a folder.  I think it scans all of the tracks in the folder before it will continue.

Yeah, I do, but I tried this minutes after doing a complete memory wipe with only the active track log a few minutes old. Still took well nigh forever. But I'll try again....

 

It can't hurt to keep the memory clear, and I don't need those logs for anything more than nostalgia about some vacation trips. Thanks for the tip.

 

Still, either way, they need to fix this behavior.

Link to comment
enhancement to be implemented. We must rejoice that the major and most of the minor bugs seem to be fixed and work hard to let magellan know which features or additions we as a group really want added. For me most of my issues were addressed except for the geocache issues I mentioned in this

Though I've not been able to upgrade my 600 yet and see if it annoys me less, I do understand why tempers are running so high. Several of the things addressed now were problems back in the SporTrak/Meridian era when 5.x firmware first started shipping a little over two years ago. I'm sure I've seen a couple *hundred* people complain about the backlight behaviour, Some of the annoyances mentioned in this very thread date back to the 330! So it's pretty easy for the old timers to see where the "flame out" factor comes from.

 

So as "Grumpy Visioneer", I'm compelled to explain why rejoicing may seem scarce. :-)

Link to comment

Thank you DOT-COM for collecting suggestions for enhancements.

 

My general wishes are:

 

hamburg.1: Before jogging or cycling in an unknown area I like to schedule my route. This procedure is very exhausting without using my computer, which I do not have at my holidays location. Firstly I have to mark all the points on the map, give them names and save them. Secondly I have to define my route by recalling all the saved points by its names. My suggestion is that while defining a route it should be possible to add a new way point by moving the cursor in the map and clicking the point.

 

hamburg.2: I am using direct route on my explorist. If I am in a sparsely populated area with only small streets I would like to see this small streets even when I am zooming out to small scales. Now the explorist has a fixed zooming level determining wheather the small streets are shown or not. My suggestion is that while the explorist draws the map beginning with the big streets it counts the number of plotted streets and if this number is less than a threshold value, it plots the streets of the lower level etc. The effect would be that in small scale zooming levels the small streets would be plotted in sparsely populated areas and not in densly populated areas.

 

hamburg.3: Only in the largest scale zooming level the POIs of my direct route are shown. I guess that this is a bug. I would like to see the POIs even in smaller scale zooming level. The best solution would be using the same technique as described by me in hamburg.2.

 

hamburg.4: When zooming out too far the map is switched from detail map to basic map at a zooming level which is independend of the basic map. My explorist has the North American basic map, therefor it does not make sense to me to switch to the basic map while I am in Germany. I would like the explorist to have two different zooming scales for switching to the basic map, depending wheather I am inside or outside of the main area of the basic map.

 

hamburg.5: The alarm is too silent when the explorist is in my pocket, it is loud enough when in the car. It would be nice to be able to set the loudness of the alarm.

 

hamburg.6: Not that important but very easily implemented: In the sunrise-sunset-moonrise-moonset-screen would it be nice to have also the time when the moon is at the highest level (in the northern hemisphere this is when the moon is exactly in the south). This would be a simplification for estimating the times of low and high tides at the coast, because for a given location they are simply a fixed offset of the time of the moon at the highest level.

 

hamburg.7: A little bug which should be solved: The barometric altimeter cannot display negative heights. Remeber that most parts of the Netherlands are under NN and that also caves might be deeper. However: Displaying zero as the height when under NN is definitly an error.

 

hamburg.8: While setting the height at the barometric altimeter it should be possible to transfer the height of the GPS position.

 

My wished concerning routing:

 

hamburg.9: It gets on my and my wifes nerves if the alarm is peepsing and peepsing and peepsing while waiting at a red traffic light. The alarm should be limited to 5 seconds. This would be a great enhancement for me and for megellan, since I do not have to justify this device! The setting could be implemented at the alarm settings where now only 'on' and 'off' is selectable, instead it could be e.g. 'off', '5 seconds', 'long')

 

hamburg.10: Why does such an expensive device like the explorist does not reroute automatically when leaving the route? (It is difficult to explain to my wife and my friends why this "basic" feature is missing.) If magellan is not able to implement this or does not want to implement it, it would be an advantage, if rerouting would be started by pushing the big cursor buttom once. It is less dangerous while driving.

 

hamburg.11: When having an active street route I would like to have a POI search along the route and not only by name and by distance, since the typical question on the road is "Where is the next gas station at this route" or "Where is the next restaurant at this route"?

 

hamburg.12: When calculating a route I would like to see the estimated travel time. The route is a compromise of shortest and fastest way, so I am sure that the device has an internal estimation of the travel time. Why not displaying it?

 

hamburg.13: Very often I would like to have a routing not only for cars but also for bikes, which means that I prefer the shortest way. My suggestion is to define the kind of vehicle:

a. fast vehicle (on German Autobahns there is no speed limit for cars)

b. slow vehicles (like trucks)

c. bikes (never freeways, allways shortes way)

d. pedestrians (never freeways, one way streets do not matter)

or

defining speed limits

a. for streets inside a town

b. outsite a town

c. on freeways

 

hamburg.14: I would like to have the possibility of calculating a street route with given via points. Together with hamburg.13 it would make it very easy to define a biking route: I just have to define some via points and the explorist calculates the whole tour with all the meneuver points.

 

hamburg.15: When calculated a route there is a fifth screen with all the maneuver points which could be stepped through. I would like to have the option to see them on the map, e.g. by getting offered a menu while pressing the menu buttom.

 

hamburg.16: The explorist could simulate a movement in the simulating menu. Why not simulate to be at an other coordinate? Then it would be possible to check planned routes before beeing at the start point.

Link to comment

Your items 2 and 3 can be fixed using this procedure. (you'll have to register to the yahoogroup) It involves changing some setting in your export.ini and remaking your map regions. I have all roads small and large appearing up to 2.5km zoom level, beyond that you will only see the basemap.

 

For item 4 you can can change the basemap to the european one, get it here

 

Item 5 could be hardware limited depending on the installed speaker inside the GPS but I will put it on the list.

 

items 7 and 8 I agree that the altimeter should be able to go negative and also your right you should be able to have the option of setting the altimeter via gps position.

 

item 9 I thought this was fixed with the latest firmware???

 

item 10 is already documented.

 

item12 is difficult to implement because the gps has no way of knowing the speed limits and/or speed at which you will be driving. All it sould give you is estimated time of arrival at present speed.

Edited by D0T-C0M
Link to comment
item12 is difficult to implement because the gps has no way of knowing the speed limits and/or speed at which you will be driving. All it sould give you is estimated time of arrival at present speed.

DC, I thought the road network data included speed limit. I don't have DirectRoute, so I don't know first hand. The road network data used for mapping website uses a speed limit field to calculate estimated drive time, so I think DR would have it as well. The product webpage says

Shortest time routing is based on the length of various street path choices and the posted speed limits on these street paths.

Is the speed limit data maintained with the road network when it is loaded into the eXplorist? If so, considering the GPSr has the horsepower to create a route on the receiver, it should have the processing power to use the speed limit attribute of the streets to calculate an estimated drive time in lieu of using your current speed.
Link to comment

The thing here is that the computed distance does not conform to the roads and the curving paths they take, but rather are based upon line-of-sight distances between the connecting turn waypoints. This underestimates the actual route distance, and it is divorced from the speeds associated with the actual roads.

 

I agree the feature(s) would be great (I like them mightily on my Garmin Quest), but it would involve a major re-write of the firmware...no incremental add-on.

Link to comment
The thing here is that the computed distance does not conform to the roads and the curving paths they take, but rather are based upon line-of-sight distances between the connecting turn waypoints. This underestimates the actual route distance, and it is divorced from the speeds associated with the actual roads.

Ach, forgot about that, Embra. RobertLipe (pretty sure it was him) gave a great explanation of that in the topic I started to compare Garmin to Magellan autorouting a while back.

Link to comment
Your items 2 and 3 can be fixed using this procedure. (you'll have to register to the yahoogroup) It involves changing some setting in your export.ini and remaking your map regions.  I have all roads small and large appearing up to 2.5km zoom level, beyond that you will only see the basemap.

 

For item 4 you can can change the basemap to the european one, get it here

 

Item 5 could be hardware limited depending on the installed speaker inside the GPS but I will put it on the list.

 

items 7 and 8 I agree that the altimeter should be able to go negative and also your right you should be able to have the option of setting the altimeter via gps position.

 

item 9 I thought this was fixed with the latest firmware???

 

item 10 is already documented.

 

item12 is difficult to implement because the gps has no way of knowing the speed limits and/or speed at which you will be driving. All it sould give you is estimated time of arrival at present speed.

Your items 2 and 3 can be fixed using this procedure. (you'll have to register to the yahoogroup) It involves changing some setting in your export.ini and remaking your map regions.  I have all roads small and large appearing up to 2.5km zoom level, beyond that you will only see the basemap.

Thank for this information, although it was not new to me. My idea at item 2 is slightly different, it is that there is a fixed zoom level now determining wheather the small streets are plotted or not. The idea is to make the decision up to which size streets are plotted not dependent on the zoom level but instead of the number of already plotted items.

 

E.G.: First plot the biggest roads and count them (or the length of them or what ever). If this number is below a threshold, plot the medium streets and add them to the counter. If this number is still below the threshold, plot the smallest streets. If this number is still below the threshold, plot the POIs.

 

The result would be that the number of plotted items is more or less the same, the less objects (streets,POIs) are in the area to plot is the higher degree of details.

 

For item 4 you can can change the basemap to the european one, get it here

This link does not look very legally...

If the base map carries the information that it is for example a Norh American one, it does not make sense to switch to that base map in Germany at the zoom level of 5 km, since at this zoom level the detail map provides more information than the North American base map.

 

item 9 I thought this was fixed with the latest firmware???

It is not fixed.

 

item 10 is already documented.

Please consider my addition:

 

If magellan is not able to implement this or does not want to implement it, it would be an advantage, if rerouting would be started by pushing the big cursor buttom once. It is less dangerous while driving.

But: Let's hope for the maximum, which is automatically rerouting.

 

item12 is difficult to implement because the gps has no way of knowing the speed limits and/or speed at which you will be driving. All it sould give you is estimated time of arrival at present speed.

There must be an idea of the typical speed, even if it is a constant value for major, medium and minor roads, otherwise the routing engine has no chance to decide wheather a longer way using major roads or an abreviation using minor roads is better. Why not put this item one the list? If it is not possible, we wont get it, so what?

 

Independent of the question if item 12 is possible or not, my item hamburg.13 should be possible adressing the bikes and the pedestrians.

 

You did not mentioned your thoughts to items 1, 6, 11, 13, 14, 15, 16. I would be happy to read an other opion wheather I am the only one wishing to have that features or not.

 

And again: Thanks a lot for your work, DOT-COM!

Link to comment

As far as item 2 and 3 goes. I understand what you want to do but it would involve much work and alot of coding I would imagine. If you look at the map details options of highest, high, medium,low, lowest , Modifying the export.ini in the mapsend program, I have set it so that highest shows everything at a zoom of 2.5km, high shows everything at a zoom of 1.4km, medium is better for midsized cities, low is good for bigger cities, and low is set for large urban cities. This works for me as I mostly use my GPS in the country and in the woods. Might not be want you want but in any case what you suggest is probably not a firmware issue but rather a software enhancement to the DR mapsend program.

Edited by D0T-C0M
Link to comment
if you cursor over a POI and select Goto, it USED to set the goto at the exact cursor location, even if you selected Goto the POI instead of the Goto Cursor option. (On several hunts that led me to look a couple hundred feet away from the actual waypoint, until I knew about that bug.) That has been corrected - it now goes correctly to the POI if you select that option.

I cannot agree with this observation: I excplicetly tried out this behaviour: If selecting a POI/Geocache with the cursor on the map, you still get this annoying offset.

Try again... and I will try again too.

Tried it again today, a couple times, and I am CERTAIN this has been fixed. There's an easy way to test it.

 

Zoom way out, say to 2 or 3 mile scale. Move the cursor near a geocache waypoint, but obviously NOT directly onto the cache. Get it just close enough that the name of the cache is shown in the status bar. (At this scale, the cursor will be at least 500 feet from the cache coords.) Then hit Goto, and the 600 will ask "Do you want to go to (cache name)?" Select yes, and you'll see the active waypoint symbol (yellow square with darker crosshairs) appear directly over the cache, not at the cursor position. Zoom all the way in to 100 ft resolution, and the active waypoint symbol will still be directly over the cache. I think this is simple proof that they've fixed it.

Link to comment
if you cursor over a POI and select Goto, it USED to set the goto at the exact cursor location, even if you selected Goto the POI instead of the Goto Cursor option. (On several hunts that led me to look a couple hundred feet away from the actual waypoint, until I knew about that bug.) That has been corrected - it now goes correctly to the POI if you select that option.

I cannot agree with this observation: I excplicetly tried out this behaviour: If selecting a POI/Geocache with the cursor on the map, you still get this annoying offset.

Try again... and I will try again too.

Tried it again today, a couple times, and I am CERTAIN this has been fixed. There's an easy way to test it.

 

Zoom way out, say to 2 or 3 mile scale. Move the cursor near a geocache waypoint, but obviously NOT directly onto the cache. Get it just close enough that the name of the cache is shown in the status bar. (At this scale, the cursor will be at least 500 feet from the cache coords.) Then hit Goto, and the 600 will ask "Do you want to go to (cache name)?" Select yes, and you'll see the active waypoint symbol (yellow square with darker crosshairs) appear directly over the cache, not at the cursor position. Zoom all the way in to 100 ft resolution, and the active waypoint symbol will still be directly over the cache. I think this is simple proof that they've fixed it.

You are right! Doing it just theoretical on the map, the selection is now on the spot!

 

But strange, strange!

 

I did nearly the same thing : zoomed out, selected Geocache-point on the map, slightly off the center, tried to find it and had an offset of about 10m at the cache's location. It was significantly differently from the correct position, when selected the point by the menu.

 

Using a 600, 2.03 FW, Mapsend DirectRoute Europe 2.0.

Edited by DocW
Link to comment

Here's an oldie but goodie.

 

Time displayed on GPS inaccurate.

 

Loaded the new firmware on my x600 the day it came out. Checked time after cold start against GMT and was within 1 second. After less than one week my clock had drifted by 1 minute and 35 seconds. Just did a clear all memory and reset x600 and now time is back to within 1 second. This is problem that has existed in the Magellan Meridian series for many years.

Link to comment

I don't know if this is a bug with the new firmware in my Explorist 500 as I can't recall checking it with the old firmware but I ran into a cache today that required UTM coordinates and when I went to enter them I noticed that the Easting was missing the letter - so instead of 17 T xxxxxxx I was seeing 17 XXXXXXXXX.

 

I recall (although I may be wrong) that my old Meridian Gold had the letter.

 

It does seem pretty basic to be able to display the coordinates correctly or am I missing something

Link to comment
Here's an oldie but goodie.

 

Time displayed on GPS inaccurate.

 

Loaded the new firmware on my x600 the day it came out.  Checked time after cold start against GMT and was within 1 second.  After less than one week my clock had drifted by 1 minute and 35 seconds.  Just did a clear all memory and reset x600 and now time is back to within 1 second.  This is problem that has existed in the Magellan Meridian series for many years.

Just checked my 500, its deadon :D

and its been about a week since I loaded the new firmware

 

Hard Oiler just checked and my east and north are both there

Edited by vagabond
Link to comment
I don't know if this is a bug with the new firmware in my Explorist 500 as I can't recall checking it with the old firmware but I ran into a cache today that required UTM coordinates and when I went to enter them I noticed that the Easting was missing the letter - so instead of 17 T xxxxxxx I was seeing 17 XXXXXXXXX.

I don't deal with UTM often enough to know what I'm talking about...but when I mark a POI with UTM my easting letter is at the end of the string:

 

18 298545E

4404975N

Link to comment
My clock on ex500 is 15 seconds slow compared to the time broadcast on 5MHz just now. Installed firmware week ago. This seems about right compared to other GPSrs (10 seconds closer than my Meridian.)

If the stupid search function worked, Escout, I'd have pointed you to two other recent threads that showed that the Explorists inherited the defect that's been present since the 330 that makes them tell time about like a McToy watch...

 

In short, until you do a 'clear all memory', you're hosed.

Link to comment
I don't know if this is a bug with the new firmware in my Explorist 500 as I can't recall checking it with the old firmware but I ran into a cache today that required UTM coordinates and when I went to enter them I noticed that the Easting was missing the letter - so instead of 17 T xxxxxxx I was seeing 17 XXXXXXXXX.

I don't deal with UTM often enough to know what I'm talking about...but when I mark a POI with UTM my easting letter is at the end of the string:

 

18 298545E

4404975N

I get the E and N OK but the UTM Grid Zone should have a letter in it I believe - so it should be something like 18T not just 18. The letter should change every 8 degrees of latitude so if it's not there then the coordinates are ambiguous.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...