Yes, it is possibly the spring, but that's my point--once you get it installed in a light, you can hear it. Much of the MLCC noise comes from the MLCC vibrating against the PCB.
Tom E wrote:
Seems like I bricked the 45, may be those fuse settings I used, in post #52 above, not sure yet. AVRDude connects fine, then can't verify at address 0x0000 (1st address), so acts like it's bricked. Tried several times, so seems permanent. I'll have to reflow another - dunno if just something flaky, or are they really bad fuse settings.
This looks like a great tool for fuse settings btw: http://www.engbedded.com/cgi-bin/fcx.cgi?P_PREV=ATtiny13A&P=ATtiny45&M_LOW_0x0F=0x09&M_LOW_0x80=0x00&M_HIGH_0x06=0x04&M_HIGH_0x10=0x00&B_SPIEN=P&B_SELFPRGEN=P&B_SUT0=P&B_CKSEL1=P&B_BODLEVEL0=P&V_LOW=79&V_HIGH=ED
This is the Fuse resetter design: http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html
That fuse resetter looks like the simplest design out there. Thanks for sharing that.
I think that is the same fuse tool Halo linked to in Post 2. It can be used in reverse. Just plug in your fuse values in the bottom and see what settings they would give you above. It seems your fuse values in 52 are valid. Is your programmer set to 5 volts?
What specific FW are you using for the DD+7135? I'd like to check it out.
I can hear the PWM whine as well. This is what I got from a smart phone app that seems to be in line with what we are all hearing.
What hardware and firmware did you measure there?
On some lights I can measure PWM speed by using the photoacoustic effect, shining the light at black fabric and holding a mic to it. I haven’t measured inner components though, and high frequencies are hard to separate from background noise.
Yes - 5 volts. Though after several attempts, I did try 3.3v but nothing worked.
Ohh - I'm using my latest eswitch.c. I could post it somewhere for you - I'm @work now though, another 10 hrs or so. You probably have an older version of mine.
How did this thread get so into PWM hums? It's got me hearing all the hums and buzz's here @work coming from all types of equipment 
.
I used a qlite with two extra 7135s and guppydrv. The noise was clearly being emitted near the head where the driver is. I held it up to the mic on the smartphone. The peak was very visable on the app i used. There might have been more peaks higher up in the range that i wasnt able to measure due to the limitations of the smart phone. And i have to say i have never heard of the photoacoustic effect. Thats pretty neat.
As for how we got here i believe it went: what core freq to run, then 6 mhz because that allows you to get 19khz pwm to keep it inaudable and then to 19khz or not we call can hear it. And i really have nothing to add to this thread other then all the fuse setting was why I was thinking of going arduino on a tiny 85.
^ You've already contributed much value to the thread. I'm not going to pretend I understand everything you, led4power, RMM, and ToyKeeper (alphabetical order) are saying, but the hum issue is one of the vexing challenges that we have to deal with in this hobby. So any discussion that may deepen our understanding is all good.
Tom E,
Much appreciated. I will PM my email address to you. I don't have much in programming skills, but I will do my best to read the data sheet and look at the alternate pwm feed portions.
I should note that I don't recall where I read that one pwm channel is for fast and the other for phase. I skimmed the data sheet and didn't see anything like that. So maybe what I read was not correct or I misunderstood it.
Well think about all of the constant current pwmless drivers out there with a pic controling a mosfet. They are all silent but i suspect its because they are running pwm in the mhz range so that by the time all of the harmonics filter down they have no energy left to be heard. I could be wrong but i highly doubt the are changing the enhancement on the gate to vary the current flow. Which wouldnt make sense because the inductor relies upon expanding and colapsing magnetic fields to generate the current and voltage levels so i would think it needs to be an on off afair. I think the real leap in blf driver design will come when we can figure out how to use the micro as constant current switch mode controller.
It seems like pics are exclusively used for this but i dont see why we couldnt do it with an attiny.
We need a PWM-less thread to discuss getting these MCU's working 
.
Well current progress:
- I reflowed a replacement 45, and back to working
- turbo timeout works, and it's dead-on accurate for 2 mins, better than I've seen on 13A's
- timing with the e-switch firmware is great - clicks vs. click/hold works perfect
- strobe works great
- mode changing is working flawlessly so far on one FET channel
- just can't get the alternate PWM channel working with the 7135 - tried FAST PWM on all modes and get no output at all
- tried LVP and doesn't seem to work with a cell even at 2.8v, maybe even 2.7v. It's a 22 wight FET+1 driver so I'm using a 22K resistor. Haven't experimented with values yet, but suspect something basic is not working
. - did not confirm low power sleep mode yet - would be nice to know it's working with a low parasitic drain
Wish I could get a better handle on exactly how these MCU's differ from the 13A. Thought there was some differences in clocks, ports, etc., just cant' find it.
Update: Ok, I got LVP working now as well. Looked at the ADC support, and with the added features in this area (temp sensor, etc.), setting the 1.1v reference is now a different bit in the ADMUX register. I had a weak cell at about 2.7v, and sure enough, the firmware backed down output in steps til output dropped altogether - just what it supposed to do!
Now, still got dual channel support to figure out, with the PB0, pin #5 7135 output.
Great work Tom! I'm planning on working on this some more early next week. Want to get that temperature sensor going.
Hhmm. It all seems to be working now. Even the Phase Correction on 7135. All tests seem to be correct - amps indicate is truly working off the 7135 in the 1st 3 modes. Dunno what was wrong before - didn't "fix" anything, I don't think... Weird, but this is really nice!! Now I can do some serious programming with a whole nother 1K bytes (Tiny25) of code space !
Yes - the temp sensor would be huge as well, for sure.
Update: ZIP files of project/source code and BAT files are shared here: drive.google.com-244585. Hope this link works. You may have to sign in to Google in order to download, not sure...
This is for a wight style FET+1 driver with default 5 modes, first 3 on the 7135. It has a turbo timeout set to two minutes. I've only tested it on a ATTiny45 which should be running at 8 Mhz. It's not taking advantage of the 45's extended capabilities yet: temp sensor, extended available memory, etc.
Way to go Tom. You are the man! I finally got a 22mm board working and tested the UI of the FW you sent me earlier today. Same results as you reported. It worked great except for the Alt PWM channel. I started examining the code and came back to report and call it a night. My gosh, you got a lot done tonight.
Tom E just opened up the hobby to a whole new level!
EDIT: Status in OP updated.
Wow, guys, this is awesome! What I’d like to see is a guppydrv style mode group selection but using more advanced mode groups like we have on the BLF-A6 FW.
Funny, I was think'n the same exact thing - guppy style mode group availability w/advanced mode nav, w/all the bells and whistles of LVP, OFF time detection using a cap or brownout detection, temp sensing based output limiting, full e-switch and/or power switch support. And, of course, it should all be done in one firmware version.
This opens the door to a whole lot more versatility.
My first step (for me) is to get back to adding full power switch support w/OFF time detection to the e-switch firmware, so lights that have both can have it both ways - lights like the X6R, Yezl Y3, L4, and many others. I ran out of program space when a I tried this before. Could also be used for e-switch lights with a lock-out feature, so you have the effectiveness of a twisty, still with full e-switch support.
So, you’re saying that the firmware will have all the fancy mode groups and UI controls available to either e-switch or clicky, or even both in the same light - all supported in one firmware to rule them all? And, it would be cool to have both tighten-for-on (the standard twisty UI) and tighten-for-off (not very common, but better, IMHO) capabilities in the same firmware. Oh, and to complete the laundry list - both forward and reverse clicky support optimized. All of this should be user-programmable (or rather user selectable ) through the UI. Am I asking too much? 0:)
Probably short answer is yes - you are asking too much, or dreaming like me . Besides, “There is only one Lord of the Firmware, only one who can bend it to his will. And he does not share power.”
However, “That there’s some good in this world, Mr. Frito… and it’s worth fighting for.”
Ran Tom E's FW through some paces and it did great. UI is solid and reliable. Strobe is great. I think Turbo timed out at 2min 6sec. Could not get it to exhibit any glitches. Very nice.
I tried working the LVP, but fried an emitter due to a careless turn of the bench top voltage dial. I never get reliable results trying to test LVP with my bench top power supply anyway. Don't have time to try testing with cells tonight.
It's a winner in my book. I'm going to go work on designing the OSH Park boards I discussed in the OP. Want to get those available and also place an order since they can have long lead times.
I did the bench PS testing, and it trips at 3.1v, so the ADC_LOW should be set at 120, and ADC_CRIT at 110 to get 3.0v and 2.8v, respectively.
Darn - just bricked another 45 MCU (can't verify the dnld). It doesn't work after this occurs, so something must be goin wrong in the AVRDude dnld process. I was able to do quite a few dnlds though before it happened again.