Midterm Review

13.1.0

INTRODUCTION

Over the last two weeks, I have been splitting my attention back and forth between our amazing group project and chipping away at my final project, the PAK system. In this week, I finally assembled what I could call the very first functional prototype of the PAK, with all of the bells and whistles in tact, just... not very pretty to look at.

If I'm being honest, I pictured myself a little farther along in this development at this point. I think I unrealistically thought I would have a lot of the subsystems of my design figured out - or at least closer to the finished product. Right now, all of the pieces don't play nice with each other, but they are all there. Let me break it down.

[x] Show progress in documenting all previous assignments
[x] Show progress on your final project idea/s and planning
[x] Made a schedule for remaining tasks
[x] Meet with your local and global instructor - Hi Henk! :)

13.2.0

THE PAK SYSTEM

Before we talk shop, let me properly define again what it is that I'm actually trying to make for my final project. I am creating a "dumb" device that requires its user to be intentional with its interaction. The device operates like a smartphone, but takes the form factor of an old Game Boy, where each application runs on it's own dedicated cartridge. The user must decide which cartridge they want to run. The plan is to develop the device itself and anywhere from 2-8 cartridges for the device depending on my time and effort in the coming 8 weeks. The first cartridge will be a simple pomodoro timer that I can use to help myself take breaks when I'm locked in on a passion project. You can read more about the other cartridges I have planned on my final project page.

Development can be broken down in to several subsystems that I need to focus on, each independently, but through each iteration I can get them closer and closer to system integration.

➔ Motherboard PCB

IMAGE CAPTION ⇲

This is arguably what will make the PAK functional, everything else will be cosmetic and/or supplemental to this PCB. I've chosen to develop the PAK on a ESP32-WROOM-32E for it's available pinout, WiFi and BLE support, and processing power available to handle the types of things I want the PAK to do. Also it supports MicroPython which is certainly a comfort zone language for me, but pushing my understanding to something of this scale will really help me get a better grasp on object-oriented programming. The main board will also house the power delivery for the device, which will be a LiPo battery with a TP4056 charger and LDO circuit. The entire device charges via USB-C, but also needs to be programmable over USB as well. The motherboard also connects to the other boards described below and components - such as the screen. Lastly the motherboard PCB will house the cartridge edge-connector-style port that each cartridge will slot into.

IMG_FILE: midtermmotherboard.png

TYPE: PNG

XYZ: 123

➔ Control System PCB

IMAGE CAPTION ⇲

The control system PCB is separate from the motherboard to allow us to stack the PCBs, get the buttons physically closer to the face plate of the case, and to allow us a bit more freedom when arranging and designing the case that the whole thing fits around. The control system PCB houses the shift register chip used to collect the inputs from our directional pad and four face buttons (A/B/START and "P" button - which stands for PAK and will act like a home/settings button). This PCB also contains an RGB LED that is used as a status indicator on the device.

IMG_FILE: midtermcontrols.png

TYPE: PNG

XYZ: 123

➔ Cartridge PCB

IMAGE CAPTION ⇲

Each cartridge is built with an identical PCB that can accommodate many different external/internal peripherals depending on the function of the cartridge. In it's stock configuration, the cartridge simply houses the flash memory SOIC that holds the script data to run the application. The cartridge will interface with the main PCB with ~10 pins however, which will allow for extra expansion to other devices that can be soldered to the cartridge board. These expansions could include extra I2C or SPI devices like an accelerometer or temp/humidity sensor that will be baked in to the cartridge (with some modifications to the 3D printed case).

IMG_FILE: midtermcartpcb.png

TYPE: PNG

XYZ: 123

➔ Cartridge Case

IMAGE CAPTION ⇲

This is the plastic 3D printed (or casted?) shell around the cartridge PCB and any other component that may be inside. The design of the cartridge itself has a physical structure such that it cannot be inserted into the slot incorrectly - it has a physical rail that prevents it from doing so. The cartridge also interfaces to the main unit with a push-push mechanism for a super satisfying click. Originally I wanted to try uses pogo pins to make this interface, but after testing, I have chosen to pivot to a more traditional edge connector style board.

IMG_FILE: midtermcartcase.png

TYPE: PNG

XYZ: 123

➔ PAK Case

IMAGE CAPTION ⇲

This is the plastic (or maybe even metal) case that surrounds the whole system. This is likely one of the last things I will be iterating on as more of the internal components take shape. The case needs to accommodate the 3.5" screen, the D-PAD and 4 face buttons, the cartridge slot, USB port, and the RGB LED indicator, which may require a light pipe or diffusion depending on where it ends up.

IMG_FILE: midtermpakcase.png

TYPE: PNG

XYZ: 123

➔ Controls

IMAGE CAPTION ⇲

The D-PAD and Face Buttons are ideally something that I make myself through molding, casting and/or 3D printing. I have stock buttons that I can use, and I could easily print something to interface with them - but I'm aiming for a really authentic and satisfying feel for the final product, so this is something I will need to develop my learning for over the next couple weeks.

IMG_FILE: midtermcontrols.png

TYPE: PNG

XYZ: 123

➔ Operating System

IMAGE CAPTION ⇲

This would be a python script main.py that would be acting as the backend for the UI and system that runs on boot, handling system inputs, interrupts, inputs, battery level, errors, and the filesystem mounting on the flash chip on the cartridge.

IMG_FILE: midtermoperatingsystem.png

TYPE: PNG

XYZ: 123

➔ Cartridge Software

IMAGE CAPTION ⇲

I'd argue each of the cartridge ideas I've proposed could be added as their own subsystem here - but I'm hoping to develop a universal python class that each cartridge app can just drawn from for simplicity in the UI, and each of the unique functions can be coded around that.

IMG_FILE: midtermcartsoft.png

TYPE: PNG

XYZ: 123

➔ UI/UX

This is less of a subsystem and more of a harmony of many of the above, outward facing subsystems, notably the main unit and cartridge cases and the two levels of software described. Being able to create a really sound and consumer-grade device that has a polished user experience is one of my main goals of this project, so I really hope I'm able to get the other items completed to a level that allows me to work on this polish more.

13.3.0

PROGRESS & PLANNING

Let's quickly recap where we're at for each of the above sub-systems and then we can develop a plan of attack for progressing.

➔ PCB Design

I have milled several boards over the past couple weeks, learning more about electronics design in each iteration. I naively began development in Week 6 and 8 by trying to mill out a "dev kit" on a single, very complex double-sided board. I wrote about all of the issues I ran into in depth in my week 08 documentation. After these learning opportunities, I made the decision to temporarily split up the motherboard into several smaller boards that I could independently mill, test, and most importantly: replace if anything broke. This would help me get closer to a device I could actually start developing on, rather than spending weeks trying to get a single board working (that could end up breaking anyways). Doing things this way helped me learn more EDA and practice my soldering skills in addition.

At the time of writing, I have functional (albeit not system integrated) for the main motherboard; which houses the ESP, power delivery (just over USB, no battery), and 21 pin headers that connect to the other boards; the cartridge board which uses my old pogo pin design (bodged together with a literal binder clip); a D-pad/button/shift register board; and a board that houses two RGB leds, although I am only hooking up to one. The whole thing isn't pretty - and I know it's literally a bunch of spaghetti on a breadboard - but it works right now, and that makes me happy and confident to move forward.

With this little dev kit I was able to test all of the pins for my final layout. I've settled on this pinout, and hopefully it does not need to be changed.

WHAT'S NEXT?

The final goal of the PAK is to have a board house complete the PCB for me, as I need much more precision and complex wiring to keep everything small and compact. I'm conflicted about sending off a board design too soon, as I'm worried I'll run into issues with the board and need to order it again, costing me money and time. I guess I won't know timelines and cost until I draft one up and get a quote - so my immediate plans should be to create a modular PCB for the motherboard and control system that could theoretically find itself in the final design. The requirements are that I get each board as small as possible, and pay close attention to position of pins for optimal wiring, and kind of most worryingly - integrate the power delivery platform that remains to be tested. My other worry is making sure the custom footprints (so far I have designed 4) will work nicely - as trying to bodge things around a PCB is not fun. But again, I guess I won't know the cost and time of these things until I actually get started.

Lastly, I need to complete the redesign for the cartridge PCB once I determine the edge connector parts either available to me in the lab, or at local shops or online.

➔ Case Design

I have a number of prototypes printed from the first few weeks (well a lot of cartridge designs, but really only one design for the PAK itself), mainly just as a way to start getting a feel for the footprint of the finished product. The only part of the design that I have, in theory, completed is the rail/block system for the cartridge slide-in, preventing the user from inserting the cartridge the wrong way. I'd like to stick with the current dimensions I have for all of the printed parts for now, but understanding that I can loosely edit them to make them fit nicely with our internals.

