cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization of multiple ISM330DHCX

JVinc.1
Associate III

Hello,

I need to use dual MEMS (ISM330DHCX) and MCU in my application for redundancy. Each MEMS is connected to a different MCU with independent supply. The data collected from sensors will be crossed checked if within a predefined tolerance. I think the MEMS may have different boot time and clock. What's the best way to synchronize them? Thanks in advance.

14 REPLIES 14
Eleon BORLINI
ST Employee

Hi @JVinc.1​ , please refer to this little discussion that may be of your interest.

The first (naive) suggestion could be to synchronize the two device chip select CS lines (and to dispose the same track length from the processor to the accelerometers on the application board), to start the acquisition in the same time, after the register configuration.

But in case of any SPI-timing issues, I believe you should synchronize the acquisition starting from a common detected external event (an impulse-like mechanical event) that can be recognized by the two sensors with enough accuracy. From that event, the two acquisition can be considered running together.

As a side suggestion even if I see it's not your case, the ISM330DHCX device, you may also use the sensor hub feature, that enables you to connect sensors together and synchronize them. You can for example trigger the data write in the FIFO of one of the sensor sensor by the sensor hub data-ready signal. You can find here some C example code for the sensor hub feature usage.

-Eleon

Ozone
Lead

> What's the best way to synchronize them?

That synchronisation relates to the signal you want to measure, i.e. it's bandwidth.

I would say, evaluate your bandwidth requirements and jitter tolerance, before going into overly complex SW/HW designs.

> The data collected from sensors will be crossed checked if within a predefined tolerance.

This does not necessarily require the sensors to be connected to different MCUs.

JVinc.1
Associate III

@Eleon BORLINI​ 

Thanks for the suggestion. I assert CS only when INT1 data ready flag set for reading measurement data. I guess you mean writing the ODR value to registers (CTRL1, CTRL2) in the same time to synch chips. Is that correct? I can not use hub feature to avoid any interference between two subsytem.

@Ozone​ 

I need to get typ. 400Hz, max . 1600Hz ODR. In my application connections from MEMS should be fully independent.

I mean, what is the actual effect of synchronisation jitter on the sampled values, i.w. what error would that introduce ?

> In my application connections from MEMS should be fully independent.

Which still does not automatically imply they are connected to different MCUs.

At my job, I am dealing with safety-related ECUs, usually having two MCUs/cores as well.

Safety-related IOs are usually two individual channels combined, just as yours. However, they can be sampled by one MCU instance, and transferred/checked by the other. Communication protection methods like running number and CRC are considered reasonably safe.

Another option would be some glue logic to trigger the sampling by one MCU, and read-out by the two separate MCUs. I'm no hardware guy, though.

Hi @JVinc.1​ 

>> I assert CS only when INT1 data ready flag set for reading measurement data. I guess you mean writing the ODR value to registers (CTRL1, CTRL2) in the same time to synch chips. Is that correct? 

Suppose you have 4 sensors: you should connect them to the same application processor through 4 different SPI lines. You may manage these lines "in parallel" via firmware. You can initialize all the sensors in sequence (same ODR for all), but you have to run the data acquisitions in parallel. Please note that you could have a jitter on the INT1, since the actual ODR can be slightly different from the nominal ODR, as reported by @Ozone​ too. For this reason, an active synchronization of the 4 CSs from the uC is suggested (for example 4 GPIOs from the same hw port). SPI speed must be >> of the ODR speed.

-Eleon

I am working with ECUs for heavy machinery, based on CAN bus devices and a 10ms base cycle.

A jitter of hundreds of microseconds or even a few milliseconds occasionally is of no big concern.

My point - you need to taylor it to the acceptable limits of your application.

JVinc.1
Associate III

@Ozone​ 

The error due to synchronization may be huge in case of a shock-high vibration event if data acquisition doesn't start simultaneously. In real application this is the situation. The sensors may not start acq. exactly in the same time also there is difference in parts due to process variations. In order to compensate it the difference between two sensors will be regarded as fault if it is longer than a certain time and greater than a predefined value. My goal is to sync them as much as possible to minimize the difference and the time for it.

In some applications it may be useful to use only one of the MCUs to read data from both sensors and the other MCU for calculations and comparison as a test equipment. From the safety perspective, it depends on the designated architecture of the system. As you work with devices for heavy machinery, you should be aware of the categories defined in ISO 13849. My MCU has multiple SPI modules which allows separation of buses but on-chip redundancy sometimes not desired due to an abnormal voltage/temperature rise on this part may result in fail of whole system.

@Eleon BORLINI​ 

As I understand, you are talking about sync of CS lines using same HW port. That's OK. By doing this, will the start of acq. also be in sync for MEMS parts? From the datasheet, the output of the sensor is updated automatically at a rate defined by the ODR value. As I know, It doesn't depend on an external trigger or event. Since exact ODR will be slightly different for each part due to process variations and also the internal clock for parts will drift slightly, there will be always difference. Can you explain further? Thanks.

> My goal is to sync them as much as possible to minimize the difference and the time for it.

I would not consider triggering two sensors individually by serial interface (SPI/I2C) a deterministic method.

Superficially checking the datasheet, I saw an option "Sensor hub trigger signal selection; START_CONFIG = 1: sensor hub trigger signal external from INT2 pin".

Otherwise I would consider looking for a sensor with external sample trigger input.

Hi @JVinc.1​ ,

>> By doing this, will the start of acq. also be in sync for MEMS parts?

The internal sensor electronics (ASIC) samples the MEMS varying voltage at a frequency much higher than ODR (i.e. corresponding to internal clock, >MHz): when ODR is configured at register level, the internal clock tree is properly set and the sensor logic averages the acquired values a number of time almost equal to internal clock frequency / ODR. Please consider that the max ISM330DHCX ODR goes up to 6.66kHz, and that at this frequency you can have maximum 1/ODR mismatch in interrupt mode... how much frequency resolution do you need?

-Eleon