Main Site Documentation

IMU Not Communicating


I have a CKDevices Mongoose IMU that I’m trying to get working with a Panda-II.

Everything is working fine using an FTDI cable with the desktop app. However, now I’m trying to connect the Mongoose to the Panda-II and don’t seem to be receiving anything. I have the serial pins connected as follows for a COM3 configuration on the Panda-II

Mongoose / Panda
3V3 / 3V3
RX / TX (D42)
TX / RX (D40)
DTR / ?

My concern is with the DTR pin. I’m not sure what to do with it. Does it need to be connected to something?

I’m configuring it as follows which is the same way the Windows app was configured except for COM11.

private readonly SerialPort _imu = new SerialPort("COM3", 115200, Parity.None, 8, StopBits.One);
_imu.DataReceived += OnImuDataReceived;

The DataReceived event doesn’t appear to ever get fired. Any ideas?


Open port first and then subscribe for events.


post my code for receive the CKDevices.

namespace FEZ_Panda_II_Application1
    public class Program
        static serial ckdevice;
        public static void Main()
            ckdevice = new serial("COM1", 115200);
            ckdevice.ReceiveDataEvent += new serial.ReceiveData(IMU_DATA);
             while (true)

        private static void IMU_DATA(object _rool, object _pitch, object _yaw, object _temp, object  _pressure)
                  //Read sensor data of IMU


    class serial
        public delegate void ReceiveData(object _rool, object _pitch, object _yaw, object _temp, object _pressure);
        public event ReceiveData ReceiveDataEvent;

        private SerialPort _serialPort;
        public serial(string com, int baund)
            _serialPort = new SerialPort(com, baund);
            _serialPort.DataReceived += new SerialDataReceivedEventHandler(SERIALRECEIVE);

        public void open()

        public void close()
        public bool IsOpen(){
            return (_serialPort.IsOpen);

        private byte[] buffer = new byte[550];
        private int countRead = 0;
        private byte[] Tbuffer = new byte[550];
        private bool find = false;

        private void SERIALRECEIVE(object sender, SerialDataReceivedEventArgs e)
            int byteread = _serialPort.BytesToRead;
            _serialPort.Read(Tbuffer, 0, byteread);

            find = false;

            for (int i = 0; i < byteread; i++)
                if (Tbuffer[i] == 10)
                    Array.Copy(Tbuffer, 0, buffer, countRead, byteread);
                    find = true;

            if (find)
                countRead = 0;
                if ((buffer[0] == (byte)'!') && (buffer[1] == (byte)'A') && (buffer[2] == (byte)'N') && (buffer[3] == (byte)'G') && (buffer[4] == (byte)':'))
                    string str = new string(Encoding.UTF8.GetChars(buffer));
                    string[] values = str.Split(',');

                    double roll = double.Parse(values[1]);
                    double pitch = double.Parse(values[2]);
                    double yaw = double.Parse(values[3]);

                    double temp = double.Parse(values[15]);
                    double pressure = double.Parse(values[16]);
                    ReceiveDataEvent(roll, pitch, yaw, temp, pressure);
                Array.Copy(Tbuffer, 0, buffer, countRead, byteread);
                countRead = countRead + byteread;


Thanks, Architect. You got it. That’s what I get for trying to do it from memory…


Hmmm… @ Michele3 Thanks for the code. Interesting…it looks like you have the Open & event subscription in the “wrong” order also. Does your code work? I assume it does…


yes code work perfect


That bug with the event handler drove me nuts for days!

COM1 works perfectly, regardless of the order of attaching the event handler. However, COM2 (and I assume COM3/4 too) has the bug.


Interesting. Doesn’t make sense… It’s the same SerialPort class being used in both cases. Is the bug in this class or further down in the FEZ API? Has this bug made it to the GHI bug list or NETMF list?


Bug is in NETMF core itself.

Share my pain…

Look at the bottom of the first page and article on page 2.


Good news is it looks like it gets fixed in 4.2.


Wow, this post save me hours of debugging… thanks… lolz, hope they fix this thing