# V3.x Calibration Procedure

A project log for TritiLED

Multi-year always-on LED replacements for gaseous tritium light sources

Ted Yapo 01/23/2018 at 04:275 Comments

I added some code in GitHub for calibrating the V3.x boards.  Since the inductor has a +/-30% tolerance, the brightness and runtime can vary significantly from board to board.  These differences are easily calibrated out by running a little python script I wrote that calculates a calibration table.

There are just a few steps required to calibrate a newly assembled V3.x board:

## 1. Run The Calibrator Image

Download the calibrator.hex image.  This image runs the LED at three different brightness levels, 16 seconds each.  When the image is running, record the currents (in uA) consumed at each brightness.  In one recent test run, I recorded the following:

```10.3
19.4
37.7```

These correspond to hard-coded blink frequencies of 100, 200, and 400 Hz.  Save these three current measurements in a file called currents.dat.  The C-code source for this image, calibrator.c, is in GitHub.

## 2. Run the Calibration Script

The python script, calibration.py, reads the currents.dat file you just created, fits a line to current vs frequency, and calculates the frequencies for 1-10 year run times.  The script pops up a window with the plot shown above so you can check the calibration.  All three points should be on the line.  Once you close the plot window, the script generates a header file called modes.h:

```#define N_MODES 10
struct run_time period_table[N_MODES] = {
{1, (int)(31000./262.124721 + 0.5)},
{2, (int)(31000./124.768381 + 0.5)},
{3, (int)(31000./78.982934 + 0.5)},
{4, (int)(31000./56.090211 + 0.5)},
{5, (int)(31000./42.354577 + 0.5)},
{6, (int)(31000./33.197487 + 0.5)},
{7, (int)(31000./26.656709 + 0.5)},
{8, (int)(31000./21.751126 + 0.5)},
{9, (int)(31000./17.935672 + 0.5)},
{10, (int)(31000./14.883309 + 0.5)},
};
```

## 3. Compile the Calibrated Hex File

The tritiled_v30_selectable_runtime.c code automatically includes the generated modes.h file, so you just have to recompile to create a calibrated hex file for the board.  Once you recompile, program the hex image to the board, and it's done.

If you want, you can verify the current drain for the various modes.

That's it.  It shouldn't take more than a few minutes to calibrate your board.

I originally had a script that would do this all automatically, but my PICkit3 has proven to be a little unreliable.  I often have to reset it before it will program correctly.  It could be that my particular programmer is flaky, some incompatibility with linux, or something else, but it was just too frustrating.  The new calibration process is simple, quick, and gives good results, so I'm going to leave it at that.

## Discussions

schlion wrote 06/02/2023 at 00:16 point

I'm finally building this project, after waiting for 1,5 years for my components.

I built the 3.1 XPE2 version and when I measured the current for calibration I got (at 3.0V)  94µA - 100 Hz, 184µA - 200Hz, 344µ-400Hz. This is way off in comparison to the 10.3, 19.4, 37.7 Ted has.

I noticed that in the eagle files, the capacitor C2 was still at 100nF and not 1uF, as in the BOM. But instead of removing C2, I accidentally took C3 (10uF) and replaced it with 100nF. Now the draw is 37µA, 73µA, 145µA and the LED seems marginally dimmer. Even though it's still plenty bright. This is pretty crazy to me, as I thought they were just storing energy, but somehow they seem to influence the timing.

Are you sure? yes | no

Ted Yapo wrote 06/02/2023 at 19:55 point

I suspect your LED is mounted backwards. In this case, the LED will conduct during the whole on-time of the MOSFET, driving up the average current considerably. What should be happening is that the inductor gets "charged" during the MOSFET on-time, then the inductor should dump its energy into the LED.

This is consistent with your observation that the average current drops when using a smaller capacitor at C2. With the LED backwards, it is drawing very large current pulses, which the coin cell and the 100-Ohm protection resistor can't supply. With the 10 uF in place, C2 can store enough charge between pulses to enable larger pulses and and overall greater current drain.

Definitely try reversing the LED direction. I have made this mistake myself a few times. It's inconvenient to re-mount the LED, but I'm pretty sure that's the issue you are seeing.

Are you sure? yes | no

schlion wrote 06/03/2023 at 11:03 point

Oh no, you are completely right :o

I took so much care, making sure the LED Cathode was connected to GND, I even double-checked the PCB. What I failed to consider is that the LED should be in flyback mode. I guess it's time to head to my local maker space to do some reworking.

Are you sure? yes | no

schlion wrote 06/04/2023 at 17:07 point

I put them the other way around and now everything looks handy dandy :)

Mean current draw of my 11 modules is at 13.2, 25.1 and 48.9 uA respectively. I even did a little write-up of the build project https://hackaday.io/project/191404-making-ted-yapos-tritiled/log/219969-calibrating-much-confusion-and-reworking-in-a-hot-pan

Have a good one!

Are you sure? yes | no

Ted Yapo wrote 06/03/2023 at 18:25 point

by the way, this is also why LEDs with built-in reverse protection diodes don't work in this circuit. I found a few that seemed great until i tried them and found that the protection diodes just cause a huge drain while the MOSFET is on :(

Are you sure? yes | no