**UPDATE August 9 2018**
After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity. I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu I apologize for the bad information) Other small updates include a possible reason for the small voltage reporting measurement error.
After having received an official Tinker Board Power supply, I submit my findings:
Test load hardware: Tinker Board S with internal voltage monitoring
Condition: No peripherals save mouse/keyboard/small cooling fan to prevent throttling
Load: minerd --benchmark
Measurement: For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work. It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient.
The Tinker S reads low when you get to the 5.0V area. I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts. This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load. With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load.
As to the supply itself:
Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire.
Electrical:
5.0 V 3.0 A. This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop.
The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply.
Data:
Analysis/Commentary (very loose format):
Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load)
Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints. It is experiencing excursions just below the acceptable minimum, so that will be something to look out for. There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load.
Recommendations for consumers:
This supply will work, and is at least on par with the other similar units on the market. The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu. Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work.
Recommendation to ASUS:
If it is at all possible request the supplier increase the output voltage of this supply by 250 mV. At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility.
We've noticed this concerns at the beginning.
As a matter of fact, believe that we are more worried about any safety design than our guests if out of the power current spec.
So that connector on the Tinker Board & Tinker Board S. We all requires our vendor need to qualified the pressure & safety stress test with 5V/3A.
They can all be relieved to used and can withstand 5v/3a.
(as I knew, the 1.8A is more like a reference standard, so also have lots connectors are required more than 1.8A.)
Since we have no intention of changing too much layout design and let it can have the highest possibility to fit RPI form-factor's 3rd party case, components, etc.
BTW glad to know you like our colorful design on GPIO, that is my favorite part too.
And we would be noted, also survey the DC jack design for If there are any new products in the future.
Here is this power supply's spec sheet: https://www.asus.com/Single-Board-Computer/Tinker-Power-Supply/specifications/
- DC 5.0V / 3.0A 15W
- 18AWG 150CM + Power Switch
- SCP, OVP, OCP, OTP, etc Power Protection.
- UL / CB / CE
- US DoE Level VI / EU CoC Tier 2
- LPS, etc lots of safety cert mark.
No, currently I don't think I have kind of this data, but I can provide the result from my simple test for refer:
- low current: avg. 4.99v
- high current: avg. 4.87v (CPU 4 core, 400%.)
About how we suggest to prevent the voltage drop.
Not much but can reference,
5V and full power as the spec. (e.g. some supply said 5v/2a (10W), but actually, when you asked v2a, you would see it may only provide 4.8v/2a)
We would suggest using 3A (15W) to prepare for the high loadings.
The cable with 20~18 AWG for large current power usage.
We also provide the best and official choice, the Tinker Power Supply.
And you can check what is the current voltage in the system.
Take a look with this node, "/sys/bus/iio/devices/iio:device0/in_voltage2_raw".
If it had been there and assumed the function was normal. You can refer below sample code (python) to get voltage.
DETECT_VOLTAGE = 4.65 #4.65
ADC_IN2_RAW_PATH = '/sys/bus/iio/devices/iio:device0/in_voltage2_raw'
with open(ADC_IN2_RAW_PATH) as in_voltage2_raw:
val2_raw = int(in_voltage2_raw.readline())
val_input = float(val2_raw / ((82.0/302.0) * 1023.0 / 1.8)) + 0.1
print('Voltage: ' + str(val_input))
if val_input < DETECT_VOLTAGE:
print('-- Low Voltage --')
print('The system may turn off due to low power input (input voltage below 4.65V), when this happens, please disconnect high power consuming peripherals or change to a qualified power supply.')
// In TinkerOS, you can find a service at "lib/systemd/system/voltage-detect.service" and similar codes "etc/init.d/voltage-detect.py".
How about try below method to get the actually current system Voltage?
that would more close with the true voltage. (But cannot get the current)
Also if measuring voltage between PSU and Cable, it would miss the Cable’s effect.
(if cable also cause the voltage drop…)