{
  "id": 334308,
  "title": "What Are IMU timestamps, or Does the IMU Take Coffee Breaks?",
  "url": "/competitions/smartphone-decimeter-2022/discussion/334308",
  "author_name": "",
  "post_date": "2022-06-30T23:00:09.089063500Z",
  "votes": 10,
  "comment_count": 1,
  "views": 0,
  "content": "<p>It seems like very few people have admitted to making use of IMU data and so maybe that could be a good approach (shh, don't tell anyone).</p>\n<p>EDIT:  I had the names of the 2 interpretations backwards.</p>\n<p>The timestamps reported in the device_imu files are mostly uniformly spaced but have variances.  For example, the GYRO data in 2020-06-04-US-MTV-1/GooglePixel4XL  has most measurement times spaced at 19 or 20 msec, but there are many that are as little as 5 msec and as much as 88 msec apart.<br>\n<img src=\"https://i.postimg.cc/CxMtVjg5/hist.png\" alt=\"hist.png\">](<a href=\"https://postimg.cc/KRVQP34h\" target=\"_blank\">https://postimg.cc/KRVQP34h</a>)</p>\n<p>My question is are these times to be interpreted as the measurement time or the reporting time?  Two interpretations:</p>\n<ol>\n<li>Reporting Time:  The IMU device makes constant rate measurements driven by a clock but the reporting hardware/software interface gets delayed.  In that case, a 10 msec measurement interval is really a 20 msec interval where the previous interval got reported late.</li>\n<li>Measurement Time: The IMU device makes measurements however it feels like (maybe taking time out for refreshing itself (coffee break 😄) and then reports the time of the measurement correctly.  This could include the case where some measurements are dropped, although this wouldn't explain a 5 msec interval.</li>\n</ol>\n<p>Given the IMU chipset specs, it seems unlikely that a 5 msec interval is correct.  Does anyone have any thoughts on this issue?</p>\n<p>This post talks about IMU alignment, but not the spacing:<br>\n<a href=\"https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135\" target=\"_blank\">https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135</a></p>",
  "messages": [
    {
      "id": "1838870",
      "postDate": "06/30/2022 23:00:09",
      "content": "<p>It seems like very few people have admitted to making use of IMU data and so maybe that could be a good approach (shh, don't tell anyone).</p>\n<p>EDIT:  I had the names of the 2 interpretations backwards.</p>\n<p>The timestamps reported in the device_imu files are mostly uniformly spaced but have variances.  For example, the GYRO data in 2020-06-04-US-MTV-1/GooglePixel4XL  has most measurement times spaced at 19 or 20 msec, but there are many that are as little as 5 msec and as much as 88 msec apart.<br>\n<img src=\"https://i.postimg.cc/CxMtVjg5/hist.png\" alt=\"hist.png\">](<a href=\"https://postimg.cc/KRVQP34h\" target=\"_blank\">https://postimg.cc/KRVQP34h</a>)</p>\n<p>My question is are these times to be interpreted as the measurement time or the reporting time?  Two interpretations:</p>\n<ol>\n<li>Reporting Time:  The IMU device makes constant rate measurements driven by a clock but the reporting hardware/software interface gets delayed.  In that case, a 10 msec measurement interval is really a 20 msec interval where the previous interval got reported late.</li>\n<li>Measurement Time: The IMU device makes measurements however it feels like (maybe taking time out for refreshing itself (coffee break 😄) and then reports the time of the measurement correctly.  This could include the case where some measurements are dropped, although this wouldn't explain a 5 msec interval.</li>\n</ol>\n<p>Given the IMU chipset specs, it seems unlikely that a 5 msec interval is correct.  Does anyone have any thoughts on this issue?</p>\n<p>This post talks about IMU alignment, but not the spacing:<br>\n<a href=\"https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135\" target=\"_blank\">https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135</a></p>",
      "rawMarkdown": "It seems like very few people have admitted to making use of IMU data and so maybe that could be a good approach (shh, don't tell anyone).\n\nEDIT:  I had the names of the 2 interpretations backwards.\n\nThe timestamps reported in the device_imu files are mostly uniformly spaced but have variances.  For example, the GYRO data in 2020-06-04-US-MTV-1/GooglePixel4XL  has most measurement times spaced at 19 or 20 msec, but there are many that are as little as 5 msec and as much as 88 msec apart.\n![hist.png](https://i.postimg.cc/CxMtVjg5/hist.png)](https://postimg.cc/KRVQP34h)\n\nMy question is are these times to be interpreted as the measurement time or the reporting time?  Two interpretations:\n\n1. Reporting Time:  The IMU device makes constant rate measurements driven by a clock but the reporting hardware/software interface gets delayed.  In that case, a 10 msec measurement interval is really a 20 msec interval where the previous interval got reported late.\n2. Measurement Time: The IMU device makes measurements however it feels like (maybe taking time out for refreshing itself (coffee break 😄) and then reports the time of the measurement correctly.  This could include the case where some measurements are dropped, although this wouldn't explain a 5 msec interval.\n\nGiven the IMU chipset specs, it seems unlikely that a 5 msec interval is correct.  Does anyone have any thoughts on this issue?\n\nThis post talks about IMU alignment, but not the spacing:\n[https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135](https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135)",
      "votes": null
    },
    {
      "id": "1838887",
      "postDate": "06/30/2022 23:58:13",
      "content": "<p>Just to make this more interesting, there are 2 lines one of the IMU files that look like this (same timestamp, different Accel Values)</p>\n<pre><code>UncalAccel    1591304364441   55004   2.724026    10.006568   0.9106898   0   0   0\nUncalAccel    1591304364441   55004   2.3340926   10.398838   1.1544678   0   0   0\n</code></pre>",
      "rawMarkdown": "Just to make this more interesting, there are 2 lines one of the IMU files that look like this (same timestamp, different Accel Values)\n```\nUncalAccel\t1591304364441\t55004\t2.724026\t10.006568\t0.9106898\t0\t0\t0\nUncalAccel\t1591304364441\t55004\t2.3340926\t10.398838\t1.1544678\t0\t0\t0\n```",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 1838887,
      "author_name": "solverworld",
      "author_url": "",
      "post_date": "06/30/2022 23:58:13",
      "content": "<p>Just to make this more interesting, there are 2 lines one of the IMU files that look like this (same timestamp, different Accel Values)</p>\n<pre><code>UncalAccel    1591304364441   55004   2.724026    10.006568   0.9106898   0   0   0\nUncalAccel    1591304364441   55004   2.3340926   10.398838   1.1544678   0   0   0\n</code></pre>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "1838870": "It seems like very few people have admitted to making use of IMU data and so maybe that could be a good approach (shh, don't tell anyone).\n\nEDIT:  I had the names of the 2 interpretations backwards.\n\nThe timestamps reported in the device_imu files are mostly uniformly spaced but have variances.  For example, the GYRO data in 2020-06-04-US-MTV-1/GooglePixel4XL  has most measurement times spaced at 19 or 20 msec, but there are many that are as little as 5 msec and as much as 88 msec apart.\n![hist.png](https://i.postimg.cc/CxMtVjg5/hist.png)](https://postimg.cc/KRVQP34h)\n\nMy question is are these times to be interpreted as the measurement time or the reporting time?  Two interpretations:\n\n1. Reporting Time:  The IMU device makes constant rate measurements driven by a clock but the reporting hardware/software interface gets delayed.  In that case, a 10 msec measurement interval is really a 20 msec interval where the previous interval got reported late.\n2. Measurement Time: The IMU device makes measurements however it feels like (maybe taking time out for refreshing itself (coffee break 😄) and then reports the time of the measurement correctly.  This could include the case where some measurements are dropped, although this wouldn't explain a 5 msec interval.\n\nGiven the IMU chipset specs, it seems unlikely that a 5 msec interval is correct.  Does anyone have any thoughts on this issue?\n\nThis post talks about IMU alignment, but not the spacing:\n[https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135](https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135)",
    "1838887": "Just to make this more interesting, there are 2 lines one of the IMU files that look like this (same timestamp, different Accel Values)\n```\nUncalAccel\t1591304364441\t55004\t2.724026\t10.006568\t0.9106898\t0\t0\t0\nUncalAccel\t1591304364441\t55004\t2.3340926\t10.398838\t1.1544678\t0\t0\t0\n```"
  },
  "source": "meta"
}