Hotwire Regulator Design Collaboration Project part 3

[Alan B]

The Programmable Hotwire Driver, as it has come to be called, has spawned some application specific projects. Basic design continues in this thread, and specific implementation threads are linked at the bottom of this posting. The photo above is of Alan's M@gSled first prototype, designed to drop-in to a D M@g and occupy the space for the original switch.

This Product is Available from the Order Thread:
http://www.candlepowerforums.com/vb/showthread.php?t=231886

Now on to this, the third section of the Design thread:

(Material from the first post of the previous thread, edited):

Now that I've built a M@g85 I can see the value of a soft starting regulator for incandescent flashlights. But I don't see much availability. ...

Being the electronics and software engineer that I am makes me think of how to build a simple regulator. With today's microprocessors having PWM, ADCs, temperature detection and just about everything else (memory, clock, ram, etc) built in, it would seem to me that very few parts are required. I have done projects with AVR and PIC microprocessors. It is amazing what can be done with a single small low lead-count chip. (The design developed here uses only about a dozen parts).

Requirements:

Primary Features:

1) soft start
2) regulated RMS bulb voltage by PWM for high efficiency
3) provide battery overdischarge protection
4) provide overtemperature protection for the electronics
5) provide selectable voltage levels (programmable Vbulb)

(10/4/08, above items are coded and tested, the FET power driver is tested)

6) have a lock off sequence for safety - secret unlock sequence to prevent accidental turnon (or provide a 'normal' flashlight Vbulb mode that would run the bulb at a lower setting that is very safe, and keep the turbo mode for expert access)
7) provide a 'timeout' feature to dim and shutdown to limit runtimes when desired
8) make it user reprogrammable, with free software tools and simple/inexpensive PC interface
9) have some public open sourcecode so folks could play with the user interface and make customized versions

As of 1/2009 the above requirements have been accomplished

10) have a public pcb layout available so folks could roll their own small batch if needed
11) one or more folks can make the hardware (and sell it), over time if they become unavailable someone new can step in and make hardware that will work with the same or slightly modified software
12) be a simple enough design to allow a builder to make one without a pcb (DIY dead-bug style, etc)

Secondary Features (possibly developed later):

1) provide one button reprogramming in the field for voltage settings, etc
2) provide a minimum off timer to reduce bulb wear from over clicking friends
3) auto-detect battery type and set voltage protection
4) other ideas??

It does not take a lot of parts to do this. A good Power FET directly driven from an AVR or PIC micro PWM output, and a way to measure the actual battery voltage, plus some calculations to determine the effective (RMS) voltage and adjust smoothly to the desired value. Approximately three processor I/O pins are required:

1) pushbutton input (option, some designs don't need this)(need on-switch detection in some cases)
2) pwm out
3) battery voltage

-) bulb RMS voltage is calculated from battery V and duty cycle of PWM

This would place square wave current pulses into the filament, but the frequency can be selected to be high enough to avoid problems, but low enough to manage losses in the switching FET. The thermal inertia of the filament provides the filtering, so pulses must be short enough for the temperature to be essentially constant from pulse to pulse.
We now know that other earlier designs work this way. JimmyM's soft start is not a micro. AW's is PWM but not a regulator. Most others I find (AWR et al) are no longer available.

Anyone interested in something like this? I don't have the time to do the whole project, but I may be able to do some part of it. Perhaps it could be some kind of group project?

Any interest? Any important requirements or concerns about this simple approach?? Anyone want to work on this???

If you have any links to similar projects (past or present), post them in this thread so we can review them and give them credit.

If you have done similar work or have ideas, chime in and let us know!

-- Alan


Today (1/24/2008) we start part 3 of the thread.

Part 1 is here:

http://www.candlepowerforums.com/vb/showthread.php?t=186291

Part 2 is here:

http://www.candlepowerforums.com/vb/showthread.php?t=209098

Project Status (1/24/2009)

Alan has a prototype drop-in "Sled" working in a D M@g. JimmyM has a development PCB working (and he may have a couple available - contact him directly). JimyM is working on a version to fit under a KIU socket adapter. wgiles is working on a version to mount in a special SF M6 battery holder. (links at bottom of this post).

Project Status Update (July 2009)

Production Regulators have started shipping. See the order thread for more information:
http://www.candlepowerforums.com/vb/showthread.php?t=231886

Schematic

http://akbeng.com/flash/hwreg/hrdc1d.bmp

Earlier Notes:

We have Code and Hardware Working:

The above is an actual scope capture of the output of the CPU driving PWM to the FET gate (in blue), and the output of the FET (in red) while driving a WA1185 bulb on Alan's test M@G D Sled prototype PC Board.

We have prototype hardware running. Alan B's sled board, and wquiles' protoboard. At this point (10/4/2008) we are working on software and calibration, and have worked through a couple of minor problems. Alan built and tested the USBtinyISP programmer. This is a $22 kit for programming the micro. This will be useful for loading the software, changing the parameters, and trying out different versions of the software. Advanced users and builders will want a programmer to have complete control over the software in their flashlights.

Alan has developed software using the Atmel STK500 board. This board has the programming capability, a socket for the CPU, and an LED and switch that can be jumpered to the chip. Using this Alan has developed software that does most of the basic functions - variable levels, voltage regulation, temperature and low battery cutout, etc. This is still in work, but it is doing most of the important functions required for this project.

Prototypes of the hardware are working. JimmyM and Alan are both working on pc boards. Alan's board is made and working, and Jim's test board is designed but not cut yet.

We have a couple of user interfaces including VariLevel Ramped with optional double-click boost, and On/Off. We have soft start. We have RMS feedback regulation.


Next Step:

The calibration problem appears to be solved, so it is about time to package this in a flashlight, and make some 'operational' software versions. The dynamic calibration needs to be finished up. Perhaps a multilevel interface option would be useful. Possibly one or more small PCBs designed to fit inside "C", "D" M@gs or SF M6's. High Power bulb testing would be interesting. Will wants to work on a one button interface and a SF M6 version. Jim wants to try a "high power" version with a driver.


Signup Sheet:

Send me a pm if you want to be added to this list:

Hardware Design: mostly done, here on the forum, by Alan B, JimmyM and That_Guy; with lots of helpful input and encouragement by folks like LuxLuthor, and others.

Hardware Prototyping: Alan B, JimmyM and wquiles working on.

Application Specific versions - wquiles is working on the SF M6 version, and JimmyM is working on a D M@G version to fit under a KIU base. Alan is working on a drop-in version for the D M@g called the M@gSled. (links at bottom of this post).

High Power Testing - Possibly Jim and LuxLuthor?

Software Development: The software is pretty far along at this point. Based on AVR-GCC in WinAVR and AVR Studio for this. All Free software tools. Thus far Software is by Alan B with input and feedback from lots of others. (JimmyM is developing a software variant to work with the similar Tiny84 chip).


Test Programs: (these are done)

* FP1: Toggle the FET Gate Output (very slow or 100 hz, 50% duty cycle)
* FP2: Electronic Pushbutton Switch (on/off)
* FP3: Always On, Fixed PWM, Soft Start
* FP4: Pushbutton, Fixed PWM, Soft Start
* FP5: Pushbutton, VariLevel PWM, Soft Start
* FP6: Always On, Regulated, Calibrated, Soft Start
* FP7: Pushbutton, Regulated, Calibrated, Soft Start
* FP8: Test Suite for ADC, PWM, Regulation Algorithms
* FP9: Flashlight Program with lots of features

More to come.


Design File Area: (schematics, code, scope traces, data)

http://akbeng.com/flash/hwreg/


References:

The Lightbrain 2002 DIY regulator is very similar to the design goals for this project:
http://lasertagparts.com/lightbrain/free_regulator.htm

AWR HotDriver (soft start, linear):
http://www.cpfmarketplace.com/mp/showthread.php?t=107783

PIR1 PWM Regulator Thread:
http://www.candlepowerforums.com/vb/showthread.php?t=107211

PIR1 Regulator Manual:
http://greenengineering.se/PIR1/PIRmanual.pdf

LVR (Willie Hunt) Lamp Voltage Regulator:
http://www.cs.indiana.edu/~willie/lvr.html

That_Guy Regulator (similar to LightBrain):
http://img169.imageshack.us/img169/5875/pwmregulatorff7.png
http://rapidshare.com/files/87979929/PWM_Regulator.zip.html

