Erratic SF windows toolbox outputs?

[j_perezdelarray]

Hello,

We have been doing some testing with FRDM-K64F / FRDM-FXS-MULT2-B development boards with the Windows sensor fusion toolbox (last version of the toolbox). We have been testing the 6DOF sensor fusion mode only.

We have obtained very good results when visually checking the sensor and fusion outputs tabs. But we have encountered 3 issues when recording and saving to .csv files:

1) Duplicated records: similar to an old post from 2015: duplicated sensor records | NXP Community 

2) Erratic behaviour of the toolbox GUI when the "record" box is selected. I attach 3 screenshots of the sensor fusion toolbox when the record tickbox is selected:

         1- Sensor tab_erratic_record.jpg: It shows values before and after the record tickbox is selected. The "erratic" behaviour can be seen after enabling the record tickbox.

          2 - "Dynamics_tab_erratic_record.jpg": similar to nº1: Ramdom peaks appear in the outputs and the behaviour of the data is somewhat "erratic".

          3 - "kalman filter tab with erratic results": Similar to 2.

3) Not acccurate info in some of the output lines: Some of the lines in the .csv file tend not to follow the selected fusion mode. The information "swifts" randomly. I attach 2 screenshots of the excel file where some of the lines have switched the initially selected algorithm and coordinate system (gaming and NED) to "2D automotive", "gyro compass", "windows8" etc. Also the numeric values in these lines are not coherent.

After eliminating duplicated values and suspicious imported excel lines, data is consistent (still some doubts about the "erratic" behaviour of the toolbox)

Q: Has anyone experimented similar experiences? Could someone advise on how to correct/improve the record data?

[j_perezdelarray]

Hello Mike,

Thank you for the promtp reply.

1) Ok. We'll soon move to our own implementation of the sensor fusion and probably dump data directly, without passing through windows. This should solve the issue.

2) I also bet it is a PC related issue. I'll try another PC to see if we get the same results. I'll post results when we do the test.

3) We have not switched fusion modes while recording. I attach the recorded .csv file and the import excel file of the trial in gaming mode. If you filter the data you will see how  randomly data is incorrect or misaligned. I'm not sure if this is a consequence of point nº1, nº2 or if the import is not done correctly.

[michaelestanley]

I agree it doesn't look correct.  I cannot envision ANY mode where the frame of reference changes on the fly.  We're seeing data corruption in the serial stream. Let's see how things work when you switch to a different laptop.

[j_perezdelarray]

Hello,

We've tested on other laptops with similar results, the behaivour becomes erratic with random corrupted data in the output. It all happens when pressing the record tab: sensor, dynamis and kalman visual outputs in the GUI are affected somehow, similar to what we can see in the .csv file It looks like the synchronization between the GUI and sensorfusion is lost or disturbed somehow.

[michaelestanley]

A couple of quick questions...

1. Which OpenSDA driver are you using?
2. Have you tried any alternatives (I personally like the Segger ones)
3. What OS are you running on your PC?

[j_perezdelarray]

Hello Mike,

Thanks. I've made some progress. I was using  the ARM CMSIS-DAP serial drivers from Windows serial configuration - Handbook | Mbed 

I have downloaded and installed the Segger driver which is specific for FRDM-K64 board (SEGGER - The Embedded Experts - Downloads ) and I have seen a huge improvement. The toolbox sensor and filter outputs don't become erratic anymore after pressing the "record" box. This was done in the laptop running windows 7. But I still see some of the excel lines flying randomly. Which segger openSDA driver are you using?

Have tried in a Windows 10 laptop with similar results.

For all you who need info on how to install SDA drivers for the development boards, visit OpenSDA Serial and Debug Adapter|NXP  and choose your development board. It explains in detail how to enter bootloader mode and links to download the necessary drivers:

 

[michaelestanley]

That's fantastic!  I've been using Windows 7 and the current set of Segger drivers (I routinely updated a few weeks ago).

A couple of years back, I spent a lot of time looking at the different OpenSDA implementations.  The Segger version downloaded programs a lot faster. The downside is that it doesn't support drag-and-drop software installation, but since I'm always using an IDE, it doesn't matter.  And as you've found out the hard way, it appears to be generally more robust for serial communications.

[j_perezdelarray]

The ARM Mbed driver was an executable file that automatically installed drivers once the board had been plugged in. But the truth is that I installed segger drivers with a drag and drop sequence, except you have to enter the bootloader mode of the board by pressing the reset button before plugin it in. I followed the directions of the NXP page above.

Also segger drivers come in a SW package. Once installed you have to look for the USB folder in which drivers can be found.

[michaelestanley]

To be precise, there are four components of interest:

1. Low level bootloader on the board.  This is used to install (2) below.
2. OpenSDA firmware on the board
3. Application firmware on the board
4. Windows-based drivers that can talk to the board-based OpenSDA code

Some versions of OpenSDA firmware/drivers can install application firmware via drag and drop.  That's the feature missing from the Segger implementation.

[j_perezdelarray]

Hello Mike,

What I've downloaded from segger webpage is an openSDA file for K64F (02_OpenSDA_FRDM-K64F.bin) and an executable installer of windows drivers.

How do you install the 02_OpenSDA_FRDM-K64F.bin file without drag & drop option?

[michaelestanley]

That's easy.  Disconnect your K64F from the OpenSDA cable.  Press and hold the reset button while simultaneously reconnecting the cable.  The board will boot in "Bootloader" mode and you will see it as a drive on your computer.  Drag and drop the 02_OpenSDA_FRDM-K64F.bin to that drive.  Once it copies, disconnect and reconnect.  That's it.

[j_perezdelarray]

Ok, then segger does support drag & drop. I was confused when you said it didn't because in fact I uploaded the segger driver that way (bootloader mode with drag&drop).

[michaelestanley]

It doesn't support application code drag-and-drop.  All OpenSDA boards support drag-and-drop of the OpenSDA firmware.  It can be a bit confusing...

[j_perezdelarray]

Ok, understood, thanks!. Yes, it definetely can get a bit confusing...

[michaelestanley]

Javier,

• I think Mark's early response to duplicated sensor records is correct.  The embedded board application runs in real-time and continuously transmits data.  Windows is definitely not real-time, and if several packets get buffered together, we'll see the problem you described.  We've not found a way around it.

I should also mention that the serial link between the board and PC does impose limitations in terms of how many packets can be sent.  We throttle communications to 40 fusion samples per second.  So if you run fusion higher, you will lose more and more packets.

• I haven't noticed this before, and couldn't reproduce it here.  Again, I'm willing to bet that this is strictly a PC-side issue only.  Can you try a different Windows machine?
• As to the 3rd item, it is normal to have a few fusion cycle delay when switching from one fusion model to another on the fly.  That's just normal pipeline delay.    However you should NEVER be able to switch between NED and Windows8 frames of reference on the fly, as those are compile-time options. Are you seeing changes happen independently of your changing the fusion mode controls on the GUI?

Regards,

Mike