Flashlight Firmware Repository

1815 posts / 0 new
Last post
LED Boatguy
Offline
Last seen: 5 months 1 week ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah
RMM wrote:

LED Boatguy wrote:
I’m gonna do a FET shootout to see if that SIR800DP-T1-GE3CT FET is really any better than the ones that are half the price.

I’m interested to see what you find.  I found that I couldn’t measure a statistically significant difference between the 4 mOhm and 2.4 mOhm FETs to the SIR; the repeatable difference was so minute that I couldn’t measure it with any of the equipment that I have, which means that certainly it wasn’t anywhere remotely close to a visible improvement.  

I built up a Wight FET +1 board with the FET you sell and will use it to compare the same board with the same components, save for the FET, driving an XM-L2 and a 3 up XP-L mounted to an iceberg, er, my big ol heatsink. I’ll have to modify the firmware to remove the 7135 from the equation.

I gots ta know…

Crux
Crux's picture
Offline
Last seen: 9 months 48 min ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

You're welcome LED Boatguy! Glad to be of service. I don't think I'll ever part with my 87V either

I've just managed to get a 2cell driver down to 20uA in the LVP sleep mode.

10uA - ADC resistor divider, (664k total resistance) I need to do testing to verify this high resistance will be stable and noise immune.

3uA - 5V regulator,

2uA - ATtiny13A,

5uA OTC bleeder resistor (1Meg at 5V). I think driving the cap_pin low during sleep will save this 5uA.

Edit: Yep, this line saves the OTC bleeder resistor current in sleep mode, 5uA in my case.    

PORTB &= ~(1 << CAP_PIN);    // Set cap_pin Low

dthoang
Offline
Last seen: 3 weeks 1 day ago
Joined: 10/09/2014 - 13:30
Posts: 319
Location: Austin, TX USA
RMM wrote:

I tried the medium press thing, including several different OTC values, and just can’t get into it.  If it’s not on a momentary switch I don’t want medium presses because I can’t consistently do it without some sort of feedback.  It’s also a pain to get things consistent between different drivers and parts.  I can see someone doing it for that “one light” they use a lot and become really accustomed to, but for lots of lights it’s a huge pain in the butt.  It’s a cool idea, but just not one that in practice I really like.  Of course, that’s just my opinion, and everyone else is entitled to theirs. Wink

~200uA is about par for the course if the attiny isn’t sleeping, plus you’ve got the voltage divider draining a few uA no matter what, and probably the pulldown resistor putting a drain on things if the MCU isn’t going to sleep. 

I have a new angle on this. You know the difference between off-time memory and on-time memory right? What is called “medium press” here is really medium off-time. Measuring off-time is tricky and depends upon RC time constant that depends upon resistance, capacitance, and voltage. What if we compare short on-time and medium on-time instead?

  1. From off, turn light on for < 1/4 second. Then off. Then on. This would count as short on-time.
  2. From off, turn light on for between 1/4 second and 1/2 second. Then off. Then on. This would count as medium on-time.
  3. From off, turn light on for > 1/2 second. Then off. Then on. This would count as long on-time.

This can be chained: on < 1/4 second, off, on < 1/4 second off, on would count as two short clicks.

The on-timing can be performed by the MCU accurately.

Any thoughts on this?

one year rookie

ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

dthoang wrote:
What if we compare short on-time and medium on-time instead?

This can be chained: on < 1/4 second, off, on < 1/4 second off, on would count as two short clicks.

Any thoughts on this?

That’s how the BLF A6 firmware enters config mode, and how some other drivers also access similar config modes or sometimes hidden modes. It’s necessary to do a bunch of short on-time taps in a row to get to the hidden modes, to reduce the chance of reaching the mode by accident.

This is also how some firmwares detect double-taps or triple-taps for other purposes, like going back instead of forward. I don’t really like doing that though, since I prefer to be able to advance forward quickly.

BTW, the memory decay trick is really useful for tracking short on-time taps. This allows it to work without writing extra data to eeprom.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

