Main Site Documentation

Accellerometer max 120 hz


#1

I try to measure vibrations with a spider and a acellerometer. However, max sample frequency is about 120 hz or 9 ms.

Do you now how I can get faster measurements. Do you think the bottleneck is the sensor, communication or the spider. Can I upgrade to achieve better results?

Best Regards
Jon Andersson


#2

@ KaptenJon - what sample rate do you need?

Welcome to the community.


#3

I don´t know yet, and because I don’t know I want at least 1 khz possible more.

I will know after we analyzed the first data samples.


#4

What accelerometer are you using?


#5

I am using the one from GHI. Do you now a better one?


#6

the datasheed from the MMA8453 said:

800 Hz should be the default


#7

You have to differ between the internal sample rate of the chip, and how fast you can read.
The chip from the GHI module uses I2C I think.
So the 2nd limiting factor is bitrate and data size on I2C.
The 3rd limiting factor is NETMF. It’s not an real time environment.
You might consider using RLP to overcome NETMF restrictions. But I’m nut sure if there is an RLP I2C driver already included.
If you want an alternative sensor: go to the manufacturer sites of these chips and choose one of the thousands of available variants. These sites usually have quite good filter functionality.


#8

the I2C bitrate should be 400 kHz on spider so this should not the bottleneck


#9

The chip might have a lower bit rate. And a limitation on reading rate.
And since I2C always needs a call by the master, you also have response time from the chip.
But most likely NETMF is the bottle neck.
For example, sending a single packet (1 byte) over UDP (Ethernet) on G120 takes about 3 to 5ms.


#10

on the mbed E-Dice is the same chip, so i have a short test and get almost 680 Hz
(only reading the values, no processing)


#11

My guess is that 120 Hz in NETMF is unlikely, especially if you’re doing anything with the data. I haven’t tried it, but that’s my guess.


#12

that was what the OP’s experimentation gave. So I guess it’s possible :wink: The hope is to get above that - that I agree may not be possible, particularly if you intend to do anything with data…


#13

I really don’t need to do anything with the data. I don’t know know yet, but I think I will sample data for 3 seconds and then calculate the results. During data collection I store data on an already allocated data array.

So you think this is NETMF. any way to get around this issue? Could I maybe use an external device that captures data and send me prepared data. do you know any?


#14

Do you think this can succeed with a faster processor? I really like to still use NETMF.


#15

I guess a G400 based device might get slightly better rates. But to get really fast, you should really consider using RLP.
Did anyone use I2C from RLP already?


#16

[quote]I guess a G400 based device might get slightly better rates. But to get really fast, you should really consider using RLP.
Did anyone use I2C from RLP already?[/quote]

What is RLP?


#17

I found it,

However are you really sure simple reading will benefit from that?


#18

@ KaptenJon - The reading itself will probably not benefit much, if you use hardware I2C or the GHI SW I2C.
But you can setup exact timers (called Task in RLP) for your next reading.
Your next reading will be at the specified time, no matter what the managed scheduler is currently doing.
If the reading itself takes for example 3ms in RLP, you could setup an 5ms Task. By this managed code would still have some time to execute in between.
Also storing the result in an predefined buffer should be faster.
There is (or at least was) and audio sampling example in the documentation, which does more or less what you need, except that you read an I2C device instead of an analog input.
RLP gives you more or less “hard realtime” on an (GHI) NETMF device, which is per definition not realtime.


#19

Ok, Many thanks for all your advices!

At last, do you know if it possible to combine NETMF with RLP. and call RLP fuctions from NETMF.


#20

You are so good at answering that it is faster than searching :slight_smile: