E-switch UI Development / FSM

Toykeeper is trelling for last months first Texas Ace
then me
last Astrolux
that her firmware has no bug its perfectly regulating temperature
does not want to write new code Astrolux paying her because she claims there is no bug

It works only if you compile the hard turbo dropdown which does after 30s a hard stepdown then limit max. current to a fraction of turbo

We had here lights that you could fry egg on and still getting hotter

There is some sort of heat up oscillation if the thermal mass and heat ratio is making slow cool downs and fast heat up

Asking just for simple code to be written:
if actual temperature is >5K than ceiling stay at MIN_THERM_STEPDOWN xxx

ignoring the problem for last months now the MF01S could be build but still no working firmware that keeps the light at safe temperature levels

TA, Astrolux and me spent hours and hours trying to fix the hardware but its not possible as the code does not work above the ceiling temperature

I'm not sure how I would feel about being asked to develop open-source software specifically for a certain company/product without compensation. The beauty of open-source is that Astrolux or whomever else are free to use the software if they meet certain requirements. I'm not sure which open-source license TK uses, but most allow modification if certain requirements are met (usually, publish the modified source code, among other things).

Astrolux offered payment to get the thermal code changed and use of firmware as far as I know
they want to get this light to production asap
a few hundred dollars spent on Toykeeper make some code actually pays of in no time
they are sitting just for the LEDs on about 20,000$ already invested in stockpiling the good tint bins
just for the CRI95 SST-20 they got 11000 LEDs below BBL

Prototypes are made but lacking the final firmware to test and going to mass producing after reviewing those and make last adjustments

Dunno, I'm sure TK will respond to all this, but I could probably help, just may take some time for me to do - I can't cut my hours at work right now, and I'm bout sure Astrolux would not pay my rate. Even for $500, I'd probably lose my shirt on the deal from my current rates and lost hours on my regular full time contract.

It's very easy to under-estimate software/firmware - boy, if anyone should know it's me.

I don’t presume to speak for ToyKeeper either, but I will mention that when I was working as a software engineer, $500 would have bought you about two days of my time.

For a bughunt on unfamiliar hardware, where either the hardware or the software could be at fault - or even both together - that’s barely enough time to set up a suitable test & development environment, never mind actually tracking the bug down and fixing it.

Bespoke software engineering is expensive.

It scares me to even think about what ToyKeeper’s freely given work for BLF would have cost on a commercial basis. I’m deeply grateful that she did it, though, because my EDCs have been running her firmware ever since the BLF A6.

The tests have been done and traced down to a simple think the Temp management does
It starts to increase the output even when a lot over the Temperature set point
Solution is to make it stay at minimum MIN_THERM_STEPDOWN value if its noticeable higher than the set point

Sure Toykeeper can do this a lot faster than anyone else that is not familiar how the current temp code works
I have searched the Temp code with the setup strings and its clustered into different sections depending which setup lines are activated,
but I do not understand the programming stuff like

OR

I know this code is responsible for temp management, but got no clue how it works or how it needs to be changed or code added to prevent the heat up above safe value

so we know its running then on a constant current that does not heat the light any further not trying to regulate heating the light up even more
Its confirmed that the temperature readout of the MCU shows those high temperatures

Getting this fixed will also be an improvement to Lights like D4S which have no hard turbo dropdown

You are cheap! $500 is not a full day for me, and it covers about a week of my health insurance (2 adults).

500$ a day?

I have to work 7-8 days for that

guess it does not pay not to be able to do complex programming stuff

at least 12% of total income for my health insurance is cheaper then (children included)

Wow. Senior programmer here earns $100 per day. Minus taxes.

Contract work is a two way negotiation. You can charge whatever you want as long as the client is willing to pay you that much. The specified rate tends to be variable based on a number of factors such as whether or not you are presently starving, or don’t need the work at all, or even how deep the clients pockets are or how much they stand to make from your work, etc. If they don’t like your price, they can go elsewhere. No one is a victim.

It depends on the point of view. Whats the price, a company would pay to your boss for your work. And Whats do you get at the end of the month from your boss.

:slight_smile:

Probably an EU / US thing. I’m in a good company pension scheme, with healthcare and some more pension provided by the state from my taxes. The $500 is what ended up in my pocket. My employer would have charged you at least three times as much if you’d gone to them and asked for my services.

By default, there is no blink at the ramp floor.

I took out the floor blink a long time ago because it is pretty obvious when the brightness stops going down, so no blink is needed. It can still be added as a compile option though.

So… it has problems when compiled without the option to prevent those problems?

Yes, it can adjust the wrong direction when temperature is changing very quickly. This is a known issue which I want to fix when I have time, but until then, the hard drop option is an effective workaround.

I have already tried a couple times to fix it quickly, but it seems I will have to do it the long way instead. The plan is to build a PDE-based thermodynamics simulator attached to a code simulator so I can run tests without hardware, and then adjust everything until it works as desired. It will probably take a solid uninterrupted week of development to finish, and I have been too busy to set aside that much time.

Until then, the workaround keeps things pretty safe. It just tends to be a little more careful than necessary.

I’ve been listening, and trying to help when I have time. I’ve been a little busy though.

Are you familiar with how PID regulation works?

It sounds like you might be a little confused about the “D” part, the derivative. It measures the slope of the temperature curve over time, and factors that into the equation. So the behavior depends on whether the temperature is rising or falling, not just what the absolute value is.

