Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Accelerometer - Digital or Analog Data Capture?

Status
Not open for further replies.

jpanhalt

Well-Known Member
Most Helpful Member
After several days of trying to break the serial code from my Sears inclinometer (discussed in previous posts), I have decided just to harvest usable parts and transplant them into a device of my own design.

The accelerometer I have is a Memsic 2020EL (100 Hz model). The output is a PWM signal. The duty cycle is proportional to the gravitational force. The Sears unit fed that signal directly to the MCU (an 8051F103). The datasheet gives an alternative way to capture the data by converting the PWN to an analog voltage with a low-pass filter and then using the MCU's A/D.

I am using the 12F683, which has a 10-bit A/D. Clock will be 4 MHz. My question is, which is better, the direct approach or the analog approach?

A very rough estimate of the accuracy of either method comes to about 0.1% (i.e., 1 part in 1024 for the D/A conversion per se), which is probably more than adequate for my purpose. Is there a difference in stability of the readings, settling rate, temperature-related drift, or any other factor to help make the decision? This is my very first experience with an accelerometer.

Thanks, John
 
Digital is better if you want to perform processing on the signal (such as generate a digital readout) but if you are happy with an analog signal then just do that.

If you use low drift op amps for any analog amplification and are careful about the layout to minimize noise then analog should work fine.
 
UPDATE

I received this response from Memsic this morning:

My recommendation and preference is the Analog output for the following reasons…

1) When using the PWM output you need to measure both the pulse width and the period with a timer resource that has enough precision. This usually results in having to manage counter overflows in the PIC and adds complexity especially if you are using one counter to measure both the pulse width and the period.

2) With the A/D you can quickly make multiple measurements and average them to reduce noise or add them to increase your effective bits or both, if needed.

If you have a really electrical noisy environment a PWM approach might be better, but in most cases that can be managed and A/D proves easier and provides better results.

John
 
"1) When using the PWM output you need to measure both the pulse width and the period with a timer resource that has enough precision. This usually results in having to manage counter overflows in the PIC and adds complexity especially if you are using one counter to measure both the pulse width and the period."

It looks like the guy that said that did not know much about using microcontrollers for digital signal measurement. :eek:

All you need to do to sample PWM accurately is to sample the digital input at a fixed period (any timer interrupt) and count the % of times the signal is Hi compared to the total. That will give you whatever resolution (and filtering) you need by just increasing the total number of samples.

So you sample 10000 times, if 5000 samples are HI the duty cycle is 50%.
 
Does that work if the PWM period changes significantly with temperature? That is the case with the Memsic accelerometers. Over the range of 25° to 40°C, the period increases about 115 uS. That equates to a few degrees tilt (10° of tilt produces an increase of 340 uS for the high time), which would not be acceptable in my application.

I played with measuring the whole period and making a linear correction for the change due to temperature to the high time. In other words, over the range I am using, subtracting half of the change due to temperature works well on paper, and avoids having to do multi-precision division. That approach has not completely been discarded, but I am currently looking at doing the calculation based on the ratio of high counts to total period counts.

What I have working now is quite simple. I use Timer1 (16 bit, 1:2 prescale, 8 MHz processor). I start the timer at the first high after the first low, stop it when input goes low, save that count, restart and count the rest of the period. Total period is 10,000 counts at 25° and duty cycle is 50% at level. The stop, save, start introduces about a 5 cycle error, which is insignificant and constant.

I posted the communication from Memsic merely as a follow-up for someone who might be searching on the same question. Memsic does offer analog-only accelerometers. As for the qualifications of the person who replied, Memsic is quite a small company, and I suspect most of the technical people at his level are fairly knowledgeable about the products.

John
 
Last edited:
Yep it works independent of period change provided of course each duty cycle is accurate within it's own period (whatever that period is).

Congrats on getting a solution the way you have done it will work fine too especially if you average a number of contiguous cycles.

... Memsic is quite a small company, and I suspect most of the technical people at his level are fairly knowledgeable about the products.

You are right of course and on re-reading my comment it does sound harsh, sorry about that. It's more likely he/she was allowing for people having electronics skills but maybe less skilled in microcontrollers, so it makes sense to suggest the analog solution as the general suggestion.
 
