Crashing rockets and recovering data from damaged flash chips | Hacker News Reader

Crashing rockets and recovering data from damaged flash chips

dontvacuum.me

70 pointsxyx082613 comments

They should have first attempted going without VCC and GND. Just make sure CS# is hooked to ground and WP is hooked to VCC.

Both pads would have protection diodes to VCC/GND providing phantom power when tied to the appropriate rail. Plenty of chips work fine with phantom power.

That's a cool idea. Going to file that away for another time. I imagine you'd maybe run your phantom voltage a little higher to overcome the ESD diode drop?

The voltage drop is probably already accounted for in the allowable range unless it's a very low voltage chip. The main concern is you can't get away with anything high current. An SPI flash chip should be ok though, it's only driving one pin and you can choose whatever rate you want.

Interesting use of a salt solution to weep into the broken parts to make contact. I personally would be shitting diamonds if I was reduced to this, it seems like it would be way too easy to short out the board with this method, especially when the packaging is so badly mangled.

I probably would have tried slowly and carefully whittling away the plastic near where the bond wires used to be to try to expose some metal first before using this salt water bath idea, but if it works it works.

This is a big enough package that it has a lead frame, and same, I would have been using mechanical removal processes to gain access to it.

What is that circular kit with the stands and pins that he's using here? https://dontvacuum.me/rocketflashrecovery/needles-1.jpg

Reminds me of PCBite

https://www.aliexpress.us/item/3256807898318737.html

> the rocket dropped unchecked and burried [sic] itself 3 meters underground.

Very impressive! I wonder at what speed it impacted. I tried reading the chart at the bottom but I'm not sure what "axial" velocity is—probably not vertical speed given it drops over time rather than rises as the rocket dropped.

I suppose you could take the derivative of the height at impact point but I'm too lazy.

The red line is axial acceleration. The rocket rapidly slows to terminal velocity, reaching it at about 25 sec., then continues to slowly decelerate as t.v. decreases as the air gets thicker. [edit: *] The black line is estimated velocity, as integration of the acceleration. It gives up trying to calculate that at about 45 sec. Based on the barometer readings, it looks like it was going about 650 fps at impact.

What I find interesting is the 4-second delay before igniting the second stage. This is very inefficient compared to immediately igniting it when the first stage burns out. Max-Q (airspeed pressure) issues? 30,000 ft permit ceiling?

Edit: * At 25 sec. it's still going up, so the velocity is decreasing due mainly to gravity, but the rocket is ballistic so the accelerometer is slightly negative due to air friction adding to the gravity deceleration. At about 40 sec. it has reached max altitude and velocity is zero. Accelerometer is still close to zero. Velocity picks up, as shown by barometric altitude curve. Eyeballing it, at about 65 sec. its reached terminal velocity, as shown by barometer curve being pretty flat. Decrease after that is due to decreasing t.v.

With solid motors lower in the atmosphere with high velocity it's often optimal to delay second stage ignition so that your sustainer motor isn't working against as much atmosphere. So, kinda Max-Q issues, but for performance reasons.

Great writeup, cool photos, no ads. Thank you!

Dennis is also one of the (if not THE) leading vacuum robot hacker and makes https://github.com/dgiese/dustcloud. Amazing work.

Might be worth it to pot the flash chip in some epoxy or something. Heck, add another one and double it up for redundancy.

Reply on news.ycombinator.com