## An observation about the new Chrome OS Smart-Lock and Instant Tethering features.

I own a Samsung Galaxy S9 smart-phone, and an Asus Flip C213 Chromebook. And, two relatively new features which Google rolled out are:

• Smart-Lock: The ability to unlock the Chromebook, using the presence of the phone, and
• Instant Tethering: It has always been possible to activate the Mobile Hot-Spot feature of the phone, assuming that a user has a plan that includes tethering, and then to connect the Chromebook (or other device) to it, in the form of a mobile, Wi-Fi Access Point. But, with Instant Tethering, the availability of the phone as a tether is supposed to be more quickly visible from the Chromebook, and theoretically, accessible with a single click.

What some people have reported is, that this feature does not always work 100%, even though the procedure was followed, which my readers can find in many other places on the Web, to set up the feature. I recently experienced as well that, on my first try, these two features were not working at all, when the Chrome OS version on my Chromebook was ’80.x’. Yet, even during the interval of my trials, an update to the Chrome OS version had presented itself, to version ’81.y’. And since the update, the features seem to work 50% of the time.

There was an additional step which can be taken, but should not be 100% necessary in this case, and which I took, which is outlined in this article:

https://www.howtogeek.com/fyi/chrome-os-instant-tethering-comes-to-more-android-phones-heres-how-to-do-it/

I will explain below, Why I changed the flag under:

chrome://flags/#instant-tethering

From ‘Default’, to ‘Enabled’. A reboot was required…

One reason these features may still not work 100% for me, could be the possibility of the phone going into ‘Deep Sleep’…

## About a minor (Home-Screen) nuisance I’ve experienced on Android deviceS.

I have owned several Android-based devices, and some of those were purchased from Samsung, those being:

• A Galaxy Tab S, First Generation,
• (An earlier Smart-Phone),
• A Galaxy S6 Smart-Phone,
• A Galaxy S9 Smart-Phone.

A feature which all these devices have, is the Touchwiz Home-Screen (program). This is the default of what the devices display, when not displaying a specific app, when not displaying the app drawer, and when not displaying ‘Bixby’ (most recently). An unfortunate behaviour of the devices is, that Touchwiz will sometimes crash. In my experience, when it does, this is no big deal, because it restarts automatically, and after a few minutes, even my Notification-Bar Entries will reappear. If certain apps fail to make their notifications reappear by themselves, then launching those apps from the application groups will make their notifications reappear.

I tend to rate each Android device, according to how rarely its Home-Screen will crash in this way. According to that, my Google Pixel C Tablet fared better because its home-screen has never crashed on me. My S9 Phone fared almost as well, in that Touchwiz seldom crashed. But now I think I’ve identified a situation which will frequently cause Touchwiz to crash on the S9 Phone.

Firstly, as I’m writing this, the firmware on that phone is at its latest version, that being the October 1 patch, of 2019, of Android 9.

I discovered that I can trigger this situation, as I was experimenting with the Super-Slow-Mo camera recording mode, in which the camera can record up to 0.4 seconds of video at 960FPS, at a resolution of 1280×720. When the camera does this, it generates a 20MB video, after that has been compressed via a standard H.264 CODEC into an .MP4 container-file. I have the default set, to record all camera footage to the external Micro SD Card. Having recorded the super-slow-mo video once, triggered this behaviour.

There is a simple way to interpret what has caused this, that does not seem to lay any blame on Samsung: When the camera is recording video that fast, it’s generating data faster than the external SD Card can store it. Therefore, the data takes up RAM, until some later point in time, when the O/S has transferred the data to the SD Card, by writing it out. This moment was reached several seconds later.

Here’s where the news gets a bit worse. I can download This 3rd-party app, that’s designed to test what speed of external SD Card I have. The reason I need to do this is the fact that I never seem to remember exactly what type of SD Card I purchased, for use with one specific device.

According to this app, my external SD Card can be written to sequentially at ~12MBytes/Sec. That makes it a Class 10 card. Yet, 20MB of data are to be stored in 0.4 seconds. In fact, simply running the benchmarking app caused a second Touchwiz crash, which was just as inconsequential as the first, that I was trying to investigate. What this seems to suggest is, that virtually no SD Card that I can buy, can really be fast enough to be written to at the speed with which the camera app can generate its data. The camera app will need to cache its footage in RAM, before that footage has been written to the SD Card.

Further, the footage is certainly being stored in RAM in an uncompressed form of data (384 raw frames), while what’s to be written to the SD Card is finally compressed. (:1)