JimmyM JM-SST Soft Start:
http://www.candlepowerforums.com/vb/showthread.php?t=181866

AW Soft Start:
http://candlepowerforums.com/vb/showthread.php?t=166223

Kiu Bipin Socket:
http://www.candlepowerforums.com/vb/showthread.php?t=171607

(Destructive) Bulb Testing - lots of bulb data:
http://www.candlepowerforums.com/vb/showthread.php?t=179748

More Bulb Data (for the SF M6, but useful for others):
http://www.candlepowerforums.com/vb/showthread.php?t=204157

Atmel Tiny85 Microprocessor Info:
http://www.atmel.com/dyn/products/product_card.asp?part_id=3612

Atmel AVR ISP2 USB Programming Adapter:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=ATAVRISP2-ND

AvrFreaks on the Tiny85:
http://www.avrfreaks.net/index.php?module=Freaks Devices&func=displayDev&objectid=102

Low Cost USB programmer (tested, works):
http://www.ladyada.net/make/usbtinyisp/

AvrDude Programming Software (included in WinAVR):
http://www.ladyada.net/make/usbtinyisp/avrdude.html


Application Projects based on this Project's Design:

D M@g Drop-in by Alan B:
http://www.candlepowerforums.com/vb/showthread.php?t=218506

SF M6 thread by wquiles:
http://www.candlepowerforums.com/vb/showthread.php?t=215806

D M@g under Kiu Base thread by JimmyM:
http://www.candlepowerforums.com/vb/showthread.php?p=2743186


eof

 

[Alan B]

Easy Calibration Setup

Today I added a quadclick to 5.00 volt option to the interface. Then I used this to calibrate the ADC.

The Procedure:

Load the CPU with the default software which calibrates based on the specs for the CPU and resistors.

Quadclick the flashlight to output 5.00 volts to the bulb output (where I have my meter plugged in).

Take the value that I read there (in this case 4.66V) and put that value into the software.

Compile and reload the CPU.

Quadclick to go to 5.00V and verify the reading is 5.00V.

It Works!

Now if an averaging meter is used we need to read battery voltage and average bulb voltage instead of the one reading, but I can put those into the program as another option. So the user does NOT need to do ANY calculations. Merely set the output to 5.00V and read it, and read the battery voltage, and put both numbers in. Compile and reload the chip. Calibrated.

I chose 5.00V since it should not hurt any bulbs if accidentally triggered with a bulb in. It is actually a good medium level for the M@g85. The feature can be removed after calibration if desired.

== Alan

 

[SafetyBob]

Alan, great recap of the massive amount of work that has gone into this project. The sight of your prototype sled is also a work of art. It is obvious that we are quickly closing in on a completed sled and testing. That is great news.

I will be wanting at least 2 of these for incan fun here in Oklahoma.

Thanks to everyone who has contributed even in the smallest degree, it has made this a superior effort that will be very rewarding for all of us.

Bob E.

 

[Alan B]

Alan, great recap of the massive amount of work that has gone into this project. The sight of your prototype sled is also a work of art. It is obvious that we are quickly closing in on a completed sled and testing. That is great news.

I will be wanting at least 2 of these for incan fun here in Oklahoma.

Thanks to everyone who has contributed even in the smallest degree, it has made this a superior effort that will be very rewarding for all of us.

Bob E.

Thanks Bob. Interest noted in the feeler thread post #5.

A bit more recent status detail:

The M@gSled board prototype design #2 is in the mail and I should have it monday. Actually it is in the UPS.

I have been doing a lot on the software. Redid the UI (user interface) code and compressed the code, and cleaned a lot of old junk out of it. Added lockout, doubleclick to turbo, tripleclick to half voltage options.

The new Fluke 189 meter is really nice. Used it to calibrate the ADC a bit ago. Really nails it. I wanted to get a meter that would make it really easy to calibrate these since it looks like I will have a bunch to calibrate, and I want to farm that work out to my kids when there are a lot to do. It needs to be straightforward for that to be efficient and accurate.

When we calibrate it we can write down the pre-calibration voltage values so the user can use those values in the software if they need to reload the chip, and save them the step of recalibrating. It is not that hard to do a calibration, but it is an extra step if you are just trying to change an option in the software.

-- Alan

 

[JimmyM]

