Thanks guys, well I think it doesn’t really matter for the highest mode in my case, will check if there’s a measurable difference in current draw.
What I didn’t expect is that I see hardly any difference between mode 4 and 5 in this set.
// PWM levels for the big circuit (11×7135) #define MODESNx1 0,0,0,0,65,255
// PWM levels for the small circuit (2×7135) #define MODES1×1 5,20,80,255,255,255
There’s a difference, but it doesn’t justify one more mode how it is right now. Will have to fine-tune the values, but I want one 0,255 mode for sure and the second highest should run forever without overheating… maybe just leave the fifth out and go with 0,255 as the second highest.
EDIT: This is an edit, just to say that I re-edited my post #1111, so that noone tries my first try…
Yup, pretty easily controlled with all of the #define logic that TK uses. Just comment-out the follow line (you’ll find it towards the top of the code) to disable the turbo timer:
Yeah, it kinda is. "NON_WDT" is "Non-WatchDog Timer". Essentially, instead of using the native AVR functions for keeping track of timers ("watchdog timers"), blf-a6 firmware is just counting "ticks" (execution cycles). It's relatively easy to code & understand, plus I imagine there are some code efficiency (space savings) benefits.
When you comment out that #define, disables this entire chuck of code. At compile time, it only gets included if that NON_WDT_TURBO is defined.
#ifdef NON_WDT_TURBO
// Do some magic here to handle turbo step-down
//if (ticks < 255) ticks++; // don't roll over
ticks ++; // actually, we don't care about roll-over prevention
if ((ticks > TURBO_TIMEOUT)
&& (output == TURBO)) {
mode_idx = solid_modes - 2; // step down to second-highest mode
set_mode(mode_idx);
save_state();
}
#endif
New Nanjg 105D.
After erasing and writing the new firmware - always got in group selection mode (instant / fleshstrob, two instant / fleshstrob) and only then entered into 1st mode
2. After erasing and writing the new firmware to the NEW ( not Nanjg 105D, driver in Convoy S2+ (from GB) like red driver in the C8 from Simon) Moonlight is available in all modes (most likely). When there is a strobe (mode battery check) - LED goes out not completely.
There is clearly some sort of mistake.
On the third issue, when, after entering the group selection mode is only Moonlight I did not come across. Yet?
I don’t know if I understand completely correct what you describe, but it sounds like you are experiencing issues that would’ve been reported by many others if they’d occur. Please forgive me for asking again, but are you really sure you got the right fuses? IIRC BOD has to be enabled with Biscotti, so high fuse should not be 0xff, even if it’s written so in the the biscotti.c file. Please, someone correct me if I’m wrong here. I never tried biscotti, but if I were to flash it I’d go with the following line:
I’m use AVR Dude & this *.cmd file
avrdude -c usbasp -p t13 -u -Uflash:w:biscotti.hex -Ulfuse:w:0x75:m -Uhfuse:w:0xFD:m -B 57600
I fussed all morning with one driver. I compile new firmware, downloaded from ToyKeeper hex file. Nothing worked (the first case).
After lunch, I got bored. I took another driver flashed it with the same parameters. And everything was normal once.
Oh, that’s strange. Thanks for the links. First time I read about that. I have some 105D laying around, maybe I’ll check biscotti out today… If so, I’ll report back, if it’s working as it should.
Of course, TK would be the person to most likely understand what’s happening there.
I’m really no expert, I just thought you maybe had the fuses wrong, because it sounded like a misbehaviour that could’ve been introduced by not having BOD enabled. I don’t even know what you’re doing with that “-B 57600” in that line, but it seems like you know what you’re doing.
I use TK's recommended fuse settings (0x75, 0xFF), disabling brownout detection, and it's been working fine for me in several lights/driver running Biscotti.
Where did the FD value for brown out enabling to 1.8V come from? Why are you guys using it?
I thought TK uses the SRAM decay (noinit) trick from alexvh to detect short versus long presses. I thought BOD has to be enabled for that, but you seem to prove that wrong?!
I've been using the same trick for quite a while with brownout disabled in other firmware versions. The 10 uF cap is a big part of that. In fact on the ThorFire BD04 (same as Convoy BD04), I pulled the C1 cap and it tested at ~1.2 uF, so Biscotti worked awful on it. I swapped the cap to a proper 10 uF one, and wholla! Worked great! With the lower cap, you had to be super quick on clicks, and with the normal cap, the timing was much easier, pretty normal.
I got some of the Simon "bad" Biscotti drivers on the way to test/trouble-shoot for Simon, that JDub-74 arranged. Think first thing I'll test is the cap -- pull it and test it's value, it's pretty easy to do. But still don't think that's the main or only problem. Problem is you can't read the fuses (don't think so) or read the programmed firmware.
Hhmm, possible the original Nanjg's weren't 10 uF, but it's been our standard since basically day one with OSHPark drivers, and thought we duped the parts. I'm not sure back then if we knew how to measure caps though. Can't recall... The 13A can take a lot more noisy signals than the 25/45/85's can, so probably could have gotten away with it. The basic Nanjg design is kind of a mess, but they get away with it, counting on out of spec tolerances, etc., and keeping the parts count down.
ComfyChair was the originator of a lot this stuff, including the first custom FET drivers where we hacked in a FET on a Nanjg.
Yea, I was aware the commands exist to read it all back but I understood they didn't work. Now could be because the factory programming locks it to not allow reading, or the USBAVR dongles we use can't do it, not sure...
Worth trying though on the 105D's from Simon - I'll give that a shot. Should have them early this week based on tracking.
