picaxe controlled variable power supply

[wapo54001]

Quote: I am actually quite happy with the 'feel' of this adjustment the way it is.

What is the configuration & software setting that you are using to be quite happy, since you've discussed a variety of them? It sounds like (and the data sheet seems to confirm that) the IRL520 is not well-suited to this application, and perhaps final circuit values that others might use should not be based on it.

I'm having trouble understanding the resistor - capacitor combinations you compare in your last post. You are comparing responses with resistors of 1M and 47R. I thought 47R means 47 ohms? Do you mean 470K?

If best response is with 1M & .22uF, that is substantially different from the circuit we published, which is 1M & .47uF, and we should correct the final circuit. I myself am not liking the 1M & .47uF for this application because it is too slow. I started out with those values because they worked very well in my previous projects that use this circuit, but those actually benefit from a lagging, smoother response.

I take it that your preferred solution still includes the pause code but does not include the ignore-if-less-than-3 code?

I need to figure out how to improve my response time. Simplest would be simply to reduce the size of the capacitor. I will also revisit the 'pause xx' code to see if that helps.

 

[BCJKiwi]

1. What is the configuration?
"the circuit and program as currently published using the IRL520".

2. Sorry about the typo on the 47R, should have been 470K ~ corrected previous post.
Thanks for the catch!

3. Best with .22 is not much different from the 0.33 I have been using and 0.47 works as well. Just the response rate changes a bit. As discussed in earlier posts by Hippy and others, the gate charge/discharge rate required to maintain/change the gate voltage (and thereby "R2") in a responsive but stable manner depends on;
the MOSFET characterisitcs and the length of time Leg5 is an output (high or low), and the R/C values.
All these are interacting components and changing any one of them will change the behaviour. Have already added (yesterday) notes to the sample projects post to that affect.

4. Yes still have the pause code as you describe it. Rationale is in previous posts here. Again, code is as posted in sample projects.

5. Agree, settled on the code as published, running at 8mHz, and found best results with Cap changes rather then R changes but either should work. However as the Cap is tied to D rather than S (which doesn't work) there seems to be some interaction here and may be the reason there is more flexibility with Cap changes than there is with R changes. For a 1.2V to 10V Vout, the Voltage at the Adj side of the Cap swings from 60mV to 9V, while Leg can only deliver 5V! Have not got my head around this yet.

 

[BCJKiwi]

Wiper noise in this system should be able to be dealt with by placing a Capacitor between the wiper output and 0V.

'
'                             +-+---- V+
'           +-----+           | |
'08M Leg3 --+ 10k +-------+-->| | 10k Pot       Input ~ setting adjustment for Vout
' (ADC4)    +-----+       |   | |
'                         |   +-+---- V0
'                     1uF |
'               0V  --||--+                     Smooths 'noisy' pot
'                     2.2uF 
'

Tested this with a 1uF cap and found it did not affect response. However since the pot used is not obviously 'noisy', can only assume that this would work as expected.

 

[BCJKiwi]

Following on from the above post,
Looked at implementing an up and down button in place of the pot.
Idea was to implement a circuit like this;

V+ ---470K---PB---+---PB---470K----0V 
                  |
                  +--------2.2uF---0V
                  |
                 10k
                  |
                 ADC4

Basically replace each half of the potentiometer with a push button and R.
This works - sort of. When the up or down push button is pressed the output rises or falls. However when both PBs are open the output creeps very slowly upward. I had expected that it may creep down if there was any loss of charge in the Cap but not up! I presume the Cap is slowly charging through ADC4. Tried setting Port3 (ADC4) to an input but this did not help as ADC4 still has to be read each cycle.
ADC4 has to rise for Vout to rise but how could the Cap gain charge when it is not connected to either V+ or V0? Would not expect in/out3 (ADC4) to deliver any thing out when it is in ReadADC mode.

Any suggestions?

 

[Dippy]

I'm glad to see you've moved onto push-buttons.
But why butons + ADC??
Buttons plus logic/interrupt would be easier.

(Qu: Why ever did you use a pot+PICAXE, when you could have just used a Pot+LMxxx reg? i.e. what was the point? A quality pot would have saved a lot of time yes/no? Serious questions btw not sarcasm.)

If its drifting then there is something wrong with your feedback, whether be how-much or how-often.

 

[BCJKiwi]

Why Buttons plus ADC? - just a logical extension. Since you need the buttons anyway, thought this was a simpler option. Program is unchanged and is fast. Following through the previous discussion on the issues arising so far would indicate that anything more in the code is likely to create issues with stability and response. However, ReadADC may be just as slow as the code involved - don't know at this time as have not explored that option.

But, do you have any idea why the Cap might be receiving charge off the ADC port? It's not a case of the feedback, its a case of the CAP charging up when it shouldn't.

Why the PICAXE control - all been discussed and answered before in this thread.

 

[Dippy]

Charge V going up: Dunno about that. Odd. I don't know what state PICAXE firmware leaves pin in after execution. Could it be a charge building up from noise pickup? Odd I'd have thought the leakage of an electrolytic would have caused it go the other way... unless your code is back to front. Have you got a nice high impedance voltmeter for confirmation?

"just a logical extension." - I honestly don't mean to sound rude and I don't know how to say this without appearing rude, but I think its an illogical complication. Pumping a cap onto the ADC and then leaving it floating does not sound like a recipe for stability to me, very sorry. Sounds like you're trying to use the same method for input control as you do with your MOSFET gate cap.

I'm going to regret saying this no doubt, but those little input worries would fly out of the window if you used P/B logic...

 

[wapo54001]

Dippy,

I think your idea of using logic rather than a capacitor to control the input is a good one. How 'bout you contribute the input buttons logic for our little project?

Ideally, it would use only one input pin, and command up/down by connecting it to +5 or Gnd (with debounce, of course). Set each up/down pulse to equal, say, 1/100th of full scale with two speeds of change depending upon if the button is held down for more than two seconds . . .

 

[hippy]

@ BCJKiwi : TRy something like this for your two button handler ...

          ___             ___
+V     __|___|__       __|___|__
-.-  .----o o----.   .----o o----.
 |   |    ___    |   |    ___    |
 `---^---|___|---^---^---|___|---^---.---> ADC
          10K             4K7       .|.
                                    | |
                                4K7 |_|
                                    _|_

The R's are guessd but should work. Should be possible to add even more buttons but R's get more critical. With this you should also eb able detect when both buttons are held together which might have some functional use. I've used similar and thatw as okay.

 

[wapo54001]

BCJ,

Per your request, attached are two JPGs -- for combined control/feedback, and divided.

Also changed the capacitor value to .22uF in both schematics.

 

[wapo54001]

How do you think it would work if we converted the 'adjust' section to a subroutine, and instead of pausing between loops of 'x' times reading the input ADC and then going to the adjust at the end of that multiple read process, we simply call the adjust subroutine between each read? In theory that would keep the output more steady, wouldn't it?

Even better, if there is an easy way to maintain a rolling average input value by adding the latest read and removing the oldest read rather than reading 'x' times and then averaging for the total reads, then that would make it even better, I think.

I don't have the programming skills to make the latter happen, but later today or tomorrow I'm going to try the subroutine idea.

 

[wapo54001]

I believe I've discovered a useful technique. In my case, it appears to have smoothed the regulation by a substantial amount.

The method I use is to require that the commanded output and the actual output match before returning to resample the input. Thus, the output loop will run until W3 and W4 match exactly, and only then will the code return to the input to see if the input has changed. It seems to keep the output closer to the intended value.

Using SERTXD anywhere in the loops seem to greatly affect regulation accuracy so I turn it on only for testing.

'PROGRAM

'Set output to minimum during start
high 2

'Set clock to 8MHz
setfreq m8

'Pause time for varying correction duration
symbol pausetime = w2

'Main Program
main:

'Read Sensor Input and average multiple readings
b10 = 0							'reset count to zero
w1 = 0							'reset average value
do									'loop to get readings to average	
	readadc10 4,w0
	w1 = w1 + w0
	inc b10
loop while b10 < 3
w1 = w1 / 3					'take the average value of readings


' output to terminal
'	sertxd (" In_Cmd: ",#w1)
'	sertxd ("    Out_Cmd: ",#W3)
'	sertxd ("    Pause = ",#w2,cr,lf)

'Calculate any conversion factors
w3 = w1							'w3 is calculated output; use formula if required

'set the output
adjust:
	readadc10 1,w4				'read current output for comparison

'if output needs no correction, then check if input has changed
	if w3=w4	then main			

'otherwise run the correction code.	
	if w3 > w4 then         ' Increase
		pausetime = w3 - w4
		low 2
		pause pausetime
		input 2
	else						    ' Decrease
		pausetime = w4 - w3
		high 2
		pause pausetime
		input 2
	endif

Goto adjust

'end of program

 

[BCJKiwi]

@Dippy,
As Wapo says how about a positive contribution?
Re the 'why bother' Q, you do appreciate that this system does not have to have manual input don't you? The number being derived from the Pot on ADC4 could come from anywhere, it just needs to be in the range of the feedback min to 1023!

Have tried a PB and code system but with unacceptable results.

'
'         PB
'         ---   +-----+
'   V+  --+ +---+ 10k +----+
'               +-----+    |
'                          |
' 08M Input ---------------+
'                          |
'               +-----+    |
'   0V  --------+ 10k +----+
'               +-----+
'   (same circuit Leg3 & 4)
'

on input 3 and on input4

The code was;

#picaxe 08M
setfreq m8
SYMBOL Up  = 4   'Input4
SYMBOL Dn  = 3   'Input3
SYMBOL FeedBk  = 1   'ADC1
SYMBOL Gate  = 2   'In/Out2
SYMBOL UpDnVar = w1
SYMBOL FeedBkVar = w2
SYMBOL PauseTime = w3
High Gate     'Drive Vout to minimum for safety!
Let UpDnVar = 127   'Ensure Vout is within acceptable range
main:
If     input4 = 1 then
 UpDnVar = UpDnVar + 1 Max 1023 'read setting Pot input voltage
ElseIf input3 = 1 then
 UpDnVar = UpDnVar - 1 Min 127 'read setting Pot input voltage
EndIf
 
 adjust:
 readadc10 FeedBk,FeedBkVar   'get voltage data from output
 if UpDnVar=FeedBkVar then main  'return if output is correct
 if UpDnVar > FeedBkVar Then
   pausetime = UpDnVar - FeedBkVar 'set pause time based on size of offset
 else
   pausetime = FeedBkVar - UpDnVar
 endIf
 
 if UpDnVar>FeedBkVar then increase
   'if UpDnVar < FeedBkVar then decrease ~ falls through to decrease if not increase!
decrease:
 high Gate      'set pin2 high to decrease Vout ~ Higher Gate V, Higher MOSFET R, Lower Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to lower gate voltage
 input Gate      'tri-state pin2 and hold Vout
 goto adjust
increase:
 low Gate      'set pin2 low to increase Vout ~ Lower Gate V, Lower MOSFET R, Higher Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to raise gate voltage
 input Gate       'tri-state pin2 and hold Vout
 goto adjust

Two major problems;
1. If the button is held down then the rate of change is quite slow.
2. the code cycles so fast you can't physically produce a button push that only lasts a single cycle so the minimum change is uncontrollable. I presume the code cycles through the reading the pushbuttons multiple times before you can actually take your finger off the button!

Maybe you have a better option?

@Hippy,
Don't understand the two PB option suggested. If using ADC, then the voltage that represents the set point needs to be maintained on the ADC port. The suggested circuit would seem to provide a single set point with no buttons, a second and third set point if one or other button is held down and a fourth if both buttons are held down - or have I lost the plot?

@Wapo,
Not sure what you are trying to achieve with the subroutine and averaging options.
The main advantage of the present code is it's high cycle rate and great simplicity.
The outer loop (Main) reads any new set point and does this immediately the last set point was reached.
The inner loop (Adjust) matches output to set point as fast as possible then goes back to main:

If the set point is not being adjusted, then the present code is rock steady. It takes care of any form of drift or load change.
Any rolling average type code (already considered) will slow the response for a step change as only the moving average value will be used.

Using an average of the last three reads (rather than a moving average would be more responsive but would not achieve anything the the 'noisy pot' Cap (see a few posts back #163) achieves. This would require a sort of shift register code block something like this,

readadc10 Set,SetVar 'read setting Pot input voltage
w6 = w5
w5 = w4
w4 = SetVar *20
SetVar = w4 + w5 + w6
'1.25 ~ 10V
SetVar = SetVar / 8 * 7 / 60 + 127

There are no more variables in the 08M but peek/poke could be used but would get very messy as the peeked values have to be read into a variable anyway.
Tested the above code and it appears to behave the same as the program does with the published code. However it's hard to tell what effect it might have on a noisy pot

 

[BCJKiwi]

Wapo,
Just seen your last post (cross posted)

Don't know what code you have been using before but the 'majic' part you have just discovered appears (as far as I can see) to be the original code and that which has been published already.

 

[wapo54001]

Wapo,
Just seen your last post (cross posted)

Don't know what code you have been using before but the 'majic' part you have just discovered appears (as far as I can see) to be the original code and that which has been published already.

Yup, that's 'cause I posted the wrong code. The code that I intended to post checks two things before returning to the input code:

1) checks to see if commanded output and actual output match, if not, stays in the output loop.

2) if 1) is yes, then it checks to see if the input has changed (a single readADC). If the input has not changed, it stays in the output control loop. It only goes to the input loop if the input appears to have changed.

As I watched the sertxd values (one in the input loop and one in the output loop), I could see how often it went back to the input with this code, and it was not nearly as often as with 1) only. If the input were to be an inserted value rather than a readADC, there would be no input jitter, and virtually no returns to the input portion of the code so the software could concentrate on the output until an input change was commanded.

It's just a way to keep the chip focused mostly on output control until the input is changed substantially. Works for me.

If the set point is not being adjusted, then the present code is rock steady. It takes care of any form of drift or load change.

I think I asked a question that nobody answered: What level of "regulation" is acceptable? Is +/- .010V good regulation? My conventional regulator seems to be solid to .001V, much better than the 08M regulator.

 

[hippy]

@Hippy,
Don't understand the two PB option suggested. If using ADC, then the voltage that represents the set point needs to be maintained on the ADC port. The suggested circuit would seem to provide a single set point with no buttons, a second and third set point if one or other button is held down and a fourth if both buttons are held down - or have I lost the plot?

You've lost the plot

The two buttons give four possible states as you note, none, one, the other, both and then as in the code in #173 you use that state to increment, decrement or leave alone the reference you will be matching the output to ...

ReadAdc adcPin, b0
Select Case b0
  Case > Z  :                                 ' Both
  Case > Y  :  UpDnVar = UpDnVar + 1 Max 1023 ' Up
  Case > X  :  UpDnVar = UpDnVar - 1 Min 127  ' Down
  Case Else :                                 ' None
End Select

There are two things fighting each other now with digital control or analogue averaging, needing an internal timebase to handle button pushes to get steady increments / decrements, and keeping the output tracking as fast as possible, and two things fighting each other with staying in the adjust loop until matched which gives better tracking but slows other operation down ( especially with a big change ) or only adjusting slightly which keeps other things ticking along steadily but slows down tracking and adjusting.

There are ways round all of this and it's a familiar problem in any real-time system, but not so easy to describe. Basically, do a READADC or Button push detect frequently at a near constant rate and in the meantime adjust the output. Design as if you were just handling a loop which ticks N times per second, then within it use calls to Adjust while not doing anything else and every so many statements. Let the Adjust do a fair bit of work but don't let it stay in there too loong. I think I touch on this someway back in the thread.

If it were me, I'd strip out the Adjust and output control and get the pot / button handling working as its own self-contained program, SERTXD to show when changes happen. Then re-integrate Adjust back in.

One thing I note is that the averaging sems to be getting incredibly complicated so it's probably best to re-visit what the problem is that's to be overcome. The first problem is when a pot sits at a transition point, the slightest pickup form passing Martians or Stan waving an RF Wok around on the other side of the world can cause the value returned by READADC to flip between two adjacent values and that will happen even with a cap on the input. The second is when a pot is moved and there's either track skip or grit which causes the READADC to jump around, and of course the above problem added when at a transition point.

I recall making quite a long post sometime showing progressively more complicated ways of removing these glitches and I'll try and hunt those down. The key thing though, is take one reading each time through the loop, do an average, use that value to adjust the output, repeat. Keep everything in the loop short and sweet. Handle more complicated things over multiple loops, so to to add SERTXD for debugging, minimise what is sent and code that so one character or variable is sent per loop.

One problem I perceive is premature optimisation or maybe it's optimisation not being done the right way. I also keep getting a feeling of Deja Vu, that we seem to be going round in circles somewhat. Maybe that's because I've lost track of where we are, what it is people are trying to achieve at the present time and what the problems are.

Maybe it's time to draw this thread to a close, start Variable Voltage PSU Redux as a new thread, post the circuit being used, post some working code, detail what the problems are which remain to be resolved and take it from there ?

 

[BCJKiwi]

Wapo, Can you update the code in your last post please.

I'm not sure where the jitter is coming from. I only see jitter when I use the VN2222L. It is actually a very fast 1V or so oscillation around the set point on Vout at certain places in the range which on a DMM appears as jitter but on the scope is quite different. Are you looking at the output with scope? Small levels of jitter should be taken care of by smoothing Caps on Vout anyway. What is the magnitude and rate of the jitter?

It may be that adding the multi ReadADC and averaging has slowed the execution of the outer loop (Main) to such a extent that the inner loop (adjust) has time to drift.
With the published program, there is only the one readADC and one calculation in the outer loop anyway.
Do....loops are not always the fastest code. You could try the code from my attempt at the 'last three reads average' with and without without the additional ReadADC and tests in the adjust loop and see how that goes. The '3 reads average' calculation should be faster than the do....loop ~ see below.


What regulation is acceptable depends on the application.
Resolution with the 08M regulator can ever be any better than ReadADC resolution. At 10Vout that means 10 / (1023 - 127) = 0.0112. As the Vout range increases then best possible resolution decreases e.g. 20 /(1023 - 64) = 0.0209
the 0.001 on your conventional regulator may be 0.001 (= 1mV) but how are you checking this. If it is with a DMM it will be averaging ripple etc etc and may weel not really be that good. Does it compenaste for supply drift, heating efects etc. Most Regulator circuits will have some compensation for this built in.

Anyway I don't know that this circuit was ever expected to surpass the inherent properties of a decent regulator, it is when all is said and done just a different adjustment technique which seems to work far better than might have been anticipated.

Execution Speed
The way I've tested code speed in the past is to creat a small code snippet with just the bit you want to test. Put it in a for .. next loop with a high count and post some text via sertxd at the start and end. Time the loop. This will add two bits of overhead, the for...next loop, and the sertxd. It is still good for comparing different code blocks. The higher the for...next loop count (within reason) the more useful the comparison.

Ran these two code segements to show what I mean;

#picaxe 08M
setfreq m8
#terminal 9600
main:
sertxd ("Start",cr,lf)
for w2 = 0 to 10000
'Read Sensor Input and average multiple readings
b10 = 0       'reset count to zero
w1 = 0       'reset average value
do         'loop to get readings to average 
 readadc10 4,w0
 w1 = w1 + w0
 inc b10
loop while b10 < 3
w1 = w1 / 3     'take the average value of readings
next
sertxd ("stop",cr,lf)
goto main

47 secs

#picaxe 08M
setfreq m8
SYMBOL Set  = 4   'ADC4
SYMBOL SetVar = w1
main:
sertxd ("Start",cr,lf)
for w2 = 0 to 10000
readadc10 Set,SetVar        'read setting Pot input voltage
w6 = w5
w5 = w4
w4 = SetVar
SetVar = w4 + w5 + w6 /3
next
sertxd ("stop",cr,lf)
goto main

23 secs

 

[BCJKiwi]

@ Hippy,
OK, I did not make the connection between PB code without ADC, and, PB code using ADC to sense which button combo was pressed ~ that damn crystal ball again.

However this would appear to be a solution to using a single input instead of two inputs. I don't see how it would address any of the problems of the PB input method as described in post #173 - slow response and poor resolution or is there further magic yet to be revealed?


I agree with the general tenet of the latter part of your post.

I don't see anything wrong with the circuit as posted in the User Projects - Misc. It has good feel and response. The input averaging I tested could be worthwhile as it is fast enough.
It's just that everyone else wants to 'improve' it. Wapo and I appear to be the only ones who actually have any real world experience with the circuit as described.

Wapo also seems to think it can be approved. So at this time I am responding to any of the various suggestions that I feel might be useful (e.g. buttons), or that that Wapo is suggesting as he has a circuit to work with.

I don't think there is anything wrong with a very intuitive pot input for this application but compensating for a noisy one would be useful.

Why wouldn't a cap to 0V help smooth a noisy pot? if its 'toggling' between different values then won't those be averaged by the cap? The average may not be as good as the proper value but it will be a lot better than no value in the skip. And the gigger the cap the less the effect of any skip.

 

[hippy]

I have found one potential 'bug', or undesirable feature ...

pausetime = w3 - w4
low 2
pause pausetime
input 2

For a full range jump, 127 to 1023, at 8MHz that's a half second delay no matter what. I don't know what impact that has overall but it's a potential reason there is more sluggishness than expected.

I'm quite surprised we're not seeing under and over shoot as well, say when going from 300 to 700. Presumably we don't because the R is so high that it actually takes so long to charge or discharge the cap.

This is where two separate fast and slow charge/discharge circuits would help, but there's no spare I/O on an 08M to do that.

Re the cap on ADC pot : The problem there is that if the ADC is at a transition point, even with a cap, if it's only one billionth of a volt ripple, the READADC will move a whole bit up and down. That may be a slight exageration but that's the drift. The cap may dampen very short noise pulses but not all of them.

 

[BCJKiwi]

@Hippy
That might be Wapo's latest code but is not the original or the published code not the code I am currently testing which is;

adjust:
 readadc10 FeedBk,FeedBkVar   'get voltage data from output
 if SetVar=FeedBkVar then main  'return if output is correct
 if SetVar > FeedBkVar Then
   pausetime = SetVar - FeedBkVar 'set pause time based on size of offset
 else
   pausetime = FeedBkVar - SetVar
 endIf
 
 if SetVar>FeedBkVar then increase
   'if SetVar < FeedBkVar then decrease ~ falls through to decrease if not increase!
decrease:
 high Gate      'set pin2 high to decrease Vout ~ Higher Gate V, Higher MOSFET R, Lower Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to lower gate voltage
 input Gate      'tri-state pin2 and hold Vout
 goto adjust
increase:
 low Gate      'set pin2 low to increase Vout ~ Lower Gate V, Lower MOSFET R, Higher Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to raise gate voltage
 input Gate       'tri-state pin2 and hold Vout
 goto adjust

Stripped that time delay from that position in the code a long time back.

This adjustable pausetime significantly enhanced the response to a step change. Overshoot happens if the R/C is too far from teh 'sweet spot'

 

[hippy]

@Hippy
That might be Wapo's latest code but is not the original or the published code not he code I am currently testing which is;

This is perhaps why I'm getting so confused with where we're at, because while the code you show doesn't use "w3" and "w4" but "SetVar" and "FeedBkVar" it does have the very same PAUSE between the LOW/HIGH and INPUT, as does the code posted in the Finished Project section ...

  pausetime = SetVar - FeedBkVar
  :
  high Gate 
  pause pausetime
  input Gate

 

[BCJKiwi]

OK but not where you showed it in your last post.
At one time Wapo moved a lot of this code to places where it was reworked more than necessary.

As indicated, this 'adjustable pause' significantly improves the step change response rate and appears not to harm the ability to hold to the set point. So I don't know what the issue is that you feel you have found - it works better with, than without.

As indicated previously, I am happy with the feel and response.

If you are twiddling a pot, for a small change it tracks precisely as you move with no lag, for a large change, the slight lag is good as it allows you to wind back a bit if it's going to far.

At one time this lag was seconds, not half a second.

Have been careful not to fiddlw withthe posted code in the Projects - Misc but have added a little to the descriptive text.


Any thoughts on the other Qs in post #178? (PB and Cap).

 

[hippy]

Any thoughts on the other Qs in post #178? (PB and Cap).

The question has to be why is the response slow ? That comes from how quickly one samples the buttons and increments / decrements the wanted Vout value, and the only thing which dictates the loop time / sampling rate is the action of the Adjust routine.

If the Adjust loop executes quickly then there should be no slow response, at 1ms with the button held it should ramp from 127 to 1023 in under one second. If Adjust takes 10ms that however increases to 10 seconds.

The only way to keep button pushed incrementing and decrementing at a constant and fast rate with a longish Adjust time is to increment or decrement by more than one every loop, but that then leads to coarser stepping. To get fine adjustment as well as speedy held response the code needs to detect both button pushes ( +/-1 per push ) and button held ( +/-N per loop ) or have some means of adjusting the stepping rate depending on how long the button has been held for. To keep a constant rate button sampling loop period means having to track how long the Adjust routine spent doing its thing. The problem is that this all takes code space.

I can see three solutions -

1) Forget about button control and use variable pot control only.

2) Split control between two 08M's, one handling the buttons, the other handling the tracking with a serial link between them.

3) Move up to an 18X and use the outputs which can be used as inputs ( ie, tri-stated ) to do the gate control, or go to a 28X1 and use Port C.

My choice would be (3), because the extra I/O allows a variety of gate charge / discharge speeds which will help get larger changes done in less time which improves everything overall and everything is single chip making development easier. That said, for (2), using Input 3 for serial input the now unused Pin 4 could be used as an additional gate fast charge / discharge controller.

Another advantage for (3) is that the extra number of ADC inputs would allow two pots for voltage setting, a coarse pot and fine control. There are also enough inputs to have buttons for Set Min and Set Max voltages and for other functions, with the code space to hopefully support all that.

For the bare minimum controller which is where we started from with the 08M, everything is constrained by the limited I/O and the limited code space and that leads to problems and some options not being feasible. The best that can be done is to take what there is and tweak it as best as possible.

We're into "you canna change the laws of physics" territory and fighting opposing forces as I've mentioned; you cannot get a fast loop time if Adjust takes a long time, and Adjust cannot run any quicker because it cannot charge or discharge the cap at a fast enough rate without long pauses. Tracking Vout and keeping it locked to a static level is fairly quick but as soon as the required output needs to change the Adjust time slows down, as the button pushes change the required level they also slow down the rate at which the buttons get sampled.

Handling a pot shouldn't be as bad as handling buttons in that respect but then averaging comes into play so like buttons the algorithm there needs to be able to handle large changes fairly quickly and smaller ones more smoothly, taking noise out the system when the pot is static. Then we're back up against code space limits.

We've built a raft and are trying to turn it into a speed boat; that's not going to happen by simply nailing bits on.

 

[wapo54001]

BCJ,

1. This is the bit of code that I meant to post -- it seems to make the regulation a little better by keeping activity in the 'adjust' loop until the input actually changes:

'set the output
adjust:
	readadc10 1,w4				'read output
	if w3=w4 then				'if output is correct then check if input has changed
		readadc10 4,w0			'read current input 
		if w0 <> w3 then main		'if current input <> stored input, goto main
	endif

Watching the result with sertxd, there are many iterations when the error is zero but the program does not go back to main because the input hasn't changed, so stays in the adjust loop to catch the next small output error and correct it sooner rather than after a full input loop delay. If the code goes to 'main' every time there is no error in the output, it has to complete the input code before it can check for an error again even if no input change was commanded. Your faster input loop technique should help this, though. I did not notice in your earlier posts -- is this what you are using now?

I kind of think we've got the priorities backwards -- the main loop should be the adjust code, and the input code a subroutine called only when the input changes by operator command.

If a low-overhead method could be found to check for a significant change in input rather than just a random change -- say a 3-count -- before returning to remeasure input, that would make a significant difference -- the execution would leave the adjust loop only when there is a real input change commanded by the operator.

Further, I would like to look at the input code and optimize it because it seems that the output drifts mainly while the chip is running the input code. (Are you now running the "23 secs" version of code for reading the input?)

I think next steps are to 1) optimize input averaging code for speed and 2) optimize adjust code to jump to input code only when there is a good reason to do so.

I will (reluctantly) break out my 'scope to have a look at the waveforms. I haven't used one much since 1980, when my fascination turned from audio to computers, but I do have a 475 gathering dust under my workbench. Now, if I can just find the "ON" switch . . .

This circuit is fine for a straightforward regulator, but for a full-featured regulator with bells and whistles, I do like the idea of using an 08M dedicated to output control, and an 18X or better for all other features.

 

[hippy]

Here's a version which works as a Finite State Machine which should give fast operation. Slightly different to what's gone before but should be easy enough to modify ...

PowerOnReset:
  SeFreq M8
  ReadAdc10 ADC_VPOT, vPot
  vWanted = vPot * K_MUL / K_DIV + K_MIN
  vLast   = vPot

MainLoop:
  ReadAdc10 ADC_VPOT, vPot
  If vPot <> vLast Then
    vWanted = vPot * K_MUL / K_DIV + K_MIN
    vLast   = vPot
  End If
  ReadAdc10 ADC_VOUT, vOut
  If vOut < vWanted Then KickDown
  If vOut = vWanted Then MainLoop

KickUp:
  Low   OUT_GATE
  Input OUT_GATE
  ReadAdc10 ADC_VOUT, vOut
  If vOut > vWanted Then KickUp
  If vOut = vWanted Then MainLoop

KickDown:
  High  OUT_GATE
  Input OUT_GATE
  ReadAdc10 ADC_VOUT, vOut
  If vOut < vWanted Then KickDown
  If vOut > vWanted Then KickUp
  Goto MainLoop

 

[BCJKiwi]

@ Wapo,
Loaded the posted code (with correction) and found it no faster than the code as published in User Projects - Misc. It also has no calculations for Min settings.

@Hippy,
Loaded your finite state machine as posted (had to switch the sense of the > & < in mainloop, kickup and kickdown to get it to run (they were back to front).

The response rate is about 3 X slower than the published code! Moving all that extra processing into the innermost loop and trapping it there means the system is going spend a long time there homing in on the precise set point whicch may be wellout of date as it only took a snapshot of the moving pot. Without the adjustable pause it also has no compensation for how far the Pot might have shifted. Added in an adjustable pause and it performs about the same as the published code.

This is the code that currently seems most efficient and performs the fastest. The changes from the published code are incremental improvements but not significant to the overall performance.

#picaxe 08M
setfreq m8
SYMBOL Set  = 4   'ADC4
SYMBOL FeedBk  = 1   'ADC1
SYMBOL Gate  = 2   'In/Out2
SYMBOL SetVar = w1
SYMBOL FeedBkVar = w2
SYMBOL PauseTime = w3
High Gate     'Drive Vout to minimum for safety on start-up!
main:
readadc10 Set,SetVar        'read setting Pot input voltage
w6 = w5
w5 = w4
w4 = SetVar *20
SetVar = w4 + w5 + w6  'Take average of last 3 Readings
'Adjust Set input value to ensure no attempt made to adjust ouput below 1.2V minimum, or above 5V input to ADC1
'Setvar is 60* the average ReadADC value so /60 ~ improves integer math accuracy (for example ~ 1023/8*7+127=1016 ~ 1023*50/8*7/50+127=1022) 
'1.25 ~ 10V
SetVar = SetVar / 8 * 7 / 60 + 127

adjust:
 readadc10 FeedBk,FeedBkVar   'get voltage data from output
 if SetVar=FeedBkVar then main  'return if output is correct
 if SetVar>FeedBkVar then increase
   'if SetVar < FeedBkVar then decrease ~ falls through to decrease if not increase!
decrease:
 pausetime = FeedBkVar - SetVar
 high Gate      'set pin2 high to decrease Vout ~ Higher Gate V, Higher MOSFET R, Lower Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to lower gate voltage
 input Gate      'tri-state pin2 and hold Vout
 goto adjust
increase:
 pausetime = SetVar - FeedBkVar 'set pause time based on size of offset
 low Gate      'set pin2 low to increase Vout ~ Lower Gate V, Lower MOSFET R, Higher Vout
 pause pausetime     '0.5ms per count @ 8mHz, 1ms @ 4mHz per count ~ continue to raise gate voltage
 input Gate       'tri-state pin2 and hold Vout
 goto adjust

There is still the point raised some time ago that the response is slower when raising the output than it is when lowering the output. I assume this is because the Cap on the Gate R/C is tied to MOSFET Drain. It's about 50% slower on a full scale (1.2V ~ 10V)step change up compared to down.

I've had enough of tweaking this circuit as basically it has not improved by any signifcant amount since before it was published 4 or 5 and almost 40 posts ago.

 

[wapo54001]

BCJ,

I've gone through your routine and converted it into what I am familiar with, and it appears that you probably have pretty much reached the limit of what can happen here.

I had not noticed your input read method, which does only one readADC per input loop and stores three iterations -- much better than mine, where I was doing multiple readADCs per input loop and delaying output corrections too long.

I'll test it out today, but I can't see where we could go from here.

 

[wapo54001]

So, could we take this circuit and modify it and the code and come up with a really spiffy high-power PWM regulator???

 

[hippy]

A final thought ... Considering we're now setting the Gate for far longer than we were when we started, what about simply setting the Gate high or low and leaving it that way while checking Vout until it matches whatever the pot is set at and then making it an input ?

MainLoop:
  ReadAdc10 ADC_VPOT, vPot
  vWanted = ...
  ReadAdc10 ADC_VOUT, vOut
  If vOut = vWanted Then
    Input GATE
    Goto MainLoop
  End If
  If vOut > vWanted Then ' < ?
    High GATE
    Goto MainLoop
  End If
  Low GATE
  Goto MainLoop

 

[wapo54001]

I modified an existing circuit card and installed the variable voltage regulator software into the 08M. The attached photo shows the card which is smaller than 2"x2" and the required potentiometer and outboard LM317.

 

[BCJKiwi]

@Hippy,
This last code suggestion does improve response.
Tested with and without adjustable pause, with and without staying in adjust loop or returning to Main.
The optimum is shown below which, as you suggested is to dispense with the pause altogether and return to the main loop each time the match is made.

Found the Gate Charge Capacitor had to be reduced to 0.1uF to obtain full benefit (else the smaller kick was insufficient to improve speed of a change. (went back and tested smaller Cap on previous code but found jitter).
However careful adjustment of the CRO shows there is a 'V' shaped ripple in Vout as adjustment occurs.
When no adjustment is being made, this ripple might be an occasional single V above or below or almost continuous. It seems the precise pot position determines if the ripple is almost non existent or near continuous, The average of last x reads seems to have no effect on the presence or absence of this ripple. Also tried code to only move to the adjustment routine if the target has moved up or down more than 1 but this seemed to have no effect on the ripple.
Would have to assume this is a result of input variations of 1 ADC step causing the adjust circuit to 'hunt' up and down. This would seem to be confirmed as a fixed resistor, or just the right position of the pot, produces no ripple at all.

This ripple reduces in magnitude but increases in duration as C increases.
With the MOSFET being tested (IRL520), 1MR and 0.15uF the ripple is about +-0.04V in magnitude and of about 10ms duration per individual ripple.
This code reduces the full range step change by 1/3rd (with the 1.2 ~ 10V test setup.

Have changed the code to reflect the various changes and improved the remarks to make it (hopefully) clearer for others.

#picaxe 08M
setfreq m8
SYMBOL Set  = 4    'ADC4 ~ the voltage setting Pot input
SYMBOL FeedBk  = 1    'ADC1 ~ the feedback loop input
SYMBOL Gate  = 2    'In/Out2 ~ output 'pump' to the R/C network on the MOSFET Gate
High Gate      'Drive Vout to minimum for safety on start-up!
SYMBOL SetVar = w0
SYMBOL FeedBkVar= w1
SYMBOL Target   = w2
SYMBOL SetVar_1 = w3
SYMBOL SetVar_2 = w4
SYMBOL SetVar_3 = w5
SYMBOL SetVar_4 = w6
SYMBOL K_Div    = 8    'Max Vout / Min Vout   ~ e.g. 10 / 1.25 = 8 ~ Min Vout is a function of the Regulator
SYMBOL K_Mul    = K_Div - 1  'K_Div - 1
SYMBOL K_Min    = 127   '1023 / Max Vout * Min Vout ~ e.g. 1023 / 10 * 1.25 = 127
main:
 readadc10 Set,SetVar  'read setting Pot input voltage
'Sum the last three ReadADC values to reduce inconsistencies and smooth adjustment
'Setvar = 60* average of last three readings
'Adjust Set input value to ensure ouput cannot go below 1.25V minimum, or above MaxVout (1023 on FeedBack ADC)
'Target = adjusted range /60 plus bottom limit offset
'*60 / 60 improves Integer math accuracy (for example ~ 1023/8*7+127=1016 ~ 1023*60/8*7/60+127=1022) 
 SetVar_4 = SetVar_3
 SetVar_3 = SetVar_2
 SetVar_2 = SetVar_1
 SetVar_1 = SetVar *15  '* 15 to improve integer Math accuracy for Targrt calculation
 SetVar = SetVar_1 + SetVar_2 + SetVar_3 + SetVar_4 'Sum last 4 Readings,  Setvar = 60 * average reading
 Target = SetVar / K_Div * K_Mul / 60 + K_Min
'adjust:
 readadc10 FeedBk,FeedBkVar  'get voltage data from output
 if Target = FeedBkVar then
  input Gate    'hold Gate charge
  goto  main     'return as output matches target
 EndIf
'increase:
 if Target > FeedBkVar then 'Out put is too low so raise output
  low Gate    'lower Gate V = Lower MOSFET R = Higher Current through Adj circuit = higher Vout
  goto main
 EndIf
'decrease:
   'if Target < FeedBkVar then ~ falls through to decrease if not increase! If...Endif not required
  high Gate    'Higher Gate V = Higher MOSFET R = Lower Current through Adj circuit = Lower Vout
  goto main
end

I see from the Microchip data sheet for the PIC the 08M is using, that it should be able to run at 20Mhz with an R/C time base on leg 2. Any one know if this can be done on an 08M?

 

[hippy]

However careful adjustment of the CRO shows there is a 'V' shaped ripple in Vout as adjustment occurs ... Would have to assume this is a result of input variations of 1 ADC step causing the adjust circuit to 'hunt' up and down. This would seem to be confirmed as a fixed resistor, or just the right position of the pot, produces no ripple at all ... the ripple is about +-0.04V in magnitude and of about 10ms duration per individual ripple

I'd expected some ripple as there's a greater chance of under and overshoot when tracking at the desired voltage but it should be possible to optimise that away to a minimum. I think it's largely ripple free and we're seeing software affects in this case.

10mS may be the natural loop time of the program but that seems quite high to me, so could it be something else ? Is there a +/-1 problem with the Vout feedback measurement when it's at a transitioning point; does that need some averaging too ?

There are two divides and a multiply in the processing and they can take quite a time so it could be that the loop is slower than expected.

I think we are seeing problems with transitioning points ( both pot and feedback ) if it is rock-solid in some cases. Even averaging doesn't remove transition point problems, it just delays them unless they occur at the same frequency as the loop time which is unlikely.

Does the ripple get much worse when averaging is removed ?

If the natural loop time is less than 10ms ( I'd guesstimated ~2ms ) it would be possible to count loops and only read and update the average once every 50ms/100ms which would let averaging do a better job and not introduce much sluggishness ( averaging may need to use less iterations or rate of sampling adjusted accordingly ).

Could ~10ms equate to mains 50Hz / 60Hz noise ? Causing a transition of ADC, that firstly causes the Vout control to be moved up or down, then the disappearance of the transition plus the longer math processing allowing the Vout to overshoot before being corrected ?

Toggling Pin 0 every MainLoop would show what rate it were running at and the extended times involved when something does change. Looking at a second trace on an aerial may show correlation with mains pick-up or dispprove that.

An aside : If connected to the PC via download cables, is everyone using an enhanced download interface to prevent unwanted interaction with ADC operation ?

I see from the Microchip data sheet for the PIC the 08M is using, that it should be able to run at 20Mhz with an R/C time base on leg 2. Any one know if this can be done on an 08M?

I've had no luck at all trying to change just 08M fuse settings. Every attempt has borked the PICAXE and rendered the PICmicro unprogrammable ( but I'm sure they can be zapped in a different programmer to turn them into blank PICmicros ).

 

[hippy]

This may help ... change this ( and equivalent high gate code ) ...

 if Target > FeedBkVar then 'Out put is too low so raise output
  low Gate    'lower Gate V = Lower MOSFET R = Higher Current through Adj circuit = higher Vout
  goto main
 EndIf

to

 if Target > FeedBkVar then 'Out put is too low so raise output
  Difference = Target - FeedBkVar
  low Gate    'lower Gate V = Lower MOSFET R = Higher Current through Adj circuit = higher Vout
  if Difference <= SMALL_CHANGE then
    input Gate
  endif
  goto main
 EndIf

 

[BCJKiwi]

Well Hippy, you've done it again.
Really do appreciate your patience, objectivity and knowledge.

The following code sits rock steady unless a change to set point is made, or, output drifts sufficiently. Am actually quite amazed how little drift there is. There seems to be a bit at turn-on but once temps have stabilised, there is virtually none.

A DMM shows slight drift in the 1s of mV but have not yet seen a 10mV drift. Response to a step change is slightly reduced but is still much better than present published code.

When a change is required to correct drift there might only be a single pluse, or a short burst of 2 to 5 pulses then straight line again - quite amazing to see!

Have also been thinking and studying why the VN2222L is not good in this application.
What is apparent is that the MOSFET datasheets are not much use. The range of R required to make the change in current is small ~ typical adjustement pots are 5k. The ohmic range graphs just don't show data at this level or for such low currents as apply here(50uA).
It may also be that the logic level MOSFET is not a real advantage in this application as a higher gate threshold means there is more R variance to work with.

When monitoring the slight output drift and trying to set a specific voltage, have same problem that we do with the Bench supplies - setting pot is too coarse!

Here is the code;

#picaxe 08M
setfreq m8
SYMBOL Set  = 4    'ADC4 ~ the voltage setting Pot input
SYMBOL FeedBk  = 1    'ADC1 ~ the feedback loop input
SYMBOL Gate  = 2    'In/Out2 ~ output 'pump' to the R/C network on the MOSFET Gate
High Gate      'Drive Vout to minimum for safety on start-up!
SYMBOL SetVar = w0
SYMBOL FeedBkVar= w1
SYMBOL Target   = w2
SYMBOL SetVar_1 = w3
SYMBOL SetVar_2 = w4
SYMBOL SetVar_3 = w5
SYMBOL Damper = w6
SYMBOL K_Div    = 8    'Max Vout / Min Vout   ~ e.g. 10 / 1.25 = 8. ~ Min Vout is a function of the Regulator
SYMBOL K_Mul    = K_Div - 1  'K_Div - 1
SYMBOL K_Min    = 127   '1023 / Max Vout * Min Vout ~ e.g. 1023 / 10 * 1.25 = 127
'#terminal 9600
main:
 readadc10 Set,SetVar  'read setting Pot input voltage
'Sum the last four ReadADC values to reduce pot inconsistencies and smooth adjustment
'Setvar = 60* average of last three readings
'Adjust Set input value to ensure ouput cannot go below 1.25V minimum, or above MaxVout (1023 on FeedBack ADC)
'Target = adjusted range /60 plus bottom limit offset
'*60 / 60 improves Integer math accuracy (for example ~ 1023/8*7+127=1016 ~ 1023*60/8*7/60+127=1022) 
 SetVar_3 = SetVar_2
 SetVar_2 = SetVar_1
 SetVar_1 = SetVar *20  '* 20 to improve integer Math accuracy for Target calculation
 SetVar = SetVar_1 + SetVar_2 + SetVar_3   'Sum last 4 Readings,  Setvar = 60 * average reading
 Target = SetVar / K_Div * K_Mul / 60 + K_Min
'sertxd (#target,cr,lf)
'adjust:
 readadc10 FeedBk,FeedBkVar  'get voltage data from output
 if Target = FeedBkVar then
  input Gate    'hold Gate charge
  goto  main     'return as output matches target
 EndIf
'increase:
 if Target > FeedBkVar then 'Out put is too low so raise output
  Damper = Target - FeedBkVar
  If Damper < 2 then main 'If change is less than 1 unit, skip ~ damps out 'hunting' around set point
  low Gate    'lower Gate V = Lower MOSFET R = Higher Current through Adj circuit = higher Vout
  goto main
 EndIf
'decrease:
   'if Target < FeedBkVar then ~ falls through to decrease if not increase! If...Endif not required
  Damper = FeedBkVar - Target
  If Damper < 2 then main 'If change is less than 1 unit, skip ~ damps out 'hunting' around set point
  high Gate    'Higher Gate V = Higher MOSFET R = Lower Current through Adj circuit = Lower Vout
  goto main
end

 

[hippy]

I've finally found a MOSFET ! From the Ark; VN10L. Couldn't even find an exact datasheet but seems to work.

I've just thrown the circuit together using an LM317 sub-system I already had so somewhat different from the recommended circuit and I used an 18X. That was useful because it means I can connect a tri-colour LED to show when it's kicking the cap up (green) or down (red). To start with I'm not using a pot, just specifying the desired feedback value in the program.

With the charge/discharge until matched loop I suggested the LED glows orange showing it's hunting quite a bit and a DMM shows ~0.01V change every so often. With just a short blip of charge / discharge it's much more steady, there's an occassional flash of green as the cap leaks and it needs a kick to keep it where it should be. I stayed with this because I'm not worried about responsiveness to pot change at this time.

Three things of note -

1) An 18X sets output low at turn-on which pushes Vout to max, and during program download. This makes an 8X more complicated for use but an output could be run through an inverter and then diode fed via a separate 1M to the Gate. Once that output is switched the diode would be reverse biased so should effectively be removed from the circuit. Haven't tested that.

2) The circuit is very noise sensitive. Put one's hand anywhere close to the circuit and the LED goes into 'disco lighting' mode. Most sensitive seems to be the Vout feedback line into the ADC ( I have the Vout divider at the LM317 end ).

3) It's probably impossible to get this working beyond 'seems okay' without a scope.

 

[hippy]

Well Hippy, you've done it again.
Really do appreciate your patience, objectivity and knowledge.

I don't think I can really take the credit because a lot of effort went into trying various things and I simply pulled the 'in which case ...' out the bag.

I think the most frustrating thing has been not having the hardware to use and not being able to see what's going on. Nothing beats looking over someone's shoulder and seeing exactly what's what on a scope trace and the effects of tweaking this and that ( apart from doing it yourself ). I think you can tell my frustration was leaking through a bit, so sorry for that and I really am glad you've got it going.

On the control front, two pots in series, 4K7 and 1K wired as variable resistors, plus a resistor to make a divider would give course plus +/-10% control of desired voltage although some resolution may be lost.

I'm also thinking two separate state machines; one for when the pot isn't moving and one for when it is. That should get the responsiveness up while keeping static track accurate and fast.

Given that I threw a circuit together and it's working for me ( although it could be pretty horrible if I looked at a scope ) shows what a brilliant idea the MOSFET plus cap idea was.

Have we beaten the Nesbit thread yet ? Just a few more posts and Dippy can claim number 200

 

[BCJKiwi]

There's a datasheet for a VN10LP here http://www.zetex.com/3.0/pdf/vn10lp.pdf (2005 - not that old!) - is that the same? This appears similar to the 2N7000 (which I don't have).

Test circuit here shows no sensitivity to waving body parts around the circuit unless I actually touch some part of the 08M side of the gate circuit.

 

[BCJKiwi]

Come up with a two pot scheme for coarse/fine adjustment.

A dual-gang linear pot of say 10K is wired up as two variable resistors (working the same way). Wipers feed each end of a single say 1k pot set up as a divider. The other ends are connected, one to +V and the other to 0V. The wiper of the divider goes to ADC.
Like this;

'   V+  --------------------------+
'                                 |
'                                +++
'                                | |
'                          +---->| | Gang1 of Dual Gang 10k Linear Pot
'                          |     | |
'                          |     +++
'                          |      |
'                          +------+
'                                 |
'                                +++
'           +-----+              | |
'08M Leg3 --+ 10k +--+---------->| |  1k Linear Pot
' (ADC4)    +-----+              | |
'                                +++
'                                 |
'                          +------+
'                          |      |
'                          |     +++
'                          |     | |
'                          +---->| | Gang2 of Dual Gang 10k Linear Pot
'                                | |
'                                +++
'                                 |
'   0V  --------------------------+

This provides a constant resistance from +V to 0V of 11K

The 10K pot slides the 1K pot up and down between +V and 0V representing the coarse adjustment, and the divider has fine control over 1/11th of the full range improving the ability to precisely adjust the set point.

Have tested this with 2 x 5K and a 1k Pot and it works well (even if a little difficult to control since these are three separate pots but proves the concept!).

Any further thoughts/suggestions?

 

[hippy]

The VN10L I have has no extra letter suffix. Pinout is as per VN10LP and in a transistor style package, but has a slither of metal coming out of the top about 1mm which I presume is some sort of heatsink.

I found a couple of references to plain "VN10L" online, one a PICAXE project where it's used to switch relays and a parts for sale where it's $100 rather than the $3 for the rest ! I don't know what's so special about this MOSFET other than it seems rare.

 

[BCJKiwi]

Well it looks like we have hit post #200 - sorry Dippy, too slow!

Conducted further tests with Ganged and single pot circuit above. Confirm that 100k Dual gang pot variable resistor(s), and 10k diivder work very well.