GPIO Analog pins?

[scottchiefbaker]

Are all of the GPIO pins digital? I'd like to read an analog signal from a photoresistor, or a potentiometer, and that will require an analog input.

[jbeale]

Yes, they are all digital. BUT, you can use a simple circuit as a "poor man's A/D" for example, by using a resistor and a capacitor in parallel. You turn on the GPIO pin as an output to charge up the capacitor, then you reconfigure the GPIO output to an input (high impedance) and time how long it takes for the voltage on the capacitor to drain down (due to the resistor) and cross the logic threshold from 1 to 0. That time value is proportional to C and inversely proportional to R, so you've done an analog measurement using only a digital I/O. The R might be a CdS photocell, for example, in which case you've measured a light level. Or instead of a resistor, it could be a current into a phototransistor. For example, the Pololu #959 QTR-1RC reflectance sensor is used in this way, see the schematic at http://www.pololu.com/catalog/product/959

If you prefer to use a traditional ADC chip you can certainly do that, connecting to the R-Pi via SPI or I2C. For example, I like the Microchip MCP3424 (I2C interface) which has 4 differential inputs and can be configured for one of four different data rates & resolutions:
- 3.75 SPS (18 bits)
- 15 SPS (16 bits)
- 60 SPS (14 bits)
- 240 SPS (12 bits)
YOu would need to write the control software though. I have used this chip with the Arduino, but not yet for the R-Pi. You can get one assembled on a board here: http://shop.moderndevice.com/products/j ... nalog-plug

[pygmy_giant]

thats very inventive - I would be very interested to see if anyone can demonstrate it working on the pi

[mahjongg]

Its a technique very common on many microcontrollers, but may be less suited for one running Linux!, as its not a "real time OS", it can happen that your code stops running for many milliseconds, as the scheduler gives other tasks priority.

The PI surely doesn't have any true analog inputs, for that you are required to use I2C or perhaps SPI interface chips. (the former for slow but multiple I'O's the latter for faster I'O's). If you want to connect a real (I2S or AC97) codec, that can be done too, but requires you to solder wires to the board for an I2S interface. for most using USB peripherals will prove to be less challenging.

[pygmy_giant]

good point about linux timing - it would be an ideal experiment for something like DexBasic

I'm trying to get this rinky dinky board working



- it has analoge inputs via I2C

(note to self - google I2S & AC97)

[jbeale]

The all-digital "analog input" should work on the R-Pi, except that the timing is not as good as a microcontroller due to the available Linux versions not being true real-time. If you make your time constants longer than 10 milliseconds or so (not microseconds) I think it should work. It would likely work best as a kernel-driver level, rather than in user space. My experiments with NTP-PPS timing in the 3.1.9 kernel with a relatively unloaded system indicate that my R-Pi has an interrupt latency ranging between 10 and 80 microseconds, and occasionally gets as long as 150 microseconds (see below). Timing delay is random but you can just try it several times, and filter out the outliers. The distribution is decidedly skewed (not a symmetric gaussian) since you can have short delays, or very long delays sometimes, but of course the delay is never less than 0. The plot shows offsets around a long term average "0 mark" arbitrarily set to zero, but true zero delay on this graph would probably be near -0.04 msec.

RPi-PPS-timing.png (19.63 KiB) Viewed 145661 times

[pygmy_giant]

I think you can reduce this unpredictability by doing something in bash to give the program high priority - haven't tried it though.

[jackokring]

Theoretically, if the output of one pin drove a filter, and its voltage float was compared to the voltage to sample using an op-amp/comparator, then absolute timing is not as essential. If the sampling of the input bit, was synchronized with the output bit being filtered, and within the interrupt handler also close in time, an actual fast clock tick was sampled, then using a calculation, the digitally estimated voltage which is being compared, can be simulated on chip, and knowing the input bit, an accurate estimate of the actual input voltage can be made. Very high low frequency accuracy!!

[mahjongg]

All I/O devices that work on any desktop system must be able to overcome millisecond hitches, as otherwise they simply would not work on any such systems (whether Windows/ OSx or Linux based it doesn't matter).

So all "soundcard systems" and such have (FIFO) buffering buit in just to overcome this issue.

[jbeale]

I think you can reduce this unpredictability by doing something in bash to give the program high priority - haven't tried it though.

If you're talking about my PPS graph, that data is coming from an interrupt-driven kernel module (pps-gpio) which records the system time when a rising edge occurs on a GPIO pin, in this case the PPS signal from an external GPS unit. I don't know if a kernel module can be given any higher priority than it already has (?)

[pygmy_giant]

err... sorry - I meant upping the measuring program's process prioraty to stop it getting interrupted - I think its the linux 'chrt' command - something like chrt -r -p 99 [pid] ...?

[pygmy_giant]

thats in userspace

[Grumpy Mike]

Theoretically, if the output of one pin drove a filter, and its voltage float was compared to the voltage to sample using an op-amp/comparator, then absolute timing is not as essential. If the sampling of the input bit, was synchronized with the output bit being filtered, and within the interrupt handler also close in time, an actual fast clock tick was sampled, then using a calculation, the digitally estimated voltage which is being compared, can be simulated on chip, and knowing the input bit, an accurate estimate of the actual input voltage can be made. Very high low frequency accuracy!!

Have you actually tried this? The explanation is a bit muddled, exactly what do you mean by:-

If the sampling of the input bit, was synchronized with the output bit being filtered,

And what do you mean by "voltage float"
From what I can gather of this suggested technique you do need accurate timing. Can you explain more clearly what you mean.

[TonyD]

good point about linux timing - it would be an ideal experiment for something like DexBasic

I'm trying to get this rinky dinky board working

- it has analoge inputs via I2C

(note to self - google I2S & AC97)

Cool looking board, what does it do?

[jackokring]

Theoretically, if the output of one pin drove a filter, and its voltage float was compared to the voltage to sample using an op-amp/comparator, then absolute timing is not as essential. If the sampling of the input bit, was synchronized with the output bit being filtered, and within the interrupt handler also close in time, an actual fast clock tick was sampled, then using a calculation, the digitally estimated voltage which is being compared, can be simulated on chip, and knowing the input bit, an accurate estimate of the actual input voltage can be made. Very high low frequency accuracy!!

Have you actually tried this? The explanation is a bit muddled, exactly what do you mean by:-

If the sampling of the input bit, was synchronized with the output bit being filtered,

Not on the pi which has not arrived, No. The GPIO input pin used needs sampling at a known time interval from the GPIO output bit used.

And what do you mean by "voltage float"

Any high impedance node in an electronic circuit "floats". Maybe the filtered GPIO output would have been better. If your asking these questions, then designing an IIR filter may be a step too far at the moment. Look up "delta sigma converter ADC schematic" for a rough principals introduction.

From what I can gather of this suggested technique you do need accurate timing. Can you explain more clearly what you mean.

Yes accurate timing is required. Knowing the exact time is not, finding the number of microseconds since the driver last ran is accurate enough. Maybe I should make a circuit based on a LM327CN when my Pi arrives, and download kernel source to make a custom device driver.

[pygmy_giant]

TonyD said:

Cool looking board, what does it do?

It does this: http://www.nsd.uk.com/miscellaneous/I2C_FLEXEL.pdf

[scottchiefbaker]

Is that just a board that lets you talk i2c to all those different sensors? That's pretty cool if it is.

[pygmy_giant]

Why yes - it will be if it stil works after I've soldered on all those itty bitty pins... it runs at 5v so it needs a logic level convrter so it does not fry the Pi... otherwise it will make a nice key ring or piece of jewllrey... it cost £12 off of ebay

[scottchiefbaker]

Ultimately I just want to be able to read a couple of photoresistors, a DS18B20 temperature sensor, and DHT11 humidity sensor. I have an Arduino setup doing environmental monitoring with those sensors, and a Linux box that polls the Arduino once a second and puts the data on a web page. The pi would be a perfect replacement, because it already has ethernet and a web server.

Would this application be something that's more suited for the Gertboard?

[pygmy_giant]

Not sure - I think the gertboard could do that but as it has not been officially unveiled I'm not certain of the spec - I think the gertboard is kinda like an old telephone switch board where you jumper things together in your desired configuration, rather than a circuit as such...

... why not connect the arduino to your pi ..?

[scottchiefbaker]

That's an option too. Ultimately I was just trying to make my installation simpler... i.e. one platform. The adruino is great, but if I ever need to move a wire, I have to recompile the code and tell it to look at a new pin. The pi would be more flexible, in that I could update the code without standing right next to the thing with a USB cable to update the code.

[DexOS]

Not sure if this as been post but here goes
http://learn.adafruit.com/basic-resisto ... i/overview

I will convert that python code to DexBasic, it would be interesting to test both and see if theres much difference in out put.

[Grumpy Mike]

Not on the pi which has not arrived, No. The GPIO input pin used needs sampling at a known time interval from the GPIO output bit used.

Then you should not be advising people on things you have no knowledge of.

Any high impedance node in an electronic circuit "floats". Maybe the filtered GPIO output would have been better. If your asking these questions, then designing an IIR filter may be a step too far at the moment. Look up "delta sigma converter ADC schematic" for a rough principals introduction.

Yes using the right words is often better when giving advice. You are still not using the right words but those are better. Oh and by the way I was in the design team that produced the audio filters for the Polaris Submarine and delta sigma converters I first encountered in the 70s doing PhD research.

Yes accurate timing is required. Knowing the exact time is not

This is not what you said in the original post.

When you get your Pi, and finally get to use it, and acquire a tiny bit of experience you will find that the one thing you can not do under Linux is to grantee precise timing intervals.

Why do you feel compelled to give advice on things you have no experience of?

[clubcsl]

Not sure if this as been post but here goes
http://learn.adafruit.com/basic-resisto ... i/overview

I will convert that python code to DexBasic, it would be interesting to test both and see if theres much difference in out put.

Have you tried out this ?
I am thinking to try it as I want to get the input from a temp sensor.

Thanks

[mahjongg]

This should work!

Its actually an old trick, used in many microcontroller boards, * and adafruit is a very reliable outfit, if they say it works you can be assured it does, and the language used should not matter so much, as long as it can access the GPIO's and is reasonably fast.

Obviously the latency problems generated by the multitasking nature of Linux prevents very fast and accurate timing, but for a signal that is slow enough this isn't a problem.

*one well known example are the famous "basic stamp" microcontroller boards, which even have a basic command ( RCTIME) for this function built in. Also on the Propeller microcontroller (where dedicated software running in on of its coders simulates all kinds of hardware interfaces) this trick is even used as an A/D converter that is able to convert sound this way.