Energy – phil caridi

May 6, 2021

A Beam That Wouldn’t Light

In preparation for the Sola(r)Dex I needed to find a circuit that would charge a capacitor with a solar cell and when the charge reached a threshold turn on an output. I went through a number of different circuits including the Schmidtt circuit and the MOSFET switch but ultimately decided that the astable multivibrator would work best. It allows the oscillation between two outputs. I started with two LEDs to understand how it worked.

Astable Multivibrator circuit. The resistor connected to the positive of the capacitor supplies the output with power from Vin. The resistor connected to the negative side of the capacitor is attached to the base of the opposite side transistor.

Phase one, left side capacitor is discharging, transistor on, LED on. Right side capacitor is charging.

Phase two once the right side capacitor charges to sufficient voltage the transistor turns on. Right side capacitor is discharging, transistor on, LED on. left side capacitor is charging.

I took that what I learned about this circuit and applied it to the Sola(r)Dex. I also wanted to see if I could build a complex Beam-Bot. Well I built one, aw heck I built two the only issue is neither work. I’ve been troubleshooting it for a few weeks now and at this point I think a full rework is in order. It looks like there is continuity on one side but not the other but all of the connections look good.

Picture of the two Beam-Bots.

V1 of the Beam-Bot.

V2 of the the Beam-Bot

Construction of Beam-Bot V2

Construction of Beam-Bot V1

May 4, 2021

Sola(r)Dex Final

What do you do with all those trading cards you have lying around your house? I put them in boxes and forget about them. But the artwork is cool, I wish there was a away to display them… Enter the Sola(r)Dex, a fun, solar powered device that flips through a number of cards and randomly stops at one. What kind of magic is this you might ask, well its totally light magic! hahah! The suns radiation powers an analog circuit that alternates between illuminating a light bar and turning a geared motor.

I started by researching different circuits that could trigger an action without any user input. I cam across a few different circuits that would work in the fashion I wanted. The Schmidtt trigger, a MOSFET switch, a SIDAC, or an astable multivibrator. I settled on using the astable multivibrator, an in depth look at my research regarding that circuit can be found here. The basic Idea behind the circuit is to allow power to flow through on capacitor and output while another capacitor charges, the use of two 2n3904 NpN transistors are what allows this to function. The power input for the system in this case are four 8.5v 100mA solar panels. They are wired in a hybrid system two sets of two series panels wired in parallel. This allows for a 17v 200mA power setup.

This circuit oscillates between outputs, in this case an LED bar of ten individual diodes and a motor. While the motor is stopped the LEDs light to show the state of the circuit, when the capacitor for the motor is charged the motor turns while the LEDs are off. This cycle repeats in perpetuity as long as there is power to the system via the solar panels.

Circuit diagram for the Sola(r)Dex, astable multivibrator.

MOSFET switch, ultimately did not use this circuit.

Schmidtt Trigger, this circuit was not used in the final.

First working astable multivibrator circuit.

Same astable multivibrator circuit, adjustments made to the capacitors, resistors, added 10 LED light bar (to both sides first for testing), and finally added the motor.

Video showing the circuit cycling under the floor lights at ITP.

Video of the circuit under the solar cart. The video to the left and this video show the same circuit under two different lighting conditions. The interesting phenomenon between the two is that the high powered light source shows a much slower cycle time. I still have out to figure out why this occurs.

Circuit with two 10 LED bars powered via 9v battery.

Finally we see the circuit working with the motor and the 10 LED bar powered by the solar array.

After the circuit was finalized and working I turned my attention to the design of the Sola(r)Dex itself, I iterated on a few different designs from pulley driven, a horizontal layout, and finally arriving on a vertical direct drive mechanism. The solar array is a remote unit so it can be placed in an area with sun exposure and the Sola(r)Dex placed in another location. I 3D modeled a few parts to mount the motor, the panels, and the carriage for the cards. These were then printed and cured. I decide to use cast concrete for the bases of both the Sola(r)Dex and the Panel unit for stability and I think it looks good hahaha. Other parts include a protoboard, aluminum tubing, and some hardware. A full BOM is provided at the end of this post.

CAD view of the motor mount.

CAD view of the card carriage.

CAD view of the panel mount.

Rendering of the three printed parts.

Rendering of the card carriage.

Rendering of the motor mount.

Rendering of the panel mount.

Protoboard assembly.

More protoboard assembly, not the last step, but the last picture I took for this part.

Solar array assembly.

Concrete molds, also known as plastic food containers. Often times I use found containers for my molds unless a very specific form is desired. Since I wanted the bases to functional, very minimal, and clean but didn’t necessarily need a something showing, I used the food containers in this case.

By far the most tedious part of the fabrication was building the card holders.

I used flexible card sleeves as the bas for the card holders.

Clear heavy duty packing tape was used to create hinge to be inserted in the card carriage.

Small brass rod was used to create an anchor point for the card holder. Three layers of tape were needed to increase the thickness of the anchor point, this was needed because I forgot to change the hold diameters in the card carriage after ordering the next smaller size due to availability issues.

The Sola(r)Dex in all its finished glory.

And another shot, cause why not?

Working Sola(r)Dex

April 4, 2021

Sola(r)Dex

The concept of the Sola(r)Dex is to combine a solar panel (photovoltaic panel, PV), a DC motor, capacitors wired in parallel, an analog circuit with MOSFET as a switch, and a cylindrical carriage to randomly cycle through a set of card.

The PV would gather light and the capacitor bank. After the minimum threshold of the MOSFET is reach the capacitors would release the stored energy to the motor which would turn until the capacitors are drained. The amount of rotation is inconsequential in this case because the desire is for the stopping position to be random.

Some of my research thus far has been figuring out the amount of capacitors I need in order to run start the motor. I’m thinking to use a a bank of capacitors wired in parallel. This will allow me to adjust the capacitance incrementally to find what works best.

The other difficulty has been finding the best way to release the stored energy at the right time. I didn’t want to use a microcontroller to do this, although it would be easier in theory. I think using a MOSFET and a few diodes will act as a voltage trigger. In this case I’m using a MOSFET with a threshold of 7V. The DC motor has an operational range of 2-7.5V, with a rated voltage of 6V.

All parts are listed in the BOM at the end of this post.

Simple Power MOSFET Motor Controller.

The about circuit diagram can found here: https://www.electronics-tutorials.ws/transistor/tran_7.html

There are a couple of important aspects of this circuit, a flywheel diode disperses any back emf produced by the motor to reduce the possibility of damage to the MOSFET. And a Clamping Network, a zener diode in series with a diode, to allow for faster switching.

March 16, 2021

PenduLight, not so final form

The PenduLight, a journey form inception to artifact. For those who have not read my previous posts about design and early fabrication I will post a quick review here.

For the TL;DR scroll top the bottom.

The full text is available below.

Lite-ulum

Link to first blog post

Pendulight

Second blog post

The initial idea behind the PenduLight was to capture the movement of a the plumb of the pendulum equipped with an RGB LED allowing the path to be recorded in a long exposer. I wanted to be able to influence the the movements of the plumb to do this I attached the the suspension cable to a lever-arm which in turn was attached to a stepper motor. I used a toggle to change direction and a rotary potentiometer to change the speed.

I think overall the project was a success. There were some issues along the way, most were solved by making small adjustment, however, there are a few changes that I would like to make.

I need a more powerful motor, I didn’t think about the amount of torque required to change the direction of the motor with the lever-arm attached. I also think a larger diameter spindle would help with some binding problems. The current circuitry will allow me to use a 24V 2A motor without changing anything except for the battery.
The housing for the motor worked but could have been better, the initial idea to create an 80/20 frame for the PenduLight would be best, it would allow for small adjustments and a very rigid attachment point.
Use barrel clasp to attach the separate halves of the suspension cable, this would make changing the length or material type a less time consuming change.
Use a heat insert at the top of the plumb, again this would make installation of the plumb to the suspension cable much easier.
Use a four strand wire instead of forgetting to buy and then have to construct one hahaha.

I’m sure there are a few other changes I would like to make and there are some new features I would like to incorporate into the overall design as well.

Exploded view of the plumb component of the PenduLight. This part is the most refined but still needs a few touchups. The inclusion of a better method for attaching the the microprocessor and the addition of a heat-insert at the top for suspension cable attachment.

Collapsed plumb component rendering.

Exploded view of the lever-arm, this part need some refinement. It seems like it would be better to use a disc rather than an arm in this situation. I believe the disc would balance the pressure on the motor spindle reliving some of the binding.

Collapsed view of the lever-arm.

All parts for the pendulum except for the controller.

Photo showing manufacturing error of the lever-arm.

