Close
0%
0%

Bluetooth Gamepad Phone Case

A bluetooth gamepad integrated into a phone case.

Similar projects worth following
A forward-compatible gamepad using 3d printed cases. This controller is inspired by the many smartphone gamepads and and game-focused phones that have come and gone. New phones come out, more powerful hardware arrives, and the old products are left underspecced or incompatible.

The current version uses an nrf51822 SoC for CPU and bluetooth.

Work in progress. There are several planned versions (if it makes it that far). v1 is for my personal use. v2 is community involvement and support for multiple phones. v3 extends functionality beyond just a gamepad.

WHY:

I want to play action/platformer games on my phone. The straw that broke the camel's back was "Prinny: Can I Really Be the Hero?" - I couldn't beat a boss because my fingers kept missing the intangible touchscreen controls. I want a gamepad that is compact to carry, comfortable to hold, and works with multiple phones.

HOW:

Current plan is an nrf51822 based gamepad in a 3d printed case. Users will be able to 3d print a case for their particular phone and drop in the electronics. When the user gets a new phone, a new case can be made and the electronics transferred.

INSPIRED BY (R.I.P.):

Xperia Play, OpenPandora., HTC Dream (G1), DS Lite, PSP

GAME PLAN:

The very broad stages will be:

  1. make a gamepad
  2. miniaturize it
  3. attach it to my phone

Breaking it down a little more, I'm expecting the stages to be something like:

  • phone case
  • electronics breadboarding
  • BLE firmware
  • electronics rough prototype (perfboard or similar)
  • standalone gamepad housing
  • PCB prototype
  • gamepad miniaturization
  • phone case gamepad prototype

ELECTRONIC DETAILS:

todo

CASE DETAILS:

todo

  • 1 × nrf51822 module

  • Still alive, new nrf module, USB-C version

    Maave05/17/2019 at 15:52 0 comments

    This project has been on hold for over a year so I could deal with life stuff. I'm getting back on track.

    It's time for a new module. I'm upgrading to the nrf52 series which should fix RAM usage, allow me to use an updated SoftDevice, and possibly use mbed OS 5.

    I bought a cheap Chinese nRF52832 module similar to my nrf51822 so that I can hand solder it. If the pinout is reasonably close I'll transplant it onto my existing perfboard prototype.

    Planning ahead for production, I found the Fanstel BM832 (nRF52832, 64KB RAM) and the reduced-cost BM832a (nRF52810, 24KB RAM). We'll see if I can keep the RAM under 24KB but it's not a priority. These modules are already FCC certified so I won't have to foot that bill if I ever sell these. The modules are BGA so I'd have to set up a reflow oven.

    In other news, I'm attempting a USB-C version! This idea has been on the backburner for a while but there's a flex PCB contest going on right now. Using a flex PCB will allow the controller to reshape for multiple phone sizes - a key feature of this project. The deadline is fast approaching so hopefully I can crank it out and win a prototype.

    I've made a new project page for the USB-C version. More updates to come so hit that Follow button.

  • Perfboard prototype with WT51822-S2

    Maave03/19/2018 at 21:06 0 comments

    Here's the current state of development. The test hardware mostly works! I've been using through-hole components on perfboard and connecting them to the WT51822-S2 with magnet wire. My soldering skills are low but it's getting the job done. Inspiration comes from NE555's beautiful perfboard work.

    Here's an early pic with no wiring.

    Current version's backside. The ground wire runs around the perimeter so that I can easily wire buttons to ground. Two buttons don't work - I probably didn't strip the enamel well enough for those wires - but all the rest works.

    Close up to the module:

    Ugly soldering but functional. The low temp enameled wire is pretty easy to work with (I had some high temp and gave that up very quickly). Flux and tin the contact. Strip and tin the end of the wire with a blob of solder. Solder the wire to the contact. Helping hands would make this easier to solder.

    I modeled this grip in Fusion 360 and 3d printed on our CEL Robox.

    Those pegs were meant to hold the perfboard. They broke off in a heartbeat. In their place I tapped some nails through the grip to hold the board. The grip itself isn't really comfortable but it's better than holding the perfboard. Good enough - I'll conserve my effort for other tasks.

    Here you can see the BlackMagic Probe reflashed STM32 that I'm using for development. SWD is used for programming and UART for serial output, both running simultaneously on the same device thanks to BMP firmware.

    The software sorta works. I'm using Gamepad Tester on Android to verify.

    Using mbed OS I managed to get it to work although there are some bugs and quirks. Fixing these are my main work right now

    RAM usage - Mbed + the SoftDevice (Nordic's BLE stack) runs dangerously close to 16k RAM. Newer versions of mbed will throw out-of-memory errors.  Build 131 has been working fine. Unfortunately mbed dropped support for SoftDevice S110 which uses 2k less RAM. According to some guide (which I lost, gotta re-find that) I should be able to allocate less RAM to the SoftDevice in the linker as long as I don't use the Central role.

    HID Report Descriptor - My HID Report Descriptor isn't working with multiple bytes. The BLE API gives me BLE_ERROR_INVALID_STATE when I try, even when using the working source from Ozan's nrf51822 controller. I have a vague idea what the issue is. Right now I'm using a single byte, with 1 bit per button. This is my main priority since I need to send the d-pad buttons separately from the regular buttons - either as a pair of X/Y axis or as a hat switch.

    Windows 10 quirks - Win10 has two issues. First is that the buttons aren't coming through to the gamepad configuration thing. Second is that sometimes the BLE will instantly disconnect after connecting. For now I'm simply ditching Windows as a target. It would be nice for testing but in the end this all intended for Android use. I have no idea what's causing either issue.

    That's all for now! More updates later when I have some solid software written.

  • core51822 breadboarding, part 2

    Maave02/05/2018 at 02:24 0 comments

    My core51822's headers have been annoying me for a while. I did get a cable to convert these 2mm pitch headers. Unfortunately (or maybe fortunately) I accidentally killed the board! Whoops. I'll keep this log short since the cable isn't relevant to the project anymore - full details are on my blog.

    It's a 44-pin laptop IDE cable. The original connector is 2x24. I sawed it half, mangling only a few of the rows and leaving me with a 2x10 and 2x11 connector. Just right for the core51822's 2x9 headers. The wire is stranded which doesn't play nicely with the breadboard - before using it I soldered a tiny bit of solid wire to the end. I should've bought the longer cable - mine is 2", I should've bought the 8".

    Anyway I killed that board so it's on to the next board:

    This one is a little harder to find info on but I believe it's a Wireless-Tag WT51822-S2 module. At the very least Wireless-Tag has the best documentation on the chip. I'll put this module on perfboard and try to get an actual functioning controller.

  • mbed OS for the nrf51822

    Maave02/05/2018 at 00:16 0 comments

    After way too much struggling I'm abandoning nrf5 SDK in favor of mbed OS. The Nordic tutorials are sorely lacking. The example code doesn't help since I don't have in-depth knowledge of BLE packet structure. Even if I persist and get it working, the barrier to entry will make it more difficult as a community project: harder to maintain, contribute to, or fork. Meanwhile mbed OS supports the nrf51822 and is MUCH easier. 

    I was tuned-in thanks to this project, which code-wise is doing exactly what I need.
    https://hackaday.io/project/27380-bluetooth-arcade-controller
    it's using mbed to simplify everything and a BLE_HID library

    Starting a project:

    -sign up for https://os.mbed.com/compiler
    -new project
    -when it asks for a board, follow the link, find "nrf51822" which is 16k (use the BLE checkbox in the filters on the left)
    -click, add
    -create a new test project. My template was BLE_Button, you can use whatever you want
    -hit Compile. It'll compile (rather quickly!) and provide a flashable .hex file
    -download the file, load and run it with gdb
    it works!

    Importing the BLE HID library
    -click Import
    -Libraries tab
    -search "BLE"
    -find "BLE_HID", double click to import into project

    bam done, start coding. Code samples for the BLE HID can be found on github:
    https://github.com/jpbrucker/BLE_HID 

    So far I've only used mbed's online IDE and compiler. It's not mind blowing but it's better than Notepad. There is a project gcc4mbed which I can try later with Eclipse, but right now my focus is on getting a prototype.

    There are a few versions of mbed OS availble right now. The 16k nrf51822 chips require mbed OS 2 (mbed classic) due to limited RAM. I don't think it will impact the project at all, it seems like the latest OS features are intended for networked/IoT applications. mbed classic has plenty of features and has already simplified my job.

    Ozan's arcade controller code is already working but I'm going to try rewriting it from scratch so that

    a) I learn C++,mbed, and the HID library

    b) I can license the code myself (instead of being a derivative of ARM Ltd's Apache-licensed code)

    The code is so straight-forward that I can't reasonably re-write it. I'll just make it a derivative work.

    Onward to victory!

  • core51822 breadboarding

    Maave12/21/2017 at 21:41 0 comments

    Unfortunately the core51822 modules use a 2.00mm (0.787") pitch rather than regular breadboard 0.1" (2.54mm). It's double row (2x9 pin) as well which makes DIY adapters more difficult.

    There are a couple solution.

    edit: after using it for a few days my 0.1" jumpers have failed. Scratch that method. I've instead swapped some headers with an inch of 24 AWG wire. More attempts to come later.

  • nrf5 SDK setup, compiling/running sample applications

    Maave12/21/2017 at 17:41 0 comments

    Here's how to get applications for the nrf compiling on Windows. Linux and Mac users will require some small changes the home directory (%USERPROFILE% to ~), serial port (COM8 to /dev/ttyACM0), etc. I'm still working on some of these settings - I'll add it to a Github Wiki later for updating and versioning.

    There are some quick start guides

    http://redbearlab.com/nrf51822-sdk/

    http://floe.butterbrot.org/matrix/hacking/nrf/

    And read Nordic's actual docs 

    http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf51/dita/nrf51/nrf51_series.html?cp=3

    The section "Application Notes > nAN36 - Creating Bluetooth Low Energy Applications Using nRF51822" is helpful for programming even though it's on an older SDK.

    Read the specs for which SoftDevice version you're using. Mine is S130 V2.0

    http://infocenter.nordicsemi.com/pdf/S130_SDS_v2.0.pdf


    Acquiring / unpacking everything

    Software we'll need:

    • nrf5 SDK v12   (I may change to v10 or v11 later)
    • nrf SoftDevice S130   (I may change to S110 later)
    • nrf5x Command Tools (contains mergehex.exe)
    • make v3.81
    • gcc-arm-none-eabi  v4.9

    All theNRF downloads:
    https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822#Downloads

    I'm calling my main directory "nrf" and placing it in my user directory. After unpacking everything it looks like this:


    /make-3.81/
    /gcc-arm-none-eabi-4_9-2015q3-20150921-win32/
    /s130_nrf51_2.0.1_API/
    /nRF5_SDK_12.3.0_d7731ad/
    /mergehex.exe
    /s130_nrf51_2.0.1_softdevice.hex


    my nrf makefile location:
    /nRF5_SDK_12.3.0_d7731ad/components/toolchain/gcc/Makefile.windows

    When I edited Makefile.windows I saw this line:

    GNU_VERSION := 4.9.3

    I assume that all makefiles are written for gcc 4.9.3 so I specifically got that version (4_9-2015q3).
    I only needed to change my GNU_INSTALL_ROOT variable. I might change this later to match Eclipse, once that is finally configured.

    GNU_INSTALL_ROOT := C:/Users/Maave/nrf/gcc-arm-none-eabi-4_9-2015q3-20150921-win32

    PROGFILES lines were not needed. I didn't need to make any changes to Makefile.common


    Configure makefile to match chip

    I went to compile the example programs and found more directories such as "pca10028" etc. There are different types of nRF5* chips and these extra directories are the particular dev boards. The latest SDK should work for this chip, it's just not configured by default. So we make some tweaks.

    Finding chip model

    My two modules have chips: 

    • nRF51822-QFAAh0 
    • nRF51822-QFAAh1

    to find your chip details, check the chip marking (source):

    Then compare it to Nordic docs:

    Packet variant and the first two digits in the build code can be read from markings on top of the nRF51 IC.

    aka only "h0" and "h1" are actually written on the IC. The last digit is not written.

    so now with the chart I know all my chip details

    packet variant: qfaa 

    build code: h00 and h10 

    package: QFN48 

    flash: 256kb 

    ram: 16kb

    These specs match the pca10001 development board. The latest SDKs don't have samples for the pca10001 but they do have samples for the similar pca10028 (nrf51422). I still don't know exactly which SDK or SoftDevice is ideal for this project.

    https://devzone.nordicsemi.com/question/90024/ic-rev-vs-compatibility-table-vs-sd-vs-sdk/

    QFAAH1 is a rev 3 chip. To save yourself a lot of headache I recommend that you use the rev 3 chip, and the latest SDK and SoftDevice. SDK 11 and SoftDevice S132.

    https://devzone.nordicsemi.com/question/51402/difference-between-pca10001-pca10028/...

    Read more »

  • STM32 Black Magic Probe flashing

    Maave12/07/2017 at 18:28 0 comments

    I'll be using Black Magic Probe to program/debug my "core51822" nrf51822 modules. Cheap STM32 boards can be flashed with the BMP firmware. (Note: Maple Mini board didn't work, stick to STM32F103C8T6 boards). HaD gave a brief summary about BMPs:

    https://hackaday.com/2016/12/02/black-magic-probe-the-best-arm-jtag-debugger/

    Quick cost comparison of dev options:

    -STM32F103C8T6 ($3) + FTDI serial adapter clone ($2) + core51822 or similar modules ($6) = $11

    -NRF51 DK ($34)

    -Segger J-Link EDU ($60 not incl shipping) + core51822 or similar modules ($6) = $66+

    The STM32 parts were sourced from China. It'll be $15-$20 if shipped from the US. I already had the serial adapter from the Arduino work so this was cheapest route bay far. Also I swear the NRF51 DK was $100 when I first checked and that's why I went the STM32/core51822 route. Now it's only $34. This is a very tempting option since it's officially supported and easier to set up. The DK has SWD pins so it can flash other modules as well.

    On to the Black Magic Probe flashing. All of the guides were for Linux so I used my VM, Thinking about it now I probably could have compiled using the Windows build of gcc. Oops, too late. If other people get into this I'll find/write a build script so that people can download the prebuilt firmware.

    The two guides I mostly followed:

    https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c
    https://gojimmypi.blogspot.com/2017/07/BluePill-STM32F103-to-BlackMagic-Probe.htm

    in terminal:

    mkdir mbp
    cd mbp
    wget https://raw.githubusercontent.com/jsnyder/stm32loader/master/stm32loader.py
    chmod 774 stm32loader.py
    sudo apt install python-pip
    pip install pyserial --assume-yes
    sudo apt install arm-none-eabi-gdb
     Wiring pic from the Medium guide. If you check STM32 board pinouts you'll see that A9 and A10 are TX and RX respectively.

    Wire up the boards according to the guide, plug in the FTDI USB, pass through the FTDI in VirtualBox to the VM. It connects as /dev/ttyUSB0 as shown in dmesg:

    dmesg | grep tty
    sudo ./stm32loader.py -p /dev/ttyUSB0

    Test build BMP firmware:

    sudo apt-get install gcc-arm-none-eabi --assume-yes
    sudo apt-get install dfu-util --assume-yes
    git clone https://github.com/blacksphere/blackmagic.git
    cd blackmagic
    make

     
    If that completes without errors then build the STM32 version

    cd src
    make clean && make PROBE_HOST=stlink
    

     
    That creates blackmagic_dfu.bin and blackmagic.bin. Now the firmware is built and can be flashed to the STM32. Either hit reset on the STM32 or unplug/replug. Then flash:

    sudo ./stm32loader.py -p /dev/ttyUSB0 -V -e -w -v ./blackmagic/src/blackmagic_dfu.bin

    Unplug it all. We don't need the USB to serial anymore. Reset the STM32's boot1 jumper to 0. Plug it through USB. The BMP updater firmware doesn't work with Win10 so I have to install the libusbK drivers using Zadig as mentioned here:
    https://docs.particle.io/faq/particle-tools/installing-dfu-util/core/#windows-32-bit

    Have the STM32 plugged in, start Zadig, select Black Magic (Upgrade) in the dropdown, use the arrows to select libusbK, install driver. VirtualBox still didn't pass through, and I'm being dumb and lazy, so I just used the dfu-util Windows build and transferred blackmagic.bin to Windows. Use dfu-util v0.9. Some other guide I had been following used v0.6 but that caused issue for me.

    http://dfu-util.sourceforge.net/releases/dfu-util-0.9-win64.zip

    Check the device ID with:

    dfu-util.exe -l

    which returned "Found DFU: [1d50:6017]" etc, I guess that's it. Time to flash:

    dfu-util.exe -d 1d50:6017 -s 0x08002000:leave -D blackmagic.bin

     Mine succeeded, the Black Magic device shows in Windows. If you get errors, check gojimmypi's account of fiddling with the memory.

    I gave it a quick test in gdb as well. I was able to start gdb and set the target.
    https://github.com/blacksphere/blackmagic/wiki/Useful-GDB-commands

  • Phone case modeling

    Maave12/04/2017 at 20:48 0 comments

    Phone case design time. I'll be 3d printing this, first in ABS, then in TPU, and eventually using it as a daily driver. I chose Fusion 360 this time to make it easier to edit the model. This is sooo much better than Sketchup, doesn't royally screw the model when I apply fillets, and it allows me to suppress feature later in development.

    Here's the best tutorial I found. The only thing he forgot to mention is the camera controls (middle mouse to pan, shift+middle to orbit).
    https://www.youtube.com/watch?v=A5bc9c3S12g&list=PL40d7srwyc_Ow4aaOGXlP2idPGwD7ruKg

    Here's a supplementary tutorial following the designer's natural workflow
    https://www.youtube.com/watch?v=E0bhdr84FNU

    Screenshot of the case:

    The "test" version with top lip removed so that I can print in hard ABS and a filament-saving space:

    This will be printed on a CEL Robox using ABS. If the test print goes well then I'll print in TPU. I group bought a printer with friends but it's currently down. I'm waiting for my friend to calibrate the bed after installing a new sticky print bed. We'll still have to mod the feed system to work with TPU.

  • Prior attempt

    Maave12/04/2017 at 14:39 0 comments

    I documented my prior attempt but the results weren't great. Here's the summary for historic purposes. This is my first real electronics project so I wanted it easy. I used an Arduino with an HC-05 Bluetooth module reflashed with RN-42 firmware, and Sketchup for the phone case modeling. The HC-05 worked but I don't think that reflashing the firmware is appropriate for a community project. Sketchup was entirely inadequate.

    I ordered parts, breadboard components, and soldering iron. I learned microcontroller basics on the Arduino - blinking LEDs, voltage dividers, button input, debouncing buttons, pull up / pull down, bitpacking. The Arduino was great for learning that. I re-learned soldering which I haven't done in years, and breadboarding. Pro tip, don't buy bottom of the barrel jumpers, half of mine are dead and it caused endless frustration.

    EEVblog how to solder:
    https://www.youtube.com/playlist?list=PL2862BF3631A5C1AA

    Concepts and mindset of soldering:
    https://www.youtube.com/watch?v=vIT4ra6Mo0s

    I had the parts ready when mitxela's guide appeared on HaD so my HC-05 attempt was based off this guide:
    https://mitxela.com/projects/bluetooth_hid_gamepad

    I got the controller to show as an HID gamepad in Windows. This is where I stopped with the Arduino/HC-05 and ordered nrf51822 gear. It can definitely work, I just don't think it's ideal.

    Here's the phone case I started for my Nexus 6P. My friends and I had already been using Sketchup for other projects however it turned out to be a poor choice for small models - I had issues with keeping faces flat and with Sketchup combining nearby lines.

    My new attempt is using the nrf51822 BLE SoC and Fusion 360. I got nrf51822 compiling and flashing working but no code of my own yet. I've made great progress with Fusion 360, parametric modeling rocks. More updates to come.

View all 9 project logs

Enjoy this project?

Share

Discussions

Michael Jensen wrote 12/07/2017 at 18:55 point

I saw that you were inspired by the OpenPandora. -- I'm interested in reusing the keyboard / gamepad from mine and integrating it into a phone case in a similar way to yours. -- If you make progress on the software side of things, I might end up using your code as a starting point.

  Are you sure? yes | no

Maave wrote 12/09/2017 at 04:29 point

Very cool, I hope my project helps.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates