Matrix Scanning

Note:  If you are seeing this note, then you are looking at an incomplete draft.  Keep checking back as I complete these series of blog posts over the next week or two.

Lately, I have had more of a need for custom input devices, like connecting an two 8-way joysticks and some buttons to my MAME cabinet or converting a really cool 1990s HOTAS controller setup from using a gameport to USB.  Soon, I will need to interface around 100 switches and buttons for my flight simulator cabinet in progress.  Why not use a commercial solution, or hack an existing joystick or keyboard?   It is far more expensive, less flexible and I wouldn’t learn anything in the process.

In any embedded project, one of the biggest constraints is the number of available IO pins.  Using one input pin per switch would be extremely wasteful. Let’s say we have 16 switches as shown:

There is a significant cost savings if we’re willing to trade off pin usage for a little extra latency and complexity in hardware and software.  The way this is done is by multiplexing the switches into a two dimensional matrix, scanning through columns and reading off the rows (or vise-versa.)

The matrix is scanned by pulling each column low in succession (with all others floating tri-stated) and reading the corresponding rows for that column.  If a switch on the selected column is open, its row input will read high due to the pullup resistor, otherwise it will read as a low.  Some microcontrollers have weak pullup resistors that can be enabled, obviating the external pullups shown.

Roughly speaking, the number of pins needed will be twice the square root of the number of switches.  For 16 switches, the number of IO pins needed is down from 16 to just 8 (four rows, four columns.)  That’s a decent improvement, but the advantage is more obvious for 101 key keyboard, which would only need 21 pins.  The main tradeoff is that it takes increasingly longer to scan through the matrix as the number of columns increases.

This approach works well as long as one switch is pressed at a time.  Pressing multiple switches at once can lead to ghosting and masking. <read more>

Here is a rough outline of what the matrix scanning code might look like in C.  The application would call initMatrix() at startup, and then periodically call scanMatrix() to scan the matrix.  Of course to read the status of a particular switch at (row, col), the application would call the function buttonPressed(row, col).

#define NUM_ROWS (n)
#define NUM_COLS (m)

uint8_t keyMatrix[NUM_ROWS][NUM_COLS];

uint8_t buttonPressed(uint8_t row, uint8_t col)
{
    return keyMatrix[row][col];
}

void deselectCols(void)
{
    // This has the effect of turning off the
    // previously selected column 
    TRIS_COL0_SELECT = 1;
    ...
    TRIS_COL(n)_SELECT = 1;
}

void selectCol(uint8_t col)
{
    deselectCols();
    
    // col latch should already be set to low,
    // so just enable the driver out of
    // tri-state mode so it can pull the column
    // down.
    switch (col)
    {
        case 0:
            TRIS_COL0_SELECT = 0;
            break;
        ...
           
        case n:
            TRIS_COL(n)_SELECT = 0;
            break;
    }
}

void readRows(uint8_t col)
{
    // Read Rows.  Switches will be active low,
    // so invert the reading.
    keyMatrix[0][col] = !ROW0_INPUT;
    keyMatrix[1][col] = !ROW1_INPUT;
    ...
    keyMatrix[m][col] = !ROW(m)_INPUT;

}

//call every millisecond or so.
void scanMatrix(void)
{
    for (uint8_t i =0; i < NUM_COLS; i++)
    {
        selectCol(i);

	// Give time for voltage levels to stabilize
        __delay_us(50);      
        readRows(i);
        deselectCols();
    }
}

void initMatrixIO(void)
{
    //configure col output pins
    
    //The latch needs to remain low for the rest
    // of the code to work.  This way they can
    // pull columns low when no longer in
    // tri-state.
    COL0_SELECT = 0;
	...
    COL(n)_SELECT = 0;
    deselectCols();

    (configure row input pins)
    (IE: tristate, enable pullups);
    
}

void initMatrix(void)
{
    initMatrixIO();
    
    for (uint8_t i = 0; i < NUM_ROWS; i++)
        for (uint8_t j = 0; j < NUM_COLS; j++)
            keyMatrix[i][j] = 0;
            
}

For a real world example using matrix scanning for a USB joystick, check this<link> out.

 

Suncom Tactical Flight Controller USB Conversion

Note:  If you are seeing this note, then you are looking at an incomplete draft.  Keep checking back as I complete these series of blog posts over the next week or two.

 

I am starting my own flight simulator cabinet build.  I want it to resemble the F15/16/18s I would see growing up on various Airforce bases and also be a good fit for some of the early 90s arcade flight simulators I played back in the day like Steel Talons.   I figured the best place to start would be the controls.  I went looking around for a nice HOTAS setup.  I really liked Thrustmaster’s Warthog, but I didn’t want to spend $500.  I turned to looking on eBay, finding an old school Suncom SFS Throttle/F-15 Tactical Flight Controller for $50- just in time for Christmas.  Christmas day, I ripped open my present and absolutely loved the look and feel of these controls!

