This is an archive of past discussions about SD card. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Can someone expand the paragraph on speed in this article? I recently bought a camera that uses SD and SDHC cards, and in my attempt to find out which cards are fastest, I've found a confusing jumble of information. The new SDHC format has Type 2, 4, and 6, corresponding to speeds of 2, 4, and 6MB/sec, but that's clearly not the whole story, because SD and SDHC cards are being advertised as 60X, 120X, 150X (this is the only part defined in the article), and there are considerable differences between read and write speeds that aren't always obvious to shoppers. With manufacturers claiming 23MB/sec, and the newest spec calling for 6MB/sec, there's definitely some important information missing in that gap. I'd start the section myself, but it's clear that I don't have all that much of a clear idea on the SD/SDHC speed situation. -Erik Harris20:01, 14 October 2006 (UTC)
Why does the page (Dec 1 '08) say "SD cards typically have transfer rates in the range of 10-20 MBytes/s, but this is always changing, particularly in light of recent improvements to the MMC standard.[4]". Strange, most SD cards claim to be nowhere clsoe to that fast! 67.242.12.28 (talk) 20:39, 1 December 2008 (UTC)
X Speed Ratings
Basic cards transfer data up to 6 times as fast (900 KiB/s) as the standard CD-ROM speed
Six times as fast, does it mean six times faster? Or that it is six times faster than the slowest SD speed, to bring up to the same speed as cdrom? I don't get it JayKeaton07:05, 21 October 2006 (UTC)
It means that the speed is the same as a 6X CD reader/writer would be. Single-speed CD-ROM is 150KB/s (this is how fast the disc is read when your audio CD player is playing music on a standard CD). The "X ratings" for SD cards follow the same convention, even though it makes little technical sense (6X actually means something with respect to a CD, but as far as I know, the "baseline speed" for a SD card isn't 150KB/sec - i.e. the first SD cards weren't 1X).
In other words, it means six times as fast, just as it says ("six times faster" would be different in that it could be interpreted to mean "seven times as fast"?). 900/150 = 6. From what I've learned in the last week or so, this speed rating refers exclusively to the read speed, and the write speed is generally quite a bit closer. I'm not clear on whether or not there's a fixed relationship between the read and write speeds, or if, for example, some "150X" cards write at "80X" while others only write at "60X." -Erik Harris12:16, 23 October 2006 (UTC)
Standards or marketing buzzwords within SD cards (what does 'Ultra' mean?)
While looking for a digital camera I stumpled upon some terms that are not explained in this article:
SD Ultra
SD Ultra II, or SD Ultra, Model II, Model II plus
SD, eXtreme II
A retailer talked about 80 speed (before Ultra "he thought") and 150 speed (with ultra "he thought"). Also he was not able to tell me what measurement unit the 80 and 150 is in.
Those are all names of different SanDisk cards. as is explained in the second paragraph of the article, the speeds are multiples of 150 kB/s. That would make the 80x card 12 MB/s and the other card 23 MB/s. --Niffux13:13, 21 June 2006 (UTC)
Actually, doing a find doesn't show any 'ultra' in the whole article, and the second paragraph doesn't help clear it up, if you're trying to figure out what speed 'ultra' is. Some of the stuff I'm looking at in advertising gives no multiple speeds, much less ultra or anything else and just says "fast" ... which is marketing lingo for "give us your money, now!" and not a technical reference at all. However, one site did say that any card which doesn't say 'high-speed' or 'ultra' were no more than 2MB/s [1] - which helps only in the negative information sense.
I'm going to order the one card which does give me a multiple speed (2G, x133 ~$35), even though my current camera probably doesn't support such high transfer speeds :\
~ender 2006-11-17 4:02:AM MST
'Ultra II' is a model name or brand for a line of Sandisk cards; it isn't an indication of speed. They also have other models. These are outside of the scope of this document, except perhaps to mention that some brands have a range of different models with different speeds. The appropriate place to look up the speed of a 'Sandisk Ultra II' would be to go to Sandisk, I think. Note that 'speed' is not a single characteristic; read speed and write speed can vary relative to each other, as can the speed of writing to very small blocks and the speed of writing to larger blocks. 136.186.1.186 (talk) 03:48, 1 July 2008 (UTC)
Ultra-II SD card with same reader?
I see an ad for a Scandisk Ultra-II 2GB SD card with "a minimum sustained write speed of 9 megabytes (MB) per second and a read speed of 10MB per second." Will these work with all SD reader devices, or do the devices have to be ready for the higher transmission speeds? Thanks, AxelBoldt 03:34, 14 Feb 2005 (UTC)
All devices will support these cards. That speed is an estimate of the maximum speed the card will go. A device will wait while the card does its thing; a faster card will cause less wait at the device. Some devices don't particularly need a very fast card so you are unlikely to notice a difference in the higher speeds, but the cards will still work. 136.186.1.185 (talk) 03:58, 1 July 2008 (UTC)
Minimum sizes
Anyone know the minimum size of a SD Card? I'm guessing 4mb but I could be wrong
Towel401
What do you mean? The minimum size available for retail sale? The minimum size in current production runs? The smallest card ever made? Only one of those is not subject to change without notice within a matter of months. --Smack (talk) 03:31, 15 July 2005 (UTC)
I think he would rather mean the smallest possible size, if there is one. --70.104.80.228 uiktlerSubscript text
Smallest I've seen is 16mb, maybe 8 even (can't remember entirely, but I *think* I've found and marvelled at it's uselessness). And these were near-worthless demonstration pack-ins with cameras and a camcorder that could save snapshots to card. What in the world would you do with a 4mb one? An 8mb can save maybe as many moderate-compression VGA-rez photos as you'd get on a single roll of 35mm film... I remember having 2mb and 8mb Smartmedia several years before SD was introduced, and they were already pretty restrictive 193.63.174.10 (talk) 14:28, 15 March 2010 (UTC)
Well, reading the article, the *theoretical* minimum size would be 2048 bytes - 2KB :-) The smallest SD card I have ever seen is 8MB, but I have seen a 4MB CompactFlash card. 86.149.199.220 (talk) 19:59, 17 May 2010 (UTC)
Made a few changes:
Rephrased in a few places.
Provided reference for SD overtaking CF as most popular format.
Removed the claim that SD card is an 'official replacement' for CF as it is not. CF has a lot of uses that SD simply does not do currently although some of this is changing with SDIO. CF is also very much the standard on high-end digital cameras and there is no sign that I can see of a shift to SD here.
Moved the point about possible floppy replacement to memory card as this is not specific to SD.
Among other things (such as SD having a 4-bit bus and CF a 16-bit bus), SD is not ATA disk compatible, which is the primary reason CF still has a long way to go in its lifetime. Thanks to the ATA compatibility, CF cards can be connected electrically to an embedded or small computer's I/O bus with no extra controller hardware, making CF still rather popular as a spindled-disk replacement. --Todd Vierling 29 June 2005 15:12 (UTC)
The site referred to by the second external link, http://www.handhelds.org/projects/h3800.html, appears to be down. This may be temporary, but does anyone know if that page is still valid? --LostLeviathan 06:08, 4 Dec 2004 (UTC)
Gives 404 today. --Nikerabbit 08:37, 8 Dec 2004 (UTC)
The Technical Explanation section states "Royalties for SD/SDIO licenses are imposed for manufacture and sale of memory cards and host adapters ($1000 per year plus membership at $1500/year) but SDIO cards can be made without royalties and MMC host adapters do not require a royalty." Is it correct that a license and royalty is not required if a host adaptor is implemented in firmware using the lower performance MMC/SPI mode to communicate with an SDIO card, even though a SDCard Association membership is required to obtain the required documentation? If true, is it possible then to sell a product containing an SDIO-only card (not combo) and host adaptor without the need to pay any liscense fee or royalty to the SDCard Association? --216.54.240.19018:02, 13 July 2005 (UTC)
Also, what does this sentence mean: "Overall, SD is less open than CompactFlash or USB flash memory drives, which can be implemented free of charge, but require licensing fees for the associated logos and trademarks." I have no idea whether it's telling me that SD cards do or do not require licensing fees, logos and/or trademarks. It should be broken out into self-contained unambiguous sentences.
Under the guise of "examples", currently there are a couple of links to 3rd party vendors of a product or two right now in the main article page. I suggest these be removed. --SaulPerdomo19:52, 18 September 2005 (UTC)
Description and market Penetration section stated that current dSLRs were using CF exclusively (the Nikon's D50 being the only exception). I've added the three Pentax models, which use SD as well (even before D50). I've also just recalled that Canon's flagship models EOS 1D Mark II/IIN and EOS 1Ds Mark II can use SD as storage media as well (in addition to CF).
So, I'm thinking: could we expect deeper SD penetration in this market any soon? If so, it could be proper to change the text in the second paragraph to "Additionally, SD has not yet conquered the Digital SLR market" and/or "where CompactFlash still remains the most popular format" (and then appropriately change the text in parentheses too). I'm not quite sure myself, so I'm not really suggesting it (yet). I'd rather be happy to hear what other people think. --Bilbo18:25, 11 January 2006 (UTC)
I think that SDHC will slowly overtake CF in dSLR cameras. Many now offer dual support, and the availability of adapters to use SD/SDHC cards in a CF-equipped camera are commonplace. I have used one for quite awhile and my last few card purchases have been SDHC. The advantages of SD/SDHC over CF are numerous, from the smaller size to the higher durability, and in many cases all else being equivalent, SDHC are often cheaper. For me, the use of SDHC is one of added flexibility as I can use them in my dSLR, my wife's smaller camera and directly into our TV for slide shows. I think the 'most popular format' statement is likely outdated now (May 2010) but have no data to back it up.
-Both CF and SD however, seem to be able to withstand numerous laundry wash/dry cycles....;) Ken (talk) 20:28, 18 May 2010 (UTC)
Size restrictions of cameras?
I've seen many digital cameras that say they support SD cards "up to 512MB". Does anyone know more about this? —The preceding unsigned comment was added by 131.191.67.168 (talk • contribs) .
I don't know why, but allow me to speculate: Perhaps they don't want to deal with managing more memory than that, as it takes a certain amount of chutzpah for the software to adapt to increasingly large cluster sizes or number of blocks. A 512 Mb is a million 512 byte sectors, so 16 sector clusters (8 k) is the minimum cluster size for a managing FAT16 structure, which is slightly easier to implement than FAT32. Or maybe it a power requirements or bit addressing size thing? Or maybe they will work just fine, but the manufacturer doesn't want to be on the hook if the larger SD cards don't work. —EncMstr01:39, 13 July 2006 (UTC)
Does anyone have some somewhat-rigorous information on the difference between SD and SDHC? I was under the impression that SDHC simply standardized the acceptance of the FAT32 file system in SD cards, and that there weren't any other really substantive differences between the two formats. That would be enough to explain the compatibility differences, because a device designed to support only FAT16 would not read a FAT32-formatted card. However, most of the 4GB cards on the market today are not SDHC cards, and do not truly conform to the (FAT16-based) SD 1.1 standard, either. As such, they do not work in many devices designed to support SDHC cards. This tells me that there's a more significant difference between SD and SDHC. I'd like to know what those differences are, but I've come up empty in my search for info. -Erik Harris12:16, 23 October 2006 (UTC)
SD uses byte based addressing, whilst SDHC uses sector based (512 byte chunks) addressing. A non-SDHC card is a byte based card with FAT32. Since the address field is 32-bits, you can get 4 GB on the old cards. But the standard also specified FAT16, hence the limit on 2 GB. PierreOssman07:01, 7 June 2007 (UTC)
Is incompatibility between SD and SDHC a hardware or a firmware issue? The filesystem is a firmware issue, but what about the block vs byte addressing? Could that be worked around by a firmware upgrade or does it require a SD card reader specifically designed to handled it? To get a little less theoretic: The Wii currently only supports SD, but not SDHC, is it fixable without new hardware? -- Grumbel09:11, 8 November 2007 (UTC)
Not necessarily. I believe SD 2.0 has tighter electrical specifications than SD 1.x (such as lower voltage tolerances and higher current tolerances) so a SD 1.x device may, but would not necessarily, qualify as an SD 2.0 device. It would need to be meet the electrical specs of SD 2.0 before it could be able to offically support SDHC and carry the SDHC logo. It is possible that some SD 1.x devices will already meet this spec just because they were designed well from the start, but they would need to be tested to ensure they meet the SD 2.0 electrical spec and also have a firmware upgrade. 136.186.1.185 (talk) 04:08, 1 July 2008 (UTC)
Almost every Windows Mobile 5 and above device can support SDHC through installation of the fan-made driver (SDHC driver made by GreateVK and FreePK). 78.37.228.242 (talk) 16:28, 5 July 2010 (UTC)
SuperSD
Some manufactures, such as Pretec are introducing a new kind of cards called SuperSD. These cards are compatible with both SD 1.1 and MMC 4.0, however they have their own standard from the μ Alliance. There are also smaller version of SuperSD cards. I think that these cards should be mentioned here.
The SD card can also be locked to a specific device. I do not know if this is simply a part of the DRM properties, or it's a security feature being available for the end-user. If I lock the miniSD card on my phone, I cannot access it elsewhere, and the card is not readable under Windows nor mountable under Linux. Unlocking the card makes it accessible again. Some more explanation of this would be greatly apreciated. —The preceding unsigned comment was added by 195.249.172.62 (talk) 2006-11-23T01:19:54
As details of SD security are not in public domain, one can only speculate that locking is similar to ATA Security Feature Set (commands SECURITY_SET_PASSWORD, SECURITY_UNLOCK, ...). In that case, if a password has been set, after each power-up the hard disk requires a correct password to be sent before it starts accepting commands that access data; the BIOS handles that transparently to the user until the drive is moved to another computer. --saimhe23:42, 12 April 2007 (UTC)
The locking is actually specified in the simplified specification. But yes, the behaviour is almost identical to how ATA does it. PierreOssman07:01, 7 June 2007 (UTC)
The CSD register has PERM_WRITE_PROTECT and TEMP_WRITE_PROTECT bits. The PERM bit is supposedly unable to be reset to 0 once it has been set to 1. The TEMP bit can be changed. There's also a COPY bit which on most cards is set to 1 and like the PERM write protect bit cannot be changed to 0, or so the SDHC licensors claim. The COPY bit is so end users cannot copy data from an OEM card (with the COPY bit set to 0) to an off the rack writeable card and use it in a device that looks for a value of 0 in the COPY bit. Any publicly available documentation from manufacturers of these cards will toe the line on saying these bits cannot be changed. I've seen claims that it's actually fairly simple to change those bits, but nobody's giving any specifics. To permanently set those bits beyond any possibility of changing would require a physical alteration, much like the old PROM chips programmed by blowing micro-fuses. Some Googling will find a cheap device, around $16 USD, that claims to be able to unprotect SD and SDHC cards, but erases all the data too, similar to how the secure erase feature in most current EIDE and SATA hard drives allows password removal at the expense of wiping the data. —Preceding unsigned comment added by 174.27.35.161 (talk) 05:10, 4 February 2010 (UTC)
Optional write protect tab
I have removed the following uncited text from the article, pending a citation, and simplified paragraph:
There is, however, a less well-known fact: the tab is implemented only as mechanical part (detected by a contact switch inside the SD Card socket) so that the device can write to the write protected SD card if its firmware decides to ignore the tab or if the switch is broken. Many users reported data loss when the switch was worn down or broken especially on early sockets where manufacturing process was not perfected or due to firmware bugs. Some devices also allow users to ignore write protect switch for user's comfort. Kingmax makes its SD cards without a write-protect tab because the company claims that the tabs are too fragile [2].
(this would be best added into the table)
What is the max supported size of SD ? The article says "Capacity limit in all SD/MMC formats appears to be 128 GB ..." But then later "A new SD format, SDHC, allows capacities in excess of 2GB".
So is SD limited to 2GB, 128 GB or something else ?
Good question. :) There are "SD" cards in excess of 2GB (I've only seen 4GB SD), but the SD (non-HC) standard doesn't officially support them, and many devices will choke on these 4GB SD cards. Furthermore, many SDHC devices will also choke on these 4GB SD cards, though they'll work on 4GB and 8GB SDHC cards. I believe the current official limit is 8GB, though I'm not positive. I'm pretty sure that the current version of the spec does not support 128GB cards. That appears to be a figure based on the memory addressing methods, which I guess would allow addressing up to 128GB of space. That doesn't mean the standard supports those sizes yet. I agree, clarification is necessary. Unfortunately, I don't have quite a clear enough understanding to make the changes myself. —Erik Harris16:28, 19 January 2007 (UTC)
The whole GB/GiB thing always confuses.
Is the "1GB" cards really 1GB? Is the 512MB cards really 512MiB or 512MB?
If the 512MB cards really is 512MB, then isn't the 1GB cards 1,024GB?
It's kinda confusing. I highly doubt that the 1GB cards really is 1GB cards.
I do NOT think that wikipedia should "lie" about the size just because the cards says something else. —Preceding unsigned comment added by Ran4 (talk • contribs)
This isn't a lie as much as it's a disagreement on standards. The SI standard specifies that "giga" means one billion, "mega" means one million, and so forth. For years, computer users have used binary approximations of these prefixes, based on "kilo" being 2^10, or 1024, and "close enough" to "kilo" to be usable. In recent years, there's been an effort to switch to a differentiating standard, using the rather ridiculous-sounding (IMO) "kibi," "mebi," etc. Some have insisted that because of this effort that "KiB," "MiB," etc are the "correct" way of doing it. However, this new standard is not officially ratified/recognized/used. The end result is that there's no "right" way. The official SI way says 1GB = 1 billion bytes. The de-facto binary way says 1GB = 2^30 bytes. Manufacturers obviously prefer the SI way because it makes their devices look larger than the binary notation, but their way is also "correct." Neither is a lie. Generally, the 512MB cards "really" have 512MB, but MB is still defined in the SI way, so they contain 512,000,000 bytes (approximately, with allowances for overhead), not 536,870,812 (512*2^20) bytes. So it doesn't follow, as you suggest, that the 1GB cards must contain 1024MB.
It is confusing, and it'd be nice if everyone stuck with one standard, but they don't. But that doesn't mean that using one standard instead of the other is a lie. —Erik Harris12:30, 20 March 2007 (UTC)
I always thought that these 7.4 % of reserves achieved by "converting" 1 GB to 1 GiB may just be dedicated to spare sectors which, in turn, are silently managed by the SD controller. Aren't they? --saimhe22:49, 12 April 2007 (UTC)
There seems to be some confusion out there about how the SD cards are to be formatted. The SD Card Association has official card formatting software. http://www.sdcard.org/about/downloads/ . The software is free and includes a PDF manual in English and Japanese. The manual notes that "Generally, SD/SCHC Memory Card file systems with generic operating system formatting software do not comply with the SD Memory Card Specification. If you have formatted SD/SDHC Memory Card with generic operating system formatting software, reformat SD/SDHC Memory Card using this software or the appropriate formatting software prepared by the SD hosts provider." 67.169.225.305:08, 7 April 2007 (UTC)ddevore
In effect I had troubles using SD 2GB cards formatted with Windows XP (both FAT and FAT32): I experienced very low transfer rates writing files to subfolders. I solved reformatting with the aforementioned software. Updated version can be found here: http://panasonic.jp/support/global/cs/sd/download/sd_formatter.html
Article tone
Please keep in mind that Wikipedia is an encyclopedia, not a tech tutorial/advice website. Some of the recent changes strayed greatly from an "encyclopedic tone" and turned the article more into a how-to column, with lines like "when purchasing memory cards, do this." Also note that anything contained within <ref></ref> tags does not appear in the main body of the article. One of the reference descriptions was changed in such a way that it made no sense in the proper context, but might have made sense if it were inserted into the article. I've done my best to manually reverse these changes without reverting all of the other changes that have been made recently. —Erik Harris15:33, 9 April 2007 (UTC)
Open Source implementations
As of February 2007, the SDCA has released an updated version of the simplified specification. Does anyone know what prompted this update? Also, the OLPC project says it has produced a truly open-source SD implementation. I've added both these things to the article, but I would like more context:
What makes the OLPC implementation more open-source than previous reverse-engineered versions?
How does the simplified spec version 1.0 (released in 2004) differ from the full spec?
How does the simplified spec version 2.0 (released in 2007) differ from the full spec?
It'd be nice to provide more information on the capabilities and limitations of open-source implementations. MOXFYRE (contrib) 18:01, 4 May 2007 (UTC)
The OLPC version is not really more open than the previous ones. They just made sure to use an open interface, not one of the many still closed. PierreOssman07:01, 7 June 2007 (UTC)
If the "simplified spec" is unavailable for microSD, htf can microSD be 'open source compatible'? For that matter, what does that row even MEAN? --moof01:38, 26 September 2007 (UTC)
Too... many... modes...
There seems to be mass confusion about what exactly are the different modes of operation supported by SD cards. Especially it has become clear that the MMC and SPI modes are *not* the same (SPI mode is sort of a limited subset), as Samsung's datasheet clearly distinguishes them. Also, is the one-bit SD mode the *same* as one-bit MMC mode? Part of this article says that they're different because the one-bit SD mode uses separate data and command channels, but below the big comparison table it's implied that they are the same. The 4-bit and 8-bit parallel modes are clearly distinct. I think we really need to sort out the different SD access modes:
which ones are distinct?
when did they originate?
exactly which models of SD/MMC cards support them?
MMC and SD use the same electrical specification, both in SPI and "native" mode. They use different, incompatible protocols though. Generally, an SD card does not support the MMC protocol and vice-versa. The wider modes use the same protocol, just with more data bits to get the speed up. Also, the high-speed modes differ between SD and MMC so they can't be interchanged either way. PierreOssman07:01, 7 June 2007 (UTC)
Image in infobox
I believe that the diagram works best in the infobox to show at a glance what an SD card looks like. Rstoplabe14 disagrees however and believes that his image of two SD cards should be used instead. I think we need to establish a consensus on using either one or the other. AlexJ14:48, 4 September 2007 (UTC)
I vote diagram. Given the current choice of images, I vote for the diagram. It's simply much clearer, brighter, and more informative. There are photos of bona fide SD cards elsewhere in the article, I see no reason why one has to appear first. MOXFYRE (contrib) 14:53, 4 September 2007 (UTC)
I am not a Wikipedia writer or editor or any such thing. I am just a web surfer, and I want to share the following story with you. I wanted to find out what the *bottom* of an SD card looks like. So I did some Googling, and after looking at a ton of web pages that only showed the *top* of an SD card, I finally was happy to find this page because it shows exactly what I was looking for: a picture of the *bottom* of an SD card. Thanks for putting that picture here, and I also suggest that you put such a picture on the web page at this URL: http://en.wikipedia.org/wiki/Secure_Digital_cardJohnDrefnier04:30, 10 September 2007 (UTC)
The article incorrectly states that EyeFi uses a nearby computer, however, I once read an article that said it uses a boradband WiFi to connect to EyeFi servers, and then back to the host computer, which must be running their software. Can anyone confirm this or knows which article I'm talking about? --stuston (talk) 20:18, 16 January 2009 (UTC)
EyeFi uses a wireless access point. It can only function in infrastructure mode, not in an ad-hoc network. It uses the AP to connect to centralized servers, and individual computers can separately connect to those servers. So there's no direct EyeFi-to-PC communication. I'll try to update the article to reflect this. ǝɹʎℲxoɯ (contrib) 21:12, 16 January 2009 (UTC)
DRM
The DRM section (mostly the second and subsequent paragraphs) sounds quite full of FUD to me. Nothing is sourced and it sounds like just a rant, slightly paranoid, on DRM. I don't see that it adds much that's useful. -Ethan (talk) • 2007-11-25 00:55 (UTC)
I am as anti DRM as Richard Stallman and the EFF, yet i see those paragraphs as nonsense. The only useful thing i can think of using DRM in a SD or SDHC is if, the labels or movie studios started selling their "products" using these instead of CDs or DVDs. And i have not heard of any players or formats being planned for that, yet. A 1g SD might cost them a couple of dollars while 4g DVDs go for 50cents or so. Not to mention the public reaction in the USA about way smaller and more efficient storage and playing devices that could easily outlast all current methods. Those are big no noes for an aging industry. Anyway yes, i suggest to remove those two paragraphs (2 and 3) from the DRM section. There is a nice DRM article you can always link to. Artemis3 (talk) 08:55, 25 November 2007 (UTC)
speeds of SD vs. SDHC cards
According to Sd card#Speeds, SD cards come in four different possible speeds - 0.9mb/s, 6mb/s, 10mb/s, and 20mb/s. According to Sd card#SDHC, SDHC cards come in three different possible speeds - 2mb/s, 4mb/s, and 6mb/s. From that, it looks like the fastest SDHC card is slower then the fastest SD card. Is that correct or is there something I'm missing? And if it is correct... why? According to the article, "SDHC uses a different memory addressing method". Is that what's slowing it down? TerraFrost19:57, 4 December 2007 (UTC)
Reference 10 on the article claims that the current maximum capacity supported by the "Physical Layer Simplified Specifications Version 2.00" for SDHC is 32GB. If I understand correctly a new version of the specification could support more, but it's not clear if a hardware or software update will be required for readers to suport higher capacities than 32GB. I don't want to muddy the waters here by editing the article without being certain. Input anyone?
--Anonymous —Preceding unsigned comment added by 221.106.232.1 (talk) 01:05, 14 February 2008 (UTC)
READ_BL_LEN This field is fixed to 9h, which indicates READ_BL_LEN=512 Byte.
Page 98:
C_SIZE This field is expanded to 22 bits and can indicate up to 2 TBytes (It is the same as the maximum memory space specified by a 32-bit block address.) This parameter is used to calculate the user data area capacity in the SD memory card (not include the protected area). The user data area capacity is calculated from C_SIZE as follows: memory capacity = (C_SIZE+1) * 512K byte As the maximum capacity of the Physical Layer Specification Version 2.00 is 32 GB, the upper 6 bits of this field shall be set to 0.
Thus the card have bit fields to represent upto and including 2 TByte. BUT the SD Card association have decided that memory cards shall be limited to 32 GByte.
However this doesn't prevent any 3rd party to make hardware that will handle this just fine.
Electron9 (talk) 11:00, 16 March 2008 (UTC)
Why SD-Card v1.01 can handle 4 GB
Technical reference as to why SD-Cards v1.01 can handle 4 GB as per the standard document:
In the SD Card Associations "Simplified Physical Layer Specification v2.00" it is specified in:
Page 89:
Table 5.3.2 CSD Register (CSD Version 1.0)
Name
Width
Cell type
CSD-slice
READ_BL_LEN
4
R
[83:80]
C_SIZE
12
R
[73:62]
C_SIZE_MULT
3
R
[49:47]
Page 91
READ_BL_LEN
Block-length
0-8
reserved
9
29 = 512 Bytes
10
210 = 1024 Bytes
11
211 = 2048 Bytes
12-15
reserved
"The maximum block length might therefore be in the range 512...2048 bytes"
Page 92
C_SIZE
"This parameter is used to compute the user's data card capacity"
I hope this clearify the situation on SD-Card v1.01 capacity. However not all devices are implemented in such way to allow for READ_BL_LEN to be set to 10 or 11.
Electron9 (talk) 10:45, 16 March 2008 (UTC)
The same specification states that the speed of SD cards is officially limited to 2 GB (see pages 5 and 14). A 4 GB variant, while it does indeed appear to be possible according to those figures on page 92, is still not to-spec and should not be considered an 'SD card'. 136.186.1.191 (talk) 01:58, 1 July 2008 (UTC)
In the "form factor" section, it states that "SD cards typically have higher data transfer rates, but this is always changing, particularly in light of recent improvements to the MMC standard."
SD-cards can handle 4 GB, SDHC can handle 32 GB. Bad edits BEWARE!
It seems some people have fun by changing the max capacity of SD-cards to something which is in contradiction to the specification. Even when the relevant parts are included within the article itself!
The last incident is with Amoiwangjy on 2008-05-20 that only have one contribution and a Comcast Cable/NJ user on 2008-05-30 that then changed the "contradiction" to be an all out consistently wrong information.
A standard SD-card can handle anything from 2048 bytes to 4 GB.
c_size=0, c_size_mult=0, read_bl_len=9
(c_size+1) * 2**(c_size_mult+2) * 2**(read_bl_len) = 2048
A standard SDHC can handle anything from 512 KB to 32 GB (inoffically 2 TB).
c_size=0
(c_size+1) * 512 * 1024 = 512 * 1024
This not saying that they are sold with all possible capacities. Usually 8 MB is the minimum.
Some SD-card reader systems does not correctly process the READ_BL_LEN parameter. And therefore will not correctly recognise some cards (esp 2G and 4G cards in std sd-card readers). But this is NOT the same as saying >1GB - 4GB standard sd-cards doesn't exist or will not work.
Electron9 (talk) 01:46, 13 June 2008 (UTC)
SDXC backwards compatibility
There seems to be substantial overlap between the SDHC and SDXC specs. Are the latter backwards-compatible with SDHC readers? This seems especially pertinent with SDXC cards being announced in the 32GB range, overlapping with currently available SDHC cards. MrZaiustalk11:01, 6 March 2009 (UTC)
SD 1.01 cards w/ more than 66x
There are SD 1.01 cards available w/ read and write speeds more than 66x, i.E. [3]. I own one of this cardws myself (the 133x/30x 2GB version). It only can be read at about 5.4 MB/s (~36x) w/ my card reader using hdtach, but I think the reasopn for this is my old card reader (hama 19 in 1 rev. 1.0, model number 00055114). --MrBurns (talk) 08:23, 14 March 2009 (UTC)
I removed the sentence about the maximum of 66x, because SD 1.01 card w/ higher speeds exist. If anyone wants to revert this change, he should have a source that SD 1.01 cards w/ >66x speed are faster then allowed by the specification. --MrBurns (talk) 01:32, 20 March 2009 (UTC)
Speed Classes are not exclusive to SDHC Cards
This article places the reference to the Speed Classes (6.1 SD Speed Class Ratings) under SDHC (6 SDHC). While both SDHC and the Speed Class came out of the Version 2.00 spec, and SDHC Cards must meet at least Class 2, the Speed Classes can and do apply to SD Cards as well as SDHC Cards. In other words, the specification does not preclude the use of Speed Classes for SD Cards (as opposed to SDHC Cards.)
SD cards have a small lock switch (at least the large ones). You can also see this on the photos included in the article. What is this switch good for? Could someone include this information in the article? Thanks! --86.135.82.168 (talk) 11:35, 31 July 2009 (UTC)
I also don't know what this lock is meant to do. I thought it might lock the Micro SD card into the slot at the base of an SD adapter, but it doesn't (unless mine is broken). The article currently fails to mention what the lock is actually for. --Bilge [TC] 15:55, 15 September 2009 (UTC)
If you're talking about the little yellow lock at the left of the cards in the very first picture, then it's a "read only" lock, but, unlike e.g. an old floppy disk, it's not a physical read-only switch. Software on the computer can see the setting of the switch, but the software/driver is free in choosing to ignore it or not. Many devices ignore it, but some will acknowledge the setting and mount the card read-only. In my experience digital compact cameras are in the latter category. --TArntsen (talk) 09:32, 14 May 2010 (UTC)
Hacked cards, miss clasifications stickers.
There are hacked cards that act like say 16 gig cards but after you put more than a gig on them data starts getting lost. There are also cards with stickers for class 6 but are actually class 2. Some mention to this fraud should be given. —Preceding unsigned comment added by 204.13.130.37 (talk) 17:24, 14 August 2009 (UTC)
There are fraudulently marked and spec'ed electronics products of all kinds, from LCD screens to cables to batteries to flash media... there is nothing particular to SD cards that I am aware of. Do you have any specific information on fraudulently marked SD cards? Moxfyre (ǝɹʎℲxoɯ | contrib) 17:51, 14 August 2009 (UTC)
missing aspects on speed classes
I had a chance to use this article for finding a right card for my situation, and I found that the following aspects are missing or not clear in the article:
speed class: does it apply to SDHC only, or equally to SD and SDHC?
does the "speed class" apply only to the card itself, or also to a host device (i.e. a laptop, a camera etc)?
in the latter case: does a host device of a lower class always able to read/write a card of a higher class? What about vice versa?
overall, is there any incompatibility possible caused purely by classes of a card and a host device?
I still don't feel an expert in the topic, but hopefully someone can give answers by improving the article itself. Thanks! --DenisYurkin (talk) 22:21, 29 August 2009 (UTC)
"Secure"?
Please add to the article to explain why is it called "Secure" Digital? Does it have some security features? If so, what are they? What types of problems do they defend against? Or is this just meaningless marketing hype? 68.110.104.80 (talk) 17:16, 1 November 2009 (UTC)
The secure features are there to protect the video/music industry against consumers that are evil by definition ;-) Ie it's not for the benefit of the consumer asfair. Electron9 (talk) 06:16, 8 November 2009 (UTC)
The article doesn't explain this very well. But as I understand it, quite a number of devices have no problems with the 2GB cards but don't work with many 4GB cards. I don't really know why. The article makes it sound as if you would expect 2GB and 4GB to have roughly the same level of compatibility problems also seem to suggest both are equally defined in the format. But as you mentioned, many sources particularly in the early days of SDHC were claiming that 4GB was unstandard and there have also been a few people who mentioned it here. I also note the SD card association [4] says 2GB is the max for SD. My guess (i.e. doesn't belong in the article) is that even if 2048 bytes per block was defined in the standard, the SD card association recommended the max size be 2 GB or didn't recommend the 2048 bytes per block be used even if it was defined therefore some devices even if they were up dated to support the new paramaters for BL_LEN for 1024 bytes per block did not support 4 GB cards (whether they refused to recognise 2048 bytes per block or 4 GB cards I don't know). The 4 GB cards could also be non standard even if they are theoretically possible from a simple reading of the spec if the association recommend against them. I believe there were also 8 GB non SDHC cards. I guess some vendors extended BL_LEN to be 12 i.e. 4096 bytes which of course was even less likely to be recognised Nil Einne (talk) 09:00, 25 January 2010 (UTC)
Actually looking more closely at the official spec you linked to earlier, it says it there as well. [5]
Up to and including 2 GB
(in two places).
There's also the section on "4.3.2 2 GByte Card" which we mentioned, but it doesn't say anything about 4 GByte card, nor does anywhere else.
There are also other similar things specifically
To indicate 2 GByte card, BLOCK_LEN shall be 1024 bytes.
Therefore, the maximal capacity that can be coded is 4096*512*1024 = 2 G bytes.
I'm now more confident in my guess. 4 GB SD is clearly not allowed in the spec. The fact it's theoretically possible from some parts of it doesn't change the fact the spec says not do to it. Any thing which does do it is not complying with the parts of the spec which say not do it.
It's possible older versions of the spec allowed it and the SD association simply changed the spec so there was no overlap in which case it's perhaps most accurate to say for a time it was allowed but it no longer is. Alternatively they were considering allowing 4 GB so expanded to 2048 but decided in the end to use SDHC for that. Perhaps they decided it was more problems then it was worth because some vendors didn't support 64k clusters so couldn't handle 4GB with FAT16.
Whatever the case, even if 2048 is defined, it's not supposed to be used. Some vendors did implement it which worked with some devices, and I guess some vendors further extended past the spec in the logical direction and added 4096.
As for what this means for the article? I strongly believe we should stop claiming that 4 GB is allowed. We can say it's theoretically possible if ignore parts of the spec which say not do to it you want, even though that's a bit ORry. (Perhaps something like A block length of 2048 bytes is also defined, which would allow 4 GB cards, but the specification does not provide guidance for its use and specifies the maximum size as 2 GB.) We can say some vendors implemented it. We should not say it's supported/allowed since the current spec clearly specifies in numerous places 2 GB is the max, not 4 GB.
The article lacks technical details on SDXC. For example, is it a type 2 card (like the way SDHC type 1)? Does it siiply use the 6 extra bits (for a total of 22 bits) that are currently unused in the SDHC (which only allows the use of 16 out of the 22)? Has the SD association ever said why they only extended SD to 32GB (from 2GB if you follow their official specs) when it seemed fairly obvious that wasn't going to last very long and it seems that they could have easily supported 1TB at the time (albeit what file system to choose may have been a more difficult choice)... (The obvious answer is money, but may be thay have an offiical answer on why they did this) Nil Einne (talk) 09:02, 25 January 2010 (UTC)
oi... "smartmedia not easily available" in 2007?
So how come I keep seeing them on the shelves in random photo and electronics shops? There's still a stock of them knocking around and there must still be enough of a user base occasionally buying fresh cards (why throw out a perfectly servicable 3 or 4 mpixel camera with good optics if it hasn't broken, just because it's >5 years old?) for it to be worth that small square of the establishment's shelf space. Case in point, last time I found a film camera in the cupboard with a near-finished film, took the last couple shots and dropped it off at the local pharmacy for processing (mid january this year (2010)) - a few packets of 128mb smartmedia hanging on their flash card rack, inamongst the SDs, memory sticks, compact flashes and XDs. Price was ludicrous for the capacity (£20?) but it was there and available. Plus Amazon has _loads_ of them. 193.63.174.10 (talk) 14:35, 15 March 2010 (UTC)
Overlap?
The article says "Standard SD card capacities have a maximum of 2 GB.[1] The capacity range for high-capacity SDHC cards overlap, beginning at 4 GB". So apparently they do not overlap. Where is truth? Goochelaar (talk) 13:07, 18 March 2010 (UTC)
Truth is some editing morons do not read the technical specification released by SD-card association and claims 4 GB is impossible. And even 2 GB in some cases. Std-SD and SDHC do overlap. Electron9 (talk) 14:12, 30 March 2010 (UTC)
Data Rate Measurement.
Hi guys,
Please don't change data rate measurements to bytes per second. it leads to confusion.
The main page of this article lacks information on the maximum heat a typical SD chip can perform in.
Do chips ever fail because of high heat? Does the data transfer at different speeds ever change when the operating temperature reaches a critical point? Dexter Nextnumber (talk) 02:11, 23 June 2010 (UTC)
SD ID
I understand one of the "secure" features of SD is a read only, guaranteed unique ID a lot of embedded system software uses for copy protection.
Can anyone pitch in on this? Thanks! —Preceding unsigned comment added by 84.1.50.169 (talk) 20:41, 24 June 2010 (UTC)
UHS
I think that UHS specification belongs to Transfer modes rather than to Speeds section. Despite of marketing fuss about it, the specification itself seemingly have nothing to do with minimal speed of transfer. Real cards (like Kingston SD10A/64GB) are still double labeled with Class 10 and UHS-I. It seems that UHS-I label is just a characteristic of interface supported and has no direct connection to the transfer speed.
--Korj.by (talk) 07:55, 27 June 2010 (UTC)
4 and 8GB?:
I cannot find anywhere that sells 4 and 8 gig SD cards.
Are they available for purchase, or just in development. If so, maybe it should be noted in the available sizes that you cant buy 4 and 8 gig cards yet. AshTM00:37, 26 June 2006 (UTC)
Where are you located? In the U.S. Newegg (and many other retailers) sells 4GB SD cards for around $85. Lennylim22:18, 27 June 2006 (UTC)
As I understand it a 4Gb SD card is now considered non standard and would now be made as an SDHC card. So 2GB and below are made as SD cards and 4GB to 32GB are made as SDHC cards. BrianDGregory (talk) 17:05, 14 December 2010 (UTC)
SD card versus USB flash memory
These seem to be competing forms of memory storage. Am I correct? What if any significant advantages/disadvantages exist between them? Tmangray04:01, 12 February 2007 (UTC)
Not quite. This isn't quite an apples/oranges comparison, but it's not quite apples/apples, either. SD Cards have a variety of applications, primarily for small form-factor storage in portable devices (though it is used in some non-portable devices, and there are readers built into computers). USB storage devices aren't suitable for most of the SD applications. They're more useful for portable storage of files that are brought from computer to computer, without requiring a reader device supporting a specific format (given that USB has become very much a standard I/O port on PCs and Macs in recent years). There are a number of competing forms of memory storage for portable devices (SD, CompactFlash, xD, Memory Stick, etc), but USB storage devices are part of a largely-separate market sector. —Erik Harris18:51, 12 February 2007 (UTC)
Memory card readers are more and more found embedded in laptops, desktops, printers, etc. This will make them competing soon. —Preceding unsigned comment added by 82.67.63.244 (talk) 19:01, 10 January 2008 (UTC)
USB is not competing with memory cards, you will never find a camera that needs a USB pen drive sticking out the side to hold your photos. On the other hand, yes, memory cards have always competed to some extent with USB pen drives as a way of storing, backing up or transferring data between computers. BrianDGregory (talk) 17:14, 14 December 2010 (UTC)
Shouldn't there be a table that indicates the cards' models and availabilities/discontinuities?
I know there's a table that indicates the ratings, write speed, and class of specific cards, but not a table on specific cards' models or availabilities/discontinuities. The 256MB, 512MB, and 1GB SD cards have been discontinued, and models beyond the 2GB cards are still available. Shouldn't there be a table about the cards' models or availabilities/discontinuities? Just asking.
~~LDEJRuff~~(see what I have contributed) July 20, 2010, 18:06 (EDT) —Preceding undated comment added 22:06, 20 July 2010 (UTC).
There are a vast number of companies which manufacture or at least brand SD cards, and a huge number of different models, making such a table impractical to maintain and to properly source. Available models are constantly changing, and in general the differences between individual products are negligible except for the obvious differences in speed and capacity. Also, I'm not sure if <2GB cards are really discontinued... they appear still to be available new from several sites. Moxfyre (ǝɹʎℲxoɯ | contrib) 13:42, 21 July 2010 (UTC)
Though this article has lots of great information, it still needs a lot of tweaks and enhancements, please be patient. • Sbmeirow • Talk • 03:09, 24 February 2011 (UTC)
Merger proposal
I propose that we merge MicroSD and MiniSD articles into the Secure Digital article. Basically, the smaller cards are nothing more than a subset of the larger cards. To fill out the articles for the smaller cards would require large amounts of duplicate text. I think it is better to have a one-stop-place for all the information. What are you thoughts? • Sbmeirow • Talk • 22:02, 30 January 2011 (UTC)
The contents of the MiniSD page were merged into SD card/Archive 1. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page.
Does anyone think some of the obsoleteness of SDIO implementation with the advent of smartphones should be included? I know from personal experience these were useful back in the day when standard Pocket PC PDAs more often than not didn't have any sort of built-in wifi or bluetooth. With smartphones now including almost all available features the SDIO cards have fallen into obscurity. —Preceding unsigned comment added by 208.124.50.203 (talk) 03:26, 22 March 2011 (UTC)
Just because SDIO isn't popular doesn't mean that it should be removed from the article. I personally think the "mini" size has become obsolete, but I've never felt that information should be removed. I wish more peripheral types would be added to SDIO and that it would become more popular. • Sbmeirow • Talk • 05:52, 22 March 2011 (UTC)
I don't think anyone's advocating removal of the information. I would agree with the anon @ 208.124.50.203 that the article should include information on obsolescence of SDIO, if that is the case. I would seem to me that the market has gone in a different direction, but I don't actually know. A reliable source is needed. —DragonHawk (talk|hist) 17:38, 1 April 2011 (UTC)
Common Problems: Repair a non-formatable SD-card
I think the following information would help many people. I am not sure if it is suitable for Wikipedia. Where could the following be put in order to maybe insert a reference into the SD-Card wikipedia page? Is a different WikiMedia project suitable? If you have an answer I'd be happy if you could copy it to my user page! This is a problem I face quite often. Now the text about SD-cards:
SD cards can become corrupted quite easily when a faulty device deletes its "secure area". It is not possible to revive it with a normal format operation (e. g. the one integrated in Microsoft Windows). Special software can do a low level format. After that and a following high level format the card is usable again. E. g. this free software works:
http://hddguru.com/content/en/software/2006.04.12-HDD-Low-Level-Format-Tool/
I want to point out that "low level" disk tools aren't truely low level. I don't think it is even possible for the avarage user to get low level access to modern hard drives. With SD cards, I don't think it's even possible to do anything with the controller that would allow any sort of low level access, let alone trying to do it over a USB card reader. The USB connection makes it even less likely so because of the OS sees any "disk" as a collection of 512 byte blocks, regardless of what the SD card uses internally. The best the avarage person can do is zero fill the drive, and that's what many of these "low level" software packages do. 66.114.93.6 (talk) 18:58, 4 January 2009 (UTC)
If Windows sees that the first sector of an SD card looks like a partition table with no partitions Windows will refuse to reformat the card and will say that it has unknown capacity. Zeroing the first sector fixes this problem though I think windows will still format the card incorrectly after this. 86.13.77.126 (talk) 09:24, 10 January 2009 (UTC)
Electrical Interface section reviewed by SD Card Association
Previous to editing this article, I've come across conflicting statements and confusion in multiple engineering blogs and articles. Many people were under the impression that SPI might be optional because of statement in this wikipedia article. Some people said they never found a SD card that didn't work with SPI bus. I decided to download the SD specs and investigate so I could determine the facts, which I then created this electrical interface section and corrected statements in other sections. The only big holes in this section is that I didn't describe the newest 1.8-volt higher speed protocols for SDHC and SDXC families. The most important part that I've done is describe what is common across ALL of the SD families.
If you find a technical mistake in the "electrical interface" section, please reply to this comment with the problem and the EXACT section of the SD specification that states otherwise, so we can investigate and determine the correction. Thanks. • Sbmeirow • Talk • 21:08, 24 February 2011 (UTC)
Absolute upper limit on SD/microSD memory size?
What is the upper limit on the memory size of SD/microSD cards? There has to be a upper limit put down by the laws of physics right (or in other words, theres a limit to how small a transistor can be shrunk)? Can anybody answer this question? 137.132.250.10 (talk) 10:00, 23 March 2011 (UTC)
Class Speed listed in bits not bytes?
This table seems to be wrong -- looks like it should be MB(ytes) not Mbits, but I can't find a decent citation else I'd edit it myself. Anyone? One source here: http://www.toshiba-memory.com/en/sd_speed_classes.html -- but perhaps the official info is buried in the member-only pages of http://www.sdcard.org/.
Class 2: 8 Mbit/s
Class 4: 15 Mbit/s
Class 6: 20 Mbit/s
Class 10: 30 Mbit/s
I agree this is confusing and needs to be clarified. Typically I think SD cards are measuered in MegaBytes but I can't verify this.
78.105.181.134 (talk) 17:43, 30 May 2011 (UTC)
Size
The technical specification linked to by reference 1 explicitly states in multiple places that the maximum capacity is 2GB.
The calculation to show 4GB in this article is I believe based on this from the specification:
• C_SIZE
This parameter is used to compute the user’s data card capacity (not include the security protected
area). The memory capacity of the card is computed from the entries C_SIZE, C_SIZE_MULT and
READ_BL_LEN as follows:
memory capacity = BLOCKNR * BLOCK_LEN
Where
BLOCKNR = (C_SIZE+1) * MULT
MULT = 2C_SIZE_MULT+2
(C_SIZE_MULT < 8)
BLOCK_LEN = 2READ_BL_LEN, (READ_BL_LEN < 12)
To indicate 2 GByte card, BLOCK_LEN shall be 1024 bytes.
Therefore, the maximal capacity that can be coded is 4096*512*1024 = 2 G bytes.
Example: A 32 Mbyte card with BLOCK_LEN = 512 can be coded by C_SIZE_MULT = 3 and C_SIZE =
2000.
This does not say that the BLOCK_LEN value can be greater than 1024 and as the specification elsewhere says 2GB is maximum capacity why keep pushing the 4GB size? noq (talk) 13:31, 31 March 2010 (UTC)
Because 4 GB cards are readily available and supported by major brands like Canon. However if you call them they will say it may work. But in practice it does work and I use 4 GB std-SD daily. The specification may specify that 2 GB is max. One can claim support for 4 GB is somewhat flaky but the same could be said for 2 GB as well because BL=1024 is not fully implemented. Only < 1 GB cards is an absolute sure bet. Also saying that 4 GB does not exist, is impossible or doesn't work seems like being in self-denial when such exists physically and does work. In the end when a card controllers are designed. The tables in the specification are the ones that are actually implemented. And in combination they will address 4 GB.
A more accurate description would then be to claim that Std-SD is 0-4 GB. With the note that SD card association does not officially endorse them (their tables does support it however). The same situation can be seen between SDHC and SDXC. Where the tables for SDHC have no real 32 GB limit. It's completely artificial.
A user with a 4 GB card in his hand will likely not believe an article that says that's impossible.
Do you have any references for this? The reference in the article says the standard is 2GB - Are the 4GB cards branded as being standard compliant? If non-standard cards support more than the specification then it should be stated clearly that they are non-standard. noq (talk) 23:59, 31 March 2010 (UTC)
I have read the actual specification details. The data structure tables defines what's possible or not. Side notes that says anything else is easy to produce. But isn't backed by data structures set in place by SD card association themselves. And you have to specify which reference you are talking about. Last time I checked the SD card association made access to the specification cumbersome as well. I think only a "simplified" compilation of previous versions is publicly available.
Wikipedia requires that claims are WP:verifiable. If there is a specification that does state that 4GB is allowed then reference it - it does not need to be an online reference. Without that it just looks like WP:Original research. Just because something is physically possible does not mean it is in specification. noq (talk) 18:12, 1 April 2010 (UTC)
The specification spls.pdf says at page 91 READ_BL_LEN may be in the range 512..2048 (table 5-8). Which is the critical part. Sandisk which is part of the core SD group have themselves sold Std-SD 4 GB cards asfair. I just didn't buy them because of the price. I searched the webb but only found this ebay card. Seems non-SDHC/XC cards is a pain to get now. Anyway in other parts of the spec it says "2 GB" but contradicts itself by the tables and formulas used. So I suggest the article facts-box says Std-SD is 0-4 GB. BUT mention in the text that the SD group only considers less then or equal to 2 GB as spec compliant. Otherwise the article will not reflect the reality of the card I uploaded a picture of. (As a side note I found that it would be possible to make an 64 GB std-sd card and still make it work, as devices use FAT32 for >2GB anyway). Electron9 (talk) 23:50, 1 April 2010 (UTC)
You seem to be missing the point which several people including me above have made. The specification clearly says no greater then 2GB is allowed. The fact that by ignoring one part of the specification you can make 4GB cards doesn't change that. (The same could of course be said for SDHC cards greater then 32GB.) A fully compliant with the latest 1.xx spec (or for that matter 2.0 or 3.0) SD device is therefore not guaranteed to support SD cards greater then 2GB simply because the specificiation doesn't say it has to. It may be true some cards have been made and they work with some devices but this is irrelevent to the point. (It of course doesn't help that some devices don't support 64 kb clusters nor FAT32.)
And the fact that some devices are not fully compliant with the latest 1.xx spec and therefore can't read cards fully compliant with the latest 1.xx spec is also a different point.
BTW I have no idea if Sandisk makes 4GB SD cards (and it isn't particularly relevent) but an eBay link us pretty useless for demonstrating that since there are a large number of fake cards there. There's no guarantee the card you linked (which isn't visible anymore) is even 4GB let alone it is a Sandisk. Sandisk themselves at one stage [6] said such cards were non compliant which is of course true even if you are apparently not able to understand that.
Note that I don't think anyone is saying we pretend that 4GB cards don't exist. Instead what we are saying is what I said before but will repeat for good measure. We need to acknowledge that while they exist and work with some devices, despite what an incomplete reading of the spec may suggest; 4GB cards aren't fully compliant with the spec. Therefore any fully compliant device is not guaranteed to be able to support 4GB cards. Which as I said is a different thing from 2GB card issues since such devices are not fully compliant with the latest spec (although they may be compliant with an earlier version).
Does anybody know if there is an extension lead available that enables an SD card to be inserted into one end - female (i.e. the same connection as is found on a laptop), the other end being a male connection. Any help would be greatly appreciated.
Um... no? What exactly would be the point? It's probably doable, by ripping open a regular SD card reader and a mini/microSD adaptor, getting a ribbon cable and doing some creative soldering. More practically, you could put it in a USB reader, and attach that to the laptop's USB port via an Am-Af extension cable... 193.63.174.10 (talk) 14:30, 15 March 2010 (UTC)
don't know of any but the usefulness is simple: as a connector-saver, meaning that in high disconnect situations the adapter wears out instead of the computer's (or whatever host) connector. Connector-savers are very common in electronics manufacturing. An SD/SDHC connector saver would forgo the issues of using USB as an interface. Ken (talk) 20:46, 18 May 2010 (UTC)
But what does your built in SD reader use? Our articles says many laptops have built in readers not using USB which is unsourced but if true may you can 'forgo' the issues of using USB as an interface with tem but if your laptop uses a built-in reader that is using USB then clearly you're not. Nil Einne (talk) 07:22, 3 July 2011 (UTC)
SDXC
The decision to label cards with a capacity greater than 32GB as SDXC and to use a different filesystem is due solely to the limitations in creating larger filesystems in certain versions of Microsoft Windows.[citation needed]
The article currently says this. I added the citation needed tag because it's unsourced. More importantly it sounds rather dubious. The simple fact is the SD 2.0 spec which defined SDHC cards only specified up to 32GB. The fact that larger is possible by simply specifying a larger size doesn't change the fact it's not in the spec therefore a fully compliant SDHC device is not guaranteed to work with a card greater then 32GB. If the SD group had simply defined a SD 3.0 or 2.5 even if they had used FAT32 but allowing greater then 32GB this would likely lead to confusion since you would have SDHC cards greater then 32GB but which may or may not work with older fully SDHC compliant devices. For this reason giving a new name is preferred in many areas, even if it's simply SDHC2. As for the file system, the limitations in certain versions of Microsoft Windows may have been a factor but I haven't seen much evidence it was the sole reason why exFAT was selected over FAT32. As far as I understand it, there are several reasons why exFAT may be preferred for rather large volumes, e.g. 2TB (the maximum SDXC specifies); performance, maximum file size. In other words, perhaps without the Windows limit the SD2.0 would have specified larger cards e.g. 64GB or 128GB as the maximum for SDHC but there's no reason to think we wouldn't still have had SDXC at some stage and probably not using FAT32. So the article is likely misleading to make the unsourced claim the sole reason for SDXC and to use a different file system is due to the limitations in Windows. Nil Einne (talk) 07:39, 3 July 2011 (UTC)
This article is full of extraneous links. Only the first instance of a link (eg, SDHC) is necessary. Also, many links that used to go to other pages (eg, microSD) simply redirect back to this (article) page. Is there a WP 'bot' that can clean this up? Regards, nagualdesign (talk) 17:13, 21 July 2011 (UTC)
Tebibytes/Terabytes?
The lead section says that SDXC cards have an upper limit of 2 TiB, but the section of the article focused on SDXC cards says they have an upper limit of 2 TB. I realize that the difference is functionally moot, given the standard practice of binary prefixing, but since the first instance is the unusual form, I feel that it ought to be changed. Feedback? 69.105.38.18 (talk) 17:48, 9 July 2010 (UTC)
15, June 2011:
I see in the article, when stating capacities, it is always in MB, GB or TB, not MiB, GiB or TiB. Does, for instance, a 2 "GB" SD card really have 2GB of data storage (like a hard disk), or GiB (Like a memory chip,, 2 to the power of..)?
My 2GB SD card has a capacity of 1.83GiB (after formatting), which leads me to believe that its capacity is 2GB. A 2GiB disk volume would have a capacity of 2GiB after formatting, I think. — Preceding unsigned comment added by 184.76.47.120 (talk) 03:54, 16 June 2011 (UTC)
In respect to Secure Digital cards, 1 megabyte = 1 million bytes and 1 gigabyte = 1 billion (U.S. billion) bytes. See the cautionary notes on the packaging; this has been the case from the beginning. Thus, the use of the binary prefixes in this context is incorrect. — Preceding unsigned comment added by 96.251.57.12 (talk) 00:51, 10 October 2011 (UTC)
Contradiction re fragmentation (in the same paragraph)?
"Fragmentation may slow down the effective write speed but the effect is tiny compared with that of fragmentation on hard drives. Defragmentation tools may be used. However, it is unnecessary to use any disk optimization tool because on an SD card the time required to access any block is the same."
In the past, what is the Lowest-Capacity that EXISTS for each of these card types? I'm not talking about the standard, but what is the lowest card that ever shipped.
I deleted the second paragraph of Section 11.2, on a "homebrew hack" that interfaces an SD card to a popular router, explaining in the Change Summary that there is now a better way of getting an SD card on a router (new products under $100 by several makers that have USB ports). The author reverted me and explained on User talk:Electron9 that one point the paragraph made was the simplicity of the SD interface. I still am not sold on the relevance, but don't feel strongly about it, and leave the issue for possible comments by third parties. Spike-from-NH (talk) 21:27, 25 October 2011 (UTC)
I do agree with Electron9 that the "homebrew hack" is innovative and illustrates a simple way to connect a flash card to an embedded system using GPIO pins. Interfaces as USB, SATA or PATA (needed for connecting a CF card) are technically complex, require ditto software support, and not all embedded systems and microcontrollers have them, making GPIO pins more desirable for many home developers and technically oriented users. The "homebrew hack" paragraph takes only a few lines, the referenced article is original, interesting and well-written, and I hope the paragraph remains in the article. Jaho (talk) 23:14, 27 October 2011 (UTC)
I rewrote part of that section. I drilled down through the references, and I think the example is using the SPI bus mode instead of the 1-bit SD bus mode. All SD contacts were numbered and named in photos used the SPI bus signal names. The SPI bus is far more documented and used far more often in embedded designs to interface to SD cards. I couldn't find the source code, so I not 100% certain. If you have links to source code, please send me the links so I can examine. • Sbmeirow • Talk • 06:01, 28 October 2011 (UTC)
A useful addition that further makes the point about the ease of interfacing to the SD. It is a problem with the existing footnote that it goes to a pictorial discussion of physical interfacing to the Linksys router, at a stage when the process of finding and installing the support code seems already to have been done. This teaches you how to replicate a hack that, again, no one should ever have to do. It was I who added the "1-bit" text (as a clerical edit to differentiate from "4-bit") so your change is probably right. If the Linksys hack actually used SD mode, this ought to be noted. Spike-from-NH (talk) 12:53, 28 October 2011 (UTC)
Too technical
Last try from new editor (I understand that SOME of you do not want to lose some of US). (Some of this message may need to be moved to one or more topics - though I don't know list of topics.) Go ahead.
I tried to alert you that IMO the article was too technical. I would think that is the kind of feedback that you would want - even if you are sufficiently knowledgeable about the topic to think that the writing is NOT too technical. (My practical suggestions are near end of this message.) I was precise to state the "too technical" at front-end of my comments. Then, I detailed it with enough information (TMI?) that someone could follow my train of logic to understand why I believe it is "too technical." I am fine that article was moved, but the reasoning given to me was that my questions were "buying advice" questions. No, those were the questions that brought me to the site. SD card now bought. Info from this site did not give me info I sought to help me understand basics of purchase-decisions. e.g., My task was "buy SD card." Simple task, if you know what it is. (I already knew I needed MICRO SD card, at least 2 GB, but that was all.) Compare: Sent to grocery to "buy potatoes" or "buy apples" - Unless you know intended use (and cook's proficiency), you have good chance of buying "wrong" potatoes or apples. (i.e., Some potatoes better for baking, mashed, potato salad. Some apples better for pies vs. raw-eating. Don't know: ask someone in Produce Section. Cannot use same logic at store - unless can trust the store.) Seems that issues of SD cards is similar. One basic thing I needed to know was whether SD and SDHC interchangeable for my use. (People who suggested "buy-online" or "wait till Black Friday" missed the point of the details I provided. If this was a purchase that could have waited until I could research it, that would have been fine advice .- which I would have known anyway)
FWIW, someone advised I could "tag" the article as "too technical" - but, without telling me how to do that - Or, telling me in a way that is too technical. Person tell me to do x, but in a way that is too technical for me (at this point) to know how to do x. At this stage, if your suggestions/comments are written in mark-up language, without explanation, I am not going to understand. (I have previously asked if there is a 'Wiki-edit Glossary.') I AM *NEW* here. I will learn more if people tell/show me how to do something, rather than changing it on my OWN page FOR me. ("Give a man a fish..." vs. "Teach a man to fish....") Far better to talk WITH someone than to talk AT them.
My suggestions: Perhaps all articles, but certainly articles of technical content, could have a scale (1-5?) re intended audience, or, pre-requisites. e.g. " Before reading this article, see xyz (with pointer). If you understand everything there, then return here." Similarly, edit box gives option to indicate whether one is highly knowledgeable about something. This is a binary question. Would you not get more useful info if people could rate their knowledge on 3-point or 5-point scale?
Note: if I am not responsive soon, I suggest no over-interpretation. I have much else that also needs attention. I expect to be here episodically, at least for now, rather than "be here usually." --KnowLimits (talk) 01:49, 25 November 2011 (UTC)
No one has snubbed you! Your previous message was moved to the "Reference Desk - Computing" as a better location for it. A few readers, including me, provided comments.
Above, I had said I was fine with page having been moved. Elsewhere (my page?), I expressed concern re "throwing out baby with bath water." (more comments below, inline) --KnowLimits (talk) 21:38, 27 November 2011 (UTC)
I have been doing clerical edits of the article in the last week, though not to reduce the technical content but just to make it flow better. It seems someone a long time ago was disappointed with the lack of universal support for a super-sized SD card and wanted to use this article to spread the word--in many, many places. Spike-from-NH (talk) 02:14, 25 November 2011 (UTC)
PS--One person at the Reference Desk told you that you were looking for a Buyer's Guide for flash memory, which is not what Wikipedia is, and I commented that the technical detail in the article did not keep it from satisfying your needs. Please don't slap a "Too Technical" template on the article. Apart from the fact that some of the text may have been more detailed than you need, the real problem is that you want personal guidance that no "encyclopedia" article can provide. Spike-from-NH (talk) 02:22, 25 November 2011 (UTC)
1) Is an article too technical, well it depends on whom you ask. One person might not understand it, yet another person might demand a lot more technical information. It is a mistake to dumb-down technical articles to a point where it isn't useful for the technical crowd! Just because a person doesn't understand a technical subject, doesn't mean that it shouldn't be include or dumbed down!! • Sbmeirow • Talk • 09:15, 25 November 2011 (UTC)
2) Wikipedia is NOT a live technical help desk nor a support blog for asking your technical questions about what SD cards works with your electronic gadget. It is the manufacturers responsibility to describe and list what is compatible with your gadget. If the manufacturer doesn't supply enough information in the user manual, then it is the consumers responsibility to contact them for an answer. • Sbmeirow • Talk • 09:15, 25 November 2011 (UTC)
In fact, the article's technical detail helped me solve a chronic mystery that several 2 Gb cards failed in several (decade-old) adaptors by the same major vendor--but only under Win98. Spike-from-NH (talk) 14:30, 25 November 2011 (UTC)
Accessibility is discussed in the linked article from this banner. Accessibility should be achieved without removing notable technical detail. --Kvng (talk) 23:42, 26 November 2011 (UTC)
The merging and the clean-up banner should help.
One simple thing to make it more readable, without losing anyone has to do with scale: Although scrolled far-down into the article, there is a picture of the various cards with a commonly-recognized object, for scale - a match-stick (albeit difficult to see), the very first picture shows scale in a way available only to a technical person: Why not show that same size card next to a standard paper-clip or something else more commonly recognizable? (Perhaps, elsewhere in Wiki, there is a standard set of objects that can be used for showing size of something.) One could always have a ruler, with markings for both inches and centimenters. However, the use of a common object may be more intuitive. As page-space allows (and images available) inserting the double-ruler to images for size-visualization could be more powerful (if it it not offensive to make the "political act" of subtly helping some readers become more familiar with inches/centimeters (as need occurs).
Perhaps there's guidance from Wiki Medical Project about how to identify articles regarding technical detail. e.g., There are some well-known *medical) articles that exist in "lay" format and "professional" format.(I usually read either only the "professional" - or, if time allows, read the "lay" version as a refresher, to make sure that everything there is familiar and understood - and then read the "professional" version. OTOH, for many readers, the "lay" version would be "too technical" or the "professional" version not be sufficiently technical (for the reader's purposes). While it would likely rarely be appropriate (or good use of time) to have more than 2-3 versions (one?) of something, it could be very feasible to have, say, a 1-5 rating for degree-of-technicality - just as, at a wiki-formatting page, there was a set of instructions cautioning people that doing anything from (that* page is their own responsibility. i.e. "for very advanced users only." --KnowLimits (talk) 21:38, 27 November 2011 (UTC)
History
The rapidity at which vendors complied with an extension of the specification might be notable. A list (in our Section 7.1) of dates on which specific vendors announced that they intended to ship a compliant product, is not notable. Spike-from-NH (talk) 00:36, 26 November 2011 (UTC)
Remove or update whatever doesn't make sense today. Some information might have been added prior to SDHC or SDXC cards being available for purchase. • Sbmeirow • Talk • 01:45, 26 November 2011 (UTC)
Am happy to "be bold" regarding rewriting or rearranging other people's stuff--less so to just discard it; that's why I'm looking for feedback here. Separately, what's left in Section 4, "Types of cards", now that I've moved much of it to the section that dealt with the respective type of card, is not much more than a restatement of the intro. If it remains (a propos of the recent complaint that the page is too technical), it probably wants to be the very first section, as it describes the various dimensions of the SD spec; whereas two of the sections I've worked on, "Interface" and "File system", should move toward the end, perhaps even underneath a new container called "Technical details". Spike-from-NH (talk) 20:05, 27 November 2011 (UTC)
Just a tip - It is usually best to not use section numbers in discusion, since they are no longer valid immidately after someone add a new section above it. The quoting the name is probably the best way to do it. • Sbmeirow • Talk • 21:29, 27 November 2011 (UTC)
Just a note - The SD spec 4.0 might be adding another row of pins on future SD cards. The spec hasn't been released to the public yet. Thought you should know about it. • Sbmeirow • Talk • 21:29, 27 November 2011 (UTC)
Yeah, a technical section might be a good way to go. I thought the same thing myself in the past. Before doing it, it would be best to start a new discusion topic just for that overhaul. Actually, maybe we should have a bigger discusion of overall relayout of the article. We should probably take a look at other card types and see how they do it too. • Sbmeirow • Talk • 21:29, 27 November 2011 (UTC)
I would like to see some type of section at the top that would be useful for newbies and non-technical people. There is some info in the introduction section and various other parts of the article, but the important minimum things for buyers could be summaried in a section. I haven't come up with a good name for the section. Summary? Buying Tips? Newbie Tips (grin) Surely there is some type of useful section name that we can use! • Sbmeirow • Talk • 21:29, 27 November 2011 (UTC)
Some detail that, at one time was current - could now be moved to a "history" section. Helpful to state which card commonly used for what devices (camera, phone, etc.), as of date of edit? --KnowLimits (talk) 21:38, 27 November 2011 (UTC)
History section is about the history of the card, not stuff that you think is old. About what should be used in devices, it will be far more vague than you want, but it will be described. I know that other authors will shoot down making a big list of cameras and phones and what works with each one, so you probably should not be expecting such a thing to be here, because those types of things are impossible to keep up to date. I have seen big lists remove from other technical articles, thus I'm not going to waste my time doing it here, because I'm mostly sure it will be deleted. • Sbmeirow • Talk • 21:51, 27 November 2011 (UTC)
Archiving this talk page
Because this talk page is getting rather long, and has comments going back to 2005, I propose setting it to automatically archive threads older than 90 days (but leaving a minimum of 5 threads).
Yes, I agree on the archiving, but not the age. What periods of time is typical....3 month, 4 month, 6 month? I always thought that 3 months was kind of short. I'm new to the archiving thing and never done it myself, and curious how to do it. • Sbmeirow • Talk • 17:54, 25 November 2011 (UTC)
Seconded. I agree that comments from 2005 should be archived; archiving after only 3 months seemed too short to me too, though I defer on that to Wikipedia regulars. Spike-from-NH (talk) 00:36, 26 November 2011 (UTC)
3 and 6 months are fairly typical, but there's no standard (as far as I know). It's up to us. I've no problem about making it longer. Is 180 days (ie 6 months) be acceptable? Chzz ► 09:03, 26 November 2011 (UTC)
I would feel a lot better about 6 months than 3 months. I don't have a problem with 12 months either, but please don't make is shorter than 6 months. • Sbmeirow • Talk • 21:05, 27 November 2011 (UTC)
Especially for the reader who might be viewing this page for first time (or return visit after time-away): a year seems minimal - and a good-compromise for practical purposes. --KnowLimits (talk) 21:38, 27 November 2011 (UTC)
Continuing with the discussion in "Too technical" and "History" above: I envisage leaving in "Design and implementation" only the features that help a reader decide what SD is all about and what flavors there are--then renaming it "Features". Sections that describe how it works ("File system", "Transfer modes", "Interface", "Power use", and "Storage capacity and incompatibilities") I'd move to a new section "Technical details" to occur afterward, even after the sections that describe the market acceptance and vendor-specific features.
The fact that the ability to plug an SD chip into an SD slot is impeded by several factors seems important to a lot of readers; I also appreciated knowing exactly what goes wrong, and the exact history, but these are also "Technical details". I'll volunteer for the editing, but will instead focus on nits for a few days to await youse's responses. Spike-from-NH (talk) 14:30, 28 November 2011 (UTC)
Well, the silence was deafening, and it is now done. I've reorganized the article in this order:
Sections you need to know to decide which exact product (capacity + form factor) you're interested in
"History"--I considered renaming this "The SD Specification"
Technical details--as set out above. Then the 2 GB/4 GB/SDSC hack. It is also a technical detail and I gave it a major heading of its own solely to not go three levels deep.
Then the comparison table and the usual end matter.
The article describes Thin SD in two places as "rare" (I think the article used to hedge its bets by saying "rare or nonexistent") but I've never seen one. Similarly, my uneducated guess is that there is no new product design for which miniSD is the best choice, and a quick use of Google only shows sales of off-brand miniSDs, some at "close-out" prices, presumably for owners of existing host devices. If miniSD is a dead end, it is notable and the article ought to say so, but I wouldn't know what to cite as proof of this. Spike-from-NH (talk) 12:52, 7 December 2011 (UTC)
"An SD"
I've been corrected once after writing "an SD" (which I read "an ess dee" not "an Secure Digital") but the article has it both ways. Is there a decision on this? Spike-from-NH (talk) 12:52, 7 December 2011 (UTC)
Pin-outs for mini and micro sizes?
The "Technical details"/"Interfaces"/"SD Card Pin-outs" section needs to include the pin assignments for the micro and mini sizes as well as the standard size as the mapping is not obvious (the cards even have different numbers of contacts). JohnAHind (talk) 18:23, 21 December 2011 (UTC)
Despite the deafening silence on the above queries in the last two weeks, I have another query. Matthiaspaul has edited the article to assert that the use of the exFAT file system is mandatory for all SDXC cards. The understanding I had, based on the text of this article when I started massaging it, is that depending on the specification version it obeys, SDXC cards could be factory formatted with either FAT32 or exFAT.
Paul also makes a good case that the decision to use exFAT is disastrous, as it requires (at least for universal compatibility) manufacturers to embrace a technology that is proprietary and that "many alternative or older operating systems do not support exFAT for technical or legal reasons" (his wording as I edited it). If true, though, this should be treated as a controversy we document rather than a fact that we report. He also states that FAT32 could have been used for file systems above 32 GB, such as those on SDXC cards, but I see a claim that this wouldn't be supported under Windows, which is a good reason not to do so; at any rate, this veers toward advocacy.
The article had various facts mixed up and was partially reading like an advertisment, that's why I fixed that when stumbling upon it. It would veer towards advocacy when suppressing information important for consumers to make educated decisions, I think. Regarding your questions:
The FAT32 filesystem supports volumes up to 2 TB with 32 KB clusters and a sector size of 512 bytes. With 4 KB sectors and 64 KB clusters, the limit is at 16 TB. (Some FAT32 variants support even more, but they are not widespread and I won't elaborate on them here.) The 32 GB number is not a limit in the design of the FAT32 filesystem (or in Windows' implementation thereof), it is an artificial limit in the disk tools provided with the Windows operating systems used to create such volumes. If you use third-party tools to create larger volumes Windows will happily accept them up to the limits of their disk drivers. Also, Microsoft could easily revise their tools to support larger volumes, if they wanted to.
The limit for the disk driver in Windows 95/98/SE/ME is close to 128 GB, because this is where LBA-28 maxes out. Patching the disk driver to use LBA-48 or using third-party disk drivers, even these old issues of Windows support larger disks (I have personally tested volumes up to ca. 1 TB on Windows 98 SE, but there are reports with volumes up to 2 TB). Note, that this limit is not in the filesystem driver, but in the underlying disk driver and it therefore also applies to exFAT or other filesystems. Modern NT-based versions of Windows support LBA-48 out of the box, and even Microsoft documents that their operating systems support FAT32 volumes up to 2 TB, as do most third-party implementations (including DOS).
Since all flash cards come preformatted and the card manufacturers could even put a Windows FAT32 format tool on the card during the format process, there is not the slightest reason why this 32 GB limit in Windows disk tools could become a problem or even be a reason why manufacturers and users had to switch to another filesystem, and it is not in the case of exFAT in particular, as this filesystem does not help the sitation but instead makes it even worst given that exFAT is not supported by the majority of operating systems. If the SDA would care about missing support they would not switch to a filesystem not supported by the majority of systems, but stay with FAT32, which is supported by virtually all systems.
exFAT is a proprietary, close-spec, patent-protected filesystem owned by Microsoft, and implementing or using it requires a commercial license from Microsoft. Users of the most recent versions of Windows won't have any problems with exFAT, and exFAT drivers will also be developed for some other commercial operating systems (Mac OS for example), but users of open-source operating systems are out of luck, because even if the internals of the exFAT filesystem have long been analyzed and understood, support for exFAT cannot legally be implemented as part of such operating systems without a license from Microsoft. And such a license is fundamentally incompatible with open-source licenses or a free usage model.
Also, while exFAT has some technical advantages for very large volumes and very large files, the design of the filesystem is more complicated that FAT32, so that it would be difficult to implement it as a *native* filesystem in older operating systems (such as FreeDOS, DR-DOS, etc.) or in many embedded systems given the memory constraints.
It would have been reasonable to allow FAT32 on SDXC cards up to the 2 TB limit and recommend another filesystem (perhaps exFAT, but there are better and open alternatives) for larger volumes on future generations of cards. But it is at least five years (probably more) before we will see any 2 TB flash cards (and SDXC maxes out at 2 TB anyway), so there was no technically reason to switch to another filesystem now. Also, the very idea to switch to a proprietary closed-spec and rarely supported filesystem on what should be a universal exchange medium is absurd IMHO.
I have seen arguments that this would not be a real problem since users could always reformat their cards to use other filesystems. While this is technically possible, it may have adverse effects on the life of the card given that the internal wear-levelling algorithms are optimized for a particular filesystem if a particular filesystem is part of the spec as with SDXC. Also, while it may be possible to reformat the card in a notebook, PDA or mobile phone, most consumer devices don't support this. For example, I have yet to see a digital camera accepting a FAT32 reformatted SDXC card. Also, the typical use case for digital cameras is to store a limited number of rather large files with not more than a few thousand files in a single directory on a freshly reformatted or completely erased volume. So, there won't be problems with long seek times or free space calculations, there are no problems with defragmentation and waste of storage space due to cluster overhang, and a large cluster size (as with FAT32 on large volumes) will only increase performance. exFAT is considerably slower in such a scenario. exFAT would have advantages in scenarios where ten-thousands of files are stored inside a single directory, when volumes don't get reformatted / reinitialized for very long periodes of times with heavy file I/O frequently changing file sizes on the card, when working without a disk cache, or when lots of very small files need to be stored. Also exFAT has an advantage when files larger than 4 GB need to be stored (since on FAT32, such files would have to be split up into several files), but video editing software can losslessy recombine multiple files and most users will run into problems trying to back up files larger than 2 GB, anyway. Finally, some of the disk structures changed on exFAT filesystems to work around some FAT32 performance bottlenecks could also be implemented for the in-memory structures in a smarter FAT32 filesystem driver, while at the same time maintaining the unchanged structures on disk. Thereby, a "smarter" FAT32 driver could reach about the same performance as exFAT even in use cases where exFAT would otherwise have an edge, and without giving up backward compatibility with existing devices supporting FAT32. There are a few other neat exFAT features, such as a timestamp granularity of 10ms and UTC support, however, these features could be implemented in a minor revision of FAT32 as well - fully backwards compatible with the existing FAT32 design. So, the exFAT advantages exist mostly on paper and could just as well be achieved in the industry standard FAT32 filesystem without loosing compatibility.
The coupling with exFAT undermines SDXC's ambitions to become an universal exchange medium, and consumers buying products supporting no alternative flash card standards (such as CompactFlash) may be forced to switch and buy (newer versions of) Windows and possibly have to upgrade their PCs and peripherals as well, given that newer versions of Windows have higher hardware requirements and may no longer provide drivers to support older peripherals.
Most users are not aware of these implications, and unless the SDA or Microsoft change their policies in regard to this (which is unlikely to happen IMO), it does not give the users any real advantages but harms them by effectively costing them more money and giving them less flexibility. In my opinion, for the article to become more neutral and informative, these implications should be mentioned in the article in reasonable details. Potential implications could be discussed in a "controversy" section, as suggested by Spike, whereas the plain technical facts don't need to be limited to such a section IMO. They should be stated whereever we see best fit. --Matthiaspaul (talk) 00:02, 29 December 2011 (UTC)
Photo and Drawing Requests
Please upload YOUR personal photos and drawings to Wikimedia Commons, so we can use them in this article:
Please see (above) - just below the "cleanup banner" toward end of "too technical"topic - the second paragraph of my comments, where I have suggested certain types of photos. You could rephrase that (and more succinctly) in your list of requested photos. Especially for photos that show various size of cards, as well as for first photo of page, I think these would be helpful. --KnowLimits (talk) 21:38, 27 November 2011 (UTC)
If there is a question of rights, the photo (of a microSD used via four nested adapters) could be taken anew; only, we have no section on "Perverse things to do with SD adapters" in which to stick it. Spike-from-NH (talk) 14:36, 1 March 2012 (UTC)
Permanent write protect?
I've heard that when Bit 13 of the CSD is set an SDHC card becomes permanently read only with no possibility of unsetting the bit. Is this true or BS? Bizzybody (talk) 09:56, 11 March 2012 (UTC)
Yes; that bit is PERM_WRITE_PROTECT and is designated as "writable (once)." See SD v3.01 Simplified Physical Layer Sec. 5.3.2 (details beneath the table). The nearby TEMP_WRITE_PROTECT can be reversed. Do you think this warrants mention in the article (probably at the end of Sec. 2.1)? Spike-from-NH (talk) 12:26, 11 March 2012 (UTC)
Incomplete/Inconsistent/Confusing?
The article refers to four types of SD card:
SDSC, SDHC, SDXC and SDIO
However:
there is no section regarding SDSC, only the other three
while it states early on that SDHC are pre-formatted it is not clear whether they have to be formatted in FAT32 or what limitations apply to the other formats
later, in the middle of a highly technical section, the file systems on the cards are detailed.
May I suggest that
a section is added to detail the SDSC format
the basic information eg regarding partitioning and file type, be consolidated into the main headings describing each format
historical information is extracted to a separate section dealing with the development of the series as a whole
detailed electronic etc information is consolidated into the technical sections as currently
Agree that a "SD (SDSC)" section should be added above the SDHC section. I need to come back later and examine the article more closely and further comment. • Sbmeirow • Talk • 00:23, 24 May 2012 (UTC)
Contradictory
From the article:
Conversely, SDHC host devices will accept SDXC cards that follow Version 3.0, since the interface is identical,[3] but the following issues may affect usability:
Following the reference leads to a page which says this:
Only Use SDXC Memory Cards in SDXC Devices
The article seems to be saying the opposite of the source. However, I got here because of a discussion on a web forum where someone was able to use a SDXC card in a SDHC device, so I don't think this is just a case of misquoting the source. What's going on here? Ken Arromdee (talk) 20:10, 31 May 2012 (UTC)
We debated this section at length. (The debate is above, especially at #File system for SDXC.) The operative phrase is, "that follow Version 3.0" (that is: "that are formatted with FAT32"). My understanding is that you can plug an SDXC into an SDHC and it is perfectly usable as a block device. However, all SDXCs out-of-the-box come with exFAT and a typical SDHC host device will not be able to navigate it. The bullets set out under the statement you quote summarize this, as well as one other thing that could go wrong: You might not be able to use the SDXC in such a device at its highest speed because of the way new capabilities are encoded in the card. Spike-from-NH (talk) 20:48, 31 May 2012 (UTC)
But the source doesn't say that you can use it when it's formatted with FAT32. The source just says flat out that you can't use it. Whether the statement is true is beside the point when the source that is quoted doesn't actually support the statement. Shouldn't the source that is used support the statement? Ken Arromdee (talk) 15:15, 1 June 2012 (UTC)
Yes. It should. In my opinion, this was a good-faith effort to improve the article that strayed into WP:OR territory. There is a use for Original Research, but it is not to be used this way. What should happen is that someone who knows that you can use SDXC as SDHC if it is formatted with FAT32 uses that knowledge to try to find reliable sources that support that view, but not to put it into the article until those sources are found. It works the other way as well; if I as an engineer see something in an article that I know is wrong, I can't just use my expertise to edit the article, but I can take a close look at whether the statement is supported by the sources. Usually it isn't, and can be removed for that reason. --Guy Macon (talk)
All flavors of SD cards can be reformatted to any file system. Just because a SDSC / SDHC / SDXC ships with a default file system doesn't mean you have to stick with it. Likely the primary reason they make that statement is for electrical and protocol compatibility reasons. • Sbmeirow • Talk • 20:00, 1 June 2012 (UTC)
Though you can format it differently, some host devices may expect the default file system to match the SD type, so we should probably skip telling people. The most flexible operating systems let ya do what ya want. • Sbmeirow • Talk • 00:24, 2 June 2012 (UTC)
“×” rating
The table listing “×” ratings (which, remember, is an old metric) is getting out of hand and I have pared it back. A previous contributor created separate columns for read speed and write speed, though the text makes it clear that various vendors vary in their selection of speeds as a basis of measurement. Today Anon has expanded the table further, to go from "common ratings" apparently to all conceivable ratings. He has also inserted question marks after most of the measurements, which seem to call into question their usefulness and express an opinion of disapproval--but we already knew both things.
The table ought not be to tell the reader how fast their 120× card can perform, because we can't do that, but to give a small, representative list of old-style ratings, and relate them to the newer Speed Class, with the cautionary notes set out in the text.
Anon has also asserted measurement error in the table and the text, which I am not an expert on, and I did not post-edit him there. Spike-from-NH (talk)
Good job. You made a nice improvement to the article. The IP editor's measurement error correction looks OK. --Guy Macon (talk) 15:42, 28 June 2012 (UTC)
What sort of memory is it?
Nowhere in this article could I find the most fundamental information about SD cards: what memory they actually contain. The summary simply says they contain "Non-volatile memory" without any details at all, this seems like a massive omission! — Preceding unsigned comment added by 80.4.146.163 (talk) 17:24, 28 June 2012 (UTC)
In my opinion, it is to make you feel as though the device is keeping your work "secure" while in practice the device is keeping authors' works "secure" from you. Spike-from-NH (talk) 14:56, 15 April 2012 (UTC)
There are special secure commands to access optional encrypted data. This is a new feature compared to the MMC cards, which SD was derived. The commands are not publically documented, thus you have to pay to get the documentation. • Sbmeirow • Talk • 00:26, 24 May 2012 (UTC)
Is this the basis of the claim in the article that you can password protect an SD card? If so, this really should be spelled out clearly. At the moment, it comes across as though the ability to password-protect an SD card is a purchaser-level operation. Additionally, I've just spent several fruitless minutes on the SD official website and could find no mention of any password-protection feature. If what you are referring to is different, then what _is_ the section on password-protection basing its claim on? Edrarsoric (talk) 18:39, 5 July 2012 (UTC)
The ability to password-protect a card and to render it read-only are indeed user options that are described in the referenced 3.0 specification. I am not surprised that this feature is not touted on the SDA website. The Digital Rights Management protection is completely separate and is not described anywhere in the specification. Spike-from-NH (talk)
UDF formatting?
The article says "Any recent version of the above can format SD cards using the UDF file system." I just tried Windows 7 HP SP1 and it does not offer UDF when formatting an SD card. I guess it is a case of "citation needed" ?
--Xerces8 (talk) 22:09, 25 October 2012 (UTC)
A device that's SDHC compatible, though manufacturer claims not
The GPX MW3836 (with SUFFIX NO: E1 label) MP3 player is able to read/write up to at least 4GB SDHC even though GPX claims is can only use up to 1GB standard SD cards. That gives this cheap $20 player 5GB of storage. :) I've a Lexar 4GB SDHC in mine. It'd be nice to see a site off-Wikipedia with a list of specific devices that support SDHC though they officially don't.
It's not that the manufacturer has claimed anything. It is often the case that the manufacturer has not been able to test his product with the larger cards simply because they were not available prior to the product's release. For example the Panasonic HDC-SD1 camcorder Operating Instructions lists the cards that can be used. Although, the reader might infer from the text that 4GB is the largest SDHC card that can be used, it doesn't actually say so. 4GB was certainly the largest card available when the camera was released. In fact the camera operates perfectly with 8GB, 16GB and 32GB SDHC cards. 86.173.174.62 (talk) 17:00, 19 March 2011 (UTC)
Also the specifications on a manufacturers website / user manual / software might not all be in sync with each other. I've noticed numerous websites and online user manuals not matching the latest revision of software. • Sbmeirow • Talk • 05:56, 22 March 2011 (UTC)
I've tested that GPX player with an 8 gig card, works fine. Too bad it's a discontinued model. The cheap players GPX makes now have no card slot. Bizzybody (talk) 09:50, 11 March 2012 (UTC)
It quite often happens that devices support things that their manufacturers don't claim (including things available at the time). The claim is basically "we have tried this and pretty much guarantee that it works. If you try anything else, great, but don't come whining to us". I have plenty of devices that accept larger SD or Micro SD cards than claimed, larger laptop and desktop computer RAM than claimed, and so on. Lots of Windows XP computers that "don't" support Windows 7, do. Asus motherboards for AMD processors generally support and make use of ECC memory, though memory manufacturers don't list this. Of course, you may run into trouble when 8GB model xyz works and you buy 8GB model zyx, which doesn't. I've found a Google search like <Inspiron 1501 4GB> to be useful. Pol098 (talk) 15:24, 31 December 2012 (UTC)
Speed in practice
I added text:
The speed class rating does not totally characterize card performance. Different cards of the same class may vary considerably while meeting class specifications. In addition, speed may vary markedly between writing a large amount of data to a single file (sequential access, as when a digital camera records large photographs or videos) and writing a large number of small files (a random-access use common in smartphones). One study found that, in this random-access use, some Class 2 cards achieved a write speed of 1.38Mb/sec, while all cards tested of Class 6 or greater, including those from major manufacturers, were over 100 times slower.
Some Original Research: I tested two 8GB Micro SDHC cards, including one from a manufacturer supporting small files well, and another (which had been my preferred choice before checking sources) from a manufacturer with a good reputation. The first card with CrystalDiskMark got a 4kB file writing speed of well over 1MB/s (I didn't write it down unfortunately), the other 0.007MB/s (decimal point, 2 zeros, 7, no typo). While photographs and video recordings are a different matter, for general-purpose mobile phone and similar use, handling small files well is important, particularly if running programs off the card. Pol098 (talk) 15:36, 31 December 2012 (UTC)
I see that you also gave us a very nice citation for the text you entered. Good work! I do the same thing, BTW; I do original research in my lab, and once I find out what the reality is, I start looking for reliable sources that found the same thing. OR is no good for writing the article, but very good for guiding me as to where to look.
I tried to calculate the ratio of the write speed of a SD card to the write speed of a CD-ROM, but my darn calculator keeps giving me a divide by zero error... <smile> --Guy Macon (talk) 06:54, 1 January 2013 (UTC)
Lots of subtleties here concerning how different SD cards are designed and whether the devices they plug into keep them powered up, let them go to sleep automatically, put them in sleep mode, up pull the plug and shut off the power to the card. for example:
I think that the best we can do is to simply say that power consumption varies widely between different cards and between different devices the cards plug into. Either that or give power consumption of SD cards a separate article and try to cover all the variables. --Guy Macon (talk) 22:51, 1 January 2013 (UTC)
I don't know enough about the variations. I'd always assumed that, whether actually put to sleep or not, the power drawn by an SD card was much less when no data transfer was taking place (the basic idea behind non-volatile memory); the references above essentially support this. Reading the article text as it was a few days ago gave the impression that some SD cards could be drawing a steady 100mA, which seems badly wrong. The essential practical point is that putting an SD card in a telephone waiting for calls shouldn't significantly decrease battery life if the card isn't transferring much data. That's my understanding, but I don't have the breadth of knowledge to say and source much more than I have in the article. My intention in quoting the figure of 200μA was simply to say that quiescent current of an SD card is small, negligibly so for many purposes. Pol098 (talk) 22:26, 2 January 2013 (UTC)
We know there isn't a big problem with SD cards and phones, because if there were we would see a thousand websites talking about which cards to avoid. Whether this is because the cards have a low drain while sleeping or because the phone powers them down except when storing a new number (reading from a copy in RAM) I don't know, but the engineers who design the phones are not stupid.
I also know from a bit of original research that at least one brand of AC-mains operated industrial equipment constantly reads from the SD card, and thus in that application it draws a lot more current -- for a SD card. The same equipment was driving a 5HP electric motor and a 1500 watt heater, so it's all relative. --Guy Macon (talk) 22:37, 2 January 2013 (UTC)
Envision wording
To pick a nit on a separate editing issue: "envisage" is the British rendition of "envision". As this article uses American grammar, the latter is appropriate and the recent edits are good. Spike-from-NH (talk) 14:23, 9 January 2013 (UTC)
In the USA, I've never used the word "envisage", but I have used "envision". You are more elegant wordsmith than me, so I can't comment. • Sbmeirow • Talk • 21:39, 9 January 2013 (UTC)
^Techgage review, including an OCZ 4 GBan OCZ 4 GB SD (non-SDHC) card
Done