Category Archives: Peter’s Stuff

Things Peter is doing, interested in, or otherwise feels like posting

TDCS Controller Step 1 – Design

NOTE: This was an initial design, that evolved as I built and tested it. For the final design, complete with a description of each major component, see this post.

The fundamental building block for any TDCS controller is a current source capable of supplying between one and two milliamps of current through the human body. This can be a bit of a challenge because the resistance of the body varies with electrode placement, skin resistance (which can vary from one second to the next), body composition, and a bunch of other factors. The trick is to build a regulated current source capable of automatically adjusting the output voltage to get the desired current even with this rapid and unpredictable change in the person being exposed.

Digging through a pile of data sheets, I found a perfect solution already packaged and ready for integration. The LM334 current regulated source can be programmed to provide a constant current ranging from microamps to ten milliamps. All it takes it is a simple resistor to set the current. Two small and cheap parts are all that’s required for the basic circuit.

We’re I comfortable that nothing would ever go wrong, and didn’t want any feedback about what the thing is doing, that would be it. I could build one on a dime, and do it for just a few dollars. However, I’ve spent way too much time fixing electronics and have seen too many cases where the primary failure was a shorted out semiconductor to trust a piece of silicon to not short out. In fact, I made a good living in college taking advantage of that particular failure mode. If the regulator failed, there would be nothing to prevent a comparatively high current from flowing through my brain and doing significant damage. Clearly this thing needs a few more features.

First, I like the idea of being able to select a lower current setting. Most of the research I’ve seen uses either one or two milliamps, and I’d like to be able to use those two settings at least. I could pretty easily build in an adjustable resistor, but they are much more expensive than simple resistors, and I’ve not seen anything showing an advantage to being able to finely tune the output. Instead, I built in a switch and an extra resistor.

Pin 4 on the LM334 is the input power, and can be from 1 to 40V. The feedback resistance between the four output pins (R1 and R2) sets the output current.

Rather than switch R1 and R2 in and out of the circuit completely and deal with the undefined state that happens during the switch transition, I hard wired R2 into the circuit and selected it to produce a 1mA output. When the switch is closed, R1 is added in parallel with R2, cutting the effective resistance in half, and subsequently doubling the output current to 2mA. If the regulator doesn’t fail, the current won’t ever be anything other than 1mA or 2mA. A simple flip of a switch will seamlessly change the output between only these two values.

With that aspect of the design complete, the next step is to provide an indicator that the thing is on. It’s a simple matter of adding a resistor and an LED on the power line. The maximum voltage the regulator can handle is 40V, so I selected a resistor value that would limit the current to about 15mA or less through the LED at that input voltage. Lower voltages will still light the indicator, but it just won’t be as bright. For my purposes, that’s okay.

The LED is actually half of a two-color (red/green) led. When power is applied, the green LED will light up.

The last three things I want in the design can be incorporated with a single basic feature. I’d like some indication when current isn’t flowing, be able to monitor exactly how much current is actually flowing, and a safety feature to shut the thing down if the regulator fails for any reason. To do any and all of these things, I need to be able to monitor exactly how much current is actually flowing through the body.

It can be a little difficult to measure low currents without disturbing the system. Initially, I believed the pile of data sheets had a ready made answer. The TSC888CILT is designed to measure the voltage across a shunt resistor and provide a gain factor to make measurements easy. Combined with a 10 ohm precision resistor, the chip puts out a 1V/mA signal.

With a 0.1% Resistor on R3, and a gain of 100 built into the TSC888, the output on pin 1 comes out to a round 1V/mA so a simple panel-mount voltmeter can be used to monitor the current.

With a signal to monitor the output current I can do several things. First, and most importantly, I want the device to shut off completely if something goes wrong and current rises above a safety threshold. If the output current exceeds 5mA something has gone wrong, and 5mA is well below the damage threshold for tissue. The simple answer for circuit protection would be to put a fuse in the line. However, mA-range fuses are hard to find, are bulky, and may not react fast enough to satisfy me. On top of that, I’m not particularly keen on replacing fuses if I happen to accidentally short something out while testing. This is where the current sense signal comes in handy.