While I’m waiting for the flasher to arrive from China I checked your repo for some code to use. After a while I found Luxdrv-0.30b and started to modify it. Very nice code for learning avr I must say, thanks DrJones. I ripped out everything I didn’t want and added a few minor tweaks. I’m not really sure about the license though? If DrJones is happy with it I stick to Public Domain, if not I’ll have to rip out some more code I guess. Smile Not that much logic left anyway, it basically is hello world.

Here’s what I got so far: http://pastebin.com/7f2GMwzs

It’s only lo-mid-full-strobe so far, and easily tweaked in the code. Memory turned off by default and no run time modifications available. A few things I don’t really get, like how you tweak pwm, but perhaps DrJones already did that. Smile I’m not really sure what driver this is meant for but I guess it should be 105c or similar.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

guardior wrote:
I found Luxdrv-0.30b and started to modify it. … I’m not really sure about the license though?

LuxDrv 0.30b says this for its public license: “License: Free for private and noncommercial use for members of BudgetLightForum.com and Taschenlampenforum.de”

By default, US copyright applies automatically and reserves all rights. Since LuxDrv only specifies private noncommercial use for a specific population, those are the only rights granted to us and we’re not legally allowed to do anything else with it.

So, modifying it and publishing changes is not legally allowed unless DrJones explicitly states otherwise. As far as I’m aware, he is the only person allowed to change it, publish it, sell lights with it, etc. The rest of us can only make personal private use of it. I had to ask him for permission before I could include a copy in the repository, and I do not have permission to include derivative works of it.

If I understand correctly, I think he takes licensing fairly seriously since he’s in the business of selling drivers and has commercial agreements with other vendors.

Just FYI, since you were unsure.

chouster
Offline
Last seen: 9 months 3 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany

Hey driver experts!

I wonder if there’s a firmware or a driver that offers “soft transitions”. What I mean by that, is that the light will always perform a short ramp into a given mode. To really beeing able to notice this cool effect, such a light shouldn’t have many modes with a big enough gap between them. So when you turn it on, it will increase brightness to 100% or 100% of the mode it will turn on in. And when you turn it off, it will decrease brightness to 0%. And when you change modes it will perform a soft transition from one mode to another. Don’t know the time in that such a ramp should happen and if the ramp should be visually linear to make it look the coolest, but I think such a light would be awesome.

Are there lights that have such a feature?
Are there drivers or firmwares that do something like that?
If, not, is that kind of firmware even possible for 105C or BLF17DD?

Sorry, if those are some dumb questions to people that know that kind of stuff, but obviously I’m not that kind of guy…

Also, am I the only one that thinks these more or less soft transitions would be awesome?

Cheers

Mike C
Mike C's picture
Offline
Last seen: 2 months 4 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

chouster wrote:
Hey driver experts!Also, am I the only one that thinks these more or less soft transitions would be awesome?

No, but in my opinion it’s worthless if it’s not driver with an E-switch. With a standard tailcap switch the light has to be switched off for a brief moment to switch modes. That breaks the seamless transition to the next mode as it is. Having it smoothly ramp up or down after being entirely switched off would just feel tacky to me.
chouster
Offline
Last seen: 9 months 3 weeks ago
Joined: 02/20/2014 - 15:05
Posts: 683
Location: germany
Mike C wrote:
chouster wrote:
Hey driver experts!Also, am I the only one that thinks these more or less soft transitions would be awesome?
No, but in my opinion it’s worthless if it’s not driver with an E-switch. With a standard tailcap switch the light has to be switched off for a brief moment to switch modes. That breaks the seamless transition to the next mode as it is. Having it smoothly ramp up or down after being entirely switched off would just feel tacky to me.

Yeah, I was actually thinking of an e-switch firmware without saying so, because I couldn’t even imagine that this kind of thing was also possible with a clicky light. I understand what you mean with a tacky feal, when the light is still emitting after having been switched off. But I think when it’s only half of a second and you already got used to it, than it might be a very nice effect.

How hard is it to get started with programming that kind of stuff to do things like such kind of a firmware for somebody who never programmed anything?

Mike C
Mike C's picture
Offline
Last seen: 2 months 4 weeks ago
Joined: 01/22/2014 - 08:03
Posts: 2009
Location: Sweden

chouster wrote:
How hard is it to get started with programming that kind of stuff to do things like such kind of a firmware for somebody who never programmed anything?

Impossible to answer, everyone is different, but what I can say is that the kind of programming used here is probably amongst the easiest. It’s pretty straight forward.

Before I got into this stuff I had done a little C programming many years ago, so I can’t give you the perspective of a total beginner. I already knew what variables, integers, arrays, definitions and all that stuff was. It was so long ago that I can’t remember how long it took me to get my head around it. When my interest in programming flashlights started I just had to brush up on the actual programming syntax. Then I started analyzing the Star firmware and started making changes to it, checking the datasheets to understand exactly what every line of code did, and then finally writing my own.

Edit: I should point out that reading the datasheets for the MCU is not necessary for ramping and general flashlight behavior modifying. You only need to start looking at datasheets if you’re going to start using different pins for everything or other major changes to the way the MCU is does things.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
guardior wrote:
I found Luxdrv-0.30b and started to modify it. … I’m not really sure about the license though?

LuxDrv 0.30b says this for its public license: “License: Free for private and noncommercial use for members of BudgetLightForum.com and Taschenlampenforum.de”

By default, US copyright applies automatically and reserves all rights. Since LuxDrv only specifies private noncommercial use for a specific population, those are the only rights granted to us and we’re not legally allowed to do anything else with it.

So, modifying it and publishing changes is not legally allowed unless DrJones explicitly states otherwise. As far as I’m aware, he is the only person allowed to change it, publish it, sell lights with it, etc. The rest of us can only make personal private use of it. I had to ask him for permission before I could include a copy in the repository, and I do not have permission to include derivative works of it.

If I understand correctly, I think he takes licensing fairly seriously since he’s in the business of selling drivers and has commercial agreements with other vendors.

Just FYI, since you were unsure.


So luxdrv-0.30b is basically closed source, even though the code is published in the open?! Do there exist any Public Domain driver? Star? Or possibly open source? Anyway, If DrJones is not happy with me borrowing a few lines of code from luxdrv-0.30b and release it as PD I will happily remove those lines he/she thinks are closed source.
bugsy36
bugsy36's picture
Offline
Last seen: 1 year 5 days ago
Joined: 07/11/2014 - 18:15
Posts: 2475
Location: Florida USA

chouster wrote:
How hard is it to get started with programming that kind of stuff to do things like such kind of a firmware for somebody who never programmed anything?

Not hard but there are two parts to it.

Part 1, Flashing: The easiest. Mainly a hardware thing and pushing a button.

Part 2, Coding: A little more difficult BUT actually written in layman's ENGLISH. The key is understanding how to read code, and by NO means am I an expert. All code starts with (in layman's terms) "Definitions" that are always at the top of the code. Below that you will see "Actions or Commands", of with words like "if" "and" "or" "while" etc. and values (numbers) that set parameters.

If you start out by reading the simplest of code (ask TK to point you in that direction) and then start seeing the differences with the more advanced code (all while knowing in advance what the actual code does) then you will start to pick it up. The hardest part of it all - READING. Very far from the sports page but just as interesting once you get the hang of it Smile I have been too busy with too many other project to devote the time to read and learn but if you have a desire to do it is worth it.

The hardest time is the first time. After that it is easy (no matter what it is) LOL

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

bugsy36
bugsy36's picture
Offline
Last seen: 1 year 5 days ago
Joined: 07/11/2014 - 18:15
Posts: 2475
Location: Florida USA

guardior wrote:
If DrJones is not happy with me borrowing a few lines of code from luxdrv-0.30b and release it as PD I will happily remove those lines he/she thinks are closed source.

That question should be posed to Dr.Jones. None of us can answer that and you should NOT assume what his position is either way. If the Doc is opposed and you do not ask that just shows disrespect AND if he is not opposed you just shorted yourself and others.

I also own a graphic design and sign business. Copyright is what we have to protect us BUT there are many things that as long as we are asked we do not care. We tend to get upset when someone takes something we worked hard to produce without asking and makes a million or is worth a million and in turn makes it worthless.

