Storage redundancy - I2C parallel write possible? FRAM?

[icannotfly]

Greets,

I am building a flight data recorder for model rockets and I need to write data to storage in such a way that it can survive the breakup and destruction of the parent craft.
First, is it possible to write to several I2C devices in parallel by ensuring that they have the same ID? My thinking here is to use a few of something like the XPI Flash SD Card (https://www.adafruit.com/product/6039), placed in different areas, and keep the CS pin common to all of them. Would this work?
Failing that (or maybe even in addition to that), would FRAM like (https://www.adafruit.com/product/1895) be useful in such a scenario? I see that the amount of storage available here is significantly less, but I don't yet know how much storage I'm going to need, and I could probably stagger writes across multiple chips.
Are there other ideas? Anything I'm missing?

[T_Mo]

(only a community member)

The first task is to decide how much data you need to save (how many values, and to what resolution), and how often. That will determine what devices, capacity, and what interface types are appropriate.

No, I do not think you can successfully use one I2C interface to drive multiple devices sharing the same address, running in parallel simultaneously.

[adafruit_support_carter]

Check out this for a storage option. Same thing, just in different storage sizes:
https://www.adafruit.com/product/4899 (512MB)
https://www.adafruit.com/product/6038 (2GB)
https://www.adafruit.com/product/6039 (4GB)

[adafruit_support_mike]

I2C has a send-and-acknowledge message model that makes talking to multiple chips unreliable.

Yes, identical chips with the same address should respond the same way. And the I2C bus does allow multiple devices to pull the line low at the same time without hurting anything. So the "everything works the way I want it to" case is possible and functionally correct.

The "something goes wrong" cases are completely borked though. The microcontroller will think everything is okay if any single chip responds the expected way. If you had three chips, each with a 1% rate of transmission failure per byte, the microcontroller would only expect to see one failure message per million bytes. Meanwhile each chip has a 50% chance of at least one error every 70 bytes, and a 99.995% chance in every 1000 bytes.

You can change the rules though.

Instead of trying to write directly to multiple memory chips at once, you could give each memory chip its own microcontroller, like an ATtiny816:

https://www.adafruit.com/product/5681

then have all the microcontrollers listen to the same Serial line. That doesn't require any handshaking or reply, so there's no problem in having multiple listeners. Then each microcontroller can push data to whatever storage is attached to it.

[Spacedog49]

1. How fast are you capturing and recording data?
2. What processor are you using?

I've had 5 rockets impact the ground carrying 500Hz flight computers. Three recorded accelerometer data through the impact in the range of 700-900 G's on a SD card. One SD card ejected from the impact and the data during the impact was lost. Good flight data, but no impact data. The last rocket has not been found.

Multiple data storage locations adds both hardware and software complexity. Better to place the flight computer in a high survivability location, behind a metal tip of a nose cone or back by the fins in a metal capsule.

I have found that most of the 400kHz I2C sensors and memories will function using the 1 MHz clock setting with the RP2040, STM32, & ESP32 processors. The higher clock speeds of the SPI and QSPI memories, like the Adafruit QSPI DIP, should provide sufficient time between data captures to write sequentially to multiple memories. A colleague is using an ESP32-C3 capturing IMU data at 2000Hz using SPI flash memory. I'm currently flying 1000Hz flight computers using the QT PY ESP32-S3 with 1MHz I2C sensor data clock and SDIO to an SD card.

[icannotfly]

Thank you all, I see that I have a few other considerations to attend to before working on storage. I'm going to just start writing to an SD card that's been glued in place until it becomes a problem, if it ever does.