Strange Sofirn SP36 Pro behavior

I got a Sofirn SP36 Pro a few days ago and overall I really like it. But I’ve noticed one strange behavior that I’m trying to understand.

Every now and then, when I turn it on with one click, the switch lights up but the emitters don’t light up. However, I can use any other mode (strobe, utility, top of ramp, turbo, etc.) just fine. When it exhibits this behavior, the fix is to hold down the switch to start ramping and then it’s fine until the next time the problem happens. I haven’t been able to determine exactly what triggers the issue, but it seems like it might happen after certain operations in utility and/or strobe mode.

I don’t know what’s causing it, but I’ve come up with a list of what’s probably NOT causing it:

  • It’s probably NOT a problem with the switch. If it were, the switch wouldn’t light up.
  • It’s probably NOT a problem with the emitters, because I can double-click to turn on at top of ramp and it comes on. Then I turn off with one click and turn it back on. Emitters are still off until I hold the button to start ramping.
  • It’s probably NOT a misunderstanding between automatic memory and manual memory. It’s set for automatic memory, no doubt.
  • It’s probably NOT an incorrect user operation because “zero brightness” isn’t a valid memory value so there should be no way to store “zero brightness” in memory.
  • It’s probably NOT corruption of the area of memory where brightness is stored because if I had the light at a dim brightness, the switch lights up dimly, but if I had the light at a high brightness the switch lights up brightly. This seems to indicate that the memory is intact but isn’t being properly applied to the emitters.

Has anyone else seen this behavior with the SP 36 Pro? It seems like it could be a firmware bug but I would have expected someone else to report it by now since I’ve already seen it happen 3 times in 3 days. I guess it could be a manufacturing defect but it acts much more like a bug than a defect. Any thoughts?

Do a “factory reset”.

Unscrew, hold the sideswitch, rescrew, wait for the fizzle. You’ll know it when you see it.

I did a factory reset after the first time I saw the issue. I know it worked because I saw the fizzle and also confirmed that all settings were reset (for example I set the switch LED to stay off when the light is off, and it came back on after the reset). The issue has happened 2 times after the factory reset.

Bugger. No flicker or anything to suggest an intermittent connection to the LEDs?

Naw, that wouldn’t explain it “working” in other modes.

Had a TK05 that worked (dim, bright, strobe, whatever), but at 1/100th the brightness. Pressing down on the LED (!) would let it work fine. Was an intermittent connection that somehow did… that. Fiik.

No flicker at all. My first thought was a hardware issue (loose connection), but once the light gets into this “zero brightness” state, I can do the following:

One click = switch LED on, but emitters not on at all
Two clicks from off = switch LED on, emitters on at top of ramp with no flicker
Two clicks from on = emitters on turbo with no flicker

I can repeat those things over and over, until I hold down the switch which turns the emitters on and starts ramping the brightness. Since it works perfectly in top-of-ramp and turbo I don’t think it’s a connection problem.

It’s almost acting like the automatic memory has stored 0 as the brightness level, except for the fact that as I recall, the switch LED brightness reflects the last-used brightness of the emitters. Meaning if I had it on dim before this happened the switch LED is dim, and if I had it on bright before this happened, the switch LED is bright.

I haven’t been able to figure out how to get it into this “zero brightness” state yet, but as I recall, every time it’s been after I was doing something in utility or strobe mode. Now that I know it’s a recurring issue I’m going to try to find a repeatable sequence to make it happen. I suppose there’s still a small chance of it being a defect in this particular unit but the way it acts just seems like a bug to me. I’ve done some development for AVR and PIC so if I get curious enough I’ll dig through the Anduril source code for this model and try to understand what’s going on, but I’m hoping someone else has more information about this issue and can save me from doing that.

If it goes to “0 brightness” and you start ramping up, does it start from 0, or from the last-used brightness?

Last used brightness as far as I can tell. Almost like the firmware isn’t turning on the emitter driver.

I’ve been able to reproduce it three times (out of about 15 tries) since I posted by going into lightning storm mode, then switching to candle, then turning off all within a few seconds. Just the type of thing you’d do when trying out a new light which is how I guess I ran into this. So I’m definitely leaning toward an obscure bug. Not a big deal for daily use but now I’m curious to understand it so I’ll try to figure out more tomorrow. I’ll also correct some of my observations now that I have more details.

One last observation before I go to bed. It’s reproducible just by using candle mode without cycling through lightning storm first. And I don’t think it’s related to how long it’s on. It seems like if I turn it off at just the right (wrong) moment in the candle flicker cycle that it then doesn’t turn the emitters on next time I click the switch. I’ll definitely try to review the source code for this function if I get time unless someone else has already figured it out.

A few last thoughts on this:

It looks like it will sometimes (most of the time?) turn back on if I just click the switch a few times. So the condition isn't as permanent as I thought. I still can't figure out the exact sequence of events in candle mode to fully reproduce the issue, but I've made it happen several times.

I thought it might be related to the issue referenced below in loop(), but I reproduced that issue and confirmed that the switch LED doesn't come on in that case, so it's not related:

    #ifdef USE_VERSION_CHECK
    else if (state == version_check_state) {
        for (uint8_t i=0; i<sizeof(version_number)-1; i++) {
            blink_digit(pgm_read_byte(version_number + i) - '0');
            nice_delay_ms(300);
        }
        // FIXME: when user interrupts with button, "off" takes an extra click
        //  before it'll turn back on, because the click to cancel gets sent
        //  to the "off" state instead of version_check_state
        //while (button_is_pressed()) {}
        //empty_event_sequence();
    set_state(off_state, 0);
}
#endif  // #ifdef USE_VERSION_CHECK</code></pre>

I confirmed that the switch LED brightness corresponds to the last-used brightness. With that in mind, I traced through a lot of the Anduril code which was an interesting learning experience. At first I thought it could be that the memorized_level variable was getting set to 0, but the switch LED proves that idea wrong based on the following code from set_level():

void set_level(uint8_t level) {
    actual_level = level;
#ifdef USE_SET_LEVEL_GRADUALLY
gradual_target = level;
#endif

#ifdef USE_INDICATOR_LED_WHILE_RAMPING
    #ifdef USE_INDICATOR_LED
    if (! go_to_standby)
        indicator_led((level &gt; 0) + (level &gt; MAX_1x7135));
    #endif
    //if (level &gt; MAX_1x7135) indicator_led(2);
    //else if (level &gt; 0) indicator_led(1);
    //else if (! go_to_standby) indicator_led(0);</code></pre>

Since indicator_led() is behaving as expected that makes me think that the level being passed to set_level() is correct. So I can't really find a good explanation for what's happening. Either it's a bug in Anduril 2020-03-18 (the version on the light) that isn't in the current version or there is a very very strange defect in my particular unit. I'm thinking that I might have wanted the SP36 BLF version anyway so I might send it back and try that one to see if it has the same issue. Like I said it's a very minor thing but it got me curious. I'll report back if I can reproduce it on the SP36 BLF, otherwise I'm moving on from it. It would still be interesting to know if anyone else encounters this behavior.

Hello, i have the same issues! SP36 PRO behaving Badly!
Here are some video of it
SP36PRO BEHAVING BADLY
SP36PRO BEHAVING BADLY2

I spoke to the Sofirn person in China thru Whatsapp Chat.
He said mine was an isolated issue!
I was not going to settle on that!!!
Quick Share!
As u can see by the Snapshot of the chat.

Ive done the factory reset, several times…

My temp fix ;
On Ramping, ive set it 20 UP FROM THE lowest and 20 from the top.

On step ramp, ive set it 30 from bottom and 1 from top with 3 steps!

My observation;
It seems that 2 x click turbo activation from a very low output & 2 x click back will see the LED’s not lit up.

3x click from off functions; batt check etc, Switch flashes, not LED’s… (Not consistently doing it)

’I need An Old Priest & a Yound Priest!!!
MAY THE POWER OF CHRIST COMPELL YOU!!!

It Seems to do it after beeing fully charged.

And on low light, the LED’s FLICKER! (Sometimes)

Otherwise, it works fine! Cant wait to do a spring bypass, brass M2.5 5mm screws!!!

Mine is beeing Replaced, hopefully, it’ll behave as it shud!

Glad u posted!!!

Your issue appears to be quite different from the one I described. It would be good to post a description of your issue in addition to videos. Video without explanation is difficult to interpret.

Yea i did checkout the videos. Specially the 2nd vid!

Okay, this sounds like a faulty 7135 chip if it’s only happening on low brightness, holding the switch ramps it up to activating the FET. Had this behavior on a few Mateminco MT04 lights and fixed it by replacing the 7135.

Agreed that the other poster’s issue sounds like a problem with the 7135. My issue was occurring both in regulated drive (7135) and unregulated (FET). I already received the SP36 BLF (Amazon is expensive but fast!) and I haven’t had the issue. Since no one else has reported that issue with the SP36 Pro I assume it’s a very strange defect in my unit, maybe with a PWM driver or timer in the MCU. Anyway I’ll be returning the SP36 Pro. The SP36 BLF has some fit and finish issues compared to the Pro (battery hole drilled so close to the edge that some threads are missing, switch LEDs misaligned) and also has some more significant thermal management issues (high CRI LEDs run HOT) but at least it comes on every time I push the button!