RESEARCH: Sunglasses & Attenuation of UV/WHT Light

This project is part of the "why am I jumping to other projects before finishing off my old ones" series...

I have always wanted a compact UV capable flash light and last week got the JETBeam MINI ONE SE (it's surprising how much they managed to cram into this thing...). Well after playing around with the UV light I soon found that I am quite sensitive to it, which would explain why I tend to get headaches after spending a good portion of the day outside

To help with these headaches I have some clip on polarizing sunglasses, and now that I have a UV source I was curious how well they attenuated UV (365nm) & WHT light. So I used my works spectrometer to get some cool spectra plots

Ambient Light

Here is the ambient light spectrum after the spectrometer was zeroed (below is a roughly overlaid humanly visible spectrum)

UV Light (365nm)

0.42W/m² → 0.05W/m² (~89% reduction)

NOTE: 365nm is a bit too close to the spectrometer limits, so there is a bit of clipping happening

WHT Light

75.31W/m² → 22.12W/m² (~71% reduction)

RESEARCH: SolidWorks Topology Optimization

One of the things I have come to realise with my AR2 project is that having a multi-extrusion 3D printer would be crazy useful, as all my prints to date needed support material which unfortunately is a pain to remove. However, with a multi-extrusion printer you can do fancy stuff like print all supports in PVA, which dissolves in water!

UPDATE: Not with a single hotend ;^)

Hence, I finally bit the bullet (bad time to be spending due to COVID19...) and ordered the MMU2S upgrade for my Prusa i3 MK3S. But there is a small hurdle, the MMU2S is designed for large (and preferably flat) working areas, something I do not have. So I decided to modify my current work space with a shelf to hold the 5 rolls of filament, and to spice things up I tried using the Topology Optimization feature in SolidWorks to design the shelf brackets. Overall, this produced quite an organic shape that reduced the bracket weight and gave it the best stiffness to weight ratio

The Steps

NOTE 1: I am running SolidWorks 2018 SP5

NOTE 2: Here is an easy to follow tutorial on Topology Optimization in SolidWorks 

1. Make a 3D model as you normally would
2. Add a SolidWorks simulation (SOLIDWORKS Add-Ins → SOLIDWORKS Simulation)
3. Create a new Topology Study (Simulation → New Study → Topology Study)
4. Select body material (I went with PET as I will be printing in PETG)
5. Define the fixtures (faces where the body will be held in place)
6. Add a force as well as it's direction (I went with 50N as at most the shelf will hold 5 1kg rolls of filament)
7. Add a model goal (I wanted to reduce mass by 40% while having best stiffness to weight ratio)
8. Specify the preserved regions and depth (I selected the bracket mounting faces and went with a depth of 2.5mm)
9. Specify De-mold direction (arrow should be pointing towards flat surface)
10. Create a model mesh (I used a 2mm curvature-based mesh)
11. Run the simulation
12. Finally, adjust the target Material Mass and calculate the Smoothed Mesh

The Results

• Original model: 
• 74.4g
• 210851mm³
• Topology Optimized model: 
• 44.5g
• 84013mm³

RESEARCH: Behavior of QX5252F (and probably CL0116)

Intro

