So I’m an absolute newbie and only an electronics hobbyist. I’ve been soldering for years, mostly modifying/repairing video game consoles. Inspired by the guys over at bitbuilt I recently decided to try and build a handheld PlayStation 2. The plan is to power it with 4x 21700 cells wired in series. I’d also like to charge (and charge while playing) through USB-C power delivery. I’ve purchased this charging management board to handle all my battery protection and charging, and if I’m not mistaken it will deal with charge-and-play. (By charge-and-play I mean that it will disconnect the battery from the load and power the console directly from the power supply when plugged in while allowing remaining power to charge the batteries). I also have the parts to handle all the voltage regulation I should need in the mail.

I’m trying to design a circuit that does the following things:

1. allows charging using USB-C PD. IE will communicate with a USB-C charger to trigger 5v voltage delivery for charging.

2. Has a USB female port that will house a small internal USB drive where game files will be stored. I want to be able to access the drive through the USB-C port when the device is off and I want the port to be routed to the motherboard when the device is on. From my understanding this should be handled by a USB multiplexer.

3. Possibly manages charging/protecting my 1s battery pack as well as “charge-and-play” if the board I bought off Amazon looks insufficient.

My problem is primarily that I don’t have any idea where to even start, which likely means I’m biting off more than I can chew. Using my limited ability to source ICs to accomplish what I want I’ve come across some TI devices like this one that appears to have the ability to meet my PD and mux needs. I just wouldn’t know where to begin designing a PCB to utilise this thing.

I guess my overarching question is this: Is such a thing far too complex to design for someone with no background? If not, what are some resources I could use for reference circuits/understanding how any of this works?

Thanks in advance for any wisdom.

 

Welcome to AAC.

Your instinct that you've bitten off enough to choke you is spot on. If you want to proceed with this you need to break it down into subsystems and work on them separately.

For example, start out by considering the power management separate from the data storage. Have a goal to integrate them into a single USB C connector but start out with two and make each piece work.

Even before this, get your PS2 part working to ensure you understand of its requirements for housing and power. Make sure you are not making a mistake by guessing at the appropriate battery, and make sure the physical layout actually works.

It is normal in a project of this sort to build prototypes—the first ones not necessarily resembling the finished product at all. This lets you test the functionality and even the feasibility of your proposed circuit.

To this end it would serve you well to forget about the implementation details you've prematurely settled on and make a functional list of what your device will do, rather than how. For example (this is just example, not suggestion):

Runtime: 3 hours

Battery Management: Single port for charging and power. Charging while in use. Battery SoC indication. Graceful shutdown in low batter situation.

Thermal management: Fanless or very quiet fan. Heat transport away from user's hands, cool case. Graceful shutdown on overheat.

Internal Storage: xxGB. Accessible through dedicated port, or through charge/power port. Upgradable.

(etc.)

Once you have such a list you can begin to figure out what you need to know to satisfy these requirements. For example you will need to know how much battery capacity will be required to achieve 3 hours run. This requires measurement. For thermal management you will have to work out how much heat you have to move. For the storage you may have to choose something other than what you first expect (e.g.: MicroSD).

All of this is speculation. But so are your current mixed requirements. You can't know what you need or how to do it without some kind of roadmap to keep you on track. Then, you can't get there unless you do this stepwise and logically. For example the PS2 part is the focus. It drives the power requirements and those requirements in turn affect the battery and housing configurations.

If I were doing this, I would write out a good list of requirements free of implementation details first. Then, at a guess but not a wild one, I would put together an umbilically powered version of the PS2 part and take measurements of peak and average current, for example, to scale the battery; and heat to make sane choices for the housing and cooling.

To succeed this is going to require a fair bit of time and learning. But if you take the meal in courses it shouldn't choke you before you finish it.

 

Welcome to AAC.

Your instinct that you've bitten off enough to choke you is spot on. If you want to proceed with this you need to break it down into subsystems and work on them separately.

For example, start out by considering the power management separate from the data storage. Have a goal to integrate them into a single USB C connector but start out with two and make each piece work.

Even before this, get your PS2 part working to ensure you understand of its requirements for housing and power. Make sure you are not making a mistake by guessing at the appropriate battery, and make sure the physical layout actually works.

It is normal in a project of this sort to build prototypes—the first ones not necessarily resembling the finished product at all. This lets you test the functionality and even the feasibility of your proposed circuit.

To this end it would serve you well to forget about the implementation details you've prematurely settled on and make a functional list of what your device will do, rather than how. For example (this is just example, not suggestion):

Runtime: 3 hours

Battery Management: Single port for charging and power. Charging while in use. Battery SoC indication. Graceful shutdown in low batter situation.

Thermal management: Fanless or very quiet fan. Heat transport away from user's hands, cool case. Graceful shutdown on overheat.

Internal Storage: xxGB. Accessible through dedicated port, or through charge/power port. Upgradable.

(etc.)

Once you have such a list you can begin to figure out what you need to know to satisfy these requirements. For example you will need to know how much battery capacity will be required to achieve 3 hours run. This requires measurement. For thermal management you will have to work out how much heat you have to move. For the storage you may have to choose something other than what you first expect (e.g.: MicroSD).

All of this is speculation. But so are your current mixed requirements. You can't know what you need or how to do it without some kind of roadmap to keep you on track. Then, you can't get there unless you do this stepwise and logically. For example the PS2 part is the focus. It drives the power requirements and those requirements in turn affect the battery and housing configurations.

If I were doing this, I would write out a good list of requirements free of implementation details first. Then, at a guess but not a wild one, I would put together an umbilically powered version of the PS2 part and take measurements of peak and average current, for example, to scale the battery; and heat to make sane choices for the housing and cooling.

To succeed this is going to require a fair bit of time and learning. But if you take the meal in courses it shouldn't choke you before you finish it.

Thanks a lot for the thoughtful answer. I’ll take your advice and start prototyping one system at a time.

 

Thanks a lot for the thoughtful answer. I’ll take your advice and start prototyping one system at a time.

One thing that I always do is try to come up with an invariant interface among subsystems. What I mean is, I figure out the signal flow among subsystems and work out what signals are necessary for each of them, then make that a fixed idea (excepting errors or omissions, of course).

By doing this you can replace any subsystem without the other systems knowing about it since all the signals you need will be provided no matter what receives them.

 

Alright here's how far I've gotten so far.



Extremely ugly I know. This is my first time using KiCad. I chose IP2721 to control my USB-C PD and TS3USB30ERSWR to control my data multiplexing. I've designed the circuit (hopefully) to supply 5v to the BMS for charging through USB-C. When the console is powered on, the mux Vcc and Select pins and the USB-A port should receive 5v from the voltage regulation board causing the mux to attach the USB A port to the router USB data lines. When the console is powered off and plugged in via USB-C, 5v should be supplied to the mux Vcc and the select pin should be pulled low to GND which will cause the mux to attach the USB-A port to the USB-C port.

I know this will be tedious to critique, but is there anything obviously wrong with my circuitry or can I expect this to perform how I expect?

I intend to physically prototype each system (mux vs PD) individually before I tie them together like this.