News for hackers. Stuff that matters.
Re:Crashing rockets and recovering data from damaged flash c... by polishdude20 on Monday December 16, 2024 @11:09PM (#42438242)
Might be worth it to pot the flash chip in some epoxy or something. Heck, add another one and double it up for redundancy.
Re:Crashing rockets and recovering data from damaged flash c... by russdill on Wednesday December 18, 2024 @02:17PM (#42453804)
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.

Re:Crashing rockets and recovering data from damaged flash c... by 0_____0 on Wednesday December 18, 2024 @03:22PM (#42454664)
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?
Re:Crashing rockets and recovering data from damaged flash c... by russdill on Wednesday December 18, 2024 @03:57PM (#42455089)
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.
Re:Crashing rockets and recovering data from damaged flash c... by jandrese on Wednesday December 18, 2024 @02:22PM (#42453871)
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.

Re:Crashing rockets and recovering data from damaged flash c... by 0_____0 on Wednesday December 18, 2024 @03:21PM (#42454647)
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.
Re:Crashing rockets and recovering data from damaged flash c... by PittleyDunkin on Wednesday December 18, 2024 @03:27PM (#42454720)
> 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.

Re:Crashing rockets and recovering data from damaged flash c... by mgsouth on Wednesday December 18, 2024 @04:36PM (#42455601)
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.

Re:Crashing rockets and recovering data from damaged flash c... by Marthinwurer on Wednesday December 18, 2024 @04:48PM (#42455753)
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.
Re:Crashing rockets and recovering data from damaged flash c... by wildekek on Wednesday December 18, 2024 @03:29PM (#42454739)
Dennis is also one of the (if not THE) leading vacuum robot hacker and makes https://github.com/dgiese/dustcloud. Amazing work.
Re:Crashing rockets and recovering data from damaged flash c... by racked on Wednesday December 18, 2024 @03:42PM (#42454925)
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

Re:Crashing rockets and recovering data from damaged flash c... by russdill on Wednesday December 18, 2024 @04:38PM (#42455627)
Re:Crashing rockets and recovering data from damaged flash c... by two_handfuls on Wednesday December 18, 2024 @05:45PM (#42456328)
Great writeup, cool photos, no ads. Thank you!