I see better what you are doing. You are sampling over many periods. In my case, the period is 10 mS, so I get approximately 10,000 samples per period. The coincidence of that number with your example led me to think erroneously that you were suggesting applying the method to a fixed period that could be less than a single period of the wave being measured. As I get more comfortable with the project, I may try something like you suggest to give me noise cancelling.

This is a bit OT, but that method of estimation can also be applied in business for cost accounting processes. That is, just take a flash picture at a fixed interval over several days. Then review the pictures and write down what everyone was doing at each instant. Since you know the total cost, you can calculate the fractional cost for each process. It should be easier, quicker, and more accurate than time-motion studies. The biggest hurdle is to convince those who have risen through the Peter Principle to accept the results.

John
 
Last edited:
I would suggest neither analogue or mark-space ratio, but use one of the I2C output sensors.

I've got some MXC6202 sensors if you want them. You should use quite high value pull-up resistors on the I2C lines, as the maximum output current on the MXC6202 is surprisingly small.
 
@Diver300,

Thanks for the offer. I suspect the final project will use a MXC6202 or its equivalent. Here is an except I got from Mr. Fennelly at Memsic:
The MXC6202GP is no longer available. Actually almost all the G suffix parts have been EOL’d as the M suffix covers all the G parts so we reduced our part numbers by eliminating the G variants. For this particular device there is a newer version, the MXC6232MP. I will be traveling for the next week so I may not be able to respond quickly to questions. Robert can probably help.

I do appreciate the offer, but but probably end up getting one from Memsic for not much more than the cost of shipping. I will let you know if that is a dead end.

John
 
@Diver300,

Thanks for the offer. I suspect the final project will use a MXC6202 or its equivalent. Here is an except I got from Mr. Fennelly at Memsic:


I do appreciate the offer, but but probably end up getting one from Memsic for not much more than the cost of shipping. I will let you know if that is a dead end.

John

Have you got a link to the data for the MXC6232MP? I would be interested in knowing what is different, and I couldn't find anything about it on the Memsic website.
 
No, I don't have a link. It may be a situation of one part of the company out of sync with the other. I will call on Monday and get back to you with what I find out.

John
 
I've seen this thread and your other thread on table reads for the inclinometer, may I ask what the final device does?

It sounds (from the table read) like you only need a coarse resolution inclinometer, which is an unusual application. Is it for a robotics tilt sensor or something?
 
I have a pallet forks attachment for the front-end loader (FEL) on my tractor. The geometry of most FEL's is such that the tilt angle changes as you raise and lower the loader. From the operator station it is difficult to tell whether the forks are level, say when you are sliding under something in the back of a pickup or on a loft in the barn.

This device will be attached by magnet to the back plane of the forks and transmit to the operator the amount of tilt. I need only a limited range and greater precision around zero. The forks are 42" long, so 1° of tilt = 3/4" of deviation at the tips, which is quite a bit when you are trying to slide under something. I could not find a level made with the particular orientation of axis's needed so it could be read from the operator station. The Sears unit I cannibalized for its accelerometer worked fine with a long piece of 4-conductor twisted pair connecting the sensor subunit to the indicator unit. This might not be as eloquent as that, but it is a lot more fun. Besides, it is too cold right now be be digging in dirt.

John
 
Cool! Thanks for the explanation. :)

Might I suggest a "fun" addition? If your tractor is on level concrete the single tilt sensor will represent tilt from horizontal and tilt from the tractor.

But if using on a slope etc the display will only accurately show the tilt from horizontal (and the palette and tractor share an identical slope which is not displayed or compensated).

Maybe you could add a second sensor on the tractor chassis, to show tractor tilt. Then you have options on the display to show both forks tilt to horizontal and forks:tractor tilt and even overall tractor tilt.

That way if the tractor and palette are both on a 3' tilt you could just set the forks to be in-line with the tractor chassis. Or if the tractor is on a 3' tilt and the pallete appears to be correctly leveled you set the forks to horizontal (and ignore tractor tilt).
 
As referenced above (post #9), here is the datasheet for the Memsic MXC6232 G/H/M/N accelerometer with I2C interface built in. I am posting here as it is not yet available on the Memsic site.

John

View attachment 60666
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top