I have an LG OLED65B9‬‬ TV screen for four years. Lately, I began having trouble turning it on. Instead of powering on (from standby mode) the red LED under the screen would blink three times, and then nothing.

On the other hand, if I disconnected the screen from the wall power (220V), and waited for a few minutes, and then attempted to turn on the screen as soon as possible after connecting back to power, the screen would go on and work without any problems and for as long as needed.

When I tried to initiate Pixel Refreshing manually, the screen went to standby as expected and the red LED was on to indicate that. Two hours later, I found the LED off, the screen wouldn’t turn on, and after I did the wall power routine again to turn the screen on again, it indeed went on and complained that it failed to complete Pixel Refreshing before it was turned on.

I tried playing with several options regarding power consumption, and I upgraded webOS to the latest version as of April 2024 (05.40.20). Nothing helped.

I called service, and they replaced the power supply (which costs ~200 USD) and that fixed the problem. That’s the board to the upper left on the image below. Its part number is ‫‪EAY65170412‬‬, in case you wonder.

And by the way, the board to the upper right is the motherboard, and the thing in the middle is the screen panel controller.

(click image to enlarge)

May 19 update: A bit more than a month later, the screen works with no issues. So problem fixed for real. The LED blinks three-four times when I turn it on with the button on the screen itself. So the blinking LED is not an indication of a problem.

This is a collection of insights regarding lead-acid batteries, in particular those sealed batteries that are used in UPSes. Had it not been for my failed attempts to get a decent battery for my UPS, none of this would have been written. It was only when I asked myself why the UPS doesn’t maintain power nearly as long as I expected that I started to learn more about these batteries.

Batteries is far away from anything I do for a living. This is definitely not my expertise. Please keep that in mind. But as it turns out, there’s a lot to know about them.

Well, I think I’ll take that back: After a lot of playing with these batteries, my conclusion is that knowledge doesn’t help much. Run a test, see how long the battery holds up your computer, and that’s it. There doesn’t seem to be anything smarter to do.

There’s probably only one important thing to know about them: They should be fresh. That’s hardly new, and yet, that’s probably the bottom line. Lead-acid batteries discharge by themselves over time, and when they reach a certain level of discharge, they get damaged. Also, the discharge rate depends a lot on temperature. So a battery that has been stored in a hot place somewhere in a distant country for over a year is probably no good candidate for your UPS. The manufacturer’s timestamp is everything: It starts to seem to me that most batteries were more or less the same on the day that they left the factory. The difference is how much damage they caught during storage.

For a concise technical background, I recommend reading Power Sonic’s Technical Manual.

So without further ado, let’s go through my findings, in more or less random order.

A 7AH battery doesn’t really give 7AH

With lead-acid batteries, 7AH doesn’t meas 7A for 1 hour. Or 3.5A for 2 hours. Or any other combination, except for 0.35A for 20 hours. More about that below.

The amount of charge (and energy) that a lead-acid battery supplies until it’s discharged depends dramatically on the discharging current. The capacity printed on the battery is given for a 20-hours discharge, or using the jargon, 0.05C. That “C” is 7 taken from the 7AH figure, so 7AH are obtained if the discharge current is 0.35A. For larger currents, expect much less energy out of the battery.

This phenomenon is approximated by Peukert’s Law.

For example, my specific case: The load is 70W (at 142VA) according to the UPS itself. I’ll assume that the low power factor thing can be ignored, i.e. that the fact that the VA figure is twice the consumed power makes no difference. This low power factor is natural to switching power supplies, as they draw more current when the voltage is low, so their behavior is far from a plain resistor (unless specifically compensated to mitigate this effect). I’ll also assume that the UPS is 100% efficient on its voltage conversion, which is complete rubbish, but for the heck of it.

So for two 12V batteries in series it goes 70W/24V =~ 2.9A, which is about 0.4C (2.9 / 7 =~ 0.4). A ballpark figure can be taken from Figure 4 in Power Sonic’s Technical Manual, showing that the voltage starts to drop after about an hour, and reaches the critical value somewhere after an hour and a half. Note that I have different batteries.

Also from Table 2 of the same Manual, we have that the actual capacity of a 7AH battery, when drained with a 4.34A current, is 4.34AH (one hour). The current is higher than 2.9A, but given that the UPS isn’t really 100% efficient, it’s likely that the real discharge current is closer to 4A than to 2.9A. So that explains why the UPS said 1:12 hours when I updated the battery replacement date.

Many battery manufacturers supply datasheets with Discharge Characteristics Curves. Even better, if there are tables with Constant Current Discharge Characteristics (also referred to as F.V / Time specification). See Ritar’s datasheet for RT1270, for example. The numbers inside this table are the constant currents for each discharging scenario. Each row is the final voltage (F.V) per cell that is reached in this scenario, and each column represents the time it takes to reach this voltage.

It’s not clear at which voltage the UPS decides to stop discharging. Even though 1.60V per cell seems to be a recurring number in datasheets for the game over.  And on the other hand, I’ve repeatedly seen 0.35A (i.e. 0.05C) paired with 1.75V and 20 hours discharge in those F.V / Time tables. So it’s not really clear. Anyhow, finding a number that is similar to the intended current in the table can give an idea on how long the battery is supposed to last.

Obviously, different batteries behave differently on higher currents. I couldn’t find data on my “Bulls Power” batteries. So maybe they could meet the 7AH specification for a 20-hours discharge, and then perform really poorly with higher, real-life currents. No way to know for sure.

So what is the state of the battery after it has been discharged with less than 7AH? It’s still charged, as a matter of fact. A rapid discharge, which yields less than the full capacity is healthy for the battery. It’s when the full capacity is utilized with a slow discharge pattern that the battery can be damaged if it stays in that state for a long while.

Charging a lead-acid battery

There are in fact several ways to charge a lead acid battery (for example, this), but the common way to charge a battery is to feed it with a current of 0.3C (2.1A for a 7AH battery) until the voltage rises to above a threshold. Or to set a constant voltage (with a current limit) and charge until the current goes below a certain level. Then comes the second phase, which is the slow charging to 100%.

When the battery is full, a floating voltage should be applied to the battery. Each battery specifies its own preferred floating voltage, but they all land at around 13.5-13.8V. This is the correct way to maintain a fully charged battery: A small charging current compensates for the battery’s inherent discharge (typically around 0.001C, i.e. 7 mA for a 7AH battery), and the battery remains fully charged in a way that is best for its health.

Battery manufacturers usually state something like 10% discharge for 90 days or so. This corresponds to about 0.000046C, or ~0.3 mA for a 7AH battery. But in this scenario, the battery discharges against its own voltage, and not the elevated floating voltage (does it matter?).

Knowing the battery’s charge level

How does one estimate how much energy a lead-acid battery has? The answer is unpleasant, yet simple: There is really no way to measure it from the battery electronically. After reading quite some material on the subject, that became evident to me: There are plenty of papers describing exotic algorithms for estimating a battery’s health and charge level, and their abundance and variety proves that there’s really no way to tell, except for draining it.

Maybe the first question should have been: What is consumed when the battery gets discharged? For one, sulfuric acid reacts with the lead plates and become lead sulfate. When there’s no acid left, the battery is done. On the other hand, the lead plates themselves might deteriorate in the process. This can happen relatively early if the lead plates are partly damaged because of previous use (or abuse).

There is one way to measure the charge level that is considered reliable, which is measuring the open circuit voltage (OCV) after the battery has been disconnected for a while (some say a few hours, battery manufacturers typically require 24 hours). Letting the battery rest allows it to reach a chemical equilibrium, at which point the voltage reflects its charge level. This is surely true for a fresh battery, because the OCV reflects the specific gravity of the electrolyte, that is the concentration of the sulfuric acid.

As for batteries with some history, the picture is less clear, and I haven’t managed to figure out if the OCV voltages remain the same, and if the voltage vs. charge percentage relate to the original charge capacity, or the one that is available after the battery is worn out. The OCV measurementt covers the charge level in the sense of how much acid there’s left to consume, but will the lead plates hold that long?

For example, Power Sonic claims that the OVC goes from 1.94V/cell to 2.16V/cell for 0% to 100% charge respectively. As a 12-volt battery has 6 cells, this corresponds to 11.64V to 12.96V. These figures are quite similar to those presented by another manufacturer.

But what does 100% charge mean? 7AH or as much as is left when the battery has worked for some time? My anecdotal measurement of the batteries I took out from the UPS was 12.99V after letting them rest. In other words, they presented a OCV voltage corresponding to 100% charge, even though they had much less than 7AH.

So how does a UPS estimate the remaining runtime? Well, the simple way is to let the battery run out once, and there you have a number. Clearly, Smart UPS uses this method.

Are there any alternatives? In theory, the UPS could let the battery rest for 24 hours, and measure its OCV. This is possible, because most of the time the UPS doesn’t need the battery. But even my anecdotal measurement shows that a 100% charge-like reading doesn’t mean much.

For other types of batteries (Li-ion in particular), measuring the current on the battery, in and out (Coulomb Counting), gives an idea on how much charge it contains. This doesn’t work with lead acid batteries, because the recommended way to maintain a standby battery, is to continuously float charge it. That means holding a constant voltage (say, 2.25V per cell, that is 13.5V for a 12V battery, or 27V on a battery pair, as in SmartUPS 750).

As this voltage is higher than the OCV at rest, this causes a small trickle current (said to be about 0.001C), which compensates for the battery’s self discharge. Even if it overcharges the battery slightly, the gases that are released are recycled internally in a sealed battery, so there’s no damage.

Hence the recommended strategy for charging a lead-acid battery is to charge it quickly as long as its voltage / current pair indicates that it’s far from being fully charged, and then apply a constant, known and safe voltage. This allows it to charge completely slowly, and then maintain the charge without any risk for overcharging. Odds are that this is what the UPS does.

But that makes Coulomb Counting impossible: During the float charge phase (that is, virtually all the time) the current may and may not actually charge the battery.

Measuring the discharging curve

Being quite frustrated by bad batteries, I decided to go for a more direct approach: Instead of taking my computer down and pushing the battery into the UPS each time, I thought it would be easier and more informative to run a discharging test: I used my old Mustek 600 UPS to charge the battery, and then discharged it through a (cheap) 55W light bulb for a car’s headlight (which is intended for 12V of course). With this, I ran a classic lab experiment, recording voltage and current as a function of time. Like a school lab.

The first step is to charge the battery of course. I’ve discussed this topic briefly above, but what about my Mustek’s UPS? It takes a very easy and slow approach: With a partly discharged battery, it starts with an initial charging current of 0.4–0.35 A. This current goes slowly down as the battery’s voltage rises. The voltage goes up very slowly from 12.8V and eventually stabilizes at a voltage around 13.5-13.6V (depends on the battery). Charging a battery to a decent level takes 7 hours, but I went for a 24 hours charge before running a discharging test. Just to make sure the battery was really fully charged.

By the way, the Mustek UPS charges even when not powered on (but connected to power). When disconnected from power, no charging occurs.

Now to the interesting part: The discharging of the batteries. I made several tests, and they all yielded the same results, more or less. In all of these, I made accurate voltage measurements (with a Fluke) as a function of time. This is the plot of the last experiment I did, with a logarithmic x-axis, each ‘x’ mark on the plot is a measurement:

This experiment was done on one of the Bulls Power batteries.

I measured the current throughout the session: The light bulb drew 4.00 A in the beginning (corresponding to ~48W), and the currents remained above 3.8A during the first 20 minutes. So this can be considered a 0.55C discharge.

The first thing to note is that the graph fits the discharge curve for Ritar’s RT1270 for 0.55C during the first 18-19 minutes: The voltage goes down gradually, and drops about 0.04V/cell during the first 10 minutes. On the next 8-9 minutes, the voltage drop is about 0.05V/cell, also following Ritar’s curve.

But then it’s quickly downhill, strongly diverting from the expected graph. The battery collapses quickly at this point. I haven’t found a single reference to this behavior, but I suppose that it’s a result of aging. And/or deep discharge during storage.

Is this consistent with the fact that this battery held for 9 minutes in the UPS, along with one that behaves roughly the same? Maybe. The UPS reported a power consumption of 105W in that situation, so if I’ll assume 90% power efficiency, we have a current of 105 * (1 / 0.9) / 24 = 4.86A ≈ 0.7C. That’s somewhere between the graph for 0.55C and 1C. So with the steeper discharging curve of this case, it’s actually possible that the collapse began much earlier.

Other random takeaways:

• With this battery, it doesn’t matter so much at which voltage the UPS powers itself off. The last part’s slope is so steep, so it’s a matter of 30 seconds this way or another.
• A 55W light bulb is blinding and heating. Be sure to have it fixed in a way that prevents it from heating the battery and also make sure  that it’s literally out of sight, and that no visual contact will be needed with it as long as the experiment runs.
• Check the crocodiles’ or easy-hook’s resistance. In particular crocodiles can have a high an unstable resistance (0.1Ω is high in this context, because it causes a voltage drop of 0.4V).
• As it says in many information sources, lead batteries recover after a discharging session after some time of rest: After a day, I connected the battery to the bulb, and it began discharging at 11.8V, and falling rapidly.

Discharging curves, round #2

The saga went on, and I tell it in detail in the other post. The quick summary is: Being unhappy with the Bull batteries, I bought a pair of batteries from a company named Afik, and put them in the UPS. The results weren’t really impressing with these either, so I decided to replace the Afik batteries with something else. Eventually, I ended up with a pair of Vega Power batteries.

Unfortunately, I didn’t make any measurements on the Afik batteries before putting them in the UPS, mainly because I thought they would work, and end of story. So as things turned out, I obtained the discharging curve from the new Vega Power batteries before putting them in the UPS, and then I did the same thing with the Afik batteries only after they had been in the UPS for a few months.

This time I created an automatic test setting that allowed two readings per second, so the curves are more accurate and detailed.

Note to self: See new-computer/ups/lead acid batteries/discharge-tests-2/.

I used the same light 55W light bulb, which drew 4.0A at the beginning of the discharging test, and then went down slowly to about 3.5A towards the end of the test. More or less constant current, that is.

The colors of the curves in the graphs below represent which test they belong to:

• Red: Vega Power battery #1.
• Blue: Vega Power battery #2, first test.
• Magenta: Vega Power battery #2, second test.
• Green: Afik battery #1.
• Cyan: Afik battery #2.

Evidently, I obtained a curve from Vega Power battery #2 twice: Once after charging for ~24 hours (from as it came from the shop) with the Mustek UPS, and the second time after a total of ~48 hours from the state of the previous discharging session. The graphs below might imply that I got these two measurements swapped, but no, there’s no mistake about this.

Vega Power battery #1 was charged during 26 hours (from its initial state from the shop), and then 18 hours with a brief pause between the two charging sessions.

So to the first graph. Time in minutes on the X axis, and voltage per cell on the Y axis.

The curves begin one minute after discharging starts, and stop when the battery reached 10.0V (with 6 cells in the battery, that’s 1.67V / cell). I’ll show more details below about the first minute. As for choosing 1.67V as the end for discharging: The graphs for charging current around 0.55C often go this low in datasheets, so I suppose this shouldn’t damage the battery.

The first and obvious thing one can see is that the Afik batteries held shorter than the Vega Power batteries: 55 minutes vs. 80-87 minutes. That’s consistent with the fact that the Vega Power lasted longer in the UPS.

But as I’ve written in that other post, the UPS started to panic-beeping after 7:30 minutes with the Afik batteries, and then kept power up for another 15 minutes. Why did that happen? There’s nothing in the green nor cyan curves that offers a clue for the reason to the early panic. On the other hand, it’s evident that these batteries lost voltage quite rapidly after about 40 minutes, possibly going into “deep discharge”. That said, they didn’t collapse nearly as quickly as the Bull Power batteries. So there are definitely different levels of junk.

As for the Vega Power batteries, they performed surprisingly well on these tests. The shortest run was 80 minutes. Taking a gross average of 3.75A as the current, that means that the battery gave 5AH. Quite impressive. Also, according to Ritar’s datasheet for RT1270, that battery will reach 1.85V/cell after one hour if a current of 3.321A is drawn from it. Vega Power got to that region after 70 minutes with a higher current.

So the question is why the UPS started panicking after 28 minutes and cut the power very soon after that. Indeed, the current that is drawn from the batteries was higher inside the UPS. But why that sudden cut? Does it have to do with the curves’ bending at around 1.96V?

In fact, the reason that I repeated the first discharging test on Vega Power #2 (in blue) was that sharp bend. To my surprise, the bend went away on the second test (in magenta), but the battery reached the 1.67V point 7 minutes earlier (after a 48 hours charging). Why? Don’t know. Lead acid batteries are not supposed to have any memory.

In the next graph, I’ve removed the curves for the Afik batteries, and left only Vega Power’s curves. In addition, I’ve shifted the positions of these curves in the X axis. Namely, I delayed Vega #1′s curve by 9 minutes, and Vega #2′s first test’s curve 2:15 minutes. And we get this:

So it’s evident that both batteries ran according to an accurate discharging pattern for at least 45 minutes, and then things happened. Is this the start of “deep discharge”? Does this mean that discharging the batteries below 1.95V is a bad idea? Maybe this is what my UPS thought, and accordingly stopped after 28 minutes (which could be the same point, as it probably drew more current than this test).

Doesn’t the part where all three curves overlap look a little linear? I’ll come back to that below.

It also looks like the shifting I made in the X axis compensates for differences in the initial charging level. If that’s true, the charging levels of Vega Power #2 were nearly the same in both tests (slightly more charge after the second, 48-hours, charging session). But if so, why did this battery reach 1.67V faster on the second round?

And why was Vega Power #1 significantly less charged after a super-long charging session? Maybe an issue with the Mustek UPS?

The third graph is the same as the first, but with logarithmic X-axis.

The interesting thing about this representation is that it’s comparable with the curves that appear in some batteries’ datasheets. It’s quite evident that these curves are similar to those that are usually given for 0.55C.

The bends of the blue and red curves are more evident on this graph. Recall that they were obtained during the first tests of each of the Vega Power batteries. The pretty curve in magenta is the second run of Vega Power #2.

Finally, I discharged Afik battery #2 down to 1V, which is considered a damaging thing to do. But who cares, I have no plans for this battery anyhow. So here’s the curve:

Note that this is the same test and same curve as shown above, only that I display it in full here.

Transient responses

So far I’ve been looking at the curves during the actual discharging phase. But some possibly interesting things happen before and after that.

So first, what happens when the discharging begins:

Surprise, surprise, there’s an undershoot. Why? I’m tired of trying to even speculate. But it’s definitely a thing. And by the way, the initial voltages (i.e. with zero current) have no meaning in particular (?), because the batteries didn’t have enough time to stabilize after charging.

Note that the X-axis is given in seconds here. Not minutes.

And here’s a close-up on the same graph, just to make the point that the undershoot occurred on all curves:

The next thing to look at is what happens when the discharging process is stopped. I did this by disconnecting the light bulb, so the current went down abruptly from 3.5A to zero. This occurs at time zero of the following graph.

Recall that Afik #2 (cyan) went down as low as 1V/cell, and yet it recovered quite similarly Afik #1, which didn’t go through this minor trauma.

It’s a well-known fact that lead-acid batteries recover after a high-current discharge and resume their capability to provide energy, even if they aren’t charged inbetween. This graph shows this phenomenon.

It’s worth looking at the first couple of minutes of the recovery. This is just a zoom-in of the previous graph (and with time axis shown in seconds instead).

Aside from the immediate jump of the voltage when the light bulb is disconnected, there’s a smooth and yet fast rise in the voltage.

Another thing that is evident from this graph, is how much faster the Afik batteries went down towards the 1.67V level, compared with the Vega Power batteries (this refers to the time period before zero).

Is a DC test legit?

This test is made with a DC current, but the UPS discharges the battery with an alternating current: As the UPS feeds the computer with an AC voltage, the delivered power as a function of time is a more or less a sinus function (if the UPS produces a sinus wave). At any time, the energy that is delivered to the computer is drawn from the battery. The UPS barely stores any energy in its own circuits. So the current from the battery is also a sinus, more or less.

So does a test with a DC current reflect the situation with an alternating current? Is it good enough to rely on the average power, and derive a DC current from that? According to Okazaki et al. (“Influence of superimposed alternating current on capacity and cycle life for lead-acid batteries“) the rippled current doesn’t change the battery’s capacity at all. They tested a current of I=I₀(1+sinωt) at 0.1Hz to 4 kHz and found only negligible differences (1%). So the DC current test seems to be accurate.

Linear discharge curve?

I’m going back to Vega Power’s second graphs, where I aligned three graphs by shifting them in the X axis. Let’s look at this graph again, but now with a dash-dotted line which represents the first-order linear regression of the segment between 20 and 40 minutes:

