Wii Pocket

[jefflongo]

Many of you may remember that I started my second portable awhile back. Well I decided to drop that project and start again from the bottom up this year. I threw out the designs for all the PCBs, I'm starting with a new Wii, and redesigning everything from the bottom up. I'm taking the inspiration from the previous idea and merging it with the "no compromise" ideals from my first portable to create the true successor to my first portable. I started the redesign last month, and I have a lot to share. But I'm going to roll it out once I'm confident in my design instead of jumping the gun. Just know that this year I will finish an entry and I hope you all are looking forward to it!

 

[jefflongo]

Relocated the NAND today, using @Aurelio 's flex board. Even with the flex board it's still no easy feat, but much better than wiring both sides by hand. Here are some pics before I trim. I also took 3 hours of video consisting of the disassembly, u10 relocation, ldo removal, and NAND relocation that I will make into a time lapse later, so look forward to that!

 

[jefflongo]

Went ahead and trimmed the Wii today. I use a slightly modified LMAO trim to retain some screwposts and things like the input pads to the preamp and the USB vias. Here's some pics of the trim if anyone else wants to try it.



Before the trim:

After:

Success! (Not pictured: 1 hour of debugging a short on the 3.3v line)

 

[jefflongo]

updates soon

 

[jefflongo]

Clearly I didn't make it in time for the contest. I didn't start this project with the contest in mind, it was more of a "it would be nice if I happen to finish" kind of thing. I'm planning on making this portable among the best there ever was, and in order to make no compromises I had to give up on the contest. In addition, I'm currently working full time which makes my modding time even more limited.

That said, I'd like to share what I've been working on for the past few months.

At the top is a USB C PD with USB data multiplexing board based on the STUSB4500. I'm able to negotiate up to 20V via USB C for efficient, fast charging. The STUSB4500 allows for three programmable power profiles. I'm currently developing code to dynamically assess the capabilities of the charging source and program the power profiles on the fly. This board contains a USB A port for the internal flash drive of the portable. It supports powering the USB A port through both the charger and the PMS 5v regulator. In addition, the flash drive is accessible through the USB C port whenever the system is powered off.

At the bottom is my custom PMS. I've been working on this one for quite a few months, before Gman's PMS became the norm. It features the BQ24292i to support charging at voltages up to 18V, as well as all necessary battery management and safety features. In addition, my PMS has an on-board fuel gauge to accurately determine the battery percentage for battery level indication. The PMS contains 5 voltage regulators which output the necessary 5v, 3.3v, 1.8v, 1.15v, and 1v rails for the Wii. Lastly, my PMS has a PIC16 microcontroller to handle programming the ICs, communication with the USB C PD board, tact switch power-on/off, driving the system's status LED, and 2 extra programmable pads which I will talk about what I'm using them for later in the development of this project. On to the system status LED, I've written a driver which controls a WS2813 LED. This LED is great because it offers 24-bit RGB color using a single GPIO pin to drive it, all in a 5x5mm package. This LED will be used to indicate charging status, low battery, and possibly other features in the future.

Both boards were developed using only 2 layers. The PMS is a mere 21x60mm. I've chosen this narrow, long shape to fit the form factor of my small case. I have one more board that came with this batch of PCBs that has some exciting features, but unfortunately there is a hardware mistake on it so I will post again when I revise the board. Thanks for reading!!

 

[jefflongo]

I've been working a lot on this project lately. Unfortunately no pretty pictures to show, since I've been working entirely in software. I got started learning the PIC environment since this is my first time working with this controller. I picked up this MPLAB Xpress DM164140 evaluation board to get familiar with using the different PIC peripherals. For any of you wanting to get started with PIC, I highly recommend picking up this board. It cost me $12 and it has everything I've needed so far: 4 LEDs, a pushbutton, an i2c temperature sensor, uart through USB, ect. I was able to get interrupts working, as well as write my WS2813 driver, and now my i2c driver (after some difficulty).

Now that i2c is up and running, I spent a huge amount of time writing an interface to flash the STUSB4500 non-volatile memory on my USB C board. In other words, the STUSB4500 can be programmed with 3 power profiles, but if the battery is dead (and thus the microcontroller that programs the STUSB4500 is turned off), the power profiles will be the defaults stored in its non-volatile memory. This is bad because one of the default power profiles negotiates 20V, so if someone were to plug in a 20V charger while the battery was dead, 20V would be negotiated and my PMS would be fried. I've refactored and improved the crappy code ST provided to reprogram the default values in the STUSB4500. This interface is simple to use: you just edit the constants at the top of the file with the parameters that you want, and run the code to flash the chip. I flashed my chip today and with no battery connected I plugged in my 20V laptop charger, which was successfully negotiated to 15V.

