Attiny25/45/85 FW Development Thread

1911 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 7 hours 34 min ago
Joined: 08/19/2012 - 08:23
Posts: 12880
Location: LI NY

I can't make all that much sense from all those posts, sorry.

About the flash going into moon mode, the 10K or 12K FET gate resistor solves it - been using it for months. Going back to PWM rates even under 1K is going backwards. Hope the high PWM rates don't have to be sacrificed to get clean pulses.

Decided to button up the JM07 now rather than experimenting with it. Started on a BLF SD10 (Lumintop) upgrade and thought I'd use it's new driver for the R&D. I had it populated, added the 12K FET gate resistor, programmed the 85 (Narsil), and wired it up, sandwich style on the stripped stock driver. Well, the darn thing works perfectly now - didn't need a cap or anything. Think this is the first one that didn't need a cap to change modes reliably... Only difference is that I'm supporting a green indicator SMD LED on pin #3 of the MCU. The SD10 light has a white/transparent button and had the green LED already there, so I "air wired" a 470 ohm resistor between the LED and pin #3, and it works great! In Narsil, I added the support of the LED, just ON or OFF. It's used as a locator light when the light is OFF (OFF by e-switch, not power), and will also blink for LVP, and blinks when blinking of the main LED is done for various reasons.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3
Sharpie wrote:
ToyKeeper wrote:
I’ve already done experiments on FET-driven moon modes with extra-fine pulse time adjustment. It didn’t work very well, and varied quite a bit with cell voltage even after voltage-adjusting the pulse timings as much as the attiny allows.

I’m thinking beyond mark-space ratio PWM, with only 256 values.

E.g. Timer 1 sets frequency, timer 2 sets pulse width.


Yeah, I did that like a year and a half ago. It ramped between 16 kHz and 2 MHz depending on voltage. It was kind of neat, but it didn’t work anywhere near as well as a 7135 chip.

Tom E wrote:
I can’t make all that much sense from all those posts, sorry.

Agreed; it’s a bit hard to follow stream of consciousness text with one sentence per paragraph.

About the moon flash (the turbo-to-moon flash on clicky lights), it appears to be outside the attiny’s ability to control and can only be addressed in hardware. Even just changing to a different model of FET seems to help. Is that the one you were talking about, or is there another?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Sharpie wrote:
… not using a tailcap switch ? But an e-switch ? …
Because if so, I think that is a bit different …

“A bit different” is one way to describe it. The code is dramatically different depending on switch type.

There are currently 13 e-switch firmwares in the repository, including three I made. Tom E’s Narsil is the most full-featured one though.

The ringing at the end of a full-power pulse still applies to these, and some firmwares take steps to de-bounce the e-switch signal when the wires are extra-long or thin, but at the moment I can’t think of any other stability issues encountered during actual usage. I’ve left a variety of them running for months at a time with no issues, as have other people around here. Dale has some running at 10,000+ lumens. It’s kind of amazing that a 17mm driver can handle ~40 amps.

mattlward
mattlward's picture
Offline
Last seen: 1 day 3 hours ago
Joined: 06/19/2015 - 09:20
Posts: 2828
Location: Illinois, USA

I have been fighting with my first 25 driver and it all went to hell when battcheck25 did not work, now I have to removed the MCU and program it and put it back on just to run battcheck. Then do it all over to flash Bisto. I would love to see a built in programmable LVP. Maybe run a battery down to 2.9 volts, pop it into the light and enter config mode and tell it that it is now the shutdown point… Anyone considered this option?

EDC rotation:
FW1A, LH351D 4000k (second favorite)
FW3A, LH351D 3500k
FW3A, SST20 FD2 4000k
FW3A, Nichia 4000k sw40 r9080 (favorite light!)
FW3A, Cree XP-L Hi 5A3
Emisar D4V2, SST20 4000k
S2+, XM-L2 T6 4C

Mike C
Mike C's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Tom E wrote:
Not sure if no one else is working with these MCU’s or just being silent on it.

I’ve been doing a lot of work on the 85s but I can’t help you here because I do not PWM the FET. My 17mm FET driver has, besides the FET, 8 x AMC 7135s which I find plenty enough for all modes under “full blast”.
Tom E
Tom E's picture
Offline
Last seen: 7 hours 34 min ago
Joined: 08/19/2012 - 08:23
Posts: 12880
Location: LI NY

