BNO055 ODR & Read times

[abelsm2]

I've read (and learned a great deal from) a lot of your wiki. I have been playing with this sensor and was looking at the board on tindie and had a question on the ODR in fusion mode. Have you had any issues with the amount of time it takes to actually read the data out of the registers from this sensor? I am reading 26 consecutive registers to get quaternions, linear acceleration, etc, and the read time is all over the place from ~1 ms up to ~6 ms. With a 100 Hz ODR in fusion mode that seems kind of slow and is making my design difficult since I can't count on consistent timing and this sensor doesn't have a data ready interrupt.

[kriswiner]

The fusion mode only runs at 100 Hz; it's fixed.

What is your I2C rate? Try 400 kHz. What processor are you using? Try a Cortex M4 like a Teensy. Or STM32M4f.

-----Original Message----- From: abelsm2 [mailto:notifications@github.com] Sent: February 9, 2016 6:32 PM To: kriswiner/BNO-055 Subject: [BNO-055] BNO055 ODR & Read times (#4)

I've read (and learned a great deal from) a lot of your wiki. I have been playing with this sensor and was looking at the board on tindie and had a question on the ODR in fusion mode. Have you had any issues with the amount of time it takes to actually read the data out of the registers from this sensor? I am reading 26 consecutive registers to get quaternions, linear acceleration, etc, and the read time is all over the place from ~1 ms up to ~6 ms. With a 100 Hz ODR in fusion mode that seems kind of slow and is making my design difficult since I can't count on consistent timing and this sensor doesn't have a data ready interrupt.

Reply to this email directly or view it on GitHub https://github.com/kriswiner/BNO-055/issues/4 . https://github.com/notifications/beacon/AGY1qpeCDDEEC6fAhFIHqLQHoR2kvWmtks5 pipizgaJpZM4HW9sh.gif

[abelsm2]

I'm running I2C at 400 kHz on a Particle Photon (STM32F205).

If I poll the sensor at 100 Hz sometimes it takes ~1 ms to read 26 consecutive registers and sometimes the sensor seems to pull the I2C clock low for a while between individual bytes of a multiple byte read, and in those cases it can take up to ~6 ms to read the same 26 registers. I am just surprised it takes so long to get data out of the registers since it doesn't seem to leave much time to do anything with the data before you are ready to poll for the next batch of data. The inconsistency is also making it difficult to poll other sensors in a predictable way.

The breakout i'm using does some voltage conversions so you can use it with 5V and other things and I am wondering if that is part of my problem, which is why I was looking at the breakout on tindie... that one seems to be just the bare 3V3 essentials. I have a Teensy 3.2 I could try hooking up but i'm not sure the controller is the issue.

[kriswiner]

I don't know why you are seeing such latency. I haven't taken a good look at the BNO055 update rates. I too read 26 bytes but I usually output to a serial monitor at 2 Hz so I would never notice if there was jitter in the read times.

With an STM32 at 400 kHz bus speed you should see lightning fast reads. Hard to believe you could be bogged down by voltage translation circuitry unless the pullups are extremely weak or there is some other circuit error.

You must know that the BNO055 is really not a great solution simply because the underlying sensors are not the best, let's say.

Have you looked at the EM7180? It allows user-selectable quaternion update rates up to 400 Hz guaranteed and maybe higher if you want to push it. I haven't looked at the read timing or consistency, but I do know the heading accuracy at 2 degrees plus the warm start and use of MPU9250 data as input produces a consistently superior orientation solution.

Kris

-----Original Message----- From: abelsm2 [mailto:notifications@github.com] Sent: February 9, 2016 9:25 PM To: kriswiner/BNO-055 Cc: Kris Winer Subject: Re: [BNO-055] BNO055 ODR & Read times (#4)

I'm running I2C at 400 kHz on a Particle Photon (STM32F205).

If I poll the sensor at 100 Hz sometimes it takes ~1 ms to read 26 consecutive registers and sometimes the sensor seems to pull the I2C clock low for a while between individual bytes of a multiple byte read, and in those cases it can take up to ~6 ms to read the same 26 registers. I am just surprised it takes so long to get data out of the registers since it doesn't seem to leave much time to do anything with the data before you are ready to poll for the next batch of data. The inconsistency is also making it difficult to poll other sensors in a predictable way.

The breakout i'm using does some voltage conversions so you can use it with 5V and other things and I am wondering if that is part of my problem, which is why I was looking at the breakout on tindie... that one seems to be just the bare 3V3 essentials. I have a Teensy 3.2 I could try hooking up but i'm not sure the controller is the issue.

Reply to this email directly or view it on GitHub https://github.com/kriswiner/BNO-055/issues/4#issuecomment-182204232 . https://github.com/notifications/beacon/AGY1qieJ2tpO7xzpor8jR_iegl9pPsEzks5 pisFDgaJpZM4HW9sh.gif

[abelsm2]

I hadn't heard of it until I read one of your articles. I will definitely check it out. I need something that gives orientation but I am also looking for accel and gyro direct output to do some short distance motion tracking.

Your articles are awesome btw... keep up the good work!

[kriswiner]

The EM7180 auto calibrates the gyro such that at rest it reads 0, 0, 0 as it should. We have just implemented an accel calibration routine such that the calibration is stored in the EEPROM so it only has to be done once or at least very infrequently, same with the other parameters which can be fetched in a warm start mode. Makes it east to get calibrated (i.e., accurate) orientation as well as scaled sensor output from subsequent power on.

Kris

-----Original Message----- From: abelsm2 [mailto:notifications@github.com] Sent: February 10, 2016 10:27 PM To: kriswiner/BNO-055 Cc: Kris Winer Subject: Re: [BNO-055] BNO055 ODR & Read times (#4)

I hadn't heard of it until I read one of your articles. I will definitely check it out. I need something that gives orientation but I am also looking for accel and gyro direct output to do some short distance motion tracking.

Your articles are awesome btw... keep up the good work!

Reply to this email directly or view it on GitHub https://github.com/kriswiner/BNO-055/issues/4#issuecomment-182735343 . https://github.com/notifications/beacon/AGY1qhkHLz0mFFLQxRG3on-c0dwDfS-gks5 pjCEagaJpZM4HW9sh.gif

[FelipeSchneider]

First I would like to Thank you, Kriswiner, for your great work.

I have also faced problems with BNO055, I am reading multiple sensors and the latency of BNO is a big problem for me. I am using a custom board (Adafruit did not help me) with 1.5K pull-ups but the time to read the BNO varies from 1ms to 4ms (for 18 bytes). Change the baud to 100K also did not help me.

I have an M0+ (ATSAMC21E) and the most strange thing is that the BNO does not work when it is read by an I2C interruption (I am using ASF and waiting for the read interruption). The data is coming messed-up.

About the EM7180, buy it from Brazil is not really an option, I need to rely on goods from mouser or digikey, so I pay taxes and delivery only once... (you know, small budget).

[kriswiner]

This is confusing to me. Are you ising I2C or UART to read from the BNO055?

The BNO055 doesn't have a data ready interrupt capability. All of the interrupts are for certain motion detection I believe.

Perhaps there is a problem with the MCU but normally I2C reads and writes happen on microsecond time scales, not milliseconds.

If you want to buy some EM7180 from me i could sell them to you at $2 each.So if you order an EM7180 breakout board and tell me how many of the EM7180 you want I can put them in the same package, for example.''Kris

On Fri, Oct 27, 2017 at 4:47 AM, FSchneider notifications@github.com wrote:

First I would like to Thank you, Kriswiner, for your great work.

I have also faced problems with BNO055, I am reading multiple sensors and the latency of BNO is a big problem for me. I am using a custom board (Adafruit did not help me) with 1.5K pull-ups but the time to read the BNO varies from 1ms to 4ms (for 18 bytes). Change the baud to 100K also did not help me.

I have an M0+ (ATSAMC21E) and the most strange thing is that the BNO does not work when it is read by an I2C interruption (I am using ASF and waiting for the read interruption). The data is coming messed-up.

About the EM7180, buy it from Brazil is not really an option, I need to rely on goods from mouser or digikey, so I pay taxes and delivery only once... (you know, small budget).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/BNO055/issues/4#issuecomment-339949743, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqnsNw4OpF2A61muIryTWKcBwCH4ks5swcLtgaJpZM4HW9sh .

[FelipeSchneider]

I am using I2C to read the BNO, about the interruption, I mean inside the microcontroller (my ARM) but it was an ASF problem and I solved it. Let me try to explain it a little: If you make a blocking write (to tell from which register you want to start reading) and make a non-block reading, the ASF repeats the start command and the first I2C byte... But I guess this is not important to this discussion.

The fact is that the BNO has a big jitter and it does a huge impact in the system final performance, you might put an oscilloscope and a blinking led to measure the final transfer time.

About the EM7180, I would like to buy 2 of them, can you send it as a letter to Brazil?

[kriswiner]

Generally the post office here will not accept letters if they contain objects like IMU boards. You will have to pay the usual $14.95 postage for a padded envelope I am afraid.

On Sun, Oct 29, 2017 at 1:41 PM, FSchneider notifications@github.com wrote:

I am using I2C to read the BNO, about the interruption, I mean inside the microcontroller (my ARM) but it was an ASF problem and I solved it. Let me try to explain it a little: If you make a blocking write (to tell from which register you want to start reading) and make a non-block reading, the ASF repeats the start command and the first I2C byte... But I guess this is not important to this discussion.

The fact is that the BNO has a big jitter and it does a huge impact in the system final performance, you might put an oscilloscope and a blinking led to measure the final transfer time.

About the EM7180, I would like to buy 2 of them, can you send it as a letter to Brazil?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/BNO055/issues/4#issuecomment-340292574, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qppGYFLN5QpgEor7EwnnridmFXHFks5sxOL0gaJpZM4HW9sh .

[FelipeSchneider]

So how can I pay you?

[kriswiner]

Go to this site and order:

https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/

On Tue, Oct 31, 2017 at 5:03 AM, FSchneider notifications@github.com wrote:

So how can I pay you?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/BNO055/issues/4#issuecomment-340742089, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm5fFcQThY3WyNfY18fi5tRbNpYuks5sxwyigaJpZM4HW9sh .

[khalilst]

I've reading BNO055 data registers in the following order in fastest data output rate:

1. bno055_read_euler_hrp(&eulerData); //Took 2 ~ 4 ms
2. bno055_read_linear_accel_xyz(&acc); //Took 1 ~ 3 ms
3. bno055_read_gyro_xyz(&gyro); //Took 1 ~ 3 ms

In worst case it sometimes took 11 ms ( < 100 Hz). Consider I didn't read other data registers and my Arduino code needs to do something else. Does somebody have any solution to speed up I2C speed using BNO055? Thanks in advance

[kriswiner]

The first two are only available at a fixed 100 Hz rate.

On Sun, Sep 2, 2018 at 7:02 AM Khalil Laleh notifications@github.com wrote:

I've reading BNO055 data registers in the following order in fastest data output rate:

1. bno055_read_euler_hrp(&eulerData); //Took 2 ~ 4 ms
2. bno055_read_linear_accel_xyz(&acc); //Took 1 ~ 3 ms
3. bno055_read_gyro_xyz(&gyro); //Took 1 ~ 3 ms

In worst case it sometimes took 11 ms ( < 100 Hz). Consider I didn't read other data registers and my Arduino code needs to do something else. Does somebody have any solution to speed up I2C speed using BNO055? Thanks in advance

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/BNO055/issues/4#issuecomment-417933019, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qp8JWOUWG0h1as_U6_d9Pdoi6Mxkks5uW-T2gaJpZM4HW9sh .

[khalilst]

I was talking about slow i2c. I know its working on 100 Hz.

Let me add no.4 to my previous comment:

4. delay(10);

[FelipeSchneider]

Apparently, BNO is a great SoC, but it has its problems, and the need of clock stretching is definitely one of them. I have been working with it for a while and still have not find a way to solve this issue. If you do not stretch, the BNO fails in communicate. Probably this is because it has only a M0 running inside and it takes to long to fuse the inertial and magnetic data...