Here is another phrase (I have lots of them).....It is the fool that does not ask. And just FYI if it wasn't for asking TK we would not have the fantastic A6 code or even Wight's +1 7135 driver (which I do not have further info about yet)

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

chouster wrote:
I wonder if there’s a firmware or a driver that offers “soft transitions”. What I mean by that, is that the light will always perform a short ramp into a given mode.

The closest examples I’m aware of are:
  • Ferrero_Rocher/Ramping_UI_Table.c uses a ramping interface, where you hold the button until it gets to the level you want and then let go. The transitions are mostly smooth, but it has only 64 (or 40) discrete levels instead of 255.
  • STAR has an option to smoothly ramp when the turbo step-down hits, but this only happens at a fixed length of time and the ramp is designed to be slow so nobody will be able to see it while it’s happening.
  • cypreus.c uses a quick ramp-up approach on moon mode, where it tries to soft-regulate the output based on battery voltage and pulse frequency.

None of these are quite what you were describing, but maybe they could give you a starting point to work from.

IIRC, the Nitecore SENS series always ramps to the level you asked it for, but it’s proprietary and uses an accelerometer instead of a button. It won’t ramp down to off, either, since it shuts off by breaking power.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

bugsy36 wrote:

guardior wrote:
If DrJones is not happy with me borrowing a few lines of code from luxdrv-0.30b and release it as PD I will happily remove those lines he/she thinks are closed source.

That question should be posed to Dr.Jones. None of us can answer that and you should NOT assume what his position is either way. If the Doc is opposed and you do not ask that just shows disrespect AND if he is not opposed you just shorted yourself and others.

I also own a graphic design and sign business. Copyright is what we have to protect us BUT there are many things that as long as we are asked we do not care. We tend to get upset when someone takes something we worked hard to produce without asking and makes a million or is worth a million and in turn makes it worthless.

Here is another phrase (I have lots of them)…..It is the fool that does not ask. And just FYI if it wasn’t for asking TK we would not have the fantastic A6 code or even Wight’s +1 7135 driver (which I do not have further info about yet)