They are amazing controllers, but go cheap because they require an obsolete gameport to connect.  I wanted so badly to try them out, so I hooked them up to a USB gameport adapter I had on hand.  Sadly, it didn’t work for any of the flight simulators I tried.  Even though the gameport adapter works, it appears the controls need special drivers to work.  I found the FUSBA from a cursory Google search on conversion kits, but it costs $100.

The case for a full on USB HID Joystick conversion was mounting- no need for an expensive USB converter or special drivers.  I ended up purchasing two $10  P-Star 25K50 Micro boards from Pololu and converted both controllers to USB myself.  The conversion wasn’t that difficult.  I converted the joystick to use a scanning matrix with some 1N4148 diodes, slightly modified the throttle’s scanning matrix and adapted Microchips USB HID Joystick demo.

I took apart the joystick grip to see what I am working with.

It appears to have some kind of encoding circuitry already, which I promptly desoldered, so I could replace it with a simpler 2 x 4 diode scanning matrix.  I modified the PCB so that I could put the hat switch on one row and the Guns, Missile, Thumb and Pinky switches on another.

Confused about matrix scanning and why there are diodes in the circuit? Check out my blog post on matrix scanning <read more tag here>.

Gameports typically used slope conversion, which measures the time it takes to charge and discharge a capacitor through an input resistance.  So the potentiometers are wired as variable resistors using two wires, which the successive approximation ADC on the P-Star can’t read directly.  To produce the voltage signal the ADC needs, I simply added a connection to the potentiometer that would let it be used as a voltage divider as shown:

If you can maneuver your soldering iron around the small space, I can tell you from experience it might be preferable to dismantling the joystick gimbal and spending the next hour trying to reassemble it.  Later, I will revisit the gimbal with some improvements that address the large amount of backlash present.

Another issue that surfaced was the fact that these potentiometers were 100K, way higher than the maximum 10K source impedance the PIC18F25K50’s ADC on the P-Star can accommodate.  This resulted in inaccurate readings during tests, until I upped the acquisition time (TACQ) to 64 TAD.  In this case TAD was set to 1.3 microseconds (FOSC/64 at 48Mhz.)  It might have been possible to add a small capacitor across the input terminals, but I wanted to keep the component count as low as possible.

Lastly, there’s a beautiful jumbo red LED right next to the hat switch.   Maybe I can have it flash during a missile warning or serve as some kind of master caution.  I wanted to make it accessible to flight simulators and MAME, so I wired it to the P-Star’s RB5 output for around 5 mA of drive current.  Of course I would have to incorporate an additional USB driver to tie into the simulator’s output subsystem, but at least the functionality is enabled for when the time comes.

You can find the software here, how it works <here> and how to modify it <here>.

Almost done with the joystick!  I finished up by organizing the wires, adding strain relief for the USB cable, soldering the headers and P-Star into a breadboard and mounting it as shown:

The throttle is considerably more complicated, probably to implement the keyboard interface and mapping.

I removed the circuit boards, disconnected the headers and reversed engineered the scan matrix.

I modified the matrix to have 3 rows and 8 columns by connecting the blue wire from the right throttle grip to the green wire on the left throttle grip.  Then, I connected the orange, brown, yellow and red lines on the left grip to the brown, purple, black and gray lines on the right grip respectively.

As with the joystick, I had to add a third wire to the potentiometers so that they can be read by the ADC.  I was able to avoid dismantling the throttle assembly by careful maneuvering during soldering.

The throttle’s potentiometers suffered from the same bad readings as those on the joystick and it was easily resolved by increasing the acquisition time to 64 TAD.  I’m not satisfied with the response curve from the linear pot arrangement, so I will be revisiting this soon and replacing them with rotary ones.

Finally, I organized the wires, added strain relief for the USB cable, soldered the headers and P-Star into a breadboard and mounted it as shown:

Of course, the software for the throttle was a pretty straightforward modification of the one I created for the joystick.  I had no problems getting these controls to work (even with Linux) on X-Plane, Warthunder and various MAME arcade games like Steel Talons, Wing war, F-15 Strike Eagle, Air Combat and Starblade.

Not only do I have a nice Joystick and Throttle, but a template for converting other controls, like a rudder or interfacing to things like landing gear, flaps, etc.  In the end, I spent around $75 on this project, so things are off to a good start.  Stay tuned for the rest of the flight simulator cabinet build, more to come soon!