I have an update regarding the FET compensation.
It makes little difference.
No-Compensation
Vin_____1157 bulb_______1157+64447
13.5V___12.07V_________11.97V
25V_____12.03V_________11.98V

With Compensation
Vin_____1157 bulb_______1157+64447
13.5V___12.06V_________12.02V
25V_____12.03V_________12.00V

So a few hundreths of a volt. Keep in mind that the 64447 @ 25V only has ~10.4 Peak amps.
A different bulb, with more peak amps may show greater value to compensation.
I do have a 64275 that should pull a lot of amps at high Vin.
I'll test and get back to you.

Nope. no real difference.

 

[SafetyBob]

I don't know Jimmy, I really think I might be able to see that 0.03VDC drop when I make my double head 623 and switch from one light on to two......now what am I supposed to do?

I'll tell you. JUMP FOR JOY!!!

That kind of regulation I did not think was possible in this kind of build. Period. That is frankly amazing. And I am glad your kids will get involved to. I hope you slip them a dollar or two for doing that. I hope they will follow your footsteps into the electrical world.

Interface sounds even better than we had ever imagined even three weeks ago.

Please keep us up on the testing of the sled.

Bob E.

 

[JimmyM]

I don't know Jimmy, I really think I might be able to see that 0.03VDC drop when I make my double head 623 and switch from one light on to two......now what am I supposed to do?

I'll tell you. JUMP FOR JOY!!!

That kind of regulation I did not think was possible in this kind of build. Period. That is frankly amazing. And I am glad your kids will get involved to. I hope you slip them a dollar or two for doing that. I hope they will follow your footsteps into the electrical world.

Interface sounds even better than we had ever imagined even three weeks ago.

Please keep us up on the testing of the sled.

Bob E.

Thanks for the kudos on the regulation, but it's Alan's kids that will be pressed into slave labor. Er I mean, assistance, yes. Assistance. Must remember that for Social Services, if I'm ever subpoena'd.
All kidding aside, my 7 year old daughter loves to come down to the shop and "help out". Even if that means me and her hooking up a 1.5V motor to my 50V bench supply and ramping it up until we let the smoke out.

 

[wquiles]

All kidding aside, my 7 year old daughter loves to come down to the shop and "help out". Even if that means me and her hooking up a 1.5V motor to my 50V bench supply and ramping it up until we let the smoke out.

That sounds like fun :devil:

Will

 

[Alan B]

Thanks for the kudos on the regulation, but it's Alan's kids that will be pressed into slave labor. Er I mean, assistance, yes. Assistance. Must remember that for Social Services, if I'm ever subpoena'd.
All kidding aside, my 7 year old daughter loves to come down to the shop and "help out". Even if that means me and her hooking up a 1.5V motor to my 50V bench supply and ramping it up until we let the smoke out.

My kids are both young adults and I do remunerate them for services in my small business. Mostly it is pulling parts, packing and shipping. This project could be an opportunity for them to learn some new skills as well as helping me and getting things done a bit faster.

-- Alan

 

[smflorkey]

Previous-thread quote from JimmyM: " All of my variables are declared as globals. Perhaps I'll try moving them into the main section. However, I have a routine that I call to reads the ADCs and sets the result as a variable I then use that variable in the main code. Does this variable need to be a global?"

I haven't done embedded programming so I may be missing something important, but in the big stuff where memory doesn't matter I would make your routine return a value to its calling point in main(). Something like

int cool_routine(int Vref, int ADC, int keepFirst, int sample_count, int read_count);

then later in main()

result = cool_routine(Vref, ADC, keepFirst, sample_count, read_count)

or

newState = oldState + cool_routine(Vref,ADC,keep1,sampleC,readC) * k;

In this way your routine looks a lot like a global variable. The value it returns can be assigned to a local variable or simply used directly.

Hope that helps. I've been enjoying reading this story. I may have to build a big incan (in my Copious Spare Time) so I can make use of the technology you all have shared.

 

[Alan B]

...

I haven't done embedded programming so I may be missing something important, but in the big stuff where memory doesn't matter I would make your routine return a value to its calling point in main(). ...

Welcome to the thread, smflorkey!

You might enjoy programming these little chips!!

