luxdrv - custom modes driver firmware with ramping

I downloaded it via torrent :smiley:

I must have tried like 4-5 different versions, from 4 over 5 to newer 6ā€¦ and not a single one wanted to finish compiling until I installed 5.1 build 208ā€¦ butā€¦ all them were tried with Dr.Jonesā€™s luxdrv firmware, it might have been that Tidoā€™s would finish compilingā€¦ who knowsā€¦

But for now, itā€™s workingā€¦

Aaaaandā€¦ I have like 4 projects I have to finish before I can continue with programmingā€¦ hopefully someone would jump in and help with memory timing with Tidoā€™s firmwareā€¦

This fact doesn't hold true when using PWM dimming. During the on time of the PWM Cycle, the LED is being driven with the full current of the regulators (2.8A for a 8X7135). During the off time of the PWM Cycle, the LED current is zero. Because of this, the efficiency gains of lower current drive are not seen. This is also why PWM dimmed lights do not exhibit tint-shift. Since the LED is being driven at the same current no matter the brightness (just not all. Most the time), the light output doesn't shift in color.

The other thing to remember with PWM is that your meter likely can't measure current draw very accurately because of it. Especially the lower duty cycles are very difficult for a DMM to measure. To accurately measure PWM Current draw, your meter has to average the on time and off time current and figure out the duty cycle. Depending on the resolution of the meter, this measurement could be very error prone. PWM signals really require more advanced equipment to measure with any degree of accuracy.

PPtk

Uh, ohā€¦ actually that makes a complete sense, now that youā€™ve elaborated it that wayā€¦ I never thought about those facts that way even if Iā€™m using PWM drivers all alongā€¦ Even Solarforce 0.8-4.2V 3-mode driver or Lumens Factory low voltage 3-mode drivers are PWM regulated on medium and low, right ???

So basically we can guesstimate these amp draws but also outputs in these situations ???

So basically PWM values of 10/51/255 ARE in fact 4, 20 and 100% even if multimeter doesnā€™t show it like that ? The light output will be 4, 20 and 100%?

Nearly. Within a few seconds, thermal sag will reduce output on the higher modes - the amount depends on the lights heat sinking capabilities.

I FINALLY got it! Found a AS5 5.1.208 torrent,

...and then Build -> Build [project name]. NOT 'Build project [F7]'. .hex & .eep files will end up in the project's debug folder, renamed and moved to their own safe spot, then

avrdude -p t13 -c usbasp -u -Uflash:w:luxdrv.hex:a -Ueeprom:w:luxdrv.eep:a -Ulfuse:w:0x75:m -Uhfuse:w:0xFF:m

and YAY, it works!

I know that to the folks who can do this stuff from scratch this must seem like someone being excited they finally figured out how to turn on a light switch... :p

Oh, I thought you were already building themā€¦ my badā€¦ I found some page that went with direct download from Atmel page, downloaded web version (smaller one) and it went thruā€¦ unlike full install, it wouldnā€™t start the installationā€¦

But thanks to slow downloads and majority of installations not being able to build right away, I can understand your joyā€¦ well, Sirius9 is on the same boat, Iā€™m sureā€¦

Now onto serious stuff, huhā€¦ :slight_smile:

Yeah, that i.amniels page with direct links goes to Atmel's copy of 5.1.208, which is broked. Broken version is 594MB, working version is 601MB, same filename.