So there’s no doubt that the Vega Power batteries’ voltage went down linearly as a function of time for a while. Maybe it was the divergence from this linear descent that made the UPS panic after 28 minutes (once again, the UPS drew a higher current).

Looking at Afik’s curves, they don’t appear linear at any stage. Maybe that’s why the UPS became nervous very soon, but then nothing dramatic happened, so it kept running.

What about the Bulls Power battery? I didn’t show the graph with linear time scale above, but here it is:

Once again, the linear regression is shown with a dash-dotted line. There are fewer measurement points, but it’s quite clear that the voltage descends linearly for a while.

The slopes of these dash-dotted lines are -2.09 mV/minute for the Vega Power batteries, and -2.86 mV/minute for Bulls Power.

What’s the explanation for this linear behavior? Reiterating that lead-acid batteries is not my expertise, I’ll give it a shot:

At the first stage of discharging, the voltage curves seem to be governed mainly by the concentration of sulfuric acid close to the lead plates. As the acid is consumed by the discharging process, the supply of new acid depends on motion of ions between the two plates. A high current means a quick rate of consumption that works against the motion of ions, some of which depends on plain diffusion. So the result is a lower concentration of acid, hence a lower voltage. This, I suppose, explains why the curves go down faster for higher currents, and why the battery recovers quickly afterwards.

But here’s the thing: When the current is constant, the gradient of the sulfuric acid’s concentration stabilizes inside the cell after a few minutes. The motion of ions gets into a stable pace. However, as the current flows, sulfuric acid is consumed. This brings down the concentration of acid overall, even though the differences (gradients) remain the same. The current is constant, and the sulfuric acid is consumed against electrical charge that passes through the battery, so we have a linear slope.

At some point, the curve breaks off from this pattern, and begins diving faster. A possible reason is that the lead plates begin to lose effective surface area (blocked by lead sulfate?), so the current needs to go through a smaller surface. This is equivalent to a larger current, with the due implications on voltage drop.

This seems to be what is often referred to as “deep discharge”. This is a term that is loosely used with reference to drawing too much charge from a battery. Everyone seems to agree that this phase reduces the battery’s capacity on the following cycles, but when does it start? Is it when the curve diverges from the linear pattern? Or when the voltage gets to the level that the manufacturer suggests avoiding?

Academic material on the topic is also scarce (for example, this paper), but it seems like this phase occurs when the lead plates start to take their impact. As evident from the graphs shown above, this phase is rather unpredictable. Even though lead-acid batteries are said not to have a memory effect, that seems to be true until it comes to the lead plates themselves. They remember.

It looks like Smart UPS takes the linear slope approach. Or maybe it looks at the slope of the voltage as a function of time. As long as sulfuric acid is consumed, it’s OK, but when the lead plates begin to deteriorate, that’s time to beep like crazy. This strategy makes a lot of sense for a long battery life, but less beneficial when power outages are rare, so who cares if the battery gets a small hit every few months. But all this is my speculation on how the UPS makes its choices.

Afterthoughts

So what have I learned from all this messing around with the batteries? Not a whole lot of relevant information, I’m afraid. Invented in 1859, lead-acid batteries are easy to manufacture and easy to use, but there doesn’t seem to be a simple theory that accurately describes their behavior. As my own anecdotal experiments show, even the same battery won’t repeat its own discharging curve twice.

Maybe it was because I tried low-quality batteries (or are they?) and inaccurate apparatus for charging the batteries (the Mustek UPS). On the other hand, it’s difficult to find written material that describes the behavior of these batteries, even under lab conditions.

The state of car batteries is often tested by measuring the “cranking current”. This is the huge current when the car is started. This is a crude and indirect measurement of the lead plates’ resistance, which I suppose gives some indication of the battery’s condition. Does it ensure that your battery will hold for the next 12 months? Good luck with that.

Startup idea

The main conclusion from all this rambling is that the only way to know how long a battery will supply power is to fully discharge it. That is, down to a reasonable level that doesn’t harm it. On the other hand, a UPS should be able to give an accurate estimate of how long time it can hold up the computer, so that its user can decide when it’s time to replace the battery or batteries. Plus, the UPS needs to know this for the purpose of shutting down the computer gently a few minutes before it’s game over.

Smart UPS has a feature called “calibration” which does exactly that: It puts the computer on the batteries and discharges them until they reach the lowest acceptable level, and then resumes normal operation. The problem is that if the main power goes out at that moment, there’s nothing to hold up the computer with. So this has to be initiated by the user every now and then.

Solution: Make a UPS with say, four batteries, each of which is connected independently to the UPS’ power conversion circuitry. This way, the UPS can initiate a full discharge test on one of these batteries while the others remain fully charged. At the worst moment, the overall capacity will stand at 75%.

These discharge tests can be initiated automatically by the UPS for each of the four batteries every couple of weeks or so. This way, the UPS can give an accurate number for how long the UPS will hold up power.

This allows the user to decide when it’s time to replace the batteries. It also makes it possible to replace the batteries gradually, without turning off power. And the UPS can also inform the user if the new battery was worth the money.

Will this startup work? I doubt it. The vast majority of people just buy a UPS and believe it will do the work. They realize their mistake when the power goes out for more than two minutes, and buy a new UPS instead. Replacing lead-acid batteries separately? Come on.

This post continues my notes on Smart UPS 750, three years later, when it was time to replace the batteries (because they barely held for 13 minutes). It should have been simple, but if I wrote this lengthy post about it, there was clearly something going on. I’ve also written a separate post on general insights on the theory behind lead-acid batteries.

Note that UPSes and their batteries is not my field. These are just my notes as I found my way through. Also, I’ve added to and modified this post several times, so there are definitely inconsistencies in my actions and conclusions, because I learned as I went.

So for short, the main takeaways are these:

• Update the time of last battery replacement with the UPS’ front panel interface (somewhere under Configuration). This makes the UPS realize there are new batteries inside, which changes the way it calculates the estimated runtime.
• Two standard 12V / 7AH lead acid batteries can be used instead of APC’s original battery pack. But check that the terminals are 6mm wide. There are mainly two kinds of terminals: F1 (4.75 mm wide) and F2 (6.35 mm wide).
• The “battery fill” percentage is close to meaningless.
• The displayed battery runtime is not reliable.
• Every now and then, yank the power cord and see how long the UPS lasts. Expect surprises both ways. Battery calibration doesn’t help much.

And now, the deep dive.

Replacing the batteries

The original replacement battery for this UPS is RBC48. But not only is this pack horribly expensive, it’s also hard to find (and maybe they’re not manufactured anymore?).

The process for battery replacement with non-APC batteries is shown in this video, but it’s really not complicated. Yank off the front panel, then the pull down the metal panel behind the former, and pull out the batteries gently. Use the harness that connects the two existing batteries on the new ones, push them in and you’re done. Plus some packing tape to keep the two batteries together.

However the original batteries’ contact terminals are about 6mm wide (F2), contrary to the ones on the battery I bought (F1), which were considerably smaller. So even though there was no problem connecting the batteries, it wasn’t all that reassuring that the contacts were smaller.

This is a picture taken from above, showing the original pair of batteries I pulled out from the UPS (click to enlarge):

The blue thing in the middle contains a fuse, and the black connector at the top mates with the UPS.

But when I powered up the UPS, the expected runtime shown on the display was just 13 minutes, even though the charge level appeared as 100%. I was surprised to see a 100% charge level on batteries that were just installed, and even more disappointed with the expected runtime. Could it be that bad? Both APC’s runtime chart and my own simple energy calculation (see below) pointed at one hour at least with the load I had. And it didn’t improve after letting the UPS work for a few hours.

My first though was that I had been sold exceptionally junky batteries. But I bought them at a reputable electronics shop, and they carried a timestamp indicating they were fresh (but see below, they were actually junk).

And then it occurred to me that I should tell the UPS that I had replaced batteries. So I went to the part in the UPS’ configuration menu for setting the month and year of the last battery change, and did that. And to my surprise, the runtime was adjusted to 1hr 12 minutes right away. There a few posts out there (this, for example) on how to “reset the battery constant” manually. It seems like this relates to the same thing.

Cute, I thought. But is that figure correct? So I let the UPS run on battery for a while. The estimated runtime went down in pace with the wall clock, but then suddenly, after 23 minutes, it took the power down.

So I reconnected the UPS back to power, and let the battery charge until it reached 100% again. At which point it reported:

$ apcaccess
APC      : 001,027,0652
DATE     : 2021-08-29 20:21:36 +0300
HOSTNAME : thehost
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : theups
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2021-08-29 18:30:15 +0300
MODEL    : Smart-UPS 750
STATUS   : ONLINE
BCHARGE  : 100.0 Percent
TIMELEFT : 23.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 300 Seconds
ALARMDEL : 30 Seconds
BATTV    : 26.6 Volts
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000008
MANDATE  : 2018-05-22
SERIALNO : AS1821351109
NOMBATTV : 24.0 Volts
FIRMWARE : UPS 09.3 / ID=18
END APC  : 2021-08-29 20:22:01 +0300

Smart UPS or what? If the battery died after 23 minutes last time, how much has it left when fully charged? Let me think… 23 minutes!

And yet, that sounds way too short for a new battery. More than 24 hours later, the same runtime estimation remained, going up and down a minute or so occasionally. So that’s that.

It could be correct, however. The way to find out is to try again after a month or so. For that, there’s battery calibration. Which for my UPS means “let the battery drain and measure its way down until it’s empty”. See my follow-up note on that: It’s more or less like unplugging power from the UPS, but less helpful it turns out. Note that the load is said to lose power at the end of this process, even though that didn’t happen to me. So the computer needs to be taken down safely, and then held in a state where a power failure won’t hurt (e.g. stuck in some boot menu). This way, it remains as an electrical load, but nothing bad happens when the power goes down.

Battery calibration is launched from the front panel menu as well. Why the best way to calibrate is to yank the power cord is explained in the follow-up note below.

Make sure the batteries are equally charged

Before connecting a pair of batteries in series (as in my case), it’s a good idea to charge them separately, if possible. That’s true in particular if a discharging test is made immediately after installation. Otherwise, differences in the charging levels may result in a deep discharge of one of the batteries. It’s the same principle as not mixing different batteries in any electronic device.

Alternatively, wait for a while (24 hours?) before the first attempt to discharge the batteries, so both batteries reach the same level by virtue of the floating current.

