MobileRead Forums - View Single Post

GreatMagicalHat · 08-03-2019, 04:22 AM

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:

Code:

#!/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?

08-03-2019, 04:22 AM	#1
GreatMagicalHat Junior Member Posts: 5 Karma: 10 Join Date: Aug 2019 Device: Kobo Aura	Setting VCOM 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: Code: #!/bin/sh input=${1#-} #echo $input big=`echo ${input} \|awk '{printf "%.2f\n",$1100+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?