Project Logs

Collapse

• New Project: FunKey

  Squonk42 • 04/22/2019 at 21:35 • 0 comments

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

• Design Decisions: The Buttons​

  Squonk42 • 05/15/2018 at 21:46 • 8 comments

  U/D/L/R and A/B/X/Y button pads and START/SELECT buttons

  One of our most difficult constraint for the #Keymu - open source keychain-sized gaming console is the overall thickness of the device: since it is a clam-shell design where the lid contains the LCD screen, this removes a few mm to the total thickness that must stay < ~15 mm. If you remove from this figure 2x enclosure wall thickness of at least 1 mm, the PCB thickness of 1.2 mm and components height of ~1.5 mm (because of the micro USB connector, mainly) and the battery, this does not leave much room for these button pads.

  Thus, we started to search for the thinnest button we could get: standard tactile switches are too thick, and the first idea is to reduce the button shaft length, eventually remove it altogether. Performing a search on Digi-Key for tactile switches sorted by actuator height off PCB leads to these 0.35 mm height, 4.10 mm square button:

  We thought we had the ultimately thinnest button on Earth, until we discovered the Arduboy tactile dome buttons:

  (Check the #Printable buttons for tactile domes project for more details).

  The secret is using these tiny metallic pieces that are curved (0.3 mm height for these example ones) and act as springs:

  We found these RK22170 models at Snaptron, which were very kind to provide us a free sample kit and a hundred of these (easy to lose) thingies.

  The only PCB footprint you need are 2 bare copper arcs with a central copper circle (no solder mask on all of these!), the dome will make an electric contact between these when pressed. You also need a small ex-centered vent hole to help the air below the button to escape on the bottom side of the PCB, that's all!

  In order to keep them in place, you need to stick the domes on a piece of rubber tape, and it is actually not that easy: the required accuracy is rather tight, as the upper plastic button must press right in the middle of the dome, or the button stroke is extremely shorten.

  Although we did the PCB with these footprints, we are not sure yet if we will keep these or not, or go back to our previous SMT ones because of this strict alignment problem: SMT assembly seems much easier to perform than glue these jumping domes on a piece of rubber tape.

  Rear LEFT/RIGHT and RESET Buttons

  For these buttons, we needed the smallest right-angle SMT buttons possible, and we found these B3U-3000P(M)-B models from Omron (3 mm x 2.5 mm x 1.2 mm, without shaft) :

  We choose the model with a boss and made a footprint with a hole in the PCB in order to have a mechanical pin that would make this SMT button resist large forces that could tear it off the PCB.

  For the RESET button, it is mounted recessed on the PCB and will require a small paper clip to be inserted in a hole on the enclosure to activate it.

  As for the rear LEFT and RIGHT buttons, we designed a 3D printed piece with a flexible axis between the 2 large external plastic buttons that presses on the actual button shaft with some very nice elasticity. We were a little bit skeptical about this solution when we designed it, but it proves to be quite nice, the haptic characteristics are very good!

  ON/OFF Slider

  We wanted to have a real ON/OFF slider, but as usual, we needed it to be as small as possible!

  However, as this is a power switch, it had to withstand the maximum current that the device could draw, ~200 mA.

  We found this small PCM12SMTR slider switch that can handle 300 mA which is only 6.7 mm x 2.6 mm x 1.4 mm, without the knob:

  ESD Protections

  As discussed in our previous log, it is very important to protect all user-accessible buttons and keys from ESD by adding a TVS diode as close as possible to the button pins, with a short path to a good ground plane in order to shunt the ESD energy to ground as much as possible, thus protected all subsequent devices connected to the button.

  For this purpose, we used some tiny 0402 bidirectional...

  Read more »

• Design Decisions: The Screen

  Squonk42 • 05/13/2018 at 17:46 • 0 comments

  Apart from the core itself, the next important decision is the the choice for the LCD screen.

  Dimensions

  As stated earlier when we discussed about the core, the whole point for the FunKey Zero project was to prototype as much features as possible for the #Keymu - open source keychain-sized gaming console device.

  We determined that the maximum dimensions should not exceed ~ 40 mm x 40 mm x 15 mm, or we should not call it a keychain emulator anymore ;-)

  For the Keymu, we considered that the screen should be as large as possible and adopted a "clam shell" form factor to protect the fragile screen and buttons from impacts on the keychain.

  But these decisions seriously restrict the available screen size: if you consider that the screen can fill the whole 40 mm x 40 mm surface, the maximum possible standard screen size that works is then 1.5" or 38.1 mm in diagonal, or 26.94 mm square.

  Screen Interface

  First of all, the picture to be displayed must be buffered ("frame buffer") on one side, either on the CPU side, or in the screen module itself, which leads to 2 different screen module types:

  • in the first case, the screen module does not contain any RAM and is just a "dumb" display that needs to be constantly refreshed in order to display a picture, using pixel clock, horizontal and vertical sync signals, and of course, the pixel data, usually in an RGB666 (18 data bits from D0 to D17) or RGB888 (24 data bits from D0 to D23), plus a few additional signals. These screens are mostly used to display "live video" coming from a camera sensor like in Handycams or dashboard cams
  • in the second case, the screen module contains a memory, often called Graphic RAM (GRAM) that does not need constant refreshing in order to display a picture. This type of screen is generally used for static displays like UI with buttons, check boxes and sliders

  In the case of "dumb" screen module, the screen interface is generally called "RGB", with a variant "RGB8" where each color component is transferred one after the other (each pixel needs 3 transfers).

  For the screen module featuring internal GRAM on the other hand, there are several standard interfaces used to drive them:

  1. for the smallest screens, an I2C bus is used. As these screen do not contain many pixels, the I2C bus with its maximum speed of 400 Kb/s is more than enough to drive these, and it only requires 4 wires: VCC, GND, SDA (Serial DAta) and SCL (Serial CLock). At 25 fps and 65536 colors, the maximum resolution you can expect is thus... 32 x 32 pixels!
  2. for screens with more pixels, the I2C bus just is too slow to allow high fps numbers, and an SPI bus is used instead, which requires a few additional wires, usually: VCC, GND, SDI (Serial Data In or MOSI), SCLK (Serial CLocK), CS (Chip Select), RS (Register Select), RESET and most of the time a separate power supply for the LED backlight. Speed is often specified up to 8 or 10 MHz, and at 25 fps and 65536 colors, the maximum expected resolution is 128 x 128 pixels. But it is not uncommon to have integrated screen controllers going up to 40 or 50 MHz and in this case, the resolution can go up to 240 x 240 pixels with the same picture parameters!
  3. in order to reduce the required interface speed, some screen modules use parallel buses with 8, 9 , 15, 16 or 18 bit bus, dubbed "MCU", "MPU", "Intel", "8080" or "6800"
  4. for the screens with the highest resolutions (including the ones used in smartphones and tablets), the interface used is a high speed differential serial, user-unfriendly interface called MIPI DSI (Display Serial Interface) requiring a specific controller, only available in high-end mobile phone CPUs

  Clearly in our case, solution #1 is not possible, as well as solution #4, as we don't have the corresponding DSI interface in our CPU. This leaves us with solution #2 or #3 or a dumb...

  Read more »

• EMC: EMI, RFI, ESD

  Squonk42 • 05/12/2018 at 08:50 • 0 comments

  No, these acronyms are not new state-sponsored 3-letter agencies, but they are sometimes considered as dreadful!
  

  ElectroMagnetic Compatibility: ElectroMagnetic Interference, Radio-Freqency Interference and ElectroStatic Discharge, this is what these mean.

  This subject is seldom covered during hobby electronic discussions, because it is not essential (things will "work" without them), it is difficult to understand and in this regard is like some kind of "black magic", and even if you already know it, this subject is just boresome;-)

  So why bother?

  Actually, our own experience shows us that EMC is really the difference between a working prototype on the bench and a reliable product in the wild!

  Another serious motivation is that any device must be certified for compliance against EMC standards in order to be transported, sold, distributed or even used outside a lab.

  This is why we decided to take EMC into consideration right from the start for our FunKey Zero project, as the goal is to prototype as many features as possible for the #Keymu - open source keychain-sized gaming console that we would really like to turn into a usable end-user product.

  EMC

  ElectroMagnetic Compatibility (EMC) is both a device characteristic and a branch of electrical engineering that deals with unintentional generation, propagation and reception of electromagnetic energy which may cause unwanted effects. The corresponding issues are emission (whether deliberate or accidental), coupling and susceptibility (or its opposite immunity).

  Please note that from an EMC compliance test point of view, this means that a device is potentially both a source and a victim of interference.

  EMI

  On the other hand, ElectroMagnetic Interference (EMI) is the disturbance generated by an external source that affects an electrical circuit, i.e. it is the phenomenon itself, not the characteristic or the study of it.

  As the equivalent electrical element between 2 coupled devices is a complex impedance that can be a resistor (R), a capacitor (C) or an inductor (L), or any combination thereof, the coupling can be linearly detailed as conduction, electrostatic coupling or electromagnetic induction, respectively.

  Continuous Interference

  A Continuous Wave (CW) interference arises where the source continuously emits in a given range of frequencies. This type of interference is divided into sub-categories according to the considered frequency range.
  

  For lower frequencies (typically less than a wavelength), conduction coupling is predominant and may affect 2 conductors in phase (such as a disturbance that hits both conductors at the same time) or out of phase. In the first case, this phenomenon is called common-mode coupling, whereas the second is called differential-mode coupling. This distinction is important, as the first class of common-mode coupling may be more easily handled to greatly attenuate the disturbance when the 2 conductors carry opposite signals ("differential signals"), whereas the second class of differential-mode coupling is much more difficult to deal with. In this last case, only frequency filtering is effective.

  RFI

  For higher frequencies and when the source and victim are separated by a large distance (typically more than a wavelength), both devices act as radio antennas: the source emits or radiates an electromagnetic...

  Read more »

• Design Decisions: The Core

  Squonk42 • 05/09/2018 at 11:56 • 3 comments

  Form Factor

  The main goal for the FunKey Zero project is to prototype the maximum number of features for our final #Keymu - open source keychain-sized gaming console  machine. The keychain form factor is the most limiting parameter: roughly, we determined that 4 cm x 4 cm x 1.5 cm were the maximum allowed dimensions to stay practical, which leaves just enough room to fit a 1.5" screen, not much larger. This rules out event the small Raspberry Pi Compute module (67.6 mm x 30 mm) or Zero (65 mm x 30 mm) as the core processor board for the project.

  Screen Resolution

  With a lot of tricks, it is possible to stuff some emulators with a 128 x 128 pixel resolution on an ESP32, for example, like the small PocketSprite.

  But based on our Edison Keymu experience, we determined that a 128 x 128 pixel resolution was barely acceptable to play some games with small fonts, so we tried to get a screen with a higher resolution, still fitting the 1.5" size.

  If you search well, you can find on AliBaba some screen in this form factor with a resolution of 320 x 320 pixels but unfortunately, to handle the large amount of data to display, they use a high speed differential serial, user-unfriendly interface called MIPI DSI (Display Serial Interface) requiring a specific controller, only available in high-end mobile phone CPUs :-(.

  We were lucky to find a nifty 240 x 240 pixel 1.5" screen with a simple SPI interface that is just perfect, which is now available at Adafruit.

  RAM

  However, a 240 x 240 pixel  in 24-bit RGB color image takes a little bit more than 168 KB of RAM memory to store in a frame buffer, which is out of reach for most Micro-Controller Units (MCUs), except for the largest one.

  Instead, we turned to bigger Central Processing Units (CPUs) with enough RAM memory, and if possible able to run a Linux OS in order to benefit from the existing software base, including already running game emulators.

  But this extra RAM comes at a price: to reach these capacities, you need to use Dynamic RAM (DRAM) instead of the Static RAM (SRAM) used in MCUs. These are generally provided as external chips, with high-speed bus connections, requiring extra-careful PCB layout and trace routing, not counting for the required real estate on the board.

  CPU with Integrated DRAM Memory

  Considering the Raspberry Pi, for most models, this DRAM complexity problem was solved using a clever technique called Package on Package (PoP), which consists in soldering the DRAM package on top of the CPU itself.

  Unfortunately, only a few chips outside the unreachable Broadcom CPUs used in the Raspberry Pi are using the same technique :-(

  We found Next Thing Co.'s GR8 chip which combines a 1GHz Allwinner R8 ARMv7 Cortex-A8 processor with NEON SIMD extensions and a Mali-400 GPU. 256MB of DDR3 SDRAM in a single 14 mm x 14 mm x 0.8 mm package. Hopefully, we only found it too late, as Next Thing Co. is now dead, RIP.

  Another option is the Octavo OSD335x-SM module which combines a 1GHz TI Sitara ARM Cortex-A8 AM335x processor and up to 1GB DDR3 memory into a slightly larger 21 mm x 21 mm x 3.08 mm package. This chip is used in the PocketBeagle. Sure, it contains almost all the required components, but it is about 1/4 of our total PCB area... More worrisome, this chip (like the GR8) is based on an older design ARM Cortex-A8, which has been superseded by the smaller, simpler and more power-efficient ARM Cortex-A7 in 2013. Be careful, the ARM version numbering is very confusing!

  We then discovered the Allwinner V3s chip wich combines a 1.2GHz ARM Cortex-A7 with NEON SIMD and VFPv4 extensions and 64MB DDR2 memory into a user-friendly 16 mm x 16 mm x 1.6 mm (including pins) LQFP128 package. No more worries regarding the power consumption, but now some concern...

  Read more »

• Licenses & repositories

  Squonk42 • 04/23/2018 at 08:40 • 0 comments

  The software released for the FunKey Zero project is licensed under the Gnu General Public License, version 2 or (at your option) any later option.

  This includes the material provided in our buildroot-licheepi-zero Github repository.

  The electronic hardware and mechanical design are released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
  

• Current state of things

  c.Invent • 04/22/2018 at 14:50 • 2 comments

  Hi everyone, many logs/files/links have been published in the last couple of days ! We’re very excited to be sharing all of this with you but we know it’s a lot of information, so if you are a bit lost and wondering the exact state of advancement of Funkey Zero this log is for you.
  

  Mechanical design and printing

  The mechanical design is done and tested. If you remember that Keymu was made with Solidworks, this time, we redesigned everything from stratch using Fusion 360. You can find the source files in the project links or here.

  We printed and tested the tolerances of our design using a Prusa i3 MK2 with a 0.1mm precision and a classic nozzle width of 0.4mm. Appart form the buttons which are still a bit too large, your prints should all fit together pretty easily. One precision though: we printed the top part in 2 halves, as well as the bottom part. See this log for more precisions. It is up to you to follow this method or not obviously but, believe us, it leads to pretty nice results.

  Electronics and Assembly

  Right now we have soldiered the essential parts : power management, screen, audio and debug pins. We have cut a hole in the bottom half of the case on order to let debug serial cables get in as you can see in this picture :

  The PCB/Case assembly went great:  for now there are no problems of tolerances, but we still have not put the snap domes and tested the buttons, so we’ll keep you updated.

  Regarding what’s been soldiered we had some minor issues for the screen and had to add a few cables, the power management part and the audio Jack work perfectly but not the speaker for now. It might be the soldiering itself or something else, we’ll have to dig a bit deeper but it should not be a serious issue.

  The BOM and schematics have been shared with you obviously, so if you want to join us in this debugging fun we’ll be more than happy to welcome you 😊

  Software side 

  On the sofware side of things, things are going pretty smoothly for now but we still have a lot of work.

  Boot time and Logo

  As you might know from our log "Linux Distribution", we developed our own linux distribution from the ground up for Funkey Zero and we are very proud to say that the boot time in under 3 seconds. It’s so fast we made a video for you to be able to believe us :

  As you can see we also added a boot logo, which is – for now – very simple and prone to evolve. But it’s still nice to be welcome by something else than a serial console.

  Usb mass storage

  Part of our new distribution is the possibility to connect Funkey Zero to any computer and it will be mounted as a USB mass storage device… basically a usb key. There is no easier way to transfer your roms than this :

  Optimized Emulators :

  Guys, having a 240x240 screen resolution is great. On Keymu the resolution was 128x128 and was acceptable but not very comfortable to play games such as Zelda or Pokemon in which you need to read a lot. This time, with Funkey Zero, the resolution is very comfortable, so even if our processor only has 64MB of RAM and a single core 1.2Ghz processor, we wanted to be able to make the most of it.

  Thanks to optimized emulators for ARM made mostly by notaz for the Pandora, we were able to re-adapt and re-build many emulators for our ARM v7 processor and our 240x240 resolution. We realized that once optimized, the V3S processor was actually a surprising powerhorse ! It even runs PS1 games at only 70% CPU load. And guys, oh what a pleasure to hear and see Final Fantasy IX running on this thing !!! Words are not enough, just watch :

  For the future, we plan to port many more emulators and the work is in fact already underway so stay tuned 😉

  TODO

  So… if in the video above you didnt see me playing it’s for a reason : the buttons and the whole button mapping interface is still under development....

  Read more »

• Linux Distribution

  Squonk42 • 04/21/2018 at 20:29 • 3 comments

  Distro Choices

  The AllWinner V3s and by extension the LicheePi Zero are designed to run Linux kernel-based operating systems, which includes both a distribution called "CamDroid" (a lightweight operating system based on Android) with a good support for MIPI cameras and H.264 video codecs, or more conventional Linux-based distributions, with a choice between an EmDebian or buildroot-based distribution.

  Camdroid

  We definitely discarded the CamDroid distro, as it requires the non-public AllWinner SDK to build which is  encumbered with closed-source blobs, as we don't need its specificities here. Moreover, support seems very difficult, as all that can be found is mainly in Chinese.

  Regarding plain Linux distros, there are some pre-built EmDebian and buildroot-based images with several build options (Xorg, gcc, Python, LXDE, minimal) available for download at https://licheepizero.us/.

  EmDebian

  Despite its attractive Debian-flavored facilities (well-known structure, number of available pre-built binary packages), we also discarded the EmDebian distro because:

  • This distro is dead: "As of July 2014, updates to the Emdebian distributions ceased. There will be no further updates and no further stable releases."
  • Even if it is tagged as "embedded", the resulting size is rather large for such a small amount of RAM
  • boot time is > 10 s

  Buildroot

  Thus, we turned to buildroot to provide our distro. "Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation.". And this is really true:

  • its core infrastructure is just a few hundred lines of make code
  • it uses make code and kconfig for the configuration interface and language. Both technologies should be familiar to all embedded Linux developers
  • compiling the whole distro is fast and don't take hours, even when re-building the cross-toolchain from scratch
  • it is designed for small to medium sized embedded systems

  On the down side, there is no runtime package management system (dpkg, rpm) and complete rebuilds are often required...

  Linux Distro Dissection

  Actually, an embedded Linux distribution is not a single piece of firmware: a first consideration are the required tools that are running on the host or build system, as opposed to the software running on the target machine.

  Host

  In the case of buildroot, you have the core system which is made up of a few hundred lines of make code and kconfig scripts to run a simple menuconfig-like configuration interface. There are also a few required utilities that are built from their source tarball packages. But the piece of meat is the cross-toolchain that includes all the tools required to build executable software that will run on the target machine. With buildroot, you have the choice either to use a pre-built toolchain or build your own from scratch. Guess what we chose ;-)

  Target

  On the target side, each independent piece of software is called a package, and is made up of a small, mostly declarative makefile, some patches and the source tarball package that is fetch from the original package maintainer location. These packages are cross-compiled using tha above toolchain and put into a set of firmware images that are burned into the target machine.

  Even on the target machine, there are several distinct pieces of software that must be considered, described here in their boot order:

  Boot ROM (BROM)

  This one cannot be modified, as it is a read-only software that is first run upon boot-time. It is in charge of bringing up the minimum resources to startup the CPU. It also reads some GPIO inputs with either pull-up or pull-down resistors known as bootstrap configuration to select some operating options such as clock frequency, boot device, etc.

  Secondary Program...

  Read more »

• Component Selection

  Squonk42 • 04/21/2018 at 10:02 • 3 comments

  Like described in the project details, we decided to use the LicheePi Zero module as the core of our FunKey Zero device. As explained, this module features an AllWinner V3s SoC, which has just the right capacity for our purpose, and a minimum size because of its integrated DDR2 RAM:

  With a size of 44.65 mm x 25.53 mm x 8.00 mm, it is small enough for the FunKey Zero, but not for our final keymu device. It features a low power consumption and all the required peripheral that we need.

  Another very important part in our design is our small 1.5" LCD screen. It has an amazing 240 x 240 pixel resolution, while using a simple SPI-based interface and not a complex DSi interface based on the differential high-speed MIPI specification, which requires a dedicated controller that is only available in higher-end SoC:

  For audio playback, we wanted to have an internal speaker. But given the reduced dimensions, we tried to find the smallest available one, which has a very small 10 mm diameter, with a total height of 2.9 mm, out of which 1.4 mm can be inserted into a PCB hole, thus only having a height above PCB of 1.5 mm:

  We use a simple mono audio playback through a MAX97000DETB+ amplifier. This amp has all the required characteristics, but uses a non user-friendly DFN10 package, so we designed a special footprint with long pads to make it easier to solder.

  We also provided an external audio headphone connection using a standard TRRS 3.5 mm audio jack. We chose a mid-mount model, i.e. one which requires a cutout in the PCB. This way, we can "mask" its height into the PCB thickness, leaving only a 1.5 mm height below and above the 1.2 mm thick PCB:

  To keep the design as thin as possible, we found the best solution was not to use standard tactile switches, but to use tactile domes instead: with dimenions of 5.59mm x 4.19mm and a height of only 0.3mm, they only requires a copper area on the PCB and costs nothing:

  We also need some right-angled tactile switches for the rear left and right button, as well as for the recessed RESET button:

  We took the smallest we could get, but we may experiment with softer (no-click) ones for the rear buttons to bring a better play experience.

  We needed an ultra-small slide switch for the on/off function, here is the one we found, only 7.7mm x 3.5mm x 1.4mm, not counting the knob itself:

  We had to add a separate microUSB connector instead of using the LicheePi Zero built-in one, as we need to get access to its +5V pin in order to feed a LiPo battery charger circuit. We choose a common model with through-hole pins in order to avoid tearing it off the board if you don't pull the chord straight. 

  The LiPo battery charger chip is a standard MCP73812T-420I/OT, followed by an ideal diode made up of a P-MOSFET and a Schottky diode, like originally used in the OLIMEXINO-32U4 board. The ideal diode will allow charging the LiPo battery while the USB is connected by disconnecting the battery from the load, and reconnect it to the load when the USB chord is not connected. Clever, isn't it?

  The only remaining mechanical part is the small DF37NB-24DS-0.4V(51) connector, matching the LCD screen connector. It is a very fragile part that does not withstand too much heat from the soldering iron, so we designed a special footprint with as long as possible pads in order to solder it using the capillarity effect as much as possible.

  For debug, we features a 7-pin right-angle 2.54mm pitch header, compatible with standard FTDI cables while bringing some extra signals on non-essential pins and adding on extra pin.

  The only remaining active part is an N-MOSFET used to drive the screen backlight from a V3s GPIO pin.

  We made provision for TVS diodes on all user-accessible parts to prevent ESD, these are small 0402 TVS that can be optionally mounted, and a dedicated USB ESD protection a close as possible to the USB connector.

  All other parts are passive resistors, capacitors or ferrite beads in 0603 form factor, as we have a lot...

  Read more »

• 3D-printed parts with no flat face

  Squonk42 • 04/21/2018 at 09:11 • 2 comments

  3D printing is a great technology, allowing people to prototype 3D parts at a minimum cost.

  But like all technologies, 3D printing with a Fused deposition modeling (FDM) has its own limitations, different from other techniques to produce 3D parts, like plastic injection using a mold.

  One major drawback is that all parts must have a flat surface lying on the 3D printer bed, and overhangs cannot be too steep or bridges too long. This seriously limits what shapes you can obtain. Also support material is not always ideal, or easy to remove especially in such small and detailed prints. 

  In particular, it is not easy to get fancy enclosures for electronic devices like we need for the FunKey Zero project: as you can see, the casing has no flat surface, it has many fillets and holes outside, and ribs, bulkheads and standoffs inside. Of course, the enclosure needs to be split into 2 parts (top & bottom) in order to put the PCB inside, but still, each half of the case is still pretty complex on both of its sides.

  Moreover, we would like to get 3D-printing parts that are as close as possible to the equivalent achievable plastic-injected parts, in order to validate them before making an expensive mold.

  We used one technique that we did not see anywhere else for such a purpose: further cut each half of the enclosure shell top & bottom part into 2 sub-parts featuring a flat joint plane and glue them together. You can find similar techniques to 3D-print a horse body for example, but it looks like nobody had the idea to apply this to complex enclosures. We may try to get a patent from this idea ;-)

  Seriously, here is an example print for the FunKey Zero PCB assembly which is everything but flat:

  And here is how it is actually 3D-printed:

  You can then assemble the 2 halves using Loctite glue to obtain the final complex part while still respecting very precise dimensions. 

  We did the same for the top & bottom part of the enclosure, resulting in parts that have many details both inside and outside with no visible flat surface (the glued joint plane is almost invisible and with an added thickness so small it's indistinguishable).

  Let us know what you think of this idea and if this is helpful for your projects!

View all 12 project logs