I have been playing with bistro today, trying to get it setup just so for the tripledown drivers mode wise.
I did notice something today, how is the SOFT_START supposed to work? It is supposed to ramp to the next mode gradually correct? I even tried changing the comment so that the “slow ramp” was enabled but yet I don’t get any kind of ramping? It just jumps directly to the next mode.
I did notice that I seem to get a bright flash as it changes modes with soft start enabled. Without it enabled I still get a smaller flash in the lower modes but very little in the higher modes? I think this flash is because I am using a tripledown that doesn’t have the new components, I didn’t see the flash with the TA drivers. Although that doesn’t explain why it is worse with soft start enabled?
Now I don’t really care myself but was curious why it would not work?
Hey TK, what do you think of a dual-switch version of bistro-tripledown?
Basically everything is the same, except short and medium presses are performed on the side switch only, and the main power switch (clicky) only does on/off. That way if memory is enabled you can use a forward-clicky for signaling, etc.
As I was finishing working with my version of bistro, I was thinking, is it possible to make turbo an option in the menu? I started to try my hand at adding this but it looks like it needs code in so many different places (by looking at the moon mode options) I didn’t feel like trying to figure it all out.
With the triple channel drivers sometimes the regulated bank of 7135’s is simply all you need and there is no reason to use turbo. For example in one light I only get an extra ~300 lumens out of turbo at an extra 2 amps. It is simply not worth it. It would be nice to simply be able to remove or enable turbo from the menu vs having to make custom mode groups both with and without it.
What settings are you using for stop motion strobe? I could not totally figure out how you were calculating the pulse timing into hz so I just used the 10hz strobe and then each of the tactical strobe timing by themselves. Have not had a chance to try them yet other then testing though.
Far as the bike mode goes, like I said, I am of the mind that the single flash bike strobe is both safer and easier on drivers while still getting their attention. A single flash doesn’t instantly bring to mind a cop (and the inevitable check of the speedo and driving conditions to see if he is after you). Plus you are not likely to stare at it which means there is less chance of hitting it.
I also have not science to back up my side, just my personal feelings based on being a driver. Another user also had some good points about the german laws as well.
As a bonus if you went to the single flash you would free up space for other features.
The tiny25 runs at 8 MHz while the tiny13 runs anywhere from 3.6 to 4.4 MHz. So, to get the same pulse length it needs a PWM value about twice as high, at least on the lowest modes.
In both cases, it’s likely using phase-correct PWM to slow down the pulses by half, but that just means ~8 vs 15.6 kHz instead of ~16 vs 31.2 kHz.
So yes, it’s caused by swapping the MCU.
Also, if moon is on the third channel (pin 2 or 3), IIRC, the PWM speed is twice as fast again. So, it’d be running at 31.2 kHz. I never figured out how to slow down the 3rd and 4th PWM channels. But IIRC the driver puts the FET there, which should work out better since the FET can handle faster speeds and it eliminates whining sounds on the high modes.
The soft start bit ramps quickly from the old mode (usually “off”) to the new mode, using a very crude decelerating curve. So, it moves quickly at first then slows down as it approaches the desired level. It does this by sliding along the ramp, so it only works with a pretty large ramp, like at least 40 values long. The code is optimized for size, not accuracy.
In general, soft start is only visible when turning the light on, when it ramps from off to whatever mode is selected, in something approximating a constant amount of time. This makes the ramp more visible on low modes because it moves slower. Soft transitions can also be seen on LVP step-down. The intent was to use it for all mode changes on an e-switch light, but I haven’t made e-switch code with it yet…
Anyway, some drivers have a preflash issue, visible when going from a high mode to a very low mode. This is entirely a hardware issue and can’t be solved in code. For bistro, it’ll be especially visible because of soft start, because every mode starts low. It should look like a very quick bright flash followed by the usual ramp-up. It only happens when the previous mode was pretty high, and only if the power was off for a short time. It’s by far the worst on high-amp triples and quads. I forget what exactly caused it, but it took the circuit folks around here a while to figure it out and eliminate it.
The bistro code was initially designed with this in mind, but I haven’t actually done the rest yet…
Rewriting it to do everything with an e-switch would be a pretty big project though. Clicky switches and e-switches require very different code. I have a design in mind for an entirely new e-switch code base, intended as a foundation for others to build on, but haven’t really started on it yet. Have been talking about it for at least a year now and haven’t done it.
The basic idea is to build a flexible “finite state machine” driven by an event parser and callback system. People would create new interfaces mostly by putting data into a big table describing the various states, event types, and state changes. Basically, build a flowchart of the interface you want, and dump the flowchart into table form. Plug in small custom functions here and there as necessary, or some useful defaults will be provided too.
Once I have the code base working, the actual interfaces should be relatively simple without the need to write much (if any) logic code. Instead you’d just define a bunch of data in tables. Each position on a flowchart is a state, each arrow is a state change, and the label on the arrow is the event type. You define the states, changes, and events.
I don’t know what kind of MCU it will require, but probably a tiny25 or bigger.
That’s weird. A 8x7135 Nanjg 105D is what I used to create and test the code, and what Convoy is using in the new C8. I tried a few and they all worked, then tried the 3x7135 and 4x7135 and 6x7135 versions which also worked.
Did you change anything else in the code? That 1/255 value should be running at 1 kHz instead of 16 kHz, meaning it’s actually on for 16 clock cycles per pulse. (or was it 2 kHz? I should really measure it) Then the 15/255 value is running at 8 kHz, so it’s on for 30 clock cycles per pulse. The others are more straightforward.
For stop-motion strobes, I generally do a turbo pulse for 1ms or 0.3ms, depending on the strobe speed, and then leave it off for much longer. The frequency is simple to calculate; a delay of 41ms (plus 0.3ms for each pulse) is 1000 ms / 41.3 ms, or 24.2 Hz. The speed will vary per-MCU though, especially on tiny13a.
I find that a 1ms pulse is a bit long for things like falling water, so I only use it for slower strobes. However, a 0.3ms pulse is both somewhat dim and a little unstable. This is because I’m still using PWM=255 for the strobe modes instead of using the pin as a simple on/off switch. That means each strobe pulse must last for a multiple of 256 frames, and I’m not synchronizing to the PWM counter so most pulses end up being 0.384 ms while some are 0.512 ms. Or maybe it’s 0.256 ms vs 0.384 ms, it’s hard to tell. Regardless, they’re short enough that the PWM cycles become an issue, and I’ve been meaning to fix it for ages.
If you prefer single-flash for bike mode, go for it. It saves space and might look nicer. I put it in the code for those reasons.
I’ve built two drivers with where soft start caused a very slight studder when advancing modes. It would jump to a level close to the intended level and then reach that level. Reflashing with soft start disabled eliminated the problem in both lights and reappeared when flashing back to enabled. Just a weird observation.
Same thing I noticed wen using the tripledown drivers. I did not notice it on the Avenger drivers, so pretty sure it is due to the voltage spike that DEL discovered.
