Orientation extremely slow?

Official Hardware Nicla Family Nicla Sense ME
1

I am absolutely stumped as to what I'm doing wrong. Using a Portenta H7 with the Nicla connected via Eslov. If SENSOR_ID_ORI is used, at all, BHY2Host.update() slows down to running at an average of over 400ms. Replicated with two different sets of Portentas and Niclas, so I'm thinking we just don't understand something.

Another oddity: if using SENSOR_ID_ORI, the temperature sensor can take longer than a minute to start reporting data.

Should we be using SENSOR_ID_DEVICE_ORI instead? What's the difference?

Portenta code:

#include "Arduino.h"
#include "Arduino_BHY2Host.h"

Sensor tempSensor(SENSOR_ID_TEMP);
SensorOrientation ori(SENSOR_ID_ORI);

void setup(){
    Serial.begin(19200);
    BHY2Host.begin(false, NICLA_VIA_ESLOV);
    tempSensor.configure(1, 0);
    ori.begin();
}

void loop() {
    BHY2Host.update();
    double temperature = tempSensor.value();
    Serial.print("Temperature: ");
    Serial.println(temperature);
    //Serial.println(String("Orientation values: ") + ori.toString());
}

Nicla code:

#include "Arduino.h"
#include "Arduino_BHY2.h"

void setup(){
    BHY2.begin(NICLA_I2C, NICLA_VIA_ESLOV);
}

void loop(){
    BHY2.update();
}
2

The plot thickens: It appears that SensorClass.h defines a default rate of 1000hz. However, something about that is broken.

ori.begin(1000) does exactly the same as previously, or about 400-500ms times. Passing 1 results in things running very quickly, more in line with what I would expect 1000hz to look like. Here's where it gets interesting: passing 10 starts out fairly quickly (sub 100ms), then rapidly slows down to >400ms. Passing anything under 10 seems to be stable and never slow down. Anything 10 or above reads quickly the first few times, then degrades to reading very, very slowly.

¯\(ツ)/¯ I'm lost.

1 Like
3

I know this was quite a while ago, but did you ever make sense of this? Running into the same thing and I'm equally puzzled if not more!

4

We ended up working around it. My memory is fuzzy, but it was something with the serial being slower than the polling rate? There's more to it, as the underlying library is doing something very weird that we never figured out.

The guy who ended up finding a good enough workaround said, "I made a uart commication function with error checking to communicate between the cards and I sent all the sensor data as packages, with start/stop identifier, symbol to separate values, and checksum."

I cant for the life of me remember how or why that resolved the issue.