In my last post, I discussed the basic requirements and layout of my lamp – I wanted it to be able to control the color temperature and brightness, and I wanted it to be really bright. I experimented with a single strip, and detailed how the control board would work. If you want to try to build your own, the code/boards are here, although it is not very well documented.

Here is the control board all wired up. It packs an ESP32-C3, because I had one on hand, and because connectivity is important for this project. In addition to manual over-the-air control, I want to be able to put the lamp onto a simulated daytime color temperature loop- a real-life version of f.lux, which turns up the warm temperature light on your display as the day progresses. I also would like to add a way to sync it to some kind of live color temperature data.

This wiring leaves a lot to be desired- this is because the boards and mechanical assembly were developed at different times, and the mechanical side of things ended up going to “plan b” aka laser cutting. It might be worth revisiting in the future, especially because a lot of ports/connectors ended up unused. For now, I am just happy to have a lamp.

Here is the control page that the lamp serves up. It lets you choose a mode: SYNC, MAX, or NORM.

Norm is a smooth light intensity with changing color temperature- the output never exceeds the brightness of having all warm or all cool lights on, so when the temperature is “balanced” the output is 50% brightness warm, 50% brightness cool.

Max allows for the overall maximum light intensity to vary, but keeps the mix “smooth”. So at full warm, 100% intensity, the brightness of the warm strip is 100%, and at “balanced” temperature, 100% intensity, the output is 100% warm 100% cool.

SYNC will take over both intensity and temperature and to create a profile that mirrors a day, which is still TBD- to be developed. There are many ways this could be implemented, from having the lamp look up the weather/sunrise/sunset, to building a weather station, to having a server on a main home automation controller that tells the lamp what to do. Its also not totally clear to me what the ideal profile would be- for example I would like to have nice bright light, even in the early evening, so I don’t want it to totally follow the real “day” profile.

Mechanical Notes + Details

This lamp, despite not achieving one of my crazy tensegrity ideas, fancy woodworking concepts, or brass-pipe dreams, does use one of my favorite tricks: using orings as precision rubber bands. The LED channels are very thin, and therefore fairly hard to attach to with screws. They are meant to be mounted with supplied clips, but I didn’t feel great with those overhead, since they are not closed on the bottom.

Instead of clips, I used the aforementioned fancy rubber bands, with two per side (four total) per LED channel. This means that if one breaks, I will have time to notice and replace it. Since they are flexible, the overall alignment of the strips matters less and the hole placement does not need to be spot on. They are also very thin, so they don’t block light.

Another interesting fabrication note is how I removed the scorching from the laser cut cross-bars. These were completely covered in soot as-cut. Usually cleanup of parts like this is annoying and time consuming because the soot is ingrained in the plys of the wood. This means the parts need to be sanded back significantly in order to remove the soot, causing the overall shape of the part to change. In this case I had access to a media blasting cabinet- a light blast with glass media removed most of the scorched material, saving time and preserving the shape (and sanity).

Done?

This is the kind of project that could go on forever, but for now I will enjoy having a nice lamp. Here is a short list of improvements for “someday”:

• use websockets for more responsive control of the lamp
• make lamp status persistent
• find a nicer looking power supply
• add a setup page/wifi STAtion mode as a fallback in case it can’t get on the network
• finish daylight color tracking/sync mode
• redo the PCB +other components to make it less of a noodly mess
• add a display (of some sort) to show the IP address
• use the neopixel on the dev board to indicate connection status
• etc.

After listening to my Make Your Own Gnome, I decided I wanted to make my own led lamp. Specifically, I want a lamp that:

-is dimmable from “nightlight” to “worklight”

-is color-temperature adjustable from warm to cool light

-has some kind of smarts- daytime color temperature tracking, live outdoor color temperature matching, remote control

LED Choice

I decided the “hybrid” LED strips from waveform would be nice based on having a high CRI, and having a mix of warm and cool LEDS on separate channels. These LEDS strip lights are “DC constant voltage” strips meaning that you put 24 volts across the power/ground of each to light them. Each color temperature has a separate ground, for low side switching. Each rail (one per color temperature) has in parallel several sets of 6 LEDs in series, with current limiting resistors. The number of LED units in parallel is controlled by the length of the strip, with 6 LEDs per color per 4″.

Since I want to have worklight-bright intensity from either a warm or cool color, I need about twice as many feet of LEDs than I would with only one brightness. Empirically, this is about 4.5 feet of LED strip (per color), or about 2000 lumens, or a total of 9 feet and 4000 lm combined.

System Architecture

I decided to have a main control board and several strip driver boards. Each control board has switching supplies for 3v3 and 12V, and an ESP32-C3. The control board has enough connectors for three channels of output consisting of warm white PWM, cool white PWM, and driver enable, as well as a connector to distribute 12V. 12V is used to run the FET gate drivers.

At higher currents (single- digit amps), the inductance of the wires from the power supply (30 cm or so) and the switching can start to cause some ground bounce, so having local decoupling is needed- and reducing the overall strip length also reduces the total inductance per-strip. Above is the drain of the fet switching the warm channel- as you can see switching what is essentially two inductive loads causes some voltage spikes, which fortunately do not exceed the VDS of the FET.

This modular architecture also lends itself to reuse for a two or one strip lamp.

Switcher Board Detail

A FET driver is way better than driving the FETs directly from the microcontroller, because it drives the gates at a high current, higher voltage, and without the inductance of long wires coming from the controller board (which could be several feet away). It also reduces the requirements for the FETS, because they do not need to have low RDSon at logic level drives.

Driving the FETs fast is important, because the longer switching takes, the longer the LEDS will be operating with additional current limiting, and therefore far from the target current. This change in current can cause the leds to shift their output spectra, which defeats the purpose of having really nice high CRI LEDs. Additionally, the longer switching time can lead to frequency limitations e.g. if the switching time starts taking up most of (or exceeding) the period.

I want to switch at 25kHz- this is above the audio threshold, so any components vibrating due to switching (capacitors) won’t be audible. This is also well above what a person should be able to notice for flicker (120 Hz) and it seems like its also well above the frequency where it would affect a phone camera with a rolling shutter. 25 kHz means that the period is 40uS. I estimated that I want at least 10-100% duty cycle, so a minimum on or off time of .4uS. I estimated that the total switching time should be no more than 10% of this minimum time, which gave a rise/fall time of 200nS.

The FET has a gate charge of about 9nC, and the driver can source on the order of 1A, so the switching time should be a on the order of 10 nS- well under the 200nS limit. This means that the minimum on time, allowing for 10% of the waveform to be rise/fall time, is 200nS. This would allow dimming to .5% full brightness, which is very dim indeed.

As you can see here, the real rise time is pretty much the predicted 10ns, with a symmetrical falling time, so the driver should be suitable for this application.

Concluding Thoughts

The switching board works fine, and I’ll certainly use them. The light is GREAT and being able to control the color output is awesome! Of course, in the process of this design I have come up with some improvements for a next iteration.

First of all, the efficiency of these lighting strips is Not Great. Per-color channel per-section (4″) they consume almost a watt (.96 W). The problem is that the LEDs consume only 70% of that energy, and they are not 100% efficient. 30% of the energy is burned off as heat in the resistors, which are wisely distributed along the strip. While this is much better than an incandescent bulb, it makes the strips get pretty warm, with the outer aluminum shell reaching about 40C in 20C ambient temperatures.

The reason for this voltage design decision seems to be wanting to run the strip off a higher voltage to reduce IR drop along the length of the strip, and 24V being a ubiquitous supply voltage. Since my strips are relatively short for this type of application, IR drop is not a huge issue. Given 6 LEDs in series, dropping down to even 20V would result in an improvement to about 85% efficiency.

Going a step further, a current-controlled switching supply could be used per-section of LEDS. While this is more expensive, I expect it to be much more efficient (close to 90/95%). Given that I’m not sensitive to a small increase in BOM cost, this could be just fine.

Second, I found the WAGO connectors to be annoying to hand solder, and a bit expensive. They are really nice, but ultimately I don’t think they are worth it. Standard screw-terminal headers would be just fine.

Next up: building the lamp+controller.

In my last post I explored the errors of unprocessed ADC data. In this post, I will show what happens if you add some simple gain + offset correction.

