accelerometer readings are doubling

edited May 2015 in Android
When ever I set the Accelerometer.SamplingConfig.OutputDataRate to ODR_200_HZ or higher, the numbers are doubling.
My log shows:
Fragment: 3.222
Fragment: 3.222
Fragment: 2.421
Fragment: 2.421
Fragment: 1.82
Fragment: 1.82
Is there anything else I need to setup for this to update faster?


  • What do these numbers represent?  Also, the BLE connection isn't meant for streaming data at 200Hz or higher.
  • The numbers are coming from the accelerometer then I'm dividing them by 1000. From what I under stand the accelerometer outputs in 1000th g's.
    Thanks for the information about streaming the data. I just wanted to make sure there weren't anymore settings I could change for the accelerometer that would make it faster.
  • Also, Why are there options for up to 800Hz if its not meant for streaming that high?
  • Derek,

    it is for logging.
  • Thanks Laura. I used the Logging methods in the Android Guide to get a basic understanding on how it works and had a few question about the results. For my Trigger I only added LoggingTrigger.ACCELEROMETER_X_AXIS. Then I used the "Log.i(TAG, String.format("Log received: id= %d, data= %s", entry.triggerId(), Arrays.toString(;" 
    My log shows:
    id= 0, data= [-4, -1, 0, 0]
    id= 0, data= [0, 0, 0, 0]
    id= 0, data= [-4, -1, 0, 0]
    id= 0, data= [0, 0, 0, 0]
    id= 0, data= [-4, -1, 0, 0] etc..
    What do the four numbers represent or mean in the entry data? Also, for these results, the MetaWare is not moving.
  • You use the logBytesToGs fn to convert the log data into Gs
  • Perfect! Thanks again, you guys are great!
  • More questions came up. 
    It looks like the Log only hold 36 acceleration numbers. Is that the max?

    What version of bluetooth is the MetaWare using? I understand LE is 4.0 but there have been some updates to 4.2 and I was wondering if the hardware will get these updates?
  • No, you can definitely hold more than 36 entries.  Try a logging session after resetting the board.

    MetaWear is using Bluetooth 4.0.  We may upgrade to the newer standard somewhere down the line but there is no benefit in upgrading right now.
  • I'm not sure of exactly how many readings the board can hold.....depends on the size of the data field and how many accumulators you have going on the board but I have seen it store well over 800 while I was testing things for MetaTracker.

  • Thanks Igleasain, I was looking for more like 1024 or 2048 to be exact. Im trying to see if I can take a small amount of readings like those numbers but at a very fast rate, about 5 milliseconds. We need to use Bluetooth LE because of the capabilities with iPhone and bluetooth 2.0. 
    I was looking up the bluetooth specifications thats on the board and noticed that it is capable of sending data at 3 data rates (2Mbps/1Mbps/250kbps). Does any one know what the board is set to with this firmware and can it be changed?

  • Derek, with the present MetaWear firmware release you can store around 15000 entries in the log.  Storing X, Y, and Z will require two entries so you can only store half that many accelerometer data points.  The logger shares flash memory with the firmware code, so as we add more features the count will go down, but not below 10k.

    BLE supports only the 1Mbps data rate.  The SoC itself can run other data rates to speak other protocols such as ANT or a Nordic proprietary protocol called gazelle.  This data rate specifically refers to the radio transmission while active, as opposed the actual data throughput.  Throughput in BLE is determined by how often the two devices communicate at that speed, which they call the connection interval.  iOS devices are capable of sending 6 packets of 20 bytes maximum every 37.5 ms.

    The accelerometer is set up to send one XYZ pair per data packet for the fastest delivery. Six packets per 37.5 ms gives a max transmission rate of 160 Hz.

    We have done some projects with fast paced action sports and found that 50 Hz covered most uses, and 100 Hz covered them all.
This discussion has been closed.