Im still working on my own personal build of RampingIOS V3 (and Anduril) and wanted to alter the voltage calibration as its reading about ~.2V high until 3.6v, then consistently .1v high until LVP on both of my D4S.
Looking at the readme\config txts for SpaghettiMonster, fsm-adc.h and RampingIOSV3 and I only see references to VOLTAGE_LOW and VOLTAGE_FUDGE_FACTOR. The Fudge factor seems more oriented towards voltage drops over protection diodes though.
I found a tk-calibration.h file in the root of the ToyKeeper folder but I couldnt find an include or a define that would pull it. Is that the correct place to be altering the readings?
Edit: tk-calibration.h is also defined by tk-voltage.h/TK_VOLTAGE_H but im not finding a reference for that either.
Yes, what you’re looking for is probably the VOLTAGE_FUDGE_FACTOR. It’s 0.05V per point. If the value you’re using is 5, and it’s reading 0.1V to 0.2V low, I’d suggest adding 3 to make it 8. This adds 0.15V to the values it uses.
The calibration stuff is mostly for older lights with a voltage divider on pin 7. But that’s not used on most newer lights.
Well, this went MUCH better than expected. Everything compiled super easy in the Linux subsystem for Windows, and I flashed using AVR-DUDESS using the fuses defined in TK’s flash scripts.
Anduril is so nice on the Q8, and IMO so much less confusing than Narsil. Especially when you can comment out almost anything you dont want, set defaults, and modify click counts to move states around.
Now I just gotta flash the D4S………That was a bit of a struggle, but hopefully some solid core wire will make that easier. Makes the light even better, voltage readings are spot on now.
Just fyi this was for a Q8 and 2xD4S
I set defaults for:
RAMP_DISCRETE_CEIL (MAX_1x7135) (default unless not defined)
default temp limit upped to 50C
altered Fudge Factor values to calibrate for my drivers
longer pause at moon level from power off
upped low voltage level to 3.1 so it will start stepping down earlier for lipo health
slightly lowered candle mode default brightness
static uint8_t candle_mode_brightness = 21 (was 24) Not sure if this is correct though
disabled all strobes and beacon (Just made goodnight ev_2clicks go to tempcheck state)
completely removed momentary (not really necessary, but didnt want to deal with the power cycle to leave “issue”)
Modified event handler to have a longer hold timeout for the q8 (I cant seem to press it as fast as other lights)
Ill be honest though, I had more tweaks done to RampingIOSV3, but Anduril is near perfect out of the box. I just wanted to make a few things easier to access for myself.
Yeah, it’s because I don’t have any drivers which work that way, and it assumes the two paired primary PWM pins will be used first, with the second timer channel as the extra or third PWM. The third channel runs at twice the speed, last I checked, which isn’t good for low modes. I’m not sure how to make it go slower; despite making a bunch of attiny firmware, I’m really not into the low-level aspects of programming, like virtually everything in the attiny reference manuals. So while we may have a nice API for building user interfaces, the underlying hardware support code is pretty clumsy.
Basically, the hardware abstraction for that is incomplete.
If you know anyone who enjoys the low-level bits and is willing to volunteer some time, it would be really helpful.
The ADC seems to be running in continuous mode, even though I don’t think I told it to. So I made the ADC interrupt bail out unless a flag was set by the WDT to allow it to run. I tried changing the ADC flags, but nothing I tried worked, so I went with the workaround instead.
FWIW, an easy way to test it is to remove the workaround and then trigger LVP. If it takes at least a few seconds per step, it’s working correctly. If it goes off almost immediately, the ADC is running too fast.
About PWM, I expect that fully abstracting the PWM channel setup will be messy because the pins aren’t entirely independent from each other and some combinations may require extra workarounds. It’s a lot easier to assume that only the first timer gets used when the driver has only one or two channels, which is what it does now.
There will also be a need to support other types of power channels, like on Lexel’s dual-linear-FET driver. And other ramping models, for tint ramping and such.
I’ll probably try to update the config mechanisms again to make it easier to pull in specific code at compile time based on the options chosen. What it’s doing now is inconvenient, and I get the feeling it’ll need to do a lot more of that sort of thing as the collection of supported hardware and software expands. But I’m not really a kernel programmer, even if I’m sorta acting as one, so this is all a little foreign to me. Maybe I should go read the Linux source for some ideas.
ADC is a bit harder, as my sample code for ADC reading did exactly what I wanted while FSM looked like it was in freerunning mode.
But turns out, the culprit was not the ADC but idle_mode().
As it seems, going to sleep triggers another ADC conversion as mentioned on Page 34 in the datasheet.
“If the ADC is enabled, a conversion starts automatically when this mode is entered.”
So at least for now, it works better by changing the ADC-Interrupt-Enable flag in the WDT code.
That also has the nice effect of saving 18 bytes of flash and a whole byte of RAM
I tried pushing it to launchpad, but sadly, windows gives each file the executable flag… And since bzr is a bit different than git, that was also pushed.
Also, a great tool for finding those issues was this small DIY eval board.
It’s just the ATTiny, a programmer, some LEDs (3 Channels + lighted switch) and some buttons but it works really well.
All channels have jumpers so they can be reassigned or that a jumper with an attachment point for an oscilloscope can be used.
The switch selects the voltage either from the programmer or an external header to play with voltage readings.
This is very helpful. I haven’t integrated the fix yet, but hope to do that soon. Also, the ADC/idle interaction explains a lot. I’ll have to give some thought to whether that’s worth fixing, and how. I’m reluctant to turn the ADC off between measurements, because the first value is generally bad. But I also don’t like having it wake up all the time. So I’ll keep the new information rattling around in my head for later, in case a clear solution comes to mind.