Database Users

OKAY, What's the BEST HORIZONTAL SURFACE INSTALLABLE HANDS-OFF CAR KIT on the market?

First, for those people responding - only please post replies having to do with the below four requirements, it would make it a much easier read for everyone involved, thanks. I am going nuts looking and cannot find a unit meeting the 4 below requirements. I have been looking for a long, long time. I am willing to do some extra installation work to get this done properly. If I cannot get an answer here there is probably no hope so I may then defenestrate! Requirements:
1. SMALL holder that can attach to a HORIZONTAL surface (not a huge geeky looking contraption with huge arms or snaking bendable supports, no huge sand-filled weights - minimal size - also power supply not on the holder which makes it bulky)
2. Allows the Kaiser to be switched between landscape/portrait position
3. Allows the Kaiser to be held with the keyboard open if preferred
4. Full functionality for auto-charging, interrupting radio speakers when turn by turn directions are spoken by GPS on the unit (extra wires and transformer kit to be hidden for installation - AND NO USE OF CIGARETTE LIGHTER!). Power supply for charging the unit must be OFF when car is not in use, so as not to wear out car battery (I would assume that is just an installation preference).
Anybody have any ideas?

KruseLudsMobile said:
First, for those people responding - only please post replies having to do with the below four requirements, it would make it a much easier read for everyone involved, thanks. I am going nuts looking and cannot find a unit meeting the 4 below requirements. I have been looking for a long, long time. I am willing to do some extra installation work to get this done properly. If I cannot get an answer here there is probably no hope so I may then defenestrate! Requirements:
1. SMALL holder that can attach to a HORIZONTAL surface (not a huge geeky looking contraption with huge arms or snaking bendable supports, no huge sand-filled weights - minimal size - also power supply not on the holder which makes it bulky)
2. Allows the Kaiser to be switched between landscape/portrait position
3. Allows the Kaiser to be held with the keyboard open if preferred
4. Full functionality for auto-charging, interrupting radio speakers when turn by turn directions are spoken by GPS on the unit (extra wires and transformer kit to be hidden for installation - AND NO USE OF CIGARETTE LIGHTER!). Power supply for charging the unit must be OFF when car is not in use, so as not to wear out car battery (I would assume that is just an installation preference).
Anybody have any ideas?
Click to expand...
Click to collapse
Is there something about the Proclip holder that doesn't meet those criteria? The only thing I can find is connectivity to the stereo. For me, I redirect the GPS audio to my Bluetooth headset where I can hear it better anyway.

Yeah, Proclips is your best bet. There's nothing that does all that out-of-box on the market right now. If you want to hook it up directly into your stereo system, then of course you're going to have to do that yourself. Or use bluetooth.

I guess there is nothing on the market
The solutions from Proclip that you suggest have no way of mounting the unit on a flat horizontal surface without damaging the car - I guess I would have to use one or two of these:
http://www.proclipusa.com/?sectionp...egoryid=&p_year=&p_countryid=0&p_leftorright=
from proclips to mount the holder (have to drill holes on the mounting surface).
Since the Tilt will work with the soon to be released higher capacity Micro SD cards (now only 8GB available but the tilt would be able to handle up to 32GB - when available) it would be nice to add the audio (music) as an automatically overriding input for the car's audio as well, for that I will have to use the hack mentioned here:
http://forum.xda-developers.com/showthread.php?t=339263
for replacing the plug on the unit with one that includes the audio out...
I will post pics once I figure out what direction I want to go with this...

HeroC's speaker jack vs GPIO

Does anybody happen to know how the HeroC's 1/8" jack is connected to the MSM 7600A inside the Hero? Is there an amplifier circuit buffering it, or are one or two of its pins wired straight to pins on the 7600A? Does it have 2 contacts + ground (mono headphone + mic), or does it have 3 contacts + ground (1 for mic, 2 for stereo, the second of which is ignored when a normal headset is used)? Is there a datasheet somewhere online?
Why? If the headphone jack is wired straight to the 7600A, there's a very, very good chance it can be used for general purpose i/o, above and beyond merely driving a speaker and sampling a microphone. God forbid, if it has 3 signals + ground, we're talking bitbanged SPI. If someone at HTC and/or Qualcomm had a sense of humor, and picked GPIO pins with I2C as a secondary function, well... that would just be pure bliss

no way we're talking spi...I mean just no way...I hope I'm wrong lol