Otherwise, how can it go wrong? Say, for example, that the UPS stops discharging at 1.7V/cell, which is a rather conservative limit. This means 10.2V for a single battery. But if this is a pair of batteries, this means cutting off at 20.4V. If one battery is still before its steep downhill phase, it can be giving 12.0V. As a result, the other battery will go down to 8.4V when the discharging stops. That’s 1.4V/cell, which isn’t a good idea, except for with a high current discharge. In the datasheets, all discharge curves end at higher than 1.5V/cell, except possibly for with the higher currents.

A note on power consumption

It’s quite obvious that the computer’s power consumption depends on its activity. But as it turns out, the power consumption is higher before Linux’ kernel is loaded.

More specifically, when the computer is on the GRUB menu, the UPS reports 105W / 157VA. One could argue that this is as idle as the computer could be. But then, when Linux’ kernel has been loaded, and it prompts me for my disk unlock password, the power stands at 65W / 120VA. After Linux has booted completely and the desktop is up, it’s 70W / 127VA. So the Linux kernel surely does something to reduce the power consumption when it kicks off.

When compiling a Linux kernel with 12 processes, the power consumption goes to 165W, 217VA.

It’s quite evident that the power factor improves as the power consumption increases. This is in line with Corsair’s promise to attain power level of unity at full capacity (which is 850W, a long way to go).

I run all my battery tests with the computer on GRUB. One has to pick one scenario, and this one represents a computer under moderate load. Whatever that means.

Why a battery drain test is necessary

It’s not clear what my Smart 750 UPS did with the batteries when recharging after they were completely empty. Coulomb Counting is irrelevant on lead acid batteries, because they are constantly discharging. The battery is supplied with a “float current” while being fully charged to keep it in that state.

Besides, there are several factors that influence the battery’s discharging curve. It might discharge nicely for a while, and then suddenly the voltage drops abruptly because the lead plates are worn out. The only way to know about this is to reach that point.

Another factor is that even when the UPS reports that the battery is 100% full, it may still accumulate charge for a long while after that. The UPS might consider the battery full and provide it with a “floating current” but in reality it’s still charging the battery very slowly. A real discharge test should be made no sooner than 24-48 hours of charging.

Follow-up: Recalibrating the battery after two months

Being suspicious about the 23 minutes estimate, I took the computer down after running 76 days (on 14.11.21), kept it powered on so it would load the UPS, and ran a calibration test on the UPS. There’s nothing special about those two and a half months, it just happened to be a convenient time.

During those 76 days, I had monitored the UPS’ answer to apcaccess, and it was steady: The battery voltage remained between 26.8V and 27.0V, and the running time remained around 23 minutes. The UPS didn’t change its mind.

So about the calibration test itself: I started it from the front panel, under the Test Menu, and it read “CalibrationTest in Progress” (the missing space as on the screen). The UPS beeped just like when it’s on battery because of a power loss, and it hummed accordingly. After 20 minutes it went back to main power, claiming to have 15 minutes left. That’s it. It didn’t reach the stage of beeping rapidly, and neither did the power to the computer go off at any time.

At this point I yanked the main power cord, and let it run out. It kept going for another 5 minutes (despite the promise) and then beeped rapidly. 30 seconds later, power went off.

So all in all, it ran for 25 minutes before it died out. The 23 minutes estimate was quite accurate.

Conclusion: Don’t bother calibrating. Just yank the power cord, and measure time.

The third important takeaway is that those “Bull Power” batteries are more like bull-something-else, and I should schedule another battery replacement in a year or so.

And here comes the really funny part. After letting the UPS recharge fully, I checked it again:

$ apcaccess
APC      : 001,027,0652
DATE     : 2021-11-14 15:19:02 +0200
HOSTNAME : thehost
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : theups
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2021-11-14 13:50:25 +0200
MODEL    : Smart-UPS 750
STATUS   : ONLINE
BCHARGE  : 100.0 Percent
TIMELEFT : 34.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 300 Seconds
ALARMDEL : 30 Seconds
BATTV    : 26.8 Volts
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
STATFLAG : 0x05000008
MANDATE  : 2018-05-22
SERIALNO : AS1821351109
NOMBATTV : 24.0 Volts
FIRMWARE : UPS 09.3 / ID=18
END APC  : 2021-11-14 15:19:02 +0200

Is this a smart UPS or what? It just had a calibration cycle which ended with losing power after 25 minutes. How could it estimate 34 minutes now? Maybe if I try again I’ll get 34 minutes? And if this is because the PC consumes less power when Linux is running, why was it only 23 minutes before?

Don’t know. I’ve played with this enough.

Second replacement, 16.4.23

I wasn’t happy with those “bulls” batteries, so I went for an early replacement of these. It turns out that it’s quite difficult to find batteries that are anything but a complete no-name. I barely able to get my hands on a Ritar. And when I say barely, I mean that I managed to get batteries from a local store. This shop pretends to have its own brand, with a battery labeled AK12-7. But I got a photo of a shipping bill, which indicated that the batteries are manufactured by Ritar. So I went for a pair of those. On the invoice I got from the shop, it says RT1270 (this is the datasheet).

According to the datasheet, the discharge time at 0.55C (see discussion about discharge rates in my separate post) should be one hour. My test ran at 105W, which is grossly 105W/24V =~ 4.4A, which is about 0.63C. So I should have expected 50 minutes or so.

These batteries have small (F1) contact terminals too. I didn’t even think about checking that before I ordered them, actually. But the datasheet says that the battery comes with both F1 and F2 terminals.

I’ll skip to the bottom line right away: These batteries were junk, much worse than the previous ones. It’s plain fraud to call these batteries RT1270. Or maybe it has to do with the timestamp on the battery, which says “201022″. What does it mean? Judging from another battery from the same manufacturer (but different model), which had the timestamp “221215″, the new battery in the UPS was manufactured in October 2020. That could explain things.

So to the story: First I tested the old batteries. I put the computer on the GRUB menu and yanked the power supply from the UPS. Actually, I aborted the first experiment and let the batteries refill on the first attempt. The reason was that the (Western Digital) hard disks made the noise of (proper) activity, so I guess they were doing some kind of self-maintenance or something. I suppose they should be able to take a power loss in the middle of whatever they were doing, but I didn’t want to push my luck. So I just waited long enough, and then they went silent again.

The UPS went down after 9 minutes. Its estimation prior to the test was 12 minutes. The estimation was not bad.

I replaced the batteries with the Afik (Ritar) pair (a.k.a. junk), updated the time of last battery replacement on the UPS, and turned it on. Something was apparently wrong. The UPS was connected to proper power supply, and yet the computer didn’t switch on properly: It powered on, and after a few seconds it had some kind of reboot. It wasn’t clear what the problem was. It could also be because of a problematic USB hub, which tends to irritate the computer (partly because it has its own power supply).

At a later stage I discovered that the BIOS had been reset. Maybe because the computer had been powered off for a relatively long time. How did I notice? Because the CPU fans made more noise than usual, and the CPU’s temperature was lower than usual. I’ve changed the settings in the BIOS to silence the fans somewhat (within safe limits, of course). Plus the RGB sequence of the LEDs inside the computer stopped working. Should I change the BIOS’ battery too?

What I did next was a bit random, but at some point the UPS requested me to confirm that the battery had been replaced.

I took out the battery and pushed it in again. Maybe a loose connection? Who knows. Eventually, I connected the UPS to power, turned on the computer, and all ran fine.

The UPS said that the battery’s charge was 100% and promised all kinds of battery times (mostly around 50 minutes).

I then ran a battery test again. It lasted 5 minutes. When the UPS went on again, it gave the battery 28% and promised 14 minutes. Not so smart UPS.

So I let the battery load to 100% again (that took about 90 minutes), and ran a second battery test.

Bottom line: The UPS promised 49 minutes, in reality it held 11 minutes. This promise made sense, as it was probably based upon 0.63C. No chance in the world that this is an RT1270. Not a decently fresh one, anyhow.

So the old batteries, which I considered new held held 23 minutes when they were new, and 9 minutes after roughly a year and a half. These new batteries held 11 minutes as new!

Restarting the UPS, it reported 0% battery (make sense, doesn’t it?) and no 0 minutes runtime. After getting fully charged, the UPS promised 17 minutes. But that was with Linux running, so the power consumption is lower than the test. So it’s a reasonable estimation for a horrible battery.

Conclusion: I need to replace the batteries again, within a year. The computer shuts itself down after 5 minutes, so I guess it will be fine, but this is ridicolous.

Strategy for the next time

After two fiascoes, I’m changing strategy. So these are things I’m going to insist on:

• The marking on the battery should belong to a company that has a more or less proper website, from which I can download a datasheet.
• The datasheet should include discharging characteristics, either in the form of curves or tables, preferably both.
• The battery’s model code, as it appears in the datasheet, should be printed on the battery.
• If the battery is marked with the name of a local importer, it’s by far not as good, even if the importer publishes a datasheet that is possibly identical to the one of the manufacturer.
• The manufacturing date of the battery should be marked on the battery. It should be easy to figure out what it means, and the battery should be fresh of course.
• Prefer an F2 terminal
• Reputable brand is a bonus.

The rationale: A datasheet with discharging characteristics is a commitment. If a large company buys 1000 batteries, and tests a few samples just to find out that they don’t meet the specs, a hefty lawsuit may follow. No sane battery manufacturer will take that risk if it can’t ensure that their batteries perform well.

I couldn’t find such a datasheet for “Bulls Power”, and surely not for that Afik piece of junk. The latter was probably manufactured by Ritar, but not with their commitment.

Not going to insist on: A known brand. Ritar batteries are unavailable here at the moment, an Yuasa’s batteries cost a fortune. Their datasheet shows discharging graphs, of course. But no tables.

But more than anything, it seems like it’s a matter of age. I don’t think anyone manufactures really bad batteries to begin with. I speculate that those junk brands buy old batteries from good manufacturers, and market them with a different name, at a low price.

Who to buy from

Obviously, web shops are the easiest options. If they cooperate with sending me photos of the battery (see below). If not, go for bricks and mortar electricity shops (Erco, for example). Also consider shops and repair shops for motored toy vehicles for small kids. The search word in Hebrew for that is ממונעים (which means “motored”) but is somehow a collective term for these toys.

Is this a Covid-19 thing?

I called up Lion Electronic‘s sales (a company I consider reputable) for a couple of Yuasa batteries (200 NIS each, April 2023), and I was told that they won’t sell me two batteries at that price, because they are imported specially, and that has an extra cost.

My next hope was to get an Aokly 6FM7/6FM9, which are quite available here. However, as of April 2023, two different suppliers told me that it had no manufacturing date printed on it. Which is really weird. So this manufacturer is irrelevant.

