stm32f1/README.md

The forumslogger (or forumslader-logger) is a small man-in-the-middle board for logging forumslader automatiklader data.

project

summary

The forumslader automatiklader is a power manager for bicycles. It used the power generated by a dynamo to charge Li-Ion battery and can also provide 12V (for lights) and 5V (to charge phones over USB). The automatiklader can also be enhanced with a bluetooth module, allowing a phone to log precise speed (using the dynamo activity), battery charge, and other values using the forumslader Andoird app.

Sometimes you don't have your phone around to log the data though, but you still want the data to be recorded. This project covers this case, always logging the forumslader data no matter if a phone is present or not.

technology

The phone connects to the forumslader using Bluetooth. The app uses the Bluetooth Serial Port Profile (SPP) to transfer data (see protocol section for an example of data sent by the forumslader). The forumslader board uses an off-the-shelf bluetooth module.

Thus instead of using Bluetooth to get the forumslader data (like the phone would do), we will remove the forumlader Bluetooth module, connect our logger board directly to the underlying serial port, and our board will have a Bluetooth module so to forward the data again to the phone. Since our board sits between the forumslader and phone it can log the data all the time.

The logged data is saved onto a micro-SD card for virtually unlimited storage space. Each time the forumslader wakes up and starts sending data a new file containing the logged data is created. The internal Real Time Clock (RTC) is used to provide date and time, which is used in the file name of the logged data.

In addition to the forumslader a GPS module is added. This allows to automatically set the correct time in the RTC (once the GPS has a fix). The GPS data is also logged (into the same file). This allows to add a timestamp to the forumslader data (every second the GPS sends the UTC time) and log the actual route cycled. While GPS also provides speed, the forumslader data based on the dynamo is much more precise (similar applies to the distance).

On top of the forumslader commands, the logger provides additional commands to list, retrieve, and delete the logged data files.

bluetooth

The forumslogger uses a common HC-05 Bluetooth module for communication with the user. Accordingly it is necessary to configure this Bluetooth module. For that enter the AT control mode:

• connect the Bluetooth module to a USB to UART converter
• press and hold the button on the module
• plug the USB to UART converter to a computer
• the module should blink every two seconds, indicating it entered the AT control mode
• connect to the module using the USB to UART serial port with a baud rate of 38400 (8N1) Alternative war to enter the AT control mode are described here.

Once connect configure the Bluetooth module:

• enter AT to check if the UART communication is working. The module should respond with OK
• change default PIN for a tiny bit of better security: AT+PSWD=1337
• change the normal mode baud rate: AT+UART=115200,0,0 (the Forumslader uses 9600 but there is no good technical reason to keep this slow speed, and the forumslogger uses 115200)
• set the device name: AT+NAME=forumslogger (different to Forumslader to avoid confusion)

Now connect to Bluetooth module to the forumlogger. When powered the module will rapidly blink (in normal mode). Once paired and connected the module will double blink every 3 seconds.

state

working:

• SD card read and write
• file read and write (using fatfs)
• GPS data parsing
• RTC date and time synchronisation to GPS time
• forward Bluetooth <-> Forumslader data

TODO:

• log forumslader data
• log GPS data
• provide Bluetooth commands to list, retrieve, and delete files

The forumslader data does not include timestamps. The data is just sent periodically. This periodicity is used to calculated the current speed, also using the provided number of dynamo steps recorded. Thus providing the logged data all at once to the forumslader app will lead to erroneous speed data. The other information will remain consistent (e.g. distance, battery status, ...) since only the last values are used (this information is not dependent on the periodicity).

protocol

The forumslader data is NMEA-0183 formatted (without checksum).

The app sends $FLT,5; TODO check what device responds

The device sends periodically data (every 50-100 ms?): $FL5,00c000,0,0,4130,4133,4135,-26,0,305,1,219,200,6750,14077; $FLB,850,101652,219,0; $FL5,00c000,0,0,4130,4133,4133,-15,0,305,1,218,200,6750,14077; $FLC,4,258,269,8,9,0; $FL5,00c000,0,0,4131,4133,4135,-18,0,305,1,217,200,6750,14077; $FLB,850,101651,219,0; $FL5,00c000,0,0,4130,4133,4135,-26,0,305,1,216,200,6750,14077; $FLC,5,66086,100,718,28,31897091; $FL5,00c000,1,3,4130,4133,4135,-25,0,305,1,240,211,6750,14077; $FLB,850,101649,221,0; $FL5,00c000,1,17,4130,4133,4133,-28,0,306,1,240,228,6750,14077; $FLC,0,16198,49,200,2146,76; $FL5,00c000,1,17,4130,4131,4133,-29,0,307,1,240,245,6750,14077;

$FLB,850,101652,219,0; 850 is ??? 101652 is the pressure in centi-hectopascal 219 is the altitude in dm 0 is the gradient in decidegree

$FLC,4,258,269,8,9,0; ???

$FL5,00c000,0,0,4130,4133,4135,-24,0,305,1,232,260,6750,14077; 00c000 is the status (hex, seperate tab) the 1st 0 is the switching step in steps the 2nd 0 is the speed in 0.6 km/h steps 4130 is the cell 1 voltage in mV 4133 is the cell 2 voltage in mV 4135 is the cell 3 voltage in mV -24 is the accu current in mA the 3rd 0 is the consumer power in 0.0124 Watt steps (dependant on another parameter) 1 is the cinsumer current in mA 232 is the temperature in F 260 is the micropulsecounter 6750 is the pulsecounter

board

The firmware is for a STM32 F1 series micro-controller (i.e. STM32F103C8T6). Currently a core board is used for development since it provides a micro-SD card slot. In the end a blue pill will be used so it can fit in the bicycle frame.

Which board is used is defined in the Makefile. This is required to map the user LED and button provided on the board

connections

Connect the peripherals the following way (STM32F10X signal; STM32F10X pin; peripheral pin; peripheral signal; comment):

• USART1: forumslader (remove the Bluetooth module)
• USART2: Bluetooth module (i.e. HC-05)
• USART3: GPS module (i.e. u.blox NEO-6M with small patch antenna)
• SPI1: micro-SD card slot

All pins are configured using defines in the corresponding source code.

code

dependencies

The source code uses the libopencm3 library. The projects is already a git submodules. To initialize and it you just need to run once: git submodule init and git submodule update.

To read and write files on the FAT formatted micro-SD card the FatFs library is used, The files are already included in the project.

firmware

To compile the firmware run make.

documentation

To generate doxygen documentation run make doc.

flash

There are two firmware images: bootloader and application. The bootloader image allows to flash the application over USB using the DFU protocol. The bootloader is started first and immediately jumps to the application if it is valid and the DFU mode is not forced (i.e. by pressing the user button on the board or requesting a DFU detach in the application). The main application should be implemented in application.c. It is up to the application to advertise USB DFU support (i.e. as does the provided USB CDC ACM example).

The bootloader image will be flashed using SWD (Serial Wire Debug). For that you need an SWD adapter. The Makefile uses a Black Magic Probe (per default), or a ST-Link V2 along OpenOCD software. To flash the booltoader using SWD run make flash_booloader.

Once the bootloader flashed it is possible to flash the application over USB using the DFU protocol by running make flash. To force the bootloader to start the DFU mode press the user button or short a pin, depending on the board. It is also possible to flash the application using SWD by running make flash_application.

debug

SWD also allows to debug the code running on the micro-controller using GDB. To start the debugging session run make debug.

USB

The firmware offers serial communication over USART1 and USB (using the CDC ACM device class).

You can also reset the board by setting the serial width to 5 bits over USB. To reset the board run make reset. This only works if provided USB CDC ACM is running correctly and the micro-controller isn't stuck.