rescale analog inputs

[kamocat]

Our analog inputs on the cRIO have a range from -10v to 10v.
Our accelerometer has an effective range from 0.6v to 2.4v
That's 9% of the full range, which means you get 9% of the full accuracy.

I was considering ways of rescaling it, and I was thinking a linear regulated 10v supply, a -10v supply, and an LM386 would be a good way to do it.

However, before I go out and buy anything, i wanted to check with you guys. Is there a simpler way to do this? Is there something I'm overlooking?

[EricVanWyk]

Originally Posted by kamocat

Our analog inputs on the cRIO have a range from -10v to 10v.
Our accelerometer has an effective range from 0.6v to 2.4v
That's 9% of the full range, which means you get 9% of the full accuracy.

I was considering ways of rescaling it, and I was thinking a linear regulated 10v supply, a -10v supply, and an LM386 would be a good way to do it.

However, before I go out and buy anything, i wanted to check with you guys. Is there a simpler way to do this? Is there something I'm overlooking?

I think the easiest thing to do is to use over-sampling. Are you really sure you need to throw hardware at it? If you are sure, there are circuits that remap one voltage range to another. I've done this for the day-job in a couple places; I have a MATLAB script I can send if you are interested.

I looked into doing something like this for the Analog Breakout. I ran into three major problems:
1) Cost.
2) Supplies.
3) Quantization vs Accuracy noise.

Cost:
Since you are one-offing this, I wouldn't worry about it too much. I couldn't design anything useful that was cost-effective in bulk. FIRST has a way different budget than medical products do.

Supplies:
To remap, you need rails that at least cover the range you are aiming for. Creating a clean (-10:10)V rail or even a (0:10)V rail on the robot is difficult, as it requires a boosting switcher of some sort. Boosts are really noisy on the output, and inverters aren't pretty either.

You could nudge the 24V rail up to 28V, filter it, and use a pair of precision LDOs to create the (-10:0:10V). The down-side is that this 0V wouldn't be ground referenced, which would cause serious issues if NI hadn't been so nice to isolate all of their cRIO modules.


Quantization vs Accuracy noise:
Here is the meat of the issue. You are recovering up to 3.4 bits of quantization, but you adding accuracy and high-frequency noise. 9% range on a 12bit ADC leaves 8.6 functional bits.

So the question is now "What is important to you?"


If you are only concerned with relative values, you are in good shape.

If you are concerned with the precise DC value, be careful. If the error exceeds .25%, it is a net loss. This includes all of the errors caused by the op-amp, the resistor dividers, whatever biasing reference you are using, and (possibly) the power supply rails. A lot of this can be compensated for by calibration, but that is a pain in the neck.

[daltore]

Not to mention, you have to compare the precision of the accelerometer to the precision of the cRIO. The DAC on the accelerometer probably outputs either an 8-bit or a 10-bit output. If it's a 10-bit output, then the values occupy 25% of the precision range of the cRIO, but 9% of the values, for a loss of -- well, somebody else can do the math, it's late. But my point is, if it's a 10-bit device, you will lose some data.

However, if it's an 8-bit output, the output precision range is only 1/16 that of the input range, so you have a voltage range that is 9% of the total, but a precision range that is 6.25% of the total. Since 9% is not a clean multiple of 6.25% there will be some error induced by thresholds not lining up, but effectively, you're not losing any data.

This is all assuming that you're not getting any EMF on the wire. As far as I've seen, there's a pretty big lack of consistency on analog devices just because of induced interference. If you're really worried about precision, a more accurate method may be either pulse-width modulation (also imprecise if the timers are not lined up, but on something as fast as the cRIO, that's not really an issue), or serial data (don't know which pins can be used as a serial bus other than the I2C port). An example would be these two, from Parallax and SparkFun:

http://www.robotshop.us/parallax-2-4...e-mma7455.html
http://www.robotshop.us/sfe-16g-trip...d-adxl345.html

At $35 and $28, these are well within the range of all of the other basic triple-axis accelerometers, and only require one connection to get all three axes, as opposed to connecting three independent analog lines. They can both use either SPI or I2C, so they might be perfect for our setup on the cRIO. Serial accelerometers go all the way down to around $20, but they're mostly 8-bit resolution at that point.

