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.
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.
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?
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).
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
