Alex Mo Tech - The Blog!

Hardware

Can’t start the software without a little hardware! We need to make a quick programming jig to move between “serial programming” and “run” mode.

I used parts-box parts but you can get similar parts from almost anywhere. Just in case, here’s an ingredients list:

3.3v FTDI cable/module

ESP8266-01

Push button switch (for the reset line which is active low. You’ll see I used a mouse button for some reason but if you use a push button, you’ll need a pull up resistor)

A latched push button (for power but I used another mouse button)

DPST/DPDT switch

Headers (both female and male)

Some perf board

Here are the pin configs for serial programming:

and so this is the schematic we’re after:

Again, I only had the parts I had so here’s the schematic with what I had:

And here’s a quick map of how the perfboard is laid out:

(The boxes and blue lines represent top-layer components and wires, the red lines represent solder mazes)

(Here’s the back side so you can basically put the parts in as in the first photo and solder the traces on the back like this photo)

When all is said and done, you end up with this:

Easy as pie and hardware part done!

Software

Alright, so next up let’s get the toolchain setup, upload the blinky code, modify, and upload again so we feel good and ready to move onto projects. I chose open-esp-sdk purely because others really liked it. 

This process is pretty typical but here’s the idea:

Install Dependencies (apt-get) -> Clone the Repository (git) -> Build the Project (make) -> Globalize the Tools (assigning to a global)

Then it’s time to build the example and load it up on the ESP.

Build Blinky (make) -> Power Cycle the device in program mode -> Load the new binary to the board (esptool.py) -> drink beer in celebration

Setting up the Environment

Install the Dependencies - download and install all the programs that will help you build the environment, build the esp binaries and use the upload tools

sudo apt-get install make unrar-free autoconf automake libtool gcc g++ gperf flex \ bison texinfo gawk ncurses-dev libexpat-dev python-dev python python-serial \ sed git unzip bash help2man wget bzip2 libtool-bin

Clone the repository - for those who are new to git (many at my company were when they came aboard, obviously me included) all this is is just copying a project that someone has posted to git down to your computer. Make sure you go to the directory where you want your project to reside and type:

`git clone --recursive https://github.com/pfalcon/esp-open-sdk.git`

Build the Environment - When it’s done, cd into the esp-open-sdk directory and make the project

cd esp-open-sdkmake STANDALONE=y

The “STANDALONE=y” ensures you get the xtensa toolchain and the esp SDK.

Depending on your hardware this may take a while. Just for shits and giggles I installed it on my Crubuntu laptop which took an hour (to be fair I was watching netflix on the Chrome side). If it goes off without a hitch, it will report 

Espressif ESP8266 SDK is installed, its libraries and headers are merged with the toolchain

Pitfalls

I’ve encountered two errors when I tried this though - one was when I followed the github instructions and didn’t try to install libtools-bin (since it said you may not require it). For safety, I just put it in my apt-get command above.

The other was because I had played around a bunch on my computer and had the LD_LIBRARY_PATH variable set to which it complained 

[ERROR] Don't set LD_LIBRARY_PATH. It screws up the build.

If that happens, make sure you clear your LD_LIBRARY_PATH environmental variable with 

unset LD_LIBRARY_PATH

and try again.

Globalize the Tools - We’ll want to make it so that we can access the xtensa gcc toolchain (which we’ll use to compile link and convert our sourcecode to ELF) and the esptools (which we’ll use to convert to a binary and write to flash locations on the chip over serial) everywhere. To make that happen, we need to add the path to xtensa-lx106-elf-gcc and esptool.py to the ~/.bashrc - the file that loads every time we load a terminal session.

There should have been a line above the success message that says  Xtensa toolchain is built, to use it:

export PATH=[your_path_to_esp_open_sdk]/esp-open-sdk/xtensa-lx106-elf/bin:$PATH

Go ahead and do that - type:

export PATH=[your_path_to_esp_open_sdk]/esp-open-sdk/ xtensa-lx106-elf/bin:$PATH

But let’s also add it to our ~/.bashrc which controls what happens when we open a new terminal:

echo “export PATH=[your_path_to_esp_open_sdk]/esp-open-sdk/ xtensa-lx106-elf/bin:$PATH” >> ~/.bashrc

and then we’re good! To test if that worked, cd to the esp-open-sdk directory and then do 

cd examples/blinky

and type 

make

If that went through well (i.e. it didn’t throw any complaints to you), you’ve properly configured your environmental path variable. Now remove the blinky binaries (make seems to make different binary locations than those used in make flash and make clean)

rm -f blinky blinky.o blinky-0x00000.bin blinky-0x10000.bin

Testing with blinky.c

Our next goal is to run blinky on the board.

Test the Serial Port

First let’s make sure we have access to the serial port so we can program the device. Connect your FTDI programmer to your USB port and type

dmesg | grep FTDI

It should list a line like this to tell you which /dev the FTDI connected to like 

usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

Next, send something like (where ttyUSB0 is the device you got)

echo -ne “\r\n” > /dev/ttyUSB0 

If you just get another prompt pop up immediately after, you shouldn’t have anything to worry about and can move to the next section. If you get the Permission Denied message, you need to add yourself to the same group as your FTDI port. Let’s find out which group we need to be a part of. Type:

ls -l /dev/ttyUSB0

and you should get something like:

crw-rw---- 1 root serial 188, 0 Jun 19 02:52 /dev/ttyUSB0

Many sites online just say to add to “dialout” but you see that my port is connected to the group “serial.” I can add myself to that group with:

sudo usermod -a -G serial alexmo

and then log out and log back in.

Now when you’re back in, if you retype

echo -ne “\r\n” > /dev/ttyUSB0 

you shouldn’t see the permission denied message.

Build

Build with 

make

You’ll see a few new files. The binaries marked blinky-0x00000.bin and blinky-0x10000.bin tell you where they should be written.

Program

Now let’s program the device with the binaries. If you see blinky-0x00000.bin and blinky-0x10000.bin, just type

esptool.py write_flash 0 blinky-0x00000.bin 0x10000 blinky-0x10000.bin

It will work on it:

esptool.py v1.2 Connecting... Auto-detected Flash size: 4m Running Cesanta flasher stub... Flash params set to 0x0000 Writing 36864 @ 0x0... 36864 (100 %) Wrote 36864 bytes at 0x0 in 3.2 seconds (91.5 kbit/s)... Writing 196608 @ 0x10000... 196608 (100 %) Wrote 196608 bytes at 0x10000 in 17.1 seconds (92.1 kbit/s)... Leaving...

and then start blinking!

Visual Evidence:

First let’s flip it. We were finding what Resistance corresponded to a known Temp, but ultimately we want the opposite - we’ll be measuring resistance, running some math and getting temp out.

There, that’s better. Okay, the first thing we see is that, as resistance gets smaller, temperature blows up. In fact, the resistor will fail before it ever reaches 0 ohms, so intuition might tell us we’re dealing with one of two things: either ln(R) or f(R)/R. We see no other poles so we know it’s not much more complicated than that our independent variable should take one of those forms.

Once we assume one of those as our independent variable, we’ll be able to use least square error to determine a polynomial that will fit this set of data. We could also use Excel/Google Sheets’ curve fitting tool after we determine the form of the equation to expedite, but I’ll go through the motions of the least-square error so that we have the power to use it if we need to in the future!

Okay, on to that equation.

T=f[R]/R

Let’s start by asking what if it’s of the form f(R)/R=T.

If a good model is of this form then we can just find T*R=f(R) and determine f(R). Here’s what T*R vs R looks like:

Amazing right!? Almost linear, r^2=1 let’s dust of our hands and call it done!

Well not quite...

Whenever we have a lot of features close to zero, it’s a good idea to plot the log of the axis where that features is measured. For example, in the case of our resistance vs temperature curve, we have a lot of change occurring when R is very small when temperature shoots up.

Plotting log(R)...

