Memsic 2125 Angular Resolution
All,
Thank you for your replies and suggestions.· Before I realized that Parallax sold the Memsic 2125, I had placed an order for a SignalQuest Inclinometer (price $250+shipping).· I am not an expert in this field by any means, however I think that my problem with the SignalQuest device was that it ouput data in packets of 10 bytes where I was only interested in bytes 2, 3, 4, and 5 (xtilt HIGH, xtilt LOW, ytilt HIGH, and ytilt LOW, respectively).· I was using a SERIN command to acquire the output and then using only the bytes that I needed.· In doing so, I was filling up an array of·BYTES which was taking up a large portion of my 26 bytes of RAM.· I may have been able to throw away or skip over the output that I did not want to store, but I was not yet quite there.· I do not think that I could have used a PULSIN command for this device either.
In contrast, I placed an order for a Memsic 2125 yesterday late afternoon and I am very confident that this will provide me with the information I need.· No more need for the huge RAM overhead involved in storing the array of bytes.· There is much more documentation out there and much more knowledge in-house (thanks Dave Andreae).· I am very carefully going through the documentation from Smart Sensors and Applications and am trying to understand every aspect of the use of this device.
So far, I think that the only problem I may have is resolution.· I am wondering if rather than scaling down from 1875 to 3125 to·0 to 255·and then back up to 0 to 359, if I can scale directly from 1875 to 3125 to 0 to 359.· In fact, can I get more resolution from the output by multiplying by 100 in order to preserve the .XX that gets truncated in the roundoff during the scaling process?
Thanks,
Neal
Thank you for your replies and suggestions.· Before I realized that Parallax sold the Memsic 2125, I had placed an order for a SignalQuest Inclinometer (price $250+shipping).· I am not an expert in this field by any means, however I think that my problem with the SignalQuest device was that it ouput data in packets of 10 bytes where I was only interested in bytes 2, 3, 4, and 5 (xtilt HIGH, xtilt LOW, ytilt HIGH, and ytilt LOW, respectively).· I was using a SERIN command to acquire the output and then using only the bytes that I needed.· In doing so, I was filling up an array of·BYTES which was taking up a large portion of my 26 bytes of RAM.· I may have been able to throw away or skip over the output that I did not want to store, but I was not yet quite there.· I do not think that I could have used a PULSIN command for this device either.
In contrast, I placed an order for a Memsic 2125 yesterday late afternoon and I am very confident that this will provide me with the information I need.· No more need for the huge RAM overhead involved in storing the array of bytes.· There is much more documentation out there and much more knowledge in-house (thanks Dave Andreae).· I am very carefully going through the documentation from Smart Sensors and Applications and am trying to understand every aspect of the use of this device.
So far, I think that the only problem I may have is resolution.· I am wondering if rather than scaling down from 1875 to 3125 to·0 to 255·and then back up to 0 to 359, if I can scale directly from 1875 to 3125 to 0 to 359.· In fact, can I get more resolution from the output by multiplying by 100 in order to preserve the .XX that gets truncated in the roundoff during the scaling process?
Thanks,
Neal
Comments
I really like the Memsic 2125! It is so easy to use.
In my little play-time experiments with it, I have not found a need to perform scaling. Perhaps, someone will jump in and tell me why it is necessary in the first place if you do not display the inclination numbers it produces.
This is how I use it . . .
I mount it in a breadboard such that I am confident it is fully inserted. Then, I take a small bubble level to the breadboard to "zero" it. Whatever number the Memsic 2125 displays with DEBUG is "zero" to me. Then I write just a very few lines of code that will only react when the tilt deviates from my original zero number by whatever number I choose.
I plan to implement the same scheme in a walker or a roller, as well. I don't see what is wrong with the idea unless the application is DESIGNED to display the degree of tilt.
Like I said, maybe someone will tell me why this is not a good idea. It certainly saves coding.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The input resolution is 3125-1875 = 1250 units of acceleration in the x and y axes, which is around 0.1%, and with a little trickery it should be possible to preserve that through to your final answer, although the resolution will be distorted due to the mapping of the trig functions. In one of your questions
http://forums.parallax.com/showthread.php?p=652084
you asked how to preserve the resolution so as to scale the MEMSIC output on a scale of -90.00 to +90.00. Smart Sensors shows how to scale it from -100 to +100 (hundreths of a G force) and alternatively from -127 to +127, both of which discard about 1/10 of the input resolution. Of course the -90.00 to +90.00 result I showed you is not in units of degrees. It is in units of acceleration (Gs), which amounts to the SIN or COS components of gravity acting on the sensor.
The next step is to convert to units of degrees while maintaining the 0.1% resolution. One way would be to add floating point capabilities, and you can indeed do that with the Micromega floating point processor that Parallax sells as an adjunct to the BASIC Stamp. You would pass the values to the coprocessor, and it would return the result either in several steps or as one preprogrammed formula.
If instead you want to slog along with the integer math and use the built-in low resolution (~1%) ATN, SIN and COS functions, think interpolation. What you do is scale the MEMSIC output into the range of -511 to +511, which maintains the resolution, and then divide that by 4 to get to the range of -127 to +127 and also a remainder from -3 to +3. Take care when the number is negative. The ATN function take arguments in the range of -127 to +127, and returns an angle in brads from 0 to 255. Then convert that answer to degrees using */ 361. All that is explained in Smart Sensors. Then you use the remainder -3 to +3 as the basis of linear interpolation, to stick in the decimal point and a fractional part in units of 0.25. So you end up with a resolution of 360*4 = 1440, which is comensurate with the input resolution. That is a road map. There are devils in the details that take more thought and trial and debugging.
Another possibility would be to use a higher resolution algorithm like the CORDIC methods that I have posted on my web site, but those too require an familiarity with integer math and scaling. If you anticipate a lot of math in your project and prefer not to slog through it, the coprocessor would really be a good investment.
Note that the resolution here is ultimately determined by the PULSIN resolution of the BASIC Stamp. If you use a faster Stamp like the BS2p, you could get a larger span to work with. I don't know offhand the intrinsic precision of the MEMSIC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 5/26/2007 1:43:33 AM GMT
Thank you very much for all of this information. I tend to stay away from the heavy number crunching and will definitely investigate the Micromega floating point processor. I found another inclinometer online from VTI Technologies (search for VTI at www.digikey.com). This device has analog output. Coupled with a ADC0831 A/D converter, I am going to give this a shot for a short term quickfix solution to this problem. The VTI has a +/-10 degree range which allows me to better capture the resolution that I need for this problem. In addition, the output is directly proportional to the tilt. I will let you know how this works out. Thank you again for your time and suggestions. I will surely investigate these possibilities further as I move forward.
Sincerely,
Neal Rosenblum
Just as an aside about the MEMSIC, if you only need the range of +/- 10 degrees, a linear approximation to SIN or ATN would work pretty well within the 0.1 degree resolution. This is because SIN(x) ~= x, for tilt from a horizonatal plane, or TAN(x) ~= x for rotation of the MEMSIC around the vertical plane. The error at 10 degrees is about 0.05 degree. What this means is that it only takes one ** operator to convert from the MEMSIC reading to tenths of a degree. Empirically, you take the change in PULSIN reading from 0 degrees to 10 degrees, say it is "result". Then on a calculator find the ** multiplier,
K = 65536 * 100 / result
Then in the program enter that multiplier,
tenthsDeg = MesicReading ** K
That is assuming result is >100. I think it is. If not, the equation would need another whole factor of the memsicReading.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com