Those are problems that occur when the product is in use. The D4 problem occurs when it is off. I think most people understand that high-power electronics can fail when they’re being powered. I’m always a little nervous when using a circular saw or a chainsaw. But after I turn the thing off, I’m not nervous about it at all. Those things don’t turn on by themselves and start killing people, unless it’s in a bad horror movie.
Off should mean off, until you intentionally turn it back on. The fact that the D4 didn’t do that, means that the code is getting too complex. Or at least the code in the “off” state. IMO, the “off” state should have no other method of going to “on” unless a user clicks a button. Nothing else. I get that the colored lights might have complicated the code. In that case, either redesign the code that handles off and on, or don’t support colored lights in the off state. Make them a moonlight mode or something like that, if the code isn’t structured to support them in “off”.
The understanding of “off” and “on” should be from what the end-user expects, not what an engineer might argue with semantics. Every user thinks that when they click the “off” button on a flashlight, it turns off and stays there. That is what it should always do, 100% of the time. Sure, it can run background tasks, but none of those tasks should be able to bring it out of “off”.
Now, there may be weird events like a cosmic ray hitting the MCU and causing a bit to flip and the light comes on by itself. Crazy one-in-billion stuff happens. But the D4 bug is a software error, not a chance event, and it’s reproducible. The software is getting too complex if there’s any other path out of “off” than a button-press.
I’ve been in this hobby for 5+ years and i’ve seen legitimate complaints about all sort of lights. Visible PWM, light starting on high rather then low, disco modes part of the cycle, output much lower then advertised, fake leds… lights shorting on battery insertion… weak anodizing… bad beam or tint…
Compared to them the D4V2 is a marvelous jewel or technology that cost less then $50. Why so much drama for a glitch in a minor mode? This light is not for muggles, that’s it. Don’t use the “muggle mode” and make sure you don’t. What’s so complicated? If you are on BLF to get access to cutting edge high power lights, you should be aware of the potential risks. Would you use candles and let them unattended with the kids around?
Anyway, i really wish all discussion about how to produce perfect software would move OUT of this thread. Thanks.
Changing subject, I was asked by Hank to write some instructions for flashing the D4V2 using his flash kit. My instructions will be for Windows 10, using a command line. The instructions should get posted on Wednesday. I've sent Hank a draft version, should be finalized tomorrow. I think the kits will also be available sometime this week.
This needs to be a collaborative project, as we need other BLF members to contribute instructions for other operating systems. It would be difficult for one person to write instructions for all operating systems and all flash programs.
I’ve been flashing firmware for a short while using an old netbook with Windows 7 Starter. Seems very similar to Windows 10 once the programs are installed. I’m happy to help however I can.
I’m intrigued by the Android app. That may be easiest for many, since there’s no problems with installing the programs and drivers, having the files in the right place and entering the command etc. Can someone that’s used the app confirm that it leaves the fuses as is when one does not go into that menu? I imagine it should but don’t want to find out otherwise on my D4V2.
Both Win10 and Win7 system work fine with the kits I will provide, I have tested them both.
Yes, the Andriod app works fine as well, confirmed by forum member “ZozzV6”, he said it’s even easier to reflash the driver with the Andriod app. And he agreed that he will shoot a video to demostrate how to reflash the firmware.
I hope with the words instruction and demostrate video, the reflashing will be simple for the majority.
Well, thanks for Mr McConnel’s opinion on the subject, but that’s only a part of the picture. You see, an ability to produce a bug free piece of software depends on numerous factors such as code length and complexity, programming language, environment(hardware, OS, compiler, IDE, requirements etc), different bug prevention models - testing or formal proof, and even how you define “bug free”. In case of fairly simple code and limited input possibilities it is relatively easy to produce a piece of software that is almost bug free and with a right approach the same is possible even when dealing with sophisticated code without spending a fortune. A good example of this approach is seL4 general-purpose microkernel, most of its code is formally verified
I can understand your point, better safe than sorry… But I can’t agree that removing the battery or unscrewing the tailcap when you are not using your flashlight is a normal way to use it. Just imagine that every time you leave your car in a parking lot you have to manually cut the fuel line and remove residual gasoline from the engine because otherwise the vehicle can start moving on its own. Besides breaking the circuit makes aux leds useless.
It depends on what you consider perfect. For example, MFM (Message Flow Modulator) is a formally proved filter program, but nevertheless I am not sure I can call it perfect.
I am sorry if my statement was misleading. By saying “but not acknowledging her mistakes is plainly wrong” I wasn’t referring to TK, I meant the users here who can’t accept the fact that TK made a mistake.
Well, thanks for your opinion on the subject. Mr McConnell is known as one of the most influential persons in software engineering and his name gets mentioned together with Bill Gates and Linus Torvalds.
Take a quick look at the Anduril source code. I did and it's easy to see that it's complex enough that bugs can slip through, esp. when new hardware is involved.
I'd like to personally thank you for this. I'd love to be replying to this with an offer to help, but I've yet to dive into flashing any of my lights for various reasons, and one (among many) of the reasons has been the lack of complete and consolidated resources for flashing. As someone mentioned earlier in this thread, there are many resources, spread across different threads, in various states of outdates, and suitable for different microcontrollers and operating systems. And I've generally been pretty fine without flashing. But it's been on my list as something I'll eventually want to do. So while this bug is, well, a bug, there is so much positive coming out of it for the community.
Topic change: Android flashing sounds cool! I've always thought it was neat to have the USB adapters for my phones, and it would just be too funny to flash a light with my phone. With the programming key, I could flash completely different software to a light anywhere I wanted!
The Linux instructions are pretty simple as well, and there is some overlap. I could help here for Debian based distros. I think toykeeper had a summary on one of her posts that would be enough for most Linux users though.
I’ve been pretty slammed with some projects this week (I’m at the end of two construction projects and in the middle of an acquisition for one of my clients). I’m not sure when I could promise a complete guide, but in the next week or so should be doable.
Your help would be appreciated. I will have my instructions up by this evening. I will reserve the first couple of replies in that thread for other contributions. I think we have plenty of time. When Hank makes the flash kits available - it will still be a week or two before people receive them.
I think we simply have a little misunderstanding here, at least I hope so. I’ve never said that in this particular case it is impossible for bugs to slip through. On the contrary I put emphasis on the fact that there are a lot factors affecting the possibility of creating a bug free piece of software. But if the development process is organized in the right way and if we are speaking about programming something relatively simple like a flashlight it is normal to produce an almost bug free code at least without bugs of critical, major and minor level of severity. You may have your own opinion regarding the subject and that is great, but I can’t agree with something that goes against my knowledge and experience without a solid proof, sorry. I also doubt that a lot of people here will embrace the idea that it is inevitable and normal to have critical and major bugs in potentially dangerous device, and that is basically what you are implying.
It’s not like I am trying to spite you or anything like that, but this is the first time I am hearing about Steve McConnell. And looking through his biography I hardly can imagine why somebody would mention his name together with Bill Gates and Linus Torvalds. Above all, he is famous for his books and IT journalism, but I can’t find any accomplishments in his biography that are more or less comparable to what was done by Niklaus Wirth or Dennis Ritchie or Bjarne Stroustrup or Donald Knuth or Linus Torvalds or Bill Gates.
