Hello.
It is possible, make a backup of the original firmware 105c driver? …. Or firmware is protected?
thanks
Alexander
The original NANJG firmware is protected and can't be backed up.
You could use NLITE as an alternative.
My QLITE rev A drivers don’t seem to be protected. I have not tried to read/reload the firmware, but the protection fuses are not set.
Yes, that's why I knew what exactly they did wrong (PWM in high). 
EEEEWWW…. really?
It’s not much, due to an error in their programing of the PWM generator, there is a very short (1 timer tick out of 256) glitch in the output when the light is on full. And due to the response time of the AMC7135 chips, not all of that glitch makes it to the output. Still, it’s rather bad form to let something like that by…
Also, regular NANJG 105 drivers also do it…
So, here I am, finally started to mess around with this, for start I just made new project in AVR Studio 4, project tipe: AVR GCC, copyed code from luxdrv-030.c to project window -> Build, and I get this msg:
always missing this *.elf file!!!
Also, how to get all those necessary files from nlite.hex or I can transfer hex directly to MCU with just:
remowed this: -Ueeprom:w:BLF-VLD.eep:a
For flashing Nlite I just have a .bat file with this inside:
avrdude -p t13 -c usbasp -u -Uflash:w:nlite.hex:a -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m
Has to be in the same folder with nlite.hex, of course.
I have compiled the code of luxdrv-03c by AVR Studio 4 without any problem.
Well, that doesnt help much 
no matter what I do I always get same No such file message and the build fails, for some reason *.elf file is necessary to build hex.
What options you selected when opening new project?
I see you have set attiny25 as mcu but Nanjg drivers us attiny13A !
s.
strange thing happened: first I loaded Tido’s BLF-VLD Fixed Modes driver, and that worked fine (a bit confusing interface, thou) then I used upper command to load nlite.hex, avrdude said it’s all fine, job done, but driver still has a Fixed Modes UI as if loading nlite was only simulation and nothing was actually change, weird !
I'm far from knowing what I'm doing with this stuff, but I try to keep each one in its own folder and either use the .bat file in that folder, or open a command prompt from that folder. Sounds like something didn't get changed in the avrdude command and it loaded the VLD files again. Try copy/paste that string of text into a .txt file, save as nlite.bat, and put nlite.hex & nlite.bat in a folder all by themselves.
I opened a GCC new project and then selected the debug platform AVR Simulator 2. I selected attiny25 was because attiny13a does not have temperature sencer built in. Then, copied and pasted to replace the .c file in the folder with the source code. I have tried to compile the code with attiny13a did not have any problem at all.
I finally managed to communicate with the ATiny13A chip… was using FastTech programmer and eBay $12 clip… so frustrated tossed the clip away, took 6 single strand #26 wires and SOLDERED each to programmer AND ATiny13A… sure enough, it’s communicating now… yay…
However… now I have same issues as Sirius9… after I try to Build it in AVR Studio 4, I get following message:
Build started 20.8.2013 at 18:26:45
mmcu=attiny13a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT EGAIN.o -MF dep/EGAIN.o.d -c …/EGAIN.c
“C:/Program Files/WinAVR/utils/bin/sh.exe”: -Wall: command not found
make: [EGAIN.o] Error 127 (ignored)
mmcu=attiny13a -Wl,-Map=EGAIN.map EGAIN.o -o EGAIN.elf
“C:/Program Files/WinAVR/utils/bin/sh.exe”: -Wl,-Map=EGAIN.map: command not found
make: [EGAIN.elf] Error 127 (ignored)
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature EGAIN.elf EGAIN.hex
avr-objcopy: ‘EGAIN.elf’: No such file
make: * [EGAIN.hex] Error 1
Build failed with 1 errors and 0 warnings…
I used same picks for project as Microa in post 191… and it doesn’t work…
I would really like to be able to setup 3 modes with no memory (4%/20%/100% or 100%/20%/4) or 4 modes with no memory (Firefly/7%/25%/100 or 100%/25%/7%/Firefly)…
But I definitely want to try this memory mode that DrJones implemented in his luxdrv driver…
I did a bit googling about this elf file that is missing and causes failure in building *.hex file…
Long story short: I installed newer version of AVR Studio 5.1.208 and that did the thing, now I can build hex files without problems 
I also noticed that I have to do erase procedure every time before uploading new firmware, if I don’t, avrdude would say that uploading went well but the driver would retain old firmware…
Well, considering that AVR Wiki called for AVR Studio 5, I downloaded it as well (5.0.1163) and tried to build again… and… of course… a NEW error…
Error 1 undefined reference to `getmode’
sigh… it’s just too late here, my brain is half sleep… I guess I have to continue tomorrow… I hope someone might help me to figure out why “getmode” is not being recognized…
Sirius9,
When you setup a new project, which options you pick at the start of wizard ? AVR GCC - C Executable Project or what?
you’ve probably just didn’t copy everything from luxdrv-030.c properly, or you accidentally changed something in code, added something or deleted, even one comma sign can cause syntax errors…
File -> New -> Project -> C/C -> AVRGCC C Executable Project -> Device Selection: ATtiny13A -> OK
then delete all that AVR studio automatically put in your new .c and paste all from luxdrv-030.c (use Ctrl+A to select everything).
Question:
how could I calculate which value from 5 to 255 correspond to which % of light output with 2.8A driver (or any other driver with 4-12 AMC7135 chips)?
Well, for the past couple of days I was messing around with Tido’s firmware… also checked amp pulls at different levels (correlated to 5 to 255 values)… so here are the readings (Fluke 117 used):
Value HEX Amp Draw
Val 255 0xFF 1400mA (100%)
Val 128 0x80 _685mA (49%)
Val _64 0x40 _330mA (24%)
Val _32 0x20 _150mA (11%)
Val _16 0x10 __65mA (4.5%)
Val __8 0x08 __17mA (1.5%)
Val 4 0x04_3mA (0.2%)
So it’s not direct linear difference between PWM value and amp draw but it’s somewhere close and based on measurements, one could pick PWM value to achieve targeted amp draw (or percentages)… I have this idea that good spread between low-med-high would be 4, 20, 100% but have to test it first… now fighting with Tido’s code to shorten memory time (it’s 2 or slightly more seconds, want to shorten it to 1 or 7/8 seconds)… this is easy with Dr.Jones’s code but I found a weird glitch when cycling thru modes with his firmware that I don’t have with Tido’s firmware… but I’m yet still to discover how to lower memory kick in time with Tido’s…
As for light output, it’s definitely not linear as modern LEDs are more efficient at lower amperages so 4% of amp draw might give 5% or 6% or even more of total light output at 100% amperage… if I’m making any sense… to accommodate even spread of output levels, we need to take in consideration lumen outputs at certain amperages for specific LED…
Oh, by the way, thanks for tips for setup… I tried older build 5.1 and couldn’t install… then after few painfully long hours downloading few versions simultaniously, I finally succeeded installing 5.1 build 208 (net version) and it’s getting better and better from that point on…
Thanks for the measurements 
somehow I totally forgot that I can do that too :nerd_face:
The 5.1.208 on Atmel's server is broken, try to extract it and you'll get lots of CRC errors, that's why it won't install.