Great to see you on, PD!
Oh, and BOM added to the post
Great to see you on, PD!
Oh, and BOM added to the post
Thats a great question. My plan is to have it running on a bleeder, but I have not tested that yet (so keep that in mind before ordering parts, if someone is so inclined). I might have to make tweaks based on how it acts behind a bleeder.
Nice job gchart!
Especially like the decreasing lighted led’s to battery level indicator.
SUPER COOL!
Seems like with probably just a few very minor code changes you could use half green and half red LEDs and have a tail ring that fades from green to yellow to red.
The problem with fading is that requires ramping PWM up and down, which requires the MCU to be awake. Awake, the 416 will probably use 1mA (@3.3MHz). Asleep, it should be around 1uA. (datasheet pages 439 and 445, not my measured values). If battery drain isn’t too big of a concern, that definitely is a possibility!
Ok… I tested it in-flashlight. It’s a Convoy M1 with a Nanjg105c & 750 Ohm bleeder. Results seem mostly positive.
Firstly, it works. But a few observations:
gchart,
This is sort of off topic but what do you have your buck driver attached to for power? I’m looking for a similar setup.
An update…
I managed to decrease the MCU power draw considerably by changing the main clock to be driven from the 32.767 KHz internal ULP (ultra low power) RC oscillator instead of the prescaled 20MHz one.
I also managed to get a good grasp on the ADC readings by using the 8 LEDs to display the significant digits of the ADC readings in binary (each LED representing one bit of the ADC reading). It worked really slick. I took 7 measurements across the typical voltage range and got a great trend line with an R^2 value of 0.99.
So now that I have a calibrated formula, I just need to plug that into the source code, re-uploaded, and we should be in business!
Thanks! What are you using as a power source?
Mr gchart I like your project very much! I am looking forward to more update and improvements!!
Give that man a Bells!
Watching close with interest
Updates:
Well, now that I know that power consumption during active state can be highly reduced using the ULP oscillator (~12uA), this actually could happen! :+1:
Hey, I think maybe you might have missed post #97 ? Is this what you’re looking for? If it’s not, just let me know.
I love where you’re going with your illuminated tailcap development gchart. I’ve just built one of your LVP tailcaps as my first non-emitter reflow and I’d love to build your voltage indicator design one day.
Even without a code change I think it would look good with four green, two yellow, and two red LEDs.
This is so sexy!
Nice implementation with the MCU! Now how do you take your ADC voltage readings exactly, with the first one being wrong? I might have a simple solution, if the first value affects the average too much.
It seems to be working fine at the moment, but I’d be curious to hear your ideas! Here’s an overview of the code:
Main()
The RTC interrupt just clears the overflow flag and then calls Set_Battery_Status
Set_Battery_Status()
Get_Voltage()
It’s probably a bit wasteful, but I have 4K of program space to work with and I’m just turning on and off a few indicator LEDs so I wasn’t very concerned about peak efficiency.
Good, I think I can contribute a bit there:
So you get 8 readings with your ADC, and then simply average them. I had these ADC reading problems with Arduinos and ATTinys as well, and I found an alternative to averaging to get better readings. I don't know if it requires less or more bytes though. Never tested it.
So the solution: get the median.
The median is the value that separates the higher half , from the lower half. To get that: Do your readings, and put them in an array. Then order them (ascending or descending, whatever you like), and take the value in the "middle" of the array. That way, a bad reading doesn't affect the value you get.
Small tip: use an array with an uneven length. If it would be an even number, you would have 2 middle values and need to take an average of those two.
I don't know how familiar you are with programming, so I'll just write it. Please let me know if you don't need code bits, it takes so long with the advanced post editor.
in C++:
//sorting array in ascending order
int i, j, temp, median;
int length = 9; //uneven is better
int array[length];
for(i=0, i<length, ++i){ //get value in array
for(j=i+1, j<length, ++j){ //get value next to it in array
if(array[j] < array[i]){ //if value next to it is higher, swap them
temp = array[i];
array[i] = array[j];
array[j] = temp;
}
}
}
median = array[(length-1)/2] //for an even length it would be (array[(length-1)/2]+array[(length)/2])/2
There's even a way without using a temporary int, here's just the principle:
int x = 5;
int y = 7;
x = x + y; //x now 12
y = x - y; //y now 5
x = x - y; //x now 7, swap done
Median - nice idea! I’m actually using that same methodology for my DIY lumen tube-logger. Its a Wemos D1 Mini running Arduino hooked up to a good light sensor via I2C. Anytime there is a change, the first reading is typically off. So anytime I do a reading, I actually grab three and return the median. That’s a pretty small sample size, but it works for what I’m using it for. But yeah, median can be helpful for dealing with outliers. I could probably get away with far fewer ADC readings by using it.
Ahh, good ol’ Bubble Sort! My undergrad degree was in Computer Science, and my go-to back then was C (I use mostly database and web languages now).