The next step is to work on on-the-fly power profile programming. This means when a USB C charger is plugged in the STUSB4500 will read the capabilities of that charger, which the PMS microcontroller can then read, then program the STUSB4500 to use the highest safe power profile the charging source can supply. This eliminates only being able to have 2 custom voltage levels for negotiating, and also ensures the system is using the charger to its fullest capabilities. By the way, I will open source both the NVM flashing code as well as the on-the-fly power profile programming when it is completed so that everyone can get in on the USB C fun.

Last order of business, my revised version of the 3rd PCB I had delivered will arrive in around 2 weeks. I think you guys will like it. Stay tuned!

 

[jefflongo]

I've been hard at work coding. As some of you might know, the STUSB4500 supports 2 configurable power profiles. The problem with this is that if I have these power profiles set at, say, 9V and 15V, and I plug in a 12V PD charger, the STUSB4500 will only negotiate to 5v even though it is capable accepting 12V. What I've been working on is a method to read a charger's power profile capabilities, and program the STUSB4500 on-the-fly to accept the optimal power profile based on user-defined parameters (minimum current, minimum/maximum voltage, maximum power). This would allow for any USB PD charger to be used to its fullest potential. This process has been excessively difficult due to ST's absolutely dreadful lack of documentation. After much struggling, I was able to get it working. I will be open sourcing this, as well as porting this to Gman's PMS code so that anyone that uses the STUSB4500 in their own project or uses the USB C board from the BitBuilt store will be able to take advantage of this feature. I'm hoping to release this by the end of the week. The release will include code to flash the non-volatile memory of the STUSB4500 to change the default settings for dead battery operation, as well as automatic on-the-fly PDO configuration.

In other news, my updated revision of the PCB I've mentioned earlier but haven't shared has arrived. I'd like to reveal my custom GC controller ports! To be a true successor to my first portable, I felt the need to include integrated GC ports as opposed to my previous dock idea. I was able to find a way to make everything work in my desired small form factor. I desoldered the GC ports from a GameCube front panel assembly (the ports from a GameCube are smaller than those from a Wii), trimmed the plastic connecting the ports together, and created my own PCB to compact the four ports together.

Now here's the kicker with these ports. When a controller is plugged into the P1 slot, the data line to the Wii will automatically be switched from the internal controller to the external controller. When the controller is unplugged, the data line will automatically switch back. This is achieved through current sensing on the P1 3.3v rail which feeds a comparator to drive a data multiplexer. Enjoy the pics!

 

[Diminuendo]

When a controller is plugged into the P1 slot, the data line to the Wii will automatically be switched from the internal controller to the external controller. When the controller is unplugged, the data line will automatically switch back. This is achieved through current sensing on the P1 3.3v rail which feeds a comparator to drive a data multiplexer.

Teach me your ways, I've been trying to figure out how to do this with my GC and integrating a PS/2 keyboard adapter on player 2.

 

[jefflongo]

Teach me your ways, I've been trying to figure out how to do this with my GC and integrating a PS/2 keyboard adapter on player 2.

One way is to have a physical mechanism with a pullup resistor that closes a circuit to ground on plug in. Since the GC port does not have any sort of sense pin, I did a current sensing route.
The short of it is that the 3.3v line to the P1 port is an open circuit when the controller is not connected. I measured the current the 3.3v line draws on a GC controller and chose a small resistor to put in series with the P1 3.3v supply to drop the voltage by about ~40mV (3.26v). I set a reference voltage between the two at 3.28v. This way, with no controller plugged the P1 supply voltage is above the reference voltage. When the P1 controller is plugged, the P1 supply voltage is below the reference voltage. A comparator outputs high or low based on this condition. The comparator drives a multiplexer to select the appropriate data line.

 

[vikMKW]

I love the auto switch over! I see that you omitted the caps, diodes, and components named "FIL" connected to the gamecube ports. Excluding them doesn't affect noise/interference?

 

[apt-get CFW]

Those GC controller boards look awesome, i want. lol