Success! Thermally regulated linear driver

51 posts / 0 new
Last post

Pages

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL
Success! Thermally regulated linear driver

I know, it’s not exactly rocket science. But it is a nice blending of the existing driver options.

I modified a nanjg105c, swapping the attiny13a for a attiny25. To make sure I could put the thermal regulation to the test, I also stacked 4 extra 7135’s for a total of 12.

On the firmware side, I used a modified Bistro/Biscotti, set up for single channel, non-OTC, with some other tweaks.

I installed the driver in a Convoy S6 with a Nichia 219C D320. In playing around with it for an hour or so this evening, everything seemed to be running properly.

I’m not sure how often I’d go through the effort to swap MCU’s, but this seems like a great step up from messing with turbo timers. And especially in tube lights where I don’t really feel the need for a FET+1, but still want some horsepower available.

CRX
CRX's picture
Online
Last seen: 4 min 10 sec ago
Joined: 04/02/2013 - 15:27
Posts: 2095
Location: Scotland

Cool, i never did manage to ever stack 7135 chips Thumbs Up

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

Thanks CRX. My first time doing it actually. I loosely followed Richard’s method, bending the legs down while clamped in some pliers for support. For soldering, I just dabbed on a bit of solder paste between each stack and touched it with the iron. Went much better than I expected.

chouster
Offline
Last seen: 2 days 2 hours ago
Joined: 02/20/2014 - 15:05
Posts: 680
Location: germany

Nice job, gchart.

I remember doing something similar a couple of months back. Single channel bistro with a nanjg 105C, but with additional OTC. I think it started acting weird when I set the modes to start on high in combination with soft start. Does that work with your set-up? Since you went without an OTC I’d be interested which firmware you tweaked?

Nicolicous
Nicolicous's picture
Offline
Last seen: 3 hours 33 min ago
Joined: 04/16/2016 - 08:28
Posts: 740
Location: Australia

stacking these chips are hard.

i have done it before with some success and some fail.

so well done gchart

Can you lend me some money to buy new flashlights?

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

In essence, it’s Bistro, using the noinit trick to replace the OTC at the expense of being able to detect medium-presses (for mode reversal). I’ve got a version of it available in TK’s repo, called Babka. It hasn’t been updated yet with my newest code, adding back in thermal regulation. I prefer more streamlined-looking code, so I tend to delete stuff as opposed to using a lot of #ifdef.

I tried modes that started on high and they worked fine. I didn’t try soft start though. I can share code tomorrow if you’re interested (when I’m back in front of a computer).

chouster
Offline
Last seen: 2 days 2 hours ago
Joined: 02/20/2014 - 15:05
Posts: 680
Location: germany

Thanks gchart, sounds good!

I know you had a firmware called Babka, but I haven’t checked it out yet, but that one was intended for the attiny13a, right?

Would be very nice of you, if you’d share the code. I think I could learn a bit by taking some closer looks at it.

I have to say, I quite like the medium press option. I usually go with BLF-A6 or Bistro. BLF-A6 mainly, because I prefer the turbo timer. Now with the triple channel drivers there’s only Bistro AFAIK. Would be great to have a Bistro version with turbo timer, but I think it’s over my head to realize it. Maybe I’ll try someday.

MRsDNF
MRsDNF's picture
Offline
Last seen: 11 hours 30 min ago
Joined: 12/22/2011 - 21:18
Posts: 11556
Location: A light beam away from the missus in the land of Aus.

Nice work gc. Thumbs Up

My current and or voltage measurements are only relevent to anything that I measure.

Budget light hobby proudly sponsored by my Mastercard and unknowingly paid for by a hard working wife. 

djozz said "it came with chinese lettering that is chinese to me".

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

djozz
djozz's picture
Offline
Last seen: 26 min 52 sec ago
Joined: 09/07/2012 - 17:04
Posts: 11026
Location: Amsterdam

Very nice, I never got round messing with firmware but it must be fun to have all those options!

Lexel
Lexel's picture
Offline
Last seen: 1 hour 27 min ago
Joined: 11/01/2016 - 08:00
Posts: 2895
Location: Germany

I have a Nanjg 105c from my B158 light

I want to add an OTC and run Biscotti on it

which modifications I have to do?

just add OTC like in Jonnys Star firmware to pin2 and ground?

[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, S42, K01 / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp

[Mods] Skilhunt H03 short / Klarus XT12GTS / colorful anodisation

[Sale] TA drivers Narsil or Bistro, XHP35 E2-3C

chouster
Offline
Last seen: 2 days 2 hours ago
Joined: 02/20/2014 - 15:05
Posts: 680
Location: germany

Biscotti works without OTC.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

Yup, it uses the “noinit” RAM decay trick to determine short-press (mode switching) vs long-press (on/off). While Biscotti wasn’t designed to use an OTC, the code still has the controls for it. If you really want an OTC for medium-press, then you could try (1) installing the OTC, (2) turn on OFFTIM3 in Biscotti, (3) trim out other stuff to make room for the OTC code bits, (4) test the crud out of it Smile

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

Nice.  My problem with noinit as it is in bistro now, is that it assumes any valid value is.. valid.  I tested a single randomly chosen slot in ram to see what resets to after decay, and it always reset to the same value, I think it was 72, or whatever, but not 0 or 255.  I assume that's just how those particular 8 bits like to settle and I suspect a different 8 bits would settle to a different value.  So on bistro anything less than I think 15 is considered valid (valid number of fast presses to get into menu), but nothing says that the settling value won't be 9 on a particular byte on a particular chip.  It's not even that unlikely,  15/255 chance.  There's a note in the bistro code about it being questionably reliable and I guess this is why.

 

The solution... is to use 4 bytes.  There's a 1 in  2^24 (almost 17 million) chance of all 4 bytes being equal assuming they're independently random (needs a bit more testing, but kind of seems that way).  That doesn't mean 2^24 times you turn it off, more likely one out of every 2^24 lights. So you check that all four bytes are equal, then you say it has not decayed and check the value.  If they're not all equal, it has decayed and it's a long press. It's a little more code space, but not so much.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

I’ve been bitten by to decay lottery on a driver or two. I’ve attempted to address it in a different manner using two separate one-byte variables: one for counting fast presses, and another one for decay detection. I figure that getting a byte that always decays to 0 is pretty unlikely. And I only check the fast presses variable if the decay detection variable is still 0.

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

well you've reduced the problem to one in 255, but only sort of.  What are the chances your test byte has a bit decay first?  What are the chances the data byte does?  50/50.   That may be more try by try related than the other random draw (hard to say).  These bytes don't decay fast.  I don't think the odds of this biting are so low.  Might as well make it 4 bytes and kill the problem.

 

As for single channel versions of things, I've tried to make HD very easily configurable for channel setup.  It should be a few #defines to uncomment to drop into straight into this (as soon as I go find out the nanjg layout I can make a shortcut macro for it in about a minute; there's probably already one there, but it might not be right).  However, I have not fixed the noinit issue.  It is on the todo list, but what I have done is made plenty of extra space available for the few extra lines of code it will need.

 

I actually don't mind at all if HD gets accepted into "mainline".   A  lot of the point of it was to re-merge some of the different variants but I didn't want to be presumptive about it either so I renamed it.  If we have one version that can be used anywhere with just a #define layout nanjg  (this was toykeeper's concept, it just got fractured over time)  then it's easier to keep all the upgrades together.  If features can be removed or included with defines then nobody is forced to use a particular upgrade either... for the most part.  I've also tried to tidy up some of that.

 

Anyway, I should follow your inspiration and get this all included.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

I might try kicking it up to more bytes, it certainly can’t hurt if you’ve got the space. But an attiny13a can run short of that quickly.

1:255 odds would be correct if SRAM decayed evenly. And I have nothing saying it doesn’t. But in testing done by other members (here), bits appear to favor decaying to 1 around 70% of the time. With even a single byte, that would change the odds to be 1:15242 that a byte would favor decaying to 0.

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

Attiny13 hunh..  I thought you said you changed the chip to a 25.  Anyway, it's not 1 in 255 even with even odds.  You're missing my point. You're working with two bytes.  One single bit will be the first to go.  How long will it be in a state with only one bit wrong?  How often will you click on during that time?  Probably sometimes.  You're relying on the fact that the first bit to go bad will be in the check byte and not the data byte.  But there's 50% odds it will be the other way around.  So that's 50% odds that at least sometimes when you click, you'll think the data is fine, but it isn't.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

Well, yes… This thread is about using an attiny25 with noinit. But I’d wager that the other 99.999% of drivers currently in production that are using the noinit trick have an attiny13a on board.

And I think I get what you’re saying, it’s just a different approach than what I mentioned. Different isn’t always wrong. Your proposed method involves copying the fast presses counter to not one, but four separate bytes. First you check to make sure they’re all the same, then you can safely assume the data they contain can be used for a counter. Is that pretty close to what you’re describing?

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

Ok, I get your point about the 13.  Yeah, I guess not many people are replacing 13's with 25's on nanjg. Anyway, yes that's it.   And I agree it will take some significant bytes of code in the context of an attiny13.  Even for the 25 version it was significant, but we've freed spaced and just not enabling one of the other methods (OTC or OTSM) now makes way more than enough space free to implement it without losing anything.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

It’s definitely a good sounding method. Do you recall about how much space it takes up? For space-constrained applications, even doing that method with two bytes sounds far better than what Biscotti has.

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

I haven't actually implemented it yet.  Just on my todo list.

I did work out that the check can look like if (a==b&c&d)

... but that's about as far as I got and actually while that looks tidy it probably doesn't optimize to much if any shorter than more verbose statements.

One trick I used to save some space is to declare a few key variables as global register variables.  This avoids all the in LDS STS instructions for those data.  If you do it too much (more than a few probably) it can result in more juggling instead of less though.  I believe these are always noinit but I have no idea if they'd persist at all like ram variables.

 

As for two bytes, yeah, that's 1 in 2^8 so 255 for equal weighted bits.  I started thinking this through with your idea first actually, then thought this other two byte trick, then figured, well, that makes it better but it will still be an actual problem so it needs 3 and might as well make it 4 (three would still hit someone someday).  But three could be good for attiny13 if it will fit.

 

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

ah.. just realized that way of doing the check isn't as clever as it is cute.  It's possible for that to pass with some not so hard to produce combinations of non-equal values, so it significantly weakens the check. Just have to do out long probably : if (a==b && b==c && c==d) Your claim of a weighted coin probably also weakens it. 

loneoceans
loneoceans's picture
Offline
Last seen: 1 month 3 days ago
Joined: 01/08/2017 - 00:18
Posts: 56

I'm not quite sure what the main problem is, but if you're using an Attiny25, why not just use the EEPROM? This in conjunction with the RAM trick or an OTC would be very useful Smile

Website: www.loneoceans.com/labs/

GXB20: Single-cell Programmable XHP50/144M 20mm Boost Driver (version 2)

GXB17: Single-cell Programmable XHP50/144M 17mm Boost Driver (version 1)

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

Yes, eeprom can probably work too, but you still need a few bytes of noinit comparisson to reliably see the long press.  Once you're setting a few bytes to the same value, might as well set them to the value that matters.  If you need multiple sets of all bytes, like a clear and an increment, then maybe that starts to get a little more costly in terms of instructions, depending where it's done and if the variables are still in regeisters from the set when the clear is done(Ok, clear doesn't need the value but anyway some details may matter...) Of course a problem with any multi-byte thing is there can be interruption in the middle of it, but the odds on that are also pretty slim, and can be made slimmer with assembly programming, if one really wants. 

 

Also eeprom is very slow (like multiple ms, which probably implies worse interruption concerns), and it has limited writes.  Bistro adds wear leveling to anything written to on every single click (presently just the mode inex) to avoid writing to many times to a single byte.  Maybe that's overkill, maybe not (100,000 writes max by spec), but you'd need more code if you want to do this to more variables as the wear leveling code isn't very general. 

 

It's definitely option, and probably more than one way to skin this (including using attiny25's and OTSM) but each may have its own issues as gchart notes.

 

vwpieces
vwpieces's picture
Online
Last seen: 1 min 41 sec ago
Joined: 07/17/2016 - 19:49
Posts: 1501
Location: PA, USA

Very cool GC.
I can do the solder work but exactly as loneoceans posted above I need a translator most of the time.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

BTW, I’ve got the multi-byte noinit stuff working just fine in the manner that Flintrock described. For proof of concept, I only used two bytes, but adding an extra one or two wouldn’t be a problem at all.

I need to remember to check and see how much extra space that takes up. I’ll report back later.

And yes, there’s all sorts of ways to address this. But I’d like to see it work on the typical nanjg drivers that are so prevalent… no OTC mods or anything necessary. Especially with the several reports of Biscotti acting funny due to the current noinit implementation, this should solve that.

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

But I got my 47uF tantalum caps and low leakage diodes now and will put together an OTSM  build with bistro, of course not nanjg or attiny13.

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

gchart wrote:
BTW, I've got the multi-byte noinit stuff working just fine in the manner that Flintrock described. For proof of concept, I only used two bytes, but adding an extra one or two wouldn't be a problem at all. I need to remember to check and see how much extra space that takes up. I'll report back later. And yes, there's all sorts of ways to address this. But I'd like to see it work on the typical nanjg drivers that are so prevalent... no OTC mods or anything necessary. Especially with the several reports of Biscotti acting funny due to the current noinit implementation, this should solve that.

 

Cool, yeah, the cap related comment was not aimed at this case.

gchart
gchart's picture
Offline
Last seen: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 726
Location: Central IL

Ok, I’ve done some initial fast_presses redundancy size testing. I can’t say these are the most optimized, but it should be pretty good. The code can be found here. I’m open to suggestions… looking at you, Flintrock Wink You’ll notice I was also testing out your variable-length mode groups, FR. With the current mode groups set up, it was adding about 14 bytes. But if I wanted groups longer than 4, I bet I’d see efficiency over making all the groups longer.

No redundancy: 984 bytes (control program)
Using 2 bytes: 1010 bytes (+26 bytes from control)
Using 3 bytes: 1028 bytes (+44 bytes from control)
Using 4 bytes: 1044 bytes (+60 bytes from control)

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

cool, 60 bytes sounds reasonable to me.  I was hoping for 50, but that was kind of just my guess.  Yes the variable mode-group length has a little buy-in price.  I haven't looked yet, will soon, so not sure how this translates to the tiny13 firmware, but the next biggest savings was probably all the array looping of  the menu variable operations, save, restore, and toggle.  The easiest savings were probably 

a) going through every function and trying with and without inline as the compiler doesn't optimize this as well as you expect even though it's only supposed to be a hint, and it's not always as obvious as it seems which way is best.

b) Changing some key variables to register variables. (and it matters which register is used).  

Flintrock
Offline
Last seen: 16 hours 5 min ago
Joined: 09/10/2016 - 20:29
Posts: 1518

really it would be great if we could figure out how to include the attiny13 software as a subset of bistro(already setup that way in principle, but in practice may be hard now to get a small enough configuration).  I might look at it.  Then these changes don't need to be maintained in two places. But it's good this way too.  It's not like it's a huge program.

Pages