Redundant Flash vs Redundant SD?

I'm working on a data logger for a small project that will be subject to very harsh loading conditions (high G, high T, etc.). For storing the logged data, I've deliberated between running two DataFlash chips or just running two SD cards, both off of a shared SPI bus and both storing identical information for redundancy.

The question I have is, what's the best way to do this? I was thinking about tying the SCLK, MISO, and MOSI lines together with independent CS lines, and then for a writing operation bringing both CS lines low to select both cards/chips. That way, both devices would be writing the same data at the same time, but I worry about the two chips fighting with each other.

The advantage to SD over DataFlash is that I can easily remove the cards, pop them in a computer, and read the data. The disadvantage is that I worry about the stability of the SD card under high loading. I don't want the cards shifting around or otherwise coming out of the slot (or breaking connection).

Really, the only advantage that the DataFlash chips have is that they're surface mount, solid state devices. If the reflow is done properly, I really don't have to worry about the chips coming off, breaking, etc. The big disadvantage to them is writing code and building a circuit to interface with them once the data has been logged (in order to pull the data off with the computer). The SD cards don't have that problem...

Any recommendations you all have would be most appreciated. Thanks!

The question I have is, what's the best way to do this? I was thinking about tying the SCLK, MISO, and MOSI lines together with independent CS lines, and then for a writing operation bringing both CS lines low to select both cards/chips. That way, both devices would be writing the same data at the same time, but I worry about the two chips fighting with each other.

You can only talk to one device at a time. You would need to log to one, then the other.

The disadvantage is that I worry about the stability of the SD card under high loading.

Yeah, all those moving parts...

I don't want the cards shifting around or otherwise coming out of the slot (or breaking connection).

Have you heard of duct tape?

Why do you need redundancy?

PaulS: You can only talk to one device at a time. You would need to log to one, then the other.

Okay, that's fine too. I guess logging times will take twice as long, but the time scale for saving data should be sufficiently small.

PaulS: Yeah, all those moving parts...

What I'm worried about is putting an SD card mounted in a mechanical socket under 50G loading with vibrations ranging from 20Hz to 2000Hz. I'm worried about what sort of noise I might pick up on the bus, assuming it does remain in contact. Static loading isn't so much the problem as the vibrations are. The design cannot tolerate intermittent connections, like what would equate to switch bounce, for example.

PaulS: Have you heard of duct tape?

Yes, but I prefer my designs to be mechanically and electrically sound before I use them. Do it once, do it right. I have the chance to design it properly from the start, so why would I use duct tape?

Plus, it's not so much keeping the card in the slot that I'm worried about, but keeping the card in contact with the pins.

[quote author=Coding Badly link=topic=92117.msg692487#msg692487 date=1329346427]Why do you need redundancy?[/quote] The data logger has to work "just once". The project I'm working on is very expensive to run and the data I take needs to be securely recovered. Data loss means a failure. SD cards are inexpensive, same with the chips, so why not? In case something happens during operation, redundancy will reduce the likelihood that all data is lost.

Atmel has had years to work out any problems with the processor. It is possible for the processor to fail but very unlikely. The same is true for SD cards. If a manufacturer was selling cards that had a high failure rate, they would quickly go out of business.

Adding a second card makes the system more complicated. Generally, more complicated also means more likely to fail. As an off the cuff example consider the power supply. It too could fail. Adding a second card increases the load on the power supply. If the power supply was just shy of failing, the second card would push it over the edge.

The most likely failure is the code you develop. Not because you are a bad coder but because it will be, by far, the least tested part of the system. If you want something much more reliable, have a second person build one with no collaboration. Make them as simple as possible. Then, use the two in parallel.