E-switch UI Development / FSM

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

Toykeeper I know what PID is and how it works
But even if I put a pot of water on my hotplate that is 30K above set point it wont start very quick to do a 70% duty cycle its likely starting about 10K above to heat up again,
but your PID even starts to increase current 40 or 50K above set point

I know even before you hit the Temperature ceiling if temp is climbing it is throtteling the output

That Video was made under Lab conditions, the heat up (I know it was way too fast) was in this test totally irrelevant
It was way more interesting what happens when the driver cools down slowly

The fact that the driver is starting to increase current even 30 or 40°C above the temperature set point is causing the heat up bug TA, Matemineco and myself has seen in multiple tets
in the video I could clearly show that it went up to 70% FET duty cycle when the temperature is falling but still 20-25°C above temperature ceiling

.

All what has to be done is keep the PID regulating to Ceiling +5K then disable it for safety reasons till ther light cooled down enough
(current PID model seems not to work so well for flashlights, when its getting hotter than set point, it wents into some sort of oscillation heating up more and more)
instead ramp down current down to MIN_THERM_STEPDOWN and stay at that level till it falls below temp ceiling
This would be sort of “Soft Turbo dropdown” dependant on temperature

Another question is about Lowering the PWM frequency on Moonlight to like 2kHz like you do which code is responsible for that
I would also like that in NarsilM some day

I am currently working on a CC FET driver and I also want to try getting on low levels the PWM to the OPV constantly at this frequency to see if this can be used to dim more
its not working on 15kHz with NarsilM

I have in main.c
#define BLINK_AT_RAMP_FLOOR
#define MOON_TIMING_HINT
enabled but it does not blink Astrolux wants it

I got round to flash Anduril onto my D4S and I think I bricked it.
I just simply copied the command from the first post without reading more about it and now I wish I did…
That’s what I did. Now after pressing the button only aux LEDs blink in low mode.

After this MCU doesn’t respond to anything

Can I still rescue it somehow or do I have to replace ATTiny on the driver?

Forgive me if that’s something obvious but I’m really not too educated on this stuff…

You used totally wrong fuse bits
Only a high voltage flasher may reset the MCU

Doesn’t help if its not flashable anymore you got to replace it

I may send you from Germany a flashed MCU

Best is to carefully unsolder one side leg by leg then folding up a few times to break other side legs

I was gonna say I might be closer and could send you an MCU, but then I realized your in Poland lol.

Sorry, it sucks to brick an MCU. Been there, done that, you’re not alone at least.

You live and learn. Eh…
Could you explain how to do it correctly for the future reference?
Will probably use your offer Lexel and place that long overdue order for couple drivers and get MCU straight away.

Actually how would it work with new ATTiny, do they come preprogrammed or how does one place initial firmware on it?

Excuse stupid questions but have no experience with it.

there are 2 ways of programming
pre solder with a SOIC socket adapter
or past reflow with an SOIC clip pusching on the MCU from above the PCB

indutrially with a pre reflow flashing robot that may be also able to retube/rerail the MCUs after flashing for PCBA machines feeder