Related
I've been working on fixing this issue for awhile. Here's the deal:
The problem.
The four keys at the bottom of the phone are monitored by a melfas touchkey chip (http://www.melfas.com/english/touch/sensor.asp) that connects to the main processor via an I2C bus (http://en.wikipedia.org/wiki/i2c). The melfas chip generates an interrupt whenever one of the keys is touched or released. The processor then reads the key value from this chip over the i2c bus. The problem is that the touchkey chip is located right next to the 3G antenna. When the phone is accessing the 3G network the RF energy gets transferred to the interrupt and i2c clock and data lines causing false interrupts to occur. The processor responds to the interrupt by reading the key value from the cypress chip. The symptoms occur more frequently in low signal areas because the phone outputs a higher RF level in those situations which causes more RF interference on the interrupt line.
Most of the time when a false interrupt has occurred the touchkey chip will return a value of zero for the key and the driver will recognize this as a bad key press and ignore it. Sometimes the RF interference on the i2c clock and/or data line causes a valid value to be returned and the driver reports a key press value to the application. In the case where the driver reports a ‘back’ key down, the software sees this as holding the back key down so when you press the power button you get a screen shot. The easiest way to cure this is to always press and release the back key before pushing the power button. This causes the software to see both a key down and key up event which cancels the screenshot mode.
This RFI induced touchkey interrupt happens hundreds of times per second when the phone is using 3G. It produces lots of different symptoms including applications that always seem to shut down. A wide variety of problems can be attributed to this failure. In addition, the processor spends a lot of time servicing these bogus interrupts, which take cpu time away from the other applications. This can make the phone appear to be slow or even freeze up for short periods of time. There’s a good chance that most people have experience this to some degree without realizing the root cause.
Solution one. Fix the driver.
Since this is a true hardware failure, a software solution is going to be less than perfect. After dozens of experiments rewriting the interrupt service routines in the driver I’ve settled on a combination of fixes. The first is to re-test the interrupt input line several times. In normal operation when you touch or release a button, the touchkey chip drives the interrupt line low and keeps it low until the driver reads data over the i2c interface. Since the RF interference is a sine wave and is being sampled it causes the interrupt line to go high and low at a fast rate. Sampling the line multiple times in software increases the chance of finding it in the high state. This is done both in the interrupt handler and then again in the interrupt thread. About 90% of the false interrupts are filtered out by testing the line in the handler. If the interrupt handler doesn’t find the line high after 10 samples, it masks the interrupt so that another falling edge doesn’t produce another interrupt. In testing I’ve noticed that the interrupt handler would run multiple times before the interrupt thread was even called. Once in a while, so many interrupts would get stacked up that the phone would just reboot. It was probably a stack or buffer overflow that wasn’t being handled. Remember, this interrupt would happen many hundreds of times a second. About 90% of the remaining false interrupts are filtered out by sampling this line in the thread. That leaves about 1% of the interrupts that need to be further tested. The second test is to read the data from the chip and discard anything that isn’t a valid key press value. This is easily done with a case statement. Finally, since occasionally a bogus valid value will get through, I set up a timer so that any key down event that doesn’t have a corresponding key up event within 3 seconds is canceled by calling the all_keys_up routine.
This combination all but eliminates the symptoms produced by this failure. The only draw back is that the processor still spends a considerable amount of time servicing the false interrupts. And rarely a phantom keypress does get through. In all, it’s a fairly good piece of duct tape and JB Weld.
During my experiments I used a copy of the kgb kernel. My version with the modified driver is in github at https://github.com/dmriley/kgb. If you want to try this yourself, be sure to use the ‘dev’ branch.
Solution two. Fix the hardware.
There are three signals that connect from the melfas touchkey chip to the processor. They are the two i2c lines: sdc which is the clock and sda which is the data. The third line is the interrupt. In troubleshooting this problem, I took my phone apart and put oscilloscope probes on the three lines. This allowed me to see the real cause of the problem. Since the interference is RFI (or EMI) the only real way to fix the problem is to either remove the RF or make the impedance of the signals much lower. Removing the RF is easy if you don’t need to use 3G. When the phone is using wifi (or no network connectivity at all) the problem does not exist. Also, when you are very close to a cell tower, the phone transmits at a much lower level. This lower level greatly reduces the RFI. Lowering the impedance is a little harder. I2C uses active pull down and passive pull up for the logic levels for both sda and sdc. This means that the impendence is mostly governed by the pull up resistor. This resistor value is typically upwards of 1kohm and probably as high as 3kohms (I didn’t measure it in this phone). Since the impedance only needs to be lowered for the 3G frequencies of around 800MHz, a capacitor can be added from the signal source to signal ground. At 800MHZ a 100 pf cap is about 2 ohms (1/ 2*pi*f*c). That’s a couple of orders of magnitude lower than the pull up resistor alone, and much too low for the RF signal to induce any significant voltage on the line. This value is also low enough not to interfere with the signal rise and fall times for the interrupt line. In the case of the interrupt line, the melfas chip drives the signal low and keeps it low until the interrupt is serviced. Discharging a 100pf cap with a 2mA driver takes only microseconds. This much delay is not noticeable when touching the key and is much less than the amount of time that the processor takes to service the interrupt.
Adding the cap to the interrupt line eliminates false interrupts. A chance does exist that a valid key event during 3G access could cause an incorrect key value to be returned due to RFI on the clock and data lines. The i2c protocol is designed to compensate for capacitive loading on the lines. Although it would cause the clock period to be stretched out significantly it would still only take milliseconds to read the key data from the chip. The difference would be imperceptible. To date I have only added the cap to the interrupt line and have yet to experience an invalid key press.
I’ll post pictures of cap mod.
Summary.
Most people will be satisfied using the software fix. I think that a couple of the kernel devs are incorporating some or most of the driver mods outlined in this document. Both comradesven (kgb dev) and ssewk2x aka Efpophis (glitch dev) were involved in the test and debug process. Much appreciation is given to both of them for the help that they gave me and for allowing me to use and hack up their code on github. Efpophis saved me hours of searching through code. Without their help, I’d still be unable to build a kernel.
UPDATE:30 Mar 2012
The phone had been working fine since the mod. I hadn't seen a screen capture or any of the other symptoms. Then, a couple of nights ago, while I running maps on 3G (a data intensive app) the touchkey backlights started flashing rapidly like the phone was having a little seizure. And then it happened, the voice search popped up. A couple of debug kernels later I've come to the conclusion (and I'm never wrong) that the clock line (SCL) going to the melfas chip was being toggled by the same RF interference that was causing the false interrupts. A random clock along with random data was causing the chip to turn the backlights on and off as well as generate a false interrupt. I was able to reliably duplicate the problem in a couple of really low signal level areas (not hard to find when you live out in the boonies).
I tore the phone apart (again) today and added a 100pf cap to the scl line right next to the chip. I also added another cap in parallel with the 100pf on the interrupt line. I spent about 1/2 hour tonight running 3G data apps in the same location where the problem first appeared. So far, no problems and none of the debug messages have shown up on dmesg.
If anyone wants pics of the added cap I'll open it back up, no problem, otherwise if you look at this photo you can see which pin is scl (although I incorrectly labeled it SDC in the photo). http://forum.xda-developers.com/attachment.php?attachmentid=953824&d=1332117055
If anyone tries these mods I'd be real interested in your results.
Here are some pictures of the cap mod:
this is the open phone showing where the melfas touchkey circuit is:
View attachment 951774
Awesome, thanks for doing this for all of us. Phantom key press is really annoying
Sent from my SCH-I500 using XDA App
the cap. yeah, that's a normal size pen to show scale
View attachment 951812
on the board
View attachment 951821
with notes
View attachment 951820
the antenna problem
View attachment 951822
close up showing touckey circuit. micro sd card for scale
View attachment 951834
my finger
View attachment 951836
back off
View attachment 951838
another view
View attachment 951837
BTW, I took these pictures with my son's fascinate
Wow, we're lucky to have someone as capable as yourself figure out this annoying issue! I've kinda kept up on your work, but seeing this breakdown and the photos is helpful in understanding the root cause of the problem. I do wonder sometimes how Samsung missed this issue in their testing, but at least we have custom kernels that implement your fixes and dramatically reduce the phantom presses!
Uuuhm...You're an awesome human being. Holy crap. -_-
That's some amazing work, thanks!
k_nivesout said:
.... I do wonder sometimes how Samsung missed this issue in their testing, but at least we have custom kernels that implement your fixes and dramatically reduce the phantom presses!
Click to expand...
Click to collapse
Yeah, it's crying shame that Samy couldn't fork over the extra penny to keep this problem from happening in the first place.
sendan said:
Uuuhm...You're an awesome human being. Holy crap. -_-
That's some amazing work, thanks!
Click to expand...
Click to collapse
wasn't just me. had help from other members here. I didn't even know where to start looking when I first started. It's so cool that people are willing to do the level of work that the devs here do without expecting anything back.
electric bill said:
wasn't just me. had help from other members here. I didn't even know where to start looking when I first started. It's so cool that people are willing to do the level of work that the devs here do without expecting anything back.
Click to expand...
Click to collapse
Thanks so much for all the work, and the detail in your post. It is amazing the work everybody does here and the knowledge you pass on to us.
I do have a few questions
Would you mind sharing what kind off iron you used? is that the most bottom line on the board you soldered to? If so, did you have to scratch it or something first? Is it the farthest left line on the chip that was used? Do they make caps that size with leads coming of the 2 sides, and if so would that be a easier mod? Is there a positive and negative side to that capacitor?
I'm really thinking about doing this, if i decide to would you mind sending me 5 of your extra caps for a $10 donation?
Sent from my SCH-I500 using xda premium
Ditto on the $10.00
neh4pres said:
Thanks so much for all the work, and the detail in your post. It is amazing the work everybody does here and the knowledge you pass on to us.
I do have a few questions
Would you mind sharing what kind off iron you used? is that the most bottom line on the board you soldered to? If so, did you have to scratch it or something first? Is it the farthest left line on the chip that was used? Do they make caps that size with leads coming of the 2 sides, and if so would that be a easier mod? Is there a positive and negative side to that capacitor?
I'm really thinking about doing this, if i decide to would you mind sending me 5 of your extra caps for a $10 donation?
Sent from my SCH-I500 using xda premium
Click to expand...
Click to collapse
I did the mod at my workplace under a microscope. I used a metcal (http://www.okinternational.com/product_soldering/mx500) soldering iron but you could use just about any low wattage iron with a really fine tip.
There's four pins on each side of the melfas chip. One end of the cap is soldered right to the interrupt pin which is the closest to the corner. the other end is connected to the ground side of C2 via a solder bridge.
View attachment 953824
I doubt that they make caps that small with leads on them. You could look. It's not hard to make the solder bridge. Remember the scale that were talking about here. That cap is 0.06 inches long by 0.03 inches wide. I wouldn't try to scratch the solder resist from the board because it's a flex circuit on top. Also, the cap is not polarized.
I bought a hundred of these caps for less than $6 including shipping. I'd feel terrible charging someone $10 for five. If you pm me your address I'll stick a couple in an envelope and send them. If you want to give away ten bucks, donate it to a charity like destiny rescue or UMCOR (http://new.gbgm-umc.org/umcor/about/financialinformation/).
Disclaimer:I've been working with parts this size for years and am pretty good at soldering. You risk dorking up your phone if you don't do this correctly. Only attempt if you are skilled at soldering. All information is presented "as is" and without warranty for fitness or use. Your mileage may vary. Void where prohibited, taxed or licensed.
What is the easiest way to implement the band-aid software fix?
I am on CSpire so there are not many proven custom roms out there.
IamUmpire57 said:
What is the easiest way to implement the band-aid software fix?
I am on CSpire so there are not many proven custom roms out there.
Click to expand...
Click to collapse
The fix is in the kernel. I used the KGB kernel as the source for my build. You can download it from github and build your own. If you're running all stock (rom & kernel) you can mod the stock kernel.
I'm really not the expert here on choices. Maybe someone else could chime in.
Too tiny to solder so band-aid?
Excellent research, fix and documentation. I was going to follow the fix, but, when I finally got the phone disassembled, I saw that the bits were much too small for me to solder. And I'm an ex-electronics guy who's worked on surface mount stuff before, so I doubt amateurs will have much luck, either.
So the problem is that RFI is hopping onto the I2C and interrupt lines... Could we just block the RFI? Sure. A grounded piece of aluminum foil which covered the whole Melfus+lines area should do that. So I tried that. Worked great for the soft keys, but, for reasons not apparent to me, my phone would no longer do 3G (stuck in 1X). Perhaps because the big old piece of grounded foil in the middle of the 3G antenna soaked up too much signal?
How about not grounding the Aluminum foil? It wouldn't be tied to ground, so the potential of the Alu foil would wobble, but it might prevent enough RFI from reaching the I2C and interrupt lines.
I opened the phone back up and squished the Alu foil a bit so that it just covered the Melfus chip and the lines heading to the left, and so that it didn't touch what-I-think-is the ground plane right at the upper edge of the PCB. Now, the piece of Alu foil was a rectangle about 6mm wide and 3mm tall. Seems to prevent softkey misfires and my phone seems more responsive. Assuming the results hold, this is a 5 minute fix for the issue and it doesn't require anything more than a tiny screwdriver, a spot of aluminum foil and a moderately steady hand. Wish me luck!
CoffeeDregs said:
Excellent research, fix and documentation. I was going to follow the fix, but, when I finally got the phone disassembled, I saw that the bits were much too small for me to solder. And I'm an ex-electronics guy who's worked on surface mount stuff before, so I doubt amateurs will have much luck, either.
So the problem is that RFI is hopping onto the I2C and interrupt lines... Could we just block the RFI? Sure. A grounded piece of aluminum foil which covered the whole Melfus+lines area should do that. So I tried that. Worked great for the soft keys, but, for reasons not apparent to me, my phone would no longer do 3G (stuck in 1X). Perhaps because the big old piece of grounded foil in the middle of the 3G antenna soaked up too much signal?
How about not grounding the Aluminum foil? It wouldn't be tied to ground, so the potential of the Alu foil would wobble, but it might prevent enough RFI from reaching the I2C and interrupt lines.
I opened the phone back up and squished the Alu foil a bit so that it just covered the Melfus chip and the lines heading to the left, and so that it didn't touch what-I-think-is the ground plane right at the upper edge of the PCB. Now, the piece of Alu foil was a rectangle about 6mm wide and 3mm tall. Seems to prevent softkey misfires and my phone seems more responsive. Assuming the results hold, this is a 5 minute fix for the issue and it doesn't require anything more than a tiny screwdriver, a spot of aluminum foil and a moderately steady hand. Wish me luck!
Click to expand...
Click to collapse
That's great work. I tried that initially with some foil tape over the whole melfas chip without success. This was all documented in the github problem log but it got deleted when the ticket was closed out. In my basement where I was doing my testing, the signal strength is very low so it's a worst case scenario. Maybe the shield will work better if it's shaped just right. I'm not an RF guy so my shield was just a guess. Share some pics with us if you find a solid solution. The shield would be much easier to implement.
electric bill said:
I tried that initially with some foil tape over the whole melfas chip without success.
Click to expand...
Click to collapse
What was not successful about it? You still had phantom keypresses or you lost 3G?
Also, how did you ground the foil? I grounded it against what I thought was a ground plane. And I covered the entire L-shaped assembly (Melfas, lines and all).
[Stating the obvious...:] The idea of covering the Melfas chip and lines with foil assumes that the RFI is getting to the lines from above the chip+lines. The foil wouldn't do anything were the RFI hopping over from elsewhere. But AFAICT the top layer of the PCB is a ground plan and the signal lines head down into buried layers directly from the connector, so I'm not sure how else RFI could get the I2C lines except from in the module...
My un-grounded foil seems to be an improvement, but not a fix, so I might try grounded-foil again and try to figure out why it killed my 3G.
Good to hear that you have a microscope; I still have 20/20 vision as a 40yo, but that's a tiny little area!
I gotta say that I am wildly disappointed in Samsung. If a few electronics-savvy folks polking around the interwebs can find root cause and propose multiple fixes, it's shocking that Samsung won't acknowledge it, much less fix it. I'm due a phone upgrade and I'd love to get an SGS III, but I really don't trust Samsung.
CoffeeDregs said:
What was not successful about it? You still had phantom keypresses or you lost 3G?
Also, how did you ground the foil? I grounded it against what I thought was a ground plane. And I covered the entire L-shaped assembly (Melfas, lines and all).
[Stating the obvious...:] The idea of covering the Melfas chip and lines with foil assumes that the RFI is getting to the lines from above the chip+lines. The foil wouldn't do anything were the RFI hopping over from elsewhere. But AFAICT the top layer of the PCB is a ground plan and the signal lines head down into buried layers directly from the connector, so I'm not sure how else RFI could get the I2C lines except from in the module...
My un-grounded foil seems to be an improvement, but not a fix, so I might try grounded-foil again and try to figure out why it killed my 3G.
Good to hear that you have a microscope; I still have 20/20 vision as a 40yo, but that's a tiny little area!
I gotta say that I am wildly disappointed in Samsung. If a few electronics-savvy folks polking around the interwebs can find root cause and propose multiple fixes, it's shocking that Samsung won't acknowledge it, much less fix it. I'm due a phone upgrade and I'd love to get an SGS III, but I really don't trust Samsung.
Click to expand...
Click to collapse
Yeah, I used what I thought was a ground pad and covered pretty much everything on that little flex board that has the chip on it. It didn't stop the problem. Also, I had a bunch of dmesg stuff in the driver so I could see every time that there was a "missfire" vs just seeing the actual symptoms. A shield could theoretically fix the problem, I'm just not a RF engineer so I went with what I know. With the microscope, it's pretty easy to add the caps. Without, it'd be kinda hard. It probably only took me 20 minutes or so to do the last one I did. The good news it, the cap fix does the trick 100%. We've been running it on three phones without a problem for a few months now.
I totally agree on Samsung's failure. That design defect should have been caught pretty early in development. Maybe these guys have never heard of a Peer Review . It's even sadder if they knew it might be a problem but decided to risk it to save 1/2 cent per phone.
I understand the corporate mentality of denying a problem exists (iphone signal loss is a good example). If they admit it, then they have to fix it and that would be very costly. I'm sure when they started to have a problem they did a cost analysis and decided that losing N number of customers was cheaper than actually fixing all the bad phones.
What made it even worse was trying to find info on the phone design. Samsung was completely unresponsive when I contacted them to get data sheets on the CPU and other info on the phone. It's as if they didn't want me to solve the problem. Come to think of it, they probably didn't want me to. Solving it verifies that the problem exists and isn't just user error.
Anyway, now with my phone fixed and the excellent AOKP ROM and Glitch kernel, I love my fassy.
electric bill said:
Yeah, I used what I thought was a ground pad and covered pretty much everything on that little flex board that has the chip on it. It didn't stop the problem. Also, I had a bunch of dmesg stuff in the driver so I could see every time that there was a "missfire" vs just seeing the actual symptoms. A shield could theoretically fix the problem, I'm just not a RF engineer so I went with what I know. With the microscope, it's pretty easy to add the caps. Without, it'd be kinda hard. It probably only took me 20 minutes or so to do the last one I did. The good news it, the cap fix does the trick 100%. We've been running it on three phones without a problem for a few months now.
I totally agree on Samsung's failure. That design defect should have been caught pretty early in development. Maybe these guys have never heard of a Peer Review . It's even sadder if they knew it might be a problem but decided to risk it to save 1/2 cent per phone.
I understand the corporate mentality of denying a problem exists (iphone signal loss is a good example). If they admit it, then they have to fix it and that would be very costly. I'm sure when they started to have a problem they did a cost analysis and decided that losing N number of customers was cheaper than actually fixing all the bad phones.
What made it even worse was trying to find info on the phone design. Samsung was completely unresponsive when I contacted them to get data sheets on the CPU and other info on the phone. It's as if they didn't want me to solve the problem. Come to think of it, they probably didn't want me to. Solving it verifies that the problem exists and isn't just user error.
Anyway, now with my phone fixed and the excellent AOKP ROM and Glitch kernel, I love my fassy.
Click to expand...
Click to collapse
Yeah: dmesg would be lots better!
My foil status: decent. I'm getting a lot less buzzing, but I still do get **some** in low signal areas (my bedroom). So I'm happier.
Samsung's response: I'm not at all surprised. I used to be an FAE for Cirrus Logic and worked a lot with ARM processors (back in 2000-2003). I got ahold of some of Samsung's datasheets on their ARM processors and was staggered: the datasheet was about 4 pages long and was full of errors, inaccuracies or glossings-over. Our datasheets were 40 pages long and we had 200 page programming manuals available on the web. You got no love from Samsung unless you were looking to buy 5M chips.
Anyways, thanks for you research and help!
I'll be giving that kernel a shot!
Second cap
I finally got around to mod'ing our last phone. Actually, I was finally able to pry it from my teen's hands long enough to do the work. I think she sat home all afternoon and twitched.
Anyway, here's a pic of the two caps. One is on the interrupt line and the other is on the clock (or scl) line. I melted the insulation from a piece of real fine magnet wire to connect between the clock pin and the second cap. The other end of the second cap is just solder bridged to the same ground as the first cap.
Hi folks,
after some years of extensive usage my Milestone needs a companion
I'm new to the xperia 2011 platform and bought myself a Xperia Pro some days ago.
Right now i'm in the process of fixing the backlight, but in a few days i'm ready to rock...
I really like devices with a hardware keyboard and it's a shame that these devices leave the scene (even more in the EU).
Anyway enough talking...
I'm not the guy who ignores the search function, but i got some specific questions and hopefully someone will put some light on that.
I know as well that we are nearly in the year 2013 and these devices are not up to date, but it's O.K. for me.
In fact there are enough features on this phone and i don't need a heater in my pocket
SoC:
As i looked everywhere there's still no datasheet or register manual floating around...
Apart from the architecture is the MSM8255 comparable to the old MSM7200 if you look at the basic function?
In short:
- memory map ?
- booting scenario: arm9 boots first then armV7 comes up?
EDIT:
It seems these questions are little bit to deep... just asked for curiosity though.
I guess i'll step through kernel code and compare some of the offsets with MSM7200 (we got register manual here).
The background is that i'd like to check some register contents for debugging at a later point...
CWM:
If i got it right there's no true CWM recovery.img for the Pro, if i got it right the CWM is part of the system and loaded to RAM by helpers.
Right or wrong?
How does the partition scheme look like?
Kernel 3.x:
I realized there'd been some attempts to get a 3.x kernels running on these devices, as far as i could conclude from what i read, the situation is as follows...
- SE left the path of standard kernel API, that's why some proprietary libs will always be required (and won't fit 3.x kernel). Right or wrong?
- HDMI part seems to be a problem... but what exactely... kernel driver is missing parts or system lib?
EDIT:
O.K. no answer here from the experts right now...
BTW, just saw the FreeXperia team has opened up a new project for porting 3.4 kernel to 2011 devices
See:
http://forum.xda-developers.com/showthread.php?t=2044262
Guess i'll ask some techie stuff over there :angel:
USB host function:
AFAIK there's no 5V power at the the OTG, but there are drivers for mouse and keyboard etc.
Just in short how does it work?
External Hub?
EDIT:
O.k. i missed some thing... datasheet of BQ24185 (connected to MicroUSB VBUS signal) gave the answer:
Code:
VBUS A1, A2 I/O Charger Input Voltage. Connect to an input supply up to 16V. Bypass VBUS to PGND with a 1μF ceramic
capacitor. [I][B]During boost mode, VBUS is regulated to 5V at up to 300mA to power USB OTG peripherals[/B][/I].
In other words, while in OTG host mode the charger is run in boost mode (could be found in the kernel board file as well).
For the peripheral drivers...
http://forum.xda-developers.com/showthread.php?t=1224676
Debug UART3:
Does anyone know anything about UART3 testpoints on the mainboard?
Code:
static struct msm_gpio uart3_config_data[] = {
{GPIO_CFG(53, 1, GPIO_CFG_INPUT, GPIO_CFG_PULL_UP, GPIO_CFG_2MA),
"UART3_Rx"},
{GPIO_CFG(54, 1, GPIO_CFG_OUTPUT, GPIO_CFG_NO_PULL, GPIO_CFG_4MA),
"UART3_Tx"},
};
EDIT:
Mmmmh still unsolved... though that these signals were routed to the testpoint area as well.
After doing some measurements this could not be confirmed right now.
Background here:
Would be nice to get serial console with a nice little adaptor for low level kernel debugging.
If someone knows...
ROMs:
Same as usual... but maybe you could give some advice...
I'd like to try a stripped down stock ICS first... don't need all these visual effects but a stable system and using the HDMI would be nice as well.
Any suggestions here?
EDIT:
O.k. i'm little impatient... so i need to look for a light ROM myself
O.k. that might be it at the first sight. I guess i'll need to play around with the device a little bit, when it's functional again.
Thank's a lot for your patience and have fun!
scholbert
After receiving my G4 last week and digging into it, I found that LG is once again dual-sourcing (JDI and in-house LGD) panels for the G4, and that all most verifiable touchscreen issues I have recorded have been on JDI panel equipped devices (EDIT: Though the vast majority were JDI, there was at least one LGD with the same issue). The problem itself is EMI/noise related and is remedied by a solid path to ground (plugging it in, good contact with your hand, etc).
I have verified this with a few dozen phones so far, but more data would be helpful. If you're going to, however, please don't post if you just feel that your touchscreen isn't as responsive as you'd like (missed taps, etc). There's too much room for error there. To verify that your device has the issue, it is best to count the number of discreet touch events it can register both while unplugged and plugged-in/grounded. If your device has the issue, you will only get 5-6 before failure while unplugged and 10 while plugged-in. You can use the free app Display Tester from the play store to check.
As for determining which panel you have, the easiest way is to check your kernel message buffer immediately after boot using dmesg. If you're rooted you can do this on the device, if you aren't rooted you can use adb.
Code:
dmesg | grep -i panel
The oem will be in your kernel command line, panel name, etc.
NOTE: Though it appears that there is a hardware element to this issue, I do think it's possible that LG could fix it in the touch driver with a software update. I personally haven't updated to the firmware that was reported to fix this on my variant (vs98612a) as it was pulled, so I can't say firsthand.
LG panel here. Just tested with display tester. While holding the phone in my hand it recognizes multiple fingers easily.
However if I lay down the G4 on whatever ground/table (it doesn't matter) it barely recognizes two fingers, the second one has to be pushed harder to get it recognized by the screen. Three fingers and it's game over. Really strange. So now I know why it was always difficult using the phone i.e. at work when I wanted to "passively" check whats going on. Most of my touches and swipes (even with one finger) were more prone to erratic behaviour while the pone was laying on my desk.
I am using LG's 6.0 MM by the way with S3V3n's rooted kernel and unlocked bootloader btw. Also there is a tempered glass protector on my screen.
Check the terminal log below for reference regarding my screen type (LGD).
[email protected]:/ $ su
[email protected]:/ # dmesg | grep -i panel
[ 0.000000 / 01-01 00:00:00.000][0] Kernel command line: sched_enable_hmp=1 sched_enable_power_aware=1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 androidboot.selinux=permissive msm_rtb.filter=0x37 androidboot.hardware=p1 lge.rev=rev_10 model.name=LG-H815 lge.sim_num=1 lge.battid=SW3800_VC0 lge.bootreason=Reboot_by_PowerKey maxcpus boot_cpus=0-5 kswitch cc_mode=0 androidboot.bl_unlock_complete=true androidboot.dlcomplete=0 gpt bootcable.type=NO_INIT androidboot.ddr_info=0x3b000206 fakebattery=disable lge.bootreasoncode=0x77665501 lge.hreset=off fips_allow_others=1 fips_panic=0 fips=0 androidboot.bootdevice=f9824900.sdhci androidboot.serialno=LGH8157479244e lge.signed_image=false lge.dsv_id=DW androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_lgd_r69007_1440p_mipi0_cmd:1:qcom,mdss_dsi_lgd_r69007_1440p_mipi1_cmd
[ 0.766209 / 01-01 00:00:00.759][4] mdss_dsi_panel_init: Panel Name = LGD INCELL 1440p Dual 0 cmd mode dsi panel
[ 0.766220 / 01-01 00:00:00.759][4] lgd_qhd_command_mdss_dsi_panel_init: panel_type is LGD_INCELL_CMD_PANEL
[ 0.766229 / 01-01 00:00:00.759][4] panel_type is 2
[ 0.766364 / 01-01 00:00:00.759][4] mdss_dsi_panel_timing_from_dt: found new timing "qcom,mdss_dsi_lgd_r69007_1440p_mipi0_cmd" (ffffffc0c56a38a8)
xdabbeb said:
After receiving my G4 last week and digging into it, I found that LG is once again dual-sourcing (JDI and in-house LGD) panels for the G4, and that all verifiable touchscreen issues I have recorded have been on JDI panel equipped devices.
Click to expand...
Click to collapse
It took just one reply to disprove that
The problem itself is EMI/noise related and is remedied by a solid path to ground (plugging it in, good contact with your hand, etc).
Click to expand...
Click to collapse
which will apply regardless of where the panel was sourced. A phone with a curve isn't really ideally suited to be operated on a flat surface anyway.
I've noted this tendency to point out where a component comes from here on the boards and this then gets extrapolated into something bad. i would not interpret a non-oem panel as a problem whatsoever.
components are sourced when required from suppliers that can build to scale. They are equivalent for all intents and purposes.
it should not make a bit of difference whether the panel is LG or JDI. If it does then it just means you 'may' have a defective panel. This can happen with either source.
I think you may be on to something. I got the JDI panel, and I noticed that if I use a touch tester app, it can only register 5 touches successfully when unplugged. The 6th touch causes it to lose all touch points. However, when it's plugged into power, it can register 10 touches without a problem.
Not that I need more than 5 touch points, but is this normal behavior for a digitizer to do that? Looks to me like this is something that could be tweaked in the driver. Would be interesting to know by someone with Verizon software 12A (I am on 11A) if they notice the same issue that their device only registers 5 touches max, or if that is something that has been addressed. I am really getting ticked off by Verizon peddling around and not being able to provide the update every other G4 user already has received. At this point, I am hoping xdabbeb's efforts of coming up with a fix for the 11A version bear some fruits.
One Twelve said:
It took just one reply to disprove that
Click to expand...
Click to collapse
Actually, no...given the individual's report of not even being able to register 2 touches that sounds more like a hardware failure than what is being investigated here.
which will apply regardless of where the panel was sourced. A phone with a curve isn't really ideally suited to be operated on a flat surface anyway.
Click to expand...
Click to collapse
I don't believe I mentioned laying it flat on a table as part of this test, but, yes, a curved phone isn't suited to that.
I've noted this tendency to point out where a component comes from here on the boards and this then gets extrapolated into something bad. i would not interpret a non-oem panel as a problem whatsoever.
components are sourced when required from suppliers that can build to scale. They are equivalent for all intents and purposes.
it should not make a bit of difference whether the panel is LG or JDI. If it does then it just means you 'may' have a defective panel. This can happen with either source.
Click to expand...
Click to collapse
I was actually quite careful in making no judgment in this regard. The words 'bad' and 'defective' were only used by you, actually. I personally don't care what panel was/is used and even stated that given the nature of the problem I feel a software fix is certainly possible.
Though there will be a tendency with any device that has a large scale issue such as this to (sometimes blindly) grasp at finding the cause, the purpose of this was to gather more information, not incite a witch hunt. I personally gathered over 3 dozen logs/reports that supported this before posting, and felt that this was the best way to get more.. I have no horse in this otherwise. I have noted tendencies of contrarianism and gross generalization, but it's the Internet...You're going to get that
@konradsa the qfuse situation makes investigating that more problematic, but that's precisely what I'm looking into next.
@konradsa the qfuse situation makes investigating that more problematic, but that's precisely what I'm looking into next.
Click to expand...
Click to collapse
Thanks, appreciate your efforts and looking forward to your results.
konradsa said:
I think you may be on to something. I got the JDI panel, and I noticed that if I use a touch tester app, it can only register 5 touches successfully when unplugged. The 6th touch causes it to lose all touch points. However, when it's plugged into power, it can register 10 touches without a problem.
Click to expand...
Click to collapse
Same problem with LGD panel.
random_word said:
Same problem with LGD panel.
Click to expand...
Click to collapse
If it was exactly the same then that settles it. Thanks for the report. Closing the thread.
We are in the process of developing a *Mezzanine* board for 96boards CE SBCs. The purpose of this board is to implement the complete interface between the standardized SBC, and pretty much any car.
*Note: This is not a feature discussion thread, the features are set, the prototypes are built, painstakingly by hand over many hours.
The mezzanine board has the following (primary) features;
Quad-stereo ADC,
2 stereo DAC with programmable DSP (also has a header for up to 2 more DACs for up to 8 channel audio),
AMFM Radio,
OEM-style class AB automotive amplifier (4x52 watt @ 4 ohm, 4x85 watt @ 2 ohm),
ATSAMD21 microcontroller for SWI, fan control (fan is not mandatory), backlight control, etc.,
Physical interface to a conventional vehicle specific automotive pigtail.
This would be the additional component recommendation (and we are also considering a KIT):
1) 96boards CE SBC. We have a current working prototype using a Hikey960 (4xA73 + 4xA53, 4 GB), and are in the process of obtaining a Dragonboard 820C (2x Kryo big + 2x Kryo little, 3 GB). Note that some CE SBCs may not have full compatibility due to lacking the optional digital audio input pin. These two I've mentioned have *FULL* compatibility, and we are providing software support.
2) An HDMI monitor with USB touchscreen. There are tons of options for these, including ones packed in a DDIN chassis.
3) A USB GPS (you can get really good ones for as little as $10). Note that the dragonboard 820c has a built-in GPS, although I haven't tested its performance.
4) A pigtail (sometimes called a "wiring harness") for your specific vehicle.
** you can also add a USB HUB and any number of UVC cameras for dashcam and/or parking assistance.
96boards is a specification for SBCs developed by Linaro. Linaro is one of the big promoters and developers of Linux based operating systems, including Android/AOSP. So what you get with this, is the ability to build the complete operating system for your car radio **from source**. Hikey960's device repository is hosted by Google and is listed as an official "Reference Board". The Dragonboard 820C's device tree is in heavy development and is not quite ready to merge, but is available on Linaro's repositories, and from what I'm told, is functionally in a very good state.
In addition, since we are interfacing with SBCs having a standardized interface, when the boards we are currently working with become dated (as everything eventually does), you can easily replace the SBC with a new one that is completely up to date, while retaining the Mezzanine that actually interfaces with the car.
We have also developed additions to the Hikey960 kernel and Android device tree for supporting our mezzanine board and enabling the Automotive features of AOSP. And yes, our additions are all open source, which means that you can build it all yourself.
We have not yet set a price point for the board, but I can tell you that it will not come cheap. The component and manufacturing cost is quite extensive. Our objective, however, is to provide two things to make up for that, which you simply can't get anywhere else;
1) A "high end" experience that is significantly higher than the expensive mainstream car radios (kenwood, pioneer, etc.)
2) Full control over the software, including complete source code. No locks on the hardware. No or minimal blobs. The Hikey960 runs on a single blob for the Mali GPU. The Dragonboard 820C runs on NO blobs -- it uses the Freedreno graphics driver.
Features of our prototypes;
1) Navigation. Uses Google Maps / Waze or any other nav software.
2) Hands free calling.
3) AMFM Radio.
4) Bluetooth music.
5) Dashcam.
6) Its running AOSP 8.1 -- the sky is the limit.
Also worth mentioning:
*** Designed in Canada.
*** Made in Canada or USA. Depends on how the pricing works out.
So, who is interested? What would you pay?
No support for lvds for the LCD? That would eliminate needing an HDMI converter.
It's also seems off that as designers you did not ask for input from the one community who this is targeted to, XDA...the point is to dig into the market currently dominated by the poor quality ODMs of Chinese head units.
Pricing...if it works well $300 to $500for the mezz and hikey as a bundle??? The dragon board is not interesting....you can't even run android on that. The hikey960 and 970 is a better choice, especially the 970 once things get going since it has GPS!
gtxaspec said:
No support for lvds for the LCD? That would eliminate needing an HDMI converter.
It's also seems off that as designers you did not ask for input from the one community who this is targeted to, XDA...the point is to dig into the market currently dominated by the poor quality ODMs of Chinese head units.
Pricing...if it works well $300 to $500for the mezz and hikey as a bundle???
Click to expand...
Click to collapse
LVDS is really not a viable option, because every different display will require extensive work to support, as well as, in many cases, a custom physical interface. If the goal was a single fixed product in a black box, then I would consider LVDS.
As a developer, I built it because I enjoy working on it. If I can sell it, so much the better.
96carboard said:
LVDS is really not a viable option, because every different display will require extensive work to support, as well as, in many cases, a custom physical interface. If the goal was a single fixed product in a black box, then I would consider LVDS.
As a developer, I built it because I enjoy working on it. If I can sell it, so much the better.
Click to expand...
Click to collapse
Makes sense! Well, great work anyways. Are we going to see any pictures anytime soon??? I have some empty 2 din cases,and A hikey960 I would love to try this on
gtxaspec said:
Makes sense! Well, great work anyways. Are we going to see any pictures anytime soon??? I have some empty 2 din cases,and A hikey960 I would love to try this on
Click to expand...
Click to collapse
I should have my next batch of prototypes (bare circuit boards) late next week or early the week after. I can post pics of the bare board, but if you're asking for pics of an assembled prototype, I'd rather not post pics of the currently running one on account of it really *looking* like a prototype (there are a few "corrections" on it).
Maybe what I'll do, is take pictures of one as I'm assembling it. I'm sure that some people would find it fascinating.
96carboard said:
I should have my next batch of prototypes (bare circuit boards) late next week or early the week after. I can post pics of the bare board, but if you're asking for pics of an assembled prototype, I'd rather not post pics of the currently running one on account of it really *looking* like a prototype (there are a few "corrections" on it).
Maybe what I'll do, is take pictures of one as I'm assembling it. I'm sure that some people would find it fascinating.
Click to expand...
Click to collapse
Very cool! If you need someone to test, always willing! I currently work on some ROMs for the Chinese based unita, but an opensource aosp unit has always been the goal (*_*)
So. Ils possible use stock screen from golf mk7 facelift with your headunit?
I'm very interested. It's something that i'm looking for a while now and will be willing to pay high-end price for high-end performance.
But it also need to be high-end "experience"... Meaning it requires a good looking radio app, physical volume control etc.
I would be also interested the hear about the display option that you found and how "high-end" this could be in term of screen quality but also dash integration?
Anyway, the mezzanine itself would be a huge step forward and I will frequently follow the 96boards website to see when it will be available.
A huge thanks for all the work you already did!
ti-b said:
I'm very interested. It's something that i'm looking for a while now and will be willing to pay high-end price for high-end performance.
But it also need to be high-end "experience"... Meaning it requires a good looking radio app, physical volume control etc.
I would be also interested the hear about the display option that you found and how "high-end" this could be in term of screen quality but also dash integration?
Anyway, the mezzanine itself would be a huge step forward and I will frequently follow the 96boards website to see when it will be available.
A huge thanks for all the work you already did!
Click to expand...
Click to collapse
The radio application is the AOSP automotive radio application https://android.googlesource.com/platform/packages/apps/Car/Radio/. How it looks really is between you and google. The objective, as far as software is concerned, is to change as little as possible with respect to AOSP. As far as physical volume controls go, the buttons on your steering wheel will work, or any other buttons, knobs, switches, or whatever else you might want to hook up.
First Assembly photo
Since I've got the software into a pretty good state now for running the previous board revision, I've now begun assembling my "V1.0". This revision is "very close" to what I will be shipping.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This board measures 123x78mm (under 5x3 inches).
U101 is a 3.3v very low dropout linear voltage regulator. It is used for powering all of the 3.3v components on the board, notably, the analog sides of all of the audio chips, which require a very clean and stable power supply, which is why its an LDO and not a buck.
Q101 is an N-FET, which controls the inhibit pin of the LDO. It takes input from either the microcontroller or the ignition signal. If they *both* switch off, then the LDO also switches off. D101 is a diode that prevents the microcontroller's output pin that drives Q101 from feeding to its input pin that reads the ignition signal.
U102,3,4 are optocouplers, used to read input signals from the car, which can vary within the range of 8-18 volts (though typically will be in the range of 11-15) and convert them into signals that are safe for the microcontroller and/or CPU. All three feed input pins to the CPU, U102 also feeds an input to the microcontroller.
The differences between this board and the final shipping board will be these;
1) There will be a 5th pin at J101, which will be connected to the "switched 12V output" of U203.
2) There will be two 3A diodes between the power input pins and J101.
** Together, these two changes will allow the board to be setup in a mode that allows the CPU and/or microcontroller to control power-off. J101 is a jumper block that allows the user to choose the mode of powering the system.
3) R203/204 are removed, since they are unnecessary.
4) The Anode of D701 is changed from 1.8v to 3.3v. This is to improve i2c performance of U701 (real time clock) and increase the charge on C701 (to increase the time the RTC can run for before the supercapacitor drains).
5) A zener diode is connected from the PWM pin of the fan plug to GND. This is to protect the microcontroller from excessive voltage that may be output by poor quality or incompatible fans. A good quality 5V PWM fan (like a Noctua) will pull the PWM pin up to no more than 3.3v. In fact, I checked with Noctua, and they pull it up to 2.5v. A low quality (cheap) fan may save a resistor by pulling it up to 5v, or a 12v fan could pull it up to anywhere between 3.3 and 12v. A 12v fan should not be used, but I'm sure that someone will plug one in anyway.
96carboard said:
Since I've got the software into a pretty good state now for running the previous board revision, I've now begun assembling my "V1.0". This revision is "very close" to what I will be shipping.
This board measures 123x78mm (under 5x3 inches).
U101 is a 3.3v very low dropout linear voltage regulator. It is used for powering all of the 3.3v components on the board, notably, the analog sides of all of the audio chips, which require a very clean and stable power supply, which is why its an LDO and not a buck.
Q101 is an N-FET, which controls the inhibit pin of the LDO. It takes input from either the microcontroller or the ignition signal. If they *both* switch off, then the LDO also switches off. D101 is a diode that prevents the microcontroller's output pin that drives Q101 from feeding to its input pin that reads the ignition signal.
U102,3,4 are optocouplers, used to read input signals from the car, which can vary within the range of 8-18 volts (though typically will be in the range of 11-15) and convert them into signals that are safe for the microcontroller and/or CPU. All three feed input pins to the CPU, U102 also feeds an input to the microcontroller.
The differences between this board and the final shipping board will be these;
1) There will be a 5th pin at J101, which will be connected to the "switched 12V output" of U203.
2) There will be two 3A diodes between the power input pins and J101.
** Together, these two changes will allow the board to be setup in a mode that allows the CPU and/or microcontroller to control power-off. J101 is a jumper block that allows the user to choose the mode of powering the system.
3) R203/204 are removed, since they are unnecessary.
4) The Anode of D701 is changed from 1.8v to 3.3v. This is to improve i2c performance of U701 (real time clock) and increase the charge on C701 (to increase the time the RTC can run for before the supercapacitor drains).
5) A zener diode is connected from the PWM pin of the fan plug to GND. This is to protect the microcontroller from excessive voltage that may be output by poor quality or incompatible fans. A good quality 5V PWM fan (like a Noctua) will pull the PWM pin up to no more than 3.3v. In fact, I checked with Noctua, and they pull it up to 2.5v. A low quality (cheap) fan may save a resistor by pulling it up to 5v, or a 12v fan could pull it up to anywhere between 3.3 and 12v. A 12v fan should not be used, but I'm sure that someone will plug one in anyway.
Click to expand...
Click to collapse
This looks exciting. Lot's of effort resulting in an Android system that is put together the way it should be. Many kudos.
If you are looking at making some changes you could save some cash by dropping the optocouplers. I know that it sounds like the craziest idea ever but I swear all you need to protect a MCU pin from the outside automotive world is a 220k resistor and a 100nF cap. Cap is on the side of the pin, resistor connects to the outside world. When I first started work at an automotive dev company I saw this arrangement and nearly fell off my seat. Turns out that almost every single MCU/CPU/device with an IO pin out there has a very simple protection cct on each pin which consists of two internal diodes per pin. Anode on the pin with cathode to VCC for the high side protection, anode on 0V and cathode on the pin for the low side protection. Some manufacturers just used a single zener with the anode on 0v and the cathode on the pin and this offered both high and low side protection. By putting the signal from the car through the 220k you technically are driving the pin such that the protection circuit is coming into play but the energy that you are driving into the circuit is SO low that the diode easily handles it and the VCC rail just sinks the tiny current elsewhere. The cap is there to protect against induced noise and very low energy but high voltage spikes that may appear on the input line. I was skeptical until I learned that this had been used on a high seller that was installed into over 3 million vehicles... After working there for 8 years I had designed it into every product I worked on and swore by it. Maybe give it a try. I swear it won't disappoint.
By far the largest killers of products that I found was overshoot caused by jump starting and installers making silly mistakes. Installers would often connect outputs directly to the items they were meant to drive instead of going through a relay first. Ever tried driving a horn with a FET? We ended up using some pretty neat protected FETs to solve this but they were costly. Another common installer error is incorrect polarity on the power lines or on the IGN/ACC line. Simply solved by putting diodes in series with the VCC and IGN/ACC inputs. The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
looxonline said:
This looks exciting. Lot's of effort resulting in an Android system that is put together the way it should be. Many kudos.
If you are looking at making some changes you could save some cash by dropping the optocouplers. I know that it sounds like the craziest idea ever but I swear all you need to protect a MCU pin from the outside automotive world is a 220k resistor and a 100nF cap. Cap is on the side of the pin, resistor connects to the outside world. When I first started work at an automotive dev company I saw this arrangement and nearly fell off my seat. Turns out that almost every single MCU/CPU/device with an IO pin out there has a very simple protection cct on each pin which consists of two internal diodes per pin. Anode on the pin with cathode to VCC for the high side protection, anode on 0V and cathode on the pin for the low side protection. Some manufacturers just used a single zener with the anode on 0v and the cathode on the pin and this offered both high and low side protection. By putting the signal from the car through the 220k you technically are driving the pin such that the protection circuit is coming into play but the energy that you are driving into the circuit is SO low that the diode easily handles it and the VCC rail just sinks the tiny current elsewhere. The cap is there to protect against induced noise and very low energy but high voltage spikes that may appear on the input line. I was skeptical until I learned that this had been used on a high seller that was installed into over 3 million vehicles... After working there for 8 years I had designed it into every product I worked on and swore by it. Maybe give it a try. I swear it won't disappoint.
By far the largest killers of products that I found was overshoot caused by jump starting and installers making silly mistakes. Installers would often connect outputs directly to the items they were meant to drive instead of going through a relay first. Ever tried driving a horn with a FET? We ended up using some pretty neat protected FETs to solve this but they were costly. Another common installer error is incorrect polarity on the power lines or on the IGN/ACC line. Simply solved by putting diodes in series with the VCC and IGN/ACC inputs. The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
Click to expand...
Click to collapse
It sound like you're describing the ESD diodes. Some might consider it slightly abusive to apply them in this manner, but I can definitely appreciate the application.
While I do know that the SAMD has this sort of arrangement on its input pins, I'm not sure whether this arrangement is present on the SoC or not -- my guess is probably NOT, and even if it is, I definitely can NOT trust that all 96boards SBCs will be equally protected. Only one of the optocouplers is even connected to the SAMD (the bottom one, IGN), all 3 optocouplers are connected to the SoC. If you will notice, there are two voltage dividers on the output of the bottom optocoupler -- R104/107 divides 5 volts down to 1.8 for the CPU, R113/114 divides 5 volts down to 3.3 for the microcontroller.
think widely
I suggest you to take a look at taho screen they don't replace the stereo they add a box that work as android with the oem stereo see youtube most of the new cars now a days comes with touch screen think widely take a look of the possibilities good luck
I will become a locale official vendor (if it has a affordable price and a excellent android support)
najaray said:
I suggest you to take a look at taho screen they don't replace the stereo they add a box that work as android with the oem stereo see youtube most of the new cars now a days comes with touch screen think widely take a look of the possibilities good luck
I will become a locale official vendor (if it has a affordable price and a excellent android support)
Click to expand...
Click to collapse
There would be nothing stopping you from using a built-in screen with this, as long as the built-in screen has an HDMI input -- which frankly, is quite unlikely, so I wouldn't get my hopes up.
In any case, that decision is outside of the scope of my project. The selection of display device would be up to whoever is installing it.
96carboard said:
There would be nothing stopping you from using a built-in screen with this, as long as the built-in screen has an HDMI input -- which frankly, is quite unlikely, so I wouldn't get my hopes up.
In any case, that decision is outside of the scope of my project. The selection of display device would be up to whoever is installing it.
Click to expand...
Click to collapse
I see it means that some of the customer like tahoe for example cannot use this product at all can you verify the cars that your targitting
can it run two screens at the same time like screen 1 for the stereo and a screen 2 for the car dashboard
najaray said:
I see it means that some of the customer like tahoe for example cannot use this product at all can you verify the cars that your targitting
Click to expand...
Click to collapse
I don't know what you mean by "tahoe" or "taho" as per your previous spelling, but it sounds to me like your questions are off topic. If you wish to continue this, please do so via PM.
looxonline said:
The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
Click to expand...
Click to collapse
Wouldn't all of these problems be solved with a TVS diode?
https://www.littelfuse.com/~/media/...utomotive_tvs_diodes_application_note.pdf.pdf
96carboard said:
Wouldn't all of these problems be solved with a TVS diode?
https://www.littelfuse.com/~/media/...utomotive_tvs_diodes_application_note.pdf.pdf
Click to expand...
Click to collapse
Yup, that's similar to the MOV solution. The problem with this type of solution is that it can create the clamp but it can't absorb all of the energy from the load dump (some, yes but not all). It therefore requires somewhere to dump the energy and that somewhere is in the resistance within the alternator and in the leads to the product. Our products could be installed in any location within the vehicle and in a huge variety of vehicles. Controlling the resistance between the alternator and the MOV (in our case) was impossible and this is one of the reasons why the MOV solution was abandoned. Another reason was cost. For a MOV that could handle the variation in conditions that our products were exposed to we had to go for a relatively high power variant. These could cost upwards of $2 which was insanity when you are talking about designing that into a circuit that is selling in excess of 60k units per month. The cut off circuit cost a fraction of that and so we ran with it
Fully operational:
This week the top of my touch screen became unresponsive.
So far I have tried the following:
1) Unplugged & re-plugged the 100cm screen cable at both ends.
2) Power cycled the stereo.
3) Tried various apps, but all have same issue with top 1cm touch area.
Any ideas ?
Is there a touch calibration somewhere ?
Thanks,
Pete
pwood999 said:
This week the top of my touch screen became unresponsive.
So far I have tried the following:
1) Unplugged & re-plugged the 100cm screen cable at both ends.
2) Power cycled the stereo.
3) Tried various apps, but all have same issue with top 1cm touch area.
Any ideas ?
Is there a touch calibration somewhere ?
Thanks,
Pete
Click to expand...
Click to collapse
Yes, it has touch calibration somewhere in the settings.
Any solution?
i have the same problem with my radio,
Andrewo30 said:
Any solution?
i have the same problem with my radio,
Click to expand...
Click to collapse
So have I now with my Sofia for the bottom 10% of the screen. The (re)calibrate screen fails constantly as the bottom right "bullseye" doesn't respond to my touches. I assume the digitizer is damaged requiring a new screen.
As I have now a PX5 and only one car, I won't take any action.
In your case I would contact Joying: [email protected]
Touchscreens communicate with the host using i2c protocol. This is a 2-wire serial protocol. One of the wires is a clock signal -- which is generated by the host (CPU), but which can be manipulated by both ends (i.e., pulled low by the device side) to indicate various conditions. The other wire is the data wire, where naturally, the actual data is transferred, subject to the clock signal and conditions indicated upon it. In addition, the touchscreen also uses an interrupt line to signal to the host that there is data to be read (because i2c does not allow the device to initiate data transfers -- it can only respond to requests from the host).
If either of those three wires is not working, then NOTHING on that bus will work. Well, the host could POLL the device for data if there is no interrupt line, but that isn't how you would normally program a touchscreen to work.
In other words, you cannot fix a partially working touchscreen by "reseating" the i2c lines, as you can with certain parallel busses. The communications lines will either work entirely, or not at all.
But this isn't the case between the touchscreen controller (goodix gt911) and the actual capacitive array. These two components use a fairly large number of ANALOG signal lines to send touch position to the controller (i.e., which lines "light up" and by what extent). If one of these lines is broken, then you will experience a sensor failure in the region that applies to that line. And unfortunately, there are "no user serviceable" parts between the controller and the sensor grid. In fact, the controller is soldered onto a "flexible PCB", which is nothing other than a ribbon wire. These ribbon wires are incredibly fragile, and there is generally not much you can do if they fail.
If you really want to get into it, you can try to separate the capacitive grid from the LCD, and look at where the ribbon wires join the edge of the glass. If one of the lines is broken, it is *probably* in that area. Putting some pressure on the joint could get it working again, just don't ask me how to get the two to STAY together after you release the pressure.
I've got this problem today too.
calibration works but even after that the top 10% wont respond.
Very weird. I can calibrate the screen and it see's my touch at the very top but once I leave that page the top 10% wont work.
It only works on the calibration page.
Why would that be?
https://www.youtube.com/watch?v=LB7C48gaC8c
Cartel™ said:
Very weird. I can calibrate the screen and it see's my touch at the very top but once I leave that page the top 10% wont work.
It only works on the calibration page.
Why would that be?
Click to expand...
Click to collapse
Like I mentioned above: for me the calibration screen does not work.
in my case the "on screen soft keyboard" does work in places where buttons in other apps don't work. That confuses me a lot. Of course I tried to tap slightly "in and around" the soft keyboard "keys" and "in and around" those not-functioning buttons (like on the install screen for apps in my case) and I simply can't find (or understand) why it works in one case and not in another.
I also reflashed the unit with both a clean Joying ROM and with the gtxaspec V9a3, but that doesn't change anything.
Maybe this?
https://www.aliexpress.com/item/New...f8ad785&transAbTest=ae803_4&priceBeautifyAB=0
Cartel™ said:
Maybe this?
https://www.aliexpress.com/item/New...f8ad785&transAbTest=ae803_4&priceBeautifyAB=0
Click to expand...
Click to collapse
Thanks for pointing that out, but Joying also has replacement screens which fir their units better. As such that is not the issue.
And personally: I am simply not going to replace the screen from my old sofia anymore.
surfer63 said:
Thanks for pointing that out, but Joying also has replacement screens which fir their units better. As such that is not the issue.
And personally: I am simply not going to replace the screen from my old sofia anymore.
Click to expand...
Click to collapse
I think joying should send this overlay.
Unless this digitizer is what they want $50 plus $20 shipping both ways for.
Then I'm gonna be pissed.
I contacted Joying and was told the same $20 shipping, plus $50 deposit story. So I searched & searched to find a suitable digitzer without success.
Finally I gave in and ordered the Joying replacement. Complete new screen assembly arrived 11 days. Then I posted the faulty screen back (£15 Royal Mail), and 12 days later I received the $50 deposit back.
So brand new screen & digitizer for $20+£15 shipping over 5900 miles each way. Given global fuel prices I think this is not bad service.
96carboard said:
Touchscreens communicate with the host using i2c protocol. This is a 2-wire serial protocol. One of the wires is a clock signal -- which is generated by the host (CPU), but which can be manipulated by both ends (i.e., pulled low by the device side) to indicate various conditions. The other wire is the data wire, where naturally, the actual data is transferred, subject to the clock signal and conditions indicated upon it. In addition, the touchscreen also uses an interrupt line to signal to the host that there is data to be read (because i2c does not allow the device to initiate data transfers -- it can only respond to requests from the host).
If either of those three wires is not working, then NOTHING on that bus will work. Well, the host could POLL the device for data if there is no interrupt line, but that isn't how you would normally program a touchscreen to work.
In other words, you cannot fix a partially working touchscreen by "reseating" the i2c lines, as you can with certain parallel busses. The communications lines will either work entirely, or not at all.
But this isn't the case between the touchscreen controller (goodix gt911) and the actual capacitive array. These two components use a fairly large number of ANALOG signal lines to send touch position to the controller (i.e., which lines "light up" and by what extent). If one of these lines is broken, then you will experience a sensor failure in the region that applies to that line. And unfortunately, there are "no user serviceable" parts between the controller and the sensor grid. In fact, the controller is soldered onto a "flexible PCB", which is nothing other than a ribbon wire. These ribbon wires are incredibly fragile, and there is generally not much you can do if they fail.
If you really want to get into it, you can try to separate the capacitive grid from the LCD, and look at where the ribbon wires join the edge of the glass. If one of the lines is broken, it is *probably* in that area. Putting some pressure on the joint could get it working again, just don't ask me how to get the two to STAY together after you release the pressure.
Click to expand...
Click to collapse
Hi,
Does it mean that if I replace the touchscreen unit, will it work ?
nagaculun said:
Hi,
Does it mean that if I replace the touchscreen unit, will it work ?
Click to expand...
Click to collapse
No 100% guarantee, but most certainly: yes.
Thank you.
surfer63 said:
No 100% guarantee, but most certainly: yes.
Click to expand...
Click to collapse
Does the digitizer has to be the exact model or any model will do as long as the size is correct ?
Thanks
nagaculun said:
Does the digitizer has to be the exact model or any model will do as long as the size is correct ?
Click to expand...
Click to collapse
Better ask Joying.
I don't think it matters, but I am not sure.
nagaculun said:
Does the digitizer has to be the exact model or any model will do as long as the size is correct ?
Thanks
Click to expand...
Click to collapse
In the very least, it has to have the same chip as the original.
In particular, however, they use sneaky tricks to prevent you from using a different brand of touchscreen.
The simplest trick is that different vendors use different pin assignments in the ribbon itself.
On most touchscreen digitizers, the ribbon cable is labeled. In other words, it tells you what pin does what. So what you would be able to do then, is use an adapter to convert differently wired digitizers with the same controller.
HOWEVER, the sneaky tricks that this vendor uses involves applying *incorrect* labels to the ribbon. The idea is, of course, so that if you try to match up a 3rd party digitizer, it won't work, or worse, could actually damage something. I once mapped out the *true* pin assignment for this brand, but it was a long time ago and I don't know where my notes are on it. If you really want to dive into differing brand digitizers, you will need the datasheet for the chip (which is available -- just do a google search for it), and a multimeter.