Okay, that helps me understand what you’ve got in mind.
I use a GPL or CC-BY-SA license on everything I can. There are a few reasons for this:
because my goal is to help empower people to make the things they want,
because it’s simpler and less drama-prone,
because open designs proliferate more easily,
and because (for someone in a western 1st-world country) there is no meaningful amount of money in flashlights. I couldn’t make a living doing this even if I wanted to.
Also, it helps me keep this as strictly an enjoyable hobby rather than work. I don’t like it when my hobbies stop being fun.
Anyway, just in case that helps clarify where I’m coming from. I’m hoping to help and grow the community.
I don’t want to sound ungrateful - thank you for thinking of us. With that said, TK is correct.
As far as the copyright discussion: in this case it’s a moot point. The copyright covers the image (eg the artwork). Here is my own image of this design which is also protected by copyright:
While these artworks may not be reproduced without permission, new artworks may certainly be created depicting the same thing. This works in the same way that a photograph of the city of New York, NY may be taken by anyone and still enjoy copyright protection without infringing on another photograph’s copyright.
Um, I didn’t think to mention it before, but I know part of what drains the OTC.
The attiny’s SRAM maintains its state for a short while after power is disconnected. On most drivers, this lasts for about half a second. However, if the driver has a 1uF OTC and that OTC is charged, the SRAM decay takes about four seconds instead. The OTC’s charge gets used to maintain the SRAM state.
This is actually beneficial in some cases. It means that “noinit” values can be trusted between boots as long as the OTC charge is above a safe threshold. It’s a nice way to implement short-term memory without eating up EEPROM write cycles.
It can also be used to implement offtime detection without a capacitor, assuming only “short” and “long” intervals matter and the exact timing isn’t important. Set a byte to zero, and if it’s non-zero at boot the MCU knows the power was off for a “long” time. If it’s still zero, the user did a “short” press instead.
I personally like having three levels of offtime (short/med/long) instead of two, but when only two are needed the OTC may be unnecessary.
I suspect that Design Rights do not work the way you think they do. See this page under the heading “What you can and can’t register”: Register a design: Overview - GOV.UK
Note these two things:
“[Must] not be an invention or how a product works - you’ll need a patent instead” (although patents also don’t apply in this case)
“You cannot protect the functionality of a design - eg a chair that folds down more quickly than others of the same kind.”
The confusion stems from some ambiguous English language words. In this case configuration means physical configuration, eg industrial design… eg if we arranged the components on the assembled product in the shape of a heart.
Generally I agree with the quoted text, but I’m curious about the part I bolded. How do you propose to “make good use” of the effect?
For a design implementing a clamp (but not the OTC related stuff), see A17DD-L v30 here. At the time I kept the OTC at 0805 and added a 0603 pulldown for it with the though of bumping to 10uF with a pulldown of low enough value to compete with whatever is happening inside the MCU. I knew we’d still be affected by temperature so I wasn’t thrilled by that plan. In theory I like your idea much better, but we are getting pretty short on space. Adding another diode and another resistor will get tricky.
Since we aren’t positive that there will be no bad behavior due to the high input resistance it probably makes the most sense to create a demonstration board in 20mm or 22mm where there’s enough space for an easy layout.
I’ll be more explicit: physical layouts are protected (so Gerber files, circuit boards, etc). Your drawing of the circuit is protected. The circuit itself? Not protected, as far as I know. That’s exactly what the Wikipedia link you used explains in reference to IC’s - mask works are protected. We can move this conversation to another thread if you like, to keep this one on subject.
I wouldn’t call that making “good use of” the boost effect. The clamp eliminates the issue but doesn’t achieve anything else for us! The clamp simply keeps the voltage inside a safe range. If we did need a higher voltage for some reason (only while using a PWM duty cycle < 100%) then it would become useful. That’s why I specifically asked - I thought you might have come up with a neat idea to put the higher voltage to good use. At 4Mhz we only need a couple of volts.
I did have comfychair try a freewheeling diode - if you read through the thread I pointed to earlier you’ll find some results there.
You definitely have a point on the safety aspect of eliminating the gate pulldown resistor in e-switch applications. It’s been brought up before and we should probably address it. A17DD-L v30 includes a gate pulldown.
You are preaching to the choir about tinkering with C1. That’s why I didn’t just add another 0805 pad next to the existing one and call it a day with 20uF. My assumption has been that the only reason we got away with things in the past is because we had so much bulk capacitance, such a hardy MCU, and so little noise to start out with (battery powered). OTOH if you are trying to say that moving C1 in the first place was a mistake… you are free to your own opinion. It kept our parts count low and functioned well.
RE: the impedance problem - you didn’t need to mention it: I brought it up in #64 based on the datasheet which we both like to reference. In any case if you feel pretty confident then I’m sure we’ll get around to trying it out. If you don’t feel pretty confident… we’ll still get around to trying it out!
ToyKeeper’s ideas are not “pure digital” AFAIK. She’s waiting for random decay to corrupt the SRAM. This does not currently give the long/medium/short indication she desires. Are you suggesting that we could allocate a bunch of SRAM for the job and measure time based on how much has decayed? Unfortunately I do not think that this approach is at all practical, but TK would be in a better position to address it. If we could hold up the entire MCU as you mentioned that would be different: we could run a timer (so yes, pure digital). Here’s the thread where the current no-OTC approach was initially discussed: alexvh’s firmwareEDIT: although running a timer and then writing values to eeprom all while running on a cap sounds crazy to me. What do you think?
I only have so much time/brainpower for tight layouts like the v30 layout I linked to. That’s why I suggested that I/we might use a larger layout to test your clever idea. That way we can knock out a layout with little to no effort. No tears will be shed if it doesn’t work.
Indeed. It may help to figure out the scope of what can be discussed without legal issues though. If we work out the technical issues and leave it at that, great. But if that gets followed up by lawsuits, the effort ends up being a net loss for everyone involved.
I add explicit GPL or CC-BY-SA licenses to the things I make, in part, because I want people to know there is no risk of legal trouble if they use it or make derivative works. All they have to do is share alike.
In this thread, the copyright notices and design right assertions don’t really foster a sense of zero-risk. It raises some potential red flags which could turn out to be incompatible with the idea of collaboration.
So what I’m wondering is… Is it safe (in a legal sense) to participate in this effort, and to build on the results here?
I’ll add — as I’m a bit old and shaky-handsed to build increasingly complicated small electronics with my own hands:
— is it safe (in a legal sense) for me to ask RMM to build me “one of those when they figure it out” and pay him for it?
How about a “protection money” fund — I’ll donate $10
in advance
to be held til needed
to pay off [you know who you are, so you’d be the one to get it, if you don’t recognize yourself, then you’re not the one]
to guarantee I can ask RMM to build the driver, and pay for the work, and not get him sued over commercializing a group concept.
Make it $15. I’ll PAY to make this potential thread to cooperation go away.
Alternate suggestion — agree ideas here are assigned to the owner of the forum to be used only for good.
Then he can at least ban participation by and advertising for any company that steals the ideas.
@All regarding the copyright protection situation - My primary concern is along the lines TK brought up. A chilling effect is undesirable, especially if the claims are not valid. With that said…
@Sharpie - I’ll have to defer to you for now on UK stuff as I’m in the states and I am not well versed on the other side of the pond. Is it safe for me to assume that (as far as you are aware) any “design rights” in the UK still depend on the “design” being “new”? And you’ve fully relinquished any claim you have on the 5-component design we are discussing, correct? If so any further discussion of those protections in this thread is purely academic (beyond any chilling effect it may have by scaring folks off). With that in mind, if it’s all accurate, let’s agree to table the matter of copyright until such time as you see the need to protect any new designs.
Thanks, I’m on-track if you’re on track.
We do eeprom writes now and get away with it using wear leveling. I’ll reiterate that TK and others are shooting for precisely measuring 3 periods of time. We want both analog and precision here. My take is that an improved analog circuit is the only solution which ticks all of the checkboxes.
While I have not personally used one yet, TK has mentioned specifically (in an unrelated conversation) that she’s running multiple flashlights with no OTC using brown-out-detection + SRAM decay to measure long/short. For the moment I’ll take TK’s word that this code works fine with no OTC.
You may not have stepped through all of the considerations for offtime w/ mode memory (the most popular config among those who’ve used a variety). If you aren’t fully familiar with offtime, ontime, and various memory/no-memory/short-cycle types of configuration… maybe another member can link to a good explanation? There have been many detailed explanations of varying quality posted all over the place, but I don’t have a link to one handy right now.
It does work very well. I’ve used it extensively when testing drivers (linear and boost) without OTC and a simple firmware to avoid the OTC or parts of more sophisticated firmware to intefere. This way I can use off time memory without OTC which makes especially mode testing easier: you don’t need the usual on-time double click after memory kicked in. So if we’re talking about this firmware implementation:
That trick was created by alexvh, not me. I just made it more popular.
In any case, I find it eliminates the need for an OTC when only short and long are needed. The physical OTC is still relevant if you want to adjust the button timing or give it more than two time buckets though.
I briefly tried to use the decay to measure more than just short or long, but it seems the SRAM goes from intact to fully decayed very quickly. The decay is too short to be useful, even with a large sample size. The technique can be used on slower-decaying RAM though. Apparently it’s quite useful for rate-limiting auth requests for smart cards, for example. It’ll refuse to auth until the RAM is fully decayed, using physics to prevent most brute force attacks.
EEPROM writes are almost entirely done within the first few ms the MCU has power. It’s part of the boot-up process, before the LED is even turned on. It’s very difficult for a human to turn the device off fast enough to interrupt that.
The exception is during config mode, when timed writes occur periodically while waiting for power to be disconnected.
The firmware is available if you’d like to see the details. It’s probably worth looking through regardless, to understand how the driver is being used, and answers quite a few questions which have been raised in this thread.
Not so much. The OTC drain and MCU power-down actually take longer when using a lighted tail switch. Sometimes to the point that they never fully power down at all. That’s why the bleeder resistor is required. Otherwise the tail switch is forcing current through the driver when it’s trying to be off.
Based on a quick calculation of runtime power versus capacitance… I estimate the MCU probably runs for anywhere from a dozen cycles to a few thousand clock cycles after power is switched off. This could mean up to 3ms or so.
The many-taps thing uses SRAM to count the taps, to reduce EEPROM writes.
The actual eeprom writes during that are two bytes per boot, done immediately at each boot. If the main emitter turns on, that’s confirmation that the eeprom write has completed.
The eeprom writes happen before the user touches the switch. The main emitter blinks out a number, eeprom write happens, then the main emitter does a stutter pattern telling the user to click. If it’s stuttering, the write has already completed.
Another write happens after the stuttering stops, and then it waits for a second with no output.
In most “stuck” cases, people have been doing two full clicks instead of a light tap. Usually, it’s resolve-able with a few tips or a video on how to tap the button.
The “bricked” MCUs were completely unrelated, failed at flash time with a firmware programmer. This can be fixed by removing the MCU and trying again, or in extra-difficult cases, using a high-voltage serial programmer. It also only seems to affect me so far; others haven’t reported running into this issue.
As far as I can tell, the most likely cause of a truly “stuck” driver would be if the SRAM byte used for tracking the fast taps has the unlikely trait of decaying to zeroes instead of ones. This could encourage the driver to enter config mode instead of normal running modes. (after resting a while the counter would start at, say, ten, instead of zero… and the estimated chance of this happening is one out of every few hundred MCUs… which can be dramatically reduced by using 16 bits instead of 8)
Has already been done. The result was that the attiny eeprom lasted about 10X longer than spec. However, this was at room temperature. It actually took quite a while to see the first eeprom failure.
If the attiny eeprom performs according to spec, and if the user taps the button 100 times per day, it should take about 876 years before the first eeprom write failure. If it performs according to test results, it would be closer to 10,000 years.
I did some brief tests on this, and IIRC alexvh did some much more extensive tests, and we both got the same result — the decay happens too quickly to be useful. That is, the beginning of the decay and the end of the decay happen so close together that the time between isn’t useful.
Possibly, but I expect it’d require a much larger capacitor than we can fit onto these drivers. We’d probably need capacitors measured in mF instead of uF. Regular MCU operation requires at least a few mA.
The attiny13a has one PWM counter and two channels. It is fully utilized, leaving nothing spare.
In my testing, brown-out options don’t actually make any meaningful difference. At first I thought it was required, but it’s not.
Longer SRAM decay isn’t really needed. It’s already long enough. The goal is to get the OTC to decay at a specific and consistent rate, and the obvious first test for that is to use a bigger capacitor with a resistor attached to it. Measure it at several fixed intervals, at a high and low temperature, and the results will show whether it’s a sufficient method. Possibly also measure it on both a single-cell and multi-cell driver, with the appropriate zener mod and voltage divider adjustments, in hopes that it can remain consistent (or at least usable) there too.
This is mostly just waiting on someone (maybe me?) to build wight’s latest design and measure it. I, um, don’t have the parts or experience for building drivers just yet… but hopefully I can do something about that soon.
I’m very familiar with the free software world, but I still need to find out how other hardware maker communities handle the legal aspects of what they do. I’m not sure how they lay the groundwork for free collaboration while also protecting themselves from abuse by large commercial entities.
The only small businesses I can think of which make any profit from BLF-related drivers are RMM and a few individual people who upgrade and resell lights on a limited basis. Sometimes they also build their own drivers from scratch. RMM uses his own designs, but collaborates with and contributes to the efforts of others. The general consensus about these people is that they’re beneficial and should be allowed to continue doing this.
There’s also Banggood+Manker, which is much more controversial. Explicit permission was given, but they have since overstepped the limits of the initial agreements and don’t seem at all concerned about it. Driver designs have also changed somewhat since then, which might nullify any rights. And even if the IP holders had the resources to do something about it, the relevant laws haven’t really been established in China anyway. Only large companies have enough influence to enforce their copyrights or patents there.
This.
Even the GPL hasn’t been proven there yet, and it’s pretty strong in western countries.
There are a few orders magnitude difference between Honda and a couple individuals on a forum.
As far as I’m aware, it’s simple: Look at the awesome things modders are building, and make that available to a wider audience. The BLF folks involved don’t get any payment aside from light samples, so there isn’t really any profit. Getting paid in half-broken flashlights isn’t what I’d call a business plan.
I don’t know what the future plans are, and most of it doesn’t really involve me. It’s mostly just “hey, I’ll send you a light if you’ll calibrate the firmware”. I have some concerns about the overall effects on BLF though, as it seems to shift the needle from makers toward consumers, so I’m hoping to focus on moving that needle the other way.
I don’t know about anyone else (except hank, who already chimed in), but I really value RMM’s driver production services. Not many people are willing or able to build drivers themselves, even from a kit, but they still have an interest in using complete drivers. I don’t want to interfere with that.
Setting up shop to produce, sell, and ship drivers, complete with a storefront and customer support and taxes and legal registration… is a significant ongoing investment. It’s enough that most people who could make and sell hardware don’t want to, since it’s a lot of work for very very low pay. If that’s something you’re interested in, you may want to protect your designs, maybe file for patents, etc. If not though, I hope you’ll decide to explicitly allow others to do so.
I’ve been following this thread quite closely because there’s some good stuff being discussed here underneath all the salt and I feel like I’m learning a lot from it. But I did want to address this point because I feel its a gross misrepresentation for one reason — code comments. A good developer will document their code with comments throughout, and ToyKeeper does a very good job of that. You don’t have to understand the actual code in order to understand the explanations that are included alongside it. I don’t see any comments or explanations on your circuit diagrams, or most anybody else’s for that matter.
saw some potentially incorrect info, this should be correct:
in case of split byte eeprom write, erase takes 1.8ms, write takes another 1.8ms
in case of atomic byte erase&write, it is 3.4ms
page 21 paragraph 5.5.4 table 5-1
in my own attiny85 firmware I do split byte eeprom operations, first erasing the next cell to be written in next boot cycle, and only after that, calculate next mode and write the previous “next” cell from the previous boot cycle. By doing it this way I haven’t yet gotten any cases of errors in mode switching. Even if it would happen it would only result in failure to switch mode.