Mike – ahh, always forget bout you… Of course! Are your designs (boards and firmware) open/available? The board design may be so different, there’s not much in common. I don’t use PWM’s on the FET much – for typical 5 modes, only mode #4 uses PWM on the FET. I can cause hickups going from full FET mode, to OFF, to moon mode on the 7135 for example, so PWM’s on the FET is never used in this sequence.
The bank of 7135’s typically means the 2nd highest mode is off the 7135’s, while ours is PWM on the FET — that’s about the only difference, but still, a big difference. Going to 7 modes or more would be more PWM FET modes.

DavidEF
DavidEF's picture
Offline
Last seen: 2 days 20 hours ago
Joined: 06/05/2014 - 06:00
Posts: 7699
Location: Salisbury, North Carolina, USA

Sharpie wrote:
The FET could do everything required, more efficiently, if operated in linear mode, all the way to saturation, not PWMed.

I suspect the additional circuitry required would take up comparable board area to x8 7135s.

But that would be a different design.


I’d like to see this design from you. We need all the help we can get. Wink

The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy

fixed it
Offline
Last seen: 4 months 3 weeks ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Sharpie wrote:
The FET could do everything required, more efficiently, if operated in linear mode, all the way to saturation, not PWMed.
Wouldn’t it overheat at some point? I think that somewhere in the middle range it would need to get rid of close to 1W. Hardware is not my field but I expect that would require some reasonably good heatsink or a different package (or both). And if I’m not completely lost, this could be avoided by switching to PWM above perhaps 300mA or so.
Tom E
Tom E's picture
Offline
Last seen: 7 hours 34 min ago
Joined: 08/19/2012 - 08:23
Posts: 12880
Location: LI NY

Sharpie wrote:
Have you considered resetting the MCU before each mode change ?

No, not all - negates advantages e-switch firmware has, plus I've seen these glitch's happening with clicky lights/firmware as well. The BLF X5/X6 v2 problems were apparently solved by changing the cap from 10 uF to 12 uF. On clicky switch lights w/25 I've built, I usually go with 2 stacked 10 uF caps to fix the issues.

texaspyro
Offline
Last seen: 11 months 1 day ago
Joined: 04/29/2011 - 12:43
Posts: 4593

You have to be very careful operating FETs in their linear region. Most FETs are only specified for pulse/saturated operation. When running them in the “linear” region you can run into all sorts of issues. Hot spots can develop and kill the device, etc. Check the safe-operating-area specs/curves carefully… I know a lot of people were unpleasantly surprised when they tried to use the wrong FETs in adjustable power supply load testers.

fixed it
Offline
Last seen: 4 months 3 weeks ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Sharpie wrote:
So e.g. each 7135 at 350 mA has to dissipate 0.6 Watts.

So eight of them add up to 4.75 Watts.

This should not be problem to dissipate with the sort of FET selected, and a little attention to PCB design.

I’ll have to take your word for it. My worry was that you’ll take the power being dissipated by eight 7135 and now have it all in a single FET. It seems like a lot to me but I’ll admit it’s just a very rough guess, I haven’t looked up any specs. I might try it and come back with pictures if I burn something Smile

Sharpie wrote:
PWMing a FET full-on, as currently done, is merely transferring the power dissipation into the LED (and a bit into the cell), running it above it’s peak efficiency point, hence perhaps the popularity of e.g. copper stars etc. It is a tiny little thing, compared with a power transistor.
Granted, but it’s convenient because you already have a heat sink for the LED anyway. Also, it’s not obvious to me that running the LED at very high current is much worse for efficiency than wasting power in the FET or 7135s. This probably depends a lot on the LED involved.

Anyway, how would you go about it? All I can think of for good control over the whole range is to build a crude 1bit DAC for the FET gate. I think it could be really poor if feedback from one of the ADCs is used to hold the output steady instead of having to rely on precalibration.

texaspyro
Offline
Last seen: 11 months 1 day ago
Joined: 04/29/2011 - 12:43
Posts: 4593
Sharpie wrote:
In any case, this is moot.

Hardly… the FETs designed 25+ years ago tend to be quite different from more modern FETs (e.g. smaller process geometry, cell sizes) You have to look closely at the spec sheets to see how they will work in DC/linear operation. Assuming your shiny new FET will work the same as your 25 year old beastie is not a good idea. Now a flashlight running at 5 amps may not be an issue, but if you are using a tiny SOT23 fet, it may be. The only way to be sure is to check the datasheets… and often the relevant info can is very well hidden / non-obvious.

I have designed power controllers for up to 7.5 megawatts. My CD spot welder does 500+ kW pulses. At those power levels the devil is in the details. Magic smoke / silicon plasma wants nothing more than to be free.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Sharpie wrote:
The FET could do everything required, more efficiently, if operated in linear mode, all the way to saturation, not PWMed.

Led4power made some drivers which work this way. He has a whole family of drivers available for purchase.

Efficiency was better and there was no pulsing in the output, but the driver itself has overheating issues in the medium-to-high modes. It’s fine on low and on maximum output, but in-between it tends to cook itself. Moon (~4 lumens, not 0.2) operates separately due to problems doing moon from the FET. I recall some issues with “low” mode too, like it was a little unstable and it’s ~60 lumens instead of a single digit and it can’t really go any lower (probably for the same reason the moon mode operates separately).

Unfortunately, led4power hasn’t released any designs or code and the MCU isn’t a type which can be reflashed on-board. It’s a nice product, unsurpassed in several ways, but it hasn’t been very widely used.

Based on led4power’s drivers and the test results for it, I think a linear FET would be a nice way to increase efficiency on modes between ~80 lumens and maximum output, if the driver has good heat sinking. A separate power channel would still probably be required for modes between 0.1 lm and 80 lm though.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Sharpie wrote:
Time for code convergence ?

Some common code has already been exported into shared headers to avoid duplication. Other parts tend to be different per project, and very different for different types of switches. There is still more de-duplication to be done, but this is very limited due to the “tiny” nature of the attiny.
Mike C
Mike C's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Tom E wrote:
Are your designs (boards and firmware) open/available?

Nothing available yet. I know a lot of people advocate releasing often but I have had enough talks with people that prefer to wait for a version that is tried, tested and approved. I have a whole pile of old obsolete versions of driver boards that are of no use to anyone. I would hate to have had people waste time and money on those versions, only to hear me say that I don’t support them anymore because I have a new design. Also, I have the FET on the dreaded reset pin (all other pins occupied). It took me a lot of swearing and hair pulling before I managed to build a device for high voltage fuse resetting and get it working. Updating the firmware is by no means an easy task if you do not have a working HVSP fuse resetter, because then you have to make/get one and figure all that crap out.

Tom E wrote:
The board design may be so different, there’s not much in common.

There are two major differences. First, I have E-switch, voltage monitoring and off time cap all on the same pin. This requires a whole different approach to the firmware. For example I have to have delays on the voltage monitoring because of the off time cap charging and E-switch presses. I have to run the watchdog interrupt at full speed in order to detect E-switch presses instantly, and disable all voltage monitoring until a moment after releasing it. The voltage divider resistors are much higher than “regular” ones as R2 on the divider becomes a bleed/pull-down resistor for the off time cap.
The second difference is that I run any number between one and eight AMC7135s fully on (constant current) and use a single PWM dedicated AMC7135 for all brightness levels between. So all of my mode values consist of two bytes, a PWM value for the PWM decicated AMC7135, and then the amount of AMC7135s I want fully on. It’s a constant current/PWM hybrid.
Tom E wrote:
I can cause hickups going from full FET mode, to OFF, to moon mode on the 7135 for example, so PWM’s on the FET is never used in this sequence.

I have had no such issues. I don’t have any gate resistors or capacitors on the FET, and can happily switch between moonlight low PWM values on the PWM AMC7135 and full blast on the FET without hickups, using both off time mode switching and E-switch mode switching. I’ve been following these discussions with interest (where to put the input cap and so on) but as I have not had any of these issues myself I have nothing to contribute towards solving them. The FET I use is the NXP PSMN3R0-30YLD if that matters.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Mike C wrote:
I have nothing to contribute

Except awesomeness, and possibly some of the answers. Smile

Seeing the differences in board design might make it clear why one design has issues while another does not.

