5V sensors with Maple analog input

LeafLabs Garden » Support » Maple Hardware Support

5V sensors with Maple analog input

(30 posts) (5 voices)

Started 5 years ago by Silntknight
Latest reply from larryang

12 Next »

Silntknight
Moderator

How can I interface analog sensors that run on 5V (like the LM335A temperature sensor and the MPX4250A pressure sensor) with the Maple's 3.3V maximum analog inputs. I also have a potentiometer, but because that is read based on the difference from a reference voltage, I think it will work anyway. I know I can provide 5V power to the devices because I designed a 5V regulator that powers the board (though USB). I am connecting all these devices through the Vin on the Maple board. I have seen transistors and the like that can step down 5V to 3.3V, but they are all for power supply purposes and would provide a stable 3.3V when I need it to fluctuate. Any idea would be helpful.

EDIT: In doing some more reading about this, I found that I might be able to run the temperature sensor off of 3.3V because it calibrates directly into Kelvin based on voltage multiplied by 100. If I can run all of these sensors on a 3.3V input, then should I still use a 5V regulator to provide 5V to the Maple, or could I connect a car 12V battery directly to the external supply and let the Maple handle the regulation?

EDIT: I also found that I could use a voltage divider. If I put a few trimpots on the signal lines and calibrate them to output 3.3V with a 5V input, would that work?

Posted 5 years ago #
okie
Administrator

Silntknight: "could I connect a car 12V battery directly to the external supply and let the Maple handle the regulation?"

Yes, Maple gives you a regulated 3.3V on VCC and VIN is the external supply minus 0.6V from the protection diode, so you could connect VIN to a 5V regulator for your sensors if you need it.

Posted 5 years ago #
gbulmer
Moderator
Try two resitors, as a voltage divider.
```
---->-- sensor output ---->--+
                             |
                             \
                             /  R1
                             \
                             /
                             +--------> into Maple ADC
                             |
                             \
                             /   R2
                             \
                             /
                             |
-----------------------------+------ Ground
```
The 5V maximum (from the sensor) appears across R1+R2,
a fraction of that voltage R2/(R1+R2) appears across R2, so the ratio of R1 to R2 is roughly 2 to 3. I'd look at the output current the sensor can drive to choose the right values.

You could use a trimpot where the resitor of the pot is R1+R2, and the wiper contact is the middle connection to a Maple ADC input. If you have a voltmeter, you could adjust it so that it is under 3.3V for a maximum output from a sensor.

Again, you need to check that the total resistence is high enough that the sensor can drive enough current to make it all work.
Posted 5 years ago #
poslathian
LeafLabs

nice ascii circuit, youve set bar a higher around here!

Posted 5 years ago #
gbulmer
Moderator

Well, I'll use Fritzing once someone has done a nice version of Maple for it (hint, hint ;-)

Posted 5 years ago #
Silntknight
Moderator

Thanks so much guys. I did also think of a voltage divider (upon closer inspection of the analog input article on the Maple documentation). Originally, I hadn't wanted to do that because the shield I was making for it wasn't able to hold everything plus 4 resistors (one sensor already has a trimpot), but then I redesigned the circuit a little bit and went with two trimpots instead of the resistors. Now it all fits and I can adjust as necessary. Also, thanks for the warning about making sure that the current is high enough. I think I'll just go trial-and-error on that, but I only need 3k total resistance (R1+R2) to go from 5V to 3.3V.
By the way, that is a really good ASCII circuit!

EDIT: Okie, you said that Vin is 0.6V less than the input? I made a small 5V regulator that connects to the car battery and outputs through USB. I was planning on using that for power because I thought Vin was a direct output of the board's power input. If this isn't true, as you said, then it would mess up my circuit A LOT! What would you recommend? I am pretty sure that the pressure sensor would have trouble with 4.4V. Should I go battery--->Maple--->5V regulator from Vin--->sensors or leave it as battery--->5V regulator--->Maple--->sensors from Vin?

Posted 5 years ago #
poslathian
LeafLabs

Silntknight,
The Maple power circuit looks something like this (im not including the battery charger circuit or the dual analog/digital regulators):

Battery ---------------| |----\
External Jack ---------|Jumper|-----|-----------[REGULATOR]--->Vcc
USB Power -------------| |----/ |
------>Vin

