I bought a 2GB SD card to use in a project ** and it just won't format
with FAT. I've tried it in a PC card reader, camera and laptop's card slot.
The PC error is Windows Can't Complete Format, or the card is said
not to be present. Looking around with Google I find this seems to be a
problem with 2GB SD cards, and some people have had luck with putting
them in 98 machines
So this is partly a plea for a solution and partly a heads up although it looks
like I may have to try and exchange this for a 4GB SDHC
BTW, there's a claim on the back of the SD packet which says "Operating
shock rating of 1,000Gs, equivalent to a 10-foot drop to the floor"
1000G from 10ft ? Remembering that will tighten up the old sphincter when
you're up a ladder
The end use for this is a museum display of an automated 1906 Edison
cylinder player. It's in working order but the stylus has been removed
to protect the cyclinder so audio will come from the SD card files
I bought a 2GB SD card to use in a project ** and it just won't format
with FAT. I've tried it in a PC card reader, camera and laptop's card slot.
The PC error is Windows Can't Complete Format, or the card is said
not to be present. Looking around with Google I find this seems to be a
problem with 2GB SD cards, and some people have had luck with putting
them in 98 machines
So this is partly a plea for a solution and partly a heads up although it
looks
like I may have to try and exchange this for a 4GB SDHC
BTW, there's a claim on the back of the SD packet which says "Operating
shock rating of 1,000Gs, equivalent to a 10-foot drop to the floor"
1000G from 10ft ? Remembering that will tighten up the old sphincter when
you're up a ladder
The end use for this is a museum display of an automated 1906 Edison
cylinder player. It's in working order but the stylus has been removed
to protect the cyclinder so audio will come from the SD card files
I can't help with formatting the SD card, but as for the 1000G's,
you'd be surprised how high the acceleration can be when a hard object
meets a hard floor. Remember, it depends not only on the height of the
fall but also on the amount of deformation which can happen upon
impact. A person's body will deform a great deal (and up to a certain
point, harmlessly, like bending your legs or compressing the fat
layer). However, an SD card, with its hard plastic case, will not
deform much during an impact. However, given its low density and high
surface area, I would also suspect that it would not reach a very high
velocity while falling. A better example of very high G's would be
dropping a billiard ball onto concrete.
> I bought a 2GB SD card to use in a project ** and it just won't format
> with FAT. I've tried it in a PC card reader, camera and laptop's card slot.
> The PC error is Windows Can't Complete Format, or the card is said
> not to be present. Looking around with Google I find this seems to be a
> problem with 2GB SD cards, and some people have had luck with putting
> them in 98 machines
>
> So this is partly a plea for a solution and partly a heads up although it looks
> like I may have to try and exchange this for a 4GB SDHC
>
> BTW, there's a claim on the back of the SD packet which says "Operating
> shock rating of 1,000Gs, equivalent to a 10-foot drop to the floor"
>
> 1000G from 10ft ? Remembering that will tighten up the old sphincter when
> you're up a ladder
>
> ======================
>
> ** A dsPIC-based WAV player/recorder
>
> http://www.siliconchip.com.au/cms/A_111521/article.html
>
> The end use for this is a museum display of an automated 1906 Edison
> cylinder player. It's in working order but the stylus has been removed
> to protect the cyclinder so audio will come from the SD card files
>
> On Sun, Oct 11, 2009 at 8:54 PM, Jinx <.....joecolquittKILLspam.....clear.net.nz> wrote:
>> I bought a 2GB SD card to use in a project ** and it just won't format
>> with FAT. I've tried it in a PC card reader, camera and laptop's card slot.
>> The PC error is Windows Can't Complete Format, or the card is said
>> not to be present. Looking around with Google I find this seems to be a
>> problem with 2GB SD cards, and some people have had luck with putting
>> them in 98 machines
You could try a linux live cd like knoppix or finnix and use mkfs.vfat
> However, given its low density and high surface area, I would also
> suspect that it would not reach a very high velocity while falling
That's what I thought. If my Applied Maths (aaah Ms Pfannkuck,
where are you now ?) memory serves me
v^2 = u^2 + 2as
v^2 = 0 + (2 x 9.81 x 3)
v = 8m/s (29kph, 18mph)
> A better example of very high G's would be dropping a billiard ball
> onto concrete
Yes, shock-absorbing deformation makes all the difference. That's
why stunt men's ankles don't come out their ears ;-)
You could use one of the other motion equations to work out what
deceleration time would apply to cause 1000G and the resulting
deformation. I'm guessing it would be some fraction of a mm
Jinx wrote:
> I bought a 2GB SD card to use in a project ** and it just won't format
> with FAT.
but why you want to format the SD? They sell it pre-formated!
Witch kind of FAT you need? FAT12, FAT16 or FAT32?
Usually a 2GB is formated with FAT16.
Aside, not all reader permit to format, dont know why!
> but why you want to format the SD? They sell it pre-formated!
Well, that's what I expected, but as soon as Windows saw it I was
asked if I wanted to format. And then wouldn't when I said yes. Also
the camera wanted to format it too, so that does look like it had no
format. As I mentioned, others on the web have had problems with
2GB cards
> Witch kind of FAT you need? FAT12, FAT16 or FAT32?
Jinx wrote:
>> but why you want to format the SD? They sell it pre-formated!
>>
>
> Oh, I do remember doing a Properties on the card and it read as RAW
>
Strange!
I've used a tool named "HP USB Disk Storage Format Tool" to successfully
format some SD.
Google for it!
Jinx wrote:
> I bought a 2GB SD card to use in a project ** and it just won't format
> with FAT. I've tried it in a PC card reader, camera and laptop's card slot.
> The PC error is Windows Can't Complete Format, or the card is said
> not to be present. Looking around with Google I find this seems to be a
> problem with 2GB SD cards, and some people have had luck with putting
> them in 98 machines
>
>
Did your google search find this site: http://www.sdcard.org/consumers/formatter/
Here's hoping. I've downloaded it and will try in the morning
I installed Nicola's HP formatter. Unfortunately it reports "No
media" in the card reader, although I noticed when selecting the
card reader with the HP formatter that it came up as "1GB". So
is it there or isn't it ? During my Google search yesterday I read
that people had reported the smaller SD cards formatting to only
half their capacity, and I suspect that if the HP formatter had
worked this might have happened
Perhaps this card is faulty or SD is somehow flakey in my
situation, because these seem unreasonable lengths to go to
to simply format it. If the card formatter above doesn't work
I think I'll go with Plan B and return it in exchange for a 4GB
SDHC, which I have no problems with
>> Did your google search find this site:
>> http://www.sdcard.org/consumers/formatter/
>>
>> Might get the job done!
>>
>
> Here's hoping. I've downloaded it and will try in the morning
>
> I installed Nicola's HP formatter. Unfortunately it reports "No
> media" in the card reader, although I noticed when selecting the
> card reader with the HP formatter that it came up as "1GB". So
> is it there or isn't it ? During my Google search yesterday I read
> that people had reported the smaller SD cards formatting to only
> half their capacity, and I suspect that if the HP formatter had
> worked this might have happened
>
> Perhaps this card is faulty or SD is somehow flakey in my
> situation, because these seem unreasonable lengths to go to
> to simply format it. If the card formatter above doesn't work
> I think I'll go with Plan B and return it in exchange for a 4GB
> SDHC, which I have no problems with
>
>
I've heard of fake SD cards where the actual capacity is much less than
the stated capacity. These fake ones do return the correct properties
but fail when you try to actually access the data in the non existent area.
David...
--
___________________________________________
David Duffy Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717 Fax: +61 7 38234717
Our Web Site: http://www.audiovisualdevices.com.au
___________________________________________
> I've heard of fake SD cards where the actual capacity is much less than
> the stated capacity. These fake ones do return the correct properties
> but fail when you try to actually access the data in the non existent area.
> David...
>
Perhaps that's the reason they are selling those unformatted? ;-)
Tamas
>
> --
> ___________________________________________
> David Duffy Audio Visual Devices P/L
> Unit 8, 10 Hook St, Capalaba 4157 Australia
> Ph: +61 7 38235717 Fax: +61 7 38234717
> Our Web Site: http://www.audiovisualdevices.com.au
> ___________________________________________
>
> -
I have had with my Intel motherboard, and an internal connected header,
the card reader was not recognized, where it previously worked, plugging
the reader into another USB header, and it worked. Maybe some sort of
hardware problem, what happens with other cards?
Jinx wrote:
> the card is said
> not to be present.
>
Jinx wrote:
> That's what I thought. If my Applied Maths (aaah Ms Pfannkuck,
> where are you now ?) memory serves me
>
> v^2 = u^2 + 2as
>
> v^2 = 0 + (2 x 9.81 x 3)
>
> v = 8m/s (29kph, 18mph)
It's not clear what exactly you're doing here since you didn't define your
terms, so let's start from the beginning.
V = AT
Where V is the change in velocity as accelleration A is applied for time T.
The distance traveled during that time is the average velocity times the
time. In our case the initial velocity is 0, and it's obvious from the
equation above that V changes linearly. The average velocity of the
interval is therefore half the final velocity, which allows us to find the
distance D:
1
D = - VT
2
We know the distance and accelleration and want to know the velocity, but
don't know nor care about time. Solving for T:
2 D
T = ---
V
Which can now be substituted in the first equation to find V:
2AD
V = --- V**2 = 2AD V = sqrt(2AD)
V
V = sqrt(2 * 9.8m/s**2 * 3.05m) = 7.7m/s
And this is assuming no air resistance. 1000G is 9800m/s**2. The time it
takes to decellerate at 1000G is:
7.7m/s
Tstop = ---------- = 786uS
9800m/s**2
So their claim implicitly says the card comes to a stop worst case in 3/4 of
a millisecond. I guess that sounds plausible for a hard floor and
considering the hard plastic case.
> Perhaps this card is faulty or SD is somehow flakey in my
> situation, because these seem unreasonable lengths to go to
> to simply format it.
I've never had problems with the 2G SD cards I have (I think I have
four of them, mostly micro-SD.) 2G is apparently the limit for "SD"
low-level protocols; a 4G card requires SDHC electronics and
firmware. I had to replace card readers to read the 4G card(s) I
bought, and it required careful attention to specs. A lot of "many-
in-1 SD card readers" don't do SDHC (at least, as of six months ago...)
On Mon, Oct 12, 2009 at 11:54 AM, William "Chops" Westfield
<KILLspamwestfwKILLspammac.com> wrote:
>
> On Oct 12, 2009, at 5:47 AM, Jinx wrote:
>
>> Perhaps this card is faulty or SD is somehow flakey in my
>> situation, because these seem unreasonable lengths to go to
>> to simply format it.
>
> I've never had problems with the 2G SD cards I have (I think I have
> four of them, mostly micro-SD.) 2G is apparently the limit for "SD"
> low-level protocols; a 4G card requires SDHC electronics and
> firmware. I had to replace card readers to read the 4G card(s) I
> bought, and it required careful attention to specs. A lot of "many-
> in-1 SD card readers" don't do SDHC (at least, as of six months ago...)
>
> BillW
The firmware change is actually quite small (basically, divide the
address by 512), but I guess that's no help when the firmware is baked
into a card reader ASIC.
On Mon, Oct 12, 2009 at 10:20 AM, Olin Lathrop
<spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote:
> So their claim implicitly says the card comes to a stop worst case in 3/4 of
> a millisecond. I guess that sounds plausible for a hard floor and
> considering the hard plastic case.
Olin, also don't forget that bouncing causes higher peak force than a
simple acceleration to a stop.
Sean Breheny wrote:
> Olin, also don't forget that bouncing causes higher peak force than a
> simple acceleration to a stop.
No, it doesn't. I'm sure the card bounces some, but it still has to come to
a stop before reversing direction and going back up. With perfectly elastic
materials, the decelleration and subsequent bouncing accelleration profiles
are symmetric. With real materials, some energy will always be absorbed in
the compression of the materials during the decelleration phase. This
energy won't be released during the bounce accelleration phase, making that
accelleration less than the initial decelleration. After all, the card
won't bounce to anywhere near the original 10 feet, so obviously a good
chunk of the energy is absorbed by the material as it initially deforms.
If you think the accelleration due to bounce is higher than the initial
decelleration to zero, then you have think the material springs back more
quickly than it got initially compressed. That's not likely, and any
inelasticity will actually make it go the other way and dissipate energy
too.
Resonance could lead to higher accellerations, but that has little to do
with bouncing.
> > On Sun, Oct 11, 2009 at 8:54 PM, Jinx <RemoveMEjoecolquittTakeThisOuTclear.net.nz> wrote:
> >> I bought a 2GB SD card to use in a project ** and it just won't format
> >> with FAT. I've tried it in a PC card reader, camera and laptop's card
> slot.
> >> The PC error is Windows Can't Complete Format, or the card is said
> >> not to be present. Looking around with Google I find this seems to be a
> >> problem with 2GB SD cards, and some people have had luck with putting
> >> them in 98 machines
>
> You could try a linux live cd like knoppix or finnix and use mkfs.vfat
>
What you want to try is to degauss the card. (wink). Well, OK, the
solid-state equivalent would be to write all zeroes (or all 1's ?) over the
first few blocks of the card, to remove any preconceived notions. This used
to be a problem with diskettes, and I don't assume Windows has gotten all
that much smarter. Although, I wouldn't expect the camera to be fooled.
I left in the Linux comment, since that's how I'd approach it if someone
brought me a card. Of course, I'd probably read the first few blocks off
the card first, since that would give me some forensics/finger-pointing
data, as well as allow me to restore it if my bulldozer tactics backfired.
The relevant command is 'dd', also known as "just shut up and write the
data" :)
Actually I would give even odds that Linux would recognize the card
outright. I've had that experience already in a situation involving a thumb
drive, Windows XP, and OS X.
If you have a perfectly elastic material, the maximum force happens at
the end of the compression, when the spring is completely compressed.
If the material is perfectly inelastic, but still compresses at a
constant rate for a given force, then the force will be constant
during the deceleration. If the spring and the inelastic material
compress at the same rate initially, then the (constant) force of the
inelastic compression will be equal to the force of the spring at some
point early in its compression, which will be less than the force
later in the compression.
> Sean Breheny wrote:
>> Olin, also don't forget that bouncing causes higher peak force than a
>> simple acceleration to a stop.
>
> No, it doesn't. I'm sure the card bounces some, but it still has to come to
> a stop before reversing direction and going back up. With perfectly elastic
> materials, the decelleration and subsequent bouncing accelleration profiles
> are symmetric. With real materials, some energy will always be absorbed in
> the compression of the materials during the decelleration phase. This
> energy won't be released during the bounce accelleration phase, making that
> accelleration less than the initial decelleration. After all, the card
> won't bounce to anywhere near the original 10 feet, so obviously a good
> chunk of the energy is absorbed by the material as it initially deforms.
>
> If you think the accelleration due to bounce is higher than the initial
> decelleration to zero, then you have think the material springs back more
> quickly than it got initially compressed. That's not likely, and any
> inelasticity will actually make it go the other way and dissipate energy
> too.
>
> Resonance could lead to higher accellerations, but that has little to do
> with bouncing.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014. Gold level PIC consultants since 2000.
> What you want to try is to degauss the card. (wink). Well, OK, the
> solid-state equivalent would be to write all zeroes (or all 1's ?) over the
> first few blocks of the card, to remove any preconceived notions. This used
> to be a problem with diskettes, and I don't assume Windows has gotten all
> that much smarter. Although, I wouldn't expect the camera to be fooled.
>
As far as I remember the problem with diskettes was that they have stored
the index marks magnetically on the disk (I mean the IBM disk drive, other
ones were using the index hole, I think Apple and Commodore was using that
for example). There was an index mark for the first sector and then for each
additional sectors, all with synchronization data and some information about
the sector and cylinder number. When you formatted the disk you had to clear
not just the data but the index marks as well to make sure the diskette
worked ok. I hope my memory does not cheating on me so I might be wrong on
this?
>
> I left in the Linux comment, since that's how I'd approach it if someone
> brought me a card. Of course, I'd probably read the first few blocks off
> the card first, since that would give me some forensics/finger-pointing
> data, as well as allow me to restore it if my bulldozer tactics backfired.
> The relevant command is 'dd', also known as "just shut up and write the
> data" :)
>
> Actually I would give even odds that Linux would recognize the card
> outright. I've had that experience already in a situation involving a
> thumb
> drive, Windows XP, and OS X.
>
> Barry
Sean Breheny wrote:
> If you have a perfectly elastic material, the maximum force happens at
> the end of the compression, when the spring is completely compressed.
> If the material is perfectly inelastic, but still compresses at a
> constant rate for a given force, then the force will be constant
> during the deceleration.
I agree, but don't see what this has to do with bouncing. Your statement
above is a reply to mine where I debunked your assertion that bouncing
increases the G force beyond what it takes to get to a stop.
Maybe you would have seen this yourself if you had properly snipped and
replied to specific points in my post. As it is, your comments don't make
sense within the context.
> If the spring and the inelastic material
> compress at the same rate initially, then the (constant) force of the
> inelastic compression will be equal to the force of the spring at some
> point early in its compression, which will be less than the force
> later in the compression.
I don't agree with this, but since it has nothing to do with the point at
hand I won't go into it.
On Mon, Oct 12, 2009 at 6:05 PM, Olin Lathrop <RemoveMEolin_piclistEraseMEEraseMEembedinc.com> wrote:
> Sean Breheny wrote:
>> If you have a perfectly elastic material, the maximum force happens at
>> the end of the compression, when the spring is completely compressed.
>> If the material is perfectly inelastic, but still compresses at a
>> constant rate for a given force, then the force will be constant
>> during the deceleration.
>
> I agree, but don't see what this has to do with bouncing. Your statement
> above is a reply to mine where I debunked your assertion that bouncing
> increases the G force beyond what it takes to get to a stop.
Those statements were just to set up the argument. Also, I think it is
a little early to assume that you have debunked my argument.
>
> Maybe you would have seen this yourself if you had properly snipped and
> replied to specific points in my post. As it is, your comments don't make
> sense within the context.
>
>> If the spring and the inelastic material
>> compress at the same rate initially, then the (constant) force of the
>> inelastic compression will be equal to the force of the spring at some
>> point early in its compression, which will be less than the force
>> later in the compression.
>
> I don't agree with this, but since it has nothing to do with the point at
> hand I won't go into it.
It has everything to do with the point at hand.
Consider that the total impulse imparted by the floor upon the
impacting object is mv for something which does not bounce and 2mv for
something which does bounce. If we consider both events to take about
the same total time, then the average force is higher for the bounce.
My attempt at a more detailed explanation would be this: If the entire
bounce (deceleration and then acceleration) takes twice the time that
the inelastic collision takes, then the average force will be the same
for both. However, in many (most?) cases, the inelastic collision will
take longer to slow the object than a pure spring would (when the
constant is the distance required to stop the object). So, the total
time which the spring takes to impart 2mv of impulse is less than
twice the time which the inelastic collision takes to impart mv, so
the average force is higher. If the average force is higher for the
spring AND the spring has a progressively increasing force over time
(until the object is stopped), while the inelastic collision's force
vs time is either decreasing over time or at least not ever increasing
faster than the spring's, then the peak force must be higher for the
spring.
> However, in many (most?) cases, the inelastic
> collision will take longer to slow the object than
> a pure spring would (when the constant is the
> distance required to stop the object).
If that is true then the "opposite " statement is true as well.
Hmmm. Can you please explain? I'm not sure what you mean.
On Mon, Oct 12, 2009 at 9:12 PM, Marechiare <RemoveMEmarechiarespam_OUTKILLspamgmail.com> wrote:
>> However, in many (most?) cases, the inelastic
>> collision will take longer to slow the object than
>> a pure spring would (when the constant is the
>> distance required to stop the object).
>
> If that is true then the "opposite " statement is true as well.
> -
Sean Breheny wrote:
> Consider that the total impulse imparted by the floor upon the
> impacting object is mv for something which does not bounce and 2mv for
> something which does bounce. If we consider both events to take about
> the same total time, then the average force is higher for the bounce.
No, the average force is still the same. The time that force is applied is
longer.
In any case your original assertion was that bouncing produced higher peak
force, not impulse, since that's what a G rating is unless it's qualified by
the length of time that G value is to be applied, which it wasn't in this
case.
> However, in many (most?) cases, the inelastic collision will
> take longer to slow the object than a pure spring would
It seems this assumption is pulled out of thin air.
> while the inelastic collision's force
> vs time is either decreasing over time or at least not ever increasing
> faster than the spring's,
Of course the inelastic force will increase over time as more material gets
envolved in compression and deformation. It will eventually decrease as the
bulk of the mass comes to rest.
>> If that is true then the "opposite " statement is true as well.
> Hmmm. Can you please explain? I'm not sure what you mean.
>>> However, in many (most?) cases, the inelastic
>>> collision will take longer to slow the object than
>>> a pure spring would (when the constant is the
>>> distance required to stop the object).
If the above is true then the next is true as well:
***
However, in many (most?) cases, a pure
spring will take longer to slow the object than
the inelastic collision would (when the constant
is the distance required to stop the object).
***
That is, your statement is equivalent to:
***
the inelastic collision may or may not take longer
to slow the object than a pure spring would (when the
constant is the distance required to stop the object).
***
I guess you mean that my use of the word "many" means that there are
cases where the opposite holds?
Well, possibly. In fact, it would be possible to construct a device
which had the exact force profile of a perfect spring but then at the
very bottom, where the spring began to accelerate the object back up
again, this device could just start providing an output of 0 force. In
other words, it could synthesize a "fake" spring which was completely
elastic right up until the object comes to a stop and then it wastes
all the stored energy so that no bounce happens. However, that doesn't
change the fact that this does not happen with most materials.
>>> If that is true then the "opposite " statement is true as well.
>> Hmmm. Can you please explain? I'm not sure what you mean.
>
>>>> However, in many (most?) cases, the inelastic
>>>> collision will take longer to slow the object than
>>>> a pure spring would (when the constant is the
>>>> distance required to stop the object).
>
> If the above is true then the next is true as well:
>
> ***
> However, in many (most?) cases, a pure
> spring will take longer to slow the object than
> the inelastic collision would (when the constant
> is the distance required to stop the object).
> ***
>
> That is, your statement is equivalent to:
>
> ***
> the inelastic collision may or may not take longer
> to slow the object than a pure spring would (when the
> constant is the distance required to stop the object).
> ***
I took the 2GB card back, expecting a refusal, as companies can be
a bit iffy about used electronic components. But the staff were quite
happy to swap it for a 4GB, saying that they often get cards returned.
and that at times they're the faultiest product they sell. So, grrr for the
time wasted but this new card does format and the WAV player does
actually work and will soon be annoying museum staff with medleys of
100-year-old vaudeville songs ;-)
> I took the 2GB card back, [...] happy to swap it for a 4GB, ...
>
Well, now you've gone and ended the adventure, and we were just getting
started. Party pooper. Well, at least you've kicked off a physics
discussion. I feel as though I am posting off-topic if I talk about storage
media :)
>
> As far as I remember the problem with diskettes was that they have stored
> the index marks magnetically on the disk (I mean the IBM disk drive, other
> ones were using the index hole
Almost every diskette technology used magnetically recorded index marks.
The drives/media that had mechanical index hardware was just used it to time
where they'd start writing the track during a format run. And they'd use it
to determine if the disk was spinning.
> There was an index mark for the first sector and then for each
> additional sectors, all with synchronization data and some information
> about
> the sector and cylinder number. When you formatted the disk you had to
> clear
> not just the data but the index marks as well to make sure the diskette
> worked ok.
>
The format procedure wrote an entire track, with all of the things you
mentioned above (plus some "gaps"). And so it was possible to format a
diskette that had no magnetic transitions at all (a truly "blank" disk).
The problems we would sometimes run into was if there was something that
looked like a parameter block in sector 0, the system would read that and
possibly believe what it saw. Then it might decide it could not format
"that" kind of disk. If you degaussed it, then the system would just shrug,
then go ahead and format it.
mit.edu [.....piclist-bouncesKILLspam