It turns out we’re diverging from the temperature when resistance is very small by using the f(R)/R formula. In fact, its max deviation occurs when resistance is smallest at 6% error which is a 34 degree K difference.

So what if we try ln(R)? Will we get better error?

T=f(ln[R])

So, I should have mentioned this earlier. There’s already an equation. It’s called the Steinhart-Hart equation and it goes a little something like this:

It implies that there is already a dependence on ln(R) and that we only have to go to up to a third order polynomial to get good accuracy. We want to put it through its paces though to make sure we’re hitting the best accuracy we can get.

First, just create a new set of data: 1/T’s and ln(R)

You can’t tell Excel or Google to exclude the 2nd order term and optimize so we have to do it by Least Squares ourselves. I’m posting a quick primer below to remind/entice interested parties. Otherwise, just skip the lower box.

Least Square Error

First, how about some intuition for newcomers/people who are used to just plugging and chugging (agh! poison to my ears!)

The idea is you have your variables (in this case, let’s say 1/T and x=ln(R)) and you assume that they follow a model

 where y is the result of the model for a given ln(R), and 1/T is the experimental 1/T.

So then, the preliminary error between these two would be error=1/T-y

We can find out how good a model is by adding the 1/T-y for each ln(R). If that error is high, then that’s bad. The only problem is some y’s will overshoot the experimental 1/T and some will undershoot it so our error will be positive sometimes and negative at others which will cancel and lessen our sum of errors which is not good! So we square the error in order to only get positive values so really our equation becomes

Now’s the fun part: finding the variables! You want to decrease that error for each of the “design variables” A, B, and C so we take the derivative with respect to each one to find zero points (we have no trouble with accidentally getting a maximum since there’s not really such thing as maximum error here).

These are pretty easy solves thanks to the chain rule:

From here, we can rearrange to get a matrix form of the three equations:

or...

From here, conceptually, the answer is simple: multiply both sides by the inverse of the 3x3 matrix and get an equation for the coefficient vector.

I was on my way to calculating the inverse but, let me tell you friends, knowing the simplicity of the final answer, and seeing how long and dark that road of calculating the inverse, I think it’s best to let Wolfram finish up here. So here’s a semi-proof. They don’t so much simplify until they get the inverse, but show its equivalence to the result that we achieved which may be good enough for some: http://mathworld.wolfram.com/LeastSquaresFittingPolynomial.html

Okay hopefully all of that makes sense- the goal is to minimize the sum of residuals squared. The way to do that is to solve for a vector of coefficients such that the derivative of the square residuals are 0 representing a minimum error along the A, B, and C “directions.”

So the solution to our problem is a stone’s throw away:

For vectors and matrices 

the solution to a becomes:

So we fire up Octave and store our ln[R] values into a vector x and then create the 3 x n matrix X = [x.^0 x.^1 x.^3], then calculate a=(X’*X)^-1*X’*y.to get coefficients of the Steinhart-Hart model.

Next I did the same with a third-order polynomial that included the x^2 term, and then a final third-order that used straight T rather than 1/T.

Here are the results:

And here are the maximum percent errors and the absolute error, assuming that the error occurred at our points of interest at the higher temperatures:

There was that little jagged bump in the middle where it looks like I didn’t do a great job taking measurements, but I think the winner is clearly the third order polynomial with relation to plain ol’ T. Toward the upper end we even have a better fit and the great thing is the math designated it so!

Last Thoughts on the Model

PHEW!

Hopefully that was a good reminder of the power of math. If I were to do it again, I might try to get higher temperature measurements for calibration and to take it a little slower so that the data is more crisp.

Also, I might try to do some weighted least squares where we put more emphasis on decreasing the error on the upper temperatures and allow the curve to fit more loosely on lower temps.

Overall though, I’m pretty confident in the model we found!

The Sensor in Question

The sensor in question is the thermistor used in the J-head reprap hot end for the Mark IV. 

I’ve been working slowly on a 3D printer on the side made from one piece of plywood (and hand tools. Seriously, where is everyone getting their laser-cut parts these days??)

The sensor is the one that comes in the print-head. I’ve read about how the leads will short with the aluminum block so you end up having to do your own shrink tubing on the leads so I figured, if I’m going to have to take it out anyway I might as well calibrate it!

It’s a thermistor which means that, as temperature increases, the resistance changes as well. The change can be either positively or negatively proportional which they call a “Positive Temperature Coefficient (PTC)” or “Negative Temperature Coefficient (NTC)” thermistors. To be honest, I’ve only ever come across NTCs.

I retrieved the part number from the RepRap wiki, this is our thermistor (although, it’s not in the blob form-factor as the drawing would lead you to believe):

Keep this handy because we’ll need some of those numbers in later sections.

Intro to Calibration

Calibration is all about finding a mathematical function that will give us what we want from what we have. For example, we will get a changing resistance from this thing. How can we turn that into temperature?

First we need data! Grab two multimeters (one with a thermocouple) and follow along!

Take Measurements The first step is to gather data because we don’t know how the thermistor will respond to temperature changes. The datasheet does list datapoints but slight manufacturing errors make deviations so we can trust no one!

Get out two multimeters and set one up for temperature measurement and the other for resistance measurement.

On the temperature multimeter, connect the temperature probe. On the resistance multimeter, clip the probes to the thermistor.

Fill a pot with some water and stick it on the stove.

Put the temperature probe and thermistor into the water.

Get out your cellphone cam and start recording the faces of both multimeters and turn on the stove.

A neat packet of probes is a good idea. That way the temp probe is always close to the thermistor. Mine packet didn’t fit in the little hole in the lid of my pot so I abandoned this method

Get used to this image. I took about 20 min of footage and watched back in slow-mo to get all of the datapoints! Some day I will make “Recordo-bot” who will take datapoints for me...

I lovingly call this pot “The Calibrator”

You want to get are as many values between room temperature water up to boiling. We want to use F because, though all of our math will be in celcius or kelvins, there’s a little under 2 degrees F for every degree C so better resolution!

After that, repeat the same steps with just some canola oil. We do this because the water’s going to struggle as we get toward boiling. Meanwhile, the canola oil will raise temperature rapidly through the low temps and will allow us to measure up to our 400 degree F ceiling.

THE KEY HERE IS TO GO SLOWLY AND TO WORK SAFELY.

If you have solder joints, typical melting temperatures for solder are around about 361 F (says a quick google search) so just make sure they are far enough away from the solder that they aren’t affected.

Excel-ify those Measurements Okay, now go through the trouble of putting all of those resistances corresponding with each degree into excel and plot that sucker. Typically, over small ranges, we would use a first order equation to represent temperature changes but it’s clear that a line is a poor approximation. 

Data! The dark blue is our experimental measurement, the light blue is a not very good linear model

So what is a good approximation?

#include "msp430g2553.h" #define RED BIT0 #define GREEN BIT6 #define TXGP BIT2 #define RXGP BIT1 static const unsigned char gameToMux[]={ 9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9, //0-16 : nothing 0xAF,0X0F,0X0C,0XAC,0XAE,0XB8,0XB0, //17-23 : 7 6 5 4 3 2 1 9,9,9,9,9,9,9,9,9, //24-32 : nothing 0XCF,0X4F,0X4C,0XCC,0XCE,0XD8,0xD0, //33-39 : u y t r e w q 9,9,9,9,9,9,9,9,9, //40-48 : nothing 0XEF,0X6F,0X6C,0XEC,0XEE,0XF8,0XF0, //49-55 : j h g f d s a 9,9,9,9,9,9,9,9,9, //56-64 : nothing 0X2F,0X2C,0X8C,0X8E,0X98,0X90,0x09, //65-70 : n b v c x z 9,9,9,9,9,9,9,9,9, //71-80 : nothing 0X26,0x8F,0X8A,0X64,0X28,0x09,0x09, //81-85 : rgt m . spc lft 9,9,9,9,9,9,9,9,9, //86-97 : nothing 0x09,0X8D,0XE8,0XC2,0XA2,0XAA,0XAD, //98-103 : , ent p 0 9 8 9,9,9,9,9,9,9,9,9, //104-112 : nothing 0X45,0XEA,9,9,0XCA,0XCD,0XED //113-119 : bkspc l o i k }; static const unsigned char gameToMuxSquared[]={ 9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9, //0-16 : nothing 0xAF,0X0F,0X0C,0XAC,0XAE,0XB8,0XB0, //17-23 : 7 6 5 4 3 2 1 9,9,9,9,9,9,9,9,9, //24-32 : nothing 0xAF,0X0F,0X0C,0XAE,0X09,0XB8,0XB0, //33-39 : u y t r e w q 9,9,9,9,9,9,9,9,9, //40-48 : nothing 0X62,0X22,0X62,0X4D,0X42,0XF8,0X10, //49-55 : j h g f d s a 9,9,9,9,9,9,9,9,9, //56-64 : nothing 0X8D,0X82,0X02,0X8E,0X98,0X10,0x09, //65-70 : n b v c x z 9,9,9,9,9,9,9,9,9, //71-80 : nothing 0X26,0x8F,0X22,0X64,0X28,0x09,0x09, //81-85 : rgt m . spc lft 9,9,9,9,9,9,9,9,9, //86-97 : nothing 0x09,0XE2,0XE8,0XA2,0XA2,0XAA,0XAD, //98-103 : , ent p 0 9 8 9,9,9,9,9,9,9,9,9, //104-112 : nothing 0X45,0X4D,9,9,0XAA,0XAD,0X42 //113-119 : bkspc l o i k }; static const unsigned char gameToMuxCircled[]={ 9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9, //0-16 : nothing 0x09,0X09,0X09,0X09,0X09,0X09,0X09, //17-23 : 7 6 5 4 3 2 1 9,9,9,9,9,9,9,9,9, //24-32 : nothing 0xAF,0X0F,0X0C,0XAE,0X09,0XB8,0XB0, //33-39 : u y t r e w q 9,9,9,9,9,9,9,9,9, //40-48 : nothing 0X62,0X22,0X62,0X4D,0X42,0XF8,0X10, //49-55 : j h g f d s a 9,9,9,9,9,9,9,9,9, //56-64 : nothing 0X8D,0X82,0X02,0X8E,0X98,0X10,0x09, //65-70 : n b v c x z 9,9,9,9,9,9,9,9,9, //71-80 : nothing 0X26,0x8F,0X22,0X64,0X28,0x09,0x09, //81-85 : rgt m . spc lft 9,9,9,9,9,9,9,9,9, //86-97 : nothing 0x09,0XE2,0XE8,0XA2,0X09,0X09,0X09, //98-103 : , ent p 0 9 8 9,9,9,9,9,9,9,9,9, //104-112 : nothing 0X45,0X4D,9,9,0XAA,0XAD,0X42 //113-119 : bkspc l o i k }; void outputKey(unsigned char FK){ if(modifier } // 0X78 - '<' // 0x4D - ']' unsigned char txMsgBuffer[]={0x87,0x02,0x8c,0x1F,0xCC}; unsigned char msgCounter=0; unsigned char rxLength=0; unsigned char readingKey=0; unsigned char modifier=0; unsigned char firstKey=0; unsigned char secondKey=0; unsigned char prevMod=0; unsigned char prevFirst=0; unsigned char prevSecond=0; unsigned char tempRX=0; unsigned char modArmed=0; unsigned int wasHeld=0; unsigned char capsLock=0; int main(void){ //Stop the watchdog timer WDTCTL = WDTPW + WDTHOLD; //Set default timer DCOCTL = 0; BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; //Set output GPIOs to low P2SEL &= ~(BIT6 + BIT7); P2DIR = 0XFF; P2OUT = 0X00; //Set up UART mode for P1SEL |= TXGP + RXGP; P1SEL2 |= TXGP + RXGP; //Set output GPIOs on P1 to 0 P1DIR = RED + GREEN; P1OUT = BIT3; //Set up the clock and prescaler to baudrate of 19200 UCA0CTL1 |= UCSSEL_2; //UART ctrlled by SMCLK UCA0BR0 = 52; UCA0BR1 = 0; UCA0MCTL &= ~(UCBRS2 + UCBRS1 + UCBRS0); //Start UART UCA0CTL1 &= ~UCSWRST; //Enable UART interrupts UC0IE |= UCA0RXIE; //Establish timer CCTL0 = CCIE; TACTL = TASSEL_2 + ID_3 + MC_1; CCR0 = 62500; //Low Power Mode with global interrupts enabled. __bis_SR_register(GIE); //Send initialize message to chatpad msgCounter=0; UC0IE |= UCA0TXIE; while(UC0IE & UCA0TXIE){ P1OUT |= RED; } P1OUT &= ~RED; txMsgBuffer[3]=0x1B; txMsgBuffer[4]=0XD0; // __bis_SR_register(CPUOFF); while(1) { //if shift key is down... if(modifier==1){ //if shift wasn't already toggled... //if shift was already toggled before... if((P1OUT&RED)){ //turn on the "wasHeld" marker wasHeld=1; modArmed=0; P2OUT = gameToMux[firstKey]; } else if(~(P1OUT&RED)){ //turn on shift P1OUT |= RED; modArmed=1; P2OUT = gameToMux[firstKey]; } if(capsLock){ capsLock=0; P1OUT &= ~RED; __delay_cycles(10000); P1OUT |= GREEN; } } else if(modifier==5){ capsLock=1; P1OUT |= RED; } else if(modifier==2){ //if shift wasn't already toggled... //if shift was already toggled before... if((P1OUT&RED)){ //turn on the "wasHeld" marker wasHeld=2; modArmed=0; P2OUT = gameToMuxSquared[firstKey]; } else if(~(P1OUT&RED)){ //turn on shift P1OUT |= RED; modArmed=1; P2OUT = gameToMuxSquared[firstKey]; } } else if(modifier==0){ if(wasHeld && firstKey!=0){ //if just releasing from a held shift P1OUT &= ~RED; //turn off the shift wasHeld=0; //reset held to not held P2OUT = gameToMux[firstKey]; } else if(modArmed && firstKey!=0){ if(modArmed==1) P2OUT = gameToMux[firstKey]; else if(modArmed==2) P2OUT = gameToMuxSquared[firstKey]; __delay_cycles(10000); modArmed=0; P1OUT &= ~RED; } else P2OUT = gameToMux[firstKey]; } } } //on sending a byte #pragma vector=USCIAB0TX_VECTOR __interrupt void USCI0TX_ISR(void) { UCA0TXBUF = txMsgBuffer[msgCounter]; msgCounter++; if(msgCounter==5) UC0IE &= ~UCA0TXIE; } //A5 = 1010 0101 //41 = 0100 0001 //C3 = 1100 0011 //B4 = 1011 0100 //on receiving a byte #pragma vector=USCIAB0RX_VECTOR __interrupt void USCI0RX_ISR(void) { unsigned char temp=UCA0RXBUF; if(rxLength<=0){ switch(temp){ case 0xA5: rxLength=8; readingKey=0b10; break; case 0x41: rxLength=12; readingKey=0b10; break; case 0xC3: rxLength=4; readingKey=0b10; break; case 0xB4: rxLength=8; readingKey=0b11; break; default: readingKey=0; break; } } else if(rxLength>0 && (readingKey&0x01)){ if(rxLength==5) {modifier = temp;} else if (rxLength==4) {firstKey = temp;} else if (rxLength==3) {secondKey = temp;} else if (rxLength==1) { txMsgBuffer[0]=modifier; txMsgBuffer[1]=firstKey; txMsgBuffer[2]=secondKey; msgCounter=0; UC0IE |= UCA0TXIE; } } if(readingKey & 0b10) rxLength--; } //every ~0.5 seconds #pragma vector=TIMER0_A0_VECTOR __interrupt void Timer_A (void) { msgCounter=0; txMsgBuffer[0]=0x87; txMsgBuffer[1]=0x02; txMsgBuffer[2]=0x8C; UC0IE |= UCA0TXIE; }

