# Retrieve a Buffer of Data from BMI160 **URL:** \ **Category:** Build your own\ **Created:** [June 5, 2019, 6:32pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687 "2019-06-05T18:32:00Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![dbeckwith](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dbeckwith/32/2139_2.png) [@dbeckwith](https://mangoh.discourse.group/u/dbeckwith)\ **Post date:** [June 5, 2019, 6:32pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/1 "2019-06-05T18:32:01Z")
I would like to retrieve a buffer of data from the BMI160 instead of just single samples. Is this possible? If so how would I go about doing it from user space? Thanks ---
**Author:** ![dfrey](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dfrey/32/303_2.png) [@dfrey](https://mangoh.discourse.group/u/dfrey)\ **Post date:** [June 6, 2019, 5:07pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/2 "2019-06-06T17:07:59Z")
There’s a `bmi160_fifo` branch in the mangOH repository that takes a stab at this. There is also this corresponding app which performs a read. [https://github.com/mangOH/mangOH/tree/bmi160\_fifo/samples/BufferedImuRead](https://github.com/mangOH/mangOH/tree/bmi160_fifo/samples/BufferedImuRead) I haven’t looked at this stuff in a little while, so I don’t remember the exact status of it all. ---
**Author:** ![dbeckwith](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dbeckwith/32/2139_2.png) [@dbeckwith](https://mangoh.discourse.group/u/dbeckwith)\ **Post date:** [June 6, 2019, 6:44pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/3 "2019-06-06T18:44:44Z")
@dfrey Thanks for pointing that out. I quickly reviewed it and I have some followup questions. First, context. I’m trying to access, from user space, the trigger buffer of data that was captured when the interrupt fires. This should have the significant motion event. Once I have this buffer then I plan on performing some analysis in the user space. 1. Is libiio the only way to access the trigger buffer from user space? 2. The branch you pointed me to requires LIBIIO. I’m working with the WP85 module which doesn’t have the IIO builtin by default. Is LIBIIO compatible the WP85 as long as I am building in IIO? 3. Currently our BMI160 driver is set to generate interrupts on significant motion. When this happens a buffer is captured in IIO. Can’t I just call fscanf in a loop and read the contents of the buffer? Thanks ---
**Author:** ![dfrey](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dfrey/32/303_2.png) [@dfrey](https://mangoh.discourse.group/u/dfrey)\ **Post date:** [June 6, 2019, 8:18pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/4 "2019-06-06T20:18:42Z")
The bmi160 driver sits on top of the IIO kernel framework. On wp85/75, IIO wasn’t built with the kernel. As a result, we pulled some of that code out of tree and built it as modules and bundled those modules with the Legato system. libiio is a userspace library for accessing IIO devices. It provides convenience over manually traversing `/dev` and `/sys/bus/iio`. It’s not “magic” though, so anything you do with libiio _can_ be achieved without it. When I worked on the buffered reading for bmi160 I was focusing exclusively on the wp76. I don’t recall if all the necessary IIO kernel modules are provided for wp85/75. ---
**Author:** ![dbeckwith](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dbeckwith/32/2139_2.png) [@dbeckwith](https://mangoh.discourse.group/u/dbeckwith)\ **Post date:** [June 6, 2019, 8:28pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/5 "2019-06-06T20:28:40Z")
@dfrey Thanks will dive in and give it a try. You mentioned here the [Using Accelerometer on MangOH Red](https://mangoh.discourse.group/t/using-accelerometer-on-mangoh-red/1716/8) the the bmi160\_fifo requires an unpublished kernel change. Can you elaborate further? ---
**Author:** ![dfrey](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dfrey/32/303_2.png) [@dfrey](https://mangoh.discourse.group/u/dfrey)\ **Post date:** [June 6, 2019, 8:33pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/6 "2019-06-06T20:33:03Z")
Unfortunately, I have forgotten what I was referring to. Let me know if you find that something is missing when you try to put this together. It may jog my memory. ---
**Author:** ![ktanikel](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@ktanikel](https://mangoh.discourse.group/u/ktanikel)\ **Post date:** [June 13, 2019, 11:18pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/7 "2019-06-13T23:18:38Z")
Sorry if I’m late to the party, but we had pretty much the same requirement of needing chunks of data from the accelerometer instead of single samples. I tried David’s bmi160\_fifo branch, but wasn’t very familiar with IIO so ended up ditching that effort. Instead I switched to using the BMI160’s onboard FIFO to get a thousand samples every 250ms. You can tie the FIFO interrupt to your application so you know exactly when the FIFO’s full. I switched out the kernel module for BMI160 and instead used a user space driver from Bosch [https://github.com/BoschSensortec/BMI160\_driver](https://github.com/BoschSensortec/BMI160_driver) to achieve this. ---
**Author:** ![dbeckwith](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dbeckwith/32/2139_2.png) [@dbeckwith](https://mangoh.discourse.group/u/dbeckwith)\ **Post date:** [June 14, 2019, 4:14pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/8 "2019-06-14T16:14:58Z")
@ktanikel Better late than never, right 😉 Thanks for the tip I will consider doing that instead. ---
**Author:** ![dfrey](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dfrey/32/303_2.png) [@dfrey](https://mangoh.discourse.group/u/dfrey)\ **Post date:** [June 17, 2019, 10:57pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/9 "2019-06-17T22:57:34Z")
The bmi160\_fifo branch uses both an IIO kernel FIFO and the bmi160’s hardware FIFO. The idea was to sample continuously and service the buffers quickly enough such that they would never overflow. ---
**Author:** ![Redferne](https://avatars.discourse-cdn.com/v4/letter/r/a9a28c/32.png) [@Redferne](https://mangoh.discourse.group/u/Redferne)\ **Post date:** [April 21, 2020, 1:51pm UTC](https://mangoh.discourse.group/t/retrieve-a-buffer-of-data-from-bmi160/2687/10 "2020-04-21T13:51:26Z")
Very late to the party… Having issues with a WP77xx and the fifo branch. It bombs out here: ``` if (devm_gpio_request_one(&pdev->dev, CF3_GPIO32, GPIOF_DIR_IN, "gpio expander")) { dev_err(&pdev->dev, "Couldn't request GPIO expander interrupt GPIO"); ret = -ENODEV; goto cleanup; } root@swi-mdm9x28-wp:~# [130.757302] mangoh red mangoh red: Couldn't request GPIO expander interrupt GPIO [130.764558] Unable to handle kernel NULL pointer dereference at virtual address 0000007c [130.771828] pgd = c8318000 [130.774424] [0000007c] *pgd=00000000 [130.777984] Internal error: Oops: 5 [#1] PREEMPT ARM [130.782926] Modules linked in: mangoh_red(O+) tem32j(O) ltc294x(O) led(O) bq27xxx_battery(O) bq24296(O) bmi160_i2c(O) bmi160(O) [last unloaded: bmi160] ``` Yes. It was caused by the GpioExpanderService trying to claim the same IRQ 🙂 Now I’m seeing this: Jan 6 04:19:29 swi-mdm9x28-wp user.info Legato: INFO | imu[1912]/imuComponent T=main | main.c ReadImu() 65 | Got channels (anglvel\_x, anglvel\_y, anglvel\_z, accel\_x, accel\_y, accel\_z, timestamp) Jan 6 04:19:34 swi-mdm9x28-wp user.emerg Legato: _EMR_ | imu[1912]/imuComponent T=main | main.c ReadImu() 90 | Failed to refill buffer: Invalid argument Any pointers?