[WIP] 17mm DD+single-7135 driver / single sided / Dual-PWM

fyi, this was the ticket communications I had with "Dan" at OSHPark. Interesting read:

-------------------------
Hi!
For order #nnnnnn, for these boards: https://oshpark.com/shared_projects/7sNNyipn, all three came with an error where the bottom should have exposed copper circle of 10mm, instead, it's all covered in purple. Others have ordered these same boards without this problem. Any ideas what happened? Can anything be done to replace the ones I received with corrected ones, or is there something wrong with the project files?
Thanks!
Tom
-------------------------
Hi Tom,
That's really weird. I'll get a new set of those shipped out to you. Doesn't appear to be anything specifically wrong with the project files, although Alex's boards have a slight history of confusing the bajeeezus out of the fab. I think this is the 4th design of his I've seen that has some random issue that comes up. Fortunately, they seem to pop up once, and never happen again.
-Dan
-------------------------
The replacement boards I received had no problems, but RMM - you could still be correct, there's something goin on confusing the fabrication, probably based on where in the panel it is, and/or what it's around.

Just received an order of these boards, and all seems to be well. I could've overlooked something, but everything seems to be where it should.

I know that in the past there have also been mask issues with some of wight's other boards as well, but I can't pretend to understand what is going on there since the gerbers and renders look alright.

I have ordered 3 batches of this board and personally haven’t had a problem with them, but I have seen inconsistencies with other boards from Oshpark.

I will say, Oshpark customer service is the best I’ve ever talked to. Knowledgeable, personable, and non-robotic.

I have had huge differences in silkscreens (precision and cutoff) and sometimes some minor milling errors, but never a huge mask issue like this, and I've ordered thousands of boards.

but were they the wight boards? Smile Dunno, maybe something bout what he does is technically correct and follows the rules, just confuses the panel fab software/system on occasion... Dan from OSHPark is sort of implying that.

Agree though - their support seems excellent, as shown in my copied response from them above. I got those replacement boards pretty quick too, like they put a rush on them.

No, they weren't wight's boards (that was the point I was trying to make).

Yes - I know, sorry, sarcasm Innocent. Ohh - got a couple of your RMM Mtn boards in - really like the design, like having those ground rings fully exposed and significant in size. Don't think you are offering the FET+1 board yet - would love to see one. Not sure if wight will be back, and actively supporting these in the near future.

Btw, 1000's is totally insane!! Those kind of #'s... Just can't get much sleep, 24/7 "time to make the boards"...

I think these boards are pushing the envelope as to what they can do. Here is my response from OSH re: solder mask over the ground ring:

Not knocking Wight in any way. OSH is happy to fix their mess up. My boards got put on a “Super Swift Service” panel today.

Checked this afternoon and the order has gone to fab again.
Good response!

Virtually every board I have of Alex’s has most of the batt side ground ring covered up. I simply scrape em clean and move on. Some of them have way too much exposed at the batter contact, completely eradicating Alex’s name and the BLF statement as to the version number.

But they work. They just take a minute or two more to build. No biggie when you’re only doing a few at a time.

I need a simple firmare for this driver in a rear clicky light. I found tk-otc and it seems perfect. Here is what the description says:

* Generic clicky-switch-with-offtime-cap firmware.
* Expects a FET+1 style driver, supports two independent power channels.
* Similar to blf-a6.c but minus the end-user config options.

But, I downloaded the .hex and flashed it on the driver it does all kinds of crazy stuff. Sometimes the light flashes and it does not switch modes as expected.

Can someone point me to a firmware? I want it to be simple, I need no things like batcheck or strobe modes etc. It should use the otc and have a dual pwm function.

STAR Off-Time or ToyKeeper's Starry FW.

thanks, but with the starry fw I get an error if I try to build it

And the star off-time fw I don’t get how to get dual pwm to work properly. It says

What should I put here if I use the default modes? What does the number 8 says?

I would prefer a more inuitive method like in the tk-otc fw

finges, this might be helpful:

http://toykeeper.net/torches/finges/

I took starry-offtime and tk-otc and did very small modifications to them to do what it sounds like you want:

  • Turned off all blinky modes.
  • Turned off 3-level offtime (so, it only senses short and long presses, no medium).

This should also reduce the size by enough that you can rebuild them without any special options. I got 812 bytes (69.3) for starry-offtime and 562 bytes (54.9) for tk-otc.

If you need any help calibrating the PWM levels for the FET and 7135, the bin/level_calc.py tool can estimate what those numbers should be according to your specs and lumen measurements. For example, to get six evenly-spaced modes on a FET+1 with XP-L emitter (including moon mode):

> ./bin/level_calc.py
How many total levels do you want? (4) 6
Lowest visible PWM level, for moon mode: (6) 1
How bright is moon mode, in lumens? (0.25) 10
How bright is the highest level, in lumens? (1000) 1300
Use dual PWM? [y/n] (n) y
Second channel, lowest visible PWM level: (6) 4
Second channel, how bright is the lowest mode, in lumens? (0.25) 0.25
Second channel, how bright is maximum, in lumens? (140) 140
1: visually 0.63 (0.25 lm): 0.00/255, 4.00/255
2: visually 2.69 (19.39 lm): 0.00/255, 38.39/255
3: visually 4.74 (106.74 lm): 0.00/255, 195.26/255
4: visually 6.80 (314.48 lm): 33.39/255, 255.00/255
5: visually 8.86 (694.83 lm): 108.28/255, 255.00/255
6: visually 10.91 (1300.00 lm): 255.00/255, 0.00/255
PWM1/FET  values: 0,0,0,33,108,255
PWM2/7135 values: 4,38,195,255,255,0
On a non-FET driver, the last mode should be 255 on both channels.

You may also need to calibrate the CAP_SHORT value, depending on how fast your offtime capacitor drains.

wow great work, thank you ToyKeeper

I flashed tk-otc on my driver and it works good.

Now I only would like to reduce the number of modes, I don’t need 7 or 6 modes.

Where exactly can I find the level_calc.py tool?

It’s under bin/ at the firmware repo linked in my signature.

You can, of course, also adjust the levels manually. The tool just gets you some ballpark estimates to start with.

Ok thanks, found it. Yes I know that I can adjust the levels manually, but in previous drivers I had trouble to find the right values for a linear increase in brightness.

Anyway, I have another problem with this driver. I build another one but now with a zener mod for a light with a XHP50 and rear clicky.
I flashed the same firmware as on the non zener modded driver and now the mode switching is totaly buggy. It seems it switches at random, sometimes I need to half press the button like 10 times to get it to switch. It also sometimes starts in moon mode and stays on for around 10sec and than switches off. Sometimes it cycles through the modes high to low and sometimes low to high … and so on.

Do I need to change some values in the firmware for zener modded drivers?

Yes. And you may need to change some of the resistors too, if you want any voltage-related functions to work. Or it might need voltage-related stuff turned off entirely.

The PWM levels will also need recalibration for each type of emitter, since the relative contributions of the FET and 7135 change. A single-channel driver can usually get by with one set of levels for all emitters, but two-channel drivers need the firmware reconfigured/rebuilt for each.

(if a light maxes out at 4amps, the 350mA channel can handle 8.75% of the total, but the 350mA channel can only do up to 2.3% on a 15-amp light… and the relative balance should be updated in the firmware to account for this)

Ok, so I think I need to change the CAP_SHORT value, and I can use offtime-cap.c to calibrate it, am I right?

And to get the right resistor values, I use the battcheck firmware?