A fool is the one talking BEFORE thinking. Silly I’ve been using open source for more than a decade and out of all code I’ve ever found on the net 99.99% has been open source or Public Domain. What DrJones has written in the beginning of luxdrv-0.30b is something like Creative Commons. CC is very very rarely used for code and is not even considered to hold up in court in most civilised countries as you usually should sign a license agreement (yeah I know almost noone reads them LOL or NDA for closed source to apply. But as I said I’ll remove lines that DrJones consider as closed source.
bugsy36
bugsy36's picture
Offline
Last seen: 1 year 5 days ago
Joined: 07/11/2014 - 18:15
Posts: 2475
Location: Florida USA

Don't take what I said the wrong way. Smile If you would like to use it why not ask?

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

guardior wrote:
So luxdrv-0.30b is basically closed source, even though the code is published in the open?! Do there exist any Public Domain driver? Star? Or possibly open source? Anyway, If DrJones is not happy with me borrowing a few lines of code from luxdrv-0.30b and release it as PD I will happily remove those lines he/she thinks are closed source.

As bugsy suggested, you’ll have to ask DrJones since no one else can speak for him and the license does not grant permission by default.

About explicitly open code, not all people who contributed code care about licenses so I’ve tried to fill in the blanks as best as I can. Here are some of the details:

  • All original flavors of STAR: JonnyC basically granted permission to do anything anyone wants with it (see STAR/README.md). This has resulted in most of the open code being based on STAR.
  • STAR derivatives: These are less clear since the parent license allows for open derivatives but does not require them to be open. I’ve done a lot of guessing based on the apparent intent of the authors, but would prefer if the licenses were more explicit.
  • My firmwares are explicitly GPLv3 licensed, except for some which I haven’t put the license on yet (but that is the plan so feel free to treat them as if they’re already explicitly open). GPL is basically “do whatever you want, as long as you re-share the code and the rights with anyone who wants them”.
  • alexvh/* : GPLv2 license
  • Tamagotchi/* uses the GPL, but I’m not totally sure its authors understand what that means and I think it only works on modded nanjg drivers.

Some others are public domain, I think, but it could take a while to verify that.

My preference is to use GPL or GPL-style licenses, since it clearly answers the licensing question for both the original project and all its derivatives, and the answer is “yes, it’s open”.

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
  • All original flavors of STAR: JonnyC basically granted permission to do anything anyone wants with it (see STAR/README.md). This has resulted in most of the open code being based on STAR.

So Star is Public Domain, I guess. Thing is, when I started learning I took luxdrv-030b because it’s so small, Star is quite big, and well commented by DrJones. It really is a good avr hello world. And should imho be put in the public domain. Smile But I’ll take a look on Star too now as the code already is public domain.
ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

guardior wrote:
I found Luxdrv-0.30b and started to modify it. … I’m not really sure about the license though?

Awesome, now it’s CC-BY-NC-SA. That’s a big improvement in terms of both permissions and clarity. Good things can come from asking. Smile
Crux
Crux's picture
Offline
Last seen: 9 months 48 min ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

pilotdog68 wrote:
I'm away for the weekend so I can't do more tests right now, but yes. I ran it off the power supply, and slowly decreased voltage from 6.5v down to 5.5v and let it run there for a couple minutes. LVP never kicked in. I put in 2 batteries, at 4v each, and within seconds it started ramping.

Just wondering whether you worked the kinks out of this. Hope you had a nice weekend!

Crux
Crux's picture
Offline
Last seen: 9 months 48 min ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

I don't know if its been tried before (let me know), but here is a way to get extremely low 'OFF state' current (parasitic current, quiescent current, sleep current, etc.). I'm talking about the current used by the driver after it has shut itself down due to Low Voltage Monitor (LVM) kicking in. (Obviously to get zero current just click the switch OFF!) Lowering this current will help protect the cell or cells when the light has been left ON and forgotten.

The amount of current used by a typical 105C driver is very small compared to the capacity of a typical cell, but remember the LVM forced a shut down because the cell is nearly dead, so there isn't a lot of capacity left to run for long before the cell voltage drops to bad levels. With some mods we can drop this current under 0.002mA (2uA). But, we need to do some rewiring and recoding... are you up for it?

To do this we need to tweak the program code, steal the use of Star3 and move the lower ADC resistor, the one going to ground (usually 4.7k in a 105C driver). One end of the resistor goes back to pin7 and the other end now goes to pin3 or Star3. The code now needs to be changed to turn Star3 into an output, and set it Low. This reconnects the resistors just as normal but also allows the ATtiny to turn this pin Off by setting it to an input when the LVM kicks in. This opens the current path through the resistors saving over 100uA. If you were using Star3 to select memory, or the like, then you'll now have something else to do in code.

I've listed some typical currents used by different circuits. These depend on battery voltage and are roughly as follows:

  • ADC resistors = 3V / (22k + 4.7k) = 112uA
    This mod reduces the ADC resistor current draw to zero.
  • OffTimeCap resistor = 3V / 470k = 6uA   This current is already zero if a resistor is not used with the OTC
    Change code to set this pin low before going to sleep, no need to keep the cap charged when "OFF".
  • ATtiny13A = 2uA   Assuming Power Down Sleep mode with ADC off
    Can't get much below 2uA...
  • Zener Mods = 6V(batt) - 5V(zener) / 200ohm = 5000uA    Changes with different resistor
    IMHO multi-cell lights should be done with low current LDO regulators (like TPS71550) rather than zeners. But I understand completely that these mods work perfectly well, they're just not as low current as a regulator. TPS71550 draws 3uA. My latest 2 cell driver now sleeps at less then 5uA.

Edit: This mod is not recommended for multi-cell setups as the voltage on the ADC pin will rise above the MCU supply voltage. This may/will draw current, and defeat the purpose of this mod. My 2 cell mod seems to work probably because the LVP point is very close to the MCU supply voltage.

I'm a hardware guy, so I don't feel comfortable telling you how to tweak the code in your particular driver to do these changes. (I had trouble trying to program a pin to be an input...) enough said. These are the changes I made to ToyKeeper's TK_OTC.c, it's nothing special even an old hardware guy can figure it out! Thanks TK! Smile

#define STAR3_PIN   PB4        // Low end of ADC voltage divider resistors
#define STAR3_DIDR  ADC2D   // Digital input disable bit corresponding with PB4

Added this to ADC_on()
    DIDR0 |= (1 << STAR3_DIDR);                         // disable digital input on STAR3 pin to reduce power consumption
    DDRB  |= (1 << STAR3_PIN);                          // Set to Output
    PORTB &= ~(1 << STAR3_PIN);                         // Pull low end of Voltage divider to ground
    DDRB  &= ~(1 << STAR3_PIN);                          // Set to Input (without pull-up) oops

Added this to ADC_off()
    DDRB  &= ~(1 << STAR3_PIN);                          // Set to Input (without pull-up)

Added this just before Set_Sleep_Mode
                    ADC_off();                     //ADC off
                    PORTB &= ~(1 << CAP_PIN);    // Drive Cap_pin Low

cajampa
Offline
Last seen: 2 years 3 months ago
Joined: 08/01/2014 - 01:55
Posts: 1963
Location: Sweden

Cool Smile more dummy prof protection is always welcome, when you want to give lithium lights to less hyper aware individual.

Does this work on all attiny13a drivers & not only on “typical 105C driver”
like the fet+7135 driver for example because that one don’t have any “stars” or am i missing something vital here?

Crux
Crux's picture
Offline
Last seen: 9 months 48 min ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

cajampa wrote:
...Does this work on all attiny13a drivers & not only on "typical 105C driver" like the fet+7135 driver for example because that one don't have any "stars"...

I think this can be adapted to any 13A driver because typically pin3 (Star3) is unused. Unfortunately, that pin is not in a convenient location to make this mod easy (but where is the fun in easy?). Even E-switch drivers can benefit from this mod. In fact they would have the most to gain because they are always drawing some current. But I don't have any to test this out on... Likewise, any driver using any micro-controller should be able to adapt this technique to reduce current.

viperbart
viperbart's picture
Offline
Last seen: 5 months 1 week ago
Joined: 07/22/2014 - 15:17
Posts: 444
Location: Toronto ON CA

Somewhat off topic… Does 112uA = +/-1A per year? So a typical 3000mAh 18650 would drain a third of its capacity in a year with a 112uA parasitic drain?

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

ToyKeeper wrote:
guardior wrote:
I found Luxdrv-0.30b and started to modify it. … I’m not really sure about the license though?

Awesome, now it’s CC-BY-NC-SA. That’s a big improvement in terms of both permissions and clarity. Good things can come from asking. Smile

You are joking right?! As I said before CC shouldn’t be used for software and even CC itself has it in its faq:

https://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_...

Quote:
We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses made available by the Free Software Foundation or listed as “open source” by the Open Source Initiative.

Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. Many software licenses also address patent rights, which are important to software but may not be applicable to other copyrightable works. Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses.

Our licenses are currently not compatible with the GPL, though the CC0 Public Domain Dedication is GPL-compatible and acceptable for software. For details, see the relevant CC0 FAQ entry. We are looking into compatibility of BY-SA with GPL in the future; see the license compatibility page for more information.)

While we recommend against using a CC license on software itself, CC licenses may be used for software documentation, as well as for separate artistic elements such as game art or music. “

Anyway, to sum it up. Tido use GPLv2 for BLF-VLD and JonnyC use Public Domain for Star. And then you use GPLv3 for blf-a6. Those are the ones that you can safely use then.

Joat
Offline
Last seen: 3 months 4 days ago
Joined: 06/13/2013 - 23:43
Posts: 521
Location: Minnesota

With CC-BY-NC-SA, you should be safe to use the code for your own use, and to publish modifications you make of it, as long as it’s under the same license and you give credit to DrJones. Selling a light with a version of that software is likely not allowed, and as a guess no selling of it is DrJones intent. I don’t know of a software license that allows that sort of use, CC-BY-NC-SA does.

DavidEF
DavidEF's picture
Offline
Last seen: 1 hour 4 min ago
Joined: 06/05/2014 - 06:00
Posts: 6161
Location: Salisbury, North Carolina, USA
Joat wrote:
With CC-BY-NC-SA, you should be safe to use the code for your own use, and to publish modifications you make of it, as long as it’s under the same license and you give credit to DrJones. Selling a light with a version of that software is likely not allowed, and as a guess no selling of it is DrJones intent. I don’t know of a software license that allows that sort of use, CC-BY-NC-SA does.

From some random page I pulled up with a quick Google search:

Quote:
The GPLv3 allows others to copy, distribute and modify the software as long as they state what has been changed when, and ensure that any modifications are also licensed under the GPL. Software incorporating (via compiler) GPL-licensed code must also be made also available under the GPLv3 along with build & install instructions.

AFAIK the GPL also allows commercial distribution, and doesn’t specifically require attribution. TK can tell us, as she works with this stuff all the time. But, I doubt those things would be hard to add if they were important to you. I think the GPL does require re-distributors provide a link to the unmodified original code, though. That would probably count as attribution. Like I said, ask TK.

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Crux
Crux's picture
Offline
Last seen: 9 months 48 min ago
Joined: 05/03/2011 - 16:27
Posts: 227
Location: Northcoast, Ohio, USA

viperbart wrote:
Somewhat off topic... Does 112uA = +/-1A per year? So a typical 3000mAh 18650 would drain a third of its capacity in a year with a 112uA parasitic drain?

Well yes, your math is correct (if you ignore self discharge), but why would the light will be in LVP mode if the cell has a full charge? Undecided

This mod helps protect the cell once it is depleted. At that point there is very little reserve capacity to feed that 112uA drain. Dropping that current to 2uA gives you 50X more time to realize that you left the switch ON. Is this a solution to all the world's problems? No, but it is a small step in the right direction.

ToyKeeper
ToyKeeper's picture
Online
Last seen: 11 min 12 sec ago
Joined: 01/12/2013 - 14:40
Posts: 7929
Location: (469219) 2016 HO3

DavidEF wrote:
I think the GPL does require re-distributors provide a link to the unmodified original code, though. That would probably count as attribution. Like I said, ask TK.

The GPL requires re-distributors to provide the source code for whatever they are distributing. If they modified it, they need to include their modified version. If it’s unmodified, they should include the original version. Aside from just guaranteeing that everyone can use and mod it, it is also intended to make sure that people share the improvements they make.

This can be inconvenient for vendors though. It would mean, for example, that if RMM sold drivers with the BLF-A6 firmware, he would need to include a link to (or copy of) the BLF-A6 source code or at least provide it to anyone who asked for it. With the public-domain(ish) STAR firmware, he doesn’t need to do this.

Some people prefer BSD-style licenses, which make virtually no demands on anyone. One can modify BSD-licensed code and sell products using it with no need to share their code or improvements. In fact, this is where much of Microsoft’s code came from; it’s based on old BSD code. There is an ancient and ongoing debate about whether “share” or “share and share alike” is more “free”.

Regardless, I’m happy about contributions people share under any open license. You’re helping people you may never even know about. Smile

guardior
Offline
Last seen: 3 years 3 months ago
Joined: 04/06/2015 - 14:06
Posts: 129
Location: Sweden

A few noob questions, what does this line do?

#define F_CPU 4800000 // CPU: 4.8MHz PWM: 9.4kHz ####### use low fuse: 0×75 #######

And these two?

#define pwminit() do{ TCCR0A=0b00100001; TCCR0B=0b00000001; }while(0 ) //chan A, phasePWM, clk/1 ->2.35kHz@1.2MHz
// #define pwminit() do{ TCCR0A=0b00100011; TCCR0B=0b00000001; }while(0 ) //fastPWM

The two last ones look like two different ways of running pwm. And the first one seems to be somehow related.

Edit: And this one?

#define PWM OCR0B

Pages