Occasionally, for no apparent reason, my Android phone refuses to accept a battery charge. (originally published 15 February 2014)
Here’s the only way I’ve found to fix this problem on my Samsung Insight II SGH-T679 with Android 2.3.6 Gingerbread phone:
Turn off phone
Remove SIM card
Remove SD card
Wait at least 3 minutes. (I’ve had to wait as long as 60 minutes.)
Replace SD card
Replace SIM card
Turn on phone
Plug in charger
This reset procedure works for me. It may or may not work for you. (8 Oct 2014) It also works for my new SGH-T399 phone.
7 August 2014 This may or may not be a coincidence, but I’ve found that since abandoning third-party battery chargers and returning to a Samsung manufactured charger, my phone’s battery behaves better, without loss of charging function.
I’ve also stopped buying third-party batteries. They’ve been short-lived. I found what seems to be a genuine Samsung battery on Amazon. The combination of genuine Samsung battery and Samsung battery charger seems to provide both longer battery discharge times and better charging behavior.
I’ve not needed to resort to the charging system reset procedure since installing the genuine Samsung battery and using the genuine Samsung charger.
Last week I ran into an ingenious Windows XP infection.
The victim’s hard drive rapidly runs out of free disk space. I never did identify the exact culprit. The virus continually appends to a hidden file named “avenger.txt” in the root of drive C:. When I found it, c:\avenger.txt was over 500 gigabytes in size!
My cure was to reformat the disk and install a fresh copy of Windows XP.
A client recently complained that his Windows XP computer had run slowly for weeks and now Windows wouldn’t start. Following power on, the Windows XP splash screen appeared for a few seconds, followed by a system reset. This sequence would repeat in an endless loop.
A low-level check of the disk revealed no bad sectors and Memtest86 revealed no bad cells. I used an Ubuntu (a Linux distro) boot CD-ROM; Ubuntu couldn’t see any partitions on the hard drive(!). This is not good news. I booted from a BartPE1 CD-ROM. It couldn’t see any partitions on the hard drive either. I booted from a Windows XP setup CD with a view to doing a repair install, but it could not see a Windows partition or system on the hard drive. Uh-oh.
The cure for this sick pup? Boot from a BartPE CD-ROM, go to the command prompt, and enter the command CHKDSK C: /F. On this disk, chkdsk needed nine hours(!) to repair the NTFS partition and its table. At the 19% point during phase 1, the screen didn’t update for more than an hour. Several times, the PC seemed to have frozen. I was tempted to shutdown BartPE, but the PC’s drive activity light indicated that something was accessing the hard drive, so I allowed it to continue.
After nine hours, chkdsk reported that it had finished repairing the disk and exited to the DOS prompt. I rebooted the PC. Sure enough, Windows started and ran. A quick look revealed tbat the 160 GB disk had 0 (zero!) bytes free. This sick puppy needed more attention, but at least its data could now be salvaged.
I don’t need BartPE often, but when I need to access an NTFS partition and run a Windows or DOS command on a machine that can’t boot Windows, it’s just what the doctor ordered.
BartPE (Bart’s Preinstalled Environment) is a lightweight variant of the 32-bit version of Microsoft Windows XP or Windows Server 2003, similar to Windows Preinstallation Environment, which can be run from a Live CD or Live USB drive. – from Wikipedia
I was asked to repair a Windows Vista computer that would consistently fail with a “blue screen of death” within minutes of starting. This is usually a symptom of a memory problem, but memtest86 (run from a DOS boot CD-ROM) failed to find a problem. Sometimes an overheated CPU will cause this problem, but the CPU seemed to be in firm thermal contact with its heatsink and both the CPU and power supply cooling fans were spinning. Sometimes a bad disk sector in the middle of the system kernel will cause this symptom, but testing the disk revealed no bad sectors. I suspected a weak power supply, but the computer ran fine with Windows in Safe Mode. I finally concluded that one or more 32-bit Windows drivers (which don’t load in Safe Mode) or anything else in Windows that doesn’t load in Safe Mode must be the culprit.
While in Safe Mode, I noticed that someone had installed a half-dozen unusual anti-malware and driver management utilities, plus a large assortment of toolbars. I tried to uninstall them, but most refused to uninstall in Safe Mode. Still in Safe Mode, I ran services.msc and disabled services that were associated with these dubious programs.
When restarted, the computer ran fine. Those utilities must have been fighting over the same interrupt. So now it was just a matter of removing the superfluous junk that had been installed, updating Windows, and installing Microsoft Security Essentials.
What caused the problem?
When prompted to install a supposed piece of security software, novices often reason “If some is good, more must be better”. With security software, this is not true.
Caveat:Disabling the wrong service in services.msc can cause serious problems. Proceed with caution. Be prepared to reinstall Windows or at least to restore to an earlier restore point if something breaks.
Last week I was asked to diagnose a sick Windows PC. I booted a DOS-based diagnostic utility program from a CD-ROM. (For diagnosing hardware at its lowest level, a single-tasking operating system ensures that a virtual memory manager isn’t writing to the disk that you’re trying to diagnose.) The program performed sluggishly. Reason? A USB-based wireless keyboard. Once I’d replaced the keyboard with a plain-Jane keyboard wired with a mini-DIN connector (first seen on IBM PS/2s), all was fine.
I’m surprised that the DOS-based program worked at all with the wireless keyboard. I guess that this Dell Dimension had a BIOS (Basic Input/Output System) that worked with a wireless keyboard and the DOS-based program used the BIOS for its keyboard input.
I’ve never understood why users choose wireless keyboards and mice. If you could see the additional layers of error detection and correction that are added, you’d wonder, also. Computers are flaky enough without needlessly degrading their reliability with wireless peripherals.
I’m convinced that every tech company contains a handful of engineers and technicians who know their product; every other employee helps create layers that prevent customers from speaking with them. AT&T is no different. I have a couple Miami-based clients who were unable to see their own websites (hosted in Orlando) when using their AT&T DSL Internet connections. Their traceroute results revealed that their packets were being dropped by AT&T, rather than being routed to Level3. Their packets never left AT&T’s network.
Twice I contacted AT&T’s DSL support department without success. One support person suggested that AT&T’s DNS servers may not have received the update for the clients’ domains. I was certain that this wasn’t the case, but obediently followed her instructions on how to request a DNS update via email, with no result. The other support person suggested that the problem wasn’t AT&T’s. On a theory that maybe Level3 was rejecting the packets, I posted a request for help on a Level3 tech support page and received no reply.
I called again. John Ledyard, another AT&T DSL support person, listened, agreed that the problem could be in AT&T’s routing tables, and asked me to email him the source and destination IP addresses together with a broken traceroute result. Mr. Ledyard told me that although he couldn’t personally fix the problem, he would forward my email to someone who could fix it. Voilà! Within a week, the packets were reaching the destination host.
I don’t know exactly what was broken or why the problem occurred, but now it’s repaired. All’s well that ends well.
In the late 1960s I was part of a small product development team whose goal was the design of a frequency-synthesized radio receiver. This included a phase-locked frequency synthesizer whose output could be set to anything from 156 to 186 Mhz in 100 Hz steps. It used two VCOs (Voltage Controlled Oscillators — their output frequencies vary as a function of steering voltage). The output frequency of each VCO was determined by a phase-locked loop. It was the first time that our employer had developed a phase-locked loop frequency synthesized product. The frequency synthesizer’s high-speed VCO covered 30 MHz in steps of 1 MHz. We distributed the 30 MHz range amongst three oscillators, each of which covered a 10 MHz range. While prototyping, we discovered low-frequency noise sidebands on the VCO’s output signal. We needed to remove these noise sidebands, or they’d appear in the receiver’s output. On a spectrum analyzer, the noise sidebands appeared to be 20 to 400 Hz each side of the output signal and 15 dB below output signal level.
After selectively freezing circuit components while observing the noise sidebands, we learned that the carbon composition resistors in the loop filter were (one of) the culprits. That was a surprise: I had always thought of resistors as discrete inert lumps. I learned that carbon composition resistors consist of tiny grains of carbon bound to tiny grains of ceramic. We were seeing noise caused by random molecular motion. These voltage spikes, though mere microvolts in amplitude, were modulating the VCOs, resulting in noisy sidebands on the VCO’s output signal.
We substituted carbon film resistors, and discovered that the noise sidebands dropped substantially. I learned that carbon film resistors can dissipate less power, but offer a more contiguous medium than ordinary carbon composition resistors. Once we’d peeled back this layer, we discovered that the ceramic feedthru filter capacitors that fed each oscillator with DC power were also modulating the high-speed oscillator.
Instrumenting this circuit was interesting: we couldn’t load the phase locked loop itself with instrumentation or the phase lock would fail; we could only examine the noise sidebands that were an effect of noisy phase locked loop components. Since those days, I’ve learned that often we can’t directly examine phenomena — we can only see indirect effects. I suppose that this is how astrophysicists have discovered dark matter. Dark matter doesn’t reflect or refract electromagnetic energy; it’s detectable only indirectly because it’s affected by gravity.
What do we ever know about anything?
B.F. Skinner was alternately praised and despised because his brand of psychology, which became known as behaviorism, admitted that it’s impossible to know the inner workings and hidden mechanisms of humans; we can only observe behavior. He had a point: are humans less mysterious than electron movements or dark matter? In the end, what do we know about anything or anybody other than its behavior?
Use Traceroute to identify which enroute router fails to route your UDP packets to the destination host. Often the culprit is a firewall or a mis-configured border router. Traceroute for Android completes my little bare-bones toolbox for troubleshooting Android IP communication problems.
What about my iPhone? Nice Trace, available from iTunes, seems to display traceroute data for the iPhone. I’ve not tried it.
Offices are introducing 64-bit Windows 7 PCs into workgroups of existing 32-bit Windows XP PCs. Allowing locally connected printers on the 32-bit Windows XP PCs to be shared over the network by the 64-bit Windows 7 PCs may seem to be impossible, if while adding a printer to the 64-bit Windows 7 PCs, you merely browse to the shared printer that’s locally connected to a 32-bit Windows XP PC. I’ve never been able to make this work. However, I have found a method that does work. Assume
A 64-bit Windows printer driver for this printer is available. (Check its setup CD.)
Existing 32-bit Windows XP PC with locally attached shared printer is named FRONTDESK.
This locally attached printer is shared with share name HPLaserj1.
Follow these steps:
Ensure that the 64-bit Windows 7 PC has the correct 64-bit printer driver installed. One way of doing this is to
Temporarily remove the shared printer from the 32-bit Windows XP PC and connect it via USB to the 64-bit Windows 7 PC.
Within Devices and Printers, add the new printer.
After the printer has been installed on the 64-bit Windows 7 PC, remove it and reattach it to the 32-bit Windows XP PC. You may delete the shadowed printer icon from the 64-bit Windows 7 PC’s Devices and Printers group.
On the 64-bit Windows 7 PC, within its Devices and Printers group, choose Add Printer.
Choose local printer. (I know that you want to choose Networked printer. Don’t.)
Choose Add a port. Name this new port \\FRONTDESK\HPLaserj1. The 64-bit Windows 7 PC should find the printer that’s shared by FRONTDESK and add it to its Devices and Printers group.
I thought that I had written an article about fixyourownprinter.com long ago, but yesterday I discovered that while my website contains a link to fixyourownprinter.com, I had never mentioned it here. Now I have remedied that.
Fixyourownprinter.com has some remarkably clued-in people onboard. I’m impressed with how much model-specific troubleshooting information can be found there. Give it a try the next time your printer misbehaves.
My Android phone occasionally disconnects itself from the Internet, especially after re-starts. I check connectivity using this procedure. The disconnection cause? For some reason, on my Samsung Insight phone the “Use packet data” checkbox randomly unchecks itself. To reconnect, I go to Home, Settings, Wireless and network, Mobile networks. Make sure that “Use packet data” is checked. Test again.
If no connection, choose “Network operators” under “Access point names”, then choose “Search now”. Make certain that your carrier’s name appears; you may be out of range of a cell site. Another possibility is that your phone may have forgotten who your cellular provider is; correct this within “Network operators”.
If you still can’t connect to the Internet, contact your cellular provider.
Update, December 2015: My Samsung Galaxy Light SGH-T399 phone with Android 4.2.2 is slightly different than my older Android 2 phone. At the top of this article, I added a large screenshot from it. I got to this screen by tapping
While working at a customer site, I needed to quickly join a laptop PC to their LAN (local area network). The customer produced a yellow Category 5 (“Cat 5”) patch cable to connect the laptop PC to an open port on a switch. After a few minutes of wondering why the laptop wouldn’t join the LAN, I closely examined the cable’s ends. It was a crossover cable. It wasn’t labeled “crossover”; I guess that its manufacturer thought that its yellow jacket color was sufficient to identify it as a crossover cable. (Yellow has become the de facto standard jacket color for crossover cables.)
I recommend that organizations keep no yellow-jacketed straight-through Cat 5 patch cables on site. Reserve yellow jackets for Cat 5 crossover cables only. You’ll reduce troubleshooting time.
Use Unix / Linux commands to check your Android’s Internet connection.
If your Android web browser can’t display your favorite sites, the device may have lost its IP connection to the Internet. You can check this by using three simple Linux commands. (Android is built upon a Linux foundation.) This requires five steps:
Install the Terminal Emulator app. (You’ll find Terminal Emulator within the Google Play Store on your Android desktop.)
Run Terminal Emulator. Enter the command netcfg (and press Enter). Your current IP address will be displayed in the third column for one of the devices in the first column. On my phone, the Internet interface device is pdp0 (the bottom line in the first screenshot). The fourth column displays your subnet mask.
The command netstat -rn will display each active communication session: protocol, bytes in transmit and receive queues, your IP address, a colon followed by the active port, and the IP address and active port of the host with which you’re communicating.
Again, run Terminal Emulator. Type the command ping 126.96.36.199 (and press Enter). Internet node 188.8.131.52 (which is a Google DNS server) should reply. TTL is Time To Live — the number of hops remaining in the packet. Time is the number of milliseconds required for a packet to traverse the route to and from 184.108.40.206. If you’re not connected, you’ll see a message such as Network is unreachable.
Finally, let’s make certain that you have DNS (Domain Name Service). Run Terminal Emulator once more. Type the command ping www.amazon.com (and press Enter). If your DNS worked and you have IP connection, Amazon’s server will reply.
This works on my stock T-Mobile Samsung SGH-T679 phone running Android 2.3.6. I have not rooted it, yet. There may be better ways to check Internet connectivity on Android devices. I’m new to Android and still a novice, though I first installed Linux circa 1993. If you know of a better method, please advise me. I wrote this article on my Android phone; it was a struggle, especially when trying to copy and paste. Any text editing suggestions?
On my phone, I can abort the pings and return to the command prompt by simultaneously pressing the Volume Down button (on the left edge of the phone) while pressing the Z key on the keyboard. This simulates a Ctrl-Z key sequence from a full-size keyboard.
Restore your last command
To restore your previous command to the command line, press the Volume Down button (on the left edge of the phone) while pressing the P key on the keyboard. This simulates a Ctrl-P key sequence from a full-size keyboard. You can backspace to edit the command. Press Enter to execute the command.
Display nearby WiFi access points in the palm of your hand.
When I arrive at the site of a client who needs WiFi help, my first step is to survey the site for existing WiFi RF signals. I usually use NetStumbler on a netbook. Now I can perform a similar survey on my Android phone, which I carry in my pocket.
I’ve tried Meraki WiFi Stumbler and Wigle WiFi Wardriver. For this survey application, I prefer Meraki WiFi Stumbler. It provides a bar chart with WiFi channel numbers on the x-axis and wireless access points’ (identified by their SSIDs) signal strengths in dB on the y-axis. It seems to be less sensitive and scan slower than Wigle, but its display is ideal for a quick WiFi site survey. Wigle is more comprehensive and an impressive piece of work, but its added features aren’t needed for ad-hoc WiFi site surveys.
My headline calls this hardware/software system a “spectrum analyzer”. That’s not strictly true. A full-blown spectrum analyzer displays all of a signal’s blemishes: distortion products, noise sidebands, harmonics, etc. The graph displayed by Meraki is merely a symbolic representation of nearby WiFi signals, after filtering out their blemishes. In most cases, it’s all the information that I need.
Oct 22: I’ve begun to use WiEye. I like it. Its display is simple, provides excellent resolution, and quick response. I found it in the Google Play Store.