Hardware fix for the screen backlight flicker

[dsimic]

Hello,

Despite some software fixes for the screen backlight flicker on PinePhone, the primary issue remains, meaning that the intensity of screen backlight changes somewhat erratically and very annoyingly when there's communication on the internal I2C bus, such as when the operating system talks to the LTE modem, or when the total power draw of the phone changes significantly, for example when scrolling the screen contents.

I've already researched the possible ways for fixing the flicker by doing some hardware modifications, and I've reached the point where I'd need to secure a development platform.  In other words, I'd need a development PinePhone, which would be used for trying out hardware modifications.  My goal would be to end up with hardware modifications and clear instructions that are as simple as possible, and easily doable by many PinePhone owners.

Understandingly, I do not want to try out those hardware modifications on my own PinePhone, because there's always a chance for the electronics to produce a puff of magic smoke.

Thus, I'm asking for a way to get a PCB 1.2b PinePhone, for the above-described development purposes.  Ideally, I would like to get an additional, separate PCBA 1.2b board, in case something bad happens to the original board.  Also, please, keep in mind that I cannot guarantee that the whole endeavour will actually result in the desired hardware fix, but I would do my best.

Finally, there are two questions:

1. Would the Pine64 team be willing to donate the required hardware?
2. If not, would the forum members be willing to pitch in?  I can accept PayPal payments.

Any help would be appreciated!

[dsimic]

You're more than welcome to be sarcastic and to express your criticism.  I would even encourage that, as long as we stay civil, so we can have healthy discussions.  In the end, this is a free forum, as far as I know.

Your concerns are perfectly valid, simply because you do not know me.  However, I am not a scammer, and I am not a poor dude asking to get $5 or $10 as a hand-out and disappear.  Also, I do not expect anyone to simply throw in their money without asking for the specifics of the proposed hardware fix, but do I expect people to simply ask whatever they want to know.

Please, keep in mind that I also value my own time, because I am a knowledgeable person with a ton of experience.  Also, for the time being I do not want to spend a few more weeks on fleshing out a few possible variants of the hardware fix in detail, without even knowing if it would be possible to get a free PinePhone for the purpose of performing the actual experiments.

Absolutely nothing about the hardware fixes would be proprietary.  All attempts toward the final hardware fix would be documented, and the final fix would be documented in great detail, with very detailed, as simple as possible instructions for anyone wanting to apply the actual hardware fix to their own PinePhone.  In a few words, my goal is to contribute to the community.

Why am I asking for a hardware donation?  First, I've already invested a ton of my time into analyzing the internals of PinePhone, all that for free, which I'm fine with.  Next, I should put my own PinePhone on the line, and possibly have it produce a puff of magic smoke.  Ok, bad things happen.  However, it is now perfectly valid to ask what would I be getting out of all that?  A lot of work done for free (which I'm fine with), taking some risk, and a clear monetary loss in the end.

By asking for a hardware donation, I'm asking the community to take the risk together with me.  I will put a lot of work into it for free, and produce publicly available results for the community, and possibly for Pine64 to incorporate in the next PCBA revision, but I do not like very much the idea of taking all the risk myself.  Let's share the risk and reap the benefits together, which is the whole idea behind having a community of any kind.

Please keep in mind that changes in the screen backlight circuit have been introduced in different PCBA revisions.  I would love to have all available revisions of the PinePhone PCBA for experimentation, and I would love to be able to produce clear fixes for all of them, but you're already bashing me for asking for a single PCBA revision.  I cannot even imagine what you'd say if I were asking for all PCBA revisions instead.

If anyone already wanted to try out the hardware fixes on their own unused PCBAs that are just collecting dust, why is nobody doing that already?  I would be perfectly fine with somebody else doing the actual work, so I am able to just replace a single capacitor (or something similar) in my PinePhone and have the backlight flicker fixed.  However, AFAIK nobody has done that yet, so I am proposing to actually do that myself, and have the community assist me in the process.  What's wrong with that?

I apologize if my comment in your thread has offended you in any way.  You could have asked me to delete my post instead.  Furthermore, why haven't you posted any updates on the actual hardware fixes you've announced?  Have you actually tried out those fixes, and if so what were the results?  If I remember correctly, you've provided no updates in about a month.

Lastly, I'm perfectly fine if this actually yields no donations in hardware.  Failure is always an option, and I might even decide to take all the risk and put my own PinePhone one the line.  I would make the results publicly available in that case, too.

[dsimic]

I totally agree with your remarks.  I'll put up a more detailed proposal for the actual hardware fixes, but please allow me to have some time for that, simply because I want us to start from a couple of viable fixes.  Of course, the proposal will need to be discussed before actually testing out anything.

Perhaps we could even end up with someone willing to test the proposed hardware modifications on their own PinePhone, instead of me receiving a hardware donation and using it to test the fixes.  I would be very happy if that would be the way to move forward, which will provide exactly what I'm looking for: sharing of the risk.  In other words, I am not looking for a free PinePhone; instead, I am looking to us solving the backlight flicker.

I would really appreciate if you would be willing to test out some of the proposed hardware fixes.  Of course, we would discuss them in detail before actually doing anything, so the risk of damaging your PinePhone should be as low as possible.

Again, I apologize for the way I came accross, and please allow me to explain further.  Asking for a PCBA 1.2b (or testing the hardware fix on it) is necessary because one of the end goals would be to have Pine64 incorporate the actual fix into one of the next PinePhone batches.  To do so, a fix needs to be tested on the latest available revision of PCBA, which is the 1.2b revision.

By the way, regarding the support for MMS, I'm afraid that I must be a bearer of bad news...   The internals of the exchange of MMS messages are insanely complicated, involving IIRC connecting to an FTP server etc., meaning that, unfortunately, implementing support for MMS would require a ton of work.  Even Maemo, Nokia's variant of Linux that shipped on a couple of old Nokia phones (e.g. N900), initially had no support for MMS.  I really cannot recall whether Maemo received the support for MMS in later updates, but if that's true, the related source code (which should be open) could be used to speed up the implementation of MMS support on the PinePhone.

Edit: This page provides more details about MMS on Maemo.

[dsimic]

My first proposal for the hardware fix would be to revert the backlight circuit changes introduced after the revision 1.0 of PinePhone.

Please, have a look at the attached couple of excerpts from the schematic of two PinePhone revisions, 1.0 and 1.2b.  As a note, all post-1.0 revisions of the PinePhone are exactly the same when it comes to the backlight control circuit.  For the sake of completeness, additional information is available in the Pine64 wiki.

Quite frankly, it makes very little sense to have the feedback of the AP3127B (datasheet) altered by the LCD backlight PWM signal (PH10-LCD-BL-EN), instead of simply driving the CE input of AP3127B with the backlight PWM signal, which is the intended way for using AP3127B.  The post-1.0 backlight circuit actually treats the CE input of AP3128B as "chip enable", driving it with the separate PH10-LCD-BL-EN signal.  However, the currently separate "blacklight enable" is the same as driving the CE input with a 0% PWM signal, which makes PH10-LCD-BL-EN redundant and the proposed hardware fix feasible.

Reverting the backlight circuit changes introduced in the post-1.0 revisions of the PinePhone would be fairly straightforward, but unfortunately may not be easily reversible back to the original PCB state.  In more detail, one of the changes would require a pin of the AP3127B to be unsoldered and lifted, which is the step that would make the reversal troublesome.

It might be possible to leave the aforementioned pin in place, but (if possible at all) that would require significant changes to the DTS file, which would turn the whole hardware fix into a "fork" of the hardware and make the later software support troublesome.  Also, it would make the hardware fix somewhat dangerous if the fixed phone is booted with the unmodified DTS file, because it would result in shorting two GPIO lines that both serve as power/signal outputs.

In short, the list of changes would be as follows:

1. Unsolder R1109, R1117, R1118, R1119, R1120, R1529 and C1110
2. Solder three 0R resistors in the places of R1117, R1118 and R1529
3. Solder a 10K resistor (already removed R1109 may be reused) in the place of C1110
4. Unsolder and lift the pin #4 (EN / CE) of the AP3127B
5. Solder a small piece of wire between the lifted pin #4 and the "left" pad of NC R1120

Of course, small "blobs" of solder may be placed instead of 0R resistors, which would make no new components required for the entire hardware fix.  We can probably not count a small piece of wire as a new component.   Also, there should be no issues caused by the lack of available space.

Depending on the actual PCB layout, it may also be possible to avoid unsoldering and lifting of the pin #4 of AP3127B.  Instead, it would be needed to cut a PCB trace, separating the PH10-LCD-BL-EN signal from the pin #4.  A piece of wire would then be soldered between the "upper" pad of NC R1109 and the "left" pad of NC R1120, which may also look neater.

The DTS file may eventually need to be changed, to adjust the definition of brightness levels (i.e. the PWM duty cycles).  That itself would not be difficult, but it would be much better if no changes would be required at all, so we don't end up with a "fork" of the PinePhone hardware.  However, we would need to give the hardware fix a go, in order to determine the need for any changes to the DTS file.

Thoughts?  Is there a way to make this simpler?

---

Edit: According to the source of the Linux kernel driver for the screen backlight and the backlight configuration documentation, the  original, unchanged PinePhone DTS file could be used after applying the above-described hardware fix.  This actually means that no new "fork" of the PinePhone hardware would be created by applying the proposed hardware fix, which is very good from the point of retaining software compatibility.

In more detail, the PinePhone DTS file expectedly contains the definition of the "enable-gpios" property, which is according to the post-1.0 backlight circuit.  To turn the screen backlight off, the Linux kernel driver properly applies both 0% PWM duty cycle to the PWM control and drives the enable/disable GPIO line low.  Turning the backlight on is done in a similar way, by applying a non-zero PWM duty cycle and driving the GPIO line high, which is again two separate actions.

In our case, those two separate actions are in fact the same thing, due to the way AP3127B works, so the "enable-gpios" property could be safely left unused (quite literally, dangling), while applying the PWM duty cycle would properly take care of everything.

[dsimic]

After further analysis, there seem to be certain inconsistencies between the released schematics of different PinePhone revisions and the actual backlight control circuits found on the respective revisions of the PinePhone main boards.  For example, R1117, R1118, R1119, R1120 and C1110, which are all part of the backlight control circuit in the released revison 1.1 of the PinePhone schematic (see the second attachment in my post above), are nowhere to be found in the released revision 1.1 of the main board component placement.

However, additional analysis is required before drawing any final conclusions.