For anyone with a Raspberry Pi3, this topic may or may not be useful. If like me you own a Raspberry Pi2, you may be facing the challenge of using Bluetooth with your Pi and wondering how on earth you get things started. Depending on how Linux savvy you are, this can be either a walk in the park or a utter nightmare that will leave your pulling your hair out and crying in a corner.
Now thanks to a good friend introducing me to Linux, I’ve been enjoying various distros for well over seven years, my favorite being Xubuntu. But that isn’t to say that I’m by any means a Guru. There are times Linux honestly leaves me baffled, but I felt pretty confident that setting up a keyboard on the RPi would be a walk in the park. After all, the latest addition, the PI3 comes with Bluetooth built in, so you’d think it worked pretty much out the box. When I bought an ultra slim bluetooth keyboard from Pimoroni, I was a little shocked to spend the next two days fighting with it. No matter what I tried the Bluetooth software in x.org refused to work with the keyboard. Thankfully the Raspberry Pi forum came to the rescue and after an hour searching for a solution, I finally had my answer.
If like me you’ve been reading guides telling you to use bluez-simple-agent to set up your keyboard, then you know that such a command no longer works on Raspbian Jessie, Bluez has been updated since those guides were written. Fortunately however Archlinux has a great Wiki page dedicated to using Bluetooth in Linux and how to get things working using the new command “Bluetoothctl“. From what I can tell the process isn’t that dissimilar to “bluez-simple-agent“.
Now I’m going to assume you’ve already installed Bluez on your machine. If you haven’t, then I suggest you get cracking.
– At the command prompt, type “bluetoothctl” and press enter.
– By default your controller is turned off, to switch it on enter “Power on“.
– Next, lets have a look at what your Pi can see, enter the command “Devices“. The computer will list any visible bluetooth devices, along with their MAC address. If you see the device your wanting to use, make a note of the MAC address now, as you’ll need it later.
– If your device wasn’t listed, try putting your pi in discovery mode with the “Scan on” command. Hopefully this will add any device that weren’t already discovered.
– Now turn agent on by typing the command “Agent on“. If successful your Pi should report: “agent registered“.
– Time to try connecting to your device using the address you jotted down earlier. Enter the command “Pair MAC address“. The PI should now attempt to pair to your device, so make sure you entered the address correctly, otherwise it will fail.
– If you’re using a device without a pin, you can manually instruct the PI to trust the device. This is sometimes necessary when your pi needs to reconnect to it. You can do this by entering the following command “Trust MAC xx.xx.xx“. Note after MAC, you should enter the address you have written down.
– Now lets finally establish a connection using the command “Connect MAC xx.xx.xx.xx“.
Hopefully your PI connected successfully to your keyboard, so why not try typing something? Did anything appear on your screen? If it didn’t, try retracing your steps. If you used the “Trust” command, you will have to use the command ‘Remove xx.xx.xx.xx’ to make your Pi forget the device. Once removed, try going through the tutorial again, making sure you didn’t miss any steps.
If typing on the keyboard resulted in letters appearing on the screen, congratulations! You successfully connected your keyboard to your Raspberry Pi. If you reboot your computer now, it will forget everything you have done so far and your Pi and keyboard will no longer be connected. To make sure this doesn’t happen and your keyboard remains connected, we’ll need to create a udev rule. This is our way of telling the Pi to look for our bluetooth device each time it boots up and if present, reconnect to it.
First quit bluetoothctl by typing ‘Quit’ and pressing the enter key, you should now be returned to Terminal. For the next step, begin by typing “nano /etc/udev/rules.d/10-local.rules“. Nano should load up a blank document, which we will use to fill with the following.
# Set bluetooth power up ACTION==”add”, KERNEL==”hci0″, RUN+=”/usr/bin/hciconfig hci0 up”
To save, press “CTRL+O” followed by the ‘ENTER’ key. Next press “CTRL+X” to exit Nano, your computer will now remember to reconnect to your device the next time you reboot.
The above guide is an adaptation of information found @ “wiki.archlinux.org/index.php/bluetooth#bluetoothctrl”
Readers of my blog will probably have seen the Amiga 600PI I built not so long ago, using a Raspberry PI 2 under the hood. Out of all the projects, I honestly have to say this was a labour of love and a lot fun project to build. But like any build, there are the obligatory tweaks that must be made to fix things that might have been missed the first time around. Issues that only became obvious after using a build for a week or two. Which is pretty much how it was for me with the AmigaPi.
After using the AmigaPI for a couple of weeks, I began noticing one or two problems. First on the list, wasn’t so much a hardware problem as software. UAE4ARM is the de facto Amiga emulator for the Raspberry pi, in shorts it’s pretty amazing. But as fantastic as it is, there is yet to be any support for remapping the keyboard. This is useful if you like playing games using the cursor keys or say your old skool and prefer using the good old Spectrum controls Z,X,O,P. At the time of writing, this still isn’t an option, which means its still isn’t possible to make use of the built in joystick ports on my KeyRah V2 interface. Sadly it seems no matter how much people plead for the feature to be implemented, those bringing UAE4Arm to the Pi are focusing on performance over functionality. Which is understandable, as any good emulator requires a decent level of real time performance. Afterall nobody wants to play Amiga games at a snails pace with choppy sound. But in the pursuit for good performance, other features have been neglected. Making UAE4Arm a good attempt, but still vastly lacking when compared to FS-UAE or Win-UAE. Both of which offer a far more advanced level of configuration, we can only hope that UAE4Arm will one day follow suit. Given the number of people using their Raspberry Pi for gaming, it would be a missed opportunity if it didn’t.
In the meantime the only way to play games on UAE4Arm is using a controller, usually this means hooking up an Xbox 360 joypad. I know a lot of people use these on their RetroArch gaming setups as they’re easy to get hold of. Chances are if you own a 360, you already have one laying about the house. However for me, seeing one hooked up to an Amiga 600 seemed as out of place as a Chippendale in a nunnery.
My AmigaPi needed a proper looking joystick, not some Microsoft rubbish. Now there are a couple of ways this can be achieved. Firstly, you can purchase the ready made USB Competition Pro by Speedlink. It looks just like the original, except for the USB connector on the end of the lead. I did seriously consider getting one of those, however digging a little deeper, I discovered more then a few people complaining about lack luster performance. While opinions on the internet are ten a penny, usually where there’s smoke, there’s fire. And at £20 a pop, I didn’t fancy finding out which opinion was right. Especially when I was pretty confident that I could build my own joystick for a fraction of the price.
Buiding A Joystick
The first thing I had to find was a bust Amiga Joystick, I certainly wasn’t about to break a working one just for a hack. At least taking something that is broken and giving it a new life, you’re recycling and not just throwing it in landfill. Luckily in my loft I had a non-working Cheetah 128, which had been
a spare for my Spectrum, until it died.
Taking it apart, I was surprised with the simplicity of the internal workings. Unlike some of my quickshot sticks, the Cheetah use simple metal pads to create open and shut gates. Press forward on the joystick and two metal pads would connect to make a circuit. Luckily for me, this would actually worked in my favour, as it would make converting the stick to USB pretty simple. The only problem now was finding the right sort of USB controller. Scouring the net, I found one company that sold a custom analogue to USB adapters, however they wanted £16! I thought this was a little pricey for a single sided, through hole PCB with only chip. It was after all, doing essentially what all the cheap Chinese controllers were doing – translating the inputs from a series of switches / buttons into something the computer could understand as UP, DOWN, LEFT, RIGHT and FIRE.
Ebay is full of USB controllers styled after SNES, NES and 360 joypads, which you can pick up for as little as a few quid. I was pretty sure one of these would contain everything I needed to convert the Cheetah to USB. So biting the bullet, I bought myself one and waited for it to arrive in the post.
A Note on Retro Game Pad Copies
After arriving at my doorstep, the first thing I noticed was the quality or lack of it Looks were pretty much the only thing the USB pad shared with the original super Nintendo controller. Unlike the latter, the build quality was cheap and flimsy and not at all solid as you’d expect. A quick game of Super Frog on the Amiga Pi quickly revealed how bad it really was, with the D pad often mashing two directions together. Resulting in a lot of unintentional left and right jumps that left me crying for it to end. After ten frustrating minutes I’d had enough and unplugged it. After seeing how rubbish it performed, I felt less guilty about scavenging it’s innards for my joystick mod.
Fitting A Square Block In A Round Hole
Inside the controller, I was faced with a major problem. The joy pad wasn’t constructed anything close to how I’d been expecting. Spanning the full width of the pad was a single PCB, populated with contact-less switches. I’d foolishly been expecting the pad to use mechanical switches, which I could have easily rewired. However a friend later explained to me that a lot of things these days are built using single a PCB to cut down the cost on components. In light of this revelation, I faced having to solder to the surface of the board. While not my preferred way of doing things, I’d just have to like it or lump it. If that wasn’t bad enough, the darn PCB turned out to be 2cm wider then the base of the Cheetah. I’d have to work some serious magic with my Dremmel if it was ever going to fit in the base.
One of the hazards with chopping up a PCB, is that they don’t usually work afterwards, not without a bit of rewiring. Such as reconnected broken ground planes etc, which are needed for the circuit board to function. Lucky for me the design was pretty simple, but I was still thrown a couple of times, chasing the ground. Having never attempted anything like this before, it was a learning process for me, figuring out how the board worked and where best to solder to. This was especially true, as I began cutting portions away to make it fit inside the base. After removing almost all the direction pads and three of the fire buttons, the PCB was finally narrow enough to fit inside the Cheetah, hurray!
If you fancy trying your hand at hacking your own joystick, my advice is to take your time, don’t rush and make a photographic record of your progress. Pictures can come in really handy if a wire pops out and your left wondering where the heck it came from!
To reduce the number of wires I had floating around inside the joystick, I shared the ground from one point on the PCB to all the other contacts. Interestingly, unlike other joysticks of the day, the Cheetah uses a cloverleaf for the main directional stick (pictured left). The only other joystick I know that shares this design, is the original Sinclair sticks that came with the grey Plus 2. This design actually made wiring everything up a lot easier, as its much simpler than those with internal switches. Beneath the star shaped metal plate are four contact screws, which represent UP, DOWN, LEFT, RIGHT. Using wire I’d stripped from an old IDE cable, I hooked the contacts up to those on controller’s D-pad. This is when having photo’s comes it really handy, as more then once I lost my way with the traces on the board. But consulting some photos, I figured out what I was doing wrong and soon had UP going to UP, LEFT going to LEFT and so on.
In theory, when connect to a USB port, the board would register the movement of the stick just as it had the original D-pad. While I recycled a lot of the Cheetah’s original wiring, I also used a lot of wire from an old IDE cable. Not only is it very flexible, but its also very low gauge, which makes it perfect for soldering to the tiny traces on the joypads PCB.
After the wiring, came the next challenge: hooking the joystick up to a USB port and hoping it worked. I’d already had the pad albeit in original form, connected to my Windows PC. It worked straight out the box with a minimal amount of setting up. Hooking it back up, I was pleased to find everything worked first time! After a game of Stunt Car (obviously!) on WinUAE, I began wondering about the buttons in the base of the Cheetah and whether or not they could be made to work. True the wiring inside was more jammed than a sumo wrestler in a phone box. But I wasn’t satisfied, I wanted those darn buttons to work. After all, the natural way of holding the Cheetah was with both hands. The whole time I’d been playing Stunt Car, I kept feeling the urge to use the lower buttons instead of the trigger.
Achieving this feat took some hacking, I can tell you. First I had to find room for the micro switches. There was barely any for them to sit between the PCB and the lid, the only option was to cut out a cavity in the buttons for the switches to sit inside.
As you can see pictured, this was finally how the buttons looked, with the switches recessed inside the red plastic housing. It took several failed attempts on my part, before I found the right depth for the switches. But eventually I was firing nitros in Stunt Car without a hitch. I think the scariest moment was when I screwed everything together. With the top and base finally secured, I was worried everything would squashed together. Luckily, I didn’t need to worry, as it worked fine.
And here is a final image, which I think pretty much captures my feeling at the end of this hack.