I am not sure what all this means but it sounds exciting. I found a pic of it dissasembled but not a great shot of the headphone jack. Hope it helps.

Well, SPI would mainly depend upon having a 4-contact headphone connector (purely speculating, I put the likelihood at around 30%). All you need to make SPI work is one pin that can be configured as input (MISO) and two pins that can be configured as output (MOSI and SCK).
I2C almost certainly wouldn't be do-able unless some engineer at Qualcomm LITERALLY paired DO and DI as secondary functions for i/o pins suitable for DAC & ADC use as well, and someone at HTC happened to pick the same two pins to use for the headphone jack. On the other hand, if the headphone jack has only 3 contacts (2 i/o + ground), that would guarantee that at least one of them IS bidirectional-capable, because it would have to do double-duty as a PWM-output device AND a voltage comparator (so it could drive one of two stereo headphone drivers, sample the mic of a phone headset, and simultaneously allow the chip to detect when the pin got shorted to ground by the user pressing the 'answer' button.
If nothing else, it could probably do not-quite-I2c-kind-of-ghetto-half-duplex-SPI, using one pin as an output clock, and using the other for input or output as necessary. The nice thing about SPI is that if you're interfacing to your own stuff, the timing can be totally brutal, sloppy, and bitbanged (take SCK high, set MOSI, take SCK low, sample MISO, stir, rinse, & repeat a few billion times)
I'm putting the odds that the headphone jack is connected straight to the 7600A at around 40%. Normally, any sane design would buffer something like an audio circuit so something really bad wouldn't damage the CPU as well... but we're talking about a phone that's basically irreparable by human hands if anything on the board fries anyway, so the real-world advantage of external buffering would be countered by real-world savings from pulling as much external circuitry into the controller as possible.

bitbang3r said:
Well, SPI would mainly depend upon having a 4-contact headphone connector (purely speculating, I put the likelihood at around 30%). All you need to make SPI work is one pin that can be configured as input (MISO) and two pins that can be configured as output (MOSI and SCK).
I2C almost certainly wouldn't be do-able unless some engineer at Qualcomm LITERALLY paired DO and DI as secondary functions for i/o pins suitable for DAC & ADC use as well, and someone at HTC happened to pick the same two pins to use for the headphone jack. On the other hand, if the headphone jack has only 3 contacts (2 i/o + ground), that would guarantee that at least one of them IS bidirectional-capable, because it would have to do double-duty as a PWM-output device AND a voltage comparator (so it could drive one of two stereo headphone drivers, sample the mic of a phone headset, and simultaneously allow the chip to detect when the pin got shorted to ground by the user pressing the 'answer' button.
If nothing else, it could probably do not-quite-I2c-kind-of-ghetto-half-duplex-SPI, using one pin as an output clock, and using the other for input or output as necessary. The nice thing about SPI is that if you're interfacing to your own stuff, the timing can be totally brutal, sloppy, and bitbanged (take SCK high, set MOSI, take SCK low, sample MISO, stir, rinse, & repeat a few billion times)
I'm putting the odds that the headphone jack is connected straight to the 7600A at around 40%. Normally, any sane design would buffer something like an audio circuit so something really bad wouldn't damage the CPU as well... but we're talking about a phone that's basically irreparable by human hands if anything on the board fries anyway, so the real-world advantage of external buffering would be countered by real-world savings from pulling as much external circuitry into the controller as possible.
Click to expand...
Click to collapse
could you put that in english please. LOL just teasing bro

I'm an computer engineering student and you just threw me for a loop. I think what you're trying to say is that if what you think is going on is that it might be possible to use the phone as a microcontroller or have controls like media playback go through the jack. Am I wrong? Just trying to put in non-engineer language.