Now that I have a known-working software & hardware setup, I can start playing. Hopefully with the knowledge that if something doesn't work it's something I did and not something in the software (which I clearly don't understand well enough yet to track down what the problem is). I'm not good with making sense of just written explanations, I have to see it work in person before the fog starts to clear.

WHAT CAUSES THIS??! It's a normal x when I quote either my original post, or when I quote your reply. But somehow your quote swapped that character to something that's not an x.

Oh, Iā€™ve seen that happen here on BLFā€¦ something with BLF quoting formattingā€¦ few members had issues because they were copy/paste someoneā€™s post and couldnā€™t flash the driverā€¦ only when they manually typed it workedā€¦ or after they realized x is turning intoā€¦ xā€¦ :slight_smile:

Ehā€¦ but it only swapped it in numbers sequence (0x75)ā€¦ maybe formatting is turning it into x-variable instead of letter x which are different for machines - no common sense to distinguish the two based on used situationā€¦ :slight_smile:

But I love that Whiskey Tango Foxtrot commentā€¦ lol

Weird, no more interest in this thread!

So, last night I build on 10 AMC nanjg with this firmware (2 modes, very fast memory function), tested it and it whines horribly :expressionless: I thought maybe itā€™s because I added 2 AMC regulators so I burned identical firmware to stock 8xAMC nanjg 105C and itā€™s the same, whines just not as loud as with 10xAMC!!!
Any ideas what may be the problem?

I sure wish we could figure out what the daggum whine is all aboutā€¦

Here is the compile speed for luxdrv
#define F_CPU 4800000 //CPU: 4.8MHz PWM: 9.4kHz ####### use low fuse: 0x75 #######

Anyone know how to tweak it up to 9800000 (that might reaaaaly screw up the timing and everything though)

I have a stock version of his compiled if you need it
https://www.dropbox.com/sh/h7sldo9ghbl7py8/AAAdZvIIuBkdqwfBm9zQbQswa

Maybe DrJones or JohnnyC could explain if we changed the code from #define PWM OCR0B //PWM-value to #define PWM OCR0A //PWM-value what it might do and/or change the F_CPU speed

Reading thru this makes my brain hurt
http://avrbasiccode.wikispaces.com/

that is default setting, and for burning the hex:

TCCR0A=0b00100001 is 9.4kHz PWM, change it to TCCR0A=0b00100011 for 19kHz. Use the same fuses (don't mess with the CPU frequency).

9.4kHz makes so much noise because the human ear is relatively sensitive to that frequency, and anything in the light that can move has the potential to turn into a speaker (springs, ceramic capacitors, springs, switch contacts, even the battery rubbing the inside of the tube or the driver PCB itself). These drivers go from full current to zero current 9 or 19 thousand times each second, high current pulses like that can make the parts the current goes through physically change shape, which gives the potential to create noise. It's not that the 19kHz firmware isn't creating the same amplitude vibrations, it is, but it's just up at a frequency most humans can't hear.

but I used 4.8MHz before and it was fine!!! so annoyingā€¦

The CPU speed isn't the issue, that is unrelated to the PWM frequency. Changing the CPU speed won't make a noisy 9.4kHz firmware be not noisy. Change the PWM setting and it will stop whining at you.

Line 67 in the original luxdrv-030.c file:

#define pwminit() do{ TCCR0A=0b00100001; TCCR0B=0b00000001; }while(0)  

change it to:

#define pwminit() do{ TCCR0A=0b00100011; TCCR0B=0b00000001; }while(0)  

yep, that did the trick :slight_smile:
thanks comfy :beer:
Just for testing I used
#define MODES 255, 100, 35, 6
nice and quiet 3.55A leaking from the ncrpf cell :wink:
but I still donā€™t understand what changed in the meantime, I was using ā€œoldā€ code normally, with no whining! Is it possible that they are now using lowes possible quality components because Nanjg 105C become so popular and everyone wants to offer lower price on them?

Please help, I can not build the hex file for Luxdrv0.3b for this error. ā€¦/luxdrv-03b.c:48:14: error: variable ā€˜modesā€™ must be const in order to be put into read-only section by means of ā€˜attribute((progmem))ā€™ at the line 48 ā€ PROGMEM byte modes={ MODES }; ā€

I did a stock compile of DrJones luxdrv-030.c with the fast PWM from above (I also have the stock version in the share as well)
Levels are compiled in as #define MODES 6,15,56,255, RAMPING, STROBE, BEACON

https://www.dropbox.com/sh/h7sldo9ghbl7py8/AABUGmE2vQ8mX8dcB0vYxDf6a

Sirius9 does your compile go Hi>Lo? Would you share your code and I will compile and share in the repository?