Flashlight Firmware Repository

I suppose I hadn’t considered the need to hand-tune ramps. I’ve been replacing table generation scripts with compile-time generation and it seemed like the ramp would be a good candidate for that. An abstract perceptual-to-linear interface would also make it easier to do things like interpolate between ramp values for smoother ramps on small firmware.

But not if they need handed-tuned!

Yeah, I was in a bit of a hurry with that, so I decided pm to you :slight_smile: You don’t come here often, do you? Anyway, thank you for your help.

Yes, but my D4V2s arrived yesterday, the Reflashing kit is still on its way. The firmware revision on my D4V2s is <= 450. The temperature target is set to 45 °C and the temperature sensor is properly calibrated.

Measurement results:

I think the problem is that 7135 heats up driver and attiny85 measuring bogus temperature. Why just not turn off 7135 in high modes? After 350mA there is no stabilization anyway.

The opposite seems to be the case. The temperature sensor lags behind massively.

See: Flashlight Firmware Repository - #2160 by 0-8-15_User

A branch with a much improved strobe mode (D4v2 only). It can “freeze” a motor that’s spinning at 20000 RPM, just like a professional strobe!

https://code.launchpad.net/~i-dan-3/flashlight-firmware/pwm-strobe


Added accurate 16-bit PWM strobe modes

Disabled by default. Only supported on CPUs having a 16-bit PWM, which means only attiny1634, which means only Emisar D4v2 and D4Sv2. I don’t have a D4Sv2 to test, so currently it’s only implemented on D4v2. The relevant functions could probably be directly copied from hwdef-Emisar_D4v2.h to hwdef-Emisar_D4Sv2.h.

Strobe rate can be continuously varied from 1Hz to 500Hz. Theoretically it could run faster, but this is already enough to freeze something that’s spinning at 30000 RPM. Uses full brightness (1x7135 plus FET) with a 1:256 duty cycle (party strobe) or 1:4 duty cycle (tactical strobe). Rate adjustment has acceleration, going twice as fast after 1 second and 4x as fast after 2 seconds. It still takes about 10 seconds to traverse the whole range from 1Hz to 500Hz.

With this I was able to freeze my Proxon drill (similar to Dremel) running at 20000 RPM. Unfortunately the flash rate fluctuates by about 0.1%, probably due to the CPU’s RC oscillator.

Anduril have no indicator led LVP ? Aux leds maybe off, but indicator led keeps shining until battery kaputt :wink:

Maybe this line have to be fixed?

#if defined(USE_INDICATOR_LED) && defined(TICK_DURING_STANDBY)
// beacon-like mode for the indicator LED
void indicator_blink(uint8_t arg) {
// turn off aux LEDs when battery is empty
if (voltage < VOLTAGE_LOW) { indicator_led(0); return; }

In blinking mode LPV works , but in low or high modes not at all.

No, I believe it’s this place:

// TODO: turn off aux LED (s) when power is really low

if (0) {} // placeholder

So…it seems simply unimplemented yet
You may try adding

// turn off any aux LED (s) when power is really low
#if defined(USE_INDICATOR_LED)
indicator_led(0);
#endif
#if defined(USE_AUX_RGB_LEDS)
rgb_led_set(0);
#endif
#ifdef USE_BUTTON_LED
button_led_set(0);
#endif

before the placeholder.

EDIT: upgraded the code
ADDED: Note that if the flashlight is on it will turned off when LVP fires. It needs to be checked whether turning it off won’t turn the aux LEDs back on.

Thanks, but i dont know how to do it, im not a coder.

Yes, and in an ideal world the ADC post-processing (averaging and decimation) would be separate from the rest of the code.

Edit: An obvious change would be to oversample the ADC readings instead of skipping three out of four ticks

Sensor lag time test results (all lights were programmed to shut off at 50 °C):



I managed to record the temperature reading of the internal sensor, this will help a lot for the further development of the ADC conversion code:

I think the aux leds do not need many amps. It can run on months with fresh batteries. So it would lasts a long time till the batterie is dead.
Many Aux-LEDs will turn off on low battery. This is implemented in some Aux-Boards from Lexel, such as MF01S or MF01 Mini or some Fireflies Flashlights.
Whithout this behaviour the LEDs will turn off because of the too low Voltage. This means they will use much less amps than with full battery.

But as Agro, it can be implemented to be on the safe side.
Otherwise the Low Battery-Indication on a MF01S or MF01 may not work as implemented, if the driver switches the aux-board off.

Fantastic! Via debugWIRE? I wonder how you managed to get the cables to the outside. Through the hole of the switch?

I insert short blips with a duration of the current temperature value and capture them with my luxmeter:

Awesome setup!

Indeed :slight_smile:

Not the red ones

Code is ready for review: https://bazaar.launchpad.net/~pakutrai/flashlight-firmware/fsm/revision/465

Link to the pull request: Merge into fsm : fsm : Code : Flashlight Firmware Repository

Hello

I have the same problem, that I cannot clone the repository.
I use the Bazaar Explorer.

What do I have to enter in “open url”:
this does not work for me: lp:~toykeeper/flashlight-firmware/fsm
I get the same errors as shown by Lexel’ screenshot.

Did you click the button with the green arrow on the left? The one that says “Quelldateien des Projektes von einem anderen Ort beziehen”? The buttons with the blue icons are probably meant to open local and not remote projects.

“lp:~toykeeper/flashlight-firmware/fsm” is the correct URL.