Distinguishing between Different Battery-Types

One of the things I recently did, was to pair my Linux-laptop, which I name ‘Klystron’, with an external Bluetooth-Mouse, because even though this advanced, HP laptop has as its hardware, an advanced Synaptics touchpad, that emulates a mouse quite well, we can grow tired of always using the built-in touchpad. I documented here, what I needed to do, to accomplish this pairing.

Well one of the features which the KDE Desktop Manager gives us under Linux, is to indicate the battery-charge-levels, not only of the laptop’s built-in battery, but also those of attached BT-mice, or of anything else which is connected, that has a battery, and the hardware of which is able to report as telemetry, the battery-level.

What was surprising me about this arrangement, was that the indicated battery-level of the mouse seemed to track accurately over the days, that the mouse was connected. This surprised me, because as I was remembering events, I had placed Nickel-Metal-Hydride batteries into the mouse some time ago, and most devices which are physically designed to accept batteries in the AA-format, or in the AAA-battery-format, would be calibrated for Alkaline, Zinc-Manganese-Oxide batteries. When such accessories try to gauge the battery-level, if they have the chip to do so, the voltage-curve of a Ni-MH battery tends to remain lower than that of an Alkaline. A fully-charged Ni-MH only generates about 1.2V per cell, while an Alkaline generates 1.5V. And so when a Ni-MH battery is inserted, this chip will usually indicate a partially-discharged battery, even immediately after it has been charged, and then, when this battery-type finally goes dead, its voltage will collapse almost instantly.

Before the indicated charge-level dropped below ‘70%’, I decided to take the AA-format batteries out, and to put them into a charger I have, that’s designed for Ni-MH batteries, and what I found was, that the LEDs in the charger refused to light up, for the inserted batteries. They did not indicate partially-charged or anything, they just stayed ‘off’.

And so next, my thinking was, ‘Darned! I now have either batteries which have failed on me, or worse – a charger which has failed on me 100%…’

Continue reading Distinguishing between Different Battery-Types

My ongoing experiences with my Linux laptop and this time, Bluetooth.

One of the observations I had written earlier, about the Linux laptop I name ‘Klystron’, illustrated in depth that it has issues with its Realtek chip-set, that provides it with both WiFi and Bluetooth connectivity, presumably providing both through the same physical antennae.

> BTW, have Linux developers ever discovered, that this chip is meant to have two antennae, which the laptop was built with, and that the drivers are supposed to switch back and forth, to whichever antenna was giving the best signal at any moment? I.e., that with the lid open, one antenna should be used, while with the lid closed, the second antenna should be used? I just thought I’d mention it as a segway… <

The Bluetooth functionality of this chip-set, on my Linux configuration, does not seem to work at all. And so something which I have done, which some people might find odd, is to buy a Bluetooth-dongle, to put that in a USB-port on the side, and then to pair my external mouse.

Actually, this has only worked on a second attempt, with a second BT dongle. I had given up on the first BT dongle, thinking that that dongle must somehow have been incompatible with the Bluetooth Stack in some way, failing consistently on both my Debian / Jessie / 8 systems. And I had erroneously come to that conclusion, even after the same, first dongle worked fine, on a Debian / Squeeze / 7 laptop.

The actual user-space software works fine, even telling me that the newer, better, $5 dongle detects the Realtek chip with its antenna only 20cm away (where it’s inside the attached laptop), and with my neighbor’s sound-bar detected upstairs from my flat… For another day.

I know that my ( “Logitech M557″ ) BT mouse works fine, because I can pair it easily with my tablet(s).

There is a bit of a trick, that will finally enable the Debian / Jessie laptop to pair with the same mouse. I need to use the GUI normally, to tell it to pair, while the mouse is in pairing mode, at which point the GUI shows activity for a few seconds, and the data-exchange-bars just seem to cease, and the mouse next stays in pairing mode, with its own blue LED still flashing rapidly, waiting to pair.

What seems to go wrong, is that after Linux has established a pairing, Linux fails to send a signal to the mouse, that it should switch from pairing-mode, to usage-mode, so that its LED extinguishes.

The way I found this out, was to wait after the data-exchange-bars in the Linux GUI vanish, where that mouse still has its Paired and Trusted icons, until the mouse ‘decides on its own’ to exit pairing mode, as if pairing has been unsuccessful – i.e. I waited for pairing-mode to time out on the mouse.

And then what followed, was that the mouse works, and that the GUI shows me that data is being exchanged steadily. After I have done this, the pairing is successful and apparently stable! :-D

What this also tells me, is that I could have kept using the old dongle… :-( But then again, the new dongle has USB 4, which the old one didn’t! :-)