As you can see, Vin is simply whatever you put in and select with the jumper, it could be 15V from external power, or 5V from USB. Note that if you removed the jumpers, you could ostensibly dump power IN to Vin, which we do sometimes when stacking two Maples together. Vcc is the regulated 3.3V supply.

Point being, based on what youve described, I think youre good!

Posted 5 years ago #
Silntknight
Moderator

Ok, I think I understand this. Whatever goes in is what comes out of Vin. I was just wondering because Okie mentioned that Vin outputs whatever goes in minus .6V. Thanks for all the help. For my project I was torn between a Duemilanove and the Maple. I figured that as long as I can interface the sensors and program it the same way (or close enough to), that I would use the Maple because it is much faster, which is what I need.

Posted 5 years ago #
poslathian
LeafLabs

Ahh, well hes actually be right about that. There is a protection diode on external in, which should drop about .6V. If its convenient, you can dump power directly in to VIN (with jumpers removed) and skip the protection diode at your own peril.

Posted 5 years ago #
Silntknight
Moderator

I actually also got in contact with one of the LeafLabs team and he told me that I could get a 5V rail from Vin if I have a 5V USB input or 5.6V external supply. I assume the protection diode is neglected from the USB input then because USB has the same pin arrangement between all devices. I guess that means that I have to be extra careful when I hook it up to make sure I connect +5V to +5V and Gnd to Gnd! Time to go look up USB pin configuration.

EDIT: For anyone else who this post helped, looking at a USB with the plastic block (used to alignment) on the bottom, from left to right the pin arrangement is - D+ D- + which depends on how willing you are to trust Wikipedia.

Posted 5 years ago #
Silntknight
Moderator

So I thought of another issue: Is the voltage divider a slope or vertical shift in voltage? Basically, my pressure sensor will give me a voltage (from 0 to 5) and the divider will output a new voltage (from 0 to 3.3). Is there a slope shift (0 Vin = 0 Vout, 2 Vin = 1.32 Vout...) or is it a vertical shift (1.7 Vin = 0 Vout, 3 Vin = 1.3 Vout...)? I am inclined to believe it is a slope shift, as that is the only one that makes sense. That also raises interesting questions about resistors, but that is another topic. Basically, if my sensor's datasheet gives me a graph of pressure vs. voltage, I have to recalculate the equation based on a divided voltage. This is easy with a slope shift, not so much with vertical shift. So much math...

Posted 5 years ago #
gbulmer
Moderator

A voltage divider gives a ratio. A voltage divider with R1=2K and R2=3K will always give an output voltage in that 2/(2+3) ratio. So it doesn't matter what the input voltage is (providing it isn't so high that it damages the resistors, or cause them to warm up significantly), the output is just a ratio.

So I assume that's what you mean by a slope.

So yes, if the datasheet gives a graph of pressure vs. voltage, you will have to do the conversion. On datasheets I've seen, they have given a specific value of something like mVolts/pascal, or whatever. The STM32F's ADC gives an absolute value, something like 3.3V/4096 volts/increment. So it should be feasible to do the conversion.

You likely understand this, but for future readers of this thread, it's important to arrange the calculation appropriately.

If the conversion is, say 4700/11000 (using 4,700ohm 11,000ohm resistors), then avoid doing:
conversion = 4700/11000*analogRead(n);
conversion = 4700*(analogRead(n)/11000);
it'll likely be 0.

The value returned by analogRead is a maximum value of 4095.
4095/11000 is 0 because it is integer division.
similarly 4700/11000 is 0 due to integer division.
So a better way to do this is
conversion = (4700*analogRead(n))/11000;

I should (and have:-) added, using 47 and 110 is better than 4700 and 11000.
1. the resistors are likely no better than 1%, so 11000 is an illusion of accuracy which can be misleading
2. in some cases (though not this one), the range of arithmetic could fit into a smaller integer type (which matters a lot on an 8-bit proceser like the Arduino's Atmel ATmega, but isn't much of an issue on the 32-bit STM32F).
3. I believe the speed of the divide operation is proportional to the size of the numbers, so it may be a bit faster to divide a smaller number by a smaller number.

Posted 5 years ago #
Silntknight
Moderator

Gbulmer, that was actually very enlightening. Going back, I do remember that a voltage divider is based on a ratio, so that makes sense as a slope shift.

