With the hard drive, that's mostly a matter of how your end device is using and reporting the available memory; I'm pretty sure the hard drive itself will have at least 1000 billion bytes on it. Even if you want to feel ripped off about the 10^3 vs. 2^10 distinctions, I think 7% is not really worth calling "far less".
Anyway, there's no equivalent issue with mAh as far as the unit goes. The point is, as with the MPG on a car, you can't capture the capacity with a single number. I think that with most reputable battery manufacturers, you will get the advertised capacity if you suck the power out at the right rate. If you discharge the battery quickly, over something like an hour, you will likely get less than the nominal capacity; if you draw it out over something like a week, you will probably get more. If your applications always discharge the battery quickly, it's reasonable to expect that you'll always get less than the claimed capacity.
You might think of something like ketchup in an 8 oz. bottle: there's 8 oz. there, and you can get it all out if you wait long enough, but you'll get a lot less if you only have 5 seconds per bottle to get it out.
Of course, keep in mind there are many more variables with batteries, like how much that capacity changes over the number of times you recharge, how the temperature affects the capacity, and on and on.
I don't think your statement about memory devices is correct. The battery part is in the post: as with range on a car, you will get more or less out of a battery depending on how quickly you try to get it out.
I don't really understand your first paragraph. Has someone like UL lobbied for the status quo? (And even if they did, I would object to the implication that it is their fault, as opposed to that of a government that will not disclose its own rules.)
I think the rest of your comment is predicated on some common assumptions that I suspect are not valid, so I'll just mention a few of them for each sentence:
"Codes come from the time when unsafe businesses burned down entire blocks."
* Safety is not binary.
* Safety was improving before and without government intervention.
* New codes are constantly being added.
* Some codes (e.g. that fire alarm thing) specifically prevent us from being safer.
"This still happens in places like China."
* Fires and other accidents still happen here in the US.
* Regading "entire blocks", are you referring to some specific recent incidents in China?
"If all US businesses had the integrity of pololu.com then all these rules wouldn't be needed for public safety."
* I appreciate your trust in our integrity, but I don't think that's a significant factor in our trying to do things well.
* Our "integrity" mostly comes from caring about our stuff, which I think most owners do.
* If you agree that the vast majority of businesses are safe enough out of their own self-interest, how much do you want to shackle them because of a few bad apples?
"But history shows it only takes one corrupt utility to poison an entire city."
* Can you point to specifics?
* Utilities in the US are so intertwined with government that I suspect instances of examples of bad behavior are more an indictment of government than of private business.
* Like safety, "poison" is not binary and tends to be used unfairly to incite emotional responses. There is a continuum to the tradeoffs between benefits a community gets from services provided by the utility and negative side effects like pollution.
* Utilities are a more difficult case, and it's somewhat unfair to bring that up in a discussion like this about codes. I'm fine with a lot of these rules existing and the processes for them as long as they apply only to public entities since the public is the owner or payer for those organizations. But private organizations should have way more latitude in their own policies.
More generally, the underlying premise of your post is that the codes are for some "public safety" kind of thing. But most of them, at least the ones I am writing about here, are about protecting individuals, who should be free to make decisions for themselves. Why should we be subject to rules intended to prevent "entire blocks" from burning down if there are no other buildings around us?
Lots of people want some kind of "regulation". I'm not sure if that's valid, but I think it's definitely invalid to assume that some detached bureaucrat will do a better job of it than a private owner.
You're kind of all over the place there, so I will just give you bullet point comments as I go through your post:
* I don't know where you're coming up with this "(as you said)" note.
* All kinds of devices (including motors and light bulbs) draw less current when you give them less voltage. You have to have some somewhat special electronics to draw more current when the voltage goes down. Some LED flashlights could certainly be in the "somewhat special electronics" category.
* I'm used to RC toy cars running for maybe 10 minutes, so 23 extra minutes is huge. Obviously, it's not in your case, but you should see it's useless for you to just mention 23 minutes without some baseline.
* Your Application 1 text is difficult to follow and seems to have a lot of extra unnecessary details.
* If you are asking for confirmation that you cannot calculate the battery life without knowing the current you are drawing, then yeah. But in that case, I don't know where you are getting your confidence about running off a particular battery configuration.
* If 1W is your input power at 12 V, you can figure 1/12 A (or 83 mA) for your current.
* I don't think a lot of little LEDs is an efficient way to get a lot of light. That's based on the good flashlights not seeming to do that.
* I expect a decent AA NiMH cell to be able to put out 7 amps for a few seconds, but if you really care, you should try to get the specs for your particular batteries.
What does your question have to do with continuous-rotation or multi-turn servos (the topic of this post)? Also, it would be nice if you didn't call your servos "servo motors" given that one of the posts in the series details why not to call them servo motors.
Anyway, it's completely possible for you to destroy your servos by giving them a bad signal. You should look at your servo control signal with an oscilloscope to see what your program is doing.
Did you read the post? Anyway, 2000 mAh should last about 1 hour at a 2 A discharge rate, 2 hours at a 1 A discharge rate, 10 hours at a 200 mA discharge rate, and so on. Typically, the capacity is based on some particular discharge rate, and capacity will be lower if you discharge faster than that. By the way, a modern cell phone battery is going to be a lithium-based battery, which you have to be extra careful not to over-discharge, and the battery module might have some integrated electronics to protect and monitor the battery.
Thank you very much for your feedback. At this point, I think that if I could just flip a switch and have comments in a way that would not be that objectionable (for instance, with some of the suggestions you had), I would turn that feature on. The way we're organized right now, though, our few web programmers are also involved in product design, and I would rather spend our time on new products or on more important features for the web site (such as the search system).
In general, it's pretty difficult to change a normal servo to a multi-turn servo; at the very least, you need to change your feedback potentiometer to a multi-turn pot or change the gearing to it somehow.
I do not know what you mean by the "in one direction" part. If it can go more than 360 degrees and keep track of position, it will be able to do that in both directions.
This article is about using one PWM source to get multiple servo control signals. As I said in the post, I think it is not helpful to think of servo control pulses as general PWM signals. You cannot get four arbitrary PWM signals out of one PWM signal.