If it’s configured for 60 C and the sensor is at 70 C, it won’t necessarily reduce the power. If it’s at 70 C and rising, it reduces power. But if it’s at 70 C and falling, it assumes everything is okay and maintains a steady course. It may even increase power if it thinks the temperature is falling too fast.

In a similar manner, let’s say it’s at 40 C. If it’s 40 C and falling, it should increase the power… assuming it’s not already at the desired level. But if it’s at 40 C and rising, it may decrease the power even though it’s not at the limit yet. The response depends on where it’s at now, and where it expects to be in the near future.

In this test, the driver is floating free and the heat comes from a heat gun. This isn’t really a supported configuration. Increasing by 40 C in two seconds should not happen in a real light, and will probably cause an overflow issue to happen because it’s changing so fast.

However, it appears to be responding fairly well despite the weird conditions. What you describe in the video as “definitely a temperature bug” looks like it may be correct behavior. PID attempts to steer into the turns, instead of waiting until it passes the threshold before it starts changing course.

That’s actually part of why this process has been so long.

Well, that, and I’ve been busy. And Mateminco didn’t ask to hire me and send me hardware until yesterday. I haven’t exactly been ignoring them.

  • Apr 10, Mateminco asked if I could fix a problem in their light.
  • Apr 12, I saw the message and responded. Astrolux and Mateminco haven’t been very good about respecting the code license in the past though, so I wanted to make sure that was cleared up first. It’s kind of a prerequisite for taking clients. So I sent info about how free software works and what Mateminco needs to do to be eligible to use it.
  • Apr 14, Mateminco replied to say they understand and will keep working on fixing their product.
  • Apr 25 (yesterday), Mateminco asked to hire me to fix it.

I’ve been pretty busy with FW3A stuff though… and also busy with other high-priority projects. So I need to take care of those things first.

Yeah… it has been frustrating being asked to do large amounts of work for free, for the benefit of a company which has a history of ignoring the code license and delivering products which do not live up to expectations. Remember the S42?

The company has been trying to improve though, to make things right with the community. And, as of yesterday, they asked to hire me for the MT18. So I’ll probably add a MT18 build target for Anduril and make sure it works correctly.

Exactly. Busy busy busy, and these projects don’t usually pay well so I have to prioritize other things.

I haven’t attempted to track anything like that, but the sloccount tool can produce rough estimates of how much it would cost to develop arbitrary code at a traditional software company like IBM or Microsoft. This includes both the salary paid to the developers and the other overhead in the company.

So I’m curious. Let’s see what sloccount says…

> bzr branch trunk test
> cd test/ToyKeeper
> sloccount .
...
Development Effort Estimate, Person-Years (Person-Months) = 3.51 (42.11)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.86 (10.36)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 4.07
Total Estimated Cost to Develop                           = $ 474,063
 (average salary = $56,286/year, overhead = 2.40).

So, after factoring the overhead ratio of 2.40, that works out to:

  • $197,526.25 salary for the developer
  • $276,536.75 corporate overhead

It estimated about 3.51 person-years to develop. I’ve been doing it in my free time for about 4.5 years. So it’s probably not too far off. However, there just isn’t that much money in flashlights. The estimated total cost is probably almost as high as the total revenue of all lights sold with my code so far… so even in an ideal scenario where I got literally all profits, I’d only get a fraction of sloccount’s number.

I have not been saying it works perfectly. I have been saying it needs the correct compile options and calibration. I have also been saying it is important to understand how PID works, and understand how to work with source code. And saying that companies need to talk to me directly if they want my help.

On a related note, your pogo pin flashing adapter design should make it a lot easier to do thermal testing on real hardware. I should have one of those soon, and I plan to make good use of it. Maybe I won’t even have to build a simulator… though I’d still prefer to to use a simulator so I can get more precise results faster. Then I could run a whole test suite in a couple minutes instead of having to wait for batteries to charge between tests.

Would it help to put some small current sense resistors in series with the led on the driver.

Not to measure current flow just to generate some heat so the mcu can respond quicker?

Thank you Ma’am, this worked perfectly!

Thank you too Tom for making the easy to read pinout diagram.

It seems to get the measurements fast enough on most lights… but it probably helps if the LED wires are thick and the MCU is close to the copper pours for BAT+/LED+. Heat travels through those wires and traces into the feet of the MCU.

I’ve been gathering courage over the last few months; to give firmware code/editing another go. I’m not there yet, but I do have a question about a feature :slight_smile:

How much code/work would it require to make Anduril have the option to do a “soft off” ?

When clicking once when on, instead of the light turning off instantly after the tiny delay:

I would love to make it do a really quick ramp down from the ramp level it was on. And THEN turn off completely.

I mean, “we have the technology”. So why not add another fancy feature :smiley:

User revdns did this mod back in 2016. Same concept. source

I tried adding a soft-on and soft-off feature once. It wasn’t very hard to add, but there’s a catch. If the user clicks during the ramp-up or ramp-down period, things can get a little tricky. It needs a way to abort the animation. This is probably at least a little bit easier now though, since I built automatic abort into the nice_delay function any time a button is pressed.

So it’s not a lot of code, but it may take some experimenting to find a good way of dealing with interruptions.

Does anybody know if Andúril has a reset function implemented yet?
(hold the switch while connecting the battery)

Or is this only planed?

Edit:
Not at the moment, maybe in the future