7 Replies Latest reply on Aug 12, 2016 12:43 PM by hrjet9_1846051

    Why is accelerometer resolution deliberately reduced and how to fix it?

    hrjet9_1846051

      In lis3dsh_driver.c, the function GetAccAxesRaw is responsible for reading the accelerometer data. The relevant code is:

       

      buff->AXIS_X = (i16_t)( (valueH << 8) | valueL )/16;

       

      Why is the value divided by 16? That loses 4 bits of precision!

       

      If this division can be removed, can Cypress please fix this and provide a new signed firmware image? I could compile and flash my own image but my Android app's users won't be able to follow the recovery procedure. A firmware OTA update (signed by a key recognized with the pre-installed image) will work for them.

       

      thanks,

      hrjet

        • 2. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
          JacobT_81

          This is a driver produced by ST Micro provided as a guideline to interface to an ST product. We provide these drivers only to aid customers in the design of their own. We altered these drivers only to allow them to access our i2c hardware, and found that the resolution they gave us was good for the WICED Sense app since we show nothing but relative changes on a GUI. 

           

          This division by 16 could be there to zero out the noisy values in the least significant bits of this sensor which are often too oscillatory to work with. Or, perhaps, it could be an accidental remnant of a driver for a 12 bit sensor where it was necessary to shift out the LS 4 bits.

           

          OTA images are produced at compile time along with the regular firmware image.

           

          Jacob

          1 of 1 people found this helpful
          • 3. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
            hrjet9_1846051

            Thanks Jacob. I realize that the OTA images can be produced by me. But since I don't have the private key that is recognized by the factory image, I will end up creating an OTA image that can't be flashed unless the device is recovered.

             

            Hence, I will have to ask my users to do the recovery process on their Wiced Sense tag. Is that correct?

             

            thanks,

            hrjet

            • 4. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
              hrjet9_1846051

              Correction: I will have to ask my users to set the Wiced Sense tag in programming mode. Is that correct?

               

              (I just realized that Recovery procedure is only for worst-case scenario, when programming goes wrong).

              • 5. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
                hrjet9_1846051
                This division by 16 could be there to zero out the noisy values in the least significant bits of this sensor which are often too oscillatory to work with. Or, perhaps, it could be an accidental remnant of a driver for a 12 bit sensor where it was necessary to shift out the LS 4 bits.

                If it is a way to zero-out noisy values, then it is an extremely naive approach that doesn't serve the purpose at all, and further introduces high-frequency noise of its own into the signal.

                 

                To prove this, I spent the whole of today on this:

                • Recompiled the wiced_sense app with a single line of change (remove the division by 16)
                • Wrote a simple Android app which captures the Accelerometer data. I kept the wiced sense stationary and captured the Z-axis.
                • Imported the data into a spread sheet and prepared some charts

                 

                Behold. This is how the data would look if it was not dividied by 16:

                wiced-chart.png

                 

                And now, how it looks with the division by 16, (followed by rounding and multiplication by 16 for maintaining the scale):

                 

                wiced-chart-by16.png

                 

                As you can see, without the division the smoothened value converges to 1482.

                With the division, the smoothened value has some spikes and wavers around 1472.

                 

                Notes:

                * For the smoothing I used an exponential filter with alpha = 0.05

                * As a bonus, after eliminating the division the firmware is a few bytes slimmer and runs a few cycles faster

                • 6. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
                  JacobT_81

                  Chopping off the lowest bits is, in itself, a rudimentary LP filter. Not a good one, but it's a filter nonetheless.

                   

                  What you've done in your data is shift right 4 then shift back out left. This is not what the driver does in its division by 16--it only shifts right 4, chopping the bits (not zeroing them--apologies or incorrect terminology in previous post). So shifting left out by 4 (filling old bits with zero) then recursively applying your exponential filter will, of course, obfuscate the results. 

                   

                  Let me say again:

                  This is a driver produced by ST Micro provided as a guideline to interface to an ST product. We provide these drivers only to aid customers in the design of their own.

                   

                  The burden of proof lies on neither you nor me that this driver was correctly implemented. This is not a Cypress driver.

                   

                  Yes, the WICED Sense kit can be put into programming mode as you have found on other threads. I'm unsure if the factory loaded firmware accepts OTA downloads.

                   

                  Jacob

                  • 7. Re: Why is accelerometer resolution deliberately reduced and how to fix it?
                    hrjet9_1846051

                    Hi Jacob,

                     

                    Chopping off the lowest bits is, in itself, a rudimentary LP filter. Not a good one, but it's a filter nonetheless.

                    The problem is that it introduces high-frequency noise of its own. Moreover, it prevents a good LP filter to be implemented down stream.

                     

                    So shifting left out by 4 (filling old bits with zero) then recursively applying your exponential filter will, of course, obfuscate the results. 

                    How does it obfuscate the results? Multiplying by a constant will simply scale the chart, and it was done to match the scale of the other chart. There is no obfuscation as far as I can tell. Here's the same chart without the shift-left-by-4 (multiplication by 16):

                    wiced-sense-by16-noscale.png

                    It looks exactly the same, but with a different scale on the y-axis.

                     

                    The burden of proof lies on neither you nor me that this driver was correctly implemented. This is not a Cypress driver.

                    Yeah, I am just trying to get this fixed; not trying to find the root-cause of the problem.

                     

                    The fix is simple and as far as I know it is Cypress that could fix this now in the mainline. This will help all users of Wiced Sense to get a more accurate reading from their device, with a simple OTA update. Otherwise they would have to fiddle with programming the Wiced Sense themselves.

                     

                    I'm unsure if the factory loaded firmware accepts OTA downloads.

                    It does, and the official Android app updates it to version 1.3. The image is signed and the upgrade uses the secure protocol as far as I can tell.

                    2 of 2 people found this helpful