But as for scaling the voltage coming off of the one you have, you may or may not gain precision. If the accelerometer's resolution is high enough to warrant boosting the voltage, you have to account for the noise that will be incurred just by virtue of amplification. However, if the accelerometer's data precision is low enough anyway (8-bit), there's no reason to scale the voltage, because the V/G (volts per G) precision will not increase with mapping, it's a resolution problem at that point. If you are going to try scaling the voltage however, do use something with low losses. And don't worry about expanding into the - voltage range, usually accelerometers only have up to 10-bit resolution (most of the time, if yours is 12-bit, go for it if you can figure out a way), so that results in 1/4 of the cRIO's ADC resolution. That means if you got the voltage range past 5 volts, that's the maximum resolution you're going to get out of the device anyway. I think you're on the right path using an LM386, they have lots of nice features for this, like both a + and - input for resolution's sake, and an internal gain. Having all of these features in such a small package guards against interference. And don't forget the good impact of twisting your wires.

[Gdeaver]

For a long time First teams where complaining about the lack of hardware SPI or I2C on the IFI RC. Now we have it on the C_RIO. May be it's time to use it. The plus is that the manufacturer takes care of the conditioning for you. A 5 volt spi device would be nice.

[Jon Stratis]

It's not a bad idea to think about this, and think about how it could be improved... but might I suggest you do some tests first with the accelerometer on the robot, without any additional hardware? You may find that it's "accurate enough" for your needs.

One of the most common problems i see in computer programmers is that the program is never "done" - there's always something that can be improved, tweaked, or modified... An important part of engineering is determining when something is "good enough" and moving on to the next task.

[kamocat]

Well, the accelerometer I'm looking at is, in fact, not the KOP one, so I'm going to provide that datasheet instead:
http://www.analog.com/en/sensors/ine...s/product.html
(can be purchased here: http://www.sparkfun.com/commerce/pro...roducts_id=849)

It says the output is ratiometric; the output scaling is proportional to the voltage input. Does that imply it's a true analog device, without a DA converter?

[David Brinza]

In prior years*, the use of custom circuits have been allowed in FRC robots. This is an opportunity to use a simple operational amplifier (op-amp) circuit to apply gain and offset to the input and filter the signal to eliminate high frequency noise (i.e. motor/compressor vibrations, electrical power noise). Signal conditioning requires some care, but is not too complicated. Simple evaluation boards can be purchased from op-amp distributors (i.e Digi-Key), not to mention kits.

Have fun!

[spartango]

Watch out re:SPI

Last year (2009) our team bought SCA3000s from sparkfun(http://www.sparkfun.com/commerce/pro...d=8791)--wired them up to a a different device and had them working nicely with SPI...Gave us AMAZING accuracy btw..

Then we took them to the cRIO and started using the standard WPILibs...and we got junk...some careful work with a logic analyzer and oscilloscope revealed that WPILib's SPI library was reading the data at the wrong point on the wave, and because the Labview VIs for FPGA control are all locked we couldnt fix this. Further, our custom library(that worked on a DAQ, albeit a little slowly) for SPI was pretty much useless because we couldnt get microsecond precision timing to do the wave generation, and once again the FPGA was off limits...

I doubt the same problem will come up with I2C, but this was really sad for SPI...

[EricVanWyk]

Originally Posted by spartango

Watch out re:SPI

Last year (2009) our team bought SCA3000s from sparkfun(http://www.sparkfun.com/commerce/pro...d=8791)--wired them up to a a different device and had them working nicely with SPI...Gave us AMAZING accuracy btw..

Then we took them to the cRIO and started using the standard WPILibs...and we got junk...some careful work with a logic analyzer and oscilloscope revealed that WPILib's SPI library was reading the data at the wrong point on the wave, and because the Labview VIs for FPGA control are all locked we couldnt fix this. Further, our custom library(that worked on a DAQ, albeit a little slowly) for SPI was pretty much useless because we couldnt get microsecond precision timing to do the wave generation, and once again the FPGA was off limits...

I doubt the same problem will come up with I2C, but this was really sad for SPI...

The SPI driver saw some minor tweaks for this next year, hopefully that will cover your issue. However, I'm reasonably confident that the timing was correct. Perhaps you could give further details?

[daltore]

It's really hard for SPI to have timing issues, that was kind of the whole point of it being synchronous (although I don't disbelieve you, they probably didn't work too hard on the SPI libraries because they probably though no one would use them last year, and they would be easy to write ). Did you compare the two programs you had for the working controller and the cRIO to see if you initialized something incorrectly?