Interestingly, the image displayed in the appnote does not actually conform to the requirements set out in the text. Specifically, the corners are too pointy.
Here is the default wheel in the generator I wrote, with the 1mm corner radius.
Generators are fun, though. I haven’t used the output for mine in a real device yet, but maybe someday I’ll get a selection of them fabricated onto a PCB and test them out. iPod, I’m coming for you.
To use it, go into KiCad’s footprint editor, and press the button to create a new footprint from a footprint generator. Select your options (inner and outer diameters are the critical ones), generate the footprint, and then save it into your library.
Simulation has always been the dream of PCB design. In most cases, it hasn’t been practical – Either in the domain of expensive or esoteric tools that are compute-cycle hungry and limited in scope. But we’re at a turning point.
This is the process for current carrying / voltage potential simulations with KiCad and ElmerFEM.
Inspired mostly by some tweets by Daniel Giesbrecht, whereupon I picked his brain a bit.
There’s also this two-hour long youtube video by Lukas Henkel that goes over the exact procedure I’ll be describing. Coincidentally, he also just did a cool podcast episode of The Amp Hour.
This is an abbreviated set of notes, mostly for myself, but it’s possible that others will benefit, so I’m hitting the “publish” button.
I’m doing this test on the large comb-like trace in the centre of this PCB. The purpose doesn’t matter, and the test parameters are fake.
The process is a bit tedious, and uses four different software packages. But it’s already way better than it was, even last year. KiCad’s new export formats have eliminated the need for a whole other software package.
I’ll be using Windows for this, but other than different download links, I believe this process is fully cross compatible.
Newer version of KiCad (Currently nightlies 8.99, but likely mainlined starting KiCad 9) allow exporting in more formats than ever before. XAO is recommended for usage in Salome.
Download KiCad 8.99 development, as of this writing.
Open up the PCB file
Go to File->Export->Step / GLB / BREP / XAO / etc
Change the top left box to XAO
Initially, use simple settings to test process, and not test your CPU
Uncheck “Export board body / components”
Export tracks, vias, pads, zones
Fuse shapes
Use the Net Filter box to only export your copper of interest (again, for now)
In Salome, go to geometry workbench and import XAO
Unhide geometry
Right click geometry in tree->Create group
Change it to flat plane, name in “input”, select input faces, add, apply
Same for outputs
Important for later: Click on output in the sidebar, then at the top, Inspection->Basic Properties. Take note of the Surface. In my case, 1.168319. This is in mm^2
Save
Go to mesh workbench
Create mesh, 1D-2D-3D strategy, add hypothesis
Max and min need to be played with, in millimetres – 02 / 0.08 worked well. Defaults were okay for me, but too fine.
Apply out of that, right click mesh->Calculate
right click the mesh in the sidebar, export to UNV
You’re done in Salome!
Onto software number three, ElmerFEM (GUI, No MPI).
In Elmer, file->open the UNV
Equation->add static current conduction
IF THIS ISN’T HERE
File->Definitions->Append
edf/statcurrent.xml
Close out of that, add new equation
In static current conduction:
Active, Apply to Body Property 1
Click “Edit Solver Settings”
Solver Specific Options->Calculate Joule Heating and Calculate Volume Current
Apply, Update, and OK out of that menu
Material->Add->Static Current Conduction
Select copper (generic) from material library
Change electric conductivity to 47.00e6, Apply to body
Boundary condition->Add
Call it “Input” at the bottom
Static current conduction->Potential: 12V? Whatever
Hit new, name it Output, Static current conduction->Current density
It is in A/m^2 – grab the previously calced surface area (1.168319mm^2), convert to m^2 -> 1.168319e-6
Divide 0.5A / 1.168319e-6 = 427965
Current flows OUT, therefore = -427965
OK out of both windows
Find the boundary conditions (input/output) on the sidebar in Geometry->Boundary. Double click, set appropriate input or output for both.
Save
Sif->Generate. Sif->View log is also the main sim input settings, useful for debugging.
Run->Start Solver
If the solver doesn’t converge to near-zero (probably), then:
In the sidebar, open up the Equation, then Edit Solver Settings
Iterative->BiCGStabl
Convergence Tolerance->1.0e-8
Preconditioning->ILU2
Hit Update, generate Sif, check the Sif file if desired
Start solver
If it converges to approximately zero (like, 1x10e-18), then it was successful! A .vtu file should have been saved.
At this point, the solver should complete. In my case, I first used the built-in ElmerVTK to view the output.
Who knew? Probably shouldn’t slam 500mA through a single via.
I recommend playing around with ElmerVTK within ElmerGUI for a bit. It wasn’t too hard to get it to display heatmaps based on my solver parameters. The results weren’t incredibly aesthetic, but they were simple to get results from.
But then if you want something prettier, move onto software number four: ParaView. Also no MPI.
The settings are mostly the same as ElmerVTK, just more complicated. Open up the .vtu file, find the same settings, and admire.
Future steps:
I have not done any research on what the preconditioning parameter above is, and that seems like an important topic to investigate.
This was originally done with an eye to creating a one-click KiCad plugin, but considering the multitude of softwares and settings used, there isn’t an obvious avenue to attack to lower the barrier to entry on this. This will remain in the back of my mind.
I may attempt to replace the Salome meshing steps with Gmsh. Gmsh is more lightweight, and should be able to do everything with the command-line, which would help with automation.
There are also a few ElmerFEM solvers that merit more investigation. Electrostatics, RF, and thermal solvers are all very relevant, depending on the project.
Adding in all of the other traces, signals, FR4, and embedding it in atmosphere is the very next step, for better thermal simulation.
Instead of a TV at home, I use a projector. It’s on my ceiling, with the buttons inaccessible. The remote for it also isn’t really working anymore. Problem.
There’s nothing on the remote control’s PCB except for an obscure microcontroller (TTR013), IR LED and driving transistors, and some carbon contacts for the buttons. The intermittent operation is not the contacts deteriorating, and the microcontroller is getting power, so troubleshooting opportunities are limited.
But, the internet is a wonderful place, and someone has just straight up recorded the exact remote control I need and posted it up on Github.
The config file is here, but they also have the raw recordings. Apparently it’s a config file for a Linux IR transmitter driver called LIRC. The config documentation is here.
It’s pretty straightforward, so I set out to duplicate the waveform using the RMT peripheral of the ESP32. The RMT peripheral is an arbitrary waveform generator, and one of the typical use-cases is an IR transmitter. Perfect.
My final code is here. The From my reading of the LIRC docs, the relevant config data is this:
header 9077 4504
one 602 1622
zero 602 511
ptrail 604
gap 108167
begin codes
ON 0x000CF20D
Where a binary 1 is denoted by an on-pulse of 602 microseconds and then an off-pulse of 1622 microseconds. Similarly for 0, it’s 602-on and 511-off.
The code for ON uses that sequence to write out 0x000CF20D.
The whole packet starts with the header sequence (9077-on, 4504-off) then 0x000CF20D, then the tail/gap sequence (604-on, 108167-off). Seems straightforward.
I put the ESP32 on an oscilloscope to make sure the RMT was doing what I wanted it to do.
It seems to be! But this is more of a logic analyser task, so I pulled that out. The waveform looked exactly as I expected, so I tested it out with an IR LED.
And it didn’t work at all. Nuts.
By connecting the remote control to the logic analyser and powering it with a nice bench power supply, I was sometimes able to get output data. Enough to grab a capture after several minutes of mashing the carbon contacts with a brass standoff.
Here’s the full waveform:
It’s worth noting that the waveform is inverted from the actual LED current, due to measuring at the LED with low-side switching. Don’t worry about it too much, just invert the logic.
Sigrok can export the waveform in a Value Change Dump format, which looked good enough for my purposes. Then I wrote a python script to convert VCD files into the RMT packet format.
It looked good, with the exception of some glitches caused by the RMT not being able to handle very long delays, relative to the fast switching. This strategy still didn’t work on my project.
Speaking of fast switching, let’s investigate that further. Abandoning the Github config files so quickly didn’t sit quite right with me. It was too perfect.
Going back to my capture of the remote, here’s a binary 1:
Here’s a 0:
And then here’s the header, along with the data portion:
And the header with the whole data portion:
It does look right. But why was this so different from the Github repo?
Well, obviously this has a carrier wave that I totally blew by.
Wow, okay. Back to the LIRC documentation. There is a frequency option that specifies carrier wave, and defaults to 38kHz. So, it’s not in the config, because it’s set by default, and is one line in the documentation. No wonder I missed it.
Honestly, my brutish Python script that specifies all of changing values is probably good enough, but it feels wrong to use a 1500-line lookup table instead of a fixed carrier frequency and 15 lines of actual data. The RMT peripheral made it incredibly easy to fix up.
The end result looks really good, but let’s compare with the captured data again.
Keeping in mind that the data to be sent is 0x000CF20D, I’ve annotated the capture:
And it looks mostly good, except… What’s that block at the end?
I can’t find anything in the original config or documentation for the config that would explain that last block. That will remain a mystery for now.
Anyway, it was about this time that I got suspicious of the ancient IR LEDs that were in my parts bin. If I cranked the current, they looked visibly blue, which, obviously is the wrong side of the spectrum when I’m looking for IR LEDs. I grabbed a spectrometer and measured it – Yep, that’s not right.
After combing through my parts bin, I found another IR LED and measured it: 815nm. Still not right. I was fortunately able to juuust barely be able to measure the wavelength, though.
Looks like a very broad band 815nm, if the peak stretches all the way to 750nm.
I’m pretty sure I’m looking for a 940nm LED, so some more combing and I found an IR proximity sensor. I don’t have a datasheet, but pointing a TV remote at it triggered the on-board red LED, so I knew it was simpatico.
A quick hack-job later, and I drove the LED directly from the ESP32. My projector turned on, without any further changes to my code. And it successfully turned off the projector, too.
So that’s how I controlled my home entertainment setup with an IR proximity sensor.
Sometime in the middle of this journey, I hooked up the LA to a little 315MHz receiver module and triggered my garage door remote. I won’t be posting the waveforms here, but minor modifications to my Python script and code worked out of the box to clone the remote. That whole process took about 15 minutes, so it was a nice and useful diversion. Because it’s attached to an ESP32, I can now trigger my garage door over the internet. From anywhere in the world! Very, very remotely.
This whole project is very specific to my needs, but it could be helpful to others. There is now a pipeline for converting LIRC config files into ESP32 RMT outputs. I doubt I’ll ever do this again, but, just for giggles, here’s a GPT-assisted script that will do it:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Force-directed graph drawing algorithms are a class of algorithms for drawing graphs in an aesthetically-pleasing way. Their purpose is to position the nodes of a graph in two-dimensional or three-dimensional space so that all the edges are of more or less equal length and there are as few crossing edges as possible, by assigning forces among the set of edges and the set of nodes, based on their relative positions, and then using these forces either to simulate the motion of the edges and nodes or to minimize their energy.
Force-directed graphs are a common way to display things like mind-maps. It’s a good way of spreading out the whole collection, while grouping related items together, and minimizing the path length between the closely related items. In my mind, this has a lot of similarities with how PCBs are laid out.
Well, there’s only one way to prove that theory.
Using KiCad PCB parsing code I wrote for another project, I was quickly able to grab the nets and footprints out of a KiCad project. Displaying the nets and allowing specific ones to be turned off was a feature I identified as critical early on, because the ground or power nets would overwhelm any of the others, rendering the important nets useless.
Truthfully, a significant part of this was wrangling TKInter to build the Python GUI that I wanted. It was a success, but I’ve never used it before, and I am not a fantastic UI designer.
Under the hood, the system essentially treats each of the nets as a spring, and applies a simplified version of Hooke’s Law to each connection. Each of the centre point of the footprints acts as a charged particle, and a simplified version of Coulomb’s Law acts upon it to repulse all of the other footprints. These algorithms are a pretty typical way to do this, by essentially setting up a physics simulation. One tweak on this strategy that is unusual, is that the nets don’t act on the footprint origin. They act on the pad itself, which allows a torque to impart a rotation on the footprint.
I’ve gotten this project as far as “fun tech demo”, and it’ll likely fall dormant for a while in this state. At some point, I will build an appropriate PCB using this technology, because I love making unusual designs that are electrically fine.
It’s a Craftex B1979C, which seems to be nearly identical to a Craftex CX704. Similar to many such mini lathes, actually, with varying swing lengths.
The previous owner explained, a little bit sheepishly, that he tried to cut steel a little too hard, and burned out the AC motor. He replaced it with a hobby BLDC motor and ESC, designed for things like quadcopters.
I played around with that system a little bit, and I didn’t like it.
Annoyingly, he bought a $50 motor and a $50 motor controller, both sensorless versions. For these kinds of motors, you need sensors to start up at low speeds with torque on the motor. That would have cost $60 for the motor and $60 for the motor controller – Not much extra for him, but annoying for me to have to shell out the full amount for both, and then have the old ones as somewhat useless spares.
Anyway, instead of going the same route, I chose to get a more sophisticated controller so that I could precisely control parameters, like speed, or acceleration. The options are essentially vESC or ODrive, unless I want to custom build something myself (I do not).
The ODrive, at least on paper, looked a little cooler. Some good communication strategies, lots of control modes, and generic enough to work well for this somewhat strange application. Right after I’d picked mine up, they discontinued support of the V3.6 and went to a closed source model, which rubs me the wrong way. The new version is also more expensive and has a single channel instead of two channels. One of the big issues with the legacy release is that there is a bug in their UART driver – If you send enough malformed packets, like, say, because you have a data line right next to a spinning motor, then the controller eventually stops responding to all UART data. That can be an issue when the packet you want to send is “stop now, immediately”. That definitely hastened my building of a separate e-stop box.
Fortunately, after I wrote a CANBus driver and used that, it’s been reasonably solid. That was just more of a time investment than I wanted to make.
I built a front panel for it as well. It’s a couple simple PCBs holding the switches, OLED, buttons, and a dev board. The advantage of not including everything on a complicated PCB is that I can pop out the dev board to flash it on my bench, before returning it to the lathe. The dev board is an ESP32, which is driving a little OLED screen that shows the target and measured speed, current, forward and backwards directions of the motor controller. The list of features I could add is nigh-infinite, but this is good enough for now. Oh, and I can do software updates over the internet! There is no way this can end badly.
It’s weird how sometimes three sentences can encompass four months’ worth of occasional project time.
The change gears the lathe came with are steel, which is unusual for a model like this. It came with a set of gears, from A-D: 20/80/20/80. However, this combination isn’t listed on the table anywhere.
The formula is ((A/B)×(C/D))×lead_screw_pitch/initial_ratio
where you have a 3mm lead screw, and it has a 2:1 ratio. So for example, 0.4mm pitch is ((20/50)×(40/60))×3/2 = 0.4.
That means the gears I have are about 0.09mm pitch, which is good as a powered feed, but not intended for any kind of threading.
Most of the other examples of this family of lathes use plastic change gears. Obviously using cast or machined nylon, but with a little bit of babying, I bet 3D printed gears would be Good Enough.
As near as I can figure, the change gears dimensions are module 1, with a 20 degree pressure angle. And a thickness of 8mm.
To practice threading, I copied a bolt that I had on hand, which was 1/2″-13 TPI, using the table to get 40/65/60/30.
Looks neat! But my tool geometry is bad and the angles are all wrong, so I reset, bought some more tooling, and moved on to something actually useful.
3D printed change gears work great! I’ve printed off a whole set, and I’m stoked. Arbitrary threads are unlocked.
I wanted to turn a gear shift knob, which has a thread of M12*1.25mm.
Using the formula above, the gears I need are 50/40/40/60.
The outer diameter of the stock is about 11.85mm.
This process ended up being incredibly drama free. Twenty minutes after starting, I had a very-slightly too-loose thread, but it snugged right up when I tightened on the knob.
Voltage glitching, also called fault injection, is the process of dumping the energy on a microcontroller’s power rail very briefly – Just enough to cause a glitch, where it skips an instruction, rather than causing a brown-out-induced reset.
I first learned about the technique in connection with the Chip Whisperer, which is an FPGA-based board with all the bells and whistles. It’s quite expensive, and like any other situation where you add an FPGA, very complicated. Naturally, that has elevated it to a level above what mere mortals can perform in the limited free time we have.
After knowing about this, and having it in the back of my mind for several years, I finally have a good use-case that can justify spending some time on this. I have a pile of generic STM8-based devices, and while I have written some of my own alternative firmware, I’d love to be able to dump the original flash to revert them back to factory code.
The function of the device doesn’t matter, that’s not the point of this exercise.
Some quick searching for options leads to this recent write-up, which is sparse on details, but serves as excellent inspiration that this task is very doable.
A few architecture notes:
The STM8 has a Read Out Protection bit in the configuration area of its flash memory. When the programmer attempts to read out the flash memory, the bootloader first checks this bit, and if it’s cleared, it starts reading out the flash to the programmer. If it’s set, it just reads out zeroes. Write capability is never blocked – That is, you can still write a zero to that ROP, and then the microcontroller will be “unlocked”, but it does clear the program memory, too.
One of the pins on STM8s is called VCAP, and it’s attached to the internal voltage regulator. The CPU runs on this voltage rail, not the actual voltage that is provided to the IC’s power pins. The pin is intended to be connected to a decoupling capacitor, and that provides an perfect spot to inject my glitches. Most microcontrollers also have something called Brown-Out Resets: When the input voltage rails sags too low, the peripheral triggers, and resets the microcontroller. Obviously, this is something we want to avoid, and using the VCAP pin should help with that.
In terms of glitching, there are two important considerations:
The glitch must start at the same time or during the cycle in which the CPU is trying to read the ROP bit, and the glitch must not last long enough to trigger the BOR or to make any other important instructions fail. It’s not easy to know these exact timings, so any reasonable values must be tried, essentially brute forcing the process.
Now, the logical way to do this would be to use an external microcontroller to wait for the programmer to reset the system, wait a set period of time, and then trigger the output transistor to glitch the voltage rail. That’s boring! You know what else can do that? That’s right, a pair of 555s.
Here are two 555s set up as monostable pulse generators. The input is the RST line on the STM8 programmer. The first 555 then sets the delay. The second 555 sets the length of the output pulse. Both of these timings are controller by a different potentiometer. These then go to a MOSFET that dumps the energy stored in the internal voltage regulator cap.
After building it with larger-than-designed time values and testing it to prove that the waveform looks as expected, we solve the next hurdle:
To figure out decent ranges for the potentiometers, my STM8 board runs at 8MHz, which means that each clock cycle takes 125ns. The STM8 requires at least 2 clock cycles for each instructions (one for retrieval and one for execution), and more for instructions with multiple bytes or arguments. So, ballparking, we need a pulse that’s anywhere from 0.2us to 1.2us or so.
One problem with a typical 555 is that it can only generate pulses as small as 10us. Fortunately, I have a pair of high speed versions up my sleeve, the LMC555. It has a 10ns minimum pulse instead, which is very zippy. They’re SMD only, so they get popped onto a breakout board to fit the breadboard, and replaced. Some other components got tweaked too, as I played around more.
Now on to the programmer. I’m using a standard STLink V2, which speaks the SWIM protocol that allows programming and reading of the STM8’s flash.
With a little bit of bit of Python and stm8flash, we get this:
import subprocess
# .\stm8flash.exe -c stlinkv2 -p stm8s105?4 -r out.bin -b 1
out = b'\x00'
while out == b'\x00':
subprocess.run(['stm8flash.exe', '-c', 'stlinkv2', '-p', 'stm8s105?4', '-r', 'out.bin', '-b', '1'])
f=open("out.bin","rb")
out = f.read(1)
print(out)
subprocess.run(['stm8flash.exe', '-c', 'stlinkv2', '-p', 'stm8s105?4', '-r', 'out.bin'])
In PC applications, writing text to console is a surprisingly slow process, so a low-effort tweak I made to make the loop run faster is to remove the flash utility’s console logging, just by removing some lines here.
So, all set up, potentiometer on the left controls the delay, pot on the right controls pulse length.
And, bam.
Firmware dumping with a 555.
Well, not that fast. It took about 45 minutes of fiddling with the knobs until all its secrets were unlocked. I’d sweep the right knob the whole way, then tweak the left knob very slightly, then sweep the right knob again. It only really worked because the knobs only had to be within the right range for a very brief period of time. It only had to work once.
Would this have been easier with a microcontroller? Oh yes, of course. But that’s not nearly as interesting.
Here is a brief overview of how light and colour work, in the context of LED lighting.
We’ll mostly be discussing the CIE 1931 colour space, with reference to the chromaticity diagram, shown below.
This is the 1931 version. Newer versions that look slightly different have come out, but the general intent is the same, and they are all used for different calculations. The 1931 version is “good enough” and is universally the one that is referred to when a colour is described in xy coordinates.
The points along the edge are pure visible wavelengths (displayed in nanometres). Anything inside the diagram is some mixture of the wavelengths.
Computer monitors don’t have the same kind of visible range as your eyes, so the colour space diagram above is just a representation, not the actual colours that you would be able to see if it were displayed side-by-side with the actual light wavelength.
There’s a curve along the centre, called the black body curve, that represents “white” light. White can be many different things – Typical incandescent bulbs are around 2500K, towards the right (warm) side of the black body curve. Daylight is very cold, with lots of blue components, towards the left. As long as it’s along that curve, it can be considered “white”. The vertical-ish lines indicate where that particular temperature extends, if a given data point isn’t exactly on the line. Duv, or “delta u,v” is a measurement describing the point’s distance from the line.
In terms of white LEDs, there will typically be a “warm white”, also called “tungsten”, and a “cool white”, called “daylight”. As shown by the black body curve, if you have both LEDs, you can’t interpolate between the two of them and expect the light output to follow the curve. It will be a direct line between the two. There are a couple solutions to this, and an easy cheat is to explore the strategy that one of the industry leaders is utilising.
The Philips Hue tunable white smartbulbs are excellent. I’ve taken apart a handful of smartbulbs, and the Hue has the largest quantity of LEDs I’ve seen(read: brightest), as well as using a few tricks to get better light quality than any other system I’ve seen.
The daylight LEDs, labeled “CW”, and tungsten LEDs, in this case labeled “FW”, (we’ll get back to that) are fairly standard. In the centre is where it gets interesting, with the LEDs labeled “L”. This is lime green.
Here is a closeup of those LEDs plotted on an XY graph, with the black body curve, and an interpolation line between them:
With both of the tungsten and daylight LEDs located on the black body curve, fading in between the two will drag the light significantly away from what we perceive as “white”, essentially making the light look magenta. The lime LEDs, towards the top of the graph, are perfectly situated to pull the light output back onto the curve when the bulb is at an intermediate temperature. Some further investigation into the meaning of the LED designators on the PCB, “FW”, reveals that some LED manufacturers with that particular temperature of LED call it “flame white”. It’s substantially warmer than most bicolour white LED tapes, at around 2200K. Mint LEDs are also sometimes used for the same purpose as lime LEDs. Mint has similar spectral components to lime, but with a little more blue components, moving their xy coordinates a little more towards the bottom-left.
Here they are next to a high quality warm/cool (bicolour) LED tape:
From left to right: my daylight, Philips daylight, my tungsten, and Philips flame. Daylights are fairly similar, within binning and measurement tolerances. My tungsten LED is 2600K, showing how far the Philips flame LED is into the red spectrum. Another strategy for getting temperature that warm is to add an amber LED.
Tungsten, flame, and amber, left to right respectively:
Tungsten LED can be combined with amber to get a warmer (lower) temperature. Amber has an additional purpose: Standard RGB gamuts don’t have a whole lot of range in between the red and the green colours, which can be filled out with the added amber channel. More on this in a bit.
“Gamut” is the displayable area made possible by mixing the available colours. Displayable points drawn with each primary colour, and the available gamut is any point within the area.
Here’s a typical RGB LED tape.
And their spectral distributions:
This green has a slightly wider spectrum than the other primaries, so it doesn’t fit as nicely on the edge of the xy graph. It’s made up of mostly 520 nm and 540 nm components.
The MacAdam ellipse is a graphical representation of what observers see as “one colour”. That is, anything in the ellipses shown appear to be the same colour to a regular person. This particular image is only the results from one participant in the study, so it shouldn’t be taken as definitive, but it does show trends that can provide actionable insights. The shapes are also exaggerated by about ten times for ease of clarity.
The ellipses tend to flow in the direction of the blue-red line, for example, showing only a few different perceptible shades in between those two primary colours. Red to green however, particularly in the red to yellow region, are extremely granular. This is where amber comes in.
The amber gives additional granularity in the existing gamut region where our eyes are very sensitive, and in the space where the gap between the RGB peaks is largest.
Emerald green, at 560nm, is another LED that would help fill out the spectrum gaps, providing more range towards the green part of the red-green line. Emerald and amber doesn’t alter the overall gamut significantly, however. There are areas without coverage on all sides of our gamut triangle, but the area to the left of the blue-green line is the most significant. This could be supplemented by InGaN cyan LEDs, at 505nm. That will be the topic of future experiments.
For reference, here is a graph of all of the colours measured and discussed.
Power management in battery applications is pretty tricky. There are a lot of different situations, and a lot of different strategies. In the past, for the topic of this conversation, single cell Lithium polymer batteries, I’ve used a pair of Schottky diodes to automatically “select” the highest voltage feeding the system. That will be either 5V USB power, or 3V-4.2V LiPo battery.
It was suggested to me to use the body diode of a P-Channel MOSFET, but I dismissed that as unnecessary: the body diodes have no lower voltage drop than a Schottky, around 0.2V. Here is one of the more readily available results for battery/wall-power switchover:
That thread doesn’t make a good case for the FET solution over the diode, but the initial suggestion to me indicated that, once “on”, MOSFETs will conduct current in either direction. This breaks my understanding of how they work, but it warrants more research.
Stack Exchange posts don’t make for good engineering, though. This calls for a simulation!
Initial results check out! Those output waveforms on V(out) and V(out2) should be identical, if the current through M1 was purely through the body diode.
Simplifying this even more, we can do this:
That results in the following waveforms. You can clearly see the shoulder in V(out3) (blue), where the MOSFET transitions from conducting through the body diode, to conducting through the transistor junction itself:
That’s pretty conclusive. It’s weird to find gaps in my understanding of basic electronic building blocks at this point, but I’m always on-board with more education.
So now this is a documented solution at handling the power switching circuitry between USB and lithium batteries.
In the future, I should put together a written record of the strategies for charging the LiPo batteries in the circuit, and also low-voltage cut-offs to avoid over-discharging and permanently damaging the batteries.
In newer versions of MPLAB X, Microchip’s IDE, My PicKit 3 clone wasn’t able to supply power anymore.
Some investigation revealed that in MPLAB 8 and before, they didn’t used to properly check for “correct” voltage before attempting to continue programming. Which is great! But they fixed that.
Here’s the message it displays:
PICkit 3 is trying to supply 3.250000 volts from the USB port, but
the target VDD is measured to be 2.875000 volts. This could be
due to the USB port power capabilities or the target circuitry
affecting the measured VDD.
The target circuit may require more power than the debug tool
can provide. An external power supply might be necessary.
Connection Failed.
Cracking open the case reveals that it’s made by Sure Electronics, and there was possibly some nebulous licensing deal with Microchip to sell these, and then they got cloned and the deal evaporated. Or something. It’s hard to tell.
Oh look, a schematic. Relevant schematics on page 69 and 70.
I had a sneaking suspicion that there was a bad voltage divider somewhere that was causing ADC readings to come back too low.
Before having to properly poke around, this post confirmed my suspicions and made things super easy.
Near the linear voltage regulator, the AMS1117, there are two resistors named R17 and R24. They are 470 and 680 ohms, respectively.
Swapping the 680 ohm resistor with a 750 ohm is recommended. I didn’t have one, so I desoldered one leg and put a 50 ohm resistor in series, making kind of a tower on my board. Results in 730 ohms, but it seems to work. My PicKit can provide power again!
As a test, I designed a nautilus-themed PCB in PCBmodE.
PCBmodE is not your standard ECAD package. It’s a collection of JSON files that get converted into SVG or gerber files.
There are some limited tools to convert SVG files back into JSON, too. It can be thought of as forward- and back-annotation.
There’s no schematic editor. There’s no traditional PCB editor. The only interface is Inkscape itself. (Inkscape is an open-source vector software, like Adobe Illustrator)
The end takeaway is that these circuits are drawn, not engineered.
The whole repo is here. All of the JSON files are the source files, which can then be compiled into SVG (for viewing and some minor edits), or to gerber (for manufacturing).
The OSHPark gerber viewer says it’ll look like this:
And here is the final board:
It’s surprisingly difficult to photograph purple LEDs. It was suggested to me that they may have strong UV components that are overexposing that part of the image, so they usually show up as white or very light blue.
Rest assured, they are way more pleasing to the eye in person.
It’s interesting to note that the battery holder footprint was a Boldport component (it looks like a ladybug!). It’s designed for one of those cheap stamped metal CR2032 battery holders, but I don’t have any. It was easier/faster for me to grab some sheet copper and cut out a holder with tin snips.
The workflow of PCBmodE is a little bit jarring for someone expecting a standard PCB tool. It’s all laid out in the official docs, but I didn’t believe it until I tried it. Editing JSON files is almost the only way to interact with the software. You edit, compile, and view it in Inkscape. Some very small amount of things – Component position and traces, mainly – can be extracted back into JSON, but that’s it.
Even for outlines, the best method is to draw them in Inkscape, then copy the SVG paths and then paste them into the appropriate JSON:
For moving components around, there are a lot of SVG layers present for each component, but the extract command only seems to care about the origin. That little dot in the middle:
Three last things:
There’s also no “generate new board” command. Official recommended procedure is to fork one of the existing boards and modify. The docs are outdated, the sample is for an old version of PCBmodE that won’t work. I like BINCO for something really simple, or The Lady for something that uses every trick in the book.
Don’t use the official repo. This fork(as of June 2018) is the almost-official dev branch that has a lot of improvements (including Python 3!), and presumably will be merged back into mainline at some point. This command will install the proper one:
And, finally, there is one issue that will prevent manufacturable gerbers. I described it here.
The next step
So, obviously this software requires some fussing, initially. It’s pretty nice once you have it set up, though. No issues, as long as you know what they are ahead of time.
What’s still a pain for daily use, however, is building usable circuits. Lacking a schematic and having to hand-draw traces as vector paths is painful.
So I quickly grabbed the first complete PCB available in Upverter, my LightBeam board. And then I wrote a conversion tool.
Here it is in Upverter:
And then in PCBmodE:
Workflow is now: Make a PCB in Upverter (or import it from something else!), Export as OpenJSON, convert it with my tool, then edit the PCBmodE JSON files as required to prettify them up, and transform them into something amazing.
The tool is here, pull requests / issues welcome. Only a small amount of available things to convert are completed, there’s lots more work that could be done.