We'll go through top to bottom:

Some (any) serial data stream goes into our microcontroller. We can control our system with any two-wire solution. I had only two GPIOs left on my micro, a simple MSP430G2211. 

We use some functions inside the micro to determine what the serial data means and that determines our 8-bit routing info.

The 8-bit data that comes out is really just for the sake of routing data from one portion of the keyboard PCB to the other and connecting them as if by a key press. The number of bits was determined in two ways: i) logically and ii) by what parts I had which were 4 x 4051's (8-to-1 analog multi/demultiplexer). I'll get to all of that in more depth in case it isn't clear.

The MUX's job is to choose one of 8 inputs to route to its single output line. The single output goes to the DMUX's single input and goes out to one of 18 outputs, simulating a key press.

The keyboard PCB thinks that there's a key-press and is jolly sending off info to the USB.

Of course I only know what I know from howstuffworks.com and taking a keyboard apart so, after scouring craigslist and ultimately buying from amazon, I had my keyboard! It's a V7 standard USB keyboard that you can find on amazon. In retrospect it wasn't the best choice (see improvements number 3), not because of the electronics, but solely because of the contacts which were unsolderable contacts that work by pressing the leads from the plastic sheets against it. I had to scratch these with a tiny precision screwdriver until the surface was rough and I go to a little bit of metal and soldered some equally sized wires to it.

This of course was not before mapping out all of the keys to each of the leads. First I used a sharpie to map out where each key was, then I dry erase traced the connections to each one. The result is the page below.

I know this is probably out there on the net somewhere but gotta keep the brain sharp!

So what I found was that I needed to connect one of 8 pins to one of 18 pins since the last two on the don't trace to the main blob IC on the PCB.

Next up, I had to figure out which MUX/DMUXs to use. I had a set of digital ones as well as the 4051's from an IC grab bag from electronic goldmine which I definitely recommend, but the digital ones didn't cut it for reasons that will later become clear. I measured the voltage on all of the pins with the keyboard PCB plugged in and they were all at about 5v which puzzled me and I would love to know the answer at some point. (edit: I put a bunch of the terminals to the ol' scope - turns out one of the sides has a slowish signal where it drives the line low. When two sides are connected, the signal is read by the other side to confirm a key-press. That way, a combination of key presses is a combination of signals!) In the meantime, the other part I had (very luckily) were four happy healthy 4051's. They are the perfect all purpose chip. They have inputs ABC to determine routing, function as both multiplexers and demultiplexers, and have 8 I/O's to 1 O/I which is a really good number. Checking the datasheet (here), it's got a great transient response with rise/fall speed at 3.75us/V. For our case, that basically means for a worst case scenario where we need to switch from 0 to 5v instantly, it would only take 18.75us!

Okay, so for the preliminaries, it will take a minimum of 4 x 4051. I determined that by treating this thing like a puzzle. Besides that, we will call each MUX by a number 1, 2, 3, and 4, and their control leads A1, B1, C1 for chip 1 for example and A2, B2, C2 for chip 2. The inputs/outputs we won't worry about too much and should be clear as we explain. Also, keep a tally of how many pins we are using on our micro because we want to be efficient!

We can configure them many ways but the most logical thing is to use MUX 1 for those first 8 pins. It makes no sense to do it any other way. That will take up 3 micro pins to control. Now we have 18 pins left for the other 3 MUXes.

It would be perfect if we had a similar chip that had one line to 32 because then we would only need 5 more bits but, since I didn't, we'll just be a little less efficient. Total, we have 3 x 8 = 24 output pins we can address on the three chips, but that would take 9 control pins: A2, B2, C2, A3, B3, C3, A4, B4, and C4.

So how could we use less pins? Let's look at two DMUXs, chip 2 and 3. We could connect their control lines together (A2-A3, B2-B3, and C2-C3) and then we would use three bits to address 1 of 8 outputs on chip2 and 1 of 8 outputs on chip3. Obviously we don't want to connect the input to both simultaneously so instead we use chip 4 to choose which of the two gets the input while the other is floating (which is fine since each pin is floating when you don't press a key). We need one bit to do that from Chip 4 (A4). But that means we only have 16 of the 18 outputs we need. So we expend one more control line, B4, to control four outputs - one for each of chips 2 and 3 and two more for additional output lines. We could splurge and use the third control line, C4, to get four more outputs, but we've reached the magical number of 18 already so no need!

Altogether, that's 3 bits for the MUX, and 5 bits for the DMUX controls for a total of 8 pins which, if we already had the hardware, would be the least we would need anyway!

I laid out my perf, soldered away, and tested it with an Arduino since it's fast and very controllable--all around great for prototyping. I just wired up to the IC socket where the MSP430 would go and wrote up a program to control everything.

There was only one big issue left: using modifier keys like the shift or alt or control since the re is only one link between keys. The big problem is that I built everything up thinking that it some DC current that triggered the key press when lo and behold, it was an AC signal (hence why the digital MUXes didn't work). Yarg! I'll tell you the treacherous way I took.

Really, it came down to needing more I/O. Eventually in this project, I would need an ADC for touch screening on the final project but, alas, the 2211 doesn't have an ADC onboard. I moved up to the much beefier 2553. It also has a UART module which I'll use later for getting input to this keyboard.

With an extra few I/O and a transistor circuit, I could keep a modifier key "held" in software while simultaneously pressing another key.

Results post to come soon.

Improvements

There are a few words of warning to the reader who wants to duplicate this.

You don't need to leave one pin disconnected! There are combinations along the line that don't have a function so you can just send that combination as an "off keyboard" command.

If you're working on Windows and (I think) Mac, there is an "accessibility" option within the operating system called "Sticky Keys" which holds a modifier key after you first press it, and then, after you push your first key after that, it will apply the modifier to that key. That way you can type "shift," then "k" in order rather than holding shift and you will still get a capital "K." If you have that available, the capacitors and calculations are totally unnecessary. There is just a threshold system level speed between key-presses to worry about that I've found to be around the 10's of ms (10ms won't work but 20ms will be okay). If you keep it at 20ms, you can't type faster than that so you won't have issues!

Well, we reasoned out, you want the widest range of course! Once you get the idea, it's all just a bunch of simple math.

For your geeky pleasure, here it is reproduced. First, we need data from the sensor. LDR's have high resistance in the dark and low resistance in the light so, first, we'll need to measure at it's lightest--when our bright LED light shines on it:

And at its darkest (i.e. when my finger covers it. Excuse the long exposure hand-jitters):

So our two values are 106.1kOhms in the dark and 2.349kOhms in the light.

Ideally, our equation should depend on those two values to come up with a new resistor value.

Let's do the math. Since we want the voltage to increase when it's light, we want to use the sensor as the upper resistor.

Then, we have two voltage equations:

for the upper voltage when it's light and

for the lower voltage when it's dark. We want the largest difference between the two so we find an equation for their difference:

and then take the derivative since we would like to find the maximum of this difference parameter:

.

From there, it's really just simplification; we give each fraction a common denominator and factor out the constant Vi, then use the quotient rule to find the derivative and set to 0:

After setting to 0, we know that he denominator is useless (unless it approaches infinity which would not be a real answer for us) so we throw it out and just solve for the numerator:

and then we simplify...

...and simplify...

...and finally...

Haha! Now things look better. Solving for R:

Let's check for our case.

The MyDaq has a power line at 5v so we'll assume we're using that to find our max and min voltage which should be pretty reasonably close to 5v and 0v:

Pretty good! And so once again, calculus saves the day! The next time you need a resistor divider for a resistive sensor (force sensitive resistor, thermistor, etc), just get the extreme resistance values and plug them in and you'll find the optimal second resistor!

By the way, I tried the same calculation with the upper and lower resistances swapped and the same answer arises so, if your want a "dark sensor," you can just switch the top and bottom resistors!