Reading analogue values on a co-op

[cchd]

I am having trouble with dodgy values read from analogue ports on a co-op, so much so that the program that plots them on http://cchd.eu/data.php requires code to ignore them (they are logged to a 'bad-data' file).

A0 is connected to an LDR, the N17DH 'Linker Light Sensor'. This generally produces sensible values.

A1 is connected to an LM35 temperature sensor, the N11DH 'Linker Temperature Module'. This causes the main problem (and I replaced it with a new one two weeks ago).

A2 is connected direct to a potential divider consisting of a 180 ohm 3-watt resistor and a zero-to-190 ohm water-tank depth sensor. It generally works, but once or twice a day produces an impossible reading around 26750 (yes, from a ten-bit port).

I don't want to post the whole program (if you really want to see my horrible code I have linked it as http://cchd.eu/read7.py). Essentially it starts with

Code: Select all

firmata = PyMata( SERIAL_PORT, max_wait_time=5 )
firmata.set_pin_mode( LDR, firmata.INPUT, firmata.ANALOG)
firmata.set_pin_mode( Temp, firmata.INPUT, firmata.ANALOG)
firmata.set_pin_mode( Depth, firmata.INPUT, firmata.ANALOG)


then reads the ports with

Code: Select all

    LDR_value=firmata.analog_read( LDR )
    time.sleep( DR_delay)
    LDR_value=firmata.analog_read( LDR )
    time.sleep( MUX_delay )
    Temp_value=firmata.analog_read( Temp )
    time.sleep( DR_delay )
    Temp_value=firmata.analog_read( Temp )
    time.sleep( MUX_delay )
    Depth_value=firmata.analog_read( Depth )
    time.sleep( DR_delay )
    Depth_value=firmata.analog_read( Depth )


where DR_delay is currently 0.1 sec and MUX_delay is 2 seconds - it works OK down to a MUX_delay of 0.7 seconds below which bad values increase in frequency. There are further delays - the total cycle delay is about ten seconds.

The big problem is with A1, temperature. It reads OK for between one and twelve hours. Then, at some time which seems quite random, it drops to a port figure that varies between 0 and 18, mean 4 (a temperature around -50C). The drop is sudden and it sticks there. I find no way to restore good figures apart from a power-off of at least five minutes. Pressing the co-op reset button has no effect. Halting the python program on the pi and restarting it has no effect. A brief power-off has no effect. The analogue port is stuck and the low reading continues. Only a long power-off restores normal operation, this being a port figure of around 142 (a temperature of 19.3). The connections seem fine, as wiggling the leads does not trigger the problem. But applying a DVM [an inexpensive one] does: it initiates an immediate drop to low figures and shows 0.05 volts or less (matching a port figure of 10). These low figures never recover, except after a ten-minute power-off.

Unplugging the Vout signal lead from port A1 for ten minutes does not fix the problem. Nor does unplugging both GND and Vcc power leads to the module from the co-op board. Only a total power-down works.

I tried setting the internal pullup resistor with the command

Code: Select all

firmata.digital_write( Temp, firmata.HIGH )


but this had no effect.

Can anyone suggest any hardware or software method to avoid this problem or to reset the port? I can detect the problem in the raspberry python code, but I do not have the hardware to trigger a ten-minute mains power cut.

[Alan]

Hi there,

This sounds very odd. My guess would be that the error is occuring somewhere in the Firmata code because as you say, it seems unlikely that 26750 would come from a 10-bit ADC, even if it was malfunctioning quite badly.

This is only a guess, but the problem may be due to you running your program for fairly extended periods of time. Perhaps a counter overflows in PyMata somewhere?

My first suggestion would probably be to try using a different analog input if you haven't already on the offchance that it makes a difference. After that, your program seems very straightforward so it might be worth just writing a custom Arduino sketch to read the ADC and send the values to a Python program using PySerial. This could be used to check to see if the problem is with the Pi Coop or with PyMata.

Hope that makes sense. Let me know if you need more info on anything.

Regards

Alan

[cchd]

Probable answer - and a question

Many thanks for your comments.

I am thinking (until I get the next failure) that the problem is transient spikes induced in the cable to the depth-dependent variable resistor in the attic.

As you say, this is a 24/365 system. I have tried different ports, with no joy though no consistent results either. I don't think it can be a counter overflow because the time-to-failure ranges randomly between one and twelve hours. At present the silly analogue values are not a problem because they get better ten seconds later and I can ignore them. The failures, where the readings drop to near zero and stay there until a long power cut, are a problem, especially as I am soon away to Australia for four weeks (but I have now got a Belkin Wemo switch I can use to depower and repower this from there).

I now suspect that the twenty feet of wire running from the ground-floor co-op to the roof tank resistor may be picking up something and jinxing the system, so I have this morning disconnected this wire to test the system without it (my inputs currently have no protection) and it has so far run OK for more than twelve hours. Five silly analogue values in 12K readings in that time (12896, 28716, 7392, 3936 and 4064), but no sign of the main 'stuck-low-reading' problem.

I think I should put a capacitor across the bottom of the wire that leads to the attic. It would be in parallel with the tank resistor, which is normally about 135 ohms, and that would be equivalent to being connected between the A2 pin and Vcc. But what value?

Or should I place the capacitor between the A2 pin and earth? That's equivalent to being across the fixed 180 ohm resistor. Suggested values in various posts range from 100pF to 4700 microFarad.

Or an inductor in each lead? In which case, again, what value? I have none, but I see RS do them in anything from 10 microhenries to 100K microhenries.

I don't think I need a 5.4 volt zener. I have no high voltages (other than induced transients).

I did connect the pi's earth line to the house earth, but that made no difference.

My system has no inputs that need to move at a frequency much higher than a milliHertz.

[cchd]

I regret to have to report that there was a failure (after fourteen hours) when running with the attic sensor disconnected. So I am now running with the LM35 temperature sensor disconnected (the one that has been causing the problem. Q: Why didn't I think of that before? A: Because it's so unlikely it could do so), and will report back in a few days. Meanwhile, I'd still be interested in views on what component might protect that vertical line to the attic.

[Alan]

Hi there,

I'm afraid that I can't offer much useful advice on removing potential noise sources from your system. If you had no joy after disconnecting the LM35 then I would still suggest writing a simple sketch for the Pi Coop and thus removing PyMata from the equation. I can provide help writing this if you need.

Regards

Alan