Many things that we routinely do in larger computers consume more resources than we like in the small chips. You can do them but once you figure out how to save codespace and time you may want to do that. I probably take it to an extreme, but I have programmed little chips over a long period and I enjoy the challenge. The sourcecode doesn't look as pretty perhaps, but it takes on its own rugged beauty in the efficiency. These days I'm getting the preprocessor to do all the hard lifting and reduce everything possible to small integer constants since those fit well in the 8 bit CPU.

Some of the philosophy when resources are at a premium:

Function call parameters are expensive. They have to be pushed on the stack and popped off the stack later. They take a lot of stack space, and RAM is small in these CPUs. Use them when necessary but it is generally much cheaper in code and memory space to access a global. Even a simple function call without parameters can be expensive as a lot of registers may need to be preserved. If the function is just doing a couple of lines of code it may be better done inline, or us a macro to avoid repeating the sourcecode.

In many CPUs globals are cheaper than locals to access. This is apparently not the case in the Tiny85 with GCC as moving globals to local in main caused a savings in codespace. Have to test the compiler/CPU to determine the resource cost. Know what code costs in time and space. Try test programs. Look at the code generated. Know your tools.

Wordsize - byte, integer, float - Bigger costs a lot, and floats cost a lot more. Use what is required and not more.

It is amazing what can be fit into a 2K processor (1K instructions). We can go to an 8K part in this package if necessary! Using a larger chip and less careful code generally causes hard to find bugs and reliability problems. So start small and build carefully.

-- Alan

 

[JimmyM]

Previous-thread quote from JimmyM: " All of my variables are declared as globals. Perhaps I'll try moving them into the main section. However, I have a routine that I call to reads the ADCs and sets the result as a variable I then use that variable in the main code. Does this variable need to be a global?"

I haven't done embedded programming so I may be missing something important, but in the big stuff where memory doesn't matter I would make your routine return a value to its calling point in main(). Something like

int cool_routine(int Vref, int ADC, int keepFirst, int sample_count, int read_count);

then later in main()

result = cool_routine(Vref, ADC, keepFirst, sample_count, read_count)

or

newState = oldState + cool_routine(Vref,ADC,keep1,sampleC,readC) * k;

In this way your routine looks a lot like a global variable. The value it returns can be assigned to a local variable or simply used directly.

Hope that helps. I've been enjoying reading this story. I may have to build a big incan (in my Copious Spare Time) so I can make use of the technology you all have shared.

I've changed my variable definitions. where/how. Now all variables are defined/declared within the main() section except where they are needed in the subroutines.
When I need a value from the subroutine I use the subroutine to return a value instead of storing the result to a global variable.

So...

uint16_t adcval = 0;
uint16_t adcvariable = 0;

void readADC(uint8_t newadmux, uint8_t dumpfirst, uint8_t samples, uint8_t divisor)
{
adc code stuff
}

main()
{
readADC(0x03,1,2,1);
adcval = adcvariable;
}

Becomes...

void readADC(uint8_t newadmux, uint8_t dumpfirst, uint8_t samples, uint8_t divisor)
{
uint16_t adcvariable;
adc code stuff
return(adcvariable)
}

main()
{
uint16_t adcval;

adcval = readADC(0x03,1,2,1);

}

Now I'm using 10.5% program space, 0.0% data. Before the total was closer to 20% total. This is on the Tiny84.

 

[Starlight]

Alan, your Easy Calibration Setup is a great idea. It solves the meter problems for all of us. Well Done!

 

[Alan B]

Alan, your Easy Calibration Setup is a great idea. It solves the meter problems for all of us. Well Done!

Thanks.

I made some quiescent current measurements with the Fluke 189. It is about 7mA without shutting down the CPU. My code that shuts down the CPU took it down to 3mA. I expected less idle current, so I need to do more work on that program.

Good to see some higher current testing, Jim. Also those local instead of global variables sure saved you a lot of codespace!

Tonite the battery in my prototype finally ran down on me so I got to see the low battery code for real. It worked pretty well, though as the battery gets lower it really cannot do much more than turn off or dim way down. There just isn't enough power to do more than come on very low or go off.

The FAQ is taking shape in the M@g D Feeler thread. That should answer a lot of questions in one place. It may be a little tricky to handle the variations because the answers are not the same for all three variants, so we'll have to think about that. Possibly break it into sections.

