AnsweredAssumed Answered

Android app missing, questions on implementation

Question asked by SCOTT MILLER on Mar 12, 2019
Latest reply on Mar 15, 2019 by Tomas Vaverka

I'm finally taking another look at NXP's sensor fusion library, and I've got a few questions.  First, is the Android app still available somewhere?  Has it been replaced by another app?  I can't find it in the Android store.  I know I've had it installed before.

 

The Windows app isn't completely working for me - in the precision accelerometer tab, the calibration buttons don't seem to do anything.  Am I doing something wrong?  The manual doesn't mention any other steps.

 

Just finding the sensor fusion code was a bit of an adventure.  The key discovery was that it's now part of ISSDK.  The sensor fusion home page still links to an outdated document.  It's a little baffling that a C source library is only available as part of a custom SDK build and only for a couple of boards.  I can understand only providing examples in the SDK, but why not give us a direct zip file download instead of having to custom build a package for a board we're not actually using and then extract it and copy the files?

 

I'm implementing drivers for different sensors, and the sensor fusion needs to be integrated into a larger existing project.  In the description of installSensor(), I'm confused by one entry.  Under the busInfo parameter, page 48 of the user's guide says "Specify background task to run during serial accesses".  The comment in the actual structure says "information required for bus power management".  I'm guessing this was a change from a previous version and the user's guide didn't get updated correctly.  Is that right?

 

Is there any way at compile time to disable use of SysTick?  Or do I need to scour the source and remove references manually?  I'd prefer for the sensor fusion system to keep its hands off of the peripherals entirely, and when a new version comes out it'd be nice to be able to just drop it in and not have to go through the seek-and-destroy routine again.

 

I've already got raw sensor reads taken care of elsewhere in the application.  It looks like I should be able to skip readSensors() entirely and have my existing sensor read system make the necessary calls to post data to the software FIFOs.  If I do have to implement the read calls, they're just going to be stubs that copy from the values already in memory.

 

I would much prefer the sensor fusion system to not expect to be in the driver's seat.  There's a bunch of stuff bundled up in it (like the serial interface functions) that feels more like a demo app is mixed in with what should be a pure library.  Ideally I'd just give it all of the configuration parameters, call an init function, then pass it scaled and rotated sensor readings at fixed intervals and get back the output values.  Seems like the rest of it could be a wrapper around that core functionality.

 

Thanks,

 

Scott

Outcomes