Micro SD card deck

Specifications

Features

• Automatic detection of deck via 1-wire memory
• Micro SD card reader
• Support for FAT file system in the Crazyflie 2.X firmware

Mechanical specifications

• Weight: 1.7g
• Size (WxHxD): 21x28x4mm
• Designed for mounting above or under the Crazyflie 2.X

Electrical specifications

It’s possible to switch the pin used for SPI chip select using the solder bridges on the bottom of the board. By defalult GS4 is used (IO4), but this line can be cut and another bridge soldered to select another IO (IO1-3) for chip select.

Compatibility

See the compatibility matrix

• Datasheet
• Schematics
• Compatibility matrix

Usage

File system

The SD-card used in the deck must be formatted as a FAT32 file system (exFAT does not work).

Data Logging

The firmware contains a data logging functionality out of the box. It can be enabled and configured by placing a config file on the µSD-Card. The file is a simple text file and an example is available config.txt. The file format is as follows:

1     # version
512   # buffer size in bytes
log   # file name
0     # enable on startup (0/1)
on:fixedFrequency
100     # frequency in Hz
1     # mode (0: disabled, 1: synchronous stabilizer, 2: asynchronous)
log entry 1
log entry 2
log entry 3
...
on:myEvent1
log entry 4
log entry 5
...
on:myEvent2
...

The config file supports logging of log variables as well as event triggers. For the fixed frequency logging, the frequency is an integer value in Hertz, for example 250 means that a data block is written every 4ms. The buffer size is used to decouple the writing to the card and the data logging. Higher frequencies require a larger buffer, otherwise some data might be lost. The Crazyflie console will show how many events had to be discarded due to insufficient buffer size:

uSD: Wrote 161378 B to: log00 (2237 of 2237 events)

In general, logging 10 variables with 1kHz works well with a buffer of 512 Bytes. But you may have to try around a bit to get feeling on what is possible. The file name should be 10 characters or less and a running number is appended automatically (e.g., if the file name is log, there will be files log00, log01, log02 etc.). The log entries are the names of logging variables in the firmware. The config.txt file will be read only once on startup, therefore make sure that the µSD-Card is inserted before power up. If everything seems to be fine a µSD-task will be created and buffer space will be allocated. If malloc fails the Crazyflie will be stuck with LED M1 and M4 glowing. Data logging starts automatically after sensor calibration if enable on startup in config.txt was set to 1. Otherwise, logging can be started by setting the usd.logging parameter to 1. The logfiles will be enumerated in ascending order from 00-99 to allow multiple logs without the need of creating new config files. Just reset the Crazyflie to start a new file. Logging needs to be explicitly stopped by setting the usd.logging parameter to 0, which protects the logfile data with a CRC32.

Data Analysis

For performance reasons the logfile is a binary file, using the following format (version 2):

uint8_t 0xBC header
uint16_t version
uint16_t num_event_types
for each event type:
   uint16_t event_id
   eventName<null>
   uint16_t num_variables
   varname1(vartype1)<null>varname2(vartype2)<null>...<null>varnameN(vartypeN)<null>
for each event:
   uint16_t event_id
   uint64_t timestamp (in microseconds)
   data (length defined by TOC event type)

Here, the vartype is a singe character and we support a subset of the ones defined here. We provide a helper script to decode the data:

import cfusdlog
logData = cfusdlog.decode(fileName)

where fileName is a file from the µSD-Card. For convenience there is also an example.py which shows how to access and plot the data.

• Getting started with expansion decks
• config.txt
• helper script
• Parameters
• Log variables

Development

File system

FatFS is used as file system handler. Have a look at the API and examples on the FatFS site fore usage information. The FatFS module will be initialized by the micro-SD deck driver when the deck is detected. After that the API calls can be used such as f_mount, f_open, f_read, f_close etc.

Errata

SPI bus limitations

Rev C

The SD-Card is using the SPI bus on the deck port to communicate. This has turned out to have some implications for the other decks that use the SPI bus which limits the speed of logging. If higher speed is needed one workaround is to use a “hidden” SPI on the deck port that is multiplexed with TX1, RX1 and IO_4. This SPI port is called SPI3 in the STM32F405 and it is a possibile to switch to this SPI bus.

The following steps can be used to work around this issue:

• First thing the SD-card deck needs to be patched. This is a quite hard to cut the small lines and solder small patch wires. Easier is to use a sd-card breakout deck such as this and solder wires to e.g. the battery holder board.
  • CS→RX2(PA3)
  • SCLK→TX1(PC10)
  • MISO→RX1(PC11)
  • MOSI→IO_4(PC12)
• Then with make menuconfig enable Expansion deck configuration -> Support for the Micro SD card deck -> Use alternative SPI and alternative CS pin.

Rev D

This revsion makes it easier to do the switch to SPI3 as described for Rev C.

• On the bottom of the board cut bridges GS4, GS9, GS10 and GS11. Then solder GS5, GS6, GS7 and GS8 (marked ALT.SPI)
• Then with make menuconfig enable Expansion deck configuration -> Support for the Micro SD card deck -> Use alternative SPI and alternative CS pin.

Together with Loco deck

If you want to use the Loco-deck at the same time, the alternative pins is better to use as the SPI bus can get congested. This means cutting GS1 and GS2 underneeth the Loco positioing deck and soldering the bridged GS3 and GS4. Then with make menuconfig enable Expansion deck configuration -> Support the Loco positioning deck -> loco deck alternative IRQ and RESET pins

• FatFS
• Deck pin allocation