Hhmm, everything I got and used has been posted here, maybe not all summed up in one spot though.
The fuses are documented in the beginning of the source code, and also in the t85fuses.bat file, also shared on the google doc link (fuse values tell you the start-up time being used).
I'm @work now, so don't have access to all my resources though, and don't have the time here either.
I use the SIR800DP FET exclusively now.
For a triple? Yes - in a SupFire M6 that I upgraded. Also had enough problems with a 219C and a high amp single LED, and solved the problems.
For your moon mode problem, are you using a 380 mAh 7135? If so, you need a higher value PWM. You need maybe a min value of 4-5 for 380's, for 350's, a PWM value of 3 always worked for me, using PHASE mode of course, not FAST.
I ensure now I use only 350 mAh 7135's in all FET+1 drivers.
Thank you very much Tom. Iāve been reading through all different types of threads concerning driving a FET properly, but having major problems understanding everything and not confusing stuff. Even the āoldā threads with great inputs from comfychair, PilotPTK, wight, JackCY and many more. What a pity most of these guys left and comfyās pics are all goneā¦ Iām glad that youāre still here!
ATM, I only have tiny25ās here, so my plan was to illuminate the bistro with a triple XP-L HI.
But with those issues reported especially with big amps, I thought I wouldnāt be able to get it running properly. Heck, Iāll just give it a try.
EDIT: yes, i was using 380mA AMCās. Thanks for the advice
Hhmm, Mitko led me to believe the FET+1 wight drivers were maybe not performing so well, so my last driver mod/build was using a 25 on a single FET driver, and found the "fix" was to stack a 2nd 10 uF cap on the regular C1 cap (doubled up).
Didn't use Bistro, but believe I tried it and had the same problem before the fix, so I think the double up cap would work fine for Bistro. I'm thinking now, Mitko might have run across an issue with using firmware not supporting FET+1's well, where you don't get the max amps you can from the FET, so think it was a firmware issue, not hardware issue of the driver.
So it's weird, but, I got two fixes I've been using - a 0.01 uF cap across the grnd and VCC pins of the MCU (on FET+1's using Narsil), or stacked C1 caps (straight FET driver running my own firmware for a power switch light) or the equivalent with a 22 uF cap instead of the 10 uF used for C1.
Also the 12K resistor across the FET gate worked great to 100% eliminate the flicker going from hi to moon on a power switch setup using a Tiny25 with FET only driver.
Thanks again for taking your time and sharing very useful information Tom.
I played with my driver today, swapped the 380mA AMC for a 350mA one, still no moon. Had to adjust the values. I wonder why this driver doesnāt show any of the issues thatās been talked about. Maybe Iāll encounter some when I hook it up to a triple. Itās still driving a single XM-L2 now. I am also going to test a longer start up time fuse setting to see if thatāll make any difference.
I builded my first A85 driver today, tom`s design( Thanks for your effords mate) and initial tests shows its has great potential especialy in Y3 style/double flashlights, will update tomorroy with some questions cause my kids want a bed story
Started with
380mA AMC and PWM-value 3, no light.
350mA AMC, PWM-value 3, no light.
350mA AMC, PWM-value 4, one of the lowest lows Iāve seen. Very cool to look at, but for me maybe a bit too dimm in terms of useability.
350mA AMC, PWM-value 5, thatās what I went with for now.
I didnāt know that a X+1*AMC350mA-driver can give that low of a low mode!
I used TKās level_calc.py to calculate ramp levels. More re-flashing to come, want to play around with it some more, calibrate voltage and adjust OTC-values to my liking (faster).
I agree with bugsy36, your Narsil looks very impressive, indeed.
Hi guys, could someone please help me with troubleshooting?
Iām trying to get bistro running on PDās Double Down driver, but it wonāt flash.
ATtiny25 is mounted to the driver already, driver is installed in a light with long wires.
I get this
verification error, first mismatch at byte 0x0000
0xff! = 0x87
I donāt think the problem is in the connection, I can flash tiny25 airwired, but not mounted. Have my connections to the programming clip like in Hoopās tutorial.
Because of the long wires, I was able to desolder C1 and tried to flash again, same story.
Do I have other options before pulling off the tiny25 to flash it unmounted?
EDIT: Never mind. I donāt know how but I got it running. I have a new favorite light now:
EE X6 3x XP-L HI U6 5A, bistro on PD68DD with FET+2, itās amazing!
Ugh, >600 posts. It feels like being back in the booster seat. If Iāve ever gotten mad at a noobie for not reading the entire thread (I have!), I repent. I was trying to read front to back, but itās taking a long time. Maybe Iāll try back to front.
Iāll throw down a few things now anyway with only 20% of the thread under my belt so far. I apologize in advance.
First of all, looks like neat stuff. As you all know, any move to physically larger MCUs is a pain for the CAD folks - so I tend to resist that change. If it nets us nice thermal protection features though, Iāve got to be game! As usual Iād prefer to try cramming in the 20M1 package with ISP headers for programming.
On the failures to program - IIRC the OTC can be the culprit here. Again this is only if I recall correctly - but I think that leaving the programming clip hooked up can charge the OTC and prevent additional flashes from being successful. As I recall a trick is to get your hex all ready to flash, discharge the OTC if necessary (with tweezers) and then clip and flash fairly quickly.
Tom E - did you ever get a handle on the calibration points you wanted? 0c and 100c are easy to reliably achieve using ice-water and boiling-water so those are common at-home calibration points. Atmel bins some chips (not the ones we buy) for 105c and 125c, I think itās fair to say that all of them are going to be OK at 100c long enough for a one-time calibration routine. Just throw the light in a plastic bag and drop it in for a while, right?
I wonder how much better an LDO driver would fair with the stuff mentioned in post #601 by Tom E. I did publish an LDO driver a while ago - itās probably suitable for testing. A17DD-SO8+LDO
I got a bit behind here tooā¦ though not nearly as much as wight.
If I understand correctly, the driver reset problem was fixed by using a bigger capacitor. It was rebooting on the trailing edge of a FET full-output pulse. So, turning the FET from 100% to 0% caused a spike of some sort.
The brownout detection options donāt seem to make any difference in any cases Iāve tried. The 4ms or 64ms startup delay doesnāt seem to make any significant difference either.
Iām going to have to try some new tricks to get some bricked drivers flashedā¦ I hadnāt thought about manually draining the OTC before or during flashing, but maybe it would do the trick.
Also, the last version I have for Narsil was still called eswBrOutCfg. Can I simply rename it, or are there extra changes to pull in along with the name change?
First of all, looks like neat stuff. As you all know, any move to physically larger MCUs is a pain for the CAD folks ā so I tend to resist that change. If it nets us nice thermal protection features though, Iāve got to be game! As usual Iād prefer to try cramming in the 20M1 package with ISP headers for programming. . . .
Tom E ā did you ever get a handle on the calibration points you wanted? 0c and 100c are easy to reliably achieve using ice-water and boiling-water so those are common at-home calibration points. Atmel bins some chips (not the ones we buy) for 105c and 125c, I think itās fair to say that all of them are going to be OK at 100c long enough for a one-time calibration routine. Just throw the light in a plastic bag and drop it in for a while, right?
I wonder how much better an LDO driver would fair with the stuff mentioned in post #601 by Tom E. I did publish an LDO driver a while ago ā itās probably suitable for testing. A17DD-SO8+LDO
I've been pushing for keeping the SSU footprint on the boards and just bending the legs. It really makes it easier to position the programming clip and the hold is much better. Those that have tried it have reported positive experiences so far.
I don't think temperature read calibration is worth the effort. Each light is going to behave differently anyway due to many factors. User adjustable seems the best approach to dealing with all the variables.
I think you may be on to something with LDO, I've been putting my 25/45/85's in buck and LDO (at opposed to zener modded) DD drivers and haven't had any issues yet, but I'm also using an older version of Tom E's FW for the 25/45/85. Unfortunately, the LDO I use is for 2S and higher cell arrangements only.
EDIT: Another benefit of bending the legs (which is easy) and is that the MCU stands higher. It allows low profile components like resistors and small caps to be placed right up to the legs, if necessary. Resistors could even go under the MCU.
Oh boy, now I'm behind... Latest Narsil is on my google drive - posted share earlier?? It's all renamed though to Narsil - it uses your header files though.
This should get you all the files: https://drive.google.com - full set of Narsil files. I'm think'n I had updates of Dec 12th, very minor maybe, maybe no change at all... Don't have access now cause @work.
I never did anything bout temp cal. TK has a pretty good solution though in Bistro, and didn't really explore/work with it yet. I'd probably lean towards dropping her implementation in to my code base.
The bent pin thing works well for me so far as well, though not liking the narrow pin contact - seems vunerable for solder issues.
FWIW: After carefully calibrating a thermal ceiling on one driver, I tried the code on another driverā¦ and it started stepping down at room temperature. It seems there is significant variation between individual MCUs.
So, I built in a runtime config option for it instead. Turn the light on at the highest level, read and save the temperature once per second, and when the user decides itās too hot they can turn the light off. This becomes the new thermal ceiling.
The tricky part is getting heat to the MCU quickly enough for it to be a useful measurement. The MCU is usually surrounded by a buffer of air, so heat travels slowly. It would probably be a good idea to stuff some thermal-conductive foam between the MCU and the pill. This wasnāt an option for the X6/X5 though, so instead I gave it a really strong lowpass filter to keep the regulation from bouncing due to thermal lag. It works, but unfortunately makes the regulator pretty slow.
Itās debatable whether thermal regulation is even relevant for such a big copper pill though, so it also has an option to turn regulation off. The first two seconds of thermal calibration mode only have the light on a dim mode, and if the user clicks during that time it sets the ceiling to 255.
Iāve gone one step further. I made my own footprint for the 85 with bent legs, itās a little smaller than the original 13A footprint so it gives me even more space. Itās verified and working on several of my boards.
I do. I do a single point calibration at room temperature, simply because I like to know the temperature that the MCU is at. Once temp is calibrated I do the routine that Toykeeper uses to set the max allowed temperature. I donāt have to do a temperature calibration for that, but as I have temperature readout (in Celsius), it is worth it for me. Iāve seen up to 15 degrees Celsius differences between MCUs at the same room temperature.