1

2

SLIDESHOW ⇲

The many different iterations of the first version of the cartridge

The cartridge rail/block mechanism that is more or less in its final state

I've also thoroughly tested the push-push mechanism for the cartridge port with off the shelf components ordered from AliExpress. It works very nicely and I seem to have already got the spacing and tolerance dialed in. I just hope it plays nice with the friction/contact needed for the edge connectors.

1

2

SLIDESHOW ⇲

the many cartridge iterations to test the push-push mechanism

and the resulting click! Super satisfying!

I did some testing of the RGB LED and a 3D printing light pipe back in week 10 to get a sense of how the indicator LED will look. This is something that will likely be revisited towards the end, but getting the location of this light is important on the board, as it should line up with the other system buttons (START and "P") as shown in this image:

The buttons themselves are also an important part of the case. I have only been using off the shelf components up until now, which obviously will not be suitable stock in my final design.

WHAT'S NEXT?

The current prototype is not super transportable, so I think the first order of business is to print a case that at least lets me move around the dev kit without being worried about disconnecting parts or traces getting ripped up.

I am concerned with aesthetics of the final design, but in my experience with Fusion so far, parametric design doesn't play well with final polish when we're tinkering with small details, so the plan should be to first design and print a basic block-like case that can act as the housing/skeleton for the internals and then when we're happy with that footprint design a more aesthetically complete shell using the same footprint and either have it printed in house or shipped off to a print house.

After learning more about molding and casting, develop, design and cast buttons that feel satisfying to use. I'm aiming for softer, rubbery buttons that have a bit of give and playfulness to them over super rigid plastic ones. I'll have more to report on this after I've experimented next week!

➔ Software

Up until this week, I have been writing all of my test software in complete isolation. Each script is basically starts from scratch so I can test the components individually to test if they even work in the first place. Early I decided to use CircuitPython on the XIAO devices for ease of use in flashing (I really can't stand how long it takes to flash a device through Arduino) and for familiarity with Python. I took a one week dive into trying development on C++, but quickly became apparent how far in over my head I would be if I continued down this route. C++ is so difficult to debug and, while I'm sure it will net me better performance, it's simply not worth the effort trying to develop on it if it risks making actual progress. I've made the switch to MicroPython and after doing some research and testing, it feels like the right call for the rest of the project's development.

Now that I have a fully assembled first prototype, I could start developing software with central methods and classes that all scripts can pull on. If I get this prototype in a transportable form, I could in theory just continue writing software on it wherever I have my computer - which would make it very easy to chip away on it over the coming weeks.

WHAT'S NEXT?

Develop a system level object-oriented architecture in MicroPython that can test and debug all of the individual subsystem components and hand off arguments to functions that could be called in cartridge applications. Then we can start fleshing out the skeleton of the UI and tweak it over time. Priority is one creating a good try/except block that catches errors, safely releases the SPI bus (to ensure we don't corrupt the data on our flash memory), and gets our errors on screen instead of just in the serial monitor.

Once I have a debug/system level script running, I can start development on the simple cartridges. I think bare minimum, I need to create the pomodoro application and get it flashed on a cartridge. From there we can look into creating more of the stretch goal cartridges.

13.4.0

Conclusion

The assignment this week asks us to schedule out our remaining tasks. The most immediate action items for the coming weeks seem to be:

- talk to Yuichi about edge connectors for the cartridge, see what my options are
- print a case that lets me move the dev kit around
- complete the redesign for the cartridge PCB (and do a test mill in house)
- design the PCB for the motherboard and control system and ship it off to PCBway
- system level object-oriented architecture in MicroPython

From here, I'm able to develop on the system while I wait for other parts (or for my own learning) to develop. After next week, in completing molding and casting, I should be able to:

- begin developing a design and cast buttons that feel satisfying to use
- print out a placeholder case/interface for these new buttons to my existing dev kit

And then continue development into the third (and beyond) spiral. These tasks align nicely with the assignments each week, so it's easy to assign myself deadlines that align closely to those tasks.

- creating the pomodoro application first, and then more complex apps
- designing and printing a basic block-like case that can act as the housing/skeleton for the internals
- create cartridges with modifications that can house expansion components

And in the final weeks:

- design a more aesthetically complete shell using the same footprint as the block-like case
- polish the UI/UX of the software
- work on the final presentation slide and video, which I'm planning on creating 3D renders for to make it feel a lot like a consumer electronics product reveal