SPI is basically a shift register protocol. It allows a master to communicate with one (possibly more, if you have additional lines to do addressing) slave(s). The master controls the clock. When the clock is low (ground), the slave is allowed to read the MOSI (Master Out, Slave In) signal, and the master is allowed to read the MISO (Master In, Slave Out) signal. When the clock pin is high (traditionally 5v, but 3.3v, 3.0v, 2.7v, and even lower signal levels are common now), the master and slave aren't allowed to read, and instead take advantage of the opportunity to change the state of their respective output lines to reflect the value of the next bit they want to send.
The main advantage of having a line dedicated to a clock is that you don't have to worry about timing if you're the slave. You don't have to count milliseconds while a pin is high or low. You just watch the clock, read when it goes low, and write when it goes high.
I've also seen circuits that went a step further, and used a MOSI transition while SCK was low (normally taboo) to signal the start of a new byte. In situations like that, if you were the slave, you'd sit there and wait for SCK to go low, then you'd wait until MOSI changed state while SCK was low. From that point, you'd know that it's time to send and receive the next byte.
Most people who get into robots start with serial ports because they're easier to interface with computers, but when you're wiring devices together without a computer in between and basically just bitbanging (taking advantage of the fact that modern processors are so fast compared to what existed 20 years ago, you literally CAN get away with just tapping your foot and busy-waiting while counting clock cycles, and faking out the signals that used to take real hardware to do.

Long story short, He is hoping that the headphone jack is connected straight to the IC so it could possibly be used as a data connection (think kinda like a modern day serial port) if it is.Aiming towards SPI with a smallpossibility of I2C. Exampals
I2C is use by wiimote's to connect to the nunchuck or the motionplus
SPI is used by alot of LCD segmant displayes ( The x3 xbox mod chip uses it for its lcd )
::edit:: didn't see your reply Bitbanger. we must have been typing at the same time

I'm an computer engineering student and you just threw me for a loop. I think what you're trying to say is that if what you think is going on is that it might be possible to use the phone as a microcontroller or have controls like media playback go through the jack. Am I wrong? Just trying to put in non-engineer language.
Click to expand...
Click to collapse
Actually, what I have in mind is a real 4-way gamepad that clamps onto the end and plugs into the headphone jack, with a 3v battery to power it and basically two i/o lines into the phone... clock and data (using something like an Atmel Tiny2313 or Mega48 to read the gamepad switches and broadcast their state to the phone using those two i/o lines).
It's something I've been toying with all the way back to my Samsung SPHi300, but I've always run into insurmountable hardware problems along the way (besides the lack of a 3D printer to make the prototype itself, of course). My i300 had a real serial port and a nice, hackable Dragonball that gave me warm fuzzy m68k feelings of joy, but you couldn't buy a connector for it to save your life, and Samsung's cables were obscenely expensive until long after the i300 faded from view. The SPHi500 would have been perfect with a thumb-operated gamepad in one hand, and the phone (using the keypad for fire buttons) in the other, but it only had USB. I tried IrDA, but Samsung's PalmOS4 ROM was a hacked-up mess. My PPC6700 had a semi-usable joystick, and architecturally was totally alien to me anyway. By the time I got my Touch, I was more comfortable with ARM, but HTC took away the IR and WiFi, leaving only USB and bluetooth. USB was out of the question, and the cheapest bluetooth module you could buy from Sparkfun was about a hundred bucks (I came close to breaking down a few times, though). I was about to finally buy one of their new ~$30 modules to use with my Hero before Christmas, until I found out that phones with 1.5 couldn't use the Android Bluetooth API. Let's just say I think the entire neighborhood heard me shouting obscenities in the general direction of HTC and Sprint when I realized that I couldn't do a thing bluetooth-wise until I had 2.x in my hands

How to hack hardware binary and bend it to your will

Before you start on actually modifying your hardware, you must know what it is you're after. Don't just go using your finely tuned soldering iron without doing some research first... http://twitpic.com/75maxq
I wanted to share some tricks I use when locating UnBrickable Mod on various devices because it has been requested many times. Overall, the methods I'm going to talk about can be called "reverse engineering", "hacking", or "circuit bending".
Each device is different so different methods may be used. I'll start with what I feel is the best method to use and move my way on through less accurate and more destructive/difficult methods. The methods I'm using here can be used on nearly ANY device for nearly ANY purpose, not just locating boot modes. Using the techniques I'm laying out here, you can locate any physical memory register on any chip.
For the purposes of this familiarization guide, we will be locating the xOM5 resistor which changes the S5PC110 boot mode from "boot from OneNAND" to "Boot from USB, then OneNAND". Other modes are available such as booting from SDCard or MMC but these modes do not allow dual booting into the standard OneNAND boot so they are not practical unless you have a NAND failure.
By reading the S5PC110 processor manual, we can see on page 6-8, this is achieved by setting the xOM bits to 101001 (hex value 29). These binary values correspond to pins on the processor. These pins can be set high or low, and they ARE set high and low on the development board for the S5PC110 development boards. On other processors like OMAP4460, or Exynos, different pins are used but the functionality is the same.
All binaries and reading materials used are availabe in the GalaxyS hack pack: http://forum.xda-developers.com/showthread.php?t=1111866
For installation of binaries, you can use the market app "mount rw/ro" and drop the binaries in your /system/bin folder. See here for more information on direct access to Linux and installing binaries: http://forum.xda-developers.com/showthread.php?t=1030107
For the purposes of this thread we will be using a S5PC110 chip which is what the entire GalaxyS series of device is based upon.
With this knolwedge in hand, lets continue into HOW we can locate these pins.
how to locate the xOM resistor cluster
If you orient the S5PC110 processor with the PIN-0 dot at the lower left corner, you will find the xOM cluster at the lower right corner. These resistors will always be near this location because the pins on the board are near this location. It's never a good idea to have "runs" on a board longer than necessary. Therefore, these resistors will always be near this corner.
NOTE: You need not remove the processor. This is only for illustration.
{
"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"
}
For other devices, see the pinouts on the processor manual.
Methods for locating modificaton
Monitoring memory locations in real-time
You will need:
viewmem installed in /system/bin
bash installed in /system/bin
Market App: QuickSSHD allows you to terminal into the device.
1. we locate the xOM registers on the device. According to the processor manual
OM_STAT 0xE010_E100 R OM status register 0x0000_0000
Click to expand...
Click to collapse
the OM registers are at 0xE010E100. So we know where to look in memory to monitor changes.
2. ssh into your device. See QuickSSHD for more information. Once you are in, assume super-user, get into a bash terminal, and use the viewmem utility.
Code:
$ su
# bash
bash-4.1#viewmem 0xE010E100 0x4|hexdump
[INFO] Reading 4 bytes at 0xe010e100...
0000000 0009 0000
0000004
3. Short and test. While shorting the high value to the active side, NOT THE VISIBLY GROUNDED SIDE, monitor output from the terminal.
The PullUp resistors are 10Kohm and the Pulldown resistors are 100Kohm. This means there's 10x more force behind a digital high than a digital low, in other words, you can short any low value high without a problem...
Code:
viewmem 0xE010E100 0x4|hexdump
[INFO] Reading 4 bytes at 0xe010e100...
0000000 0029 0000
0000004
the 29 signifies that the device is modded properly. A value of 0x9 is a standard production device. When you see 0029, you've located the proper resistor for the modification.
Using overlays
Take a picture of the board, then use an annotated pinout to locate the proper pins on the processor. This allows for a visual of the device as though the processor were removed.
here's a picture of my own annotated overlay. Use this and we'll walk through overlay logic.
Now, with a xOM value of 0x9, that's a binary value of 001001, use your calculator in "programmer" or "scientiffic" mode if you don't believe me.
Broken Down:
xOM5=0
xOM4=0
xOM3=1
xOM2=0
xOM1=0
xOM0=1
xOM 3 and 1 are both high values, all the rest are low. We can use this to our advantage. We can see that 4 resistors are connected to ground on one side and 2 are not. Those two are obviously xOM3 and xOM1.
If we look at the processor pinout, we can see that if xOM3 and xOM1 resistors were swapped, one would be very much longer than the other so there's only one logical solution.
Moving on to the shortest ones, xOM4 and xOM2 would obviously be closest to the top of the resistor cluster, and it's also obvious wich one would be which.
Now that leaves two resistors in the middle. One is high and one is low. by drawing it out you can see that if xOM5 were on the right, then xOM1 would be very much longer than xOM5, so xOM5 must be on the left.
So, we've located all xOM values with this method.
Using relative positioning
This method is not nearly as scientiffic... Since there are now 10 guides made for modifying xOM5 on different boards, a resistor may be picked and chosen as though it were from anothe board. See here for various modifications: http://forum.xda-developers.com/showthread.php?t=1236273
Verification from this method may be made using UART. you would be expecting an output like this over the UART on your device.
See here for info on UART: http://forum.xda-developers.com/showthread.php?t=1235219
If the modification was sucessful, UART will output a line which states OM=0x29.
Using a multimeter
You can remove the processor from a device and trace out the pins manually. This method is only appropriate for a broken device.
conclusion
So, these are my methods for hacking hardware and making it do what I want. I'd like to hear others. Lets hack up some hardware and talk about it here.

+1
Good that every chip component is configureable on lowest level by set of external passive elements - opens big possibilities to change any hardware into something different.
Worth to add - always think twice, or even once more before short circuiting anything. If between some V line and another there is positive voltage, like +1V, it still doesn't mean that second one is GND. First one can be +2V and second one +1V. READ carefully all datasheets and documentation. Don't connect any power line straight to another without resistor - this will cause high current go through some component and probably damage it.
Example of bad test - there are some capacitors on the left of Adam's needle when testing resistor. It's highly possible that these capacitors are ARM_CORE stabilisers, which is 1.2V and can handle up to about 1.4V. Adam is operating with 1.8 or 2.8V from other V line - accidentally touching the capacitor with needle can damage CPU core.
If you never been doing any hardware mods but feels like you want to start - prepare for some victims in your electronic devices. That's all of my experiences for now.
//Damn me and my bad habit of reserving posts in Adam's thread. Sorry. :d

very informative

Excellent and authoritative article! Though I'm personally too scared to do anything like this on my phone!

I've gotten replies from people that removing a BGA chip is almost impossible. A tutorial on how to unsolder one would be helpful for aspiring hardware hackers.

Master Melab said:
I've gotten replies from people that removing a BGA chip is almost impossible. A tutorial on how to unsolder one would be helpful for aspiring hardware hackers.
Click to expand...
Click to collapse
It IS almost impossible. It's rediculously difficult. You'll end up pulling a pad or two off the board. You must heat up the entire chip with a heat gun or a hot air station, then pull it off... Meaning you're heating up the entire chip to the point where the solder melts. It takes a multi-thousand dollar professional setup in order to make sure no damage is done. I use a digital temperature controlled heat gun. It works, but it's not accurate.

If you could replace the pads with a socket or something like that you'll be set to go.

we need to get you a better camera

elmanortega said:
we need to get you a better camera
Click to expand...
Click to collapse
HAHHAHHAHHA. funny story about that...
You see, my 6 year old tried to do unbrickable mod on that today..
I no longer have a dedicated camera

I wish i could try it, but i am sure i wont be able to, lol

Thank you very much for this guide.
Could you also describe what tools (soldering iron etc) do you use?

I use a Radio Shack digital soldering iron. It's nothing special but it's temperature controlled and has a fine point.

I made some more overlays
here is Exynos4210
This is from OMAP 4460, but I'm pretty sure it applies to OMAP 4430 as well

verry intresting, soon i try

Seriously this guys work is awsome, learnt quite abit from your work, thank you very much!
Sent from my Desire HD using XDA App

cdesai said:
I wish i could try it, but i am sure i wont be able to, lol
Click to expand...
Click to collapse
Same here but why dont giveit a try... just encourage

AdamOutler said:
... It takes a multi-thousand dollar professional setup in order to make sure no damage is done. I use a digital temperature controlled heat gun. It works, but it's not accurate.
Click to expand...
Click to collapse
Sorry Adam, you have a great writeup, but this is really a BS statement!
-- You can easily unsolder a BGA chip with a $5 micro-blow-torch! You just have to make sure you shield the surrounding components from the excessive heat. Put a small piece of copper (a penny?) on top of the chip, then put a piece of low-temperature (lead-free) solder on top of the coin, so you can get an idea when you have enough heat. Continue 10-20 seconds. Very carefully try to jam a few sharp toothpicks under any space between chip and PCB. Never bend!
This technique is well known and well demonstrated on YouTube, ever since the HP/Nvidia scandal of video chips falling of the MOBO after dust blocking the fan intake with (purposely) under-dimensioned and faulty heat-sink design.
The problem is getting it back ON! Then you need to invest in a professional heat plate and re-balling grid.

excuse me mister, i have done it, n my tab turn back on, now i have another problem, the screen is black and the bottom light is on, could you help me?

^^ good idea! I've always used a high power and small heat gun. It works for 99% of the pads, but I always lose 1 or 2. I never intend to put them back on.
apram75 said:
excuse me mister, i have done it, n my tab turn back on, now i have another problem, the screen is black and the bottom light is on, could you help me?
Click to expand...
Click to collapse
This is the wrong place to post that. And it does not really make sense that you did this in context.

Unsoldering a BGA is easy.
Doing it without causing unrecoverable damage is a different story. Same for resoldering it back on.
However it is getting easier nowadays - temp-controlled hot air rework stations have dropped drastically in price - http://www.amazon.com/Updated-Aoyue-Digital-Soldering-absorber/dp/B006FA481G/ref=pd_cp_hi_3
Also, reflowing a BGA without removing it (such as for Xbox360 RRoD fixes) is a LOT easier than remove-and-replace.
Also - my personal favorite deal in terms of soldering irons is http://www.amazon.com/Aoyue-937-Dig...ref=sr_1_1?s=hi&ie=UTF8&qid=1331244730&sr=1-1 - The Aoyue 937 is amazing considering it is <$50.

[BUG FIX] Phantom keypress and screen shot

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.

Questions about Joying JY-UL135N2

Hi!
I have a couple of questions about the JY-UL135N2 head unit.
On the source button (SRC), it cycles through different apps for source to audio as expected. Is there anywhere to select which apps it cycles through? I'm not interested in cycling through the video player and such, but would like it to go Radio>Spotify>Google Play Music and nothing else. Is this possible?
Also, I'm having issues with the bluetooth dialer app. I think I've read that it's a common issue, that the app is simply not good. Is it possible to install the stock Google Phone and Contacts app? I tried downloading the Contacts.apk, but it wont install.
Has anyone used the SUB output? I'm using it with a factory installed OEM subwoofer with its own amplifier, problem is that the SUB output isn't really managed, it just plays like a regular output with no crossover or anything. Is there any way to fix this?
And lastly, I'm seeing that it's sitting pretty constantly at 70 to 80'C in CPU temp, which probably means the internal heatsink is insufficient. Does anyone have a picture of the CPU systemboard without a heatsink, or perhaps know of a heatsink which may fit? Another option is to attach a small PC heatsink, but not sure if I'd rely on adhesive or thermal glue to not come loose in a car environment with impacts and vibrations.... The best would be to have something to bolt down and secure it in place with some sort of mounts or something.

Hilari0 said:
Hi!
I have a couple of questions about the JY-UL135N2 head unit.
On the source button (SRC), it cycles through different apps for source to audio as expected. Is there anywhere to select which apps it cycles through? I'm not interested in cycling through the video player and such, but would like it to go Radio>Spotify>Google Play Music and nothing else. Is this possible?
Also, I'm having issues with the bluetooth dialer app. I think I've read that it's a common issue, that the app is simply not good. Is it possible to install the stock Google Phone and Contacts app? I tried downloading the Contacts.apk, but it wont install.
Has anyone used the SUB output? I'm using it with a factory installed OEM subwoofer with its own amplifier, problem is that the SUB output isn't really managed, it just plays like a regular output with no crossover or anything. Is there any way to fix this?
And lastly, I'm seeing that it's sitting pretty constantly at 70 to 80'C in CPU temp, which probably means the internal heatsink is insufficient. Does anyone have a picture of the CPU systemboard without a heatsink, or perhaps know of a heatsink which may fit? Another option is to attach a small PC heatsink, but not sure if I'd rely on adhesive or thermal glue to not come loose in a car environment with impacts and vibrations.... The best would be to have something to bolt down and secure it in place with some sort of mounts or something.
Click to expand...
Click to collapse
1. No way to change that I know of.
2. I use the program tablet talk, If you play with the settings you can get it to play well with the stock bluetooth dialer. I even went as far as to hack the manisfest, it so I can use google voice to dial out. It's a paid app, so I don't think I should post my modded version, but can tell you what I changed. It also syncs SMS messages between the phone and HU. I use "read it to me" to have the HU speak the SMS messages.
3. External crossover works well.
4. No heatsink is installed from factory. I added one from a desktop processor. I also added a small fan in the top of the case, with a 5v voltage converter to power it when the unit is on. It's a 12v fan, but It runs nice and quiet at 5v and moves enough air. Before I was at 70C+, now rarely exceeds 50C with no throttling. I fastened it with thermal conductive epoxy, it's never coming off. See attached.

Ok, thanks for the answers.
Would be awesome if you could share what you modified to get Tablet Talk working properly, sounds like something I'd like to try as well.
And that heatsink looks like it would do the trick. Is there only one chip to cool under there? Or are there other components that could benefit from cooling?

For heatsink, I think I'll get a stock intel CPU cooler. That should suffice for a low power chip I think. It's low weight and compact, and already has a fan mounted on it so it's practical.