Netduino Plus 2 Interrupt Performance

I had been considering using the Quadcopter IMU to drive the execution of the orientation and stabilisation algorithms. The MPU 6050 has an interrupt output which can be configured to trigger when there is data available to be read etc.

I had read discussions about the maximum frequency which the Netduino & the NetMF could cope with and just wanted to check for myself. For this test I assumed that the PWM outputs (once initialised) consume little or no CPU and that with only an InterlockedIncrement in the interrupt handler that these would be the maximum possible values.

Netduino Plus 2 Interrupt Testing

I used the onboard PWM (D3) to drive an interrupt (D1) and then had a background thread display the number calls to the interrupt handler in the last second. The button (D4) in the picture above allowed me to increase the frequency of the PWM output in 100Hz steps. The desired count and actual count where displayed using Debug.Print and the .Net Microframework deployment tool

100 101
200 107
700 453
1000 867
1500 1225
1800 1629
2100 1943
2900 2470
3200 3093
3600 3432
4000 3799
4000 4020
4000 4021
4000 4020

The counts seemed to be reasonably accurate until roughly 13KHz then there would be major memory allocation issues and the device would crash.


MPU 6050 I2C read rates using Netduino plus 2

The quadcopter will need to determine it’s orientation then update the thrust to be delivered by each motor many times a second. So I was interested to see how fast my Nedtduino plus 2 could read data from the MPU 6050 accelerometer & gyroscope. I stumbled across this blog and it appears that they are building a Quadcopter as well(Google translation was hard work to read).

There was also some very useful C# NetMF code which I used as the basis for my performance test harness.

10,000 readings of 16bit values from the Accelerometer (X,Y,Z) Gyroscope (X,Y,Z) and temperature sensor. The initial run didn’t look to positive

21.78, 21.77, 21.77, 21.77, 21.77, 21.77, 21.77,21.77,21.77,21.77 sec Avg 21.77

Which is roughly 460/sec

I then had a look at the I2C interface code and noticed that the bus speed was set to 100KHz so I increased it to 400KHz

10.33, 10.23, 10.23,10.23,10.23,10.23,10.23,10.23,10.72,10.23 Avg 10.29

Which is roughly 970/sec

I then had a look at the I2C interface code and changed the way that the register values were read so the array of registers to read didn’t have to be loaded.

8.55,8.57,8.55,8.57,8.55,8.57,8.57,8.57,8.55,8.57 Avg 8.56

I think 1170/sec should be sufficient, but I’m going to have a look at the Digital Motion Processor (DMP) capabilities of the MPU6050. This will require significant effort as there currently (June 2013) doesn’t appear to be any NetMF support for this approach.

Quadcopter MPU 6050 IMU mounting board ordered

For testing I’m going to need a shield to mount my MPU 6050 breakout board and connectors for the four motor speed controllers so a protoshield looked like an ideal solution. The netduino plus 2 I am planning to use for the Quadcopter controller has a slightly different I2C setup to the original Netduino & Netduino plus. After some research it looks like the Netduino plus 2 arrangement is the same as the Arduino Uno & Arduino Leonardo with the I2C SDA & SCL pins next to the AREF pin. I did consider using a software based I2C implementation but discounted this because I was worried about performance and additional complexity.

Many of the Arduino/Netduino protoshields currently on sale (June 2013) don’t have the necessary SDA & SCL pins e.g. Sparkfun, Freetronics, Adafruit, Makershed, ladyada etc.

I have sourced 2 x Leoshield from GorillaBuilderz in Australia which look suitable.

MPU 6050 Quadcopter IMU has arrived

The  3 x MPU 6050 breakout boards (GY521) I ordered on Alibaba arrived from China yesterday. I’m looking at using a device which has both an accelerometer & gyroscope in one package rather than an IMU assembled from several discrete devices to make the software simpler (only one I2C bus address).

To make the Microsoft I2C implementation work with multiple discrete devices usually requires a layer of abstraction like commonly used AbstractI2CDevice class which I was wanting to avoid in this project.

The test rig for my light weight high performance driver, a netduino 2 plus & breakout board.


If I need a compass to make the Quadcopter controller work I’ll upgrade to an MPU 9150.