28X ADC issues

CharlieG

New Member
I'm having difficulties with my 28X on the ADC inputs. I'm currently using pins 0,1,2,3 as 8 bit ADC inputs, and to start off I just had a basic programme to read the ADC, then display their values on the debugger.
All well so far the ADCs are connected to a rotary pot as part of a feedback loop. Unfortunately the ADCs are reacting in an unexpected manner!
If you set all the pots to halfway, then, say, rotate potA on pin0, then the value on pin0 goes up, but so too does pin1, but by a percentage (possibly) of the initial value. So if you start pin1 at 150, it will go up to 175 for pin0 going from 0-255.
Bizarrely however, altering the pin1 pot does not have any effect on the pin0 value. I've metered the voltages going into the ADCs and they only change when their respective pots are moved, even though their reported values change without the voltages changing.
Has anyone else come across this ? Do I have a confused 28X, or might it be a bug in the software ? I'm running at 8Mhx, on COM5 through a USB adaptor.

Thoughts to solutions gratefully recieved!
 

BeanieBots

Moderator
I'm guessing that your pots are a high value. Maybe several 100k or higher.
If this is true then I would expect what you see.
Try it with pots of around 10k value.

If you are using 10k pots already, then possibly a wiring fault around the 0v area.
 

Technical

Technical Support
Staff member
A common mistake that gets adcs interacting is using an incorrect symbol or pin variable in the readadc command

readadc pin0,b1
symbol ldr = pin0
readadc ldr,b1

are all wrong

They should be

readadc 0,b1
symbol ldr = 0
readadc ldr,b1
 

CharlieG

New Member
I think i have it correct. programme is as follows:

main:

readadc 0, b0
readadc 1, b1
readadc 2, b2
readadc 3, b3

debug

goto main
 

BeanieBots

Moderator
Not simply, but it is due to the way the ADC works.
Very crudely speaking, the ADC input is capacitively coupled by the sample and hold mechanism. This means that whatever voltage was on the sample and hold capacitor needs to be 'charged' to the new voltage being sampled. The charge current comes from the source being measured. If the source is of high impedance, the current is very low and hence the reading will tend towards whatever the voltage was at the previous reading.

For a fuller explanation you will have to read the PIC datasheet. Failing that, just take my word that source impedances greater than about 10k MAY give 'strange' results depending on what you are doing with other inputs and in what order you read them.

The maximum impedance specified in the datasheet varies for each type of PIC but 10k is good all round figure.
 

hippy

Technical Support
Staff member
Simply - It's like jumping from building to building and measuring how high they are using an altimeter while holding on to a helium balloon ...
<code><pre><font size=2 face='Courier'> O
| o
`-|-
/ \ \
.----. *
| | \
| | *
| |____ \
| | |----. *
| | | |----.
__|____|____|____|____|__ </font></pre></code> With a low impedance source you fall like a lead weight and hit the building and can measure the height accurately. With a high impedance it's like having a bigger balloon ( a greater resistance to falling ), so when you are over the next building you haven't fallen to its top and the height you read off from your altimeter is too high.

This is also why earlier readings affect those later on but not the other way, and the 'balloon' can also act as drag when climbing to the next along which is higher up, so you can end up with under-readings as well.
 

Dippy

Moderator
I've had some funnies in the past too when doing ADC on different mux channels in both PICAXE and 'another' language. However, I've been able to do very fast ADCs sequentially in the same channel on a very rapidly changing signal without problem.

Theoretically the firmware would be doing the appropriate acquisition waits/delays and waiting for the completion bit, but sometimes I've still needed a dummy read after changing ADC mux channels.

I have seen numerous posts on other forums (non PICAXE/Basic) about ADC oddities when changing mux channels, so you are not alone....

Unless, of course, its something to do with your circuit? Perhaps post it on tinypic?

For an experiment, may I suggest doing 2 READADCs of each channel and check the first/second values, or introducing a delay bewteen reads. Have a dabble - but this DOES assume your circuit (e.g. input impedances/feedback/cross-interference and Vsupply) aren't affecting things??
 

CharlieG

New Member
Thanks guys !!

I replaced the 470K pot with a 10K pot and it worked just fine - now i just need to get the correct type of 10K pot for the hardware, and we'll be well on the way. Now I just need to work out why the circuit keeps reseting the pic - I reckon there must be some sort of field collapse snarling it up from the motors, even though they have a capacitor and diodes to protect against it !!

Thanks again

Charlie

(PS - any objections with me putting this exchange in my report as an appendix?)
 

BeanieBots

Moderator
CharlieG, you SHOULD put this in your appendix.

Dippy, these &quot;oddities&quot; are straight forward design errors. Running things out of spec. It is as simple as that. The PICAXE is working fine and waiting for end of conversion just like it should.
The MUX will only change channel when it executes the command so just adding a delay will have no effect. The sequence would need to be:-

readadc pin,var 'switch MUX
pause delay 'wait for out of spec source to charge SH
readadc pin,var 'get better accuracy reading.

Even doing the above will not GAURANTEE the specified bit accuracy because the source is still quite simply OUT OF SPEC.

This is why I get so tense with comments like &quot;I've used 100k with no problems&quot;.
Often this will be OK, but then one day the code will be changed to read two or more inputs in a different order and suddenly it's not OK.
By all means use values outside the specification (eg for ultra low power situations) but understand the consequences of doing so.

The resetting problems are probably due to noise from the motor. Replace the motor with an incandescent light bulb to confirm that the problem goes away.
Fit a cap between the leads right at the motor and also fit one between each lead and the motor case. Three caps in all.
Design the layout of the wiring such that motor current does not go down the same wires as the supply to the PICAXE. Ensure the PICAXE has good decoupling with possibly more than one decoupling capacitor of a decade difference in value. Try 100nF &amp; 10nF in parallel and possibly a 10uF for luck.
Don't forget the obvious serin pulled low and reset pulled high.
 

Dippy

Moderator
Red Face: Here come the excuses:- Well, it was ages ago (2 years) when I was doing it, so I was a PICAXE newbie then and this thread just reminded me of it.

I have just looked at my old circuit (which I was having the problem with) and it was godawful. I should have looked BEFORE tapping away. Ah well.

I have just tried a test circuit and, in fact, with suit inp/imp it worked perfectly.

Why do you have the pause in there BB?

Anyway, based on that, bottom line:
If it doesn't work then you've done something wrong. Just like what I did...

Edited by - Dippy on 18/01/2007 12:56:54
 

BeanieBots

Moderator
Why the pause?
Imagine a MUX looking at two sources, one at 0v the other at 5v.
Imagine each source is high z, say 1M.
The MUX feeds the ADC.
Imagine the ADC has 10uF across it.

OK, exagerated values, but I'm sure you can see the need for a pause AFTER switching the mux. In the PICAXE, the mux is switched by the command readadc. So it switches to the new source, starts the a2d conversion, waits for completion and then returns the result.
Unfortunately, the &quot;cap across the adc&quot; has hardly changed value in the short time it takes for the a2d to work. However, (and this is a slight assumption on my part), the mux is still connected so the cap continues to charge. Taking a reading significantly later on using the same address will now give a more accurate reading.

In reality, the cap across the a2d is actually a sample and hold cap. The normal procedure (and whole point) of such a device is that it is disconnected from the source during the conversion. I do not know for a fact if it is reconnected after the end of conversion in a PIC but it would make sense to do so rather than wait for the next start conversion which would require a mandatory (and unnescesary) wait prior to conversion start. By specifying a maximum source impedance, the wait after mux change can be fixed and kept small, if required at all, over and above normal operation switching times. Without the source impedance spec, the user would need to calculate the wait time and include it as one of the paremeters for using readadc.
 

Dippy

Moderator
&quot;OK, exagerated values, but I'm sure you can see the need for a pause AFTER switching the mux&quot; - quite right, perfectly logical and its obligatory.

&quot;In the PICAXE, the mux is switched by the command readadc.&quot; - sounds sensible to me.

So, (forgetting PIC jargon for a second) can I take it that READADC =
(Roughly in this order &amp; TRIS already set?).
1. Change pin to analogue
2. Select that pin on A/D mux
3. Turn A/D module on.
4. Wait Tacq (s/h cap charge up).
5. Start Conversion
6. Wait for conversion to end
7. Get result.
8. 2Tad wait??

So, how can your pause BEFORE the READADC command affect the Tacq?
Sorry, I must be thick as in my Red Face test I didn't need any pause.

PS. &quot;I do not know for a fact if it is reconnected after the end of conversion in a PIC but it would make sense to do so rather than wait for the next start conversion which would require a mandatory (and unnescesary) wait prior to conversion start.&quot;

The charge holding capacitor (CHOLD) is not discharged after each conversion.

After a conversion has completed, a 2.0 TAD delay must complete before acquisition can begin again.
During this time, the holding capacitor is not connected to the selected A/D input channel.


Edited by - dippy on 18/01/2007 15:07:32
 

BeanieBots

Moderator
As mentioned, I cannot be 100% certain and I don't have the datasheet to hand.
The idea behind the pause is to increase the step 4 delay. If the s/h cap is not connected until step 3 then my suggested pause would be pointless.

&quot;After a conversion has completed, a 2.0 TAD delay must complete before acquisition can begin again.
&quot;
Can't think what this would be for.

Might have a play with this using seriously high impedance sources (comparable to DC pin input impedance) and see if the pause has any effect.
If not, then for very high source impedances several reads in succession would be required.

Without detailed knowledge of the exact internal circuit and sequencing, this is moving further into the realms of guess work and assumption. The proof would be in testing.

In your specific test, you reduced the source impedance so Tacq would be within spec. Also, I'm quite sure that Tacq would be very small compared to a PICAXE command time so the time taken to load and execute the next readadc would more than suffice for an extended Tacq. Without having values for Tacq and s/h C, I can only guestimate.
 

hippy

Technical Support
Staff member
There's a benefit to the PAUSE if after READADC completes it leaves the pin as an analogue pin <i>and </i> the ADC hardware leaves the S&amp;H capacitor connected to that pin.

We've never had a definitive answer on whether a READADC leaves the pin as analogue ( potentially bad if it doesn't ).

My reading of the 2Tad period after an ADC completes, is that the capacitor is disconnected during that time, and after that does reconnect back to the last selected pin.

Consecutive READADC's will force the S&amp;H cap closer to the input voltage for subsequent conversions, but the PAUSE would only be beneficial if the S&amp;H cap remains connected to the input. Otherwise it would be necessary to POKE SFR's and then PAUSE to perform such pre-charging.

The answer as to whether a PAUSE does any good could be determined by experiment, or by looking at the ANSEL and related SFR.

As a final note; Tacq and/or Tadd will be affected by over and under-clocking.
 

Dippy

Moderator
Well that was my point re: Tacq.
This time (which for a 16F88) could be as low as 20uS with &lt;10k source.

The Tacq is required AFTER a change of A/D select channel (MUX). But your pause is BEFORE the mux change in the READADC. Thats the bit I can't see the point of as your pause is not in (it seems) the 'right place'. If READADC doesn't set/reset mux when using same channel (for consecutive a/d) then the pause may be beneficial for higher imps as, I think, hippy implies.
Suck it and see I guess?

I've never checked a/d status after READADC, prehaps check ADCON0.0 for F88 and/or ANSELs as you suggest? It certainly would make good sense to switch it off.

Anyway, it works.... so I'm going back to vaporising transistors.
 

hippy

Technical Support
Staff member
Test results for 18X (16F88), READADC 0 followed by an immediate READADC 1 ...<code><pre><font size=2 face='Courier'> TRISA ANSEL ADCON0 ADCON1
76543210 76543210 76543210 76543210

Power On Reset --110111 -0000000 000000-0 0000----
After READADC 0 --110111 -0000000 100000-1 0000----
After READADC 1 --110111 -0000000 100010-1 0000---- </font></pre></code> READADC turns the ADC hardware on and keeps it on. Conversion Clock is Fosc/32.

After conversion, the last input used is left selected.

After conversion, All inputs are returned to being digital ( ANSEL bits low ). I really think they should be locked as analogue once used as such given the warning in the datasheet.
 

BeanieBots

Moderator
Thanks for doing those tests Hippy, saved me the effort.
Good point about the effects of over/under clocking.
Makes source impedance even more critical when using readadc overclocked.

Anyway, the big lesson is,
There is a spec and it's there for a reason.
 

Dippy

Moderator
Well done. So for low-power people (doing the occasional A/D) it looks like a quick poke might be in order to switch off ADC module.
 

hippy

Technical Support
Staff member
And the answer to whether the S&amp;H cap tracks the analogue between reads - Figure 12.3, Page 121 of the 16F88 datasheet I have, indicates the cap is disconnected from the analogue in when the conversion starts ( to prevent changing values while converting presumably ) and is re-connected when it finishes, so yes it does and a PAUSE between consecutive reads of the same pin will help pre-charging, providing ANSEL bit low doesn't disconnect it from the pin, if it does, just poke ANSEL after the first READADC.
 

Dippy

Moderator
AS you say, yes it does disconnect between reads - I never suggested otherwise.

My original point was really about questioning the need for a pause when READADCing DIFFERENT channels consecutively.

Assuming you have a similar D/Sheet to me, look at the para above Figure 12.1 which shows the sequence of what you must do if you were doing a READADC routine in assembler (or a compiled language). Look at the position of &quot;Wait the required acquisition time&quot;. In PICAXE you have no control over Tacq*.

Quite logically, it is AFTER the mux channel selection (pretty obviously yes?).
So, in theory, all of this is part of the READADC PICAXE command. And therefore all of this is after a PICAXE PAUSE. Therefore, when READADCing DIFFERENT channels consecutively the PICAXE PAUSE is irrelevant as the Tacq is required AFTER mux change i.e. 'during' the READADC command.

However if READADCing the same channel consecutively I CAN see the possible validity of a Pause for higher imp inputs.

But, at the end of the day, the only way is to try. If in some circs the Pause is beneficial then great, do it. My 5 minute test with READADCing 3 different channels of &lt;10k input imp showed no need for a pause. I didn't try anything more dramatic as I'm just about to fiddle with Brownout as I find the figures in that other thread very strange.

In an aside where I have been ADCing in another language I've found that Tacq can be reduced to 1 usecond with some other PICs.

Anyway, this has been an interesting OT 'thought exercise' but I need to get on.

*I'm sure if the right person POKEd about he/she could initiate a manual READADC with a slow Tacq??
 
Top