Database Users

Project Electric Himalaya

Hello to all. I'm a "new" member to the XDA-Dev community, and I am today presenting a document on my project that I've been dreaming about for 2 years or so. Finally, I had enough time to take time off my schedule to do something significant today - start this project officially.
I have an O2 XDA II with a broken connector. I will be attempting to hardwire an electrical source to the device by as many means possible. I have created this thread for people to come together and discuss any information they might have, any thoughts/ideas they want to share, or any observation(s) on their own experiments with this device.
http://s21.photobucket.com/albums/b296/tubecena/?action=view&current=himalaya.jpg
ps. : Here is something i forgot to add to the drawing :- At the end of the two wires in the end, I aim to put a USB male/female (haven't decided). Maybe i'll even redesign the area of the connector, but that would result in heavy work. We'll see how it goes. (and see how this thread gets feedback)
Here's something that might kickstart your contribution to this thread :
- Will it be possible to run the device without a battery with a charger of 5V?
- Will it be possible to join the two plates, positive (1+2) and negative (5+6), together, and get more power? Will there be any changes? Will there be a performance hike?
- What will happen to the device if a charger of 5.2V is used?
- If the two end wires are left not connected to a source, will an energy leak of any kind happen?
- Will the length of the wires significantly increase resistance and therefore reduce battery life?
I'm new here, go easy on me! >.<
Thanks for your time, and effort.

your questions are mainly in the general electric cat rather then himalya really
"- Will it be possible to run the device without a battery with a charger of 5V?"
yes unless the device detect the batt present and refuse to work without it
"- What will happen to the device if a charger of 5.2V is used?"
thumb rule is 20% each way without any problem
"- If the two end wires are left not connected to a source, will an energy leak of any kind happen?"
electrons travel from + to minus can't travel over air unless it's very hf
"- Will the length of the wires significantly increase resistance and therefore reduce battery life?"
there are many sites which let you calc the resistence of wires over lenght
but if you don't make them longer then 50cm you should not worry

Ah, thank you for your reply. Yes maybe you are right about the "electrical category" part, but since I was working on Himalaya, I might have just gotten a little over-excited and thought I might start a "project". Right you are, indeed this is purely electrical stuffs, but if you/anyone else might have any other information or ideas to refurbish your Himalaya, maybe this might be the place?
I was thinking of making use of the cradle from XDA II, resulting in a rewiring of the cradle and the device. Then that would mean that I need alot of USB cables, a drill, and maybe some wood? Well, if anyone has any points to bring up, speak up yeah?
In any case, IF I do decide to make something to help those dead Himalayas (like I said earlier, remodelling the cradle and device), then we'll have this thread as a tut.
Thanks and have a nice day people.

DEAD Hima.
okay, so i took two wires, connected the battery and the device (one plate and one pin each) and tried to fire up the device. It wouldn't start. I reinserted the battery to the Hima and it wouldn't fire up. I'm guessing that it's DEAD. Anyone might want to help me on this one?
- my connector is dead.
- my 2 batts are fully charged, still no avail. (not dead batt i guess)
- i charged my backup batt but still no avail.
- either there is an overall power undersurge(i'm just shooting random thoughts), or the RED SWITCH is causing the problems. coz the red switch is indeed loose"r", or, more loose, than before. Maybe I hit it abit too hard in the process and thought the battery did it, i'm not sure. Any help would be appreciated.
Oh and I'm buying a SECOND HAND PDA/XDA/WMTS DEV. I'm situated in Singapore. And I just need a very cheap one. I wouldn't mind if it has 1/10 cosmetics, coz i just need it to let my mum play solitaire. She's an avid player and would be very very cranky if she doesn't play in every few hours. Would preferably consider a very rundown XDA II, or XDA IIs, provided the cost is below SGD 70. Thanks and have a nice day people.
ps. even if it's not rundown, just pm me, we'll see how it goes. I need this asap!

Connector broken
Hi,
I have the same problem, my PDA connector (22 pins) is broken and I would like to connect directly the power on the battery pins (6 pins connector) but I dont know where are the + and - on these 6 pins!!!
Thanks for your help,
TD.

thats why we made a wiki for you
http://wiki.xda-developers.com/index.php?pagename=Connectors

completely broken
No because the 22 pins connector is completely broken (motherboard too)!!
But when I plug a charged battery, it's OK...

curious
tdfamily said:
Hi,
I have the same problem, my PDA connector (22 pins) is broken and I would like to connect directly the power on the battery pins (6 pins connector) but I dont know where are the + and - on these 6 pins!!!
Thanks for your help,
TD.
Click to expand...
Click to collapse
yeah even i got curious where does the right pin on my himalaya
because i'm on my project to recover my hima to out of his grave

lontong balap said:
yeah even i got curious where does the right pin on my himalaya
because i'm on my project to recover my hima to out of his grave
Click to expand...
Click to collapse
http://pinouts.ru/PDA/pda_wallaby_pinout.shtml
Have fun

how about fitting a mini usb to the himalaya?
You see, i would do it but my himalaya is very precious to me, so if i screwed up i am done for.

flyboyovyick said:
how about fitting a mini usb to the himalaya?
You see, i would do it but my himalaya is very precious to me, so if i screwed up i am done for.
Click to expand...
Click to collapse
Hardwiring means HARDWIRING YEAH
{
"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"
}
I wonder that hima could survive it.

aeroflyluby said:
Hardwiring means HARDWIRING YEAH
I wonder that hima could survive it.
Click to expand...
Click to collapse
whats that you are holding in your hand?

flyboyovyick said:
whats that you are holding in your hand?
Click to expand...
Click to collapse
A soldering

You're right: It looks a bit like a Gamma Scout! lol

When my connector goes thats what iam going to do. mini usb it.

flyboyovyick said:
When my connector goes thats what iam going to do. mini usb it.
Click to expand...
Click to collapse
Flashing via bluetooth would be genius (and possible, radio stack should support it)

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.

Controlling the FSA9480

Hi folks,
I have a hardware/software project that I'm building on a Galaxy Nexus phone and I would like to exert full control over the FSA9480 chip that switches the phone's pogo pins and micro-USB port between the USB and charging circuits.
The overall goal is to have a USB accessory plugged into the phone at all times, including in a pogo-pin based charging dock. Since the default "auto" switching mode keeps the phone in USB-host mode as long as the OTG cable is plugged in, the phone will not currently charge in the pogo dock.
Thanks to Adam's great thread on the FSA chip, I've been able to control the FSA chip via the i2c interface, using the i2c tools in his hack pack. (Heading to those threads to leave my thanks as soon as I get this FP in).
Even though I can check the registers and in fact see that the switches inside the FSA chip are in the modes I specify, the phone doesn't do the things I expect it to, like charge or enter USB accessory mode. I suspect this is because I've unloaded the FSA kernel module in order to access the i2c device. I was hoping that merely connecting the wires to the right places via the FSA would do things like enable the USB connection or allow the device to charge. Alas, that does not seem to be the case.
Since Google has declined to share the source for this phone, I've been poking around and assuming that their driver is similar to this code and this header. I love that fsa9480_SetManualSW is exported, but I have no idea how I might access that method, if it is in fact in the Nexus code. I'm searching through the lib/*.so files now to see if there's anything FSA related there, but so far no luck.
So that's where I am - I can control the device, but that doesn't appear to be enough to do the things I want to do. I'm not sure where to go next - I don't think I should have to write my own kernel driver, but I'll be damned if I know what to try next.
Does anyone have any ideas how I might exert software control over this FSA chip, or barring that, what else I need to fool with on the i2c bus so that the phone charges or enters the proper USB mode when I set the FSA mode manually?
Many thanks in advance and I hope this is the right place for this question (Q&A section did not seem like the place for this type of question).
Peter

You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.

E:V:A said:
You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
Click to expand...
Click to collapse
Certainly happy to explain as much as I can... let's see:
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
Click to expand...
Click to collapse
I got the term "pogo pins" from this thread. They are three tiny pins on the side of the Galaxy Nexus. They allow for car and desktop docks. They provide charging through the outermost pins and a digital signal of some kind (don't care about that one for this project) on the center.
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
Click to expand...
Click to collapse
I've simply assumed from the kernel messages and from screwing around via the i2c bus (as explained before). It may not be there, it may be something completely different, but from the software side, it behaves exactly like I'd expect the 9480 to...
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
Yes, I glossed over that fact. Expansion: We've got a USB accessory that we would prefer to never disconnect from the phone. Since even having just the OTG cable connected drains the battery, our app is already managing power by binding/unbinding the fsa9480 driver. When unbound, the driver leaves the phone pins in (afaik) a floating state and the accessory/OTG cable does not draw current. When we want to poll the accessory, our app binds the fsa9480 driver, which results in the USB system seeing the OTG cable and connecting everything up nicely. When it's done, it unbinds the driver again and saves battery.
Since we don't want to/can't disconnect the accessory from the micro usb port, charging is an issue. So we'd like to charge the phone via the side pins (what I perhaps erroneously called the "pogo pins"). Since we're only polling for short periods, we'd like to be able to switch from USB host mode to charging mode during the period in which we are not accessing the device.
Now, I had forgotten that dedicated chargers short D+/D-. My hope was that by controlling the fsa9480, I could connect the +5V and GND pins to the battery and charge the phone, while keeping the USB accessory offline. I'm afraid I'm so tired and burnt out this may not be making sense, so please tell me what's confusing!
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
Click to expand...
Click to collapse
Sure! Where to start...
OK, so based on Adam's thread "Build Your Own Music Dock", linked above, I grabbed the spec sheet for the fsa9280a, which he claims is "functionally the same" as the 9480.
As you can see in the datasheet, the chip is controlled via the i2c bus. Looking at the file layout of the Nexus, I figured out the address of the chip on the bus and started plugging in commands outlined in the datasheet.
for example, setting the "Manual Switch 1" register on my Nexus is done by the command
Code:
i2cset 4 37 19 <your value>
(4 being the bus where the chip is located, 37 (0x25) being the address of the device, and 19 (0x13) being the address of the register)
The datasheet outlines all the register addresses, default values, values under certain conditions, etc. I assured myself that the datasheet was valid and I was communicating with the device I thought I was by setting and observing registers.
That "Manual Switch 1" register controls where the different wires are connected and is very important to me, as far as I know.
this is the block diagram from the spec sheet in Adam's thread above. I should have linked directly to the spec sheet, sorry.
{
"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"
}
And this is the register description from the same document
So... let's simplify my goals and say that I want to charge the phone from the micro usb port without connecting the USB host device (USB HS in the block diagram) to the micro USB connector: I'd want DP_CON and DM_CON floating and Vbus_in (on the micro connector) connected to Vbus_out (on the blue CHARGER IC in the upper left). I set the proper registers to do that, and things "should just work", right? (this is assuming I do things like initing the device, etc in the proper order, which I think I am)
They don't. Because I'm confident that the proper registers are set on the FSA, I'm assuming that the internal connections are all as I expect. Thus, my suspicion is that I need to do something more to get Android to start charging off the current coming in through Vbus_in...
Oh, and before I forget: unless I unbind/unload the driver for the FSA9480, I can't write to its address via the i2c tools because the driver already owns that address. I think of this driver as a kernel module, maybe that's incorrect or imprecise. Apologies.
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
Click to expand...
Click to collapse
I hope the block diagram cleared this up. I too was confused by the Vbus_in/Vbus_out thing. I really should have linked that datasheet.
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.
Click to expand...
Click to collapse
Agreed.
With that massive clarification, does that help? I'm starting to think this is something hovering right at the intersection of hardware and software. Maybe it's time I looked at writing my own device driver, or expanding the existing one?

E:V:A said:
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
You had better explain that slowly to my Nook, because it's sitting beside me here charging and connected to two keyboards and a USB audio adapter.
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current.
Even without the data lines shorted, a device can charge.
Moreover, if you tell your device in software to do a high current charge, it can.
Solution: use host mode and charge at the same time.
One connector does it all.

One thing I noticed while playing with the FSA chip was some of the registers would not change. They may be overridden by resistor values.
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.

Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)

@Renate NST: Yes, I should have been more careful with my words. I meant charging as operating as a high current Dedicated Charging Port (DCP). But then again thebeerbaron already understood this.
@thebeerbaron: Here are your "pogo-pins" (right side is towards the top of the phone):
The pins and their function is loosely described in this thread, and very nicely used in this thread, so it seem that the following is true:
Code:
[SIZE=2]P1 +5V
P2 Signal: 1-wire interface, using MFM encoding
P3 GND[/SIZE]
(check these!)
I don't have the Samsung parts list of the GT-I9250 so I still don't know what those chips are. But U601 is a Fairchild chip and could be another type of switch. On the other side of this board you find the multiplexers U809 and U810 configured like this:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
And here is another relevant hack for a wireless charger, But the interesting part is the Kernel hack mentioned:
For those of you wanting to charge at AC speeds instead of USB, Fast Charge Mod is here!
1) Install Franco Kernel (Milestone 1)
2) Run this script to activate it from the terminal (minus quotes):
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
and the UI Mode Manager code over here.

E:V:A said:
I meant charging as operating as a high current Dedicated Charging Port (DCP).
Click to expand...
Click to collapse
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.

Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
Well, Samsung try to conform to the "Battery Charging 1.1" standards, and that's how DCP is defined in there. The limitations are then also present in the chips and/or in the one or more PMIC Kernel drivers. So your NST is either not conforming to any standards or just have a hell-of-a-hacked Kernel, or both.
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do. If you are interested in knowing what kind of crazy hardware is included in a Galaxy class Samsung phone, you can have a look here.

Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.

Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
I don't know about the NST, but my Nook Tablet has several additional pins dedicated to charging the device, it's not a true USB port.
What's going on here is trying to convince the USB port to go into host mode, where it natively supplies 5VDC, but instead reverse it, use the 5V line to charge the device and supply 5V from an external source.
While the NT has a dedicated charging circuit, this device repurposes its usb pins based on input conditions. So here's what I see being required
1. Ground USB pin 4 to activate HOST mode.
2. shut off 5V power supply from FSA chip
3. set registers in FSA to charging mode.

Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Click to expand...
Click to collapse
It's pointless to discuss standards of what should and should not happen unless we are on the same page. Here are the specs.

Sorry.
/me wanders off elsewhere.

Sorry for the slow reply folks, I appreciate the input, but got sidetracked onto another project today. Wearing many hats means making a lot of context switches!
Renate NST said:
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current...Solution: use host mode and charge at the same time.
One connector does it all.
Click to expand...
Click to collapse
I haven't tried charging during host mode, as we were trying to keep the external wiring changes to a minimum. Based on what I found last night though, we may go with a completely external solution...
AdamOutler said:
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.
Click to expand...
Click to collapse
If we go with the external wiring solution, this will be what we do. When I set the FSA to various modes over i2c, it did not charge or connect the USB device as it should. This is very likely because the kernel is listening to the FSA for state changes and telling other devices how to behave based on those states. That's sad.
What is the SBL?
Renate NST said:
Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)
Click to expand...
Click to collapse
Yes, this is how things should behave. Unfortunately, the Samsung engineers who wrote this device driver were rather short sighted.
If you wade through this mailing list discussion (sorry, I apparently can't link until 8 posts... https://lkml.org/lkml/2011/6/29/124), you'll see the engineers need several attempts to get their code approved. The most interesting part to note (for me), is that they create the device file /sys/bus/i2c/devices/.../switch, which accepts input from userspace and sets the FSA9480 "manual switch 1" register appropriately. Unfortunately for me, they only coded a small portion of the possible states for this register and will not accept arbitrary values. UGH!
I sat down with the GN last night and tried using the /sys/bus/i2c/devices/.../switch device to set the manual mode. What I discovered is that even though this obviously passes values into the driver module (it prints a kernel message when I set a bogus value), the values don't "stick". In the driver code (I'm still not 100% sure I have the right source, but I think I'm close.. again, sorry for lack of clickability: https://bitbucket.org/franciscofranco/android-tuna-omap/src/388ae9aa9b26/drivers/misc/fsa9480.c), it has a _detected function, which gets called whenever the cable changes and overrides any manual settings I put in. For example, I set the "switch" file to "AUDIO", yet the phone remained in USB accessory mode, and plugging/unplugging did nothing. Sigh.
The lesson is, apparently, that I need to write my own driver module, which can replace this fsa9480.c transparently and allow me to ignore cable change detections and provide me with a way of setting the FSA state manually (with more flexibility than the Samsung engineers allowed). We're thinking about a different approach, but this may yet get done...
E:V:A said:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
Click to expand...
Click to collapse
Some great background info in here, thanks! I'll have to sit down and process this another day.
To unbind the fsa9480 driver, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/unbind
And to bind it, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/bind
E:V:A said:
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do.
Click to expand...
Click to collapse
Yep, that's what's interesting and what's making this difficult. It's kind of a gray area of where the topic experts are and what I need to learn...
Thanks for your input all... maybe something will come along that'll save me from writing a kernel module... fingers crossed!

I am very interested in the outcome of this project. I purchased the GNex thinking I could charge it while at the same time, connecting an SSD (via SATA->USB converter) to the phone for media playback. Thanks for your hacking skills!

Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.
Click to expand...
Click to collapse
Not true. https://github.com/CyanogenMod/andr...mmit/c7016a2513abfd522b02633b79d2f21bcb99d4e2 - The USB charging standard defines an Accessory Charger Adapter. It's signaled with a particular resistor value (36k if the code comments are correct...) on the ID pin.
Although while I thought the I9100/I777/N7000 used an FSA9480, it looks like the MAX8997 handles the task on these devices... hmm... The FSA might support this mode though, so instead of trying to force-override it, look to see if there's a particular resistor value you can hijack or, in this case, a resistor value that is standardized to provide the function you want.
I hate when I only have access to github's web interface and not the ability to grep my hard drive at home.

Extending Camera Flex Cable on Nexus 7

I'm looking to replaced my Nook Color in my car with a Nexus 7 in the coming weeks. Can be seen here One of the things that I wanted to do was a back up camera.
My intentions were to originally do either a BT or WiFi camera but I realized that it would be ridiculous for me to sit in reverse for 10+ seconds while my tablet pairs/connects with the tablet. This leaves me with the only one other option which is to use the front facing camera. I am considering extending the cable by about 9 feet. I have no idea if this will even work because of the length needed.
I think the way I want to do it is by using hot air to remove the connector for the camera from the board, then solder thin wire to each contact. Then in the back of my car, above the license plate, I would have a backup camera housing which would house the front facing camera and some sort of FPC/FFC board allowing me to install the connector I removed from the main board earlier. I would then plug in the front facing camera to the board with the installed connector.
My biggest question at this point is.... Do you think the range is too long for something like this? I drive a fairly small car so it won't be as long as say an RV or something. Here's some of the parts. I was able to find the part number for the connector by using the M370T diagrams floating around the forums.
Board Connector
{
"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"
}
Camera Side Connector
Below is the kind of board that I would like to find to put into the backup camera housing. The pitch is right but the width is off. I'd have to hunt a little more but I think I can find something that would work.
http://www.proto-advantage.com/store/product_info.php?products_id=2200081
Kind of what I'm thinking..
Let me know what you guys think. Any input would be greatly appreciated.

As long as you get good solder connections and make sure its weather proof it should wirk. Maybe wrap it in some shielding to cut down on electrical interferance from the car. The only worry is the resistance from that length wire may be too much and not work. I'm not sure how sensetive it is to resistance changes. I would say try it, but make sure it works with that length wire before doing a full install. Cool idea.
Sent from my ADR6425LVW using xda app-developers app

Hi. I'm sorry to say that you would be wasting your time trying to extend that cable. The signals from the camera module are low-voltage high speed link running at 25+ MHz. There is no line drivers in the camera module, nor the Nexus mainboard, so they won't be able to drive the cable capacitance, rendering you with a camera that won't work.
IF you had the right circuitry, you could maybe extend the camera half a metre, without extra circuitry, i would guess 10 Centimeters maximum.
I have my HU mounted under my drivers seat along with one of my Amp's and i have extended the Front panel connection so it's up above the rearview mirror. Had the same problem, not able to drive the cable. Added some line drivers and it worked, but only because the signalling speed were below 500 KHz.
// Per.

You extended the camera up there or the LCD? What part would I need to extend the camera? Do you have a part number?
Sent from my SAMSUNG-SGH-I717 using xda app-developers app

Are there no usb cameras that can work with otg cable?
Sent from my LG-P999 using xda premium

Omyn said:
You extended the camera up there or the LCD? What part would I need to extend the camera? Do you have a part number?
Click to expand...
Click to collapse
I think parts you selected are ok. But as zapro said - the problem is in transmitting high frequency signals on such long range so it creates much more complex problem.
You could probably use circuits called "Buffers" to drive voltage level in cable to higher (in your phone its 1.8~3V), like 10~20V. Near the camera there would be also buffers to drive it back to the source level. Also you need pinout of camera connector to generate camera power lines (voltages and ground) in your trunk.
You'd have to calculate max frequency of camera's clock signal (inspecting kernel driver should provide enough info) and get buffers of high enough quality. For normal circuits like this http://www.linuxfocus.org/common/src/article251/TL071.pdf (op-amp is a magical device with hundreds of uses, that also can serve as a buffer) usual maximum working frequency is less than 1MHz. You would need something that's working good up to 25MHz or so (like zapro said).
Everything is doable, it's always matter of motivation and time.

I dunno. At those speeds the wires have to be exactly the same length. I don't think it would work.
You'd be better off setting up a raspi, a touchscreen, a mobile phone and your tablet up to use mirrorop sender and have the raspi change its receiver settings when you put the car in reverse. Put a phone on your license plate or behind the bumper so it can display rear view as a mirror view sender.
I've never played with mirrorview, so I don't know much more than the general outline.

fadownjoo said:
Are there no usb cameras that can work with otg cable?
Sent from my LG-P999 using xda premium
Click to expand...
Click to collapse
This is the route that I must go. My concerns initially were the ability to charge while using the device in USB host mode but that seems to be possible now.
My only concern now would be to find some way to have the tablet switch on the usb camera when the reverse lights are on and mirror the source. I'm thinking something like this might be possible with a IOIO board as an interface. I just don't know what would be the best way to set this up. Maybe something along the lines of a simulated media button from the IOIO when it detects the 12 volts. Then I would have a program like tasker trigger the webcam to open when it detects the media button press.
I would also like a way for when the tablet detects the battery is under 75% then flip a relay to pull the charge straight from the battery as opposed to the cigarette lighter adapter. That way if the car sits, the tablet will never drain to low battery.
I appreciate everyone's input so far.

I don't think the nexus camera is good enough and the angle is wide enough... Camera normally come with 160 degree view which let you see your whole bumper...
Accidentally sent from my Samsung Galaxy Note 2

Been hoping for a solution to this also
I've toyed with the idea of installing a Samsung Galaxy Tab Tablet 2 7.0 in my Nissan Maxima where I already have a rear view camera installed in the trunk key-hole. It's pretty slick, but the screen in the dash ONLY shows the camera image- no other functionality (the radio is in the single-din space below the double din space where my 7" screen is). I'd like to swap it out for a tab with tons more features and still retain use of the camera. Every way I try to make this work leads me to a dead end And this forum is about the only one I've seen online for similar interest.
My original thought was finding the video input lead from the rear view camera, matching the frequency from my existing cam and just piping the signal in directly to that lead, leaving all other circuitry intact. But after reading here, i'm thinking converting a standard NTSC signal to the galaxy rear cam input is not an easy task.
Has anyone found any documentation out there for specs on that camera, frequencies, pin-outs, etc??
Cheers,
Q

I also want to extend front camera ( or rear camera) of my mobile xeomi mi4i without any distortion in quality of video/pic. Even half meter extension will be sufficient. I am ready to drill hole in back cover of Mobile if required. I want to know from where i can get connector cable etc for the same. I guess there won't be any distortion for half meter extension and no external amplifier/ buffer required. Thanks in advance.
QUOTE=Omyn;33894241]You extended the camera up there or the LCD? What part would I need to extend the camera? Do you have a part number?
Sent from my SAMSUNG-SGH-I717 using xda app-developers app[/QUOTE]

[Q] Galaxy S4 Connectors Under Back Cover

Hi -
Does anyone know the specifications of the 4 connectors under the back cover?
I think the ones to the left of the flash are for wireless charging.
What polarity are these?
Can you fry the phone when connecting with wrong polarity or is it protected?
What are the connectors to the right of the flash for?
Thanks!

Two of the four connectors
The Telstra Samsung Galaxy S4 4G has two external antenna ports L1 and R1.
When connecting your Galaxy S4 to an external antenna it's important to only use the R1 port.
The L1 Port is for LTE MIMO operation only.

springarchie said:
The Telstra Samsung Galaxy S4 4G has two external antenna ports L1 and R1.
When connecting your Galaxy S4 to an external antenna it's important to only use the R1 port.
The L1 Port is for LTE MIMO operation only.
Click to expand...
Click to collapse
Thanks but the ports I am referring to seem to be for wireless charging.
More info here: http://forum.xda-developers.com/showthread.php?p=42213467

Bringing this back up to add some info.
I had been researching fixes for the diminished signal when using the Zerolemon 7500mAh battery. Figured out that my laptop TV tuner card antenna uses the same connector as the L1 port on the GS4 and tried it out. I got about 8-10dbm signal increase across all bands. The test was done with the phone stationary inside a concrete walled large warehouse with moderate signal in south DFW.
I noticed that GSM had the best signal, then WCDMA then LTE the lowest. This may be due to connecting to difft towers, or other factors. But I think the concrete walls vs frequencies have an effect on things.
GSM
Before: -83
After: -69
WCDMA
Before: -85
After: -73
LTE
Before: -101
After: -89
Unfortunately I have no idea what type of connector it is, nor where the antenna came from.
Since it has a detachable retractable mast I tested it with and without. It actually had the same signal with it off, so I
would think you'd only need the wire itself to gain signal. My next step will be aquiring another connector, then create a modified version
using ribbon cables that can stick to the inside of the battery door.

The other terminals are for an NFC antenna. Such as in the official QI back, or the Note 2 Antenna fits.

any updates on this?
Starting to look at this area

I plugged a copper wire into the R1 port in the back of the phone and I guess I really messed something up internally b/c now when I don't have a piece of metal stuck in the port I get little to no signal anywhere. Also, since this happened I can no long make calls or texts on LTE b/c my phone's radio will not switch over to make the calls or texts. I can receive them though. Any fixes? I'm assuming a messed up a copper connection under the port by jamming crap in there. I'm going to remove the back of the phone and see if I can see any damage to the circuit board. I will report back with my findings.
EDIT: THIS WAS DONE ON THE SPRINT TRIBAND MODEL. (L720T)

silentdeath631 said:
I plugged a copper wire into the R1 port in the back of the phone and I guess I really messed something up internally b/c now when I don't have a piece of metal stuck in the port I get little to no signal anywhere. Also, since this happened I can no long make calls or texts on LTE b/c my phone's radio will not switch over to make the calls or texts. I can receive them though. Any fixes? I'm assuming a messed up a copper connection under the port by jamming crap in there. I'm going to remove the back of the phone and see if I can see any damage to the circuit board. I will report back with my findings.
EDIT: THIS WAS DONE ON THE SPRINT TRIBAND MODEL. (L720T)
Click to expand...
Click to collapse
Worrying as I've just ordered a mmcx to sma adapter to try something similar. As mmcx to rp-sma seem harder to gt hold of I would be bridgeing with a small piece of wire, but not directly into the samsungs xt aerial port.
The prior posts regarding this on a number of sites are contradictory
Some say that nothing disables any and that the electronics always seeks the highest signal from either internal or external
I saw at least one pot that said you have to manually select (somehow) the internal aerial after using the external
Some say teh external doesn't work and is only for testing purposes, which has apparently been refuted by samsung tech support.
UPDATE
read here
http://forum.xda-developers.com/galaxy-s2/general/external-antenna-socket-warning-t1273292/page8
+ google 'Samsung galaxy s4 how to change antennas' for a youtube vid using battery monitor utility

I think he means these connectors (see attachment)
{
"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"
}
the R1 and R2 antennae are to the right, and aligned vertical...
The others, are aligned horizontal, there's a larger to the right of the flash, and a smaller to the left....
wondering what these are for, is what brought me here....

exactly! i am wondering the same
Ghozer said:
I think he means these connectors (see attachment)
View attachment 3527464
the R1 and R2 antennae are to the right, and aligned vertical...
The others, are aligned horizontal, there's a larger to the right of the flash, and a smaller to the left....
wondering what these are for, is what brought me here....
Click to expand...
Click to collapse
wonder if there was ever an answer to this

The two smaller connectors on the left are contacts for a wireless charging pad.

audit13 said:
The two smaller connectors on the left are contacts for a wireless charging pad.
Click to expand...
Click to collapse
and the other two on the right? any suggestions

I have no idea what the other 2 connectors are for. At first I thought it was for NFC but that doesn't make sense since there are no corresponding connectors inside the back/battery cover.

audit13 said:
I have no idea what the other 2 connectors are for. At first I thought it was for NFC but that doesn't make sense since there are no corresponding connectors inside the back/battery cover.
Click to expand...
Click to collapse
There's a cutout in the back cover for an NFC antenna (it isn't there) that matches perfectly with those 2 pins, which makes me think that Samsung decided to include the NFC antenna in the battery instead after the phone's design stage was done.
I highlighted the area where the pins would have made contact with the back cover NFC antenna in this photo.