Plus, the things you built by yourself are some of the most fascinating and exciting projects on BLF. You may think of your old boards as obsolete junk, but the ideas within, and the details, could potentially be the basis or inspiration for all sorts of other projects. It’s not just the final revision which matters; the things you learned during development would also be beneficial for other people to know. And you’ve downplayed the value of your code by saying it requires different hardware and different approaches, but variety is exactly what BLF needs to grow and move forward.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Sharpie wrote:
I was thinking of a linear driver having a controllable range of, say 0.1 to 5 or 10 Amps, but also gate-able, so for say 100 mA downwards you can use the same sort of PWM scheme as with the current 7135.

It’s a good idea. However the FETs don’t perform well at moon to low levels in either PWM or linear modes, so a separate power channel is still likely required to get those levels to run well.

Sharpie wrote:
Thermal design would need careful consideration, perhaps firmware could have a learning algorithm using the internal sensor to map the particular application, or PID, or just simple feedback, and control the operating point safely.

I’d have to check again, but I think led4power’s drivers use a separate thermal sensor to regulate themselves since heat is so much more important on a linear FET design. As for learning algorithms or PID, I looked into PID while doing the bistro thermal code. A fairly simple PID algorithm doesn’t fit onto the MCU, much less a nice-quality PID algorithm. DrJones recently tried to do it too, reduced the size until it would fit, and found that it behaved very badly. He ended up taking the same approach I used, which is basically just an incremental correction factor with a really strong lowpass filter to avoid bouncing.

So, it can work, and it improves efficiency quite a bit on medium modes. However, it also adds some significant complications. Eventually someone will probably decide the complexity is worth it though, and dive in. We already know it works; it just needs someone to do it.

There are other interesting ideas to explore too, like boost and/or buck drivers. It’s possible those might be developed first, since at least one is already in progress. There’s also the many-7135s approach already in use, which provides some of the linear FET’s benefits but without the heat issues. All sorts of interesting stuff happening lately.

cbrake10
Offline
Last seen: 1 year 10 months ago
Joined: 11/25/2014 - 17:04
Posts: 492
Location: Alabama

comment for subscription purposes. Enjoying the conversation and brainstorming going on in here.

-Clark

texaspyro
Offline
Last seen: 11 months 1 day ago
Joined: 04/29/2011 - 12:43
Posts: 4593
ToyKeeper wrote:
As for learning algorithms or PID, I looked into PID while doing the bistro thermal code. A fairly simple PID algorithm doesn’t fit onto the MCU, much less a nice-quality PID algorithm. .

I’ve seen PIDs implemented in a TINY13’s…

Check out Dale Wheat’s LED dimmer code. He uses a PID (actually a PD) for doing smooth fades in his LED dimmer. Link to the source code is in the description. I’ve used his dimmer for lots of stuff. Modified the code and for a TINY85 to control a 5000 watt composite curing oven using a PID. I modified his circuit board with a better FET/heat sink/regulator. Also modified one to do PID based control of a fan prevision temperature control of ovenized crystal oscillators. By changing the regulator to an LM2936 and a couple of tweaks to the firmware the off-state current draw is under 10 microamps.

http://www.dalewheat.com/news/12v-dimmer-kit-v2-now-available/

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3
texaspyro wrote:
ToyKeeper wrote:
As for learning algorithms or PID, I looked into PID while doing the bistro thermal code. A fairly simple PID algorithm doesn’t fit onto the MCU, much less a nice-quality PID algorithm. .

I’ve seen PIDs implemented in a TINY13’s…

Check out Dale Wheat’s LED dimmer code. He uses a PID (actually a PD) for doing smooth fades in his LED dimmer. Link to the source code is in the description. I’ve used his dimmer for lots of stuff. Modified the code and for a TINY85 to control a 5000 watt composite curing oven using a PID. I modified his circuit board with a better FET/heat sink/regulator. Also modified one to do PID based control of a fan prevision temperature control of ovenized crystal oscillators. By changing the regulator to an LM2936 and a couple of tweaks to the firmware the off-state current draw is under 10 microamps.

http://www.dalewheat.com/news/12v-dimmer-kit-v2-now-available/


Cool. I’ll have to look at that in detail next time I’m working on the code.

I didn’t go into much depth when I checked out PID… just deep enough to see that the reference code was orders of magnitude bigger than I had room for, so I went with an extremely simple approach instead.

Edit: I was too curious, so I looked at the code. He’s doing pretty much the same algorithm I did for the “soft start” thing in bistro, which makes smooth transitions between different output levels. That’s not really sufficient to make thermal regulation behave, but it works well for traversing arbitrary adjustment distances in constant time with a smooth-looking ramp.