Gain error is caused by DNL. The ideal code width is 1, but lets say that there is a predictable DNL error of +.1 LSB- that means that for every code (and there could be a lot of codes!), the measured value strays from the ideal value by +.1 LSB. At the end of the range, the difference will be +.1LSB * number of codes. This (in the example) is equal to INL. Take a look at the INL of the arduino above- the average code width is 1.08, so the INL increases by .08 LSBs/code. Therefore the INL looks like a straight line when plotted against LSB.

If we just assume each LSB is a little bigger, we will get a much lower INL. This will cause us to loose a little voltage resolution (.08 LSBs), but we will end up with a MUCH lower INL. This is the same data, but with gain correction. INL was reduced from 85 LSBs to about 6 LSBs.

However, the INL can still be improved- at low voltages, the most ADCs dont work very well. This causes a large DNL at the first code, as seen here in the corrected plot. This is where the line shoots straight up from 0 to about 6 at the first ADC code.

On a plot of DAC input-ADC output, it looks like the above – basically code 0 has a huge width. We can null this out by just adding a small offset to all the data. That means code 0 will still be wrong, but the rest of the codes will be right. because only the first code is messed up, we can usually ignore this error because we it only exists for a single code (code 0).

Here is the DNL for the fully corrected ADC- the max DNL across the whole ADC is closer to .8 now, except at code 0, which is off by about 6LSBs. This is equivalent to saying we cant measure less than 6 LSBs, but that if we make these corrections we will have an accuracy that is about .00084 mV (with 100x oversampling). That is pretty darn good.

What about the other ADCs?

How much can the other ADCs be improved? The ADS already has a pretty perfect gain and very little offset, so I skipped trying to fix it. Note the new LSB size and standard deviation are different than the previous values – to avoid the influence of the extremes of the ADCs, I only used the middle 90% of the ADC range to calculate the average LSB size.

Surprisingly, the ESP and the SAMD are much closer in this comparison. SAMD still wins out, but at least the ESP32 has recovered slightly from having a three-digit INL. The one caveat here is that my calculation of code widths does not account for missing codes, which produce -1 DNL each. This data is correct if the missing codes on the ESP (of which there are 15) need to be ignored for this to be valid.

Hopefully my catchy title helps people find this post. After spending some time building a tools to compare A/D converters, I wanted to share some results from popular micros and previously popular (but now out of stock) ADCs.

Single Reading Accuracy/ENOB

ENOB, effective resolution, noise free resolution – these are all ways people describe an adc. I’ll provide the ENOB based on IEEE 1057, which is described as:

ENOB = log2 [full-scale input voltage range/(ADC RMS noise × √12)]

I will also list how good a typical measurement is from 5-95% of full scale. This comes from the average standard deviation across all codes. In theory, this is equal to the ADC RMS noise. I like this number because it tells me the typical LSBs of noise from the converter. However, because I didn’t test per-code the type of distribution, it does not necessarily mean that the noise distribution is gaussian.

If the noise distribution does not behave in a gaussian way, the predicted oversampling will not be accurate, as you can see here. The orange is data oversampled at 16x, and the dark purple color is the predicted standard deviation.

Here is a histogram for a random DAC input code from the ADS1015. As you can see most of the codes are code 400, so oversampling wont help much- the average will not improve much because most of the time code 400 will be returned.

Compare this to the SAMD standard deviation plot:

Here the predicted and actual 16x measurements start to line up pretty well round code 40000. If we look at code 42000:

The distribution looks a lot more gaussian, and covers many codes- in this case averaging can help, and the predicted error lies up nicely with the measured error.

Unsurprisingly, the ADS1015 is the best in terms of ENOB. Since the ADS is actually an 11 bit ADC (it reserves a bit for the sign, but it never uses it in single ended mode). It costs as much as any of the other chips, but it has only one job: being an ADC. The ESP32 really is pretty bad, as it loses about half its effective bits to noise for a given reading. The atmega comes in at a respectable 9.7 bits! The resolution is lower than the ADS, but much better than the ESP.

The SAMD21 ADC is what I would like to use. looking at the standard deviation chart, it looks like 16x oversampling is reasonable to do. This would give similar performance to the ADS1015 in terms of noise.

DNL/INL