And yet, either of these two apps will cause the Touchwiz crash. Hmm… I think that for the moment, I’ll just hold my horses, and record a maximum of 0.2 seconds of Super-Slow-Mo. Thankfully, this is a parameter that I can choose, with the little icon in the upper-right-hand corner of the view, before shooting.

(Updated 11/17/2019, 12h10 … )

## Comparing two Bose headphones, both of which use active technology.

In this posting I’m going to do something I rarely do, which is, something like a product review. I have purchased the following two headphones within the past few months:

The first set of headphones has an analog 3.5mm stereo input cable, which has a dual-purpose Mike / Headphone Jack, and comes either compatible with Samsung, or with Apple phones, while the second uses Bluetooth to connect to either brand of phone. I should add that the phone I use with either set of headphones is a Samsung Galaxy S9, which supports Bluetooth 5.

The first set of headphones requires a single, AAA alkaline battery to work properly. And this not only fuels its active noise cancelling, but also an equalizer chip that has become standard with many similar middle-price-range headphones. The second has a built-in rechargeable Lithium-Ion Battery, which is rumoured to be good for 10-15 hours of play-time, which I have not yet tested. Like the first, the second has an equalizer chip, but no active noise cancellation.

I think that right off the bat I should point out, that I don’t approve of this use of an equalizer chip, effectively, to compensate for the sound oddities of the internal voice-coils. I think that more properly, the voice-coils should be designed to deliver the best frequency response possible, by themselves. But the reality in the year 2019 is, that many headphones come with an internal equalizer chip instead.

What I’ve found is that the first set of headphones, while having excellent noise cancellation, has two main drawbacks:

• The jack into which the analog cable fits, is poorly designed, and can cause bad connections,
• The single, AAA battery can only deliver a voltage of 1.5V, and if the actual voltage is any lower, either because a Ni-MH battery was used in place of an alkaline cell, or, because the battery is just plain low, the low-voltage equalizer chip will no longer work fully, resulting in sound that reveals the deficiencies in the voice-coil.

The second set of headphones overcomes both these limitations, and I fully expect that its equalizer chips will have uniform behaviour, that my ears will be able to adjust to in the long term, even when I use them for hours or days. Also, I’d tend to say that the way the equalizer arrangement worked in the first set of headphones, was not complete in fulfilling its job, even when the battery was fully charged. Therefore, If I only had the money to buy one of the headphones, I’d choose the second set, which I just received today.

But, having said that, I should also add that I have two 12,000BTU air conditioners running in the Summer months, which really require the noise-cancellation of the first set of headphones, that the second set does not provide.

Also, I have an observation of why the EQ chip in the second set of headphones may work better than the similarly purposed chip in the first set…

(Updated 9/28/2019, 19h05 … )

## Overheated Circuitry

One of the things which I do frequently, is ‘walk around’, or, ‘use public transit’, with my disposable earphones plugged in to my Samsung Galaxy S9 Smart-Phone, and listening to music. These earphones are clearly not the ones, which had the AKG seal of approval, and which shipped with the phone. But this week-end marks the second heat-wave this Summer, when outside daytime temperatures exceeded 31⁰C, with direct sunlight and not a cloud in the sky. And under those conditions, the battery of my phone starts to hit a temperature of 42⁰. One of the facts which I know is, that Lithium-Ion batteries like the one in my phone do not tolerate temperatures exceeding 41⁰C.

A peculiar behaviour which has set in for the second time, during this second heat-wave of the season, is that the music I was listening to would either back-space to the beginning of the song, or skip ahead one song, or just stop. So, a catastrophic sort of explanation I could think of would be, that the entire phone, with its battery, is finally just having a meltdown. But, a second possibility exists, that merely the chip in the earphone-cord could be malfunctioning. After all, the little pod in the earphone-cord has one button and a mike, and it’s actually cheaper to mass-produce the chip that makes it work, than it would be to mass-produce other sorts of discrete components. One cheap chip could just be malfunctioning in the extreme heat, and not the entire, complex circuitry of the phone. (:1)

The earphones cost me about \$15, while the phone is much more expensive than that.

But even if it was true, that only the little remote-control in the earphone-cord was malfunctioning, this can lead to impractical situations, because just random patterns, of unreal button-press-combinations, could also send the software of my phone into a confused state, and even so, if the circuitry in the smart-phone never malfunctioned. This behaviour could get misinterpreted by the security apps of the phone, let’s say, as though somebody had ripped the earphone-cord off my head, and thrown all my possessions around.

All that was really happening was that my music was no longer playing, as I was walking home normally, in the heat, with my overheated electronics. And when I got home, my actual phone never displayed any signs of having malfunctioned.

(Updated 8/17/2019, 17h50 … )