Sd Card Specification And Testing

The MCU being used by the OBDH subsystem allows us to fly an SD card with a capacity of 2 gigabytes as secondary storage. However, we must first ensure the card is able to survive and function in space.

The SD card does not, as far as we know, have any filght history. It is rated for "up to 80,000ft" but this does not represent a maximum tolerance for the device. The SD card is based on the same flash memory technology as the ROM on the flight module though, so we believe if the board can survive the environment, so can the SD card. It is packaged differently than the flash memory on the board, so it may need additional shielding to survive as well in space. We plan to obtain an SD card and test its susceptibility to radiation at some point in the future.


Information about the temperature range

Radiation tolerance

The satellite's orbit will cause it to pass through the South Atlantic anomaly, the point of closest approach to the earth of the inner van Allen radiation belt. The anomaly - which is caused by the slight offset in the earth's geometric centre - contains highly energetic protons and electrons. The effect of these on flash memory such as that in the SD card is unknown, and testing is necessary to ensure the card will remain functional after prolonged exposure to the anomaly. Should it not, shielding will be required to protect the card.

The testing will be carried out either by computer simulation or exposing the SD card to similarly energetic particles. Research into the range of energies that the particles may have is ongoing and will allow a test to be planned and performed.

SD Card interface

Reading raw data from an SD card

These methods should work using internal SD card readers built in to many laptops. If they do not, an external USB card reader is more likely to work as it will use generic drivers.


Download the program HxD in your language and install it.

If you are using Windows Vista, right click the HxD icon you will be using to launch the program and choose properties. Click the 'Advanced…' button and tick 'Run as administrator', confirm any UAC windows that appear as you close the properties window. Without this step, HxD may not detect the SD card if it doesn't contain a valid file system.

Launch the program, ensure the SD card is in your reader, and navigate to 'Extras/Open disk…'. Alternatively click the 'Open disk' icon in the toolbar.

Select the SD card in the 'Physical disks' section, it is likely to be called something like 'Removable Disk 1'. Press open, and the raw SD card data will be displayed.


The basic procedure uses linux, with python installed.

  1. The card is inserted into the reader and is detected (shown by it popping up into gnome, or from its existence in the /dev directory).
  2. A mount command is then run to find the location of the card (this is not the only way but is the easiest and quickest thing I could think of).
  3. Python is then started in interactive mode as root.
  4. The following code is then typed in line by line

'/dev/device' is replaced with the actual device name as shown in /dev, and 512 in the read command is the amount to read in bytes from the sd card (512 is chosen as it is the size of a sector), the print command will print it out as ascii and not hexadecimal but this is a trivial thing, this code is here is more a proof of concept than a practical implementation, which will come later in a full blown program.

An alternative method to get the data from the sd card is to copy directly from the card to a file on a linux machine, this is done using the dd command

dd if=/dev/device of=out.bin count=1024

this can then be opened using a hex editor to view the actual values of the file, and therefore the actual values on the sd card.


Links Datasheet for a typical industrial SD card


The sandisk product manual (version 1.9) has been uploaded (here), in this file it documents the protocols of the sd card.

The current version of the sd card code sd.c. To use this code, a function has to be constructed to run sdinit at the start, and then sd_read_block to read and sd_write_block to write, calling sd_wait_notbusy before each read and write command to wait until the previous read/write has completed. A version including the read/write buffers will be implemented and that version will contain functions to read and write data - that is write_image, read_next_image, write_adcs, read_next_adcs, write_pay, read_pay etc. once the data required to be written is known.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.