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.
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.
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.
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
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
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.
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 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.