[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

Yeah, I know the RGBW firmware would NOT be Narsil or Bistro. I wouldn’t want a RGBW light to work like a white-only light. The “four channel” aspect of a Bistro or Narsil light is just a way to have more efficient mode levels. It’s the next step up from three channels, which is the next step up from two channels, which is a bit better than one channel. It’s almost like having a 8K television versus 4K versus 1080P versus 720P versus “standard DEF” in that it deals with “resolution”.

And it does open up the possibility of having multiple led outputs. Like an all red mode or an led on the side and front of head as I’ve seen in some mods out there. It opens up many more possibilities and is a step toward another possible color firmware.

Well yeah, that too. :stuck_out_tongue:

Yeah, they’re designed for only one actual LED, or maybe one plus an indicator somewhere. Adding more channels to a one-LED light has diminishing returns. Here’s a conceptual comparison of 1-channel, 2-channel, and 3-channel drivers:

As far as I can tell, the Tripledown or QuadrupleDown (lol) method is how Zebralight and some other premium brands do their drivers. On close inspection, their medium modes have fast oscillations between two stable output levels… just like what Bistro and Narsil do. Not all premium brands operate like the led4power linear drivers.

The really interesting parts of having more PWM channels is the ability to do more than one LED. Like, RGBW or white plus an indicator or two, or multiple color temperatures for adjustable CCT, or things like that. Or use extra pins for extra I/O, like another switch or an external temperature sensor or a backshine/feedback sensor. Of course, those aren’t going to happen in most cheap hosts, so I expect the 2-to-4-channel single-LED drivers will remain popular.

I have the house to myself for about 5 months and plan to make the most of it. After that, I don’t know what will happen.

Before you go, could you upload the saber driver to oshpark? :slight_smile:

I had some similar experiences while trying to make bistro fit onto an attiny13 for biscotti. I hope to merge together both of our space-saving ideas soon, to make all the projects as small as possible.

I must admit I haven’t really made time yet to read through it, after barely a week of catching up, and I don’t have hardware to test it on. But it sounds like you’ve been doing good things. :slight_smile:

Ideally, I’d rather curate people’s code instead of writing it. I never intended to write ALL TEH CODEZ, just to get it all together in one place and make it easier for people to collaborate. So, I’m really happy to see people making cool new stuff.

First folks should understand this is not a 4 channel firmware. It's actually many different firmwares programmable by the c-preprocessor options, and 4 channel is just one option. You can build it for only one channel or two or three, and you can select whichever of the 4 channels you want (although 1 and 2, on pins pb0 and pb1 are preferred slightly at least). 4-channel was really just a why not kind of thing after figuring out how it was possible. The Vcc-read and the eswitch ire probably the most immediately useful features on existing hardware and the OTSM will I hope be a great benefit in the very future possibly even on existing boards with some changes to the components. It also combines well with the other two features.

Color mixing was pretty much what I thought you were getting at David. But before someone can program it they'd need a vision of how it would be used. If you just want to set up some color for photography I guess it can require a little setup and several menus for each led to fine tune things. Using a standard UI I'd probably do color mixing at a medium brightness level in the hidden modes or just have a dedicated modegroup like that, just have as many preset mixes as you want. Then standard modes are just W or maybe equal RGBW, or anyway a fixed custom tint.

One thing I've thought would be nice though, similar to hidden modes, but somehow make it easy to switch back and forth between two or three mode groups. Not the full menu 5 thing, some kind of quick access toggle. It could be a short menu in the hidden modes. Then the user can define their 2 or three bookmarked groups from the main menu. For me I use my light walking and biking and indoors, and kind of want different mode groups for all three (but especially for indoor vs outdoor). I wouldn't mind if it even defaulted back to the indoor settings after an hour. (RAM actually lasts that long with these big caps, but without an eswitch there's no good timer and the RAM probably actually lasts too long).

Anyway, lots for room for creative advances still. I was kind of hoping to mostly knock out the real hardware-driver side of the firmware with as many configurations as can cram into 5 pins. Then the "application" side of the software can be developed more, but I'm sure there will be more ideas on the hardware side too. There already are a couple of ideas that fall in between, like pseudo regulated PWM, that aren't in here. If I do more that might be my next thing.

[quote=ToyKeeper]

I knew this is what you meant, I just couldn't come up with the expression at that instant.

TK, you mention the possibility of using a second eswitch. Would this be a difficult task? E.g. One switch to brighten and one switch to dim.

Flintrock, I like your idea of creating a menu to form a custom color/tint to be used as the main output with normal output options. The way I like to use RGBW for 90% of the time is as a dynamic white. You really can get a very nice tint this way and some extra output for the white channel. Anyway, I’m glad there is a starting point in this regard. I’m also excited about the hardware changes. I’m not quite sure how to implement it all right now, it I’m watching as many of you understand it much better and will be posting mod threads soon;)

I missed this comment the first time. I already took your diff from the TA driver thread from I think sometime in Decemeber and merged it. It's the first thing I did. If there are newer things then I don't know about that, but much of it might not apply anymore. I did some pretty big reworks on a number of sections to get it this this tight, not that they weren't written well, this was just an extra push for space, but you can't do that kind of thing until you have a good working code to start from. I still feel like it should be possible to save a few more bytes in the strobes, but placing them in an array failed in one attempt at least, and trying sequential switch made different assembly, but about the same. I don't think there are any gains left there except maybe in assembly and then probably not enough to be worth it. Even with all this it only saved 15%, so it's not like it was bad to start with. But I squeezed in the new stuff partially by letting the sleep interrupt literally leave a path of destruction behind it before resetting everything anyway. :)

Well the eswitch code is mine so I'll comment. Basically OTSM and eswitch work identically now as it is, in fact that's why I went ahead and added e-switch. They both use the same code to look for pins going low, go into a sleep loop, wake periodically to count time and check for the pin comming back up. And basically that creates the clicky-switch/eswitch combo in OTSM e-switch lights as it is now. There are some technical differences, mostly put in on purpose though, but I'm not even sure any of those even as things are at this moment would prevent you from using two e-switches and no clicky.

However, on a 4 channel driver, there's only one pin available for doing switching* (I'll come back to that asterisks) because there are only 5 pins other than gnd, vcc and reset. Presently OTSM and e-switch (and voltage monitoring) can all exist on one pin. However, in that case it's not presently possible to tell the difference between one switch and the other. The only difference is that one will kill the power after a couple of seconds and the other wont and in fact I added a loop to make it burn up power for a couple of ms after the long press threshold, to kill it faster and make sure you don't wake into off mode with the clicky as you would with the eswitch. That's not a problem though because if it really was an eswitch, the couple of ms wouldn't do anything to it. But we do need to be able to tell which switch is which. I've had a plan for that for awhile, and it's not too bad. You need the eswitch to pull the pin down not to zero, but to about 0.5V and then use the adc to tell the difference. So that requires the right resistors on the switch and a couple of extra lines of code. Of course you might want two eswitches AND a clicky, for that we have to get to the asterisk.

  • So about those 5 pins. We discussed this some in the attiny thread and I don't even remember whose idea it was, but basically, you can put a switch on the reset pin. You would want to pull it from high to some intermediate voltage, or the other way around, keeping it always above reset voltage (which I recall is very low, like 0.1V, not normal logic low). That could be done with the right resistor combination and wouldn't be a big deal to add support for in software (except that the conditionals for all the combinations both in c-preprocessor and actual code, would be getting bogglingly complex to get one's head around, have a look at PINT0_vect, but it just takes a bit of thought). This probably wouldn't even require an ADC read like joining switches on the voltage pin does. I'm kind of starting to like it actually.

So if going with the reset switch, actually I think it's pretty easy if you don't need a clicky switch at all, and doable even if you do.

Thanks flintrock. I have a few lights that have two switches, mainly sunwayman and nitecore, but also some lumintop lights with large switchboots that could house two switches. I have not modded them because the idea of a “dummy” switch that does nothing or does the same as the other never felt right to me. Anyway, good to know it is possible.

I’m doing this in my OTSM firmware with a morse code like technique:
short-long for 1st mode group, short-short-long for 2nd mode group, and so on. Once you have the code for recognizing morse codes (convert a combination of long/short clicks to a single byte value) implemented, you can easily access all functions and setup options directly with a simple code. For instance my firmware displays battery status with a long-long click, does a lockout with long-long-short-long, turbo with short-short, tactical strobe with 3x short, bike strobe with 4x short. With little effort you might even let the user choose which click combination calls a specific option. No need for cycling through strobes and batt status.
Not my invention btw., Dr.Jones did a similar thing years ago, though only in setup menu, if I remember right. In my firmware the “morse” codes are functional at any time.

Nice. Most of the code is actually already in there. I only time the first click, but not a real big deal to time them all probably. Would need to time the on time's too, but I've got a global time counter commented out in the delay function just for that. Still some work to put it all together but many parts are there already. Anyway, not really something I'm jumping to work on real soon.

Your point is correct, but I just want to mention that the efficiency for the FET-only case is not as bad as the straight line in the graph. This is because there are 2 main contributors to lower efficiency at high current: one is the high current density itself and the other is the temperature. So when the PWM duty cycle is, say, 50, the temperature won’t be as high as it is at 100, so the light output curve won’t be a straight line. See here for some measurements:

That plus one seems to come a bit far up the curve. It's only 350mA. To me +1 is for moon modes, not efficiency. Tripple channel is to help a bit with efficiency, and yes, isn't a huge issue. I'm not exactly sure what the axes are on that plot though or why the ideal one goes verticle toward zero. Of course with any linear driver there's loss of efficiency of Vo/Vi, but that should be factored into "ideal" for a linear driver I suppose, as distinct from the PWM and LED heat issues. I find bucks more and more worth the money. Twice the cost of the light, ok, but it runs twice as long on high output, at least, and without all the fuss about wire gauge and tiny voltage drops. That's not really about efficiency though either. A second set of batteries aint cheap either. It just depends what you need to do with it. The efficiency also depends if you're looking at it as 80 vs 90% efficiency (only 10%) or as two times less heat in the driver, which again depends what you're doing with it. If you're not a turbo freak, the heat's probably not a big deal. Another reason to have the extra +N channels though is just to get a regulated mode for constant brightness/battery drain. Well like I said, regulated PWM is the feature that interests me most next.

Yes, this is exactly how dr jones RGBW firmware works. Once the codes are memorized it is quite easy to program each channel as desired. It is also available to use at all times, not just in a config menu. Although the advanced function of “Morse code” UI could be argued to be configuration in itself.

I like what I am hearing from you guys! :slight_smile:

Rats, I found 8 more bytes in the new bits. I'm ok really. I can stop anytime I want... I think, probably. Everyone counts bits in their sleep right? I mean that's normal isn't it?

The first (as I'm aware) purpose-built bistro-HD OTSM driver with BODS is constructed and on first look seems to be working fine. Will do a little bench testing and then close it up in the light to see how it handles. The board is a standard TA tripple and it's setup pretty in bounds, other than usinig an 0805 cap on an already generously sized 0603 pad. More details on the component selection to follow.

Hi

I am currently working on a light with Forward clicky and eswitch on Texas Avenger board

Which part of your code modifies normal Bistro to eswitch?

I want to implement Eswitch into Bistro Avenger triple

I am using an Attiny85, so the lengh of code should be no problem