I am an Engineer in the Boston area. I like making things, teaching people how to make things, and tea. This blog is documents the things I make and do, and provides instructions on how to do the things I do, or make the things I make.
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.
Lost Range (millivolts)
New LSB size (LSBs)
Compensated INL (LSB)
INL Improvement (LSB)
Compensated INL (Volts)
*this is actually much worse
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:
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.
STD.DEV. (Ideal volts)
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.
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.
Average Width ± std dev (LSB)
Worst DNL (LSB)
Wide Codes (#)
Max INL (LSB)
Max INL (volts)
Missing Codes (#)
*the standard deviation is so absurd that this does not even matter
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.
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 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.
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.
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.
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.
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.
Just another version of the micro word clock. Like the old version, this uses a matrix that is more widely available than the original matrix, including on adafruit. Unlike the older version, this version is very tiny (no larger than the display) and it incorporates a battery fallback for the RTC, as well as a USB connector for power. This was a fun layout as I had to balance my hype for assembling teeny tiny parts (generally low) vs size.
PCB Layout Trickery
there wasn’t a lot of real estate on this board once the display was placed, since it is through hole. The pins basically cage in the rest of the components. In order to get a clean layout (no vias on any of the display pins), I did a lot of pin swapping. Based on having to tweak the code last time for a new matrix, I knew that I had total flexibility here.
I also had to add a programming header somewhere but I really had no room on the front or back for even something like a tag connect. My solution was to add a connector via a castellated connector on the edge of the board. Then I used pogo pins and a little jig to make a bed of nails so the boards could be reprogrammed once assembled.
I also used a magnetic USB connector, which is ancient Greek for “an accident waiting to happen”. These cables come with a microUSB to tiny PCB adapter, and the cable itself snaps on and catches the adapter. the “hot” side has absolutely no protection that I can see, and actively accumulates magnetic (conductive) particles. The power is also routed through an open joint on the end of the connector (kind of a slip ring system). Since it basically adds two unreliable, moving slip joints to the power path, its very important for the coin cell to do its job to prevent the RTC from losing time.
I think the next stop for this project is to teach a few people how to use kicad. its a cool little project that’s hard to mess up, but that makes a pretty neat little widget without too much trick soldering.
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).
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).
After my first dactyl, I decided I needed at least another one, maybe two for my home, my office, and some third place. Unfortunately, instead of just sucking it up and wiring it by hand, I had the delusional notion that it would take less time for me to make a flex PCB to do the wiring for me.
My initial design process was to do a quick paper prototype. To do this I printed out (on a 2d printer) a lot of 1u sized pieces of paper and fit them to an empty dactyl shell. bridges were added to these connections, and the whole thing was scanned on a flatbed scanner. after a few iterations I had a pretty organic board that fit pretty nicely, but ultimately it was going to drive the price up because it did not use board area efficiently, and it was going to bump me out of a lower price bracket.
The original design helped me work out some of the main layout challenges around the thumb cluster, which was helpful for the next iteration. Unfortunately, the organic shape made the flex quite inefficient in space usage. Instead of trying to get a flex that would conform exactly to the shell, I realized the main spacing issue was between columns (keys are spaced about 23 mm vertically). To simplify routing, I decided there would be a single connector between columns, with a few specialized connectors for the thumb cluster and the ‘extra keys’.
I went back and forth between physical prototypes, electrical layouts, and sketches to arrive at this final shape. Paper cutouts are a cheap and fast way to design, and making a physical model gives me a lot more confidence in terms of clearances (especially for assembly). Doing this in a CAD model would have been possible, but nightmareish, due to the curvature and odd angles of the switch connectors.
Here is the final version! Since its a pain to make the actual flex parts of the pcb in kicad, I tried to minimize unique flex connection types.
The inter-column connector design was refined over time, and it let me make sure I had the right number of interconnects between columns. Due to constraints in kicad in routing arcs, the actual flex had to be laid out and then converted to a pad footprint in the footprint editor. this means the flex tracks are represented as parts on the schematic, which is a little annoying because it makes the nets not work for DRC errors/net connections, as each pad can only have one anchor. It also made it a little irritating to change routing, because the actual footprint/schematic needed to be changed to make a routing change. On the other hand, I was guaranteed identical routing between all my interconnects.
There are a few little flex details that I threw in, which I hope help make the board more functional mechanically. As you can see above, the main flex parts were routed without overlapping copper to prevent the thicker copper (copper-kapton-copper standwich) from stiffening the flex. I also tried to add maximum radii on the parts that would flex.
Here you can see the bridge where traces go to the microcontroller. on this flex, there are a couple notches which should help define a board flex location.
Diodes were placed to minimize the stress on the solder joints by putting them perpendicular to the flex direction.
Well…its ordered. The rest of the keyboard parts are in hand, so I am hoping to have another keyboard in a few weeks, with a lot less wiring!
Dactyl builds seem to mostly be done by people who either know what clojure is (professional keyboard pokers), or at least people who are in the electron herding/plumbing industry. This means that there’s not a whole lot of build guides written by people who know to hate STLs with a burning passion, and who might actually want to use typical feature-based CAD (and not keyboard mashing) to edit their keeb to their liking. While there are many reports of being able to open openscad files in freecad, that did not work for me.
Fortunately joshreve used python to make a generator that can create a STEP, albeit one with a lot of self-intersecting and bad geometry that prevented solidworks from opening it on the first go. After a few hours of editing, I was able to knit up all the surfaces and make a solid body. But shoutout to joshreve-this work was critical!
I picked an extremely whacky keyboard to build, because why not? Worst case I get hooked on it, spend a lot of time making a keybord nobody else will use, and I have to build my own keyboard for the rest of my life. Best case, I make it and decide its awful and retreat blissfully into querty land.
Unlike most people who seem to tout the wonders of the manuform, I do a lot of CAD. CAD means you use a mouse, and you have to type a lot of numbers. I’d like to see what the manuform can bring to that- specifically, can I right-hand-mouse and left-hand-numpad? Would I like a layer for common shortcuts just for specific programs? Would it be cool to have a trackball built into my keyboard? I have questions that have not been answered by a cursory google search and so I will have to find out for myself.
What did I change?
As a mechanical-type engineer, I like things to fit together without having to drill extra holes or to hot glue in connectors. So it was important to get the case holes right, to prevent that. The micro however, will be taped (double sided) to the interior, since there will be no force on it from removing connectors etc.
I also moved the screw bosses to the inside of the case, since they will look better there. they are sized for M3 heat set inserts from McMaster.
Of course, there has to be some frivolous embellishment on it because it is both 3d printed and a keyboard. Instead of spending hours on this, I just threw some text on the “knuckles” of the keyboard. “PROTO–TYPER” seemed to be appropriate, as it is a prototype to see if I like split weirdo keyboards enough to keep using them.
There are better guides out there on this but overall it is straightforward to wire these keyboards and if done carefully, there is little danger of anything shorting out, and even if something is shorted, its easy to fix. If I were to do it again I would use enameled copper wire or fully stripped 28 ga wire and a wire wrap tool, with cut to size ptfe tubing as the insulator. I think this would be easier than carefully cutting 20 or so small wires per row. I will say that it took a surprisingly long time to solder this, even for someone who is fairly good at fiddly soldering.
Update: A Few Months Later
It took me a few months to button this project up, and in the mean time I have been using the keyboard. It is now my daily driver- for everything. Surprisingly I have been spending most of my time in kicad and altium instead of solidworks, but the time I have spent in all three programs has been pretty pleasant.
I think the most challenging thing will bet to remap all the important shortcuts to the left hand, and for those that cant be remapped, to make an application specific layer. For example, the ‘M’ key is really important for moving things in kicad- but its on the right hand. That means that to move stuff, one of my hands has to come off the mouse or the keyboard.
One thing that has been surprisingly nice is my navigation layer, which makes the left home keys arrow keys, and the right home keys the mouse directions. the thumb keys on the right side become left and right mouse clicks. I would say if I am not in a cad program, my hands stay on the keyboard, which is nice! The only issue is that its easy to get stuck in a layer (or my numkey layer) and not know that I am in that mode when I first sit down and start typing my password. some kind of indicator will need to be built into the next version.