e-Map Memory cart problems
Olaf Knode
Modules?
1 MB = 1024 kByte correct??
so 32MB = 32768 perfect conclusion.
Now if you pic up maps from a selected area (RR-Germany and
MG-Germany ---both full paid---) and get a size of
32224 with 137 maps everything is ok
32720 with 147 maps everything is ok
32752 with 135 maps you are able to upload it to the unit without any
warning, only after one hour the unit says uploading was incomplete :-(((
, but when you use the unit to view the uploaded files, you are able to use
the maps, if complete i can not say, but the list of uploaded files "Source
data" is complete emty but selectable (the function with which you can
switch a map on or off.
So there is obviosly a limitation in size 16 k difference
If you do the same tric with an 8MB unit = 8192 you ar able to use maps up
to 8180 Diff =12 without any problems.
So i belive you are not allowed to sell a unit with ??promised?? 32MB =
32768
and afterwards say >>> GARMIN Germany <<< sorry but it's impossible to use
everything of this module, use the try and error method to find the
limitation.
greetings Olaf
Harry Broomhall
<kn...@med.uni-duesseldorf.de> wrote:
>Hello out there, did anyone recognice the following limitations of the 32 MB
>Modules?
>
>1 MB = 1024 kByte correct??
>so 32MB = 32768 perfect conclusion.
>
>Now if you pic up maps from a selected area (RR-Germany and
>MG-Germany ---both full paid---) and get a size of
>
>32224 with 137 maps everything is ok
>32720 with 147 maps everything is ok
>32752 with 135 maps you are able to upload it to the unit without any
>warning, only after one hour the unit says uploading was incomplete :-(((
>
Don't forget that these memory cards aren't 'perfect', rather like
hard disks. There are a few error cells which are 'mapped out', just
as with hard disks. This means that you won't get the theoretical
amount of data into one, and the difference will depend on the
individual card.
I have to agree that Mapsource is not well informed about the
actual memory available in a given card. I have had some odd results
occasionaly, but when I get an error of 'incomplete' I believe it!
I would also suggest that you get the USB programmer - waiting for
and hour for an error message is not my idea of fun!
Regards,
Harry.
Olaf Knode
GArmin products is that you hav plenty of time drinking tea ore anything
else while waiting for results. IMHO no more bucks for insufficient tools.
Getting an error message faster really doesn't make it better :-)
"Harry Broomhall" <harry.b...@uk.easynet.net> schrieb im Newsbeitrag
news:bf9i8tcdmdr3le94r...@4ax.com...
Gilles Kohl
On Tue, 13 Feb 2001 12:22:05 +0000, Harry Broomhall
<harry.b...@uk.easynet.net> wrote:
> Don't forget that these memory cards aren't 'perfect', rather like
>hard disks. There are a few error cells which are 'mapped out', just
>as with hard disks. This means that you won't get the theoretical
>amount of data into one, and the difference will depend on the
>individual card.
OTOH, as with harddisks, the cards often have a "reserve" they can
draw upon in case there are bad blocks. I don't think this reserve is
or should be included in the indicated capacity.
Regards,
Gilles.
Joe Mehaffey
upload are ESTIMATES. At times, MapSource Loader may report map sizes
slightly larger or slightly smaller than actual map file size. When the
maps are loaded, it is possible that a map group reported as "will fit"
will actually "not quite fit". This is likely due to small variations
caused by a) large files will load just a few "loader gaps" while b)
many files will have many more "loader gaps". It appears that in any
case, the unusable space at the end of the 32meg memory is typically
measured at less than a few thousand bytes out of more than 32 million
bytes. Are we not worrying about trifles here?
The options were:
1) Provide each map size with a guaranteed guard band so the maps
selected would ALWAYS fit but this process would always waste maybe a
meg of memory.
2) Provide a "best estimate" of map size and on rare occasion (and if
you creeped up on 32768 to see if you could load the last byte you
thought you bought.) the actual map size would exceed 32768 bytes while
the estimate was several hundred bytes short.
Personally, I like option #2 because routinely you get to use a bit
more of the than you would with option 1. We have to remember, maps
come in random sizes and a "perfect fit" of randomly selected map
sections at the top end of memory is an unfulfilled dream.
Joe Mehaffey
--
Got a Question about GPS technology? Looking for a GPS FAQ site?
See: http://joe.mehaffey.com
Roger Stewart
proper flash memory systems, software manages the flash memory:
1) detecting and marking as "Bad" all non functioning blocks (resulting in a
reduction of the available space)
2) making block usage as uniform as possible, since flash has intrinsic
limitations as to the number of rewrite cycles it can take.
Therefore the actual capacity could vary from cartridge to cartridge over
time, I guess, requiring the sytem to be a bit "fuzzy" in it's promises...
"May fit"... "May not fit"...
Roger Stewart
www.mobit.com
Joe Mehaffey <j...@mehaffey.com> wrote in message
3A89FE25...@mehaffey.com...
Tamas Kerecsen
The data Mapsource calculates is a rough estimate that ignores the
gaps caused by the block structure of the IMG files. If you
don't want to wait an hour, either always reserve a spare megabyte or
so (easy -- but not nerdy -- solution) or when Mapsource says that it's
done building the mapset and starts uploading it, go to your
$TEMP\Mapsource directory, and check the size of the image
file (map*.tmp).
Tamas
> Hello out there, did anyone recognice the following limitations of the 32 MB
> Modules?
Olaf Knode
"Tamas Kerecsen" <kere...@bigfoot.com> schrieb im Newsbeitrag
news:3A8E9387...@bigfoot.com...