Increasing SC Card size

 

G'Day Mates, I have a pair of 3597LMT's that currently have 8GB SD cards installed. On both units, the current SD Cards contain map data. I want to increase the SD Card size as a hedge against the ever increasing new map sizes. I am a bit leery of just inserting a new card and downloading new maps. Has anyone successfully upsized their SD Cards when their old ones contained map data? Would appreciate any guidance and thanks in advance for verified procedures. Regards/Og

--
The Ogre

3597 SD card

I have 32 GB micro SD cards in my 3597LMTHD's. They work just fine. Just make sure they are formatted as FAT32. If you want to transfer your current maps and data to the larger card, just copy the contents of the old card over to the new card. Then do a complete power shutdown of the 3597 (not just a sleep mode shutdown), swap the cards and boot it back up.

--
Alan - Android Auto, DriveLuxe 51LMT-S, DriveLuxe 50LMTHD, Nuvi 3597LMTHD, Oregon 550T, Nuvi 855, Nuvi 755T, Lowrance Endura Sierra, Bosch Nyon

Success

Thanks again. 32GB SD Cards successfully installed. Og

--
The Ogre

When you format the card

Give it the largest block size you can.

When you load the maps from the card, you'll not wait so long while it loads (transfers) the data from the card to the internal memory.

I consistently saw 8 - 10 second performance benefits using a slow card.

BOL and YMMV

--
Never argue with a pig. It makes you look foolish and it anoys the hell out of the pig!

Good to Know

BarneyBadass wrote:

Give it the largest block size you can.

When you load the maps from the card, you'll not wait so long while it loads (transfers) the data from the card to the internal memory.

I consistently saw 8 - 10 second performance benefits using a slow card.

BOL and YMMV

I always accept the default block size. That info is good to know.

Just to make sure

So it works like this.

If you format the card with little sectors ( blocks ) the disk is better utilized space wise, but it takes more read requests to get all the data.

On the other hand, large block sizes benefit large files sp it takes fewer read requests to get the same data into memory.

So think about it like this.

You need to fill your gas tank. You get your choice. You can either use a thimbul or a 5 gallon gas can. But which ever you choose, you must only use that volume.

Of course realize, once you start pouring the gas into the tank, the transport vessel ( thimbul / 5 gallon can ) will be full and you must pour until the gas is completely empty in the can.

So while you'll loose less using the thimbul, you'll spend your entire life filling the tank. On the other hand, using a 5 gallon can, once the cars tank is full, the remainder of the gas in the can winds up on the floor.

Hope that helps

--
Never argue with a pig. It makes you look foolish and it anoys the hell out of the pig!

Sector size or Allocation Unit Size

BarneyBadass wrote:

So it works like this.

If you format the card with little sectors ( blocks ) the disk is better utilized space wise, but it takes more read requests to get all the data.

On the other hand, large block sizes benefit large files sp it takes fewer read requests to get the same data into memory.

So think about it like this.

You need to fill your gas tank. You get your choice. You can either use a thimbul or a 5 gallon gas can. But which ever you choose, you must only use that volume.

Of course realize, once you start pouring the gas into the tank, the transport vessel ( thimbul / 5 gallon can ) will be full and you must pour until the gas is completely empty in the can.

So while you'll loose less using the thimbul, you'll spend your entire life filling the tank. On the other hand, using a 5 gallon can, once the cars tank is full, the remainder of the gas in the can winds up on the floor.

Hope that helps

Are you talking about increasing the sector size from the default 512 bytes/sector or increasing the cluster size (allocation unit size)? The Fat32 formatting programs that I'm familiar with only allow you to change the allocation unit size.
Mark

CLusters

as with all the prior answers, the maps are large and read large sections to memory
it is significantly better to read 1 large cluster than 128 small ones, to read 64K

I get similar readwrite advantage oncamera cards, the pics are 6mb and cluster sizes are 1mb

--
the title of my autiobiography "Mistakes have been made"

Much of what has been said is true, but....

Although much of what has been said is true, a test I did seems to indicate that at least with a relatively new (chronologically) card it doesn't matter much.

I took a Sandisk 16 GB Ultra Plus microSD card which has an 80MB/sec. sequential read and write speed. I use this card regularly in my nuvi 2689, actually I have two and keep current maps on both. With current maps, the 2689 has one file of appreciable size on the card, that being gmapprom.img at 3.8GB. I backed up the content of the card and then formatted one to the default cluster size of 4096 bytes, then recopied the contents back to the card. I also did the same thing forcing a cluster size of 64K, the maximum my Win 10 offered. In checking the boot times of the 2689 with both cards, there was perhaps a one second difference. I'm therefor forced to conclude that with a reasonably new card that has decent read/write speeds, there is little if any difference.

I do notice that the OP was using 8 GB cards so they may be quite old. For at least a few years it actually has been difficult to find 8 GB cards at reputable sources; eBay being not reputable; Amazon not reputable but to a lesser extent. Today a place like Best Buy or some of the New York photo stores (B&H or Adorama) only carry 16GB and larger. A 32GB Sandisk Ultra Plus microSD is currently $14 at Best Buy.

--
John from PA