It’s pretty easy to set up an op-amp as a voltage comparator and use it to trigger a “crowbar” if the output current exceeds a set value. The idea of a crowbar is that it’s like dropping a metal crowbar across two electrical terminals to blow a fuse or trip a circuit breaker. With the 1V/mA sensing gain and a 5mA threshold current, all that is required is a 5V reference voltage on the inverting input and the current sense signal on the non-inverting input. For the reference voltage I used a simple zener diode and resistor. I also used a 4.8V zener because it was cheaper than the 5V ones available at the time, and because 4.8 mA is still high enough that I want to shut things down if the current goes that high.

U5 and R8 combine to form a constant 5V reference. If the voltage on pin 5 of IC1 exceeds this reference, the output of pin 7 goes to the positive supply rail. The other op-amp in IC1 is used as a threshold detector to turn on the red LED of U3 if the output current is below approximately 0.8mA. The voltage divider of R7 and R6 set the threshold voltage based on the 5V reference.

The output of the comparator then needs to drive the crowbar. I added a resetable fuse just after the power switch. This fuse is guaranteed to hold 100mA (plenty to run everything) and trigger before something like 250mA. The MCR08B Thyristor can handle 800mA, so it will happily load the fuse when triggered. The output of the voltage comparator will trigger U4, which will turn on and stay conducting until power is removed. When the SCR turns on, the resetable fuse opens up and cuts power until power is totally disconnected and the fuse cools. Theoretically, none of this part of the circuit should ever actually function, but I’m happier knowing it’s there. If the current regulator fails, the crowbar will shut things down without putting anyone in danger.

U2 is a 100mA resetable fuse which is tripped by U4 if the output current of the device goes above the safety threshold. This is a redundant safety feature to ensure that a short in IC2 (the current regulator) won’t expose anyone to dangerous currents.

Because the chip I used for the crowbar trigger has two op-amps, I have one to spare that I can use as a fault detector. If the output current falls bellow 1mA, either the electrodes are disconnected, the connections are poor (i.e. they are too dry), the battery is low, or something else is wrong. R6 and R7 form a voltage divider off of the 4.8v reference used for the crowbar, and sets an 840mV reference for the voltage comparator. Any time the output current falls below 0.84mA, the output of the op-amp goes high and turns the red LED on.

The last parts to add are jacks for power and to connect the output leads. I used a simple mono-headphone jack for the output, and a 2.1mm barrel jack for the input power. I also added a connector and a diode to make it so I can plug in a 9V battery instead of a wall-wart transformer. When connected to a human, you should run this thing on a battery all the time to make sure you don’t encounter any ground-loop issues. At a minimum, make sure that the output of your power supply is floating with respect to earth ground (if you don’t know what that means, use a battery). There are good reasons hospitals have outlets with the neutral floating with respect to the ground pin. Finally, I added some mounting holes to the diagram so they show up on the board.

All combined, the circuit looks like this:

The completed TDCS controller circuit with a 1mA/2mA current regulated source, a 1V/mA monitoring circuit, power and fault-indicator LEDs, and a safety crowbar to shut things down if something goes wrong. VDD is for powering a panel-mount digital volt meter hooked to TP1 to display the output current (optional), but I didn’t include that in the schematic.

I laid the board out in such a way that I can reliably make my own by using 15mil clearances between traces, and 20mil minimum traces. I could have made it much smaller if I were going to farm this board out to a fab house by putting components on both sides of the board, using small vias, and finer traces. However, I like rolling my own boards, so traces are pretty thick, all the components are on the top-side, and vias are large enough I can drill them, stick a wire through it, and solder it to both sides. The final board is just under 2″ on the long side.

Top board layout. The bottom board is almost all ground-plane with a few jumpers and pads for vias and through-hole components.

Now, on to making the board.

Another Project – TDCS Controller

CAVEAT: The design described here has fatal flaws. I’ve since re-designed it, and have left this here as a way to document the process and share the realities associated with designing even relatively simple things with whoever might read it. The current design is available here.

I don’t seem to be able to function well without some kind of project. Usually I have several waiting patiently for my attention. However, at the moment all my current ones require either time, money, or energy I just can’t afford to give. I have a coding project to finish the user interface for the antenna analyzer I designed and built. But that’s at a point where the interesting work is done, I’m stuck on something that should be easy, but there’s something I’m missing. I’ve been using the project to get better at C++, and have run into issues that probably stem from my poor understanding of class objects and their use in my implementation. I’m out of ideas, frustrated at my inability to figure it out, and just can’t convince myself to re-attack it. I’ll tackle it again, but not until I’ve quit being frustrated with it.

Many of the other projects require large enough chunks of money to move to the next step that they have to sit and wait for that arbitrary future when I’ll have enough cash to make more progress. Sometimes incremental progress isn’t really viable, so things just sit and collect dust. The rest (like my writing projects) require motivation and energy I just don’t have at the moment. I don’t have a good excuse other than I’m burned out on them. They’ll sit until I change how I feel about them.

I needed a project I could work on that didn’t take much creative energy, would keep my mind active, and that I could reasonably finish with the small budget I get to spend without having to impact the household finances. Thinking about it, I decided I’d try designing and building a Transcranial Direct Current Stimulator (TDCS). I’ve been seeing reports on the technology for years, and have watched agencies from DARPA to the Air Force research lab study it and demonstrate measurable effects. I’ve been curious to try it, but the controllers are either expensive, or I question the safety features in the slip-shod designs of products coming from places like China or fly-by-night hobby shops just trying to make a quick buck.

The basic concept behind the devices is really simple. The circuit applies a voltage just large enough to induce a small current through the head. Done right, the current is way below the threshold for causing any physiological damage. It can tingle or sting some, will probably leave a metallic taste in your mouth, and might cause a perception of a brief flash of light, but that’s about it. The theory behind its effect is that the small current creates a marginal potential in the brain that modulates the much stronger natural electrical signals already there. That modulation is thought to help selectively dampen or enhance those natural signals.

TDCS has shown clinical significance treating some forms of depression, anxiety, and chronic pain. It had been shown to increase user focus and accelerate learning. There are claims all over the place that it does everything sort of washing the dinner dishes for you. Some claims are backed up by robust research, others are anecdotal or even outright crap. I’m mostly interested in trying the more researched claims associated with depression and focus.

In particular, I’m interested in seeing how effective it would be against my particular variety of mood disorder. However, I’m not interested enough to buy a good device and not willing to risk attaching electrodes to my head driven by a device built and sold by Fast Eddy in his garage. I trust myself and the things I build in my garage. Not so much things built in other people’s garages.

So, with that in mind, I’m going to design my own. Over the next few posts, I’ll share the process and details. So without further adieu, on to Part 1 – Design.


You say I block you from success,
That my needs cannot be met,
Without sacrificing what you need.

You have not listened to understand,
Nor given me time to teach,
What and why or discuss alternatives.

There is space in the ground between,
What you need and want aren't one,
Step back and then meet me in there.

We can do what needs doing together,
We can both find some room to withdraw,
And then forward together much stronger.

An Expensive Toaster

A few years ago, I got tired of a toaster that didn’t bother popping up before the toast was charcoal, so I got on-line and ordered a commercial-grade toaster from some restaurant supply store.  Based on the presumption that restaurants couldn’t afford to have a toaster that didn’t work right, I hoped to have a reliable appliance well into the future.  Unfortunately, that hope was unfounded.  Within two years, the toaster quit working.  You could hold the handle down and the heating elements would do their thing, but it wouldn’t stay down.

Isaac, being one of the bigger fans of toast in this house, rigged up an elastic band that would hold the handle down, but it wasn’t long until this arrangement produced it’s share of carbonized bread.  Unfortunately for Isaac, I don’t eat a lot of toast anymore, so I didn’t really have much of a motivation to replace it.  However, a few weeks ago I got a bug in my ear, went out to the garage for some tools, and tore down the toaster to see if I could figure out what was wrong.

The toasters I’d taken apart in the past (yes, I’ve disassembled one of almost everything at this point in my life) all used a bi-metalic strip in a mechanical assembly to hold the toast down until it heated up enough and bent far enough to release the mechanism.  All in all, it’s a pretty simple setup, if a little unpredictable when trying to set the toaster for the perfect toast. I figured something had been bent or broken in this kind of an arrangement, and that I could probably adjust or repair it.  If not, what difference did it make?  The worst I could do was to ruin an already broken toaster.  However, when I got it apart I realized my original assumptions were wrong.

This high-falutin’ hoity-toity commercial toaster used a digital timer circuit to control how long to leave the toaster on.  This, as luck would have it, was a good thing.  I’m reasonably good with mechanical stuff, but my bread-and-butter has for years been electronics.  I pulled out my well-worn but still functioning test equipment from the days when I actually got paid for fixing things and went to work.  Within a few minutes I’d reverse-engineered the simple circuit and identified the bad part.  Easy, I thought to myself, I’ll just add this part to my next Digikey order for one of my other geek projects.

As it turned out, Digikey doesn’t carry the integrated circuit I needed.  Neither do Mouser or any of the other parts-houses I’ve used before. The defective part was made by a Chinese semiconductor company and only available from China.  In fact, the only place I could find to order it from without having to read Mandarin (or whatever language it was) was, and it would take 2-10 weeks to arrive.  The good part was that it would only cost me about $5.00 for 5 of the things including shipping it over on the slow-boat.  I placed my order and sat back to anticipate the part’s arrival.  What I’ll do with 4 extra “toaster timer” IC’s I’m not sure.

The parts arrived yesterday.  Compared with Amazon, the shipping times leave a little to be desired,  but I had the part in-hand so I went out to the garage and went to work without grumbling too much.  I soldered in the new component, tested the toaster, and put it all back together pleased with a job well done.  However,  no sooner had I assembled it than I realized it wasn’t working.  While it had been working on the bench while disassembled, it seemed to have a different opinion about proper behavior when fully assembled and on the kitchen counter.

I spent the next three hours disassembling, testing, tweaking, reassembling, testing disassembling, etc…  Any time I put it all back together it wouldn’t latch the handle down.  As it turned out, somewhere along the line, someone pushed a little too hard on the handle, and it bent the assembly, almost imperceptibly, but significantly.  Any time the whole toaster was assembled, the case would interfere with the handle and prevent it from fully engaging the locking mechanism.  It took forever to get everything straightened out and working reliably.

So, this gets down to my problem… I was seriously considering tearing out the electronics and programing one of my Arduinos to control the toaster.  What kind of an idiot would do that?  The alternative wasn’t much better.  Instead of re-engineering a solution, I spent an inordinate amount of time fixing something that, in the end, is worth no more than half an hour of my time if I were to bill out at an hourly rate.  I should have stopped before I even took it apart the first time, little lone the time and energy spent actually fixing it.  The fact that I was actually cogitating re-engineering the thing to work with a custom-programmed micro-controller speaks volumes.  Normal people would have just thrown the dumb thing in the trash and gone to WalMart for a new one.

Recreational work

Stop, I'm told, and smell a rose.
Pause and take a break.
So I comply.
The smell offends my nose.

Why don't you do what others do?
I'm asked without words.
But I'm not them.
Must I pretend to be like you?

What's wrong with loving work?
Both the process and results?
Rest is wearying.
But labor refreshes and refuels.

Geeking Out

Since we moved back into a city and left behind a mostly rural life I’ve had to adjust my hobbies to the new environment.  I don’t spend much time planting fence posts, the only animal I take care of now is an old and grouchy dog, I don’t have old or worn out farm equipment to rebuild or repair, can mow my lawn with a weed whacker, and couldn’t fit a car in the garage to work on it if I had to.  This has been a hard transition, but it has given me an excuse to reengage with several hobbies that have lain dormant for quite a while.  One of the things I’ve restarted has been playing with electronics.

Back in high school I spent a lot of time in the electronics shop designing and building various projects that included a simple television jammer, an all electronic Christmas tree that could flash lights in various sequences, and a custom built clock that was crazy enough that it made airport security really uncomfortable when I took it to Kansas City for a national competition (after x-raying it, they  made me disassemble it and show them it wasn’t a bomb).  My brother Tolon and our neighbor Mike have tons of stories about the crazy stuff we did with electronics growing up, so needless to say, it was a big part of our adolescence.  However, once I left college and the part-time television repair job I had, electronics mostly fell by the wayside.   It wasn’t that the interest faded.  It was really just that I had a long list of competing priorities and interests.  Besides, I don’t have much use for the kinds of simple projects I could build at home.  While flashing lights are cool in some respects, it doesn’t do much for me once it’s built.  I have a higher standard of applicability for projects these days.

This last Christmas, however, I bought Isaac a robot car that used a raspberry pi for the controller.  Unfortunately (or not, depending on how you look at it), the cheap Chinese version I bought came with code that was so bad that I spent my Christmas break learning Python and writing new code from scratch.  I hadn’t done much coding for a long time, and in the process of making a functional software set for the robot I remembered how much I like that kind of a puzzle and challenge.  Another thing working on Isaac’s robot did was get me back looking at electronics hardware design and thinking about the software/hardware interface in ways I hadn’t before.  I have been a Linux geek for over 20 years, and the possibilities of a super-cheap, super-small Linux-based computer with exposed low-level I/O ports really piqued my interest to the extent that I actually had a spell of insomnia while a whole host of ideas for things I could do with it flooded my mind.