I made other significant attempts to get a battery that meets the above criteria in May 2023, and failed: Every time I asked for a photo of the battery and its timestamp, I got no response, or a rather negative one. I got online purchase orders canceled twice while attempting to buy a CSB battery from an online shop, which is an importer of this battery. After talking with someone at the company about manufacturing date, and putting that request in the comments of the order, the company canceled the order, claiming that they don’t work with end customers (so why was it listed on the website?) and the batteries were delisted from the website. Trying to get the same battery from a web shop (that is, from the same source, but indirectly), I got the order canceled again, with the supposed reason that the minimum purchase for resellers is 10 units.

And there were several other attempts that ended with the other side simply not cooperating with sending me a couple of photos.

Given this rather odd picture, I speculate that there was a lot of batteries that got stuck in storage, somehow related to Covid-19. And now the manufacturers need to get rid of a whole lot of old, and hence damaged batteries. That’s the best explanation I have to all these batteries with no date marking, plus a lot of weird behavior.

My decision was hence to stop my attempts to replaced the batteries in my UPS for six months, and try again somewhere towards the end of 2023.

Third battery replacement, 17.12.23

I went into Erco‘s shop in Kiryat Ata, and was offered a couple of Vega Power NP12-7 batteries. Never heard about that brand? Neither have I. Neither did this company have a reassuring Internet footprint. But the batteries had an an engraved timestamp saying 10/08/2023 and they had F2 terminals. So I bought a couple of them, at a price of 120 NIS, VAT included. Cheap, in other words.

And the answer to my previous question: Yes, the lack of fresh batteries was most likely a Covid-19 thing.

I ran a detailed discharging test on these two batteries, which I write about in that separate post. Spoiler: The discharging test doesn’t say too much about how the batteries will behave inside the UPS.

First, I wanted to check the situation of the Afik batteries that were already inside the UPS. I brought down the computer to where GRUB waits for prompt, so the UPS reported power consumption was 105W / 150VA. At this point, the UPS promised 12 minutes.

So I yanked the power cord. The UPS began panic beeping after 7:30 minutes, stating 3 minutes were left, which dropped down to 0% and 0 minutes quite soon. Contrary to its pessimistic estimation, the UPS kept up the power for quite long after that, so the total time with power ended up at 22:00 minutes.

Say what? The same batteries held 11 minutes when I first put them in the UPS, and now the time doubled?!

If I don’t want to develop mysterious theories about what happens inside the battery, the explanation could be that the battery was far from being fully charged when I tested it a few months earlier: The UPS claimed that the battery was 100% full after 90 minutes, but it’s quite possible that this estimation was anything but accurate.

It’s also worth citing Power Sonic’s Technical manual: “By cycling the battery a few times or float charging it for a month or two, the highest level of capacity development is achieved. Power-Sonic batteries are fully charged before leaving the factory, but full capacity is realized only after the battery has been cycled a few times or been on float charge for some time”. This is written about another lead-acid battery of course, but maybe it’s a thing that a few months inside the UPS does the battery good.

I replaced the Afik batteries with Vega Power’s. These batteries had been separately charged with another UPS for 48 hours each. After updating the battery replacement date on the UPS (i.e. telling the UPS that there are new batteries inside), the UPS initially promised an uptime of above an hour, and then swayed along until it gradually stabilized at 49 minutes.

Yanked the power cord. All was good and calm until panic beeping started after 28:15 minutes, after which the power went out just a few seconds later. Boom.

The computer was stable on the GRUB menu throughout all this.

So what’s the verdict? I don’t know. The discharging tests that I ran on both pairs of batteries made things even more confusing: Vega Power performed really well, and Afik didn’t worse, but not much worse.

The only clear conclusion is that a UPS discharge test is required every now and then. There’s no way around this.

Repeated discharging test, 22.3.24

Three months later, I ran the same discharging test on the Vega Power batteries. The panic beep began after 22:10 minutes. At 31:30 minutes, the panic beep went off, and then it went on and off sporadically as the UPS’ estimation for remaining time fluctuated between 3 and 6 minutes. At 33:50 minutes the panic beep became steadily on again, and at 34:20 the UPS went off.

In short: Three months of floating current added 6 minutes to the battery time. And an even more confused ride as the battery discharged.

One more discharging test, 20.4.25

A bit more than a year later, yet another test on exactly the same battery. There had been no power interruptions inbetween, so this was the first time the battery discharged. So with the GRUB menu on, the UPS claimed its load as 105W and 150VA, promising 34 minutes. The UPS held power calmly for 22 minutes, with the promised remaining time decreasing from the original 34 minutes in pace with the time elapsed. But after 22 minutes, the panic beep went on, the promised time showed one minute, and it didn’t hold even that. Power off.

In summary: One year later, the battery had lower capacity, but still quite reasonable. The UPS itself, however, gambled on the last figure it had at hand.

Forth replacement, 28.6.25

I got two Yuasa NP7-12 from Batteriexperten as their price was lower than others with a clear margin (about $38 each). Small terminals (F1, unfortunately, but there were no F2 available anywhere near), both marked 24110435, probably meaning they were both ~8 months old, which is reasonable.

Measured voltage before connecting to anything (OVC at equilibrium), room temperature:12.857V on one battery, and 12.863V on the other. With a 6 mV difference, it’s safe to assume they are equally charged. So no need nor point pre-charging them separately. Being an AGM battery, this indicates a charge level somewhere between 90-100%, in line with what one would expect from a battery of this sort and age. In other words, it’s probably fresh and in good shape.

I put the batteries inside the UPS and let it run for 7 days so that they would be in good shape for the test. Which I ran on 6.7.25.

I went for the same GRUB menu scenario, however the UPS reported 120W / 157VA this time. This is higher than the other tests, because I ran the test with a different monitor, which eats more power. The promised run time was 44 minutes (a wild guess, once again, because the UPS didn’t know what’s installed).

When yanking the power cord, the UPS raised its power measurement to 135W / 202VA, and the time estimate immediately went down to 37 minutes.

After 29 minutes, the estimation was 13 minutes left. Panic beep at 33:30, power down at 34:10 (40 seconds later). That’s the best result so far, and not all that off the estimate after the power cord was yanked. So yay to Yuasa. Let’s see how they hold with time.

After quite a while of working perfectly well, the mini HDMI2AV module I have (in the picture above, mentioned in this post) started producing an unstable picture, and in the end a completely garbled one. It took some time to nail down this specific component in the foodchain, because there was also an HDMI splitter involved.

The problem, as it turned out, was that this module takes voltage from the HDMI plug, if such is available, instead of the dedicated power plug. In my specific setup, it seems like there was some voltage was available, but not enough to drive the device — because the HDMI plug was connected to the HDMI splitter. I suppose some internal power supply switch went into some not-here-not-there kind of situation, and eventually got some permanent damage. The other HDMI2AV unit I have didn’t work either in the same conditions, but probably didn’t reach the point of permanent damage (so it’s working right now).

On an HDMI connector, Pin 18 is +5V, minimum 55 mA, intended originally to feed the monitor with voltage even if it’s shut off, so its DDC (EDID) information can be obtained. Some devices (e.g. cheap HDMI splitters and HDMI to AV converters) might use this voltage instead of the supplied external voltage in some cases.

Not all cables conduct this pin. It’s therefore advisable to check the cable before working with it, when the setup is more than just a direct connection. It’s not easy, even with a multimeter. Pushing a thin wire into the tiny holes at the front may give contact with the relevant pin, but this isn’t bulletproof. Possibly try with an HDMI/DVI adapter (pin 14 on a DVI connector is +5V). Or test with a device that is known to rely on this voltage (e.g. this HDMI2AV module).

The solution in my case was to replace the HDMI2AV module and all cables with such that don’t let the +5V wire through. In particular, it seems like the cable to the TV set (via HDMI) that went to the HDMI splitter (which connects to the HDMI2AV module on its other output) was the issue.

So the procedure is simple (cited from manual, page 7, “Pairing”):

1. Turn the ignition on.
2. Make sure the Bluetooth feature of your phone is turned on.
3. Start the pairing procedure on your mobile phone.
4. When prompted for a passkey, enter 1234 on your mobile phone

The crucial hint is that nothing is expected to happen in the “Phone” any setup menu, as shown in many video tutorials.

So on an Android phone, open Settings > Bluetooth and make it search for devices. Once it finds it, enter the 1234 passcode (it’s was actually suggested, that and 0000. So it was 1234). Don’t expect anything to happen on the car radio’s side nor the dashboard display until the phone is paired.

I managed to pair two phones (the manual says there are up to five allowed).

$ xrandr --verbose

which outputs a lot of information about the display, in particular the EDID information obtained from the monitor. Among others, it’s a detailed listing of the video modes that the monitor is willing to accept. These modes are usually the standard VESA graphics modes, but there’s no guarantee that they are. But in reality, they are probably all industry standard, in particular those repeating themselves in the different dumps.

Also in reality, most monitors will display anything thrown at them, as long as it makes sense (or not) even if the graphics mode doesn’t appear on the list. After all, no monitor manufacturer wants the screen to be black when the competitor’s monitor shows as image.

So here are two such dumps. The first one is from my Lenovo Yoga 2 13″ (non-pro) laptop connected to a Dell P2415Q monitor, so the first set of data relates to the laptop’s own screen, and the second set to the much better external monitor (which goes up to UHDTV at 60 fps).

The second set is just my desktop, which is connected to a Samsung 23″ LS23ELDKF (a.k.a LED XL2370HD) monitor.

So the Laptop first:

Screen 0: minimum 320 x 200, current 5760 x 2160, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (0x47) normal (normal left inverted right x axis y axis) 293mm x 165mm
 Identifier: 0x43
 Timestamp:  3827058
 Subpixel:   unknown
 Gamma:      1.0:1.0:1.0
 Brightness: 1.0
 Clones:   
 CRTC:       0
 CRTCs:      0 1 2
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:
 EDID:
 00ffffffffffff0006af2d2000000000
 00160104901d117802bc05a2554c9a25
 0e505400000001010101010101010101
 0101010101011d3680a070381e403020
 8e0025a5100000181d36800872386640
 30208e0025a510000018000000fe0041
 554f0a202020202020202020000000fe
 004231333348414e30322e30200a0043
 BACKLIGHT: 94
 range: (0, 94)
 Backlight: 94
 range: (0, 94)
 scaling mode: Full aspect
 supported: None, Full, Center, Full aspect
 Broadcast RGB: Automatic
 supported: Automatic, Full, Limited 16:235
 audio: auto
 supported: force-dvi, off, auto, on
 1920x1080 (0x47)  138.5MHz -HSync -VSync *current +preferred
 h: width  1920 start 1968 end 2000 total 2080 skew    0 clock   66.6KHz
 v: height 1080 start 1088 end 1102 total 1110           clock   60.0Hz
 1920x1080 (0xae)  138.5MHz -HSync -VSync
 h: width  1920 start 1968 end 2000 total 2440 skew    0 clock   56.8KHz
 v: height 1080 start 1088 end 1102 total 1182           clock   48.0Hz
 1920x1080 (0xaf)  138.5MHz +HSync -VSync
 h: width  1920 start 1968 end 2000 total 2080 skew    0 clock   66.6KHz
 v: height 1080 start 1083 end 1088 total 1111           clock   59.9Hz
 1680x1050 (0xb0)  146.2MHz -HSync +VSync
 h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
 v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
 1680x1050 (0xb1)  119.0MHz +HSync -VSync
 h: width  1680 start 1728 end 1760 total 1840 skew    0 clock   64.7KHz
 v: height 1050 start 1053 end 1059 total 1080           clock   59.9Hz
 1600x1024 (0xb2)  103.1MHz +HSync +VSync
 h: width  1600 start 1600 end 1656 total 1664 skew    0 clock   62.0KHz
 v: height 1024 start 1024 end 1029 total 1030           clock   60.2Hz
 1400x1050 (0xb3)  122.0MHz +HSync +VSync
 h: width  1400 start 1488 end 1640 total 1880 skew    0 clock   64.9KHz
 v: height 1050 start 1052 end 1064 total 1082           clock   60.0Hz
 1280x1024 (0xb4)  108.0MHz +HSync +VSync
 h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
 v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
 1440x900 (0xb5)  106.5MHz -HSync +VSync
 h: width  1440 start 1520 end 1672 total 1904 skew    0 clock   55.9KHz
 v: height  900 start  903 end  909 total  934           clock   59.9Hz
 1280x960 (0xb6)  108.0MHz +HSync +VSync
 h: width  1280 start 1376 end 1488 total 1800 skew    0 clock   60.0KHz
 v: height  960 start  961 end  964 total 1000           clock   60.0Hz
 1360x768 (0xb7)   84.8MHz -HSync +VSync
 h: width  1360 start 1432 end 1568 total 1776 skew    0 clock   47.7KHz
 v: height  768 start  771 end  781 total  798           clock   59.8Hz
 1360x768 (0xb8)   72.0MHz +HSync -VSync
 h: width  1360 start 1408 end 1440 total 1520 skew    0 clock   47.4KHz
 v: height  768 start  771 end  781 total  790           clock   60.0Hz
 1152x864 (0xb9)   81.6MHz -HSync +VSync
 h: width  1152 start 1216 end 1336 total 1520 skew    0 clock   53.7KHz
 v: height  864 start  865 end  868 total  895           clock   60.0Hz
 1024x768 (0xba)   65.0MHz -HSync -VSync
 h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
 v: height  768 start  771 end  777 total  806           clock   60.0Hz
 800x600 (0xbb)   40.0MHz +HSync +VSync
 h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
 v: height  600 start  601 end  605 total  628           clock   60.3Hz
 800x600 (0xbc)   36.0MHz +HSync +VSync
 h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
 v: height  600 start  601 end  603 total  625           clock   56.2Hz
 640x480 (0xbd)   25.2MHz -HSync -VSync
 h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
 v: height  480 start  490 end  492 total  525           clock   59.9Hz
HDMI1 connected 3840x2160+1920+0 (0xe3) normal (normal left inverted right x axis y axis) 527mm x 296mm
 Identifier: 0x44
 Timestamp:  3827058
 Subpixel:   unknown
 Gamma:      1.0:1.0:1.0
 Brightness: 1.0
 Clones:   
 CRTC:       1
 CRTCs:      0 1 2
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:
 EDID:
 00ffffffffffff0010acc0a04c553630
 2d18010380351e78eae245a8554da326
 0b5054a54b00714f8180a9c0a940d1c0
 e10001010101a36600a0f0701f803020
 35000f282100001a000000ff00503250
 43323442343036554c0a000000fc0044
 454c4c205032343135510a20000000fd
 001d4c1e8c1e000a2020202020200196
 02032af15390050402071601141f1213
 2720212203061115230907076d030c00
 1000303c200060030201023a80187138
 2d40582c25000f282100001f011d8018
 711c1620582c25000f282100009e0474
 0030f2705a80b0588a000f282100001e
 565e00a0a0a02950302035000f282100
 001a00000000000000000000000000f9
 Broadcast RGB: Automatic
 supported: Automatic, Full, Limited 16:235
 audio: auto
 supported: force-dvi, off, auto, on
 3840x2160 (0xe3)  262.8MHz +HSync -VSync *current +preferred
 h: width  3840 start 3888 end 3920 total 4000 skew    0 clock   65.7KHz
 v: height 2160 start 2163 end 2168 total 2191           clock   30.0Hz
 3840x2160 (0xe4)  297.0MHz +HSync +VSync
 h: width  3840 start 4016 end 4104 total 4400 skew    0 clock   67.5KHz
 v: height 2160 start 2168 end 2178 total 2250           clock   30.0Hz
 3840x2160 (0xe5)  297.0MHz +HSync +VSync
 h: width  3840 start 4896 end 4984 total 5280 skew    0 clock   56.2KHz
 v: height 2160 start 2168 end 2178 total 2250           clock   25.0Hz
 3840x2160 (0xe6)  297.0MHz +HSync +VSync
 h: width  3840 start 5116 end 5204 total 5500 skew    0 clock   54.0KHz
 v: height 2160 start 2168 end 2178 total 2250           clock   24.0Hz
 3840x2160 (0xe7)  296.7MHz +HSync +VSync
 h: width  3840 start 4016 end 4104 total 4400 skew    0 clock   67.4KHz
 v: height 2160 start 2168 end 2178 total 2250           clock   30.0Hz
 3840x2160 (0xe8)  296.7MHz +HSync +VSync
 h: width  3840 start 5116 end 5204 total 5500 skew    0 clock   53.9KHz
 v: height 2160 start 2168 end 2178 total 2250           clock   24.0Hz
 2560x1440 (0xe9)  241.5MHz +HSync -VSync
 h: width  2560 start 2608 end 2640 total 2720 skew    0 clock   88.8KHz
 v: height 1440 start 1443 end 1448 total 1481           clock   60.0Hz
 2048x1280 (0xea)  221.3MHz -HSync +VSync
 h: width  2048 start 2192 end 2416 total 2784 skew    0 clock   79.5KHz
 v: height 1280 start 1281 end 1284 total 1325           clock   60.0Hz
 1920x1080 (0xeb)  148.5MHz +HSync +VSync
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
 v: height 1080 start 1082 end 1087 total 1125           clock   60.0Hz
 1920x1080 (0xec)  148.5MHz +HSync +VSync
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
 1920x1080 (0xed)  148.5MHz +HSync +VSync
 h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   56.2KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   50.0Hz
 1920x1080 (0xee)  148.4MHz +HSync +VSync
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.4KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   59.9Hz
 1920x1080i (0xef)   74.2MHz +HSync +VSync Interlace
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   33.8KHz
 v: height 1080 start 1084 end 1094 total 1125           clock   60.1Hz
 1920x1080i (0xf0)   74.2MHz +HSync +VSync Interlace
 h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   28.1KHz
 v: height 1080 start 1084 end 1094 total 1125           clock   50.0Hz
 1920x1080 (0xf1)   74.2MHz +HSync +VSync
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   33.8KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   30.0Hz
 1920x1080 (0xf2)   74.2MHz +HSync +VSync
 h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   28.1KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   25.0Hz
 1920x1080 (0xf3)   74.2MHz +HSync +VSync
 h: width  1920 start 2558 end 2602 total 2750 skew    0 clock   27.0KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   24.0Hz
 1920x1080i (0xf4)   74.2MHz +HSync +VSync Interlace
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   33.7KHz
 v: height 1080 start 1084 end 1094 total 1125           clock   60.0Hz
 1920x1080 (0xf5)   74.2MHz +HSync +VSync
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   33.7KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   30.0Hz
 1920x1080 (0xf6)   74.2MHz +HSync +VSync
 h: width  1920 start 2558 end 2602 total 2750 skew    0 clock   27.0KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   24.0Hz
 1920x1080i (0xf7)   72.0MHz +HSync -VSync Interlace
 h: width  1920 start 1952 end 2120 total 2304 skew    0 clock   31.2KHz
 v: height 1080 start 1126 end 1136 total 1250           clock   50.0Hz
 1600x1200 (0xf8)  162.0MHz +HSync +VSync
 h: width  1600 start 1664 end 1856 total 2160 skew    0 clock   75.0KHz
 v: height 1200 start 1201 end 1204 total 1250           clock   60.0Hz
 1600x900 (0xf9)  119.0MHz -HSync +VSync
 h: width  1600 start 1696 end 1864 total 2128 skew    0 clock   55.9KHz
 v: height  900 start  901 end  904 total  932           clock   60.0Hz
 1280x1024 (0xfa)  135.0MHz +HSync +VSync
 h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
 v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
 1280x1024 (0xb4)  108.0MHz +HSync +VSync
 h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
 v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
 1152x864 (0xfb)  108.0MHz +HSync +VSync
 h: width  1152 start 1216 end 1344 total 1600 skew    0 clock   67.5KHz
 v: height  864 start  865 end  868 total  900           clock   75.0Hz
 1280x720 (0xfc)   74.2MHz +HSync +VSync
 h: width  1280 start 1390 end 1430 total 1650 skew    0 clock   45.0KHz
 v: height  720 start  725 end  730 total  750           clock   60.0Hz
 1280x720 (0xfd)   74.2MHz +HSync +VSync
 h: width  1280 start 1720 end 1760 total 1980 skew    0 clock   37.5KHz
 v: height  720 start  725 end  730 total  750           clock   50.0Hz
 1280x720 (0xfe)   74.2MHz +HSync +VSync
 h: width  1280 start 1390 end 1430 total 1650 skew    0 clock   45.0KHz
 v: height  720 start  725 end  730 total  750           clock   59.9Hz
 1440x576i (0xff)   27.0MHz -HSync -VSync Interlace
 h: width  1440 start 1464 end 1590 total 1728 skew    0 clock   15.6KHz
 v: height  576 start  580 end  586 total  625           clock   50.1Hz
 1024x768 (0x100)   78.8MHz +HSync +VSync
 h: width  1024 start 1040 end 1136 total 1312 skew    0 clock   60.1KHz
 v: height  768 start  769 end  772 total  800           clock   75.1Hz
 1024x768 (0xba)   65.0MHz -HSync -VSync
 h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
 v: height  768 start  771 end  777 total  806           clock   60.0Hz
 1440x480i (0x101)   27.0MHz -HSync -VSync Interlace
 h: width  1440 start 1478 end 1602 total 1716 skew    0 clock   15.8KHz
 v: height  480 start  488 end  494 total  525           clock   60.1Hz
 1440x480i (0x102)   27.0MHz -HSync -VSync Interlace
 h: width  1440 start 1478 end 1602 total 1716 skew    0 clock   15.7KHz
 v: height  480 start  488 end  494 total  525           clock   60.1Hz
 800x600 (0x103)   49.5MHz +HSync +VSync
 h: width   800 start  816 end  896 total 1056 skew    0 clock   46.9KHz
 v: height  600 start  601 end  604 total  625           clock   75.0Hz
 800x600 (0xbb)   40.0MHz +HSync +VSync
 h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
 v: height  600 start  601 end  605 total  628           clock   60.3Hz
 720x576 (0x104)   27.0MHz -HSync -VSync
 h: width   720 start  732 end  796 total  864 skew    0 clock   31.2KHz
 v: height  576 start  581 end  586 total  625           clock   50.0Hz
 720x480 (0x105)   27.0MHz -HSync -VSync
 h: width   720 start  736 end  798 total  858 skew    0 clock   31.5KHz
 v: height  480 start  489 end  495 total  525           clock   60.0Hz
 720x480 (0x106)   27.0MHz -HSync -VSync
 h: width   720 start  736 end  798 total  858 skew    0 clock   31.5KHz
 v: height  480 start  489 end  495 total  525           clock   59.9Hz
 640x480 (0x107)   31.5MHz -HSync -VSync
 h: width   640 start  656 end  720 total  840 skew    0 clock   37.5KHz
 v: height  480 start  481 end  484 total  500           clock   75.0Hz
 640x480 (0x108)   25.2MHz -HSync -VSync
 h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
 v: height  480 start  490 end  492 total  525           clock   60.0Hz
 640x480 (0xbd)   25.2MHz -HSync -VSync
 h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
 v: height  480 start  490 end  492 total  525           clock   59.9Hz
 720x400 (0x109)   28.3MHz -HSync +VSync
 h: width   720 start  738 end  846 total  900 skew    0 clock   31.5KHz
 v: height  400 start  412 end  414 total  449           clock   70.1Hz
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
 Identifier: 0x45
 Timestamp:  3827058
 Subpixel:   no subpixels
 Clones:   
 CRTCs:      3
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:

And the Samsung monitor:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
 Identifier: 0x51
 Timestamp:  110079
 Subpixel:   no subpixels
 Clones:   
 CRTCs:      0 1
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:
 load detection: 1 (0x00000001)    range:  (0,1)
HDMI-0 disconnected (normal left inverted right x axis y axis)
 Identifier: 0x52
 Timestamp:  110079
 Subpixel:   horizontal rgb
 Clones:   
 CRTCs:      0 1
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:
 audio:    off
 supported: off          on           auto       
 underscan vborder: 0 (0x00000000)    range:  (0,128)
 underscan hborder: 0 (0x00000000)    range:  (0,128)
 underscan:    off
 supported: off          on           auto       
 coherent: 1 (0x00000001)    range:  (0,1)
DVI-0 connected 1920x1080+0+0 (0x54) normal (normal left inverted right x axis y axis) 510mm x 287mm
 Identifier: 0x53
 Timestamp:  110079
 Subpixel:   horizontal rgb
 Clones:   
 CRTC:       0
 CRTCs:      0 1
 Transform:  1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter:
 EDID:
 00ffffffffffff004c2d2a0733323037
 0e14010380331d782a81f1a357539f27
 0a5054bfef8081009500b3008140714f
 8180a940950f023a801871382d40582c
 4500fe1f1100001e000000fd00384b1e
 5111000a202020202020000000fc0053
 4d584c3233373048440a2020000000ff
 004831414b3530303030300a202000a1
 load detection: 1 (0x00000001)    range:  (0,1)
 audio:    off
 supported: off          on           auto       
 underscan vborder: 0 (0x00000000)    range:  (0,128)
 underscan hborder: 0 (0x00000000)    range:  (0,128)
 underscan:    off
 supported: off          on           auto       
 coherent: 1 (0x00000001)    range:  (0,1)
 1920x1080 (0x54)  148.5MHz +HSync +VSync *current +preferred
 h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
 v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
 1600x1200 (0x55)  162.0MHz +HSync +VSync
 h: width  1600 start 1664 end 1856 total 2160 skew    0 clock   75.0KHz
 v: height 1200 start 1201 end 1204 total 1250           clock   60.0Hz
 1680x1050 (0x56)  119.0MHz +HSync -VSync
 h: width  1680 start 1728 end 1760 total 1840 skew    0 clock   64.7KHz
 v: height 1050 start 1053 end 1059 total 1080           clock   59.9Hz
 1280x1024 (0x57)  135.0MHz +HSync +VSync
 h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
 v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
 1280x1024 (0x58)  108.0MHz +HSync +VSync
 h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
 v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
 1440x900 (0x59)  136.8MHz -HSync +VSync
 h: width  1440 start 1536 end 1688 total 1936 skew    0 clock   70.6KHz
 v: height  900 start  903 end  909 total  942           clock   75.0Hz
 1440x900 (0x5a)   88.8MHz +HSync -VSync
 h: width  1440 start 1488 end 1520 total 1600 skew    0 clock   55.5KHz
 v: height  900 start  903 end  909 total  926           clock   59.9Hz
 1280x960 (0x5b)  108.0MHz +HSync +VSync
 h: width  1280 start 1376 end 1488 total 1800 skew    0 clock   60.0KHz
 v: height  960 start  961 end  964 total 1000           clock   60.0Hz
 1280x800 (0x5c)   71.0MHz +HSync -VSync
 h: width  1280 start 1328 end 1360 total 1440 skew    0 clock   49.3KHz
 v: height  800 start  803 end  809 total  823           clock   59.9Hz
 1152x864 (0x5d)  108.0MHz +HSync +VSync
 h: width  1152 start 1216 end 1344 total 1600 skew    0 clock   67.5KHz
 v: height  864 start  865 end  868 total  900           clock   75.0Hz
 1024x768 (0x5e)   78.8MHz +HSync +VSync
 h: width  1024 start 1040 end 1136 total 1312 skew    0 clock   60.1KHz
 v: height  768 start  769 end  772 total  800           clock   75.1Hz
 1024x768 (0x5f)   75.0MHz -HSync -VSync
 h: width  1024 start 1048 end 1184 total 1328 skew    0 clock   56.5KHz
 v: height  768 start  771 end  777 total  806           clock   70.1Hz
 1024x768 (0x60)   65.0MHz -HSync -VSync
 h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
 v: height  768 start  771 end  777 total  806           clock   60.0Hz
 832x624 (0x61)   57.3MHz -HSync -VSync
 h: width   832 start  864 end  928 total 1152 skew    0 clock   49.7KHz
 v: height  624 start  625 end  628 total  667           clock   74.6Hz
 800x600 (0x62)   50.0MHz +HSync +VSync
 h: width   800 start  856 end  976 total 1040 skew    0 clock   48.1KHz
 v: height  600 start  637 end  643 total  666           clock   72.2Hz
 800x600 (0x63)   49.5MHz +HSync +VSync
 h: width   800 start  816 end  896 total 1056 skew    0 clock   46.9KHz
 v: height  600 start  601 end  604 total  625           clock   75.0Hz
 800x600 (0x64)   40.0MHz +HSync +VSync
 h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
 v: height  600 start  601 end  605 total  628           clock   60.3Hz
 800x600 (0x65)   36.0MHz +HSync +VSync
 h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
 v: height  600 start  601 end  603 total  625           clock   56.2Hz
 640x480 (0x66)   31.5MHz -HSync -VSync
 h: width   640 start  656 end  720 total  840 skew    0 clock   37.5KHz
 v: height  480 start  481 end  484 total  500           clock   75.0Hz
 640x480 (0x67)   31.5MHz -HSync -VSync
 h: width   640 start  664 end  704 total  832 skew    0 clock   37.9KHz
 v: height  480 start  489 end  491 total  520           clock   72.8Hz
 640x480 (0x68)   30.2MHz -HSync -VSync
 h: width   640 start  704 end  768 total  864 skew    0 clock   35.0KHz
 v: height  480 start  483 end  486 total  525           clock   66.7Hz
 640x480 (0x69)   25.2MHz -HSync -VSync
 h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
 v: height  480 start  490 end  492 total  525           clock   60.0Hz
 720x400 (0x6a)   28.3MHz -HSync +VSync
 h: width   720 start  738 end  846 total  900 skew    0 clock   31.5KHz
 v: height  400 start  412 end  414 total  449           clock   70.1H

Just in case this is helpful to anyone…

But hey, this never happened in the past! Asking a round a bit, I was advised to check if the fan is OK. Maybe the thermal paste went dry.

Opening the case and looking, I noticed that the heatsink was full with dust. More precisely, a lot of dust was stuck between the heatsink’s grill blades, obstructing the air flow. No air flow, no cooling. So I unsnapped the fan off the heatsink, took a vacuum cleaner, and removed all dust.

And my PC is like new now! The temperature goes from 30.0°C to no more than 44.0°C when I run that kernel compilation test (watching the temperature with “watch sensors” at shell prompt).

It was that simple.

Note to self: Vacuum the CPU’s heatsink every now and then.

And here’s what it looks like after two years, during which the computer has been on continuously (click on images to enlarge):

And this is with the fan taken off. One can clearly see that the layer of dust disrupts the air flow.

A minute with the vacuum cleaner, and we have

Snap the fan back in place, and the computer is ready to go!

I can’t say I’m disappointed, because I didn’t really expect things to work as specified on a $10 camera.

Even though the manual promises 70 minutes of recording time, I got 48 minutes in reality before the camera stopped itself (the memory card wasn’t full, it was the battery that ran out).

Note that a MicroSD card needs to be purchased separately, which will cost significantly relative to the camera’s price (some $8 in a store, possibly $4 on EBay for a Sandisk card). The largest file I managed to obtain with a 48 minutes recording was 1.7 GB, so a 2 GB card is probably large enough.

LED colors

It looks like the LED colors were changed since the manual was written. The blue LED is the power LED, indicating that the device is on. The red LED says something is happening.

Optics and image quality

The image is a 720x480, apparently progressive (non-interlaced) rolling shutter with a noise level that resembles web cameras from the late 90′s. The measured opening angle on the frame’s width was as narrow as 25 degrees which, I suppose is about 80mm focal length on a 35mm-equivalent scale. In other words, this is with a slight touch of a tele lens.

The camera was announced having an 80 degrees view angle by its EBay seller, which turned out to be wrong. The narrow angle is a problem for most relevant applications, since it the desired subject gets off-frame easily. It’s also the reason for the shaky footage this camera emits. I’m not even sure about using this as a helmet camera.

With a $1 Jelly Lens, the angle of view rises to 40 degrees, which is around 50mm focal length (on a 35mm scale). In other words, the extra lens is some x0.6 (not very impressive, but what did I expect from a $1 lens?) and it gives the camera a “normal” focal length. The sticky adhesive on the jelly lens held the very small piece of plastic firmly in place. I don’t know how well this would work on a helmet cam, though. Did I say $1?

I should mention, that for a cellular phone with an already pretty wide angle, this Jelly Lens actually achieves an impressive wide angle (and green visible borders). So it’s a very good deal, given its price…

Another lens tried out was the AGPtek “180 Degrees” lens for cellular phones for some $5. It is often announced as x0.28, but it’s not. My measurement was 53 degrees, which is about 36 mm focal length (on a 35mm scale), so the lens did in fact x0.45. Better than the Jelly Lens, but by far not as good as expected. It does have a slight roundoff in the corners like a fish-eye lens at 53 degrees view angle, which gives the illusion that it’s wider than it actually is.

Charging

Connect the camera to a computer via USB, so it gets power. The blue LED goes on, and the red LED starts blinking. According to the user’s manual, a green LED should be blinking, but it looks like the color was changed to red. The user’s manual also says that the LED should stop blinking when the battery is charged, but that didn’t happen even after an overnight charging. It just went on blinking (red). According to the seller at EBay, the charging time should be 3 hours. Go figure.

Note that the MicroSD is mounted on the computer due to the USB connection.

Accessing the MicroSD card

Well, simply connect to the computer (as in for charging). The following (or similar) will appear at the log:

Jan 31 17:54:27 myhost kernel: hub 1-2:1.0: unable to enumerate USB device on port 2
Jan 31 17:54:29 myhost kernel: usb 1-2.2: new high speed USB device using ehci_hcd and address 62
Jan 31 17:54:29 myhost kernel: usb 1-2.2: New USB device found, idVendor=04d6, idProduct=e101
Jan 31 17:54:29 myhost kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 31 17:54:29 myhost kernel: usb 1-2.2: Product: usbdisk  
Jan 31 17:54:29 myhost kernel: usb 1-2.2: Manufacturer: anyka    
Jan 31 17:54:29 myhost kernel: usb 1-2.2: SerialNumber: 942954944
Jan 31 17:54:29 myhost kernel: scsi102 : usb-storage 1-2.2:1.0
Jan 31 17:54:30 myhost kernel: scsi 102:0:0:0: Direct-Access     anyka    MMC Disk         1.00 PQ: 0 ANSI: 2
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: Attached scsi generic sg4 type 0
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] 3858560 512-byte logical blocks: (1.97 GB/1.83 GiB)
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] Write Protect is off
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] Assuming drive cache: write through
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] Assuming drive cache: write through
Jan 31 17:54:30 myhost kernel: sdd:
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] Assuming drive cache: write through
Jan 31 17:54:30 myhost kernel: sd 102:0:0:0: [sdd] Attached SCSI removable disk

This is just like connecting a disk-on-key, and so is the access to the content.

Using as a webcam

This is useful for getting an idea of the image quality, and immediate feedback for aiming the camera properly.

With the camera connected via USB (and hence the MicroSD card mounted), unmount the volume (“Safely Remove Drive” or something) and press the camera’s Power button for three seconds or so. The red LED will stop blinking, and the blue remains steadily on. The following lines in the log indicate the transformation into a web cam:

Jan 31 17:55:20 myhost kernel: usb 1-2.2: USB disconnect, address 62
Jan 31 17:55:21 myhost gnome-keyring-daemon[28416]: removing removable location: /media/New flash
Jan 31 17:55:21 myhost gnome-keyring-daemon[28416]: no volume registered at: /media/New flash
Jan 31 17:55:21 myhost gnome-keyring-daemon[3139]: removing removable location: /media/New flash
Jan 31 17:55:21 myhost gnome-keyring-daemon[3139]: no volume registered at: /media/New flash
Jan 31 17:55:23 myhost kernel: usb 1-2.2: new high speed USB device using ehci_hcd and address 63
Jan 31 17:55:23 myhost kernel: usb 1-2.2: New USB device found, idVendor=04d6, idProduct=e102
Jan 31 17:55:23 myhost kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 31 17:55:23 myhost kernel: usb 1-2.2: Product: UVC..
Jan 31 17:55:23 myhost kernel: usb 1-2.2: Manufacturer: ANYKA
Jan 31 17:55:23 myhost kernel: usb 1-2.2: SerialNumber: 12345
Jan 31 17:55:23 myhost kernel: uvcvideo: Found UVC 1.00 device UVC.. (04d6:e102)
Jan 31 17:55:23 myhost kernel: uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
Jan 31 17:55:23 myhost kernel: input: UVC.. as /devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.2/1-2.2:1.0/input/input13

The last row indicates the generation of /dev/video0:

$ ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 2013-01-31 17:55 /dev/video0

It’s important to start doing something with the webcam soon, or the camera goes into sleep mode. Running Cheese Webcam Booth (2.28.1) shows an immediate image. No configuration should be necessary (it should find /dev/video0 automatically).

Using as a stand-alone camera

According to the manual, the camera has two modes: Normal recording and audio-triggered. I haven’t tried the audio-triggered mode, and neither do I want to. To switch from one mode to another, there’s the “Mode” button. Which I’m not touching.

Needless to say, a MicroSD card must be inserted for this to work.

To start, make sure that the device is disconnected from the computer and off (no LED is on). Press the Power button for a second, wait a few seconds. Only the blue LED should lit steadily.

To start and stop recording, press the button on the camera’s short edge (next to the record/stop symbols). The red LED will blink at 0.5 Hz during recording.

If the “Mode” button is pressed, the red LED will blink at 2-3 Hz to indicate audio-triggered recording. Turning the camera off and on is the best way to make sure the camera is at a known state.

Playback

The video files are put in the “VIDEO” subdirectory. A typical playback session with mplayer looks like this:

$ mplayer "/media/New Flash/VIDEO/2012-9-21 18-26-54.AVI"
MPlayer SVN-r31628-4.4.4 (C) 2000-2010 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /media/New Flash/VIDEO/2012-9-21 18-26-54.AVI.
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO:  [MJPG]  720x480  24bpp  30.000 fps  2449.9 kbps (299.1 kbyte/s)
Clip info:
 Software: ankarec
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG)
==========================================================================
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 8000 Hz, 1 ch, s16le, 128.0 kbit/100.00% (ratio: 16000->16000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [pulse] 8000Hz 1ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 720x480 => 720x480 Planar YV12
A:   3.0 V:   3.0 A-V:  0.001 ct:  0.002  92/ 92  5%  0%  0.1% 0 0

The video format is MJPEG 720x480 (not sure about the aspect ratio) with uncompressed 16 bit per sample mono sound, at 8 kHz sample rate. The file name represents the time at which recording began.

A small timestamp appears at the lower right of the recorded image.

Setting the time

This is somewhat confusing. The way to set the time, is to create a file called time.txt in the card’s root directory. To make things a bit complicated, the camera creates a file called TIME.TXT in the same place, with a timestamp sample (or something). Editing this file will do nothing. It’s a new file that needs to be created with something like

$ vi "/media/New Flash/time.txt"

It looks like the file appears from nowhere, with a sample timestamp (2012-09-21 17:08:56) set. Update it to something like

2013-01-31 19:45:00

or write it from scratch if nothing appears. Write and quit vi. Unmount the volume, unplug the camera, and turn it off. The camera will update the time to the file’s content when it starts up the next time.

There’s a null-character in the end in the sample timestamp. It can be omitted or left. Doesn’t matter.

Conclusion

Pretty much expected, it’s a piece of junk with poor documentation. Otherwise, it wouldn’t go for $10. But it’s good for putting in places where it has a good chance to get lost or destroyed, and hopefully get some cool footage when put on a helmet or something like that.

Everything was OK until it failed to start. Or more precisely, it started, and then restarted itself. Like this:

And again. And again. It turned out that a defective MicroSD flash card caused it to go crazy. So I replaced the card, and everything looked fine again. But then it had a horrible relapse: It went back to this restarting pattern again, but this time it didn’t help to take out the MicroSD card. What turned out to be really bad, was that it was impossible to connect it to a computer through USB for backup, because it would restart all the time.

It wasn’t a power supply thing. I learned that from the fact, that when the phone was started without a SIM, it asked me whether it should start the phone even so. And it didn’t restart as long as I didn’t press any button on that question.

So it was clear that the phone did something that went wrong a few seconds after being powered on. So the trick was to prevent it from getting on with its booting process, but still allow a USB connection.

Connecting the USB cord while in any of the pre-start menus turned out useless (Use without SIM? Exit from Flight mode?). So I looked a bit at the codes.

What did eventually work, was to use the *#06# code, which is used to check IMEI. The phone showed me the serial number and didn’t restart, and when I plugged in the USB cord, I got the usual menu allowing me to choose mode. From there on it was a lot of playing around, trying and retrying until I finally recovered my phone list.

This also made it possible to reprogram the handset with Nokia’s Phoenix software, which didn’t work otherwise. Neither did the Green-*-3 three finger salute for a deep reset nor the infamous *#7370# code for the same purpose. These two never did anything, even when the phone appeared to be sane.

I should point out, that it’s possible that this trick may have solved a very specific issue on my own phone’s internal messup, and still, I thought it was best to have it written down for rainy days.

ionice -c 3 -p 18898

And you have your computer back. “-c 3″ means class 3, which is idle class. In other words, take the disk when nobody else asks for it.

I love it. More here.