The ideal code width for an ADC is 1, and the DNL is the error from the code. If we have consistent code sizes, it will be easy to compensate for, but codes that represent an extra-wide or extra narrow voltage range are more difficult to compensate for. If the DNL is -1, the code will be missing (the narrowest width a code can be is 0). Missing codes are very bad, because its hard to tell if they are missing or just really really narrow. If you map the adc and compensate by ignoring that code, there will be an LSB of offset when it reappears.

The most interesting stats here are the average code (this better be about 1) width and the standard deviation. If code widths are all about the same (even if they are say, 1.2 on average), it’s good, because each step is a predictable size. If the widths are all different, its hard to tell how much the measured voltage changed with 1 LSB difference.

I flagged any codes that were larger than 2 standard deviations from the mean. For most ADCs this only catches high (wider) codes since if the standard deviation is >.3 LSB, 3 standard deviations below the mean is a missing code (DNL = -1).

INL was calculated as the sum of the DNL. Max INL is the maximum error you expect to see from a straight line. Positive and negative DNL cancel out, but very high DNL mid-range is hard to compensate for because you need a lot of small negative codes to get rid of it- and while positive DNL can go to any number, INL can only go to -1 before the code disappears.

High DNL at the start or end can be compensated for- basically, you just add a DC offset and dont use those codes. If the LSB error is consistent, or if steps are mostly slightly wide/short you get a gain error, which can also be compensated. However in the middle, it is hard to compensate for because there is a big jump. In theory you can just note that measuring a specific code maps to a wide range of voltages, but that makes the ADC kind of nonlinear and bad, plus you need a huge lookup table.

I took measurements with and without the gain/dc offsets applied on the ESP32 and SAMD21 ADCs. Both these micros have built-in compensation values. I also manually compensated the Arduino ADC for fun.

For Worst DNL, I only included values from 5-95% of the range, even for uncompensated ADCs. I feel those numbers are a better metric for how good an adc is mid-range. If no wide codes were reported, I gave the highest code width measured between 5-95% of the range.

As you can see, the ESP32 ADC really is terrible (as promised by the datasheet). The standard deviation, DNL, and INL are all high, and there are missing codes! On the other hand, the dedicated ADS1015 is really good. The thing that surprised me here is how bad the SAMD21 is in terms of worst case DNL. It does not add up quite as high as the ESP, but its still not great, especially with all the wide codes that it has mid-range.

(Un?)surprisingly the Arduino ADC did well in overall INL, even uncompensated, compared to the ESP32. This is pretty cool, since a lot of people use it. The INL error chart shows it should be pretty easy to compensate. this is a “good” plot because it shows that on average the code width is a little wider than it should be, since INL increases in an apparently linear and monotonic fashion, with some offset near 0.

Compensation:

I will look at this in my next post, using the collected data. Aside from oversampling, the next adc-error correction technique is to change the assumption that 1 LSB = 1/2^n volts. If we have measured all the code widths as 1.1 LSB (in volts), then every code we are (on average) adding .1 LSB INL! This causes gain error in the ADC.

By assuming that each adc code is on average wider/thinner than 1 LSB, we can correct this gain error. The tradeoff is a change in range and in resolution- if the resolution goes up ( average LSB<1) the range will go down- we wont have enough bits to measure the whole range. if resolution goes down ( average LSB >1) the resolution will go down but the range should go up (although it may not, because ADCs are poorly behaved at high and low values).

I built a tool to measure DC performance of an ADC. Since I have it, I figured I may as well use it to investigate the four ADCs I have lying around- an esp32, and arduino uno (atmega328), SAMD21 based feather board, and the ADS1015. This post is about the data I want to collect and analyze.

Key Performance Indicators:

The things I look for in an ADC for DC performance are a high effective number of bits (including with oversampling), good monotonicity, low DNL and INL. All of these characteristics are related, but each one gives me a feel for the ADC, and only some of these are listed in datasheets.

Here is the data I intend to capture.

Standard Deviation + ENOB

The standard deviation per DAC output code is a good metric to start with. It is important to have resolution, but if the lower bits are twiddling back and forth seemingly randomly, they are not really useful. We can measure this twiddle and find out how many bits are useful- the effective number of bits (ENOB), for a single read. Even better, that twiddle might not be random- if we look at 100 codes and average them, we should get closer to the “real” value (oversampling).

I took 100 readings with the ADC per output code. The “true” value of the ADC is probably close to the mean of these readings. I calculated several standard deviations based on this mean- the standard deviation for the population of all readings, and then the standard deviation of oversampling 4x, 8x, and 16x.

As the oversampling increases, the standard deviation of the population of oversampled results decreases. Basically since we are averaging a bunch of samples, the random error cancels out and we end up closer to the mean. The standard deviation should be reduced by a factor of 1/sqrt(n) where n is the number of samples (standard error). Here you can see the results of a run with the SAMD21. I plotted the 1x and 16x sampling, as well as the predicted 16x sampling (dark blue over orange). It is pretty cool to see the theoretical value line up with the measured value. If these don’t line up, its a sign that the errors are not random- and that means that oversampling wont actually help get close to the “true” value.

One artifact of calculating ENOB this way is that at the edge of a code, the standard deviation is going to be really high compared to mid-code. You can see this effect here- the xticks are set to be the width of an ADC code, but they are not aligned. Usually the standard deviation is pretty small, but it gets really big near what are likely code transitions. Since we usually don’t have a map of the whole ADC when we are measuring something, we have to take the worst case scenario (our measurement could be on a code). Still, averaging helps improve ENOB.

Monotonicity

Monotonicity is related to ENOB- the output codes should be monotonic at the effective number of bits. Since my reading from the ADC is in terms of averages of 100 readings, I will use the standard deviation/10, since the standard deviation should be reduced by sqrt(100 readings). The worst case standard deviation is about 14.5 LSB, so I chose to look at the output code every 1.5 LSB ADCs of input voltage.

In theory, this should always be a positive difference- the output code should increase by at least 1 every 1.5 lsbs. However, this is not the case. There are 39 non monotonic jumps, and each of them is only a little bit bad- about 1 LSB. In terms of the code/code plot. these correspond to flat spots, or places where the codes actually decrease, or are flat, as seen in the next section.

Max DNL

There are two DNL errors to look for, DNL<-1, which causes missing codes, and DNL>1, which causes non-monotonic (not always increasing) behavior. Looking for missing codes is easy and is done more or less by brute force – fortunately in this in this example, there were no missing codes.

It is not surprising to have codes be wider or skinnier than 1 LSB of the ADC. However, DNL>1 causes a the ADC output to be flat for a while- this means that we have extra error that we is hard to account for. I looked for codes that were more than 3 standard deviations from the mean width, and then plotted the errors. The widest code (aside from the expected nonlinearity near 0) was an astounding 7LSBs!

Max INL Measurement

To get the INL, I just took the sum of the DNL’s. Since I didn’t correct for offset in this case, there is a large jump in DNL at the start.

Conclusion:

I now have a tool for measuring real world DC performance of ADCs. I have a few ADCs lying around, and I want to figure out what kind of defects they have and compare them!

With the ADSXXXX series out of stock for the foreseeable future, I needed to evaluate the ADC’s on several micros to understand if they would be good enough for my application – reading oxygen sensors. Mostly I care about DC characteristics, because my signal should be changing very slowly- on the order of many seconds.

I’ve seen a lot of interesting work done on ADC characterization and calibration, but only rarely do the posts explain where the reference voltage is coming from. If the voltage source is noisy or has some nonlinearity or bias, it will throw off the calibration.

really really excellent series on adc error/calibration from thea.codes

demo showing how the esp32 adc is bad

auto-cal of the esp32 adc*

The most obvious way to do this is to generate a really nice (precise + accurate) voltage, put it into the ADC, and then figure out what the expected error is for a sample or for multiple samples. With enough resolution on this voltage, I can look for missing codes (high DNL) and for error in value from code-to-code (INL), and find really good gain and offset correction factors, and come up with an idea of how good the ADC is (at DC, for some ADC settings, etc).

The trick, of course is generating the nice voltage. Since I don’t have a sub-mv programmable reference voltage, I had to buy one. Since I didn’t want to spend hundreds of dollars on a non-programmable benchtop equipment, I decided to buy a 16-Bit DAC. These chips are pricey, but on the order of a pastry and a coffee, not a nice bicycle or oscilloscope. Instead of spinning my own board, I bought an eval kit to speed things up.

The DAC8050X comes in a one and two channel flavor. I got the two channel flavor in case I wanted to make differential measurements at some point in the future. These are really nice, and offer <1LSB nonlinearity. This is really pretty impressive to me, and looking at the typical characteristics, the INL and DNL are way way lower than 1 LSB.

The DAC80502 is also pretty sweet in that it has programmable gains for both the reference and the outputs- this gives it a really wide range of outputs, without any external circuitry. It also has an external VREF in, so you can supply a voltage range you care about. Combining the two outputs with some creative-op amp-ery could give you a really wide range of voltages to play with, but I really care most ab out the sub-3v range, which this is perfect for.

*this seems somewhat sketchy given the really bad stated INL/DNL for the adc, and the fact that the DAC on the esp32 seems to be 8bit. it might make the output look linear, but I wouldnt use it for anything important

Who tests the Tester?:

When making measurements against a standard, its important to understand how good your reference is. In this case the DAC is being used as a reference, which means it needs to be very “nice”. There are many charts in the datasheet, showing that all kinds of systematic and thermal drift, referred noise, error under load, etc. The total unadjusted error appears to be around .02% typically, and the INL/DNL per code is <<1 bit, usually around .2 LSB. While these charts are all very reassuring, its nice to verify them.

To do this I connected the DAC to a nice 6.5 digit multimeter (Agilent 34465a) and captured a 5 reads at each output code, and then calculated the error per code, to verify. This turned out to be a slow process, because 2^16 (65.5k) times even a few milliseconds is a LONG time. In order for the instrument to have a high enough resolution/accuracy, I had to wait a long time for it to collect data, so the test ended up taking ~4 hours.

N.B. the 34465A is a lot faster at resolving lower voltages than the lower spec models- those would have taken even longer!

This chart shows the measured voltage and the difference in voltage from output code-to-code in LSB. The ideal difference code-to-code should be 1LSB of voltage – 1 LSB is Vref/(2^16). A difference of 0 indicates no change in output (a missing output code) and the distance from 1LSB indicates how far from the ideal each step is (INL). A different-sign difference between codes, which we don’t see here, indicates that the output is not monotonic (increasing or decreasing constantly). Fortunately, the worst thing seen are some missing codes at the start.

NB: this happens even without auto-zero on, and the meter can read negative voltages, so these really are missing codes (DNL>1). This seems wrong compared to the datasheet, but my measurements should be good enough to capture this. That said, I wont totally rule out some small dc offset or error in measurement.

That means this DAC is pretty awesome. The standard deviation of the errors is about .073 LSbs. Its not quite gaussian (kurtosis 1.17) because it has basically no tails, but its close enough for me. As you can see the LSB error code to code (DNL) is usually less than .2, which matches with the datasheet.

NB: this result was obtained under ideal circumstances. When I worked at my computer/charged my phone right next to it and generally jostled the setup, I got non-monotonic readings an more LSB error. With short wires to the DMM and good test practices it performed much better.

Preliminary Data:

Here is a read of the SAMD21 ADC with the internal 1VREF and no gain, compared to the DAC with 1.25VREF. The total error/code is shown below in LSB. This is a lot more than the stated 15 bit total unadjusted error, but I haven’t used the built in gain/offset correction, and I’m not sure if this incorporates the samd21 adc arduino bug. As you can see, a simple offset could reduce this total error by about 40%. Interestingly, there were a couple very odd codes near the 1/3 and 2/3 points where the error quickly jumps.

My flex pcbs showed up and they are just lovely. Unlike a rigid PCB, they are a kind of coppery gold translucent color with shiny copper underneath. And unlike a rigid PCB, I had to spend hours and hours carefully routing every trace in smooth, even curves, so the whole thing just has a delightful aesthetic. They came in sheets of two (right and left) with the flexes being retained in the sheet by a few small tabs. This is a great way for them to come because once they are free of their nest, they become very flexy and floppy (as planned).

Time Savings vs Handwiring:

Wiring up a dactyl with these flexes is dead simple and fast. I estimate that it takes about an hour to put on all the diodes and to solder all the switches. I’ll time myself next time when I am not taking photos (and running to microcenter), but it would be easy for someone to do in an evening, provided you are used to surface mount soldering. My first dactyl took me multiple evenings of careful snipping, bending, soldering, stripping, and checking, I would estimate that took 8++ hours.

Assembly Steps+ Notes:

Soldering to a flex pcb is a little different than soldering to a regular pcb. The big differences are that it is very floppy, and that the pcb coverlay (kind of like solder mask) has very low thermal conductivity, and it is very thin. I did all my soldering on a heat proof silicone mat, with a normal sized chisel tip on a hakko FX888D with tweezers and no magnification. You don’t need a fancy iron, but magnification can help if you are not used to components of this size. The small size components (and orientation) are important to preventing stress on the solder joints when the flexes are flexed. Below are the steps I took to solder this thing. These steps assume you already have a keyboard with the keys installed (look at the flex to make sure you install them in the right orientation- pins should be close to the bottom of the keyboard).

A note on safety: unlike rigid boards, flex boards are springy and if they release at the right time, I’m sure they could shoot some molten solder somewhere bad- say your eyes. It seems like a very good idea to wear some eye protection while working with these.

1: Remove the flex from the backing sheet. This should be done by carefully pulling the flex apart instead of tearing the flex or using a knife. find each tab and pull perpendicular to the tab take your time. Once the flex is fully free, double check to make sure there are no tabs left between the flexes.

2: Diode soldering. The cathode (marked with a line) goes on the “cup” side of the solder mask. Solder the diodes on, or if you want super detailed instructions, continue on. First, I deposited a small blob of solder on one side of every diode pad. I put the solder on the pad on my dominant hand side. Then I laid out a bunch of diodes, and lined them up so all the cathodes were facing one direction. on this board, most of the diodes are cathode-on-left so that is how I lined them up.

Once I had all my diodes ready to go, I started tacking them to the board, working towards my dominant hand. that way the iron/iron wielding hand does not have to cross over already soldered components. Once the diodes were soldered, I rotated the mat that the flex was on and tacked on the other side. if a diode didn’t look flat, I took it off and reworked it.

3: The next step is to start to install the flex. I started on the outermost row (outside the pinky row). I simply pulled the pcb up and into the shell- it was happy to extend out like a slinkie so that some of it was outside the shell while I worked. First, I made sure that the pins from the switches went through all the holes on the pcb, then I tacked down the first and last pins with solder. Once the flex was tacked, I went through and soldered each pin to its pad, making sure to get a good connection. Once the row was done I would start the next row.

4: Thumb cluster buttons are a little different- each one lives on its own little mini flex connection. It worked well for me to tack them down one at a time. NB the “L” peninsula buttons do not change orientation- the bottom side of the PCB should always face the switches.

5: Solder the micro. NB the island that the micro sits on is meant to be folded over, so that the micro sits on top of it. There is some text that says “THIS SIDE UP” to indicate the right side. If your micro came with headers on all the pins, and you don’t want to remove it, you can snip off the extra flap of material. The USB connector should point “down” towards the thumb cluster. The micro orientation might seem strange to some- its mean for a USB bulkhead like this one, so the “wrong” orientation is meant to let the cable have a nice service loop in the shell.

6: Program the micro. Plenty of tutorials on that, and I will have some files up soon to fix a few pin order mishaps that happened on these boards (one header is flipped). NB some kapton tape should be placed under the micro to prevent shorts.

What went wrong:

Inexplicably, I flipped a single header, so there may need to be separate firmwares for the left and right hands. This is annoying, but not nearly as annoying as wiring up a whole dactyl or screwing up in some way that is not a small matter of programming (SMOP).

What’s next?

I need to test the right side and finish my second keyboard (for the office).

How do I get one?

Twoards the end of the week I will be putting the extra prototypes up for sale. If you are interested, you can submit some info here to be notified.

Hey! where are the design files?

At the moment, I have decided not to share the design files. Unlike many projects there is little to be learned from them for repair or use. The boards are literally transparent, and the schematic is the same one thats been used on pretty much every dactyl. I have decided I want a bit of a head start selling these to recoup some of my costs before I make it easy for anyone to just go and buy a grip of them and sell them and put them up for sale (however unlikely that is).