2019-11-01 05:20 AM
Hey all!
Recently I've purchased the STEVAL-MKSBOX1V1 (SensorTile.Box), and I've been blown away by the board. First of all, great job!
Now I have a following question: I want to use this board to generate data of vibrations. Before buying the board, I already did some exploratory work with the STEVAL-MKI109V3 and a separate LSM6DSOX sensor. In UNICO I noticed the different configurations of the sensor (2g,4g,8g etc, and 26Hz, 52Hz etc).
However, I do not know where I can configure the MKSBOX1V1, since it does not connect to Unico. How am I supposed to do this? What is the base configuration of the SensorTile.Box's LSM6DSOX? What is the difference if I don't change this configuration?
Thanks in advance!
2019-11-04 07:04 AM
Hi @TSchi.2269 , first of all thanks to the good feedback on ST.box tool :smiling_face_with_smiling_eyes:
Please note that the fully integrated MLC at FW and app level on ST.box / STBESensor will be available estimated end of November, with a proper set of examples that you'll able to launch directly from the smartphone app (car vibrations, industrial vibrations, etc).
By now, the procedure for implementing a new MLC with a ST.box could be, in Mode 3 (or Pro Mode), the following one:
Regards
2020-01-25 10:37 AM
Hello, is the situation with integrated application the same as 3 months ago?
The process outlined by Eleon doesn't sound too complicated, but it's quite tedious to create many iterations quickly. At least for the last two steps it would be nice to have a more streamlined solution.
BR
2020-01-25 10:47 AM
Dear SFort.1
The process is exactly the same as three months ago. You are right, it is quite tedious to create many iterations quickly. To make the last step easier, I just overwrote the .h file of the sensor config and changed the name of my sensor config in the BLEMLC project. Then I mapped the outcomes of the decision tree to the already implemented icons (since my decision tree had only 0 or 1 as output, i mapped these to the "walking" and "driving" icon. This is not really that nice, but it works great for me.
The only tedious thing yet left is the building of the project. I have to build it, get the .bin file and load it with the programmer onto the ST.Box. I also have a ST-Link, because i wanted to debug the ST.Box and make uploading and testing easier, but the ST-Link is not recognized by the Cube IDE, so I still have to do it in a tedious way.
2020-01-27 01:48 AM
Hi @SFort.1 , @TSchi.2269 , from last week an upgrade of ST BLE Sensor application is available. It implements the MLC virtual sensor (and the FSM virtual sensor) as input source. This feature automatizes the upload of the .ucf file whose generation from Unico is described above and outputs the label recognized by the MLC.
Next step is of course do the whole MLC process on the SensoprTile.box / ST BLE Sensor app, but unfortunately I have no precise estimation of the completion date for this activity.
Regards
2020-01-27 02:18 AM
Thank you for your message Eleon.
Past weeks we've implemented it self and are now aware on how to develop a project for the ST.Box in the Cube IDE. I hijacked the BLEMLC and rewritten the code now so it matches our needs. This was the most important step. How we are going to try to see if we can ONLY use the LSM6DSOX and a dedicated microcontroller without all other peripherals to maximize energy efficiency. Meanwhile we are capturing data to keep improving our current decision tree.
Is there any place where the library for the LSM6DSOX can be downloaded, or do we have to recycle the code of the BLEMLC sensor project (which is fine as well)?
2020-01-27 04:45 AM
Hi @TSchi.2269 , so you are now switching from the ST.box platform to and optimized LSM6DSOX + MCU platform, right? Depending on the MCU you'll choose (especially if it is from STM32 family), there are lots of specific reference designs, also depending on your specific application. For example, the FP-SNS-ALLMEMS1 function pack. There are also generic C drivers and code samples on ST official Github repository for LSM6DSOX. Examples include finite_state_machine.c, machine_learning_core.c and Sensorhub drivers for custom implementation. Regards
2020-01-29 04:18 AM
Yes, that is true. We probably choose a STM32-type MCU, since we want our whole project based on ST products. Thank you for all your help!