I have added code that takes a bulb type, battery chemistry and number of cells, and fills in the voltages. There is still a manual override, but this way the standard values are there and one can just select the factors. This is all done at compile time so no codespace in the chip is required. More work for the preprocessor.

-- Alan

 

[Alan B]

Thanks.

I made some quiescent current measurements with the Fluke 189. It is about 7mA without shutting down the CPU. My code that shuts down the CPU took it down to 3mA. I expected less idle current, so I need to do more work on that program.

...

-- Alan

I made a change to the code and dropped the off-current to 300 uA which would take 270 days to drain Eneloops. I'm not done yet, I may reduce that further, but it will probably take minor hardware adjustments to accomplish that. (such as changing resistors and changing a bit of code). If we double that value one more time then the self-discharge will probably be equal to the drain and there is not much benefit available beyond that. The tailcap lockout is always there, too...

JimmyM asked what was done to reduce the current - essentially it took a one bit change. The CPU sleep state was not optimal. I had set it to "idle", I changed it to "power down". I don't recall which bit it is, but the code is in FP9 except for this one bit change in a constant. The processor consumption in power down is about 1uA, and all the clocks are stopped. I turned off the ADC before sleeping already. I need to double check if the Vref generator needs to be turned off separately, that is another item that might still be on.

I'm considering using the 1.1V ADC range which will also reduce the current. I believe Jim already did that. We could also stray from the specifications for the ADC input impedance and raise it (which would lower the divider current), but it is difficult to evaluate the consequence of that. Since I'm only using 8 bits I can probably get away with a bit more than the 10 bit codes. Getting good 10 bits from these ADCs is difficult.

On another item, I wrote code to sample the ADC in the center of the PWM. I have not tested it yet. Jim has already done this, but he has a fiducial there to test or interrupt on, and the PWM mode my code is in does not. So I checked to see what it takes to do a delay to the center of the PWM (finding the edge was already coded). Interestingly enough, it takes an argument to the low level gcc library delay function that is four times the PWM value. Which is trivial to do since you just shift the PWM value two bits left and call the delay loop with that value. I'll probably test the code, but I have a different technique that I plan to use that samples the pulse in several places.

A bit more dieting on the code has it at 55% of the 2K part, so there is a lot of space for improvements, and the code has a lot of features in there now. I use it every day as a flashlight, and it has a nice user interface and a very impressive range from a few lumens to a thousand or so. At 2 volts the light output is similar to a M@g solitaire (though it is orange), and at 10.8 volts it is more than required for most purposes. The boot-up memory value is midway between low and high, or 6.4 volts ((2+10.8)/2) which is a very nice useable level as well. I do have code that allows the memory to survive reboots, but that is not turned on at the moment.

Also the lockout function is currently reset by rebooting, so I will probably have to fix that and store the lockout in the nonvolatile memory. Perhaps that should be another option, do folks want the lockout to stay locked when the tailcap is loosened and the CPU reboots? It would seem to be a good idea if the lockout is to be very robust.

-- Alan

 

[Alan B]

I started working on a feature that I thought about a long time ago but never pursued. This relates to using the three Vref's of the ADC for three voltage ranges. The Vref's are 5.0, 2.56 and 1.1 volts. Switching between these ADC ranges gives a very nice set of three fullscale voltages. I just need to set up the code so everything compensates for the change, including the scaling, the ADC initialization, and the calibration.

I will probably set it up so that the calibration voltage changes as well. So on the low voltage range the cal voltage will be 5.00 volts, 10.00 on the midrange and 20.00 volts on the high range, subject to change as I get the code done.

So by changing the settings in the compiler there will be three voltage ranges. That way there won't be any resistor swaps.

Seems like a better choice for everyone.

-- Alan

 

[wquiles]

That would be AWESOME!

As you know I have been using the VCC reference, and it was been working perfectly, so I have no doubth that what you are trying here will work well

Will

 

[LuxLuthor]

Easy Calibration Setup

Today I added a quadclick to 5.00 volt option to the interface. Then I used this to calibrate the ADC.

The Procedure:

Load the CPU with the default software which calibrates based on the specs for the CPU and resistors.

Quadclick the flashlight to output 5.00 volts to the bulb output (where I have my meter plugged in).

Take the value that I read there (in this case 4.66V) and put that value into the software.

Compile and reload the CPU.