BTW, This is a kind of BT mouse, that does not require we pair using a PIN. The GUI has a separate button for that.



Bluetooth Dissed

One argument I hear often from laypeople, is that they don’t like Bluetooth, because at the user-level, Bluetooth Pairing is hard.

People who are knowledgeable in Computing understand, that every time we create a Bluetooth Pairing, our devices are establishing a communications channel, which is as secure as the authors of Bluetooth can make it, due to Advanced Encryption. So we see that there is a potential benefit to this.

For example, in the case of a keyboard which is connected to a tablet – which means that a BT session is underway – it can happen at any time, that we type in our password to unlock the tablet, or to unlock any of our accounts on the Internet. That could be made a generic wireless link which is extremely easy to set up. But then, since we’re always weary of an eavesdropper, the link would be of an ideal format, to steal all our passwords from us through direct exploitation.

But because we’re using Bluetooth, in fact it’s an encrypted link. So even if the ones and zeroes that make up a communication were intercepted, the hypothetical eavesdropper would still not be able to exploit them.

And so I can empathize with knowledgeable people, who feel that the added difficulty in establishing a Bluetooth Pairing, is well worth the effort.

Continue reading Bluetooth Dissed

Pixel C Keyboard Pairing Problem – Solved.

I own a Google Pixel C Tablet, which I did order with its recommended, accompanying Bluetooth Keyboard. I’ve been using it with a lot of fun for months now. But yesterday evening, the problem finally happened to me, which I had been contemplating, which was, that I had spent such a long series of hours using them, into the night, that the keyboard actually went dead. I mean, the batteries of the KB could not live as long as my session would have, and pressing keyboard keys eventually had no more effect on the tablet, as the pressed keystrokes were no longer being received. So what I did was to close the tablet over the keyboard in the recommended way, to plug the two in to have them charge, and to leave them that way overnight.

Next morning, I wanted to find that not only the tablet charge was back at 100%, but that I could just step in and start using the keyboard again. But what I found, was that the tablet – with its battery at 100% – was still unresponsive to the keyboard. So my first conclusion was, that the state of the Bluetooth Pairing, was somehow corrupted on the software-level, between the tablet and the keyboard. So I followed ‘The usual, basic steps, to re-pair the two':

  1. Separate the tablet from the keyboard. The on-screen keyboard will become available.
  2. On the tablet, go into Settings -> Bluetooth, tell it to Forget all Bluetooth Pairings, and turn Bluetooth Off.
  3. Re-Attach the tablet to the keyboard, and watch the tablet ask me to turn Bluetooth On. Do so.
  4. Wait for the Tablet to show me the PIN-number, which I am to type into the keyboard, to make them pair.

The next problem was, that Step (4) above wouldn’t happen. So my next thought was, that one of two things could finally be wrong with my keyboard:

  • The charging system / KB battery could genuinely be defective (Unlikely, as they are virtually still new, and were working before).
  • The logical corruption in the Bluetooth Pairing State, between the tablet and keyboard, could be more-deeply corrupted than I thought, from the broken-off session the previous night, maybe even at the Firmware Level.

So now I proceeded with ‘A more-robust procedure, which amounts to resetting the keyboard, as there does not exist a more-proper, explicit way to reset that keyboard':

  1. Separate the tablet from the keyboard.
  2. On the tablet, go into Settings -> Bluetooth, and tell it to Forget all Pairings / and turn Bluetooth Off.
  3. Soft Boot the tablet.
  4. After the orderly reboot has finished, Go To Step (3) in the more-basic procedure above.

And what I found next, was that after I had allowed the tablet to turn Bluetooth back On, it did in fact greet me with the 6-digit PIN-number, and after I typed that into the keyboard, and after I had hit Enter on the KB, the keyboard worked fine again.


Now, there exist people who claim, that they tried all the steps above, numerous times without success, but that “Suddenly, the keyboard started working again.” To the best of my understanding, what must really have been happening to those people, is that they did try all the above steps, but ‘Maybe not in the correct sequence?’


(Edit : )

Even when there is no malfunction taking place, I never try to reboot my tablet, with the BT Keyboard connected.

My best guess for what goes wrong with this KB, would be that it keeps its local store of information, with its encryption key, as a volatile (RAM) chip, with no backup power-supply. It lacks a non-volatile chip to store that. Hence, when the battery goes fully flat, its encryption key is corrupted, and depending on the extent to which encryption is hardware-based these days, it can also leave a trace in the firmware of the tablet itself, that the tablet was paired with it. Hence the reboot needed.