Synchronization of multiple ISM330DHCX

[JVinc.1]

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.

[Eleon BORLINI]

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]

> 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]

@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.

[Ozone]

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.

[JVinc.1]

@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.

[Ozone]

> 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.

[JVinc.1]

Sensor hub feature is not useful in my case; since it doesn't provide independence of sensors.

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

This would be best option for synchronization but I couldn't find a part. Do you know any?

[Eleon BORLINI]

Hello @JVinc.1​ ,

any news about your issue?

-Eleon

[JVinc.1]

Unfortunately I haven't tested yet. I am currently develeoping firmware; it may take some time.