SD Card Tests with and without M9

[Robert_M]

Advertisement (gone after registration)

I apologize for starting a new thread but I think my reasons are valid. I've done extensive testing of SD cards over the last few days, both with and without going through the M9. In the end, I believe I can point to definitive evidence of an M9 problem and where it is. But I'll make the reader patiently read through a post or two first before getting to the punch line. (No, I really don't have aspirations to be a mystery novelist but I do enjoy a good read ).

 

My reasons for a new thread are:

1) The main post on this problem is now 778 posts long and some of the lazy readers of this forum have expressed that they don't want to read all that. So I'll make it easy.

2) The big thread has evolved into an argument between a couple factions. As one member put it recently "To be honest, I am giving up trying to prove anything to anyone in this thread anymore, it is futile and a complete waste of energy. I'll leave them to drink the Kool-Aid." I think he may have a point.

3) I believe I have relevant real data to present here and don't want to bury it in that long post.

 

So enough of the commentary, I'll stick to the factual presentation.....

I have a fairly large collection of SD cards since I tend to use them for other temporary storage needs, not just camera needs. I figure, it is more useful to buy SD cards and use them as USB drives when necessary rather than just buy SD cards for cameras, and USB thumb drives separately. Anyway, you get the idea. So I went about systematically testing all the cards I had available (excluding some I didn't want to erase the contents) and see how they measure up to spec and if they had any evidence of the phantom, highly rumored, cause of all evil "fake card". (excuse my sarcasm, I'll try to stick to the facts...).

 

Using a laptop PC running Windows XP, I used the program h2testw_1.4 to test the cards. As I pointed out in another thread, this program tests for read speed, write speed, memory errors, and false claims of performance (ie false card size claims). One can do a web search and find this program for free download. I highly recommend this program as a diagnostic tool which is simple to use.

 

Just for reference, ALL the cards I've purchased and tested were acquired from highly reliable retailers. They are all retailers who would be purchasing directly from the manufacturer. There is no reason to doubt the origins of the cards. The cards were purchased at various times from about 2006 to the present. A couple of the cards are old enough that they don't even mark the speed rating. A couple are less than 1 month old. All cards were SDHC except for the 2 SD cards noted in the comments.

 

In the jpg below, I've summarized the results of the read write tests. In all cases, the cards the cards had the full memory size expected and had no errors in read or write.

 

Conclusions: All cards met or exceeded their marked specification. There is no evidence of anything other than what they claim to be. You will note that SD manufacturers advertise non-industry standard speeds, such as "up to 15MB/s speed". In all cases, these claims are overblown and only apply to the optimal read (not write) speeds. I refer the reader to do a wikipedia search for a more extensive article on these standards and advertising claims.

 

I also note that SanDisk used to vastly exceed their specifications during the Ultra II era. Their current Ultra cards still well exceed the spec but not by as much.

 

In short, there is no evidence that these are nothing but legit cards which conforms properly to any advertised specification. BTW, it was card # 12, 13, and 15 on this list which caused me an anomalous event. Cards #5, 6, and 14 I have not yet tried in the M9.

 

I expect that others who do a similar analysis of cards from big retailers will find the similar results. There is nothing unusual about my findings.

 

RM

Welcome, dear visitor! As registered member you'd see an image here…

Simply register for free here – We are always happy to welcome new members!

[Advertisement]

The Leica Q3 is available for pre-order at B&H Photo Video and Adorama

[Robert_M]

I should have noted in the last post that the SD cards were read directly in a SD card reader which was part of the laptop computer. I did not use an external card reader. I don't expect that makes a difference.

 

Now, having done those tests, I naturally was curious about the read/write speed of the M9 itself. So, I decided to test a couple of the cards in the same way but with them mounted in the M9. I put the M9 in mass storage read mode for the USB. This mode is common for most all devices that use SD cards. In this mode, the device acts like a USB drive so the only thing the device (M9 in this case) is doing is handling the read/write interface with the SD card. My purpose was to establish the read/write speed of the M9 as it handles the SD card. This should be a spec which is available and known, but I've never seen it.

 

Well, to my surprise, I did not find it possible to completely write to the full card. I tried several times with a couple of cards. The M9 always got hung up near the end of the write operation (when the card is almost full). In one case, it got hung up early on.

 

The jpg below summarizes the original SD-to-computer read/write results for two cards listed earlier and then the results for the same cards going through the M9. For one of the cards, I tried it both as a FAT32 format and FAT (or FAT16) format since it is an older SD card.

 

BTW, the cards were tried both formatted in the computer and formatted in the M9. This should no make a difference in any case (and did not). For those interested, the M9 will only format the card as FAT32. If you put in the old FAT standard SD card and format in the M9, it will change the format to FAT32. Also, be aware that formatting in any device (computer or camera) only clears the FAT (file allocation table) and gives it a device/volume name. Only those tedious overwrite/full format modes actually write to and clear memory locations.

 

And, in case someone asks, I did this with a full battery and didn't touch any other buttons.

 

Conclusions:

 

I conclude that this data strongly indicates that there is some problem/error in the interface in the M9 between the SD card and the camera memory. There is a handshake problem in the protocol or something funny going on with the way the M9 uses the FAT32 table.

 

AND, I now conclude that it doesn't matter what other button punching goes on. Well, that may exacerbate the problem and provoke the symptom. But the heart of the problem lies in the interface between the M9 and the SD card slot. This is properly called firmware. (One should go read a dictionary or a wikipedia article to understand the clear distinctions between software, firmware and hardware. This is admittedly subtle and hard to interpret at times.)

 

Finally, I conclude that the M9 writes at roughly 4 MB/s and reads at 6 MB/s. So, buying faster cards won't speed up your picture acquisition speed but it will help your downloading to a computer later if you use the card directly in the computer and not the USB port to the M9. But others have already concluded this. I have just quantified what that write speed limit is (I think).

 

 

Challenge:

 

OK, now I expect the usual "your M9 is different than mine" response. But before anyone says that, I issue the challenge that they try the same test. Simply run the H2testw_1.4 program through the M9 to the SD card in the camera. If they are able to complete the write test fully, I'll concede defeat.... But until then, don't tell me I have an anomalous M9. I have seen no evidence that I have anything but an ordinary M9 production model.

 

If I haven't made the test clear, please let me know and I'll list step by step procedure.

 

 

Hope this give the reader something to chew on.

 

RM

Welcome, dear visitor! As registered member you'd see an image here…

Simply register for free here – We are always happy to welcome new members!

[Robert_M]

And, for further detail, I'll post the error response from the h2testw_1.4 program for the sequence of failures to write to the SD card. First, #7a in the above list. I've cut/pasted together the responses with my comments in between:

 

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

First testing the write mode and it stops near the max

memory size

 

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

 

Error writing file 'E:\2.h2w', offset 0x38a00000.

It is still possible to verify the test data written up to this point.

(The semaphore timeout period has expired. Code 121)

Writing speed: 4.05 MByte/s

H2testw v1.4

 

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

 

repowered the M9 and then did the read

 

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

 

 

Warning: Only 1930 of 1934 MByte tested.

Test finished without errors.

Reading speed: 6.13 MByte/s

H2testw v1.4

 

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

 

Read OK. Tried the write again.

Same write error.

 

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

 

Error writing file 'E:\1.h2w', offset 0x8a00000.

It is still possible to verify the test data written up to this point.

(The semaphore timeout period has expired. Code 121)

Writing speed: 3.86 MByte/s

H2testw v1.4

 

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

 

Try write test again. Same result.

 

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

 

Error writing file 'E:\1.h2w', offset 0x8a00000.

It is still possible to verify the test data written up to this point.

(The semaphore timeout period has expired. Code 121)

Writing speed: 3.86 MByte/s

H2testw v1.4

 

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

 

Redo read test and all OK.

 

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

 

Warning: Only 1913 of 1934 MByte tested.

Test finished without errors.

Reading speed: 6.12 MByte/s

H2testw v1.4

 

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

 

 

And, here are the log responses from item #9a in the above list (fewer comments this time).

 

 

 

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

 

Error writing file 'E:\4.h2w', offset 0x1700000.

It is still possible to verify the test data written up to this point.

(The semaphore timeout period has expired. Code 121)

Writing speed: 4.11 MByte/s

H2testw v1.4

 

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

 

Warning: Only 3095 of 3874 MByte tested.

Test finished without errors.

Reading speed: 6.12 MByte/s

H2testw v1.4

 

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

 

Error writing file 'E:\4.h2w', offset 0x31700000.

It is still possible to verify the test data written up to this point.

(The semaphore timeout period has expired. Code 121)

Writing speed: 3.95 MByte/s

H2testw v1.4

 

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

 

Warning: Only 3863 of 3874 MByte tested.

Test finished without errors.

Reading speed: 6.17 MByte/s

H2testw v1.4

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

 

 

One should note the error code in the log. Perhaps another computer nerd will be able to identify what that means?

 

RM

[scrubs]

Thank you Robert, For an excellent informative post and great timing too -

as you posted this I was currently sat with stop watch in hand working out

write speed differences in Luddite fashion and concluded that my £4

Generic 4MB/S card was no faster in camera than my Sandisk extreme.

So I will be saving money there in future...

 

When this is indeed the case - Leicas statement in their FAQ serves to confuse me:

 

Which types of memory cards will work with my LEICA M9?

...The M9's performance is very much based on the card's speed. Therefore,

we suggest using the faster types on the list below ...

 

It leaves me curious to know why they recommend this when such a bottle

neck/limitation is in place...

 

Thanks again for the effort and time you have put into this, I hope someone can

shed some light on those error codes. Great work.

[k-hawinkler]

Hi Robert,

 

This is the best way to check out these aspects of the M9 - mount via USB connection Mass storage. I did the same when checking out formatting differences http://www.l-camera-forum.com/leica-forum/leica-m9-forum/192294-m9-mac-memory-card-formatting-differences.html. After all with regards to USB, SD, SDHC the M9 is merely a bloody computer.

 

Thanks for the progress. Please, let the facts speak for themselves.

Folks are entitled to their opinions but not their facts.

 

Question: What happens if you write the memory card in the M9 only to 70%, 80%, 90% nominal capacity?

Best, K-H.

[k-hawinkler]

Hi Robert,

 

The beauty of your tests is that they show an apparent repeatable firmware bug.

Of course, it's the way to go for an initial checkout of M9 and memory cards.

 

Unfortunately the M9 also has other failures modes of an intermittent nature.

Those require an additional different kind of approach, namely actually being used to take pictures

with parameter settings that seem to have a much higher probability of failure.

 

Thanks again for your excellent demonstration.

 

Best, K-H.

[Robert_M]

Advertisement (gone after registration)

Hi Robert,

 

The beauty of your tests is that they show an apparent repeatable firmware bug.

Of course, it's the way to go for an initial checkout of M9 and memory cards.

 

Unfortunately the M9 also has other failures modes of an intermittent nature.

Those require an additional different kind of approach, namely actually being used to take pictures

with parameter settings that seem to have a much higher probability of failure.

 

Thanks again for your excellent demonstration.

 

Best, K-H.

 

K-H,

I'm not so convinced that there are other, independent failure modes. I can hypothesize (but NOT prove) that the failures are all related to the SD card-to-camera interface (firmware). The other actions could indeed exacerbate the situation. After all, the camera is a multitasking device in the electronics/firmware. It could also just be coincidence? Anyway, I'll maintain a open mind about issues but keep looking for logical facts to back up statements. Onward....

 

RM

[k-hawinkler]

K-H,

I'm not so convinced that there are other, independent failure modes. I can hypothesize (but NOT prove) that the failures are all related to the SD card-to-camera interface (firmware). The other actions could indeed exacerbate the situation. After all, the camera is a multitasking device in the electronics/firmware. It could also just be coincidence? Anyway, I'll maintain a open mind about issues but keep looking for logical facts to back up statements. Onward....

 

RM

 

 

RM,

 

Exacerbation is good enough for me. The fact is if I use the M9 with S, compressed DNG, and manually switching on or off with an empty card and full battery it behaves seemingly solid.

 

However, if I save DNG + JPG fine, and chimp while images are being saved I get intermittent failures, lockup of the entire camera etc. This behavior would indicate to me that additional factors might be in play.

 

Anyway. Thanks.

 

Best, K-H.

[Robert_M]

OK, I'm fresh after some morning coffee. I'll make another (too) long post here which again points directly at the SD card interface in the M9 as the problem. But to explain this evidence, I must first outline for the reader how the M9 records the image.

 

1) The Kodak ccd captures the image and the data is read out from the ccd chip in 2 halves (to speed up the readout time). The interface line is right down the middle of the image (left and right are independently readout). If there is a readout problem, one will see some artifact related to this symmetry. Indeed, there are postings on this forum which have shown this symptom when it (rarely) occurs.

 

2) After readout, there is minimal processing in the M9 by a DSP. Most importantly, the DSP adjusts the readout amp gain, and then stores the digital output of the ADC. The dynamic range of the Kodak ccd is over 70 dB, judging from the spec sheets of similar devices on the Kodak web site. If I recall right, the dynamic range of a 14bit ADC (used in the M9) is 42 dB. Yes, it is possible to get 16 bit and higher ADCs but they are slower for readout. The user's ISO setting is what determines the amp gain used on the image readout. In addition, the DSP adds EXIF information, does some minimal correction depending on the lens detection reading, etc. At this point, we have a DNG file with a jpg preview in a file sitting in the camera buffer.

 

3) Finally, the image file in the buffer is written to the SD card via the SD card interface. It is important to note that this writing of the image now has a consistent pixel order (from top to bottom, left to right, I believe). Thus, errors in the image writing to the card will look very different than errors from the ccd readout. Again, there have been posts on this forum which show such problems. Typically, it is horizontal lines or the bottom of the image corrupted.

 

 

OK, enough of that; now some data:

At one of my SD card/M9 write fail incidents I ended up with a corrupted file. I could see the image in the camera preview (since the camera is apparently just looking at an imbedded jpg preview). But I could not copy or read the file in a windows pc with the normal copy. I used the standard file reading utilities in Ubuntu (Linux) OS to read the file, and those utility programs could detected (and corrected) some of the corruption in the file while copying. Going back to windows xp OS, the file could now be handled by the OS, however Lightroom still did not want to read nor process it. Fortunately, I could process it with the PWP 5.0 (Picture Window Pro) program. BTW, I use the camera in DNG only (not compressed) mode for the images.

 

The resulting retrieved image is shown below. You will note that the bottom half of the photo is corrupted. It is clear to me that in this incidence, the M9 developed a SD card write fault most of the way through writing this file. The SD card was close to full in this case, BTW. Any other kind of fault that I can think of would not show up in this sort of image.

 

Let me emphasize that these faults have been extremely RARE for me. Thus, it is very hard to document the image evidence which points to select issues. Another time this happened to me, I didn't get any file (just a 0 size file which truly did not contain any data). So I count this episode as very useful data in pointing to the problem.

 

I conclude the same as before: The SD card problem is at the SD card to M9 interface!

 

 

RM

Welcome, dear visitor! As registered member you'd see an image here…

Simply register for free here – We are always happy to welcome new members!