Edit 2: The “soft start” and dimmer adjustment algorithm is:

  1. Are we there yet? If so, stop. Otherwise…
  2. Go about a quarter(ish) of the remaining distance, minimum 1 unit.
  3. Go back to step 1.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Looking around a little more, I think I might have found a potentially-useful approach. Thermal regulation is rather unpleasantly like trying to steer a really heavy ship. The high degree of inertia makes it hard not to over-steer. Bistro’s solution is to steer very very slowly.

This looks promising:
https://en.wikipedia.org/wiki/Kalman_filter
http://greg.czerniak.info/guides/kalman1/

wight
Offline
Last seen: 2 months 2 weeks ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

I know it doesn’t do much good either with or without source, but INFERION (whose ATtiny85 firmware is written in assembler) claims to have implemented PID in the Indigo 5.x firmware. http://forum.fonarevka.ru/showthread.php?t=20409

Hopefully I won’t put my foot in my mouth, but it seems to me that PID shouldn’t require a lot of space. Here is an Atmel document on the subject (with code provided in a zip), as linked from the ATtiny85 docs page. Atmel claims that their PID function compiles to 534 bytes.

http://www.atmel.com/Images/doc2558.pdf
http://www.atmel.com/images/AVR221.zip

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

texaspyro
Offline
Last seen: 11 months 1 day ago
Joined: 04/29/2011 - 12:43
Posts: 4593
ToyKeeper wrote:
He’s doing pretty much the same algorithm I did for the “soft start” thing in bistro, which makes smooth transitions between different output levels. That’s not really sufficient to make thermal regulation behave.

Well, I do have some true PID code for my reflow oven. It runs on a MEGA2561 and uses floating point code. It is pretty much the same PID/fan control code I used my GPSDO (GPS Disciplined Oscillator) temperature stabilizer. I have seen it control temperature with a 24 hour RMS error of 1 microdegree, with peak errors of less than 5 millidegrees… Might be a bit much for a flashlight.

A simple temperature control PID is not much more complex than Dale’s code. Implementing the I (intergral) term can be a bit tricky… you have to handle “integral windup” where the integral (long term compensation) value keeps accumulating in the same direction and “runs away”

Tuning a PIDs control parameters is always a pain. Most simple method is to start with P/I/D values at 0. Increase the P value until the output starts oscillating and then increase the D value to stop the oscillation. Then adjust the I value to minimize long term drift. My oven / GPSDO code has some auto-tuning code to that does a lot of the work.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 8 hours 3 min ago
Joined: 01/12/2013 - 14:40
Posts: 10298
Location: (469219) 2016 HO3

Hmm, 534 bytes. Not bad at all. Certainly better than the ~5k bytes one I looked at. Smile

I’ve got a copy of the Indigo 5.2 firmware, but it’s a little … opaque. Assembly code with sparse Russian comments. I think Atmel’s version will be a more useful reference, and another Kalman link I found which deals specifically with compensating for situations where one or more values lag behind.

It wouldn’t be a big deal to devote an extra ~500 bytes to PID on a tiny45/85. I wonder how much the response curve can be improved with PID and/or Kalman instead of the “steer really slowly” approach, and if it can anticipate over-heating conditions and start to correct for it in advance. I also wonder if it’ll need to use the full 10 bits of precision instead of 8, since temperature measurements are rather coarse so far.

Too many questions/unknowns. I need to just do it and find out. … … after I get more parts and some time.

texaspyro
Offline
Last seen: 11 months 1 day ago
Joined: 04/29/2011 - 12:43
Posts: 4593

Belive me, you don’t want to go down the Kalman rabbit hole. Insanity awaits those foolish enough to enter that dark realm. I’ve been there and barely escaped with my life. Bits of brain still ooze out of my nose whenever I think about it.

Tom E
Tom E's picture
Offline
Last seen: 7 hours 34 min ago
Joined: 08/19/2012 - 08:23
Posts: 12880
Location: LI NY

ToyKeeper wrote:
Mike C wrote:
I have nothing to contribute
Except awesomeness, and possibly some of the answers. Smile  ...

+++1 here! Sorry been behind here but Mike - you have some real original work goin on and always enjoy following you.

Mike C
Mike C's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Been away climbing for a while, sorry for late replies.

Sharpie wrote:
Mike C wrote:
There are two major differences. First, I have E-switch, voltage monitoring and off time cap all on the same pin. This requires a whole different approach to the firmware. …… The voltage divider resistors are much higher than “regular” ones as R2 on the divider becomes a bleed/pull-down resistor for the off time cap.

I’d mused about combining OTC and voltage monitor too. Better defined. But you are doing it for real Smile


It works very well, I’ve been using it in several lights. It’s all just voltage measuring, and deciding what to do with the measured values.
Sharpie wrote:
Mike C wrote:
The second difference is that I run any number between one and eight AMC7135s fully on (constant current) and use a single PWM dedicated AMC7135 for all brightness levels between. So all of my mode values consist of two bytes, a PWM value for the PWM decicated AMC7135, and then the amount of AMC7135s I want fully on. It’s a constant current/PWM hybrid.

External decoding or individual pins to select group ?


Individual pins with groups. AMC7135 groups are PWM, 1, 2 and 4. Another pin for the voltage input and the last pin I’ve put on either a FET or a larger group of AMC7135s. I’ve looked at using external components to avoid mucking around with the reset pin but on I’m all out of space for the solutions I could find. I’m not that knowledgeable with these things though, any good suggestions I could look at?

Tom E wrote:

ToyKeeper wrote:
Mike C wrote:
I have nothing to contribute
Except awesomeness, and possibly some of the answers. Smile  …

+++1 here! Sorry been behind here but Mike - you have some real original work goin on and always enjoy following you.


Thanks! In regards to board design I wouldn’t know why I’m not having the same issues. No funky stuff with the layout. And as far as I have been able to tell, these issues with the FET / moonlight you have been having have not been able to be resolved by firmware coding. What is the FET you are using? If it has the same footprint I could always build a test driver with one of them (if it’s not the one I use).
Tom E
Tom E's picture
Offline
Last seen: 7 hours 34 min ago
Joined: 08/19/2012 - 08:23
Posts: 12880
Location: LI NY

I’ve been work’n on a few older mods with the wight FET+1 driver v009 and a Attiny85 and noticed not all had issues. Couple didn’t need anything extra, while others needed the FET gate resistor and the 0.1 uF cap across the +/- input to the MCU. I use about always the SIR800DP FET, where it’s been reported by others to be prone to the flash problem. Read somewhere that someone simply replaced it with a different P/N FET and the flash went away – don’t recall where or which FET it was though.
I tried pretty much everything in firmware to fix it, TK has also, and we couldn’t fix it.

Mike C
Mike C's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

ToyKeeper wrote:
Hmm, 534 bytes. Not bad at all. Certainly better than the ~5k bytes one I looked at. Smile

I’ve got a copy of the Indigo 5.2 firmware, but it’s a little … opaque. Assembly code with sparse Russian comments. I think Atmel’s version will be a more useful reference, and another Kalman link I found which deals specifically with compensating for situations where one or more values lag behind.

It wouldn’t be a big deal to devote an extra ~500 bytes to PID on a tiny45/85. I wonder how much the response curve can be improved with PID and/or Kalman instead of the “steer really slowly” approach, and if it can anticipate over-heating conditions and start to correct for it in advance. I also wonder if it’ll need to use the full 10 bits of precision instead of 8, since temperature measurements are rather coarse so far.

Too many questions/unknowns. I need to just do it and find out. … … after I get more parts and some time.


I do have interest in temperature control. Currently I have temperature calibration and step down, and have a few first tests of temperature controlling. What advantages would a PID controller have? My testing consists of running a “learning” routine where the light heats up, shuts off and does a few things, all timing how the heat behaves in response to turning off and so on, and then storing the values into the EEPROM. My main issue is that with some hosts the difference between doing this routine while holding the light as a lot different than doing it while it is laying on the table. Care to write a few lines on how a PID controller could be used to make all this a little easier?
Mike C
Mike C's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Tom E wrote:
I use about always the SIR800DP FET, where it’s been reported by others to be prone to the flash problem.

Ahh, OK. That one was harder to get in Europe, I think that’s why I went with the NXP PSMN3R0-30YLD. I’ve not used another one. If I remember correctly the SIR800DP has a diffferent footprint so I wouldn’t be able to test without changing the board.

Pages