It didn’t take too long for me to realize that the best way to get sleep would be to pick a project and get to work on it.  As I thought about it, I kept coming back to a project I’d built years ago and decided it was time to update it and build it again.  The original project was nothing more than a Mr Coffee that I stripped the electronics out of and repurposed to turn on a light at a given time every day.  This light woke me up every morning for several years, but it was bulky and ugly, and the way the light turned fully on instantaneously was rather jarring.   In an effort to fix this shortcoming, about five years ago I designed and built an analog circuit to gradually turn on a bright LED lamp.  Unfortunately, Liz hated the bright white color and couldn’t stand the fact that the LEDs weren’t diffuse enough.  They were rather blinding if you looked right at them.  I had to retire the light and Mr Coffee electronics.

In thinking about the possibilities of a super cheap computer with easy to use hardware interfaces, I came to the conclusion that I could easily build a control circuit to digitally dim a three color LED.  I decided to build a raspberry pi based project that would mimic both the brightness and color of a sunrise at any time I wanted to wake up.  Because it was software driven, I could tailor both the brightness and color to match a sunrise from start to finish.   I would also be able to set it up so that I could program different alarms for weekends or any other unusual day.  Not only that, but I could even program it to do any kind of goofy rainbow-colored light show if I ever got the inkling (but I have to admit that the odds of that are kind of low).

Now, I haven’t made custom circuit boards in almost 20 years, and I haven’t written much code since I left grad school.  A sane person might hesitate to jump into what amounts to two simultaneous complex projects, and you might think it would at least have given me pause.  But no, true to form I jumped in.  I scoured datasheets from several electronics vendors, ordered materials for etching circuit boards, and began learning Eagle CAD.  Before too long, I had a schematic complete.  Not long after that, I had a circuit board layout.  A few failed attempts later I had a complete board and was on my merry way writing code to see if it would all come together the way I intended it.

The top board is a Raspberry Pi Zero W. Beneath that board is the first completed controller board I built. The piece hanging off the right side is a real-time-clock module that keeps time when the power is off. The LEDs, and the circuit board with the LCD panel and input buttons aren’t connected in this picture.

After fumbling around with Python and learning some of it’s ‘features’ the hard way, I managed to make the LCD and buttons I bought work as a menu of sorts, and got it to start the sunrise sequence on-schedule.  Pretty stoked about my progress, I plugged it in near my bed and set it to go off the next morning.  Unfortunately (or perhaps fortunately) I woke up a few minutes before the alarm and was watching it as the first blue-gray light started to come on.  Almost immediately, I realized my design wasn’t going to work.  At low brightness, the light flickered enough to really bother me.  I wanted to understand why, and what I could do about it.

As it turns out, one of my day-job responsibilities is setting design criteria for safety critical systems, and I had spent a good deal of time recently getting familiar with what are known as “real-time operating systems” and their role in safety-critical applications.  In any modern computer, multiple processes (programs) compete for processor time.  The operating system will hand control to a process, and how long that process has control before the next process gets to do it’s part is not tightly controlled.  For example, if you’ve ever been working on a computer that suddenly ‘hiccuped’ for a second and then caught up with you, you have been the victim of a non-real time system.

For routine applications, a slight hiccup that results from a process taking too much processor time isn’t all that important.  The process will eventually finish and the computer will catch up without any dramatic consequences.  However, if that computer were flying a plane or guiding a missile, even a slight hiccup could result in a crash.  For these situations, a special type of operating system is put in place to make sure that the important stuff always gets the processor time it needs, and only the unimportant stuff occasionally gets stuck with a hiccup (if at all).  Everything runs on a heartbeat, and important stuff gets done every heartbeat, every time.  When done properly, this kind of a system ensures that there aren’t any hiccups on things that matter.

So, how does this apply to my stupid little project?  First, it’s fundamentally difficult to efficiently dim an LED the way you would dim a conventional light bulb — especially using a digital controller.  Instead, to dim a high power LED you turn it on and off very rapidly, and our eyes average the intensity naturally.  To make the light brighter, you leave the light on for a longer percentage of the time.

