Flash memory dies and the data logging DMM with it ???

[Kiriakos-GR]

I am trying to calm down by reading this piss poor review saying that ... No no read it all ..

http://www.amazon.com/Agilent-U1272A-Handheld-Counts-True/dp/B004URG9EU/ref=cm_cr_pr_product_top

And reply with your comments about the Flash memory comment. 
I am a piss poor electrician, I am expecting comments from serious EE to solve the puzzle. 

[ejeffrey]

That sounds like a made-up complaint to me.  First off, even the reviewer doesn't claim that memory memory failure prevents the meter from operating as a meter.  To do so would require someone to observe memory failure.  Second, the memory is not even necessarily flash.  It could be battery backed SRAM with a lithium coin cell or even a capacitor to keep power while changing the battery, or it could be an EEPROM.

SRAM lasts forever.  Industrial flash and EEPROMS both have limited write number of write cycles, but it is over 1e6, and often much more.  I can't really see how you would ever reach that limit even under extraordinary use -- To reach that in 20 years you have to be filling up the log every 10 minutes.  24/7.  That isn't really practical with a battery powered hand-held meter.

These concerns apply to any logging DMM with the NV ram.  Unless there is some specific design flaw in the agilent (there could be, but this appears to be only speculation on the part of that reviewer) there is no problem here at all.

[Alex]

Kyriako, "Tzetzeris rolled about and found the cap". 

I guess you found your Nemesis.

Anyway, Flash memory has a limited write endurance in the 100k cycles ballpark depending on subtechnology. In the functionality within a logging DMM other components will fail first. If it was used as say a scratchpad memory for firmware execution the it would fail within hours. But it is not; it is used for storage.
 

[Kiriakos-GR]

Kyriako, "Tzetzeris rolled about and found the cap". 

The truth is that something had hit me, and I believe that it was the  "Tzetzeris "  ( large cooking pot)

Speaking about memory, every DMM with the Min-Max function it does a heavy use of reading and writing in the interval of 250mS,
due the collection of all those samples, and there is no any written limitation about for how many hours you will have the Min-Max active.

When you use PEAK ( or Min-Max-PEAK by the Fluke book), the samples is taken at 1mS = a more faster rate = more heavy workload.
According some tests of my, when such modes become active the DMM consumes the batteries more aggressively than in any other function.

Even today not even one DMM died as far I know from a such a reason.
Not to say that with the current technology we have advanced memory modules with amazing capabilities.
We have end up to have today, even Solid state disks. 

And speaking about the data logging memory that probably is the storage, the writing rate of 1 recording per second,
how in earth it can effect the lifespan ?

Flash memory has a limited write endurance in the 100k cycles ballpark depending on subtechnology

   
100k = 100.000 cycles.

If I do 100.000 data logging sessions and charge 1$ per its one, I will gain 100.000$ before my HH dies.
In this case I do not care..     
 

[Alex]

For min/max averaging, peak and other similar functions I would expect a memory closer to the MCU being used, possibly part of the SRAM on board the MCU.

The endurance figure is the mean lifetime for each memory cell (or block). You would have to write a cell (or block) 100k times to kill it. But since this is the mean of a standard deviation, you can get cells (or blocks) that die sooner and other die-hard cells.

Techniques such as dynamic mapping of the data on cells with fewer read/write cycles and of course error correction can also be used.

Have a look at the capacity of your pen drive, note it down. Use it for a year and check it again. You will notice that it is less.

If I do 100.000 data logging sessions and charge 1$ per its one, I will gain 100.000$ before my HH dies.
In this case I do not care..   

 

To do 100k sessions you would need a lot of batteries. You will also need to eat, pay rent and bills, possibly petrol to get to the place where you will do the data logging. All of this cost money, so unless you start charging much more per session you will have a loss.   "This is not a business for me -I'm out!" Now...if you ask for a new DMM for each session then you will probably make a profit! 

[ejeffrey]

min/max and peak hold use normal RAM to hold the results.  This has no write cycle limit.  Flash /EEPROM is only used for data logging, and maybe storing some configuration settings that need to be preserved when the power is off.   These uses will not exceed their wear limits under any normal or even abnormal usage.

[Kiriakos-GR]

Thanks for the information people, I do appreciate it. 

I believe that all those  PDA GPS , they use identical technology too as storage.
My HP iPAQ rx5915 Travel Companion, an 500$ worth GPS PDA ( or was worth) uses  2GB internal Flash /EEPROM.
The specific model was made for the American market so to have enough storage for the local maps.
I deleted those files, and gained the free space as storage for other files.

And the bottom line is that if all those PDA GPS devices can make it, about handling the usage of reading maps / MP3 / movies etc etc.
The hand held  DMM haves nothing to fear.

Not even my ancient Smart media cards of my Olympus digital Camera had not even fail on my hands ( I am gentle to them ),
that is a 12 years old or more  technology.
And by mainly using my first Smart media card 128MB since 2001 until today , I had take 10.000 pictures or more.



 

