This is driving me crazy. All I did was edit the LVP, OTC, and TT values in blf-a6. I’ve set AVRStudio to optimize for size, but now when I go to flash it still says it is too big. My hex file is 2,922 bytes.
Maybe someone else can try to compile it to see if it comes out smaller? What size am I shooting for?
k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? - I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn't directly meaningful. You could edit the .HEX and see where the last records end - little trickier though.
@work - don't have latest 6.2 version installed here, or time to dnld projects, etc.
k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? – I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn’t directly meaningful. You could edit the .HEX and see where the last records end – little trickier though.
@work – don’t have latest 6.2 version installed here, or time to dnld projects, etc.
Ok, it compiles to 1032 bytes both before and after my changes. Does version of AVR matter? I am using version 5.1
k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? - I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn't directly meaningful. You could edit the .HEX and see where the last records end - little trickier though.
@work - don't have latest 6.2 version installed here, or time to dnld projects, etc.
Ok, it compiles to 1032 bytes both before and after my changes. Does version of AVR matter? I am using version 5.1
Ohhh - I started with 6.0 and am on 6.2 now. It could the issue. Might have made optimizing improvements in newer versions. Just 8 bytes over - close
Good News! I think in the beginning, someone posted having probs with 6.0, so most people stuck with the older 5.x tools, but I quickly found the problem and fixed it - some compiler directive, or mnemonic that luxdrv had in it, I think.
Thinking of implementing a lock-out like this in my e-switch firmware for the 25/45/85. This is from a review on the Sunwayman C15A:
Lock out: The flashlight should be more than seven seconds off, press 1 click and maintain a second click (short flashing) the flashlight will be locked. To unlock, do the same.
Not sure if it's the best way, but I got a couple of side switch lights that don't have lock-out threaded connections, so something like this might just work. Richard's SupFire M2-Z is one example. Dunno bout that 7 second delay though - seems odd.
That's another way, just that if the button was stuck on, it would go to last mode? I really dunno what is better. I think the quick click to hold might not be so easily reproduced in a pocket or bag. I know my F6 had gone on in my pocket sometimes when I forget to lock it out.
You know that F6 is simply an awesome light! I got the Convoy (2nd version) and drilled a hole in an indent next to the switch and mounted a light pipe (tube) in there now. Works really well - on the nightstand it's a clear low green glow - bout perfect. Didn't know the light is the exact match/copy of the Sunwayman C15A (http://budgetlightforum.com/node/21628), just the C15A is a small tube for an AA/14500 cell. The C15A's switch looks better. Actually I might buy one from ILLUMN if I can get a good deal - they've been great before. He's got them marked down to $33 now (illumn.com/sunwayman-c15a), hoping the F6 driver will fit, and swap the LED. I have a T5-5D3 LED in my F6 and it's just a perfect milky white, at least to these ol eyes. I want to add a 2nd light pipe towards the rear, in another indent - it would be closer to the color LED's and should be even brighter. This light works so well with a SANYO GA cell - not as quickly burning hot as with a higher amp cell.
I got the Convoy (2nd version) and drilled a hole in an indent next to the switch and mounted a light pipe (tube) in there now. Works really well – on the nightstand it’s a clear low green glow – bout perfect.
I’d love to see a picture of that, sounds very cool.
I only just how had a chance to look over your BLFA6 UI. That is really great. It adds a whole new dimension to the open source pool for sure. I can hardly wait to start playing around with it.
Thanks again.
—
In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not. http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.
TK, I was still puzzled by the much lower than advertised PWM frequencies we see (and hear) on the BLF A6 and re-flashed Nanjg drivers.
I get 13 kHz – 14 kHz, as opposed to the expected 18.75 kHz.
The delay_loop_2 function that is supposed to take 4 CPU cycles is also way off, as you probably noticed.
There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but
this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data
during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL
register must be updated by firmware. The calibration data for 4.8 MHz operation is located in
the high byte at address 0×01 of the signature area.
It seems the specified 10% clock accuracy is only valid if using the default 9.6 MHz internal oscillator (and at 25 C and at 3 Vcc).
Maybe I am just late to the party, otherwise I hope this bit of info is helpful.
A fix, without getting into the user calibration procedure, would be to manually write the 4.8 MHz calibration data (it is there, just not used) to the calibration register.
Personally I decided to run at 9.6/8, phase-correct PWM only (2.352 KHz). Any higher and the PWM signal turns ugly on an oscilloscope. Probably not a good option if you want to avoid noise with a high-current driver. Also slightly higher MCU power consumption.
PS. Your s7.c firmware got me started in this. Thank you !
Thanks for this thread and the work. I was wondering if you might include Tido’s work in the repository (or maybe it’s there and I missed it), the BLF-VLD:
TK, I was still puzzled by the much lower than advertised PWM frequencies we see (and hear) on the BLF A6 and re-flashed Nanjg drivers.
I get 13 kHz – 14 kHz, as opposed to the expected 18.75 kHz.
The delay_loop_2 function that is supposed to take 4 CPU cycles is also way off, as you probably noticed.
There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but
this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data
during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL
register must be updated by firmware. The calibration data for 4.8 MHz operation is located in
the high byte at address 0×01 of the signature area.
It seems the specified 10% clock accuracy is only valid if using the default 9.6 MHz internal oscillator (and at 25 C and at 3 Vcc).
Maybe I am just late to the party, otherwise I hope this bit of info is helpful.
A fix, without getting into the user calibration procedure, would be to manually write the 4.8 MHz calibration data (it is there, just not used) to the calibration register.
Personally I decided to run at 9.6/8, phase-correct PWM only (2.352 KHz). Any higher and the PWM signal turns ugly on an oscilloscope. Probably not a good option if you want to avoid noise with a high-current driver. Also slightly higher MCU power consumption.
PS. Your s7.c firmware got me started in this. Thank you !
Thanks!
This probably explains why the attiny25 appears to run so much faster than the attiny13. And why selfbuilt measured “15 kHz circuit noise” instead of 19 kHz. I expected the tiny25 to be 166% as fast, but I measured about 210% instead, perhaps because the 13 is running slower than expected. I suppose I should probably figure out how to activate the attiny13’s 4.8 MHz calibration data…
As for 9.6 MHz / 8 (2.3 kHz PWM), it’s not used because faster clock speeds use more power… and because I find 2.3 kHz PWM both loud and obnoxiously slow. Anything under 10 kHz is hard for me to not see, so I try to keep the pulses fast enough that they’re a little beyond the human perceptual range.
BTW, how do you measure the PWM speed? Above ~3 kHz I can’t usually get a loud enough signal to measure it with a microphone. I’ve been tempted to try an optical sensor instead, maybe wiring up an LED in reverse, shining a light at it, and sending its output to a nice DMM, the DMM might be able to measure voltage pulse speeds… but I haven’t tried it.
I've used a scope in the past to measure high PWM's, just needed help from guys here @work to set it up. Great though seeing the exact waveforms, sliding the markers to get a precise measurement - pretty cool.
For the 25/45/85's, I'm really liking the 8 Mhz operation - the timing for every driver/MCU I tried has been dead-on accurate with no calibration -- 90 secs turbo timeout is accurate to within a second, and even that slop is probably me using my stopwatch.
I know it must be using more power than the 4.8 Mhz 13A, but thinking it's pretty insignificant in terms of LED ON and standy mode power - dunno the detials though.
I was wondering if you might include Tido’s work in the repository (or maybe it’s there and I missed it), the BLF-VLD:
I didn’t have that in the repo, but it’s included now.
I’m not sure how I missed that one. It looks like it’s pretty decent, has some interesting tricks, and is free under the GPL.
Hi,
Thanks. BTW, it appears you looked at the code? Might you have any idea why the “fixed mode” version (not the “simple” one and not the “extended” one) might be giving me only two modes (kind of “high” and “medium”) and it seems to be skipping clicks, i.e., I’ll click, click, click, and then light will light then click, click….. click and then it goes off, then click, click…. and then different mode. Its like it’s missing the clicks?
As for 9.6 MHz / 8 (2.3 kHz PWM), it’s not used because faster clock speeds use more power… and because I find 2.3 kHz PWM both loud and obnoxiously slow. Anything under 10 kHz is hard for me to not see, so I try to keep the pulses fast enough that they’re a little beyond the human perceptual range.
BTW, how do you measure the PWM speed? Above ~3 kHz I can’t usually get a loud enough signal to measure it with a microphone. I’ve been tempted to try an optical sensor instead, maybe wiring up an LED in reverse, shining a light at it, and sending its output to a nice DMM, the DMM might be able to measure voltage pulse speeds… but I haven’t tried it.
I am still debating the 2.3 kHz PWM. I can see it when flicking a credit card, otherwise not. But I much prefer the resulting signal on the oscilloscope. Power consumption also seems lower actually. I get ~1 mA in between the flashes of a 5 s beacon. A 4.8 MHz clock gives ~2 mA. (I am running the MCU with the 9.6 MHz and 8 pre-scale fuses set, so 1.2 MHz.)
With an oscilloscope it is of course easy to measure the frequency. I also have a few FFT apps on the phone that seem to be reasonable accurate (E.g. FrequenSee HD and Speedy Spectrum). FFT with logarithmic amplitude scaling is the way to detect frequencies. The base and harmonics really pop out. They have no problem picking up the BLF A6, especially using your black cloth trick.
Using a regular 5 mm diode as a photo detector does work with the oscilloscope (I use a green or red one). Mode 2/7 on the A6 gives a ~0.5 Vpp signal with ~1.5 V DC offset. Just the bare LED between the scope probe and ground at 2” from the light. Neat to check strobe frequencies etc. without opening the light.
I just tried it on 3 different multimeters, it only worked on an older one.
I posted on my other thread that I just tried nlite.hex and that seems to work well (3 modes) on one of my NANJGs.
Does anyone know which ones are designed to work with NANJGs/7135 drivers? I’ve tried a few and many behave similar to the BLF-VLD with NANJG, i.e., the modes are somewhat inconsistent.
Thanks. BTW, it appears you looked at the code? Might you have any idea why the “fixed mode” version (not the “simple” one and not the “extended” one) might be giving me only two modes (kind of “high” and “medium”) and it seems to be skipping clicks, i.e., I’ll click, click, click, and then light will light then click, click….. click and then it goes off, then click, click…. and then different mode. Its like it’s missing the clicks?
I didn’t look at the code very closely, so I’m not sure how the UI works. However, I think it uses on-time memory… so the only “clicks” which really count are the ones which happen immediately after it gets power. I’m not sure what the on-time timeout is though, or how exactly it handles memory.
Mostly, I noticed that Tido used some interesting code techniques which are totally different than STAR. It looks like he has done a lot more C programming than I have; mostly I use Python and shell so my C is rusty.
Something else I noticed is that it only uses 3 slots for wear-levelling… so it’ll wear out the eeprom about 10X as fast as STAR or 20X as fast as blf-a6. Most of the eeprom is used to store the mode table, instead of putting that in regular ROM or RAM.
ohaya wrote:
I posted on my other thread that I just tried nlite.hex and that seems to work well (3 modes) on one of my NANJGs.
Does anyone know which ones are designed to work with NANJGs/7135 drivers? I’ve tried a few and many behave similar to the BLF-VLD with NANJG, i.e., the modes are somewhat inconsistent.
Anything tagged with attiny13a and ‘ontime’ memory should work fine on a nanjg.
I am still debating the 2.3 kHz PWM. I can see it when flicking a credit card, otherwise not. But I much prefer the resulting signal on the oscilloscope. Power consumption also seems lower actually. I get ~1 mA in between the flashes of a 5 s beacon. A 4.8 MHz clock gives ~2 mA. (I am running the MCU with the 9.6 MHz and 8 pre-scale fuses set, so 1.2 MHz.)
…
Using a regular 5 mm diode as a photo detector does work with the oscilloscope (I use a green or red one). Mode 2/7 on the A6 gives a ~0.5 Vpp signal with ~1.5 V DC offset. Just the bare LED between the scope probe and ground at 2” from the light. Neat to check strobe frequencies etc. without opening the light.
I just tried it on 3 different multimeters, it only worked on an older one.
Yeah, 2.3 kHz seems too slow. Even 4.5 kHz stands out to me during regular use, and I can see up to about 20 kHz with the credit card trick. (if I look really closely, I can just barely see the 31.25 kHz PWM on attiny25)
I wonder if the clock divider puts the MCU to sleep for 7 of every 8 cycles. That would explain the lower power use. Given Atmel’s design goals, I bet it does something like that. Or, it could actually be running at a slower speed, underclocked.
Now that you’ve confirmed it works, I really want to try the LED photosensor trick. Until today it was just a random idea I had, but hadn’t actually tried… I’m pretty sure my DMM has some sort of relevant mode for that, though I haven’t explored that yet. It’s a Fluke 8846A which is mostly used for automated testing at work, but I can do other stuff with it between tests.
Yeah, 2.3 kHz seems too slow. Even 4.5 kHz stands out to me during regular use, and I can see up to about 20 kHz with the credit card trick. (if I look really closely, I can just barely see the 31.25 kHz PWM on attiny25)
I wonder if the clock divider puts the MCU to sleep for 7 of every 8 cycles. That would explain the lower power use. Given Atmel’s design goals, I bet it does something like that. Or, it could actually be running at a slower speed, underclocked.
Now that you’ve confirmed it works, I really want to try the LED photosensor trick. Until today it was just a random idea I had, but hadn’t actually tried… I’m pretty sure my DMM has some sort of relevant mode for that, though I haven’t explored that yet. It’s a Fluke 8846A which is mostly used for automated testing at work, but I can do other stuff with it between tests.
The more I look at this, the more I realize full power PWM is not the way to go. LEDs really crave current regulation. If only we had an LD-2 with an ATMELMCU
In the meantime I will hack an 8×7135 into two or three controllable groups of 7135s, as others have done. Only first group with PWM to get the very low modes.
For the photosensor, just connect the LED between the ‘LO’ and ‘HI’ inputs on your meter and select frequency. If the signal is large enough for the frequency counter to trigger, you will have a reading. If not, the LED signal will need to amplified and the DC offset removed.
I’ve been able to build a .hex – just using the minidrv for now.
I’ve been messing around with the modes, and I was wondering what is the minimum value for that in the array? From the comments, it looks like minimum is 5, but is that the lowest mode I can get? If so, it still seems kind of bright, so how do they get those moonlight modes that are lower than that?
This is driving me crazy. All I did was edit the LVP, OTC, and TT values in blf-a6. I’ve set AVRStudio to optimize for size, but now when I go to flash it still says it is too big. My hex file is 2,922 bytes.
Maybe someone else can try to compile it to see if it comes out smaller? What size am I shooting for?
Here is my .C file
My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03
Major Projects: Illuminated Tailcap, TripleDown/TripleStack Driver
k, take small steps. First try it with no edit changes whatsoever. Your target size for code is 1024, data is ?? - I forget, maybe 64 or 128?? You should see that final code size somewhere. The file size of the .HEX file isn't directly meaningful. You could edit the .HEX and see where the last records end - little trickier though.
@work - don't have latest 6.2 version installed here, or time to dnld projects, etc.
Ok, it compiles to 1032 bytes both before and after my changes. Does version of AVR matter? I am using version 5.1
My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03
Major Projects: Illuminated Tailcap, TripleDown/TripleStack Driver
Ohhh - I started with 6.0 and am on 6.2 now. It could the issue. Might have made optimizing improvements in newer versions. Just 8 bytes over - close
Just in case you haven’t already done so, set your build type to “Release” rather than “Debug”. That produces smaller file sizes for me.
Got version 6.2 installed – no other changes – it now compiles to 1000 bytes
My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03
Major Projects: Illuminated Tailcap, TripleDown/TripleStack Driver
Good News! I think in the beginning, someone posted having probs with 6.0, so most people stuck with the older 5.x tools, but I quickly found the problem and fixed it - some compiler directive, or mnemonic that luxdrv had in it, I think.
Thinking of implementing a lock-out like this in my e-switch firmware for the 25/45/85. This is from a review on the Sunwayman C15A:
Lock out:
The flashlight should be more than seven seconds off, press 1 click and maintain a second click (short flashing) the flashlight will be locked. To unlock, do the same.
Not sure if it's the best way, but I got a couple of side switch lights that don't have lock-out threaded connections, so something like this might just work. Richard's SupFire M2-Z is one example. Dunno bout that 7 second delay though - seems odd.
FWIW, the way I did locking on Ferrero_Rocher/Baton.c is:
I haven’t used it much on a real light though… simply copied the UI from the popular Baton series.
That's another way, just that if the button was stuck on, it would go to last mode? I really dunno what is better. I think the quick click to hold might not be so easily reproduced in a pocket or bag. I know my F6 had gone on in my pocket sometimes when I forget to lock it out.
You know that F6 is simply an awesome light! I got the Convoy (2nd version) and drilled a hole in an indent next to the switch and mounted a light pipe (tube) in there now. Works really well - on the nightstand it's a clear low green glow - bout perfect. Didn't know the light is the exact match/copy of the Sunwayman C15A (http://budgetlightforum.com/node/21628), just the C15A is a small tube for an AA/14500 cell. The C15A's switch looks better. Actually I might buy one from ILLUMN if I can get a good deal - they've been great before. He's got them marked down to $33 now (illumn.com/sunwayman-c15a), hoping the F6 driver will fit, and swap the LED. I have a T5-5D3 LED in my F6 and it's just a perfect milky white, at least to these ol eyes. I want to add a 2nd light pipe towards the rear, in another indent - it would be closer to the color LED's and should be even brighter. This light works so well with a SANYO GA cell - not as quickly burning hot as with a higher amp cell.
I’d love to see a picture of that, sounds very cool.
I'll have to take some pics of it...
Edit: Post #236 here: http://budgetlightforum.com/node/30673 has the pics.
Thanks Tom. Really neat looking that is.
Toykeeper,
I only just how had a chance to look over your BLFA6 UI. That is really great. It adds a whole new dimension to the open source pool for sure. I can hardly wait to start playing around with it.
Thanks again.
In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.
Hi, just wanted to mention that the code repo now has some attiny25 tools and firmwares. It’s only a small amount so far, but it’s a start.
TK, I was still puzzled by the much lower than advertised PWM frequencies we see (and hear) on the BLF A6 and re-flashed Nanjg drivers.
I get 13 kHz – 14 kHz, as opposed to the expected 18.75 kHz.
The delay_loop_2 function that is supposed to take 4 CPU cycles is also way off, as you probably noticed.
I stumbled across this document:
http://www.atmel.com/Images/doc2555.pdf
There is also this in 17.3 of the data sheet:
It seems the specified 10% clock accuracy is only valid if using the default 9.6 MHz internal oscillator (and at 25 C and at 3 Vcc).
Maybe I am just late to the party, otherwise I hope this bit of info is helpful.
A fix, without getting into the user calibration procedure, would be to manually write the 4.8 MHz calibration data (it is there, just not used) to the calibration register.
Personally I decided to run at 9.6/8, phase-correct PWM only (2.352 KHz). Any higher and the PWM signal turns ugly on an oscilloscope. Probably not a good option if you want to avoid noise with a high-current driver. Also slightly higher MCU power consumption.
PS. Your s7.c firmware got me started in this. Thank you
!
My OSH-Park boards
Hi TK,
Thanks for this thread and the work. I was wondering if you might include Tido’s work in the repository (or maybe it’s there and I missed it), the BLF-VLD:
http://budgetlightforum.com/node/799
Jim
I didn’t have that in the repo, but it’s included now.
I’m not sure how I missed that one. It looks like it’s pretty decent, has some interesting tricks, and is free under the GPL.
Thanks!
This probably explains why the attiny25 appears to run so much faster than the attiny13. And why selfbuilt measured “15 kHz circuit noise” instead of 19 kHz. I expected the tiny25 to be 166% as fast, but I measured about 210% instead, perhaps because the 13 is running slower than expected. I suppose I should probably figure out how to activate the attiny13’s 4.8 MHz calibration data…
As for 9.6 MHz / 8 (2.3 kHz PWM), it’s not used because faster clock speeds use more power… and because I find 2.3 kHz PWM both loud and obnoxiously slow. Anything under 10 kHz is hard for me to not see, so I try to keep the pulses fast enough that they’re a little beyond the human perceptual range.
BTW, how do you measure the PWM speed? Above ~3 kHz I can’t usually get a loud enough signal to measure it with a microphone. I’ve been tempted to try an optical sensor instead, maybe wiring up an LED in reverse, shining a light at it, and sending its output to a nice DMM, the DMM might be able to measure voltage pulse speeds… but I haven’t tried it.
I've used a scope in the past to measure high PWM's, just needed help from guys here @work to set it up. Great though seeing the exact waveforms, sliding the markers to get a precise measurement - pretty cool.
For the 25/45/85's, I'm really liking the 8 Mhz operation - the timing for every driver/MCU I tried has been dead-on accurate with no calibration -- 90 secs turbo timeout is accurate to within a second, and even that slop is probably me using my stopwatch.
I know it must be using more power than the 4.8 Mhz 13A, but thinking it's pretty insignificant in terms of LED ON and standy mode power - dunno the detials though.
I’ve been wondering if I should use 6.4 MHz instead.
At 8 MHz, the PWM should be 31.25 kHz, which is a bit fast. Or 15.625 kHz with phase-correct. At 6.4 MHz, it would be about 25 kHz or 12.5 kHz.
However, 8 MHz seems to work well enough in my initial testing. BLF-A6 runs fine on it, and moon mode even seems reasonably stable.
Yikes, that PWM is pretty darn high. Didn't realize that - good or bad? Hhmm...
Hi,
Thanks. BTW, it appears you looked at the code? Might you have any idea why the “fixed mode” version (not the “simple” one and not the “extended” one) might be giving me only two modes (kind of “high” and “medium”) and it seems to be skipping clicks, i.e., I’ll click, click, click, and then light will light then click, click….. click and then it goes off, then click, click…. and then different mode. Its like it’s missing the clicks?
Jim
I am still debating the 2.3 kHz PWM. I can see it when flicking a credit card, otherwise not. But I much prefer the resulting signal on the oscilloscope. Power consumption also seems lower actually. I get ~1 mA in between the flashes of a 5 s beacon. A 4.8 MHz clock gives ~2 mA. (I am running the MCU with the 9.6 MHz and 8 pre-scale fuses set, so 1.2 MHz.)
With an oscilloscope it is of course easy to measure the frequency. I also have a few FFT apps on the phone that seem to be reasonable accurate (E.g. FrequenSee HD and Speedy Spectrum). FFT with logarithmic amplitude scaling is the way to detect frequencies. The base and harmonics really pop out. They have no problem picking up the BLF A6, especially using your black cloth trick.
Using a regular 5 mm diode as a photo detector does work with the oscilloscope (I use a green or red one). Mode 2/7 on the A6 gives a ~0.5 Vpp signal with ~1.5 V DC offset. Just the bare LED between the scope probe and ground at 2” from the light. Neat to check strobe frequencies etc. without opening the light.
I just tried it on 3 different multimeters, it only worked on an older one.
My OSH-Park boards
I posted on my other thread that I just tried nlite.hex and that seems to work well (3 modes) on one of my NANJGs.
Does anyone know which ones are designed to work with NANJGs/7135 drivers? I’ve tried a few and many behave similar to the BLF-VLD with NANJG, i.e., the modes are somewhat inconsistent.
Thanks,
Jim
I didn’t look at the code very closely, so I’m not sure how the UI works. However, I think it uses on-time memory… so the only “clicks” which really count are the ones which happen immediately after it gets power. I’m not sure what the on-time timeout is though, or how exactly it handles memory.
Mostly, I noticed that Tido used some interesting code techniques which are totally different than STAR. It looks like he has done a lot more C programming than I have; mostly I use Python and shell so my C is rusty.
Something else I noticed is that it only uses 3 slots for wear-levelling… so it’ll wear out the eeprom about 10X as fast as STAR or 20X as fast as blf-a6. Most of the eeprom is used to store the mode table, instead of putting that in regular ROM or RAM.
Anything tagged with attiny13a and ‘ontime’ memory should work fine on a nanjg.
Yeah, 2.3 kHz seems too slow. Even 4.5 kHz stands out to me during regular use, and I can see up to about 20 kHz with the credit card trick. (if I look really closely, I can just barely see the 31.25 kHz PWM on attiny25)
I wonder if the clock divider puts the MCU to sleep for 7 of every 8 cycles. That would explain the lower power use. Given Atmel’s design goals, I bet it does something like that. Or, it could actually be running at a slower speed, underclocked.
Now that you’ve confirmed it works, I really want to try the LED photosensor trick. Until today it was just a random idea I had, but hadn’t actually tried… I’m pretty sure my DMM has some sort of relevant mode for that, though I haven’t explored that yet. It’s a Fluke 8846A which is mostly used for automated testing at work, but I can do other stuff with it between tests.
The more I look at this, the more I realize full power PWM is not the way to go.
LEDs really crave current regulation. If only we had an LD-2 with an ATMEL MCU
In the meantime I will hack an 8×7135 into two or three controllable groups of 7135s, as others have done. Only first group with PWM to get the very low modes.
For the photosensor, just connect the LED between the ‘LO’ and ‘HI’ inputs on your meter and select frequency. If the signal is large enough for the frequency counter to trigger, you will have a reading. If not, the LED signal will need to amplified and the DC offset removed.
My OSH-Park boards
Well, that was ridiculously easy. I should have tried this sooner!
Step 1: Connect an LED to the DMM. I used an old XM-L T6.
Step 2: Press the DMM’s “FREQ” button.
Step 3: Shine a light at the LED.
Instant and precise PWM speed measurement!
I measured a few things…
I was also able to measure the party strobe modes on my EDC:
It’s neat to see that I got them pretty close through guesswork.
Hi,
Could someone build the .hex for luxdrv and for STAR?
Thanks,
Jim
I’ve been able to build a .hex – just using the minidrv for now.
I’ve been messing around with the modes, and I was wondering what is the minimum value for that in the array? From the comments, it looks like minimum is 5, but is that the lowest mode I can get? If so, it still seems kind of bright, so how do they get those moonlight modes that are lower than that?
Thanks,
Jim
Pages