Charging an Inventor Hub via MacBook never finishes #647
Comments
|
What is the charge current with the not working USB port? |
Let me charge the Hub and come back. |
|
Actually, you should discharge the hub and come back. The charger chip in the hub will reduce the charging current as the hub nears the full point. So to see the actual charge current, the battery needs to be discharged below 8V or 7.8V or something like that. |
No charger attached
Hub connected to MacBook
|
|
Since it is ~500mA, it looks like it is detecting the port as a standard charging port and limiting charging at 500 mA. Maybe that isn't enough to ever trigger the full point? Everything other than that is controlled by the charger chip, so if it isn't getting to full, I'm not sure what else we could do about it. When the battery is nearly full, what is |
|
After the Hub was fully charged by Apple Charger. Plugged in the Apple chargerThe charging led is Off.
Connected to MacBookThe charging led is RED.
|
So it is still charging. The current should gradually drop and the charging should finish when it reaches 8.4V. |
This is what I thought too. Apple charger finished charging overnight, and the Hub connected to the MacBook did not finish charging overnight even when the Hub was previously charged 😞 Will give it a second try tonight and will report back. |
|
When it is this close to full, it should take (much) less than one hour to finish. |
Great, will give it a try tonight. |
|
Started charging via MacBook at 17:30 CEST with these values:
30 minutes later:
30 minutes later:
30 minutes later:
The official documentation mentions the charging time shall be approximately 2 hours. Here I am charging already charged Hub 😞 |
|
Here is the datasheet for the battery charger if you want to read about the I'm guessing that there is just some condition with this specific USB port that causes the chip to never get out of the EDIT: the trickle charge phase is when the battery voltage is very low. The constant-voltage phase is when the battery is nearing full. |
|
From the data sheet, it seems like we should eventually get a timeout fault because the charge current never reaches IBF (150mA?). The timeout fault should cause CHGOK pin to oscillate which should cause the hub light to turn yellow. But it isn't clear what resets the safety timer fault. |
|
I suppose you could also try with the official LEGO firmware and see what happens. |
|
I have tried the official LEGO firmware now (v1.4.01.0000-594ce3d). from hub import battery
from mindstorms import MSHub
hub = MSHub()
print("Battery Info:", battery.info())
print("Battery Current:", battery.current())
print("Battery Voltage:", battery.voltage())
print("Charging:", battery.charger_detect())
|
|
I think they may have changed the meaning of red/green in recent updates, so we should be sure it actually means the same thing as Pybricks firmware before drawing conclusions. |
|
also, does |
|
Or better, just copy/paste the literal output here. |
|
|
I have updated my original comment. |
|
so https://lego.github.io/MINDSTORMS-Robot-Inventor-hub-API/mod_battery.html |
|
and |
|
What the heck 😆 So it means even though they still charge the hub, they have a lower voltage threshold that is used to indicate the battery is fully charged by lighting the led GREEN. That is not bad actually, it makes sense - the user sees the hub is charged because it will probably not get charged more than it is. |
|
I think that on LEGO firmware, green means charging and red means done. You could discharge the battery or charge it fully using the working charger port to be sure. |
Fom what I observed in the past, it was RED when it was charging (battery was 50%). Now it is GREEN and the MS app reports 100% charge. Will discharge the battery and come back 😊 |
That would kinda be against common sense. RED usually means charging whilst GREEN means charged. Will test agan and confirm. |
|
Yeah, or maybe LEGO has seen the same problem and they use the voltage level for the indicator light now instead of the battery charger CHGOK signal. |
Yep, that is what I thought. Seems like the |
|
Discharged the battery a bit:
Connecting it to MacBook, the charging indicator goes RED as expected. Thus, GREEN means "fully" charged. |
|
I just had a look back at my reverse engineering notes and it does look like anything above 8.2V is considered "charging complete" in the LEGO firmware. However, 8.2V is only 75% according to the battery charger data sheet. |
How about making the indicator GREEN once the voltage reaches 8.3V? Also wondering, does that the current charging way reduce the battery lifetime? By charging the battery indefinitely even when the voltage is 8.35 mV, that cannot be good. |
|
Hmm... we were hoping that the charging chip would be smart enough and we wouldn't have to worry about things like this. Back to the drawing board, I guess. 🤔 |
dlech
added
hub: primehub/inventorhub
|
I am seeing values on Prime Hub with Pybricks similar to @lobodpav. In my case, the hub is connected to the USB port on my monitor, EDIT: It did eventually turn green, so maybe this particular case is fine. |
|
As mentioned in duplicate issue #700, I've now seen this when leaving a hub running overnight connected to a USB 2.0 port. The hub had 5 motors plugged in (not running) and a SPIKE color sensor with the lights on along with the default "user program running" status lights on the hub itself contributing to the 90 mA load. I logged the data during the time and graphed it:
We can see that we are in the constant-voltage phase of the charging cycle as previously thought. In this phase, the current is supposed to drop to below 150mA and then charging stops. But we can see the current never drops below 300mA so charging doesn't stop and the safety timer eventually kicks in and the battery starts discharging. I didn't capture the start of charging, but we can see it takes over 12 hours for the safety timer to trigger. |
|
The jump in the charge current in the graph could be explained by this from the data sheet:
Unfortunately, it doesn't go into any more detail about what "non-sync operation" is. Nevertheless, seems like a reasonable suspect for why the charge current would stall or reach equilibrium at this particular level. |
|
Could you add the charger type to your log post? Does it only happen on standard downstream ports? |
|
That information is not exposed in the Python API so we have no way of knowing what type of charger the firmware has detected. But assuming it was correctly detected, it is a USB 2.0 port, so should be detected as standard downstream. |
|
It looks like the battery current is always 90 mA for this load, whether it not it is charging. Does it remain 90 mA when unplugged? If so, where is that 300 mA going all this time? It would be interesting to see if we could measure the real current through the cable for comparison. |
|
I actually just did that while you were typing 😉. I've been running another experiment and the charge current measured by the hub is 335mA. The current measured by my USB power meter is 0.21A. However, the data sheet does state that what we call the "charge current" is the total battery current, not what is just coming in over USB so we shouldn't necessarily expect these to match exactly. We also should not assume that the "charge current" is calibrated correctly. |
|
Looking forward to seeing that experiment when it ends, and whether that 0.21A drops once the battery is full. |
|
I have repeated the experiment, this time with nothing attached to the I/O ports on the hub and all of the lights turned off to simulate the hub being "shut down". This time the battery current measured on the hub is about 15mA instead of 90mA. Also this time, it is starting with a not full battery so we can see the constant current charge phase before the constant voltage charge phase.
We can see that the "charge current" still levels off, this time at around 250mA. The USB power meter reads 0.07A at the end (and 4.91V). Comparing this to a similar graph from the data sheet, it seems like the current should be dropping much faster instead of leveling. Note that the data sheet capture is using a battery simulator, which is how the battery voltage is going up with 0 current before the halfway point on the time scale.
|
|
More observations: When the battery is "full" (8.348V for this hub) and I unplug the USB and plugin it back in, I get different results depending on the USB port used. When plugging into my computer, the battery indicator light shows charging (red) and the meter shows the port is at 4.88V. If I plug into a wall socket USB charger the battery status light on the hub show charge complete (green) and the USB meter measures 5.13V. The data sheet mentions that the charge current is also proportionally limited by the USB voltage, so this could be a factor as well. |
|
Another experiment, same hub, all lights off, no I/O devices, connected to USB charging port (wall socket type) so it charges with a max of 1.5A instead of 500mA. Also supplies voltage a bit over 5V as mentioned above. This time, the graph looks more like the one from the data sheet. The charge current actually starts dropping proportionally during the "constant current" phase then drops much more quickly during the "constant voltage" charge phase. Then we get CHGOK and the battery starts discharging.
|
|
Raw data for the record: RI hub battery charging logs 2022-08-10.ods and test program from pybricks.hubs import InventorHub
from pybricks.pupdevices import Motor, ColorSensor, UltrasonicSensor, ForceSensor
from pybricks.parameters import Button, Color, Direction, Port, Stop
from pybricks.robotics import DriveBase
from pybricks.tools import wait, StopWatch
hub = InventorHub()
timer = StopWatch()
hub.light.off()
hub.display.off()
while True:
print(
timer.time() // 60000,
hub.battery.voltage() / 1000,
hub.battery.current(),
hub.battery.temperature() / 1000,
hub.charger.current(),
hub.charger.status(),
sep=',')
wait(60000) |
Besides the improved light indication, does this also stop charging in the case where it never finishes above? (In order protect the battery by mimicing the same discharge behavior of the wall charger?) |
|
No, that has not been addressed. |
Environment
pybricks-micropythoncommit81d342d LICENSE: update copyright for 2022Replication steps
redLED light indicates chargingredLED never changes togreen(even after 24 hours) and keeps on being redredshall gogreenonce the battery is fully chargedWhen connecting the Hub to an Apple USB-C charger with the same cable, the charging led goes from
redtogreenimmediately (the hub is fully charged).The text was updated successfully, but these errors were encountered: