STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

BGA...man I would actually have to start being careful with my reflows!  Sealed  

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

I would imagine those tiny pins are a little harder to flash after soldering, too. Can they even be flashed once they’re stuck to a PCB?

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

ToyKeeper wrote:
I would imagine those tiny pins are a little harder to flash after soldering, too. Can they even be flashed once they're stuck to a PCB?

You would have to have header pins or something, which would destroy any size advantage.  You would have to pull it off and reflow to reflash without headers on the board.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

fellfromtree
fellfromtree's picture
Offline
Last seen: 6 years 8 months ago
Joined: 07/25/2014 - 15:14
Posts: 470
Location: spelunking

That ATtiny24a looks like it would work.. Pins 5-8

http://www.digikey.com/product-detail/en/ATTINY24A-SSUR/ATTINY24A-SSURCT-ND/2774343

$1.45ea.. Not too bad but 14 pins you might as well run two 13a! The 20 pin QFN might be small enough to do what I need

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

fellfromtree wrote:

That ATtiny24a looks like it would work.. Pins 5-8

http://www.digikey.com/product-detail/en/ATTINY24A-SSUR/ATTINY24A-SSURCT-ND/2774343

$1.45ea.. Not too bad but 14 pins you might as well run two 13a!

You understand why running two 13a’s in order to control one light is an undesireable thing, right? I can’t tell if you’re joking or not! :~

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

I think he was simply referring to the size of the MCU...it was supposed to be a joke. 

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

fellfromtree
fellfromtree's picture
Offline
Last seen: 6 years 8 months ago
Joined: 07/25/2014 - 15:14
Posts: 470
Location: spelunking

hehe well edited the 20 qfn might work.. I still dunno the size until bust out my mm ruler though..

EDIT
What if I just set the buck to high (it has memory). Disconnect the eswitch wire from it’s mcu. Now I have voltage monitoring already setup in the bucks stock driver. Now use the bucks mcu vcc to power the tiny24a also (not sure if that’s too much of a load on that circuit, otherwise I’d zener to B+). So I ‘d run the LED+ on the buck to the emitters +.

On the LED – (4 sets of gnd on that 4 color XML) coming from the emitter, those would go to 4 fets pwm controlled by the 24a. When the voltage gets low the buck would simply flash and eventually go out on it’s own.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

RMM wrote:

ToyKeeper wrote:
I would imagine those tiny pins are a little harder to flash after soldering, too. Can they even be flashed once they’re stuck to a PCB?

You would have to have header pins or something, which would destroy any size advantage.  You would have to pull it off and reflow to reflash without headers on the board.

.. and you wouldn’t want to do that, as I understand it. A BGA is a one-shot deal unless you “reball” it. It comes with balls of solder stuck to the bottom, once they’re used up the solder must be removed and replaced with new balls. It’s a pain and there’s gear available to make it easier, commonly used in refurbishing electronics like phones, computers, and game consoles.

If you just want to be able to reprogram the chip then the lack of exposed pins is not a big deal. If you want to make it a weekly practice to reprogram the chip, yes, I imagine it would be a pain. We normally break out some pins as inputs, outputs, etc. ISP flashing (what we do) only requires 4 pins in addition to VCC & GND. I’m glancing at the Atmega-88PA for reference and in that case MISO and MOSI are both on PWM pins, so no problem there – we’ll want to break those out anyway, right? SCK is on PB5, an outside row pin with no peripherals. Reset is on PC6, another outside row pin. PB5 can be used as a star or whatever, PC6 would have to have a dedicated, unused pad I think. So not that bad IMO. For development purposes you can either use a larger PCB with an actual ISP header if desired.

Another option for programming may be to use a properly setup bootloader (eg no delay at boot, it would look for a condition before going into bootloader mode). You’d need an extra PCB with some support components (caps, I think) and you’d need VCC, GND, and 2 data pins broken out. http://www.obdev.at/products/vusb/index.html Some frequency stuff would also have to get worked out for a V-USB based bootloader.

IMO the bootloader business is pretty ambitious – I’m not suggesting that anyone work on it! I’m only mentioning it so that everyone knows this stuff exists.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

fellfromtree wrote:
hehe well edited the 20 qfn might work.. I still dunno the size until bust out my mm ruler though
It’s pretty small, smaller than the ATtiny13A-SSU’s package (what we use now). Wiring it up is different though, so it would require new PCB designs.
RMM wrote:

I think he was simply referring to the size of the MCU…it was supposed to be a joke. 

I’d have assumed it was a joke, but this isn’t the first post where fellfromtree mentioned using multiple MCUs to get enough PWM. I didn’t feel like writing out why it’s undesirable if it’s a joke.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

wight wrote:
fellfromtree wrote:
hehe well edited the 20 qfn might work.. I still dunno the size until bust out my mm ruler though
It's pretty small, smaller than the ATtiny13A-SSU's package (what we use now). Wiring it up is different though, so it would require new PCB designs.
RMM wrote:

I think he was simply referring to the size of the MCU...it was supposed to be a joke. 

I'd have assumed it was a joke, but this isn't the first post where fellfromtree mentioned using multiple MCUs to get enough PWM. I didn't feel like writing out why it's undesirable if it's a joke.

Gotcha. I was wondering if you had lost your sense of sarcasm. Wink

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

wight wrote:
.. and you wouldn’t want to do that, as I understand it. A BGA is a one-shot deal unless you “reball” it.

If you just want to be able to reprogram the chip then the lack of exposed pins is not a big deal. If you want to make it a weekly practice to reprogram the chip, yes, I imagine it would be a pain. We normally break out some pins …

Thanks, that’s a good summary.

I’m definitely a software person, not so much a hardware person… I enjoy doing the firmware-of-the-week thing (though, for convenience, development happens on a dedicated dev board). I like how it’s pretty standard these days to use big enough pins to easily reflash production hardware. More / smaller pins would significantly raise the barrier to entry for this hobby.

That’s why I like the idea of the attiny25. Same convenient size and interface, but more space and features to play with. Can even be used on existing boards in place of the tiny13. Or, for something with more I/O, the attiny84a-ssu might be nice… like, for a RGBW+ driver.

JonnyC
JonnyC's picture
Offline
Last seen: 3 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

On second thought, maybe discussions like the ones above should be discussed somewhere else?  Maybe this thread should be a discussion about single emitter lights and what variations of UI's people have come up with using STAR as a starting point, along with what new features can be added to make it even more useful.

I know there are other threads about multiple emitter (RGB) lights using the PIC.  Maybe one can be created if people want to attempt to use an AVR instead.  I for one won't be delving into that area, too complex for my tastes.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

RMM wrote:
Gotcha. I was wondering if you had lost your sense of sarcasm. Wink
If I lost what little capacity I have for parsing sarcasm we’d be in pretty sad shape. Wink
ToyKeeper wrote:
Thanks, that’s a good summary.

I’m definitely a software person, not so much a hardware person… I enjoy doing the firmware-of-the-week thing (though, for convenience, development happens on a dedicated dev board). I like how it’s pretty standard these days to use big enough pins to easily reflash production hardware. More / smaller pins would significantly raise the barrier to entry for this hobby.

That’s why I like the idea of the attiny25. Same convenient size and interface, but more space and features to play with. Can even be used on existing boards in place of the tiny13. Or, for something with more I/O, the attiny84a-ssu might be nice… like, for a RGBW+ driver.

I agree that the ATtiny25 is a logical next step for these drivers. I also think that arbitrarily switching to a no-leads package for these drivers is most likely to unjustifiably raise the barrier to entry. We have enough documentation / training and specialty hardware issues as it is. If someone brings a design to the table which can’t be done without a QFP or BGA package that’s a little different – but we can burn that bridge when we get there ;).
JonnyC wrote:

On second thought, maybe discussions like the ones above should be discussed somewhere else?  Maybe this thread should be a discussion about single emitter lights and what variations of UI’s people have come up with using STAR as a starting point, along with what new features can be added to make it even more useful.

I know there are other threads about multiple emitter (RGB) lights using the PIC.  Maybe one can be created if people want to attempt to use an AVR instead.  I for one won’t be delving into that area, too complex for my tastes.

I also have no immediate plans to build an RGB driver. Keeping the thread primarily on the topic of STAR based firmwares seems smart.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

JonnyC
JonnyC's picture
Offline
Last seen: 3 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

wight wrote:
I agree that the ATtiny25 is a logical next step for these drivers.

I agree as well.  I'm attempting to write a forked version of STAR_momentary for RMM where it can monitor temperature via a voltage source from a temp sensor along with the existing battery voltage monitoring, then adjust output up and down according to defined temp thresholds.  This requires jumping back and forth between ADC inputs, and it's not working very well right now (broken more accurately).  On our list is to port the program to the ATtiny25, so that might happen sooner rather than later because I could really use a second timer so temp ramp up/down timing doesn't have to be squished into the WDT ISR (which has very inaccurate timing).

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

JonnyC wrote:

wight wrote:
I agree that the ATtiny25 is a logical next step for these drivers.

I agree as well.  I’m attempting to write a forked version of STAR_momentary for RMM where it can monitor temperature via a voltage source from a temp sensor along with the existing battery voltage monitoring, then adjust output up and down according to defined temp thresholds.  This requires jumping back and forth between ADC inputs, and it’s not working very well right now (broken more accurately).  On our list is to port the program to the ATtiny25, so that might happen sooner rather than later because I could really use a second timer so temp ramp up/down timing doesn’t have to be squished into the WDT ISR (which has very inaccurate timing).

Do you have any inking as to what the problem is? (I will understand if it’s one of those situations where you say “if I knew what was wrong I’d have fixed it by now”)

I’ve been desirous of exactly the setup you describe. Having both measurements would open doors.

If we were truly constrained to the ATtiny13A here is what I’d suggest: Apparently there exist products called “Low Voltage Detectors” which provide a binary output, see post #6 here. I think combining the appropriate one of those with an analog temp sensor could provide an easy binary “overtemp or not” input. I would not be surprised to learn that a product which combines those two things in the same package was already available.

That said, let’s not do that. It’s way more flexible to have an analog temp input.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

JonnyC
JonnyC's picture
Offline
Last seen: 3 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Actually the input that RMM was able to provide in his setup is good (honestly I didn't even know how he did it, I'm totally ignorant of circuits).  We are still using the internal 1.1v reference to compare against.  All I'm doing is switching the ADC input on each WDT tick, and keeping separate variables for the results of battery voltage and temp voltage ADC checks.  It actually works fine, but then we attempted to change the number of ticks between temp voltage checks from 500 to 2000 (10 seconds to 40 or so) and it breaks.  If I disable the battery voltage check it works just fine, which means we aren't switching ADC inputs.  My suspicion is that I am going about the ADC switching and checking all wrong, so I'll go back to the datasheet.

I'm going to do some more testing tonight, and if I'm still stumped I'll post up a specific question here, or just give up and start porting it for the 25.

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

You can see the latest code here:  https://github.com/JCapSolutions/blf-firmware/tree/master/MTN_momentary_...

The only changes I've made to this is to changed the adc_temp_ticks to a 16 bit variable, and extend the time out.  The momentary feature is commented out in my build, as well as the turbo timer.  

Like Jon said, it all works, even with a 16 bit variable, until the temp ticks gets too long during the second temperature ramp down.  I am feeding the adc with a temperature sensor through another voltage divider so I can use the 1.1V internal reference voltage to compare the temperature sensor against.  

Initially I was just using the primary ADC voltage monitoring as a temperature step down, which worked alright, but then I got power hungry and wanted both to work at the same time!  Tongue Out 

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

JonnyC
JonnyC's picture
Offline
Last seen: 3 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

So I think I have it working now.  I just went about switching and polling ADC inputs poorly.  If anyone else wants to give it a shot it's here...

https://github.com/JCapSolutions/blf-firmware/tree/master/MTN_momentary_temp

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6422
Location: Held against my will in IOWA, USA

Sorry to break the train of thought here…

How much work would it be to almost completely change the UI of the momentary firmware? I am a fast learner (and have already learned alot in this thread), but have very little experience in this kind of thing.

I’m hoping to achieve something like this:

4 modes: Low ≤1%, Medium 20%, High 60%, Turbo 100%
90 sec Turbo timer down to High
Low voltage step-down
No mode memory

UI:
From off:
short click ( long press (>750ms) = power on high
press&hold 3sec = short pulse at medium then “locked out” (3 short clicks from “locked” goes to low)

From on:
short click = advance to next mode (cycling L-M-H-T-L-M-H-T, with ‘off’ not in the rotation)
Long press = off

Thanks in advance

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

pilotdog68 wrote:
Sorry to break the train of thought here…
[snip]
From off:
short click ( long press (>750ms) = power on high
press&hold 3sec = short pulse at medium then “locked out” (3 short clicks from “locked” goes to low)
[snip]
Doesn’t sound too bad to implement. I’m assuming you actually want long press while off = turbo, that seems much more sensible to me and is easier to handle I think based on what we already have.
  • Change the long press action while on. (add a conditional to the “//not pressed” else section like this: if mode_idx != 0 {mode_idx = 0;}). You can’t just shove that behavior into prev_mode() because prev_mode() is used for low battery stepdown.
  • Change the looping behavior to skip the first mode (off) when you advance modes. You can look at the code for prev_mode() in order to figure out the logic for this behavior, it’s simple. (you’ll be implementing that logic in next_mode() of course!) Sorry, I made it more complex than it needed to be. Change the behavior of next_mode() so that the //Wrap around section reads “mode_idx = 1;”, duh!
  • oh, as I snipped your quote I see that I ignored the “lock out” portion of your UI. Right now I’m not sure I like the idea… what is the goal?

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 months 1 week ago
Joined: 05/30/2013 - 23:31
Posts: 6422
Location: Held against my will in IOWA, USA

I would prefer the long press go to high instead of turbo, but if turbo is considerably easier to implement, I can make that trade-off.

I want to use this in an EDC side-switch light, so the lock-out would keep the light from turning on in my pocket. Alternatively, if I sat on the button in my pocket, it would turn on to high/turbo. With the lockout, sitting on it would either lock itself out, or simply remain locked until a successive 3 clicks.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Changing the UI can be simple or very complicated, depending on the details. If you’re interesting in programming, I suggest diving right into the code and changing it to your heart’s desire, since it can be a fun exercise.

Whenever I can get a couple hours, I’m planning to implement this UI for e-switch lights (using STAR-momentary as a base):

From Off:

  • Long press (~1/3rd second) press to moon
  • Quick click to last mode used
  • Double click to Turbo (or highest mode)
  • If there’s room, longer press to toggle lock

From On:

  • Quick click to Off
  • Press and hold to cycle through modes. (~1/3 second pause at each mode). Release to select mode.
  • Double click to beacon

… and hopefully with the red/green Ferrero Rocher indicator lights still working, or a compile-time option to add a battery check mode somewhere if those indicators aren’t available.

It might take a while to get it all to fit.

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

pilotdog68 wrote:
I would prefer the long press go to high instead of turbo, but if turbo is considerably easier to implement, I can make that trade-off.

I want to use this in an EDC side-switch light, so the lock-out would keep the light from turning on in my pocket. Alternatively, if I sat on the button in my pocket, it would turn on to high/turbo. With the lockout, sitting on it would either lock itself out, or simply remain locked until a successive 3 clicks.

Definitely easiest to go directly to Turbo (highest mode). [Also, my opinion is that from off a long press and a short press in order to get into turbo would be a very strange UI decision.] The software lockout you want is more work. I currently use physical lockout for anything I don’t want to turn on by accident. AFAIK making the two changes I described above should cover your entire desired UI – other than lockout and the fact that a long press takes you to turbo.
ToyKeeper wrote:
Changing the UI can be simple or very complicated, depending on the details. If you’re interesting in programming, I suggest diving right into the code and changing it to your heart’s desire, since it can be a fun exercise.

Whenever I can get a couple hours, I’m planning to implement this UI for e-switch lights (using STAR-momentary as a base):

From Off:

  • Long press (~1/3rd second) press to moon
  • Quick click to last mode used
  • Double click to Turbo (or highest mode)
  • If there’s room, longer press to toggle lock

From On:

  • Quick click to Off
  • Press and hold to cycle through modes. (~1/3 second pause at each mode). Release to select mode.
  • Double click to beacon

… and hopefully with the red/green Ferrero Rocher indicator lights still working, or a compile-time option to add a battery check mode somewhere if those indicators aren’t available.

It might take a while to get it all to fit.

In the UI you describe a person would be able to enable / disable software lockout only while the light is off? Just looking to improve my understanding of what you’ve described.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

wight
Offline
Last seen: 1 year 4 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

JonnyC wrote:

So I think I have it working now.  I just went about switching and polling ADC inputs poorly.  If anyone else wants to give it a shot it’s here…

https://github.com/JCapSolutions/blf-firmware/tree/master/MTN_momentary_temp

May I ask what you guys are using as a temp sensor? Is it the LM45 like Microa is using, a thermistor, or some other thing? I think I want to board this train. Wink

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

JonnyC
JonnyC's picture
Offline
Last seen: 3 months 1 week ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

wight wrote:
JonnyC wrote:

So I think I have it working now.  I just went about switching and polling ADC inputs poorly.  If anyone else wants to give it a shot it's here...

https://github.com/JCapSolutions/blf-firmware/tree/master/MTN_momentary_temp

May I ask what you guys are using as a temp sensor? Is it the LM45 like Microa is using, a thermistor, or some other thing? I think I want to board this train. ;-)

Here's what Richard emailed me a little while back...

Quote:
Microchip MCP9700 Sensor | TO-92 Package | 2.3v-5.5v input | 6 uA supply current | ~$0.25 each
 
Temperature calculation for 75C target temperature.
MCP9700 is as follows:  0.5V + (N*0.01V) so (0.5+(75*0.01))=1.25V output
 
Voltage divider resistors I chose were R2: 36000 and R1: 19100
 
(1.25V * 36000 * 255) / ((19100+36000)*1.1) = ~189 (8 bit ADC value)

When you are checking with your multimeter on the input pin, you are looking for the voltage of approximately 0.814V.  
 
189/255=0.74  
1.1*0.74=0.814

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

ToyKeeper wrote:
Whenever I can get a couple hours, I’m planning to implement this UI for e-switch lights (using STAR-momentary as a base)…

As it turns out, I had a bit of time tonight.

What I’ve implemented so far:

From Off:

  • Long press (~1/3rd second) to moon
  • Short click to last mode used
  • Double click to highest mode
  • Longer press to toggle soft lock-out (~3 seconds). On unlock, it will return to the last mode used before activating lock.

From On:

  • Quick click to Off
  • Press and hold to cycle in low-to-high order through modes (except moon). (~1/2 second pause at each mode). Release to select mode.

The red/green Ferrero Rocher indicator lights work for real-time voltage readout. Turbo step-down works if enabled. I think low-battery stepdown works too, but I haven’t checked yet.

What I haven’t implemented yet:

  • Double-click while on to enter beacon mode (or strobe or something).
  • Battery check mode (for lights without the red/green indicators), and the ability to turn off indicator support.
  • Fast PWM modes, and PWM=0 support. (currently uses only phase-correct)
  • General code cleanup.

The code (and a precompiled version) are available here: (Baton.c, Baton.hex)
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

I should note that it’s built with the moon mode set to PWM=1, so it requires a pretty high-powered light for that to work. A FET or lots and lots of 7135 chips. For anything else, you’ll need to adjust the PWM levels for each mode and recompile.

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

ToyKeeper wrote:
A FET or lots and lots of 7135 chips. For anything else, you'll need to adjust the PWM levels for each mode and recompile.

In my experience more 7135 chips takes a higher PWM level to turn on than less chips.  Has your experience been different?  

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

I haven’t tried nearly as many hardware configs as RMM, but I’ve found that 2-8×7135 chips on a nanjg/qlite driver will light up at around PWM=6, while 32×7135 chips on a BLF-SRK driver will light up at PWM=1 (or even PWM=0 in fast mode).

It might not be the number of chips, but rather the design of the driver. I don’t know.

In any case, I haven’t seen a FET which won’t light up at PWM=1, though the output gets really dim at low voltage.

RMM
RMM's picture
Offline
Last seen: 1 year 5 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

Are you using the 350mA or the 380mA chips on the SRK?  The 350s with the rounded tab like you get from FT light up with a lower PWM number than the 380mA "38A" or equivalent chips do.  The difference is pronounced enough that I have two different files for the 32x 7135 drivers depending on which binned 7135s are used. 

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 weeks 3 days ago
Joined: 01/12/2013 - 14:40
Posts: 10655
Location: (469219) 2016 HO3

Ah, I’m mostly using the 350mA model. It looks like the 380mA chips might give me a nicer moon mode though. I think ~0.2lm is the sweet spot for a moon mode.

I have data about these:

  • 32×350mA: ~1 lm at PWM=1 (phase-correct) (3xXM-L2)
  • 2×350mA: ~0.7 lm at PWM=6 (fast) (red XP-E2)
  • 4×350mA: ~0.5 lm at PWM=4 (phase-correct) (XP-G2)
  • 5×380mA: ~0.2 lm at PWM=6 (fast) (Nichia 219B)
  • 8×350mA: ?? lm at PWM=9 (fast) (old XM-L T6)

I had no idea the 7135 bin would have this effect, but I like the lower moon mode on the 380mA chips.

Also, old XM-L emitters need a significantly higher PWM level in order to light up. Not sure what the actual output is though, since I took that light apart before measuring it.

Pages