Hello, Welcome to the field! Mixing code and hardware is tons of fun. (Also, sometimes complicated and difficult.) The "no activity" problem you're running into may be a blocking I2C call. Do you actually have an MPU-6050 connected, or are you running with just the Teensy right now? The code tries to do some initialization steps during the boot process, and the Arduino "Wire" library used for I2C communication has some blocking function calls in it such that it can totally freeze if the expected signals aren't seen on the wire. There is no timeout. If you don't have a motion sensor, make sure you go into the "config.h" source file and change the motion configuration so that it doesn't try to use it. You'll know that the boot process succeeded if you see the Teensy's orange LED flash briefly every couple of seconds. If there's no blinking LED, then it didn't finish the boot process. As for debugging, if you have KB+Mouse+Joystick USB selected, then Serial.print() calls won't go anywhere. You need a USB configuration with Serial in it in order for that to work. Serial is also used for the KGAPI host communication protocol, so if you have serial enabled, you should see data come from that port from time to time, e.g. touch events. It's binary data, not human-readable ASCII, to use a terminal application that can display hex (like Realterm). Or, you can use the Python stub console script. That's primarily what I use for rapid testing, since it speaks KGAPI easily without manually assembling or parsing binary packets. For 3.3V vs. 5V, I did that because all of the sensors and the Bluetooth module that I chose use 3.3V natively, so that avoids the need for additional regulators. It also makes it easier to reliably power the device with a standard single-cell LiPo battery. Concerning Teensy configuration, there is a comment block in the "support_board_teensypp2_t19.cpp" file that shows the function of all pins. The sensors are all inputs most of the time; touches are detected by very briefly setting one pin to output mode and then reading the input logic state of all other pins to which it might be connected. This is typical of a scanning keyboard matrix, though the implementation is a little more straightforward and relies less on reusing multiple pins for more than one key. See this Keyglove blog post for some further discussion.