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?
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.
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.
that was what the OP’s experimentation gave. So I guess it’s possible The hope is to get above that - that I agree may not be possible, particularly if you intend to do anything with data…
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?
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]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]
@ 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.