Well, as it turns out, the code that determines how long the LED stays on works by deciding every few microseconds whether to turn the light on or off.   Because the ultra-bright LED’s I used are so bright, when I want them to be very dim the lights are only on for a few of these cycles before they turn back off again.  Even small changes in how long the lights are on in that case make a big difference in how bright the light looks.  The way this thing is set up, it turns the LED on and off 200 times a second (each cycle is 1/200th of a second) to make sure the human eye can’t see it flickering.  To make the sunrise work, I break that 1/200th of a second into 1024 chunks (why not just a round 1000 you ask… 1024 = 2^10, and computers do most things best with powers of 2).  When the light is at it’s dimmest, it’s on for 1 chunk (about 1/200,000th of a second) every cycle.  When the light is all the way on, it’s on for the full 1024 chunks and never turns off.

When the light is at it’s dimmest (where I start it in a sunrise sequence) even a five microsecond delay (about 100000 times faster than a blink of the eye) will cause the light to stay on twice as long as it should and change the brightness by a factor of two.  Small glitches make a big difference.  As the code runs through it’s loop deciding when to turn the light on or off, other processes randomly run a little long, and the decision to turn off the light is delayed just a bit.  Because the raspberry pi isn’t running a real-time operating system, there is competition for processor time, and that shows up as a flickering light that flickers worst when it’s on very low.  Because I’d just been through the wringer working through the real-time operating system stuff at work, I instantly recognized the situation for what it was.

Unfortunately, this realization meant that my design was fundamentally flawed.  I had relied on the pi for timing, and even using the most optimized code I could find to run the timing, the light still had a noticeable flicker.  Did that stop me?  If you are reading this, the odds are pretty good that you know a fair bit about me already, and could guess that I don’t quit that easily.  One solution would be to implement the code in a real-time operating system.  However, I’m not really an expert on those systems, and I don’t believe they’ve ported real-time linux to the pi.  The answer would have to be a hardware-based timer for the lights, and the best part is that I already knew where to go to find one.

Something I learned while working with Isaac’s robot car was how servos work (the small motors that steer the car and point the camera).  They work by generating a pulse with a very specific width proportional to the turn angle at regular intervals, just like the way I was trying to control the lights.  Robot designers don’t use the I/O pins on the pi to control servos for the same reason it didn’t work well for the lights — flickering, but in the case of servos, they don’t flicker, they jitter back and forth.  If you’re using the servo to control a remote-control plane for instance, that jitter would make the plane uncontrollable and result in a crash.  In Isaac’s car, the designers had actually re-purposed an LED controller with built-in timing to generate the servo pulses, and I was already familiar with how that controller worked and how to program it using the pi.  It would be an easy answer.

Frustrated, but unwilling to give up, I pulled open the schematic, deleted the control lines that I had been using, and added in the controller.  A few days of spare-time later, and I had a new board layout ready to process.  Thankfully, when I originally ordered parts for the first board, I had planned for the probability that I’d ruin several boards and had ordered plenty of extra resist film and copper-clad board.  I was also willing to bet I’d break something or need to re-build another board, so I had spares of all the parts.  I etched and solder-masked another board and built it out with everything but the new controller.  At this point, I’m waiting to order the new part and am looking forward to getting the code written and version 3 up and running (version 1 died before the first hardware met the real world).

Version 3 of the board. The new controller IC goes where the copper pads are. I’m pretty confident this one will work to my satisfaction.  The three big black things are the drivers for the red, green, and blue LEDs.  The cluster of components towards the bottom of the board are a 5V power supply to power the pi and all the other electronics.  I also added a real-time-clock module that keeps track of the time when the power is out, but that’s on the other side of the board.

At this point, if I were to add up the number of hours and the money spent on parts and processing stuff, this would definitively be the most expensive clock I’ve ever owned.  To make it worse, I’m looking at probably 20 more hours of coding to fix bugs in the current code and integrate the new controller (I’m not particularly efficient with Python).  Given my going labor rate, I can’t afford my own time.  But then again, it’s not really about either the cost or the time.

Because I Can

I'm told it'd be better and cost less,
If I hired the experts to do it.
They reason true.
I know.

My time's too costly for stuff like this,
I should just pay someone else.
Again, they're right.
I know.

But money and time aren't the point,
I do it myself 'cause I can.
Joy has value.
I know.