Watch out our new #FunKey project - All your games on your keychain ! 

Before starting, you can find all the Solidworks source files from the project files or directly here.

This log is not about 3D printing Keymu's body (there will be dedicated build instructions) but about presenting the mechanical design and discussing the different main parts. The design is fully functional but there is a lot of room for improvement, as you'll see. In fact we are currenty working on improving this design thoroughly for the next iteration. 

Solidworks

Why Solidworks? I know Fusion360 is the big thing right now but I simply already had a bit of experience with Solidworks so I simply went with what I already knew. So without further ado, lets jump into the design.

PCB

First things first: before starting dressing it up, the PCB needs to be 3D modeled in the most accurate way possible. It is quite easy with Eagle to output an pretty decent 3D model of the board and components. Simply hit the "IDF to 3D" button in the board view and follow the instructions. 

Even better is to set and fill an attribute "HEIGTH" to your components in Eagle before exporting to 3D, that way even if the components are modeled by bouding boxes, they'll automatically have the right height.

The IDF file can be directly imported into CircuitWorks, and the bounding boxes simulating the components should be sufficient to develop the 3D case. However if you would like to makes things more real, most of the components 3D source files can be downloaded right from Digikey or from the constructors websites. Simply replace the bounding boxes by these models, this is what I did with the most important components: 

As you can see I left the bounding boxes for the battery, the speaker and all the passive components (making sure they were the right height though). 

Snap/fit

Keymu is designed to be put together without screws, it's all snap/fit parts:

I was a bit sceptic at first, thinking that there would be some wiggling or even fearing that the parts would break but with tolerances around 0.020mm I was very happy with the results. The bottom and middle part fit together really well, in fact they do not wiggle at all and I have tried throwing them against walls a couple of times, they do not break nor disassemble.

Hinge

The hinge was also designed so that its two parts - the screen casing and the main middle part - would slide in its socket on one side and snap fit together on the other:

This is NOT optimal for many reasons: for starters it is obviously fragile, it is also not very easy to 3D print, there is no controlling the force of the rotation, and most importantly, the OLED flex cable is folded in two everytime the screen opens or closes.

So why what it designed that way? Well, if you look at how our old clamshell phones work or even if you open up a good old GBA SP, you'll see that most of the "active hinges", that is to say hinges designed for passing electrical wires through them, are designed pretty much always the same way. The flex PCB of the screen enters inside the hinge part from one of the 3D case travels through this hinge part inside the hinge part from the other 3D case, and enters the other 3D case from there. Most of the time the flex cable inside the hinge parts is already rotated, so basically when you open or close the screen, nothing bends or folds, it just follows the already designed rotation. 

This is all good and well but this means flex cables are designed especially for our needs and most importantly with a width of around 4-5 mm max proportionnal to Keymu. The 1.5" OLED screen in Keymu is sadly not designed for active hinges and it is 28mm wide...while Keymu's width is 42 mm. This leaves around 7 mm around each side of the flex cable, hence the choice of this simple but effective design instead.

Main Buttons 

The main buttons are independant and rest directly above the panasonic tactile switches. Same thing with the arrows, appart this time this is a whole block supported not by the tactile switches but by its central spherical part.

When I started building Keymu people told me that it would be too small to play, and the buttons impossible to click without getting finger cramps. In fact I thought so too, but I figured it wouldn't matter if I couldn't play, Keymu would be cute as hell anyway. 

This is wrong.

After I built Keymu, I realised two things: that it was actually not that hard to play with and that the current design could actually be optimized tenfold, for an even better playing experience. Now that we are working on the improved version, I have to say that is totally possible to play on this thing, and - in a lazy way - quite enjoyable actually since the thumbs just push and practically do not have to move... it's not easy to explain so I guess when you'll finish building your own Keymu you won't have to just take my word for it.

But let's talk about everything that can be improved in the current version:

• The visible part of the buttons is too high (2mm), this should be reduced to at least half of that for two reasons: it would reduce the whole height of Keymu of 1mm, and having buttons too high leaves too much space for the thumb to "fall under", height that need to be "climbed" again when hitting another button. It's not practical.
• The total course of these microscopic tactile switches is close to nothing. When clicking on the buttons, one feels a little "click" and that's it, no real "buttony" feeling! It's just frustrating for two reasons: a console button shouldn't click, it should be soft, and the course should be felt.
• The tactile switches under the arrow should be closer from the center of each branch (not at the end like now)
• The arrow could be completely replaced by four independant arrow shaped buttons for a better feeling.

As you can see, there's a lot of room for improvements here and, in my opinion, it is Kevin Bates from Arduboy who found the best possible configuration with the snap domes instead of the tactiles switches or silicone keys.

LR Buttons

Finally let's talk about these LR buttons: 

I am not very proud of them, I have to admit it. They are plain ugly but they do the job and for a first prototype that's what counts.

Now the room for improvement here is... let's say that it's not a room but a big ass mall. It's basically inviting you to propose a better solution (quick suggestion: full bottom corners buttons would be amazing).

First and foremost, this is my first PCB so please be indulgent.

This being said:

• You can download the schematics in the project files or here.
• You can download the BOM in the project files or here.

I prefer writing a log about this instead of build instructions, since this is more of a discussion of the schematics/BOM than proper build instructions. Of course, any comments/critics are very welcome so that Keymu can benefit from everyone's knowledge.

Schematic

Keymu was built around five mains blocks visible on the schematics:

• page 1 : Power management, screen management, buttons, and audio
• page 2: The Edison itself

Power management:

This block was mainly inspired from Sparkfun's Battery block for the Edison. 

Basically there is a MCP73831 linear charge management IC which does all the job of charging the battery from the micro-usb port. There is also a power switch to turn on/off the supply of current to the rest of the system (while still allowing the battery to charge), a blue LED to indicate if the system is turned on and a green LED that lights up when the battery is fully charged.

The few changes from sparkfun's battery block are :

• RC circuit with high supported voltage connected between the micro-USB shield and the ground to handle electrostatic charges,
• Changed R7 resistor value to charge 220mAh batteries at 1C.

Screen block

This block is almost fully based on adafruit's 1.5'' OLED Breakout Board. The only difference here is the VDDIO input signal of the screen which is set to 1.8V (instead of 3.3V) which is the Edison's GPIO's working voltage. The screen is also powered by the 13V boost converted and communicate with the edison through SPI.

Audio Block

Even though the last version of Keymu does not output audio, it is not the hardware's fault but the developer's one (guilty). The hardware is all there, and now Keymu needs the corresponding Kernel drivers to drive it. There is no DAC on the Edison so the chosen solution was to drive the speaker through a transistor delivering 3.3V with a PWM signal. Even though the sound quality is not the greatest, this is a well known solution and costs way less space (and price) than driving an external DAC with I2S. There is a great article about PWM audio in Make magazine, and this is the solution used for the Edidoom project as well, where it can be seen that the sound quality is not that bad, especially keeping in mind that the final product is a keychain.

PushButtons

Not much to say about this part, this is pretty much simply a matter of connecting the switches to the edison's GPIO's on one side and ground on the other. This is possible since we use the internal pull-ups of the edison allowing to save space and an easier rooting.

Board layout

The full board layout can be seen on the following snapshot:

This is a bit of a mess to untangle so I will be discussing the top and bottom parts separately in the following paragraph. One thing to notice though is the yellow superposed drawings of the mechanical design for the casing and the buttons. 

Top side

For more clarity here is the top part of the PCB:

It can be divided into two main parts: the higher one and the lower one. The lower one is mainly dedicated to the pushbuttons. It is quite had to find some space for other components in this part because otherwise it could prevent the full course of the mechanical parts above the pushbuttons.

The higher part is dedicated to the microUSB on the left, the screen connector and dedicated components in the middle, and power management with battery connector on the right.

Bottom side

and here is the bottom side:

Here again it is divided in two: this time the lower part contains the Edison connector and all the components under the Edison: 13V DCDC boost convertor on the left, audio block on the right of the speaker and the on/off switch on the right. The top part is totally free of componnents on purpose: this is where the battery is located.