[andybarton]

However, if I save DNG + JPG fine, and chimp while images are being saved I get intermittent failures, lockup of the entire camera etc. This behavior would indicate to me that additional factors might be in play.

 

 

Isn't this a bit like banging your head against a brick wall? If you stop doing it, you will stop getting a sore head.

 

It is well known that the CPU and transfer rates of images from buffer to card in an M9 (and M8) are not the quickest. If you continually have a problem when you chimp images while the CPU is trying to write remaining files from the buffer to the card, why not just accept the limitations of the hardware (and firmware) and stop chimping so quickly? Do you really need to chimp while writing others from a sequence of "burst" shots?

 

I really am at a bit of a loss here.

[k-hawinkler]

RM.

 

Many thanks indeed. Let's assume you are correct.

How can we check out whether there are exacerbating contributing factors?

 

Best, K-H.

[john_newell]

I conclude the same as before: The SD card problem is at the SD card to M9 interface!

Fascinating, in a bad way. Do you really mean in the physical interface, or do you mean in some part of the process of reading data from the card that would be influenced by the camera's firmware?

 

If the former, exact card physical and/or electrical specs could be a factor? Even, possibly, sample variation from a single model card from a single manufacturer?

[k-hawinkler]

Isn't this a bit like banging your head against a brick wall? If you stop doing it, you will stop getting a sore head.

 

It is well known that the CPU and transfer rates of images from buffer to card in an M9 (and M8) are not the quickest. If you continually have a problem when you chimp images while the CPU is trying to write remaining files from the buffer to the card, why not just accept the limitations of the hardware (and firmware) and stop chimping so quickly? Do you really need to chimp while writing others from a sequence of "burst" shots?

 

I really am at a bit of a loss here.

 

 

Andy,

 

I will answer you just this one more time, understood?

You seem to be a very reasonable fellow most of the time.

 

If I want to just take pictures with the M9 I operate it in the most prudent way very successfully. Thank you.

However, what we are trying to do here is debugging a device with firmware problems.

 

If you want to contribute to this discussion in a meaningful way, please read some of the other threads from the beginning carefully. You might learn something.

 

Best, K-H.

[andybarton]

Please don't patronise me.

 

That wasn't clear to me. I thought that it was Robert who was doing the de-bugging and you were commenting that when you do certain things with your camera, it breaks down. The implication, as I read it, was that you did this regularly.

 

I apologise for not understanding what you were doing and I also apologise for only a being a very reasonable fellow most of the time. I will have to try much harder than I do now.

 

I will leave you to it and wish you well. As I have said before, it does seem to affect only a very small number of users, so you may have a long job on your hands.

[k-hawinkler]

Please don't patronise me.

 

That wasn't clear to me. I thought that it was Robert who was doing the de-bugging and you were commenting that when you do certain things with your camera, it breaks down. The implication, as I read it, was that you did this regularly.

 

I apologise for not understanding what you were doing and I also apologise for only a being a very reasonable fellow most of the time. I will have to try much harder than I do now.

 

I will leave you to it and wish you well. As I have said before, it does seem to affect only a very small number of users, so you may have a long job on your hands.

 

 

Andy,

 

Thanks. I apologize for coming on a bit too strong. Sorry about that.

 

Best, K-H.

[mjm6]

Robert,

 

Excellent work, and I appreciate that it must have taken a long time to compile.

 

In the spirit of getting to the bottom of these problem(s), is it possible that there is more trouble than just the one card write issue that you have (possibly) identified? The reason I ask is we have (had) a list of 'good' cards that Leica put out when the camera was new. We know that this list is now suspect as things have changed over the two years...

 

What variable in the specifications of these various 'good' and 'not good' cards is causing problems, and is there a way you can postulate that the specifications of the various cards interface with the write problem to make some of them more susceptible than others? It seems that if this is a general write problem, all cards should be hung with the problem, not just certain cards.

 

 

---Michael

[Robert_M]

I have been informed (more recently than my doing these tests) from a reliable source (who shall remain anonymous) that more than one department of Leica have recognized the problem and are working with Sandisk and Jenoptic to diagnose the problem. I'm told that they are focusing their efforts on the interface between the SD card and the camera electronics.

 

I feel that this information validates my tests and conclusions. I only wish that Leica had hired me as a high paid consultant to do debugging for them.

 

At this point, I find it less productive to just poke away at the device looking for other issues and avenues. It would be better to encourage Leica and offer help to them if they wish. I really wish they would be more open and informative. Some of us would be happy to help and are not about complaining as a hobby. I don't really know how to contact them directly (and I don't mean the usual customer service route). If anyone has ideas, speak up.

 

RM

[Robert_M]

Robert,

 

Excellent work, and I appreciate that it must have taken a long time to compile.

 

In the spirit of getting to the bottom of these problem(s), is it possible that there is more trouble than just the one card write issue that you have (possibly) identified? The reason I ask is we have (had) a list of 'good' cards that Leica put out when the camera was new. We know that this list is now suspect as things have changed over the two years...

 

What variable in the specifications of these various 'good' and 'not good' cards is causing problems, and is there a way you can postulate that the specifications of the various cards interface with the write problem to make some of them more susceptible than others? It seems that if this is a general write problem, all cards should be hung with the problem, not just certain cards.

 

 

---Michael

 

 

Yes, this does take a long time. I probably put in more than a man-day of work on this testing alone.

 

Yes, I understand your point in asking if some cards are ok and others not. One can play more to test cards. When I get some more time, I'll test another card on their list. I believe that one of the tested cards (#9) is indeed on their list (and is an Ultra II production form the same epoch as the Leica list). For the in camera tests, I picked some smaller cards. At 4MB/s write speed, it does take awhile if you want to try big cards (ie 1000sec for 4 GB).

 

RM

[Advertisement]

Hallo,

Look here: Leica M

[k-hawinkler]

I have been informed (more recently than my doing these tests) from a reliable source (who shall remain anonymous) that more than one department of Leica have recognized the problem and are working with Sandisk and Jenoptic to diagnose the problem. I'm told that they are focusing their efforts on the interface between the SD card and the camera electronics.

 

I feel that this information validates my tests and conclusions. I only wish that Leica had hired me as a high paid consultant to do debugging for them.

 

At this point, I find it less productive to just poke away at the device looking for other issues and avenues. It would be better to encourage Leica and offer help to them if they wish. I really wish they would be more open and informative. Some of us would be happy to help and are not about complaining as a hobby. I don't really know how to contact them directly (and I don't mean the usual customer service route). If anyone has ideas, speak up.

 

RM

 

 

Hi RM,

 

Excellent work and thanks for the extra information as well.

Aside from testing more cards in the M9, is there anything else you would recommend we collectively should do at this time?

A short No or Yes as an answer is fine. If Yes, what is it?

 

Best, K-H.

[t024484]

Robert,

 

A small side comment on your earlier posting.

The M8 and the M9 have both the same speed limit of 2 pictures/second.

The M8 Sensor is well documented and has two simultaneous outputs to transfer pixels.

 

The M9 sensor has physically the same pixels, only much more of them, almost twice as much.

Since it is not possible to read out pixels twice as fast, it can only be achieved by having 4 output channels instead of 2. So the frame is not divided in 2 but in 4 parts.

 

But since the whole picture is processed inside the camera before anything else, I think that SD card problems cannot reflect any of this internal subdivision and that "one will see some artifact related to this symmetry" is not related to this.

 

The prove that the picture is completely processed inside the camera before writing to the SD card lies to my opinion in the fact that you can shoot a number of pictures without an SD card. When the SD card is inserted in a later stage, everything is nicely written to the SD card.

 

Hans