[patb]

Have a look at the capacity of your pen drive, note it down. Use it for a year and check it again. You will notice that it is less.

Alex, could you elaborate regarding this behavior. I use pen drives regularly and never seen "auto-magically" reduced capacity.

[Kiriakos-GR]

I think that he is referring about automatic mapping of bad blocks.

I have see the USB controller of a pen drive to short and kill the USB port of my MB.
But never see any bad blocks, I do not use pen drives that much. 

[patb]

I think that he is referring about automatic mapping of bad blocks.

I don't see any way that this could work automatically. Sure, you can get bad sectors on any drive (including flash drives), but you would notice it by getting read or write error(s). It is the file-system driver that reports capacity and free space of a drive (for end user), not the USB drive itself. And the FS driver works on higher level than the drive. AFAIK there is no way the drive can tell FS - hey, let's reduce the size of me, because I think some of my cells are damaged. It can only go the opposite way - FS asks drive for physical data and drive may respond - oups, something is wrong - mark that sector as "bad". So I think that the only way to reduce the usable capacity of a drive is by getting bad sectors (or of course writing files ). It is also possible and common that various applications create hidden files or even directories on a drive - then it appears to the end user as a reduced free space. After you format that drive you should get the original capacity minus bad sectors. I am 99% sure that it works that way.

[ejeffrey]

All of the wear leveling and bad sector remapping that goes on in flash drives is behind the scenes, handled by the flash controller.  The drive has a bit of extra capacity (in the 20% range, depends on the drive) above and beyond the capacity reported to the host computer.  Every time you write to a block, the flash controller has the option to remap that to a new physical location on the drive, and move the original block to the spares list.  This spreads out the wear so that if you write the same file over, you actually write to many physical locations only a few times each.  When a given block starts to wear out, the flash controller will stop using it altogether.  When the number of spare blocks drops below a certain level, the drive becomes essentially useless.

In any case, the reported total size should not change over the life of the drive.  In principle it is possible, and some solid-state drives may allow you to reformat and get a new slightly reduced capacity, but this doesn't happen under normal use, never happens to USB flash drives that I know of, and isn't really standard.

Most flash failures occur during writes.  The amount of time needed to erase and write a block increases with the number of times it has been erased.  When the write time gets to a given threshold, the controller decides that the block is dead.  You should never see IO errors from this type of failure, as the drive should automatically redirect the 'write' request to a new block with no loss of data.  It is possible to have failures triggered by reads (block was written OK, read OK once, fails the second time) or by writes to an adjacent block.  In these cases you will get an IO error as there is data loss.  The OS may mark that block as bad, and stop using it, although that is not really helpful or necessary: writing data to that block will cause the firmware to remap it to a new physical location and mark the damaged block as defective.

The important thing to keep in mind is that the virtual block address seen by the host computer is not really related to the physical block address at all.

All of this only applies to large NAND flash drives like SD/compact flash, USB pen drives, and SATA solid state drives that are designed to hold a general purpose filesystem.   Small embedded chunks of flash typically do not work like this at all.  They are generally designed either to be occasionally written serially all at once, like the program memory in a microcontroller or the separate boot firmware on a PC or embedded device, or used in a log fasion where they are written a few bytes at a time in a circular fashion (this would be my guess for how the logging meters work).  In some cases, they will use a special filesystem called a logging filesystem that is specifically designed for flash drives and writes in a logging format (beginning to end) while providing a more standard filesystem interface, usually at a considerable speed penalty (which is OK as these devices are usually very small: a few MB at most).  In any case, these embedded devices typically do not have to provide a full filesystem compatibility, and naturally spread the wear over the whole drive, so the flash controllers don't have to do this.

[patb]

ejeffrey, your explanation is extactly how I see it. I only wonder if simple flash cards (SD, CF etc) have all those reserved sectors for spare blocks. For SSDs this is out of the question, because they contain advanced flash controllers esp. designed to handle file systems. But is it also the case with flash cards and cheap pen drives? I really don't know.

Anyway, designing effective SSD controller must be a really challenging task. And interesting. For example - a question: where do SSD controllers store mappings of blocks to logical sectors? Is it on the same flash chips where the data is stored or maybe in some other memory (built-in maybe?). This is really interesting stuff where hardware meets software.

[Wartex]

ejeffrey, your explanation is extactly how I see it. I only wonder if simple flash cards (SD, CF etc) have all those reserved sectors for spare blocks. For SSDs this is out of the question, because they contain advanced flash controllers esp. designed to handle file systems. But is it also the case with flash cards and cheap pen drives? I really don't know.

Anyway, designing effective SSD controller must be a really challenging task. And interesting. For example - a question: where do SSD controllers store mappings of blocks to logical sectors? Is it on the same flash chips where the data is stored or maybe in some other memory (built-in maybe?). This is really interesting stuff where hardware meets software.

I have a Panasonic SDHC class 10 that does wear leveling. Most of them don't.