Communication

Communication  STM32F4 with MPU9250:

I use the I2C inter integrated chip communication ability of the MPU9250. At 400kHz the performance is fast enough for the flight controller. An extra GPIO input is provided from the STM32F4 to receive a “new data available” interrupt. This interrupt starts the process of data reading, PID calculation and controlling the speed of each motor individually. Since the distance on the PCB from the MPU9250 to the STM32F4 is rather short the communication works reliable. However a watchdog makes sure, that every 1/sample_rate_of _the_MPU9250 (in my case 333Hz) a new data got received. Otherwise a system reset takes place. A reset of the flight controller does not affect the BLDC motor speeds; so for a few milliseconds the quadrocopter would not be updated with motor speed information but that is not noticeable.

Communication STM32F4 with the BLDC motor controller:

I initially also used the I2C bus for communication. Don’t do this! The noise immunity is not good enough to work in such an ugly environment like a quadcoper. At full speed an average current of almost 20 A is chopped with 20kHz. Peak currents are even much higher; so there is a lot of induced noise everywhere.

I use now a CAN bus. This bus uses a differential signal 2,5V to 5V and 2,5V to 0V. Therefore all commen mode induced voltage do not really influence the communication. Your Car uses CAN bus in almost all of its communication needs; an very harsh electronics environment too.

A CAN bus is a fieldbus system, rather fast. Each BLDC motor has it’s own address and receives only data for his address. However it uses a 5V power supply. So I have just for the CAN bus to provide 5V (in the mean time I use the 5V for powering the FPV camera an the quadcopter as well).

The CAN bus works great. One small drawback is, that the STM32F4 CAN bus peripheral only allows to send 3 messages at once (mailboxes). Therefore I do have to wait in the mail loop until the three messsages got transmitted until I can send the 4th message for the last motor. This plugs up my main loop for a few milliseconds. I have not found a way around (would a RTOS operating system solve this?) yet.

The statistical profiling of the software shows, that the system is ideling most of the time in the main loop (82% of the time). However the above mentioned delay in sending the 4th CAN bus package is reflected in (high) 8% of the time.

Communication STM32F4 to GPS and Telemetry:

Here I use standard UART (RS232) communication.

Communication STM32F4 with RC receiver:

The used RC receiver is a Futaba R2008SB. It provides 6 channels of pulse-width modulated outputs. I use only four channels at the moment (roll, pich, yaw, and throttle). The receiver also provides a proprietarry serial protocol, the so called S-Bus. The S-Bus runs at 100k baud. I tried to read the S-Bus with a UART but found, that the akward unusual 100k Baudrate is very sensitive to the hardware timing of the UART peripheral. Since I clock my STM32F4 with the onboard oscillator at 168MHz I do have some percentages deviation of this nominal clock frequency. One could tune “manually” the core clock but probably over temperature you might get out of Futaba’s timing specs. No good when you are up in the air! I skiped this approach and read not the for channel outputs with four GPIO interrupt inputs and measure with an extra timer the pulse-width time what represents the channel value. I lost to much time hacking the S-Bus really. Now my system works very robust an reliable.