How the crap do you get out of momentary mode? I’ve looked at the flowchart and can’t figure it out. All I can do now is momentarily use the strobes.
You have to disconnect power to get out of momentary mode, it is a feature not a bug.
Among other things you can do with momentary mode is signalling. That can involve long sequences of button presses and releases at different intervals. Since there is no way to guarantee that any particular exit sequence wouldn’t be used as part of the signalling, the only way to exit that mode is by loosening the tailcap.
I see, good to know. Thanks.
By default, the highest regulated mode is available by loosening the tailcap for a moment, tightening it, then doing one click. It needs to be loose long enough to reboot the driver.
Or it can also be accessed as level 4 of 7 in the stepped ramp, with default settings. The stepped ramp is recommended when you want to hit exactly the same level each time.
To switch between the smooth and stepped ramp, click 3 times while the light is on.
Yeah, things have been gradually changing. It’s a double-edged sword. Growth allows us to do bigger and more interesting projects, but it also means expanding somewhat from a niche to a more general population where people don’t have as much expertise.
Muggle mode was almost not included on this light at all, because limits are the opposite of what Emisar is about. Like it says on the tailcap, it’s high-power illumination, not low-power illumination. But it was re-added at the last minute, and that may have been a mistake.
Okay, I’ll put that down as a “no”.
There was a valid point in there about bringing a small company’s processes up to the formality level of a large company, but it’s hard for people to see that message when it’s delivered inside of a burning envelope.
I hate to “well actually”, but fires are a real concern for modern computer OSes. For a relatively mild example, this line of the Linux source code handles the case when a printer has ignited. It may be more of a running joke at this point, but there are more serious cases too.
However, your main point stands. In 2019, it is not commonplace for flashlights to need firmware updates. Granted, devices in many fields are becoming “smarter” all the time, and I’ve recently had to update the code on a phone, a typing keyboard, a drone, a television, a gaming console, a multimeter, and three different musical instruments. There is now such a thing as malware for dishwashers and refrigerators. So the world is definitely heading in that direction. But we’re not yet to a point where it’s common for flashlights.
I’m not aware of a formal plan for things like this. I think Hank is going through orders one at a time and sending messages to each person individually. I’ve been trying to help through more public methods when I can, but there isn’t much coordination involved. It’s sort of uncharted territory.
I also sent some pogo pin adapters to MtnElectronics, and tracking says it should arrive tomorrow. For now, he has the D4 v2 listed as “out of stock”.
I wouldn’t describe it as “works just fine”, since RampingIOS doesn’t work at all yet.
RampingIOS V2 doesn’t run on the D4 v2 — it doesn’t support the hardware. That’s unlikely to change since it’s a dead branch.
RampingIOS V3 does not support the D4 v2 yet. I tried to build it just now and it doesn’t even compile… but I could probably get it working fairly quickly.
So if you want RampingIOS on a D4 v2, it’ll have to be updated.
RampingIOS V2 doesn’t work on the D18 either. At least, not in its current form. However, RampingIOS V3 does.
The command does not have any fuse values in it because of two reasons:
- The fuse values should not need to be changed.
- Attempting to flash new fuse values is risky because it can make the MCU unflashable.
So that part is left out on purpose. As long as the user does not try to change the fuse values, it should be safe to reflash as many times as necessary.
After avrdude runs, it should end with a message like this:
...
Reading | ################################################## | 100% 2.52s
avrdude: verifying ...
avrdude: 9112 bytes of flash verified
avrdude done. Thank you.
If it does not complete the verification step, keep trying until it does.
In particular, it gives an error like this if there is some sort of physical connection problem:
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
It’s possible that a pin may be mapped to the wrong place, like getting VCC or GND on the wrong pin of the usbasp. Sometimes when that happens, it can sort of flash but then it fails during verification.
As far as I can tell, the D4 v2 has now shipped with three firmware revisions. Those three are:
- 2019-06-06: Was used on the D4 v1.5, and some of the early D4 v2 lights. Testing was done on a D4 v2 dev host (just the head of a light, with driver hanging out) and an original D4 v1 (for thermal tests). I did not know this would be shipped to anyone, but Hank tested it and found it acceptable.
- 2019-06-17: Official production version. Tests were run on a production sample D4 v2 this time. Changes from before are:
- Muggle mode re-added (with a brand new bug, oops)
- Made the bottom of the D4 / D4 v2 ramp slightly smoother
- Adjusted thermal response based on measurements of a production sample D4 v2
- 2019-07-18: Current shipping version. Changes from before are:
- Added factory reset function
- Doesn’t measure temperature while asleep… and for good measure, also explicitly ignores thermal events while asleep and during the half-second before falling asleep
- Aux LED “voltage” mode responds to changes faster
- Slight improvements to thermal response
To identify each is reasonably straightforward:
- If it has a factory reset function, it’s 07-18 or later.
- If it has muggle mode but no factory reset, it’s 06-17.
- If it has no muggle mode, it’s 06-06.
I hope this makes this a little more clear.
Excellent, and thank you for the info, TK!
As far as I can tell, it’s probably failing to activate the correct ADC channel while asleep, so it’s probably measuring the wrong thing. The way voltage measurement works, it compares an internal reference to VCC, dividing the reference by VCC. This means the value gets higher as voltage gets lower. So if it interpreted that number as a temperature, it would appear to get hot when the battery is low.
That’s my theory so far, anyway.
At least I can explain why it takes 15 minutes to activate. The temperature values go through a lowpass filter and an additional noise reduction filter, so it eliminates any bizarre measurements as long as they don’t persist. This allows the response to be smoother and more consistent. So if it suddenly started getting crazy values, it would initially ignore that data and then slowly start to “believe” over time. And with it being asleep, everything happens in slow motion.
Then, when it wakes up, it completely resets its thermal history and starts from scratch, so it forgets anything weird it saw in a dream.
That would be awesome. We might want to coordinate though, and try to put the guides together in one place. This should make things easier for everyone who needs it.
So far it looks like…
- Windows: Zadig, avrdude, and either a command line or some sort of flashing GUI.
- OSX: ???
- Debian-based Linux: apt install avrdude, run a command
- Fedora-based Linux: dnf install avrdude, run a command
- Other Linuxes, BSDs, etc: People running these OSes are probably clever enough to figure it out on their own.
No, the FW3A has no flashing pads.
Yes. Plug one end into USB, and press the other end against the flashlight’s circuit board. Then run a command on the computer. Wait about 10 seconds, and it is done.
I would like that too. The person designing the circuits is aware of this though, and adds vias when they can fit. It just isn’t always easy to fit a bunch of vias in the right places. Usually there is at least one though, so once the device is aligned it does not tend to slip.
This is already in progress. I sent Mtn some adapters, and he’s planning to update his entire stock of D4v2 lights. I don’t know his other plans though.
This is good news. 
They are difficult to assemble by hand, as you said. It is very precise. I don’t know how to solve that, but I don’t have much experience with manufacturing.
If it is not too late, do you think it will be possible to make it with 8 pins instead of 6 pins?
This is not necessary, of course, but it might be helpful for future projects if the pad layout ever changes. With 8 pins it can be more universal, compatible with more designs.
I thought, and still think, that Muggle Mode is a very good thing to have. If nothing else, most of us occasionally need to hand over a light to someone who has no idea what they’re getting. Also, there are people, like my wife, who would like to have high-end light capabilities for emergencies, but wants something safe and minimal that they don’t have to think about for the day-to-day use.
I hope you’ll keep it around.
By turning off your auxillaries in ramping mode or electronic lockout, you wouldn’t be able to know whether you were accidentally in muggle mode unless you checked whether you could could trigger Turbo or not. Having to check for Turbo each time you turn your light off,is unnecessary if you have your auxillaries on in the other modes.
I strongly agree. Having everything in one place, and all organized in a similar way, will make it easier for people to find and use them.
I have too much going on this week to have started working on anything yet, but I plan on putting together some preliminary notes after that. The main process should be fairly simple. I think the toughest part will be the “what do to when something doesn’t work as expected” section. Fortunately, my own experience has given me some insight in that direction too. :-}
This is why people in the community can not put up with your behavior.
I think you and TK are having a bit of a misunderstanding.
I believe TK was talking about updating RampingIOS to make it compatible with the driver in the D4V2 for those that might want that operating system on the D4V2 or future 1634 MCU based lights.
The current version of RampingIOS is only compatible with the ATin85 MCU. It requires an update to be compatible with the 1634 MCU used in the D4V2. If you try to flash a D4V2 with any of the current version of RampingIOS the firmware won’t work. They use different chips and the code is not compatible between them without updating it first.
I do not believe she was saying that Ramping IOS does not work or needs to be updated for older lights, running on the ATiny85.
[quote=ToyKeeper] [quote=Neg] [=ToyKeeper]I haven't updated RampingIOS yet [/quote] please don’t , there is nothing wrong with them ,they work just fine. [/quote] I wouldn't describe it as "works just fine", since RampingIOS work at all yet. RampingIOS V2 doesn't run on the D4 v2 -- it doesn't support the hardware. That's unlikely to change since it's a dead branch. RampingIOS V3 does not support the D4 v2 yet. I tried to build it just now and it doesn't even compile... but I could probably get it working fairly quickly. So if you want RampingIOS on a D4 v2, it'll have to be updated. [quote=Nev] put ramping v2 on my d18 [/quote] RampingIOS V2 doesn't work on the D18 either. At least, not in its current form. However, RampingIOS V3 does. [quote=ZozzV6] The flashing sequence not even completed once. ... Usually flashing scripts have fuses. I don’t know why this not have. [/quote] The command does not have any fuse values in it because of two reasons: * The fuse values should not need to be changed. * Attempting to flash new fuse values is risky because it can make the MCU unflashable. So that part is left out on purpose. As long as the user does not try to change the fuse values, it should be safe to reflash as many times as necessary. After avrdude runs, it should end with a message like this:
... Reading | ################################################## | 100% 2.52savrdude: verifying …
avrdude: 9112 bytes of flash verified
avrdude done. Thank you.
If it does not complete the verification step, keep trying until it does. In particular, it gives an error like this if there is some sort of physical connection problem:
avrdude: error: program enable: target doesn't answer. 1 avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.
avrdude done. Thank you.
It's possible that a pin may be mapped to the wrong place, like getting VCC or GND on the wrong pin of the usbasp. Sometimes when that happens, it can sort of flash but then it fails during verification. [quote=srvctec] I wonder if there are any potential issues with the preproduction F/W or is the only difference the fact it doesn't have muggle mode [/quote] As far as I can tell, the D4 v2 has now shipped with three firmware revisions. Those three are: * 2019-06-06: Was used on the D4 v1.5, and some of the early D4 v2 lights. Testing was done on a D4 v2 dev host (just the head of a light, with driver hanging out) and an original D4 v1 (for thermal tests). I did not know this would be shipped to anyone, but Hank tested it and found it acceptable. * 2019-06-17: Official production version. Tests were run on a production sample D4 v2 this time. Changes from before are: ** Muggle mode re-added (with a brand new bug, oops) ** Made the bottom of the D4 / D4 v2 ramp slightly smoother ** Adjusted thermal response based on measurements of a production sample D4 v2 * 2019-07-18: Current shipping version. Changes from before are: ** Added factory reset function ** Doesn't measure temperature while asleep... and for good measure, also explicitly ignores thermal events while asleep and during the half-second before falling asleep ** Aux LED "voltage" mode responds to changes faster ** Slight improvements to thermal response To identify each is reasonably straightforward: * If it has a factory reset function, it's 07-18 or later. * If it has muggle mode but no factory reset, it's 06-17. * If it has no muggle mode, it's 06-06. I hope this makes this a little more clear. [/quote]
Yes MARK M
tell me about it!
We can all play childish games ,
You are the only child around here and just as intelligent.
I wish I had followers like you backing my corner
This has to stop , I’m sure tk isn’t impressed by your antagonistic remarks on all my posts. Leave it out.
This has nothing to do with her, just your nasty impetulant behavior.
I come to this forum learn about bleeding edge technology. Please go elsewhere that may be more suitable for off topic banter. If you want tried and true lights, buy a large production light from a major manufacturer. This place is for enthusiasts who support each other learn about their passion. Not trying to point out flaws to make yourself look big. Don’t expect perfection in early limited produced products. Just be grateful to possess a product that is on the bleeding edge and use common sense and take precautions to ensure your safety. Hint…. lock out etc.
I have been probably the most “talkative” person on this forum for quite some time. I recently walked away from BLF because of all the petty bickering from the new members. Would you guys go grab a beer and work it out please? This is not the place for all the back and forth argument over behavior.
I am waiting to hear about the specific fuse values required before flashing my D4V2, the command given includes no fuses and everything I’ve ever flashed before required this (literally hundreds of drivers) I’ve seen even ToyKeeper brick MCU’s getting all this sorted out, and a lot of other very talented people as well. So, until I can get some verification my light awaits it’s upgrades… (primarily I want the Samsung emitters but I am waiting to proceed so I can get the flashing right in order to help those that would have me do so.)