Bluetooth Gamepad Phone Case

Project Logs

Collapse

Still alive, new nrf module, USB-C version
Maave • 05/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
Maave • 03/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
Maave • 02/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
Maave • 02/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
Maave • 12/21/2017 at 21:41 • 1 comment
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.
- buy an Waveshare BLE400 breakout board ($9)
- soldering wires to the headers / replacing the headers ($0)
- modding a pre-existing adapter ($?)
- make an adapter on perfboard (sub $2)
- get a PCB made like this or this
- 44-pin (laptop) ATA cable ($1 from China, $6 from US after shipping)
- 2x10 pin 2mm pitch IDC cable ($4)
- 2x20 pin 2mm pitch headers only (10pk $4) and make your own cable
- buy 2.00mm to 0.1" jumper cables ($5-7)
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
Maave • 12/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
Maave • 12/07/2017 at 18:28 • 1 comment
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
Maave • 12/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
Maave • 12/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.