Contents
  1. 1. Remote SD card driven by Arduino
  2. 2. Android application
  3. 3. Conclusions
  4. 4. Code

Nowadays some high end phones do not have an extra SD card slot, therefore its users are limited to the internal storage space of the device. If you need more, you have to spend more money or use the manufacturer’s proprietary cloud solution as an alternative extension.

Is there a way to solve this problem? I hope so! Only some extra storage space has to be attached to these mobile phones.

However this attachment can be problematic! Fortunately Bluetooth Low Energy (BLE) is supported by today’s all major mobile phone operating systems: iOS, Android and Windows Phone. The idea is to add extra storage space to these mobile phones through BLE, which demonstrates that this extension is possible!

The solution consist of two parts:

  1. An external SD card extension, which is driven by an Arduino microcontroller.
  2. An Android application, which provides access to the remote SD card content.

Remote SD card driven by Arduino

First of all there is a need for simple hardware setup, which offers a remote SD card through an API:

The following components can be seen on the picture above:

  1. Arduino Mega 2560 microcontroller board
  2. Micro SD Card storage board
  3. Adafruit Bluefruit LE UART Friend - Bluetooth Low Energy (BLE)

The role of the Micro SD card module is obvious. An external micro SD card can be plugged into this board, which will communicate with the connected Arduino Mega 2560 microcontroller board through the Serial Peripheral Interface (SPI). The Adafruit Bluefruit LE UART Friend board provides the Bluetooth Low Energy (BLE) connectivity. The speciality of this component that it adds hardware or software serial communication - UART - capabilities to the project.

Based on that, the idea is to establish a Bluetooth Low Energy based serial communication channel between the phone and the remote SD card. The question might arise about why shall BLE has to be used over classic Bluetooth? Actually what is the difference between the two?

This article summarizes the difference. In short a BLE device consumes much less power than a classic Bluetooth device and it is compatible with Apple’s iPhone. Apple only supports those classic Bluetooth devices, which were certified through the Apple MFi program. This is not the case for this prototype, which makes BLE the only viable choice.

The reason why an Arduino Mega 2560 board was picked is because it has four hardware serial communication channels. One of them gets used during programming the Arduino board and later to debug its behaviour through the Serial Monitor View. Another one will connect the Arduino Mega 2560 board with the Adafruit Bluefruit LE UART Friend. Certainly other Arduino boards can be used - e.g. Arduino Uno, but in that case software serial has to be used, which slows down the communication.

Please note that the Arduino TX pin has to be connected to the RX pin of the Adafruit Bluefruit LE UART Friend and vica versa!

The following pins have to be used for SPI connection on the Arduino Mega 2560 board:

  • 50: SPI MISO
  • 51: SPI MOSI
  • 52: SPI SCK
  • 53: SPI SS - this is the SD card chip select (CS) pin

The Arduino Mega 2560 board can be powered through the USB socket or with a 9V battery.

Once the wiring is done the BleSdRemote.ino sketch has to be uploaded to the board, which provides the following communication API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
IN  <-: @LIST# - List all files and directories in the root folder
OUT ->: @DIVE0001.TXT,DIVE0002.TXT,DIVE0003.TXT,LOGBOOK.TXT,BOOKS/,PICTURES/,#

IN <-: @LIST:BOOKS# - List all files and directories in the given folder
OUT ->: @../,TEST.JPG,TUSKEVAR.PDF,BAROK.PDF,#

IN <-: @INFO:Images/About.png# - Sends back information about the given file
OUT ->: @<file name>%<file size in bytes>%<file creation date>%<file modification date>#

IN <-: @DELF:Images/About.png# - Deletes the given file on the SD card
OUT ->: @OK%<file path># or @KO%<file path>#

IN <-: @GETF:Images/About.png# - Download the given file from the SD card
OUT ->: @<file size in bytes>#<file content>

IN <-: @PUTF:Images/About.png%<file size in bytes># - Upload the given file to the SD card
OUT ->: @OK# -> Switch Arduino into file receiving mode
IN <-: <file content>

Every inbound message starts with the @ character and ends with a #. The : divides the message into two parts; the keyword and the payload part. Outbound messages are similar to the inbound messages except that the delimiter character is the %.

At this point everything is ready to write an application which communicates through the API with the remote SD card hardware. This will be an Android application described in the next section of this blog post.

Android application

The Android application supports the following use cases based on the previously mentioned API:

  1. Scan for the nearby BLE devices and connect to the one, which is UART capable
  2. List the content of the SD card and be able to navigate in its directory structure
  3. Download files from the SD card to the phone
  4. Delete files from the SD card
  5. Upload a file from the phone to the SD card

Let’s go one by one and elaborate on these use cases!

After the application start the nearby devices list is empty. The scan button has to be clicked in order to initiate a device scan and populate the list with the available devices. After a while these BLE devices appear on the screen:

Those which are UART capable has a special SD card like icon next to its name. A tap on such a device initiates a connection request. Once the device is connected, the content of the root folder gets displayed on the screen:

The folder icon indicates subfolders, which are navigateable to. For instance a tap on the Images folder leads to the following screen:

The empty folder icon leads back to the previously selected folder, while the other files are selectable with the checkboxes on the right. Let’s select some file, which will be downloaded from the SD card to the phone! A tap on the download icon in the navigation bar starts the download process, which will open up a file picker:

In this picker the destination folder on the phone has to be selected. Once it is done, the download process will start. The file size and the progress get displayed on the dialog:

Besides downloading files from the SD card other options are available. For instance files can be deleted from the SD card with the press of the delete button in the navigation bar:

For sure some files have to be uploaded to an intially empty SD card from the phone. In order to get this done, first of all the upload candidate file has to be selected with a file picker on the phone:

This file then gets uploaded to the SD card. The progress and the file size is indicated on the upload dialog:

Conclusions

This solution justifies that Bluetooth Low Energy based SD card extension is possible for a mobile phone. However this is clearly not the main purpose of BLE devices. The classic, stream based Bluetooth connection is more suitable for this purpose, because the throughput of this solution is limited. The UART data connection works with chunks. The chunk size is 20 characters. After each chunk a small delay has to be inserted into the communication - right now 100 milliseconds were used - in order to let the channel be able to identify the end of the chunk transmission. This restriction has a significant impact on the upload speed and file size.

Based on this limitation I suggest the usage of BLE based file upload and download only for small configuration files. For large files the classic Bluetooth solution is more feasible.

The prototype code is not production ready! Only the most common error conditions were tested. My intention was to demonstrate the capability and not to build a final product!

Code

The following GitHub repositories contain the source code of the two applications:

  1. Arduino: BleSdRemote
  2. Android: BleSdRemoteDroid
Contents
  1. 1. Remote SD card driven by Arduino
  2. 2. Android application
  3. 3. Conclusions
  4. 4. Code