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?
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.
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.
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.
A couple of quick questions...
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:
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.
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.
To be precise, there are four components of interest:
Some versions of OpenSDA firmware/drivers can install application firmware via drag and drop. That's the feature missing from the Segger implementation.
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?
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.
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).
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.