The QX5252F (and it's brother CL0116) are a joule-thief type LED driver that can also use a solar cell to charge a 1.2V rechargeable battery (use YX8018 if you want 2.4V). Here I share my findings to try and figure out how this IC works.

Solar Cell Characterization

First off here is the IV & PV curve of the (shoddy) solar cell I made up. The test was done on a hot summer day with clear skies, so results are rough and don't use an exact 1000W/m² lamp.
As you can see peak power (~390mW) occurs at ~1.7V (~230mA).

QX5252F Tests

Circuit

I used the exact same circuit as shown in the datasheet which you can see here:

L = 100uH

Initially I tried setting the inductor (L) to 100uH, interestingly this limited the battery current to ~40mA. This might be relevant to table on pg3 of datasheet, though this table shows how you can set LED current by using different inductor values.

L = 20uH

I then lowered the inductor to 20uH, this time current was not limited and the battery got a much better charge. Also the battery I used had a capacity of 1200mWhr and the QX5252F managed to charge the battery to 925mWhr (77%) for the day.

SBAT to VBAT Diode Drop

From further tests I concluded a few of things:

1. The battery is charged directly by the solar-cell via a Schottky diode, hence the voltage drop varies with current. What this means is that at a low charging current you have a higher efficiency and at a high charging current you see a lower efficiency; for example with above data the peak efficiency (98.1%) occurred at a current of 0.01mA, while the lowest efficiency (83.8%) occurred at 136.44mA, also the overall efficiency for the day was 86.9% which is pretty close to the datasheet value of 90%
   
2. The QX5252F does not have maximum power point tracking (MPPT). Interestingly enough the peak power (230mW) for the 20uH test occurs at Vsolar-cell ~= 1.7V which if you look at the PV curve (different light conditions) is also the peak power voltage. I think this is more to do with me getting lucky with the solar-cell arrangement, as when I used the same solar-cell on a YX8018 while trying to charge a 2.4V battery the circuit would peak at 10mA before steadily dropping to 1mA (see graph below, terrible charging efficiency).
   
3. Strangely the inductor value seems to set a charging current limit for the battery, I am not sure how this works as I thought charging the battery occurred via the schottky diode. Also the oscilloscope did not show any switching DCDC converter behavior when charging the battery (light hitting solar-cell). 
   
4. When the battery is discharging the operational frequency of the QX5252F is ~133kHz. This is when the joule thief part of the IC springs into action.
   

Conclusion

The QX5252F is a pretty nifty IC which makes building a simple solar harvesting circuit very easy. A few small downsides is that:

• You are limited to a single 1.2V battery, though you might get away with using a YX8018 and a higher Voc solar cell
• You have to choose solar-cell that has a Voc of at least 2.4V (2x1.2V) for it to work properly
• As you would expect it does not have MPPT, not a biggie at this price point

Also the inductor sets the peak battery charging current (not expected) as well as the peak LED current (expected). I might have had my data logging circuit wrong, so will have to redo this step in the future

RESEARCH: Controlling an RGB LED with a potentiometer

One of my upcoming projects will require me to control an RGB LED with a single potentiometer.
Scouting the internet for relevant code came out a tad fruitless as most code had poor transitions between each RGB value, as you could see each LED momentarily turning OFF between major transitions.

/////////////////////////////////////////////////////////////////////////////////////////////

// RGB LED control - v1.1                                                                  //

//                                                                                         //

// A simple program for controlling an RGB led with a single potentiometer.                //

// As per I/O pins below, the RED pin of the RGB LED is connected to pin #9 of the Arduino //

// GREEN pin to pin #10, and BLUE pin to pin #11. Also the output of the potentiomenter is //

// located on pin #A0.                                                                     //

//                                                                                         //

// ANTALIFE - 09.08.15                                                                     //

/////////////////////////////////////////////////////////////////////////////////////////////          

//MUH I/O PINS

int R_pin       = 9;

int G_pin       = 10; 

int B_pin       = 11;

int RGB_pot_pin = 0;

//MUH VARIABLES

int anal_val    = 0; // ;^)

int theta       = 0; 

int colour      = 0;

void setup()

{

  //MUH OUTPUTS

  pinMode(R_pin, OUTPUT);

  pinMode(G_pin, OUTPUT);   

  pinMode(B_pin, OUTPUT); 

}

void loop()

{

  //Using an RGB circle with RED being 0deg, GREEN being 120deg, and BLUE being 240deg

  //Here we map the 360deg circle to a value between 0 and 255 (aka the duty of the PWM)

  theta           = analogRead(RGB_pot_pin)/4;

  colour          = (6*theta)%255;

  

  //RED TO GREEN [0deg -> 120deg OR 0 -> 85]

  if (theta <= 42.5)

  {

    RGB_write(255,colour,0);

  }

  else if ((theta > 42.5) && (theta < 85))

  {

    RGB_write((255-colour),255,0);

  }

  //GREEN TO BLUE [120deg -> 240deg OR 85 -> 170]

  else if ((theta > 85) && (theta < 127.5))

  {

    RGB_write(0,255,colour);

  }

  else if ((theta > 127.5) && (theta < 170))

  {

    RGB_write(0,(255-colour),255);

  }

  //BLUE TO RED [240deg -> 360deg(or 0deg) OR 170 -> 255(or 0)]

  else if ((theta > 170) && (theta < 212.5))

  {

    RGB_write(colour,0,255);

  }

  else if ((theta > 212.5) && (theta < 255))

  {

    RGB_write(255,0,(255-colour));

  }

}

void RGB_write(int R_val, int G_val, int B_val)

{

  //A simple function that displays the desired LED colour by setting the duty of the

  //PWM on each RGB LED

  analogWrite(R_pin, R_val); 

  analogWrite(G_pin, G_val);

  analogWrite(B_pin, B_val);

}

So after having a look how an RGB colour wheel works (http://www.colorspire.com/rgb-color-wheel/) I decided to write a simple function myself, thus giving the code below:

To give a quick explanation of the code look at the picture below. You see how as you move around the colour wheel (or change the theta angle) the R G B values of the LED change accordingly giving you a certain colour. One other thing to note is that only two values are being changed at any given point, that is from 0deg to 120deg only the R and G values change while B stays constant (you can witness this by playing around with the colour wheel link above).
Knowing all this the above code maps the angle theta to a certain mixture of PWM duty on each LED, in the end giving you a pretty display of colours.

EDIT: Turns out humans see the brightness of colours differently, here is a good post about how this would have to be accounted for in software.