Aura Setting VCOM

[GreatMagicalHat]

I replaced the screen on my Kobo Aura. It seems to work for the most part, but there are some minor issues with the screen: the images appear "faded" as everything seems to be a bit lighter than it should be and there is a lot of ghosting. These issues line up with what I'd expect to happen when the VCOM voltage* is too low. Now, my old screen needed -2.25 and my new one needs -2.33, so that's actually pretty close. I still think that setting the correct VCOM voltage might be the way to go.

I have searched on the internet a lot, but I didn't find anyone describing the process of setting the VCOM voltage for a Kobo e-reader. The closest I got was a post on this forum in which someone asked for exactly that, but never got an answer. So, I started experimenting.

---

I did some speculation. The first assumption I made is that the VCOM voltage is set through software in the factory. Basically, that's just the more maintainable production process. There also doesn't seem to be a physical potentiometer on the PCB. And while the digitizer ribbon cable has a chip on it, the EPD ribbon cable doesn't.

The second bit of speculation is that the VCOM value probably has to come from somewhere other than KoboRoot.tgz. This idea comes from putting myself in their shoes. I wouldn't want to build a new image for every new batch of screens, so I would use a standard KoboRoot.tgz and get the VCOM value from some other file or input. Now, I have still been looking at KoboRoot as it's still a main look into the device, but it was something for me to keep in mind.

My main discovery has been that there is a bash script "vcom_store" which seems to validate at least some of my assumptions. It also suggests that there might be some preprocessing necessary to get from the voltage to the actual number that needs to be set. Unfortunately, it doesn't work. That's because it uses "/sys/class/hwmon/hwmon0/device/vcom_value" but the hwmon part of the tree is unpopulated.

For reference, these are the contents of the vcom_store script:

#!/bin/sh

