Requirements for PCB design for HW-testing setup
The PCB design needs to contain:
- A socket for placing a Raspberry Pi Pico (RPi)
- A USB-A female port on the board connected to the RPi marked as "Pico". Used for control and to power the RPi.
- A 12V-in barrel jack which powers a buck converter with ~3.8-9v 4A output. This will be used to power phones running without a battery
- A software-controllable way to adjust voltage on the buck converter
- A way to measure power voltage and current in the output of the regulator
- An integrated USB hub that:
- Can do power control on one port, which is connected to the RPi
- Has one USB-A female port output marked as "Phone"
- Receives power from the 4A buck converter
- One RGB LED connected to a GPIO for board identification
- One or two buttons connected to GPIOs
- 5 GPIOs, one I2C, and one UART connection from the RPi should be connected to headers. This will be used to control buttons, UART, and have possibilities for future expansion
- A way to adjust the UART connection between 1.8V and 3.3V
Other requirements:
- The PCB design should be shared with the postmarketOS project, by sending an MR with the KiCAD file(s) to develop the project to a TBD repository.
- The PCB KiCAD file(s) should be placed under an Open Hardware License
- Board dimensions should, if possible, not exceed a credit-card size
- If possible, the board should be one-side populated
Activity
changed milestone to %Hardware testing setup
One LED connected to a GPIO for board identification
I might suggest this using an RGB LED here. With PWM you can do a ton of colors, but even just using GPIO you can get a bunch of color combinations easily. I always find I don't have enough LEDs to indicate status, especially when debugging, so suggest erring on the side of too many here.
By Bryant Mairs on 2024-05-22T20:48:53
Edited by Ghost User-
Not really an experienced hw dev, but some thoughts:
- A socket for placing a Raspberry Pi Pico (RPi)
- A USB-A female port on the board connected to the RPi marked as "Pico". Used for control and to power the RPi.
If you mean that part of the assembly process would be plugging a dedicated usb cable from the onboard pico uUSB to the USB-A on the same board, IMO we should eliminate the cable. Instead reference design rpi pico board has testpoints on the bottom that expose usb, so if the board is intended to be socketed, pogo pins can be fitted; and if the board is intended to be soldered on, I think people usually put vias there and solder into them when manually assembling; pcba should be better with pads, they have an oven. Alternatively rp2040 modules that expose usb pins as pads exist too, though not sure if it's trivial to get those for mass production at a pcba place.
Upsides:
- Less manual steps for assembly if the board only needs to be fitted;
- Less clutter with cables in the test setup;
- More reliability (i.e. can't accidentally unplug the cable in maintenance);
- Slightly smaller BOM/cost: one less cable; one less connector; one less manual assembly step.
A 12V-in barrel jack which powers an LDO with ~3.8-9v 4A output
Probably should be switching regulator. You don't really need low noise floor on board power, and LDO would be inefficient since it would need to dissipate heat, especially at 4A rated. thus I'd say s/LDO/regulator/ across requirements.
By Nikita Travkin on 2024-05-30T15:25:58
Edited by Administrator -
the board would basically be a "hat" for the pico. idk how viable pogo pins are for USB (reliability might be an issue) but soldering to the test pads for d+/d- is probably acceptable. That said, a USB cable is honestly not the worst solution here, short micro usb cables are pretty easy to find.
By Caleb Connolly on 2024-05-31T03:38:53
-
talked to an engineering friend, and got some input on the top post proposal:
- we should require the design in a KiCAD file, it's the open source standard software for this
- "A 12V-in barrel jack which powers an LDO with ~3.8-9v 4A output" -> instead of LDO: buck converter
- "A way to adjust voltage on the regulator" -> software controllable
- "A way to adjust the UART connection between 1.8V and 3.3V" -> jumper is enough here, no need to control that in software
- LED: at least 3 for RGB (as Bryant noted), as they don't cost much and make it much more usable
- designing this should take somebody who is very experienced half a day / a day (much less than I thought!)
- how many do we want to produce once we have a working design? he estimated that very roughly for 100 units (without the pi zero) we would pay 10-15€ per piece. I think that sounds good.
- we should give the dimensions of the board, e.g. credit card size and we probably want it populated one-sided
- we should write for what we need the electrical power supply, how many watts for waste heat and heat sink
By Oliver Smith on 2024-05-22T20:57:52
-
I reviewed this with my friend and found some of the specs confusing. Specifically trying to understand why the low-level specs, but we have no context to match them too. Could you provide a description of how the overall system will work? I couldn't find one. More detail the better, especially if it includes a prototype hardware setup for reference.
What is the adjustable voltage for? And does it really need to be runtime-configurable? I'm assuming this is so any style of phones can be supported? Could we instead use a hardware jumper to set a specific set of voltages (is there a small set of voltages that would work here)? This will be much simpler to implement, require less software, and be easier to use.
Also, did you want this to support a Chromebook for testing? 9V will be too low for that, right?
So we want to be able to control a phone via USB, GPIO, i2c, and/or UART using a single USB connection from a PC and external power? But why not have a second USB cable and plug the phone in directly?
This would be a pretty simple set up:
_____ /------ USB ------------------------------------| | | /----- GPIO lines -------| | PC ----- USB ------- PCB------ UART -------------| | DC PWR ---------------^|\----- i2c --------------| | \------ PWR --------------|___|Then the board is basically a pin breakout for the raspPi and a power adapter. Why couldn't you do [this](https://www.adafruit.com/product/5096 and this power adapter? Is it because you want to monitor power of the device?
Also, do you want someone to write any firmware for this device at all?
By Bryant Mairs on 2024-06-06T21:13:26
Edited by Ghost User -
The firmware is already written in https://github.com/calebccff/pts-pico-firmware, which also has a diagram. I'll let @calebccff answer the rest of the questions. And I agree we should document this better. I'll try to add more info to the milestone next week
By Pablo Correa Gomez on 2024-06-06T21:13:26
-
@susurrus replying to both your comments:
What is the adjustable voltage for? And does it really need to be runtime-configurable?
Yes this is for battery emulation. We may want to test things like undervoltage conditions (I'm currently starting work on porting Qualcomms driver for handling this conditions to upstream, and don't have a good way to test it).
Could we instead use a hardware jumper to set a specific set of voltages
This would be done via a potentiometer (jumpers would need a resistor ladder and calibration anyways which is more complicated), and while this is pretty easy, it breaks the usecases i mentioned above. Regulators that can be programmed via i2c are not prohibitively expensive and don't add any significant complexity here.
The other benefit to these fancy i2c regulators is that they can be calibrated automatically when the pico is powered on. So we can actually ENSURE that you don't accidentally overvolt the phone.
:: adjustable voltage w/ feedback is safer and easier to use.
Also, did you want this to support a Chromebook for testing? 9V will be too low for that, right?
Not something I want to focus on initially. If someone is really committed to it they could fairly easily find a workaround (like if the chromebook has a proper "reset" test pad and we can avoid needing to cut the battery power).
So we want to be able to control a phone via USB, GPIO, i2c, and/or UART using a single USB connection from a PC and external power?
(probably redundant but just to clarify) We want to be able to attach one USB cable to a PC and then access UART and USB on the phone, as well as power cycle it and toggle GPIOs.
But why not have a second USB cable and plug the phone in directly?
Because then you either need to use a USB hub with PPPS (power port power supply control) or you're stuck with VBUS always being supplied, making it impossible to properly power cycle the device.
Why couldn't you do this and this power adapter?
You technically only need this cheapo buck converter, the pico, two 10k resistors and some wire, breakout board is way overkill.
But then you also need the PPPS USB hub, your control software needs to power sequence by sending commands to the pico and controlling the hub, which is significantly more complexity (and requires hardcoding the usb port addresses), and the end result looks something like this (frustrating to work on, easy to damage, and not scalable):
Is it because you want to monitor power of the device?
Yes. The goal of building a custom PCB is to have something which is easily plug 'n' play, is reliable, consistent, and can level up the capabilities of the entire community.
Power monitoring is definitely one of the biggest motivations, beyond just having hardware testing. Including it is just foresight.
is this designed so anyone with minimal soldering skills can get some PCBs made of this and get it up and running or should it be cheap to have full assembly done?
Ideally both? I would prefer parts that are easily available (and will continue to be...), if they can be hand soldered that's ideal, but I think with the fancy i2c regulators they're only QFN. If they can be ordered with assembly that would be preferable.
I think once we have a design done and working we can do an initial batch, get them to some devs and start getting set up. Then once we have some software up and running we can make any PCB changes that are needed and do a much bigger batch so we can start getting them in the hands of more folks across the community.
By Caleb Connolly on 2024-06-06T22:10:07
-
Just a small comment..
For the UART level-shifting there are many ways to do that, from some simple pull-ups or simple circuits with a BSS138 FET.
One of the most convienent ways I have found, is to use the NXP NTB0104 or TI TXS0108E.
By Robert Eckelmann on 2024-06-08T11:38:52
-
I had some additional thoughts on this, it might be useful if we could use U-Boot's networking support and just netboot. This would solve the flashing problems, and it should be quite doable for Qualcomm phones and the Librem 5 since they have DRD capable USB controllers.
We'd just need a supported USB NIC and a powered hub, this could potentially be integrated into the testing harness, or just something separate.
It would also make it really easy to integrate with ci-tron CI, which seems like one of the best options for a CI system.
By Caleb Connolly on 2024-06-26T14:05:39
Edited by Ghost User -
Would that mean, that it would be a requirement for any device to be added to the CI to boot with U-boot? Would such setup require some additional requirements to those out-lined above, so that it wouldn't work? If those requirements are a bit "too much" for that use-case, I'd say let's keep the requirements, and then we can support multiple use-cases? At this point, the time and effort to change the requirements and partially re-start the process is probably greater than paying some extra hours for a more complete design, wouldn't you think so?
By Pablo Correa Gomez on 2024-06-26T14:05:39
moved to phone-harness#1 (closed)
