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

Flashlight Modding and DIY Parts
32

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.

33

[quote=ToyKeeper]

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

34

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;)

35

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

36

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.

37

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.

38

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.

39

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.

40

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:

41

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.

42

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:

43

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?

44

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.

45

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

46

I actually have a few updates (not posted yet), mostly to help with some corner case bugs in the preprocessor options. Anyway, that shouldn't matter. You don't need to mess with the code itself at all, just the preprocessor configs. I think the tripple_layout as I posted it has the e-switch already defined on the cap pin in the fr-tk-attiny.h, but you can check. Then you just need to uncomment the use_eswitch option in bistro-hd.c That's it.

Do realize it's experimental. The code itself is mostly all in PCINT0_vect, the pin change detection interrupt.

Unfortunately, the OTSM isn't quite working out. Details are here:

https://budgetlightforum.com/t/-/34900/1887

Basically it works on FETs but there is a mysterious difference on the 7135s, a difference that really shouldn't exist, sill trying to figure it out.

By the way OTSM is not very compatible with most available revisions of attiny85's. e-switch should be fine though. OTSM does work(well, in principle, given above mentioned problems) with attiny45V though. With that light, you might want both if OTSM gets working better. I was eyeing the Supfire A2 as a light like that. I might get one and test it out, but it's a difficult mod to get a custom driver in there. I think lightbringer modded one.

Oh, of course my original motivation for the e-switch was the Q8. Once once I get my hands on one of those you can bet I'll get it running, but I think that's e-switch only.

47

I got no expirience with programming

I was hoping there is an easy solution to change the OTC pin to eswitch

I opened the Bistro HD.c file in AVRStudio and searched for eswitch and its in there like dozens of code lines

48

Ok, I'll detail it for you shortly. You'll want to start to get some understanding of preprocessor defines, but anyway, it's simple. Most of the lines are where the options are used. You only need to worry about the ones where they're set (#define), near the top. I just don't have time right now to quote the relevant lines... I'll post back soon though, along with some notes on options for how to wire the clicky part of things.

49

Congratulations to everyone involved! Awesome job!

50

@RH64 Well the main original goal, OTSM, has some problems still, and it's a mystery at the moment that I'm a bit stumped on. The debugging required to get the bottom of it is maybe not lightweight at all either (maybe needs custom hardware to time triggered shutdowns for example, a bunch just to debug).

@Lexel I think I misunderstood where you're coming from. You're trying to port the e-switch into Bistro-TA. That's your mistake. Bistro-HD is a not a specialty release like some previous ones. It fully includes bistro-TA, as well as bistro-trippledown and plain bistro, and I may even get a BLFA6 emulation build into it. It's just a matter of selecting the right config options. I'm presently working on separating pre-set configs out into separate files so we can just have configs like this laid out for custom lights and ready to go. It will be part of the next release. I don't know much about biscotti, but ideally that would be config options too. That may be unrealistic, not sure.

Anyway, what you need is just to go to fr-tk-attiny.h

Go to the trippledown layout section.

Uncomment this:

//#define ESWITCH_PIN PB3

That defines the eswitch as being on the traditional CAP pin.

Actually there should be no problem with me leaving that uncommented by default, but it wasn't. You don't need to uncomment the CAP_PIN either (if everything works right), and in fact you can use it for both.

Then go to bistro-HD.c In the top section the #define statements turn options on and off, until line 209.

then enable USE_ESWITCH. (un-comment #define USE_ESWITCH)

You will want to go down and look at the first boot options and set them how you like too. Memory is turned on by default I think which wasn't actually my intent, probably happened during testing (another reason to have custom config files).

Now comes the complicated stuff. Is it a 1S light? Does it have an LDO, a protection diode? If it's 1-S with no LDO, I would set READ_VOLTAGE_FROM_VCC and comment out READ_VOLTAGE_FROM_DIVIDER This frees up the voltage pin from complication. This only works if Vcc sees the battery voltage (minus possibly a small diode drop).

Now, what about your clicky switch? We can have it use the tk noinit method that requires no cap. gchart and I have been working on an upgrade for that in BLFA6 to address a fairly serious reliability issue. It's working there. It's not in here yet, but could be soon. You can USE OTSM, but it's not working right yet, and may never be low parasitic drain. You could use OTC actually. You would just put both a cap and a switch on the OTC pads. The switch will short the cap and bring it down. Might want a small series resistance in line with the switch to reduce the cap discharge current. I think this is a good option for now.

If you want OTSM, and you're using READ_VOLTAGE_FROM_VCC you'll want R1 to be 1/3 (no more, less is ok) of R2. And the total bleed resistance (R1+R2 is part of that, parallel to bleeder) is still a mystery. It should work with a total of 4k but there are question marks still.

If you're using READ_VOLTAGE_FROM_DIVIDER and OTSM you'll want the max divider voltage to correspond to Vcc, or maybe 5% less. If it drops too low it will trigger OTSM. In that case you'd also need to reference the ADC off Vcc and I think the option for that only exists in my un-released version.

Anyway, either enable USE_OTSM or USE_OTC, or neither to revert to the noinit method. I wouldn't go with OTSM at the moment unless you want to help fix it. Even OTC or noinit in combination with E_SWITCH are still very alpha and you should approach it that initialliy it can be a lockout and get the e-switch working. If it does more on first try, that's a bonus. These combinations were tricky to work out and still untested.

At some point maybe I can work up a config for your case and all you'll need to do is select the right config file. The danger with doing too much of this is it's more baggage to maintain if the configs all need some re-working. Oh well, if they weren't there, they'd need to be reworked too, just not by the programmer who broke them. It puts more responsibility on the development side.

51

Ok if I get the settings right I do need to compile the hex file
I did it one time with a narsil triple.c
But how do I get the attiny.h on the hex or MCU?

Do I only need to disable the one OTSM line or also lines like
#if define(USE OTSM) || defined(use_eswitch)?

As there is only one Bistro HD.c file in that download is it set to 3 channels?