As far as the conversion goes, there are much easier ways to do it. For example, if the signal is 1.2V (from a 5V Vin), then you have 1.2/5 = your ratio. 4096(1.2/5) will give you the analog read out. In any case, using the map function makes this much easier because you only have to know the minimum analog value and what it correlates to. The expression works because the voltage divider is based on a ratio: (1.2/5)(3.3) gives you the divided voltage (going into the pin), and ((1.2/5)(3.3))/3.3 gives you the percent (as a decimal) of the 3.3V maximum. Multiplying that by 4096 gives you the analog read value. Simplified, you get my original 4096(1.2/5). Of course, 1.2 is just a representative. It is actually whatever you need. Also, I generally do the math before I enter the code so the program isn't constantly running the math. Using the above method, you can get the min and max map values for the output.

Also, thanks for noting the difference between 4700*(analogRead(n)/11000) and (4700*analogRead(n))/11000. I wrote a Java program to emulate the functions my code carries out and at first I kept getting answers like infinity, 0, or -infinity. When I made the switch, like you pointed out, it started working and I didn't know why!

Posted 5 years ago #
gbulmer
Moderator
For example, if the signal is 1.2V (from a 5V Vin), then you have 1.2/5 = your ratio. 4096(1.2/5) will give you the analog read out.

Agreed.

I am accustomed to doing workshops where we might be sharing a multimeter between 4, 5 or more people (I think 1 between 15 is my record:-).

Also some people are not confident at using multimeters, so a way to cross check is reassuring (IMHO critical). Plus, the resistor values are 'written down', so I try to offer alternative approaches. Part of my approach is to encourage folks to look at the math (I am a 'STEM Ambassador':-). By looking at the math, I hope people will understand how to choose appropriate resistor combinations, and get a better grasp of how things work.

do the math before I enter the code so the program isn't constantly running the math

It turns out that the math is slower in map():
http://arduino.cc/en/Reference/Map

The code they show there is:
```
long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
```
Which is a function call, and six arithmetic operations vs no-function call and two arithmetic operations (though they both do a divide, which is much slower than the other arithmetic, so the difference is not as bad as one might guess).

To be clear, IMHO if map() is easier to understand, use it. (IMHO premature optimisation is a common cause of broken code.)

On the Maple the slower map() won't matter much (probably only 2-5x slower), but FTBOFR* this is will be much slower on an Arduino's Atmel ATmega than, e.g. (47*analogRead(n))/110 because map() uses more operations, and the math uses long (32 bit) integers, which is quite a lot of software for the 8-bit ATmega.

Side note: That conversion would fit in an unsigned int (16 bits on an ATmega), speeding it up if it mattered (and if folks knew exactly what they were doing; but avoid premature optimisation)
Aside: We should post some benchmarks.

Also FTBOFR, map() uses integer arithmetic (32-bit on Arduino), so a factor of 1.2 would get turned into 1.

Finally FTBOFR, conversion using something like 4096(1.2/5) could be done, but, I think it would be much slower as it would become a floating point calculation, which is many more instructions in software.

HTH

*FTBOFR - For The Benefit Of Future Readers :-)
Posted 5 years ago #
Silntknight
Moderator

When I did the math, the values I got were relatively close to whole numbers. I only need this "premature optimization" once because my pressure sensor isn't linear over it's domain. It is only linear over .2V to 4.9V. I knew I wouldn't be getting voltages anywhere near these values, so I decided to calculate what these voltages translated to in analogRead(). I guess, looking back, that I could just have easily written a function using these two known points.

Which brings me to my next point/comment. I was actually wondering if map() would be slower than writing out a function. In one of my preliminary codes I wrote the math as functions. I can easily do that again and possible avoid the premature optimization problem (though it doesn't apply in my case). Because of your logic with a function call and 6 operations, I will probably just write functions each time I need them rather than use one generic one. I will probably use whole numbers to keep the math fast. If I do this, I would assume, for obvious reasons, it uses integer math. I am not worried about these small errors too much. I was going to ask, until I re-read your post, what the resolution for an int was, just to make sure I would be within the range. 32-bit int's are definitely long enough.

This also brings up an interesting issue of optimization (speed) vs. simplicity. In any case, thank you.

EDIT: How can I do non-integer math? I am writing a timer and I need some non integer math or else my timer will be off an the rest of my code will be too. Can I use double's? I ask because I am working with millis(). I am actually subtracting an old and a new millis() value, so I should get a difference <300, so I don't need to use long to store the value. If I store it as a double, can I get decimals? In other words, would this code work? timeNew and timeOld are both long's.

double delta_t = 1.275*((timeNew-timeOld)/2);

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.