Skip to content

Meeting Notes (2020 08 18)

Alex McLain edited this page Aug 20, 2020 · 5 revisions

Meeting Notes

  • KiCad / PCB layout
    • Trying to lay out a naive 8x9 matrix on the PCB doesn't work well because the keys aren't physically arranged the way the matrix is wired.
    • The physical matrix is more like 16x5. Electrically 8x10 if you split the rows down the center and duplicate the columns.
    • We probably aren't going to be happy with an off-the-shelf key scan IC because they don't meet all of our specs (scan rate, max keys detected simultaneously, too small - difficult to prototype with).
    • We probably want to roll our own key scan solution. The BeagleBone Black PRUs look feasible. An FPGA is an alternative.
      • If we do this, we can drive/sense the rows/columns however we want.
    • It doesn't matter where the rows and columns physically connect, as long as they're electrically connected.
    • We need to overlay 2 matrices: The keyboard matrix + the LED matrix.
    • LED matrix
      • We would need to use two of the IS31FL3733 matrix drivers.
      • Rather than using the second IC to drive the leftover LEDs after maxing out the first IC, each IC could drive half of the LEDs.
        • This may also let us reuse a lot of the existing matrix if we add more keys/LEDs.
      • We could put the ICs on the back of the keyboard for the finished product.
    • Processor
      • May need to use a pin header or flat flex cable that allows us to put the system processor on a separate board to avoid interfering with the keys.
      • Or make a space at the top of the keyboard for the controller.
    • Multiple schematic pages? Use hierarchical sheets.
  • LEDs
    • The RGB LEDs can consume 20-30mA of current.
      • This would be about 4 amps for all of the LEDs at full brightness.
      • This would exceed the USB 2.0 current limit.
      • We could put an artificial limit on the brightness to reduce current consumption. To the user it's 0-100% brightness, but we set in hardware what the max brightness value we send to the LED matrix drivers.
    • The Keybow uses APA102 LEDs.
      • They're probably too small to hand-solder (hand-reflow).
      • They work by chaining them together and shifting serial data through the chain. Not great for prototyping because we have to populate them in the order they're wired together if we only want to test a few of them on the board to start out.
    • Wurth 150352M173300 LEDs should be compatible with the ISSI driver IC.
    • We could provide other keys on the board for num lock, caps lock, scroll lock. They don't have to be RGB.
      • We don't currently support reading these values from the O/S.
    • Each matrix driver is 12x16. We probably need to swap the rows/columns so we get 15 lines down the 5 rows of keys (R+G+B * 5 = 15) and 8 lines across the columns of keys.
      • This configuration also leaves some spare columns left over for expanding the key count (i.e. F-keys) without redesigning the entire matrix.
    • Cree LEDs - They were too tall for the MX keys.
    • Common annode/cathode RGB LEDs
      • It may be possible to use them, but it may reduce our flexibility when prototyping.
      • We could rewire or rotate the independently wired LEDs.
  • MX switches
    • Not all switches have an LED cutout.
    • Some keys have plastic lenses for the reverse-mount LEDs.
    • We're intending to design for switches that work with surface mount LEDs.
    • Compatibility with through-hole LEDs?
      • Don't think they would work with hot-swap switches.
  • Dev board controller
    • Designed the controller (Raspberry Pi, BeagleBone Black) to be mounted to the dev board with standoffs, not electrically connected.
    • Headers from the matrices are exposed on the dev board, which can be jumpered to the controller.
    • This allows flexibility for prototyping, since we may not be satisfied with the initial wiring. We can also connect other devices to the board this way, or bypass the ISSI LED drivers and drive the LEDs with something else.
  • Cockatrice - FPGA project that lets you program FPGAs in Elixir.
  • Octavo OSD3358
    • The AM335 processor plus a lot of the supporting components, all in one package.
    • It comes on the BeagleBone Black Wireless for prototyping.
    • Or the OSD3358-SM-RED .
    • Seems like it's compatible with the BeagleBone nerves system, but not 100% sure.
  • PCB repo
    • We'll use separate repos for hardware and software.

Action Items

  • Merge the bottom of Chris' PCB layout with the top of Alex's.

Resources