input=${1#-}
#echo $input

big=`echo ${input} |awk '{printf "%.2f\n",$1*100+16384}'`
#big=$(echo "${input}*100+16384"|bc)
#echo $big

num=${big%%.*} 
#echo $num

result=`printf 0x%x'\n' $num`
#echo $result

if [ -e /bin/busybox ]; then
echo "Set vcom_value to $result "
echo $result > /sys/class/hwmon/hwmon0/device/vcom_value
fi

I don't really know where to go from here. I might try a few more things such as calling this script at startup, but I thought I'd ask around here as well. Does anybody have any suggestions, ideas or knowledge on where to go from here?

---

*: Or does the V in VCOM stand for voltage, meaning that you can't say VCOM voltage because you would be saying voltage twice?

[pazos]

The voltages are stored in the raw disk. They're called the waveform data.

Kobo provides a way to update this waveform data as part of software updates but, sadly, I couldn't find that specific blob in any fw upgrade.

A few years ago I repurposed some "broken" kobos for a local library and I remember I had to dump and copy data between devices to have the proper settings when swapping screens between them.

I'm pretty bad taking notes but a quick google search returned this https://news.ycombinator.com/item?id=14085861

The blob is loaded by uboot. I could provide more info if you are interested

[frostschutz]

there's also some vcom setting in hwconfig but it's set to 0 I believe

the value printed on my H2O replacement display was completely different from what was in it before

The old display I don't have it anymore and it's blurry on the picture https://www.mobileread.com/forums/at...hmentid=172062 but it was -2.1x something and -1.27 on the new one https://www.mobileread.com/forums/sh...d.php?t=320264

so this is a big difference, no?

and yet it works just fine so ... I never worried about it

[GreatMagicalHat]

Originally Posted by pazos

The voltages are stored in the raw disk. They're called the waveform data.

VCOM and waveforms are separate things.

Based on different things I read, my guess would be that VCOM is the voltage, and the waveform is the timing of when the voltage should be applied, when the inverted voltage should be applied and when no voltage should be applied. That's just guessing, though, the one thing I'm sure of is that VCOM is not the same thing as the waveform.

Originally Posted by pazos

https://news.ycombinator.com/item?id=14085861

That's one of only a few references I have found to someone the waveforms differ from panel to panel. I have the feeling it's far more likely the waveforms are the same for each panel of the same model and the VCOM voltage is the thing that differs. I might be wrong about that, though.

Originally Posted by frostschutz

there's also some vcom setting in hwconfig but it's set to 0 I believe

Interesting, I'll have a look at that.

Originally Posted by frostschutz

the value printed on my H2O replacement display was completely different from what was in it before [..] and yet it works just fine

Hm... that's interesting. Maybe it's not VCOM that's causing my issues. It it's not, though, I'm not sure what is.

[lormaccone]

Same problem here. I replaced the screen of my kobo aura v2 and the contrast is very poor. I managed to rewrite the vcom values (I hope I got them right) with ntx_hwconfig, but nothing changed.

Did you manage to get yours fixed? Thanks!

[DomesticExtremis]

Well I stumbled across some info during my investigation of the TPS65185 chip. In the datasheet, section 8.37.
It seems that the PMIC can measure and save the adjustment value but how uboot or the kernel can be persuaded to make that happen I don't know. I have a suspicion that the second serial header on my Aura H2O is there for the purpose of doing that at the factory, so maybe that is the only possibility, no doubt you would need some special programmer to interface with it.
If some of you smart hackers can figure out how to do it, I'd be interested to sse the result.

ETA: here, maybe?

[jkelol111]

I'm about to replace my Kobo Aura screen soon...has anybody succeeded yet?

[nicke]

The below link is for the ancient Kobo Wifi, but later models of Kobo also seem to have these data blocks in the raw partition:

http://blog.ringerc.id.au/2011/01/ta...i-without.html

I had similar poor display issues when using a SD image from one Kobo mini on another Kobo mini. Transplanting the data blocks mentioned in the above link from the corrupted SD card to the image from the working SD card not only fixed the display, but also set the mac address.

Something to consider.

[jkelol111]

Originally Posted by nicke

The below link is for the ancient Kobo Wifi, but later models of Kobo also seem to have these data blocks in the raw partition:

http://blog.ringerc.id.au/2011/01/ta...i-without.html

I had similar poor display issues when using a SD image from one Kobo mini on another Kobo mini. Transplanting the data blocks mentioned in the above link from the corrupted SD card to the image from the working SD card not only fixed the display, but also set the mac address.

Something to consider.

Hmm, it's made much more difficult because the Aura has soldered onboard storage...

[DomesticExtremis]

Originally Posted by DomesticExtremis

Well I stumbled across some info during my investigation of the TPS65185 chip. In the datasheet, section 8.37.
It seems that the PMIC can measure and save the adjustment value but how uboot or the kernel can be persuaded to make that happen I don't know. I have a suspicion that the second serial header on my Aura H2O is there for the purpose of doing that at the factory, so maybe that is the only possibility, no doubt you would need some special programmer to interface with it.
If some of you smart hackers can figure out how to do it, I'd be interested to sse the result.

ETA: here, maybe?

Relevant section of the datasheet:

8.3.7 VCOM Adjustment
VCOM is the output of a power-amplifier with an output voltage range of 0 V to –5.11 V, adjustable in 10-mV steps. In a typical application VCOM is connected to the VCOM terminal of the EPD panel and the amplifier is controlled through the VCOM_CTRL pin. With VCOM_CTRL high, the amplifier drives the VCOM pin to the voltage specified by the VCOM1 and VCOM2 register. When pulled low, the amplifier turns off and VCOM is
actively discharged to ground through VCOM_DIS pin. If active discharge is not desired, simply leave the VCOM_DIS pin open.
For ease of design, the VCOM_CTRL pin may also be tied to the battery or IO supply. In this case, VCOM is enabled with STROBE4 during the power-up sequence and disabled on STROBE1 of the power-down sequence.
Therefore VCOM is the last rail to be enabled and the first to be disabled.

8.3.7.1 Kick-Back Voltage Measurement
TPS65185x can perform a voltage measurement on the VCOM pin to determine the kick-back voltage of the panel. This allows in-system calibration of VCOM. To perform a kick-back voltage measurement, follow these
steps:
• Pull the WAKEUP pin and the PWRUP pin high to enable all output rails.
• Set the HiZ bit in the VCOM2 register. This puts the VCOM pin in a high-impedance state.
• Drive the panel with the Null waveform. Refer to E-Ink specification for detail.
• Set the ACQ bit in the VCOM2 register to 1. This starts the measurement routine.
• When the measurement is complete, the ACQC (Acquisition Complete) bit in the INT1 register is set and the nINT pin is pulled low.
• The measurement result is stored in the VCOM[8:0] bits of the VCOM1 and VCOM2 register.
The measurement result is not automatically programmed into nonvolatile memory. Changing the power-up default is described in the following paragraph.

8.3.7.2 Storing the VCOM Power-Up Default Value in Memory
The power-up default value of VCOM can be user-set and programmed into nonvolatile memory. To do so, write the default value to the VCOM[8:0] bits of the VCOM1 and VCOM2 register, then set the PROG bit in VCOM2 register to 1. First, all power rails are shut down, then the VCOM[8:0] value is committed to nonvolatile memory such that it becomes the new power-up default. Once programming is complete, the PRGC bit in the INT1 register is set and the nINT pin is pulled low. To verify that the new value has been saved properly, first write the VCOM[8:0] bits to 0x000h, then pull the WAKEUP pin low. After the WAKEUP pin is pulled back high, read the VCOM[8:0] bits to verify that the new default value is correct.

(plus a block diagram and flowchart)

Simples

[jkelol111]

Originally Posted by DomesticExtremis

Relevant section of the datasheet:


Simples

"Simple"

How does the software side of things work with this stuff though?