I know the writings on the board are pretty unreadable, my apologies in advance.

Printing the PCB

If you want to print this PCB, I sincerely recommend OSH park but there are many other options. This is free publicity for them since I was very happy with their service. I chose the 1.6mm depth for the PCB since it was a bit faster to arrive, but if you want to make Keymu easily slimmer, you can also choose the 0.8mm option. Here is what the PCB looks like:

It's almost time from some soldering now but before:

Ordering the components...

From what can be seen in the BOM I tried to get most of the components from the same place, which is to say in this case: Mouser. The reason for Mouser over Digikey is mostly because shipping costs are free after 50$, but most of the components are standard and can be ordered from basically any main reseller. 

The cost of components to build one Keymu is around 112$ (95€) counting the PCB from OSH Park, but not counting various shipping costs for components not available on Mouser and not counting also the 3D printed enclosure. 

I would say the final price (counting everything) is around 150$, but of course it's an approximation. If you start ordering the same component in large quantities for exemple, the price decreases a lot. One exception though is our dear Edison chip which is damn expensive regardless of your efforts. 

All things considered, prototyping Keymu is quite expensive, and that is why we are working hard on greatly reducing the price for the next iteration.

...and soldering it all together

Whoah, you're here. Great so it means you are ready to get your hands dirty.

I have to be frank this part is long, fastidious and requires some pretty high end material, but if you are here already, then listen to our old pal Nike and just do it (dammit).

First do not make the rookie mistake I made and hope you can soldier everything with your bare eyes and with a 50$ soldering iron from Amazon, just don't. Some of the components parts are very small like the pins of the edison connector, and some other are not only small but very sensible to heat like the pushbuttons. In ordier to soldier Keymu, a binocular is highly recommended, and you'll also need a high quality soldering iron. I used the professional material we have at work and it still took me around 2 hours to soldier both sides. If there is a hackerspace close to your place, I recommend going there and using their material for this kind of soldering. 

Another rookie mistake, for those who might not know or the clumsy like me: it goes without saying but diodes have only one working side, careful to soldier them in the right direction.

What else to say? Good luck, just put some of your favorite music in your ears and it's actually quite a good head clearing time.

Since the last project log ended with "This is it for this first log, the next one will be, I think, about describing more in details the advancement of the project and giving the roadmap", one was not wrong to expect more logs or build instructions to be posted soon after.

But since then nothing...how in the hell did this happen ?

Was this all a lie ?

Of course not, and this log is dedicated to give updates and explanation about what happened these last months, because - in fact - many things happened.

Let's start from the beginning, Keymu was originally a side project to learn electronics/embedded systems. As it is explained in the project introduction, I fell in love with Sprite_TM's micro Gameboy and realized I could learn a lot by making one myself. And learn I did: making my first PCB, modifying and recompiling the linux kernel, building a dedicated debian distribution, 3D modelisation and 3D printing... all this was new to me. A few months later and with the support one genius of a colleague, Keymu was born and I started this entry on Hackaday. 

I figured participating in the Hackaday Prize 2017 would give Keymu some visibility and - oh my god - it did, way beyond what I had expected. 

When things get out of hand - in the good way

Just after Hackaday's article on the Intel Edison being discontinuited, a Danish journalist contacted me about Keymu basically to write about how Intel's announcement affects people and existing projects. He asked me if I had a small video showing Keymu in action so this is when I shot the very unpolished youtube video you can see in the introduction. 

This article was not really about Keymu though, in fact, it was entitled "One of the victims of Intel's IoT retreat" - not very glorious... However, a few weeks later, Hackaday wrote its own article about the project, like it does for many projects in the Hackaday challenge 2017. This article led to another in BoingBoing, which led to another on Gizmodo, which led to many others. 

We (my genius colleague - now partner - and I) even were invited on an live show by a Youtube channel in France called Geekinc where they interviewed us about Keymu (interview in French): 

All these articles were a very nice unexpected surprise, and led to many views on this page, as well as many views on the youtube video (which is now monetized, allowing me to recover a little bit of the various costs of making the prototype). 

But most importantly, all these views and comments led me to realize that many people were interested in Keymu and wanted one (some unanswered comments on Youtube even proposed that I simply named my price to buy some). 

So, where do we go from there? Well, let's product some Keymus !

Production baby

Yes that's right, Keymu is now on the road to becoming a real product but the road is still very long. One does not simply jump the huge gap between homemade prototype and production-ready device, but even before that many issues need to be solved with the current prototype:

• Keeping the Edison is not an option now, this means rethinking the whole harware,
• Developing a new linux distribution, very lightweight and optimized this time,
• Rethinking the whole mechanical design, most specifically the hinge...
• Adding working audio,
• and many other things...

This is without counting all the new difficulties added by entering production, certifications, legal issues, starting the crowdfunding campain... So I officially parnered up with my genius colleage and we have both been working hard on the new product for the last months or so, and continuing to do so... hence the lack of activity on this page for a long time.

Excuses, always excuses

Juggling between daily work, Keymu new objectives, and - well - life, meant little time to post long and detailled tutorials to build Keymu like I initially planned but a promise is a promise and I will be releasing (with less details) the Edison Image, Eagle files, BOM, and Solidworks files very soon. For the tutorials on how to build the Edison image, it will also come but a bit later. So stay tuned, and again thanks for all the Keymu love!

At the time when these lines are written, the project prototype has been fully validated except for the sound. Granted, design-wise the prototype is much closer to a bomb than to a keychain, but believe me, after all the work it involved, it has never been so rewarding to play some good old fashion SuperMario Kart (GBA).

However there is some catching up to do before getting into the fonctional prototype.

This first log describes the main components of this project:

• Let us start by the most important component: the processing unit. After looking online for the best fitted computer module (nice comparison of modules at the end of this page), I believe the most suitable solution can be found in the Intel Edison module. For around 50$, you have a module of 35.5 x 25 x 3.9mm with a beefy dual core 500Mhz processor (based on an x86 architecture), 1GB of RAM, 4GB of flash storage on board, bluetooth, wifi, a power management unit, and many interfaces: usb, sd card interface, SPI, 2 I2C, 2 UART, I2S, and 12 GPIOs.
  Agreed, it is expensive but it is either this or building its own processing unit (which I simply do not know how to do), or opt for a way bigger solution. I sincerely hope Intel will decrease the price of their module, especially since it is out for some time now.

• The second main component of Keymu would be its screen. For this part I realized very quickly that, as for the processing unit, there were not many possible solution available. The size constraint makes it only suitable for screens up to 1.5" to 1.6" maximum to be considered. The Edison does not have display interfaces such as MIPI or MCU, so the only way to command and send data to the screen was with SPI. With difficulty, it is possible to enable DMA on the Edison (I'll get into this later), allowing to communicate in SPI up to 25Mbit/s. Using RGB 565 (2Bytes per pixel), at 25fps, the maximum squared resolution reachable with SPI is then given by sqrt(25000000/(2*8*25)), that is to say 250x250. Other requirements were the display depth and the minimum size of the flex connector (it had to be long enough to turn around the hinge). After searching everywhere I could think of, I could not find a screen meeting all the criterions. The closest I found was an SSD1351 OLED screen but a concession had to be made on the resolution since it is only 128x128. There is a very good point to this screen tough: it is very easy to prototype with since Adafruit sells its very own breakout board.

• The rest of the components are represented in the block diagram above. They were relatively easy to find once the final design was decided so I will not spend too much time on it. The only thing I would stress out is that "easy to find" is never given when building a product so small. Everything need to be thought of in advance, and my advice is to have a VERY good idea of your final design before getting the components and vice-versa when building the design. Yes it is a vicious circle but it is the way of small, optimized packages such as Keymu: the mechanical design and the choice of components are interconnected and need to evolve at the same time.

This is it for this first log, the next one will be, I think, about describing more in details the advancement of the project and giving the roadmap.