Quadclick to go to 5.00V and verify the reading is 5.00V.

It Works!

Now if an averaging meter is used we need to read battery voltage and average bulb voltage instead of the one reading, but I can put those into the program as another option. So the user does NOT need to do ANY calculations. Merely set the output to 5.00V and read it, and read the battery voltage, and put both numbers in. Compile and reload the chip. Calibrated.

I chose 5.00V since it should not hurt any bulbs if accidentally triggered with a bulb in. It is actually a good medium level for the M@g85. The feature can be removed after calibration if desired.

== Alan

Holy Moly that is great!

I made a change to the code and dropped the off-current to 300 uA which would take 270 days to drain Eneloops. I'm not done yet, I may reduce that further, but it will probably take minor hardware adjustments to accomplish that. (such as changing resistors and changing a bit of code). If we double that value one more time then the self-discharge will probably be equal to the drain and there is not much benefit available beyond that. The tailcap lockout is always there, too...

JimmyM asked what was done to reduce the current - essentially it took a one bit change. The CPU sleep state was not optimal. I had set it to "idle", I changed it to "power down". I don't recall which bit it is, but the code is in FP9 except for this one bit change in a constant. The processor consumption in power down is about 1uA, and all the clocks are stopped. I turned off the ADC before sleeping already. I need to double check if the Vref generator needs to be turned off separately, that is another item that might still be on.

A bit more dieting on the code has it at 55% of the 2K part, so there is a lot of space for improvements, and the code has a lot of features in there now. I use it every day as a flashlight, and it has a nice user interface and a very impressive range from a few lumens to a thousand or so. At 2 volts the light output is similar to a M@g solitaire (though it is orange), and at 10.8 volts it is more than required for most purposes. The boot-up memory value is midway between low and high, or 6.4 volts ((2+10.8)/2) which is a very nice useable level as well. I do have code that allows the memory to survive reboots, but that is not turned on at the moment.

Also the lockout function is currently reset by rebooting, so I will probably have to fix that and store the lockout in the nonvolatile memory. Perhaps that should be another option, do folks want the lockout to stay locked when the tailcap is loosened and the CPU reboots? It would seem to be a good idea if the lockout is to be very robust.

-- Alan

Sweet Jesus!

I started working on a feature that I thought about a long time ago but never pursued. This relates to using the three Vref's of the ADC for three voltage ranges. The Vref's are 5.0, 2.56 and 1.1 volts. Switching between these ADC ranges gives a very nice set of three fullscale voltages. I just need to set up the code so everything compensates for the change, including the scaling, the ADC initialization, and the calibration.

I will probably set it up so that the calibration voltage changes as well. So on the low voltage range the cal voltage will be 5.00 volts, 10.00 on the midrange and 20.00 volts on the high range, subject to change as I get the code done.

So by changing the settings in the compiler there will be three voltage ranges. That way there won't be any resistor swaps.

Seems like a better choice for everyone.

-- Alan

Dear Lord...have I died and gone to Heaven?

 

[wquiles]

+1 - These features/improvements in the firmware are great!!!!!

Will

 

[Alan B]

I am building a P7 with a d2Flex and I could not help but notice the similarity between the controller design and the regulator here.

It uses the same Tiny85 CPU, and a FET PWM switch, and of course there is a control switch input, and a voltage regulator.

The FET is only good to around 3.4 amps at 70C, and 24V.

The d2Flex is fairly small at 0.8" diameter on a round board (M@g C size).

The pushbutton control switch input appears to be on the same pin my software already uses.

The FET gate output is on a different pin than I used, which would require some minor software changes. Probably about 4 lines of code would change.

The voltage input divider is missing. This would require two resistors be added.

The programming interface is by pads, so something would be required there. The easiest might be to wire a standard six pin programming plug and epoxy it on the board. There is quite a lot of room on the back side.

This regulator, modified and reprogrammed, should be just adequate for a M@g85. Keep the current below 3.4A and the voltage well below 24V, say 15-18V.

Jim's future small regulator will have a lot more voltage and current capability. But if someone wants to experiment now, this could be a quick way to start.

Now, I have not done this, so there may be a surprise or problem. It would require working with some small wires and modding a surface mount board, but the mods appear to be fairly simple. If someone wants to try this I am willing to give a bit of help.