Thanks! This looks like it provides some examples for a couple things which might be useful. 
Could a pin be used with something like that (I don’t even know if that is a valid schematic, that would work and would not catch fire):
It could detect which button is pressed by reading the value of the output of the voltage divider. It could also detect if both buttons are pushed at the same time like that.
Otherwise, do you have any good pointers on how to get started with designing drivers? I really would experiment with that a little and maybe write some very basic firmware for a microcontroller to control it. I guess that would probably be a good start(?)
That’ll work. Back in the day when I was using 8 pin MCUs I combined off time cap, voltage divider and E-switch on the same pin with something similar.
Some people here use them breadboards for testing. Personally I don’t because most stuff I buy for drivers are SMD components. Try testing different LDOs, digipots and regulators that are all SMD with a traditional breadboard. Not so great, so I design my own “breadboards” with a bunch of things that I need, a few voltage dividers, diodes, digi-pots, caps and so on, and have separate “breadboards” for regulators so I can burn them up without having to use another full size breadboard to test more. It can get a bit messy with all them cables running around but it’s good for testing stuff like you just suggested. Start by designing something similar, build and start testing. Then you can test what you want before committing to a driver design.
Thanks Mike C, your advice is really appreciated! One question though: Are there some good schematics of drivers out there that you can recommend for me to study to get a feeling of how everything works?
Guess I need to read into the whole FET/7135 stuff (my electornics knowledge is just too basic).
@Kanton, check the original Texas Avenger series of driver thread (the OP by TA, not the lexel sales threads) it has the full schematic.
The TA drivers Cereal_killer mentions are here, there is a schematic in the first post. Texas Avenger "TA" Driver series - Triple channel + Bistro or Narsil + Clicky or E-switch - The Ultimate open source driver!
Here is a basic schematic for classic 8 x 7135 design: LED Driver Schematic - #15 by relic38
Another tip if you make your own “driver breadboard”: Instead of using the standard 0603 and 0805 resistor/cap pads, make your own with much bigger solder pads but keep same distance as 0603. It makes replacing those components much easier. Here I have 0603 resistors on these oversized pads:
Wow, thank you all!
Don’t forget to check the oshpark project thread (managed by RBD). It’s got tons of projects organized together in it as well as lots of our parts libraries.
What pcb design software do you plan to use? My eagle parts library is posted in the oshpark thread but it hasn’t been kept UTD with my actual library I use for a few years.
If you plan to use eagle LMK and I’ll make sure I post my current library file, come to think of it I recently promised to repost my current library for gchart as well so I’ll get that done soon anyway.
Final bit of advice, many of us that use eagle all learned from the same guy, a God really; Mattaus. He’s not around anymore but his video series on YT still exists. Eagle has been updated a lot since his time here but the basic work flow is still the same and he has the best video on making library parts I ever came across on the internet.
I don't quite understand - read it a couple times, not sure what that all means in the real world. Seems like it's limited to input only, and if so, maybe for a switch, but will the switch work? Or something added to make it work. Sorry, I just don't have enough understanding of the voltage range of a switch to tell if it would work or not.
Happy New Year to the UI developers. With the new year I bring you a new (fictional, at the moment) UI: Spark UI!
Having experienced the true spaghetti monster (Meteor M43 UI), also the D4 UI, and various clicky UI’s there were some areas of improvement that I felt could be explored.
The abstract criticism I have with the current UI’s is that they don’t adhere to a principle of good UI development: user inputs should cause the same reaction no matter what state the UI is in, and parallel to that, the user inputs should result in the same behavior at all times.
By improving these two areas, the user can better understand the UI and the UI can better understand what intention the user has when pressing buttons.
For example, if a single click turns the light on and off but a double click turns on strobe, then you have already violated a design principle. A double click should conceptually be no more than a fast cycle on then off. A 6x click should result in the power cycling 3x times on-off.
The M43 Meteor is a good example of bad UI in this regard: it has no idea what number of clicks you finally intend to press, so it has to blindly start changing modes each time you click. The user therefore has to content with all kinds of flashes, blinks, awkward pauses before the UI says “Ahh, you wanted six clicks to lockout!”
So how do we maintain 6x click complex UI functionality?
The general theme of Spark UI is that the user is given a small window of time with a visual cue in which the UI accepts advanced user inputs. The visual cue is a metaphoric “spark” that either leads to ignition or burns out, as in to start a fire, you have to act quickly to ignite the spark into flames!
I took inspiration from Toykeeper’s graphics to explain the UI. Without further ado, here it is:
Hopefully you can see that a spark can be accessed from anywhere in the UI; also, the behavior of clicks and holds is mostly predictable (only one deviation, continuous holding from any position results in Turbo EXCEPT in a multi-level; in this case, Turbo hold is repurposed to advance to the next pattern. See the green text)
In summary, the “spark” is the cue that the firmware is telling the user “I’m waiting and listening. Tell me what to do.”
Let me know what you think. Hopefully this sparks some discussion (pun intended).
I can’t speak for any other firmware than my own, but the quoted behavior is certainly not in my firmware. I simply have a timeout after each single click. This timeout is short enough so single click on and off doesn’t have much of a delay. If multi clicks are entered rapidly enough there is no action between the clicks. As mentioned, I can’t speak for anyone other than myself but I will be pretty surprised if the popular BLF flavors of E-switch firmware don’t work like this too.
Then it’s just a matter of taste which function you want first in the order of available functions. I’d start by arguing that the blinkies should be way down in the list past battery check and lockout. I have them well out of the way in my firmware.
I kinda like the idea (which is why the rest of the text is critique of the parts I don’t understand/like) but I think it’s not really realistic with just one button. For example reverting the tactical mode (I assume that’s the momentary function, right?) will result in 4 turbo flashes (a thing that also annoys me on the D4). Some questions regarding your interface: How does “RAMPING UP/DN” work in detail? I would assume you hold until it sparks, release, hold again, to ramp up. How do I ramp down? And how to I reignite a spark if holding also is necessary to leave the ramping mode and reignite a spark?
Another thing I don’t really like but seems unavoidable is the whole timing thing. I personally feel like the “STILL HOLDING” —> TURBO isn’t the best idea. On my D4 I sometimes miss the release of the button after it’s turned on in moon mode and it starts ramping up. That’s not that bad. Finding myself suddenly with turbo instead of the wanted moonlight because I held on too long would be a major issue for me (because the reason for wanting moon mode are usually either to not blind myself or to not destroy others). Which brings me als to the question: What is the visual cue you would want to use? If the light is on, it can’t be the main light, right?
One last thing I think you are not considering are user stories. A very prominent one for example is “I walk with my dog in the night, having the flashlight set on a lower level. I hear a noise and want to switch on turbo quickly to look what is going on. After I concluded my search for the noise I want to return to the previous brightness and continue my walk.” Narsil in the D4 solves this by a double click to enter turbo and another double click to return to the previous brightness. How would that scenario be handled in your UI?
Edit: One last thought: You are also breaking with some established conventions. Double clicking for turbo and holding the button from off to get into moonlight can be found in many lights. I don’t know if that’s an issue for you though - guess you have to break with the established stuff to create something unique and new.
Cheers
Not a fan of the still holding to turbo, and not sure how the click to moon works? I'm a bit confused what really is happening in that UI.
I would read it that way: From off you hold until the “spark” ignites, then release, then click once to enter moon.
Wut is the "spark"?
This reminds me of work - graphic designers layout out our screens to make then balanced and no sense of dynamics or how many clicks it takes - all they care about is the look, not function. I'm not quite getting the "spark" thing. Sorry...
I guess its like a stutter letting you know your can click to enter other fuction/options. .
As far as I understand it it’s either a short blink of the LEDs or some other secondary LED that e.g. blinks after you hold the button telling you that you can now start with the click inputs (1x, 2x, 3x, 4x etc. clicks):
But I guess we are better of waiting for NWoodsman to explain it in detail.
Thanks! I hope 2019 is better for all of us.
Ever looked at HiveLD? It’s a lot more confusing than the Meteor.
That is a good design goal. Stateless interfaces which always respond in the same way are great. However, what you described in the UI diagram doesn’t look like it follows that design pattern. Even having memory is technically a violation of that goal.
When using FSM, it’s actually easier to avoid that issue than to implement it. The library waits until it’s sure the user is done pressing buttons before it sends a “finalized” event to the UI code, and the UI code can easily avoid false starts on the way to a longer input.
However, the false starts are sometimes desirable in order to provide a faster response to user inputs. So some interfaces implement those on purpose, and then cancel them if the user keeps pressing buttons.
If I understand correctly, the answer is to put the main on/off function on a single click, and reset the click counter on each button release in that mode, making the light act like it has only one mode… and move everything else behind a “hold” action? Basically, instead of a bunch of actions from “off”, it has a bunch of actions from “hold”. Or, to phrase it another way, every input except the basic on/off action has a “hold” prefix?
This appears to be a way to optimize the interface for latching momentary use, at the expense of all other usage styles. And, depending on one’s needs, that might be a worthwhile trade.
Yep, that is a good point. You would be expecting turbo, but it wouldn’t be pleasant to ‘fake strobe’ to get the mode back to normal.
You are pretty much understanding. You hold for a spark. It starts glowing, you release. While still glowing you start a hold again, and the ramp immediately starts. Reverse ramp would be another release and hold within a timeout. Delay too long and it results in a new spark as you point out.
If the light is on, the cue is to ‘buzz’ the main emitter which is just a high mhz strobe at whatever brightness you are at. Not blinding, since the light is already on at a comfortable level. If the light is off, the cue is a 1 lumen buzz of the main emitter. If you want moon mode, you look at the main emitter, hold for spark, and release once you see the 1lm glow buzz. Now just point away and click and moon turns on. If you want turbo from darkness, don’t watch for the buzz, just point the light in a safe direction and keep holding until it flares up.
This is a good point and I would need to clarify the diagram with the intention of the “spark keep holding” is for momentary turbo, with a return to off/last level when you release the hold.
This means turbo is accessible in your scenario from a simple keep holding. Turbo would also be accessible from the top of the ramp if you wanted it to stick.
Can you clarify this?