It took a little bit of time to get the code for the stepper to work well. This code was adapted from the moto-knob code available with the Arduino IDE.

/*
  Code adapted from
  MotorKnob
   A stepper motor follows the turns of a potentiometer
   (or other sensor) on analog input 0.
   http://www.arduino.cc/en/Reference/Stepper
   This example code is in the public domain.
*/
#include <Stepper.h>

const int stepsFull = 200;

//Stepper pedulumstepper(stepsFull, 2, 3, 5, 6);
Stepper pedulumstepper(stepsFull, 3, 5, 6, 9);
//int dirControl = 9;
int dirControl = 10;

void setup() {

}
void loop() {
  int sensorReading = analogRead(A0);
  int stepperSpeed = map(sensorReading, 0, 1023, 0, 100);
  if (stepperSpeed > 0) {
    delay(1);
    if (digitalRead(dirControl) == LOW) {
      pedulumstepper.setSpeed(stepperSpeed);
      pedulumstepper.step(stepsFull / 50);
    } else {
      pedulumstepper.setSpeed(stepperSpeed);
      pedulumstepper.step(-stepsFull / 50);
    }
  }
}

To cycle the RGB LED the code wasn’t that bad, I adapted it from James Harton, and can be found here https://gist.github.com/jimsynz/766994

const int redPin = 3;
const int greenPin = 5;
const int bluePin = 6;

void setup() {
  // Start off with the LED off.
  setColourRgb(0,0,0);
}

void loop() {
  unsigned int rgbColour[3];

  // Start off with red.
  rgbColour[0] = 255;
  rgbColour[1] = 0;
  rgbColour[2] = 0;  

  // Choose the colours to increment and decrement.
  for (int decColour = 0; decColour < 3; decColour += 1) {
    int incColour = decColour == 2 ? 0 : decColour + 1;

    // cross-fade the two colours.
    for(int i = 0; i < 255; i += 1) {
      rgbColour[decColour] -= 1;
      rgbColour[incColour] += 1;
      
 //quick and ugly invert
//      setColourRgb(255-rgbColour[0], 255-rgbColour[1], 255-rgbColour[2]);
      setColourRgb(rgbColour[0], rgbColour[1], rgbColour[2]);
      delay(50);
    }
  }
}

void setColourRgb(unsigned int red, unsigned int green, unsigned int blue) {
  analogWrite(redPin, red);
  analogWrite(greenPin, green);
  analogWrite(bluePin, blue);
 }

I used a Two different boards in the construction of the PenduLight. Originally I was going to use two Arduino Nano Every which is a very cost effective board and has just enough digital pins to accomplish the tasks at hand. I ended up using one Nano Every and one Nano 33 IoT.

I used the Nano 33 IoT with the stepper. I had some issues with the motor driver. I started with a SparkFun dual H-bridge that used a TB6612FNG, it was being very sporadic in the operation of the stepper. I read in the data sheet that it doesn’t handle low-voltage steppers very well. So I ordered a Pololu DRV8834 low-voltage stepper motor driver. This board has the advantage of a small potentiometer that allows you to set a current limit. HOWEVER after a full day of troubleshooting the code and wiring I abandoned the board and went back to the TB6612FNG and to my surprise it worked flawlessly. I still don’t know why it worked out the way it did, I would like to do more research into why.

I decided to use a proto-board and solder everything to reduce the since of the controller box. This is where I ended up change from the original Nano Every to the Nano 33 IoT. In the end I didn’t actually have to do this. After I finished soldering to the proto-board nothing worked, I checked my wiring but didn’t see anything wrong. So I pulled the Nano Every off, which was a royal pain. I connected it to the USB and it worked. I was stumped. So I switched to the Nano 33 IoT, soldered it up and… it didn’t work! I knew at this point it had to be a wiring issue. I checked for solder bridges or crossed wires and finally found the culprit. The VCC in was attached to ground, Had I spent a few extra minutes checking the wiring first I wouldn’t have had pull the Nano Every off, we live, we learn.

This is the CRV8834 which I did not end up using, notice the small silver disk towards the lower left of the white board, that is the current limiting potentiometer.

Proto-board with all components soldered in place and working, hahah

Controller box with all components installed.

The RGB LED was much simpler on the wiring side. I used the Nano Every and a diffuse cathode RGB LED.

I used 9V batteries for both the LED and the motor. In hindsight and after doing some more calculations the 9V choice for the motor isn’t the best option. In the future I will use a different motor with more torque which will need a different battery.

Board installed on the carrier.

Heat setting the threaded inserts.

All components installed into the lower half of the plumb.

Completed plumb.

All components ready to hang.

Setup in the door lights on.

In the door backlit.

Just the RGB LED on (don’t mind the power strip light in the back).

Process Gallery

AND NOW FOR THE ARTIFACT, THE REASON ALL OF THIS EFFORT AND DESIGN HAPPEND IN THE FIRST PLACE.

BOM

March 14, 2021

It costs what?!?, to run a server.

The TL;DR of it all is about $21.00 a month. Now the questions really is how did I get to that number. I bought a BN-LINK WiFi Heavy Duty Smart Plug Outlet. This has a pretty rudimentary app but it was enough to give me that data that I needed. Unfortunately gathering the data had to be done manually and methodically. There is no way to transfer real-time data, it gives a momentary glimpse of what is happening when the app is open. So I set a schedule and took a screenshot when I opened the app top track the data. A classmate of mine, Brandon Roots and I were talking about this issue. He did a tremendous amount of research regarding these issues. He was able to hack the plug and flash new code to it. This enabled him to gain access to real-time granular data. Please take a few minutes and head over to his blog post for a very detailed set of instructions, https://brandonroots.com/2021/03/11/measurement-project/.

The app I use did give daily usage in kWh in a graph format which allowed me to check the accuracy of the data I was recording through my screenshot process. Below are the screenshots from my process

Image Courtesy of Amazon

After 11 days of collecting data I took to a spree sheet to calculate and make a few observations. The above visualization shows a few different pieces of data. Daily kWh represented in purple hexagons, notice this starts of being higher than the Running Total kWh which is represented by the orange hexagons. Daily Data Server is in green and just for comparison Daily Data Workstation (the workstation was on a different plug). I was seeing very little variation for the server’s daily kWh draw so I decided to test if the load of the server contributed to the energy draw. For this test I increased the load on the server by running a full system backup of the workstation with one, two, and three different HD videos being streamed through a PLEX media server to three different devices. Surprisingly the daily kWh didn’t really change but the current draw did. Under normal operation the server was drawing never more than 991 mA however, under the load the draw increased to 1039 mA. What I did find out is that my workstation can draw up to 1300 mA while preforming graphic (rendering) heavy tasks, thankfully I don’t have my workstation running 24/7.

So back to the first line of this blog, it costs about $21.00 a month to run the server. The cost to build the server was about 3k, and I’ve needed to replace one of the hard disks a year since I built it in 2014 to the tune of about $100 a piece. So it can get a little pricey BUT I have approximately 64 TiB of usable space with dual redundancy, in contrast that would cost about $10,000 a year with a service provided by a very large company that sells lots of good online…

Raw data below.

March 1, 2021

Pendulight,…we have a problem

A quality control check of the parts reveled issues with the two aluminum parts. More details on that later in this post.

3D printed plumb base, printed solid for durability and weight.

3D printed plumb top, printed solid for durability and weight.

3D printed combination pcb mount and battery holder.

Extension arm, CNC milled 6061-al, at first glance part looked to bein spec.

Pillow Arm arm, CNC milled 6061-al, at first glance part looked to bein spec.

During the tapping process it seemed the the hole was not perpendicular to the arm face.

After tapping and assembly the mis-machining was confirmed.

Red lines show misalignment.

The misalignment between the arms causes the tension of the bearings to be very off creating binding for half of the rotation and looseness on the other half of the rotation.

I will be contacting the machining service for replacement. In the event that the parts can’t be replaced this design allows for the use of the only the extension arm however, the desired compound rotation will be lost.

February 23, 2021

Pendulight

At right shows the initial sketch concept of having a dSLR capture the movement of a pendulum. There have been a few changes to the system from the illustration at right.

Updated parts can be found below. The plumb of the pendulum is equipped with an RGB LED. The dSLR will capture the path of the plumb with a long exposure. The pivot point of the pendulum is on a multi-arm extension attacked to a stepper. The extension has three positions on each arm, allowing for some degree of adjustment to the physical system. Direction and speed of the stepper will be controlled through a toggle and a radial potentiometer.

Plumb for the Pendulight, 3D printed in solid abs

Pillow arm assembly.

Exploded view of plumb.

Exploded view of the extension arm.

Animation of plumb

Animation of extension arm

Bill of Materials

February 16, 2021