Smartphones

As I stated in my previous post, I would be talking about the Nexus 5x.

This isn't going to be so much about the phone itself, but more about the crappy experience I've gone through these past few months that lead me to buying three phones within 6 months.

Since I bought my Galaxy Nexus a few months before the Nexus 4 was released, I had hung onto it for quite a number of years (especially when I was unemployed for almost two years). When I got my job earlier this year, I knew I was going to need some sort of upgrade, since the Galaxy Nexus was being really sluggish.

Since the Nexus One, I stuck with keeping it stock and unrooted until I got a newer phone. My friend/co-worker said that he read about a cache filling up that causes smartphones to be sluggish and it can only be cleared if the phone's rooted (factory data reset would also work). I didn't want to tinker with my phone any, so I just dealt with it while looking at some new phones. I also wanted to upgrade because the Galaxy Nexus was "3.5G" and not true 4G.

The first phone I found was Alcatel's Idol 3 (or whatever it is, I'm too lazy to look up the correct name right now), which I thought was a very nice phone for the price (though reviews said that the interface was a bit iffy).

I stuck with the phone as the "phone-to-get" until I saw news of ASUS's ZenFone 2 - the top model being $50 USD more than the Idol 3 and having better specs. I was quite ecstatic, but the large screen was the main drawback for me.

I kept up with upcoming phones until the ZenFone 2 was released, and I bought my first one. I liked it quite a bit (save for the large screen, but at least ASUS has a "One Hand" feature that remedies that, though slightly awkward to use sometimes) and I used it no differently than my Galaxy Nexus.

That was the problem.

When I was putting my phone back into my bag, I kinda spun it in my hand to re-orient it to slide it into the bag in the correct orientation (I like keeping my things oriented in certain ways for efficiency), but this time, out of the numerous times I've done it, the phone slides out of my hand and falls onto a large, sealed, lead-based battery. I'm talking about ones that are about the size that would go into the average sedan.

It fell (long) edge-first onto the terminal of the battery, bounced, hit the wall, and into a metal box. I'm not sure if there was a grimace on my face, but I was definitely cringing - the first non-Otterbox case I use and I drop it onto a battery. I didn't even see that it hit the terminal, but when I pulled the phone out of the metal box, and saw the shatter pattern, I immediately was upset the half-second between that and turning the screen on to see about 1/6 of the screen not working.

It was still useable, but I put it into a thick, plastic bag to keep the glass shards from going everywhere, and at some point I took the case off while keeping it in the bag (which became a bad idea because it scratched the glass of the camera glass).

How did I know it landed on the battery terminal? There was a dent in the plastic bezel, even though the case was some sort of plastic rubber stuff (I wish I could describe it better). At the least, the case prevented a much worse damage, but still didn't protect my phone like I wanted.

I panicked, and bought a new ZenFone 2, but since Amazon didn't recognise my sign in, they disabled my account. I had to make a new password and re-enter my  credit card info before I was able to redo the order.

At some point afterwards, I was talking with my friend/co-worker about it and he was suggesting I see if I could get the screen repaired. At this point, I hadn't calmed down yet, so I ignored his suggestion then.

When I got home, I then looked at replacement screens, which was $30-50 USD, and I first went with the cheaper option after cancelling the order for the new ZenFone 2. When the screen was out for delivery, I decided to go ahead and disassemble my phone, so that it'd be ready.

It didn't even cross my mind to backup my data at all.

I reached the point of no return when I removed the screen and digitizer assembly from the plastic, as I had to pretty much break the screen even more to get it out.

Bad became worse when I got the replacement screen, as it was for the model before my phone (ZE550ML... or was it CL?) and (probably) wasn't compatible with my phone (the backlight came on, but no image). I returned it and went with the slightly more expensive option, but had to wait at most a month for it be delivered from Hong Kong.

I had no choice but to go back to the Galaxy Nexus.

(Also, I'll mention now I had problems booting correctly, but I was unaware at that time.)

After waiting about two or three weeks, I try again, but I had the same problem, where the backlight would turn on, but not give me an image at all. (Also, the phone itself was turning on just fine, but again, I was unaware.) I stuffed the parts into anti-static bags (the replacement screen going back into the packaging it came in) and just set it to the side.

I tried to continue using the Galaxy Nexus, but eventually I broke again, as Google Play Newsstand crashed without warning (I had the problem before getting the ZenFone 2), and ordered another ZenFone 2.

While getting apps installed to the new ZenFone 2 (via Google Play Store web-version), I noticed that there were two ZenFone 2 entries, and it didn't take me too long to figure out that one of them was the screen-less ZenFone2 (which made it much easier to make a near facsimile of it).

When I took a closer look somewhere with the device info, it said that it was last used 14 or 16 July, which is when I last tried to get the screen to work. I was happy that the motherboard was fine, but still upset that I can't get into it to get my stuff off of it.

Since my new ZenFone 2, I've been a lot more careful about handling it, along with trying out a couple other cases that I think (or thought) would offer better protection. I now keep some sort of positive contact (be it the fairly grippy sides or the screen and the case backing) when I remove/insert it from/into my bag.

My friend/co-worker told me that he had to root his ZenFone 2 to be able to write to the SD card, and that was one of the things I did when I got my new ZenFone 2. (I apologise for the lack of chronology.) I uninstalled all the bloatware and went to do the system update (after installing all the apps I had). Bad idea.

The ZenFone 2 took too long to get past the loading screen, so I turned it off, but when I tried to turn it back on again, the screen didn't come on at all. That is when I found that I did what I wasn't supposed to do. Eventually I found some restore images, including one for the latest update. Once I got the ZenFone 2 to turn on properly (two vibrates and not one, and without having anything plugged into the micro USB port... I think?), I was able to apply the image and proceed to set up my phone and reinstall my apps again.

The problem I've been having now is that I get an error every time I try to apply an OTA update... (Well, the first one actually worked, but nothing after that.) While I should've updated manually, I haven't had the patience to do it, especially considering the experience I've been having when straying from the Nexus line of phones.

One of the updates to ASUS's power saver app somehow changed my battery mode setting from "balanced" to "smart saving" without my knowledge or consent, which screwed up how my timer app worked - I use a timer app to know when to take lunch and when to clock out of work, otherwise I'd lose track of time and who knows how over I'd be.

It took a while to figure out that it was that along with the power saver app that really fucked things up. I even tried switching timer apps because I thought the app wasn't working.

I think it was a couple Fridays ago when my alarm didn't go off and I was woken my my dad about 10 minutes before I was supposed to leave the house. When I returned home, I found that something got screwed up and the alarm didn't fire off. Eventually I fixed it (not sure how), but I started becoming really aggravated with the ZenFone 2.

It was earlier this week when I had another OTA update (which failed, needless  to say), and I don't remember what else set me off, but I snapped this past Thursday night and pre-ordered the Nexus 5x.

While the ZenFone 2 is the best specifications for the price, and I do like the ASUS launcher a bit more than the stock (being able to hide bloatware or folder apps to get to apps not on the home screen(s) quicker), but the reliability is poor... Yes my base system's not up-to-date, but it should still be just as reliable.

Honestly, with how much money I've spent this year on phones, I should've just bought a Nexus 6 and dealt with its large size.

I was considering the Nexus 6p, and while I would like to go back to an AMOLED screen, I don't really need the specs and I don't want a "phablet" (I've already learned this too well with the ZenFone 2).

I wanted a somewhat high-spec phone originally because of the app-crashing issues that I had with the Galaxy Nexus, but considering I'm using Ting as my cellular provider (pay-per-use), I've learned to use my phone less and less. The only thing I'd need performance for is to be able to play some graphics-heavy games - that is, when I actually do play them.

When I get my Nexus 5x, I'll be backing up my ZenFone 2 on Melty before doing anything else. I'll also swap the motherboard from the screen-less ZenFone 2 to the newer one and praying I can get what I need off of it.


Before the two ZenFone 2 phones (I'm really getting sick of typing "ZenFone 2"), I only had the Nexus One and Galaxy Nexus, so I've always had the base-line Android experience. To a point it feels a bit foolish of me to stray from it, while chasing something I didn't need at all. (At this point I also remember that I wanted something that was x64 compatible for some slight future-proofing, though it was mainly ARM64 that I was looking for.) I think I've learned my lesson after spending how much I've spent across three smartphones (two and a half?).

Things I've learned:

• Don't get blind-sided by price-performance ratio
• It's better to stick with what works sometimes, as pricey as it may be
• Handle large phones cautiously

Updates / Pi2 / Dell / Lie-chan / Mei-chan

I first will apologise for not posting in almost two months; it's been a bit rough on me when the screen on my first ZenFone 2 cracked and I tried to replace it myself without backing the data up first - I "lost" quite a number of project pictures.

About a month afterwards, I bought another one because I wasn't able to stand the Galaxy Nexus, and I've been fine with it ever since (just handling very gingerly), but it still irks me that I have numerous pictures I'm unable to access.

Besides the loss of motivation to update because of that, I've just been somewhat busy with work and sometimes coming home fairly exhausted.

Today was a bit different though, because I had planned on working with the Pi2 a bit, because Raspbian Jessie was released. I also wanted to try Tumbleweed again, because I couldn't remember if I tried using YaST2's software management to install XFCE, which didn't turn out.

After initial testing, everything seemed a bit nicer, so I pulled off some files (mainly just vsftpd.conf) and overwrote whatever Raspbian I originally had with the newer version.

I had gotten everything set up and changed the "pi" username, and started running into trouble when trying to get it to boot into XFCE with auto-login.

I tried quite a number of things, and the closest I got left me with a "file/directory does not exist" error (because /home/pi was no longer there). While I tried to look for a fix, I gave up and went with my original thought of creating a symbolic link, which worked (though not the best fix).

I'm done with the Pi2 for now, but I really hope I can migrate to a true rolling release distro at some point.

I ordered the Pentium D 945 a few days ago and got it yesterday. I put it into the Dell after finishing with the Pi2 and immediately noticed a difference in speed during POST; it also was evident that the CPU was no longer the bottleneck for 64-bit. I ordered 4 x 1 GB of RAM last week, which will be here sometime next couple weeks or something. Altogether, about $30 USD to max the Dell out, which isn't bad at all. Hopefully I remember to update the machine reference page after writing here.

Last week (or maybe earlier this week?) I decided to tinker around with Lie-chan, since she's not really being used right now and I had found a way to possibly get the Sound Blaster Audigy SE card working in Manjaro. I don't remember too much of the specifics, but it involved setting the default card by hand, which made the sound work pretty much perfectly with VLC, but not G(something) music player. I then found that I had to make a configuration file to copy the sound from the front speakers to the rear speakers and to the subwoofer, and luckily, the post also explained how it worked, so I copied the sound from the front speakers to the centre (just like the subwoofer) because the centre's tweeters are better than any of the other speakers.

I'm quite happy with the results, since I don't have to have GNOME 3 and XFCE in Tumbleweed and mess around with the YaST2 sound setting to get the card to read properly or whatever it was.

With Mei-chan, I finally got her the pair of blu-ray burners, did the massive near-300 data-disk DVD copy-job, cleaned up the files/folders, and got the burning projects lined up and saved in K3b.

What I had forgotten was another large project (about 44GB) that was on Melty, which I transferred this past Thursday after work, burning the first blu-ray before going to bed (which wasn't the best idea).

Yesterday after work, I burned the second disk of that project and got an I/O error, which made me suspicious (though I should've been when the first disk technically erred out but was still readable except for the last file). I then found that I was supposed to use cdrecord and not cdrkit, but because the article/post was somewhat old, cdrecord is no longer its own package - it's now included with cdrtools.

After burning the first disk again, it finished and verified with no problems (albeit faster as well), which made me wonder why cdrkit hasn't been depreciated if it can't handle blu-rays.

I've got other projects that I have pictures for, but I probably won't be getting around to that until I get my Nexus 5x. (More on this in the next post.)

An upcoming project is to get the Banpi to Tumbleweed - I know I'll only have cli, but since I haven't a need for a graphical manager, I should be fine (it's only a matter of figuring out how to configure transmission-cli). With that, I'll be able to do a headless system and save myself the bluez headache (along with removing the bluetooth adapter).


Things I've learned:

• cdrkit is junk for blu-ray burning.
• I can configure the sound card to work properly in Manjaro.
• Try the simpler way to fix a problem before the more complicated ways.

Manjaro Part 3 / openSUSE Tumbleweed Part 5

On Friday (31 July), GNOME began glitching out on Triela, so I just dealt with it until Saturday morning, which I reinstalled Manjaro with XFCE instead (I couldn't find a good GNOME-to-XFCE guide at all). It only took about 3-4 hours to get it all back to the way I had it before (mind you that building from AUR depends on the package, and atom-editor usually takes a while to build).

I mentioned in a previous post that I installed Manjaro on Lie-chan and that the sound card didn't work right. I updated Manjaro and nothing changed.

I tinkered a lot and while the on-board sound worked fine, the front speakers were dead (I had killed the front channel with ESD via headphones a long time ago) with the only work around being to plug the front speakers into the side channel and set up for 7.1 sound, which would just make things screwy when trying to watch something that has 5.1 audio.

I did as much as I could until I decided to just go back to openSUSE, opting for Tumbleweed. After installation, I tried to install XFCE and switch over to it, but couldn't get it to work. I then (using init 3) uninstalled GNOME and rebooted to the xdm login screen. I logged in without any real regards to it and was able to get into XFCE just fine.

I eventually looked around to figure out how to set up automatic login, but was unable to, then noticing that xdm was installed and not lightdm (which is usually default for XFCE), so I (again, via init 3) uninstalled xdm and installed lightdm instead - ending up at command line.

I decided to download the net install and just reinstall Tumbleweed again with XFCE to make things much easier, and since the net install ISO wasn't very large, I was able to install once it was downloaded and burned.

It did have to download about two gigabytes of data (even opting out of LibreOffice to save time, and also forgetting that Tumbleweed only has "Fresh" and not "Still"), and it kinda sucked to sit through it while I was somewhat exasperated and tired from working on Lie-chan from about 10:00 (this was this past Saturday, the 1st); it was probably around 20:00 when I was waiting on the install.

After installation, I dug around for the 13.2 multimedia and codec guide thingy by caf4926, eventually having to "activate" my SUSE account to get into the forums to look at the 13.1 guide. I don't remember How I got to the 13.2 version, but I copied the packages for later reference (if/when needed), so I wouldn't have to deal with the crap again.

Once it was pretty much ready, I went to bed and continued with it when I was able to the next day.

Since XFCE settings differ a lot from GNOME's, there wasn't really any way to adjust the sound card besides YAST, which made things weird once I got the card configured properly in YAST (opting for "advanced" config instead of "quick" or "normal"). Eventually I found that I just choose the proper output in VLC before figuring to select the proper output in VLC's settings.

By this time, I'm somewhat tired after messing around with it all, and since it was about thirty Celsius in the room, I just turned Lie-chan off, not wanting to forego watching what I was originally wanting to watch early Saturday morning.

So what was supposed to be a quick update (probably about thirty minutes to an hour), turned out to be a sixteen-hour, semi-gruelling process of tinkering/installing/updating/configuring.

Lie-chan will be one of few Tumbleweed installations (the Pi2 will have Tumbleweed once tested, and Banpi will be tough because the GPU isn't supported by the kernel), as almost everything else will be Manjaro.

FreeFileSync decided to go with MegaUpload (or similar host) instead of SourceForge and FOSSHub, so the AUR entry for it is broken and I'm not able to compile it at all. I'll eventually see what happens, as I'm not using it right now and I have other ways of syncing (though it's a more time-consuming way).

For those wondering, yes I did write the first paragraph later, and that was because I remembered it after finishing about Lie-chan. I didn't feel like fixing the rest of the post to make up for it, so deal with it. (XD)

So I won't be saying goodbye to openSUSE at all, but I definitely won't be using any more versions (11.3 to 13.2 is a fairly decent run, I'd say).

openSUSE Leap 42.1 Milestone 1

Installation took about half an hour, and after rebooting into it (save for the in-between GRUB update step in Manjaro), I opened up terminal and looked for updates, to which there was none.

I then searched for VLC and also found nothing, double checking with a search of "h264", which obviously yielded nothing.

To summarise: it is much too early for me to test Leap. In other words, I should wait until it's out before an actual test.

I can't really say much else, just because there isn't really anything to talk about with Leap - GNOME 3.16.x is GNOME. I am literally throwing my hands into the air because I have nothing (XD).

I think it'll be mature around November, so I'll wait a few months before I test it again (hopefully I remember on my own).

openSUSE Tumbleweed Part 4 / openSUSE Leap 42.1 Milestone 1 / Manjaro Part 2.75

I'll apologise ahead of time for bouncing between Tumblweed, Leap, and Manjaro; I'll try to make it evident which I am talking about.

So far I've installed and updated Tumbleweed and at the moment I'm waiting for the other packages to install (VLC, K3B, etc).

It does seem like I would have gone with Tumbleweed had I thought about it, but since I haven't been able to preform any real testing, I can't say anything for sure right now.

Also, while I was browsing around yesterday, I saw the upcoming release of openSUSE is called "Leap" which will have the SUSE Linux Enterprises (SEL) at its core and allow security updates directly from them. In other words, I have another version of openSUSE to test out once it's downloaded and I've finished my testing for Tumbleweed.

Oh, one thing I forgot to mention with the first Manjaro Linux post is that I figured out what the weird "fourth" button (the one second from the left) on the volume/user/etc menu is. It's meant for devices with accelerometers, in other words, it's to allow/lock screen orientation. I figured this out when I updated from GNOME 3.14.x to 3.16.2, as the circular arrow was replaced with a tilted rectangle with a curved arrow, and when I clicked on it, the arrow became a padlock. Mystery solved.

Back to Tumbleweed, I just tried a video file in VLC and it gave me the error message that it could not decode h264; I looked in zypper and found there weren't any h264 codecs at all. Looks like I'm going to have to add the repository from Packman and test again.

When I booted into Manjaro, I saw that I had GNOME 3.16.2 and not 3.16.3 that I updated to on Melty, which gave me problems. As much as I wanted to update it and test to see if it broke on Triela, the Tumbleweed testing came first (kinda hard to update GRUB if the target system isn't usable. Sure I could use mhwd-chroot and do it, but that requires booting into a live version of Manjaro to do - so why take the risk if it will just complicate things?

Tried VLC again in Tumbleweed with the same message, but this time, h264enc was in the repository. Oh how long it's been since I've had to do this sort of thing... I should pull up caf's guide, but at the same time, I don't really want to. Luckily, it worked without any problems.

Decided to try an mp3 and I'm glad I did, as supposedly the plugin wasn't installed, though zypper tells me something different, I decided to install gstreamer-0_10-plugins-fluendo_mp3, but it didn't seem to help, so I tried removing pullin-fluendo-mp3 which also didn't work. I then noticed that gstreamer-0_10-plugins-fluendo_mp3 replaced gstreamer-0_1-fluendo_mp3, so i reinstalled gstreamer-0_1-fluendo_mp3, but that also didn't work.

I decided to used caf4926's guide (from 12.3, but it's not like the packages are any different), and after getting it all installed, I was able to get mp3 playback.

So yes, Tumbleweed is quite viable, but as I mentioned twice before now, I'd rather yaourt than have to go through the trouble doing it "manually" (plus, I'd probably have to put some extra effort into FreeFileSync, since it's meant for 13.2 atm). So with this, I conclude Tumbleweed's test, and now I move onto updating Manjaro.

---

It took a bit longer than I wanted for Manjaro to update, but I was able to reboot back into it without any problems. What's weird is that the screen orientation button has reverted to the circular arrow... Since I know what it is, it won't bother me any.

I suppose I'll stick with GNOME on Triela for now, since I don't feel like going through all the hassle to reinstall/reconfigure Manjaro... I might be able to install XFCE and remove GNOME (I found instructions for going from XFCE to GNOME on Manjaro's wiki), but I think a reinstall would be less of a headache to be honest.

Tomorrow I will test openSUSE Leap 42.1 Milestone 1, since I'm still waiting on the download.

openSUSE Tumbleweed Part 3.5 / Manjaro Linux Part 2.5

With my Manjaro Linux post, I got a comment on Google+ (because I have blogger set up to post the blog entry to G+ once it's posted) asking why I didn't try openSUSE Tumbleweed. I explained to him breifly of the issues I had before and told him that I will give Tumblweeed another try since it's been quite a few months when I last tried it.

At this moment I already have downloaded and burned the Live GNOME Tumbleweed (x86_64) to a DVD+RW and plan on doing a test install on Triela's testbed partition tomorrow after work.

I'm thinking that the VLC codecs are going to be a problem again, but it is part of my test procedures, so we will see what happens.

If the test's successful, will I move to Tumbleweed from Manjaro? As much as I would like to, I'll probably be sticking with Manjaro because of the Arch Linux User Repository (AUR), which allows me to build FreeFileSync, Skype, and Atom (text editor) from source. With Tumbleweed (and even openSUSE), they would be .rpm files I'd have to download and "install" - with the exception of FreeFileSync, as it's able to run on it's own without installation.

So even though I'm quite set on Manjaro, I will keep my word and try Tumbleweed out.

---

One thing that I forgot to mention with my previous post is that I've gotten quite used to pacman and yaourt in terminal, confirming my theory that learning pacman would be fairly easy to learn since it's similar to zypper (yaourt works the same as pacman, but it's for building packages from the AUR).

Manjaro Linux Part 2

Last night I decided to forego the installation of Manjaro onto Melty, which went well until I rebooted after getting the updates. I reinstalled 3 more times after that, doing different things to try to figure out the problem, which was most likely GNOME 3.16.x. Being tired from spending approximately seven hours with it, I grabbed the Manjaro XFCE disk before getting some sleep.

This morning, I stuffed the ISO onto my Linux stick, but somehow the kernel was missing, even after trying writing the ISO again along with trying it on the Dell. I ended up just booting into Windows and using Unetbootin to write it to another flash drive, which tested well on the Dell (GRUB was just a bit strange with "Default" as the first option which didn't seem to do anything).

Installation went just fine, but that obviously wasn't the issue, and while I let it update, I kept system configurations to a minimum, so that if it did break, I wouldn't have lost too much time.

As the screen went from the Manjaro splash screen (which is similar to Ubuntu's, but with green dots instead of orange ones) to XFCE desktop, I held my breath a bit as I hoped that it would be fine, but expecting it to break at the same time. Fortunately, nothing happened and I was greeted by the desktop and panel.

I began installing other programs and getting the settings configured, and tried the XFCE theme I usually use for Pi2, Taiga, and Sae-chan, which made me very slightly cringe as it was a light theme. When I was able to, I began looking for the authors of the theme to see if they had anything dark, and I was able to come across it somehow (I was between DeviantArt, Google, and xfce-look.org).

I first grabbed Ambiance Blackout Flat since it was what I was looking for and RAVEfinity was definitely reliable, since they made the pink Radiance theme that I use for Pi2, Taiga, and Sae-chan. I then grabbed Vivacious Colors and Vibrancy Colors GTK icon themes, seeing that I wanted something else besides the "M(something)-circle" icon theme that was default upon installation - it's an interesting set, but I wanted something that was a bit easier to see against a dark theme (though the default theme was dark anyway).

I really liked the application icons of Vivacious, but liked the folder colours of Vibrancy, so I decided to hack the two together and it worked out okay.... Until I cleaned up the lot of extra themes, which ended up breaking the icon theme without my knowledge. After "finishing" with that, I decided to look at Ambiance & Radiance Flat, since it was essentially an "updated" version of the Radiance theme (I like flat themes, and I don't know why). I took a quick look with Melty and didn't really notice much different, but got everything packed away and uploaded to the Pi2 and the NAS before downloading it to Sae-chan to install it.

It was when I watched the scrollbar flatten that I noticed the difference, and when I looked at the icon theme change, the folders worked, but not the application icons. I then looked on Melty and noticed that the application icons weren't like I remember them. While trying to figure out what went wrong, I found that Vivacious actually did have extra folder colours, but as an add-on pack, so I downloaded it and gave it a test, which didn't make any difference to the icon theme I hacked together (this is technically a good thing), but the application icons were still not there.

It took quite some time, but I found a note in small print on the Vivacious Colors page:

(!) Folder Color Add-on Requires Main Theme to work!

Oh. That explains why the application icons disappeared. I downloaded the main theme again and extracted the "Vibrancy-Colors" folder to where I needed them (in the light/dark XFCE themes I was building and on Melty, so that the theme wasn't broken any longer), double checked the theme, and repackaged the themes yet again.

Unfortunately, it didn't make any difference on Sae-chan, so I just let it be and shut her down, but at the least, I was finally done with the theme.

I finished the rest of the setup, which was just my usual bout with commonly-used applications and their settings.

As to why I haven't a problem with GNOME 3.16.x on Triela but on Melty, I haven't a clue, but I don't mind XFCE at all, since I've already been using it for quite some time. I'm thinking that Lie-chan won't have any problems either, but it's too early to say as I haven't taken the time to update her yet.

Will I be switching from GNOME 3 to XFCE entirely? I can't say, but I think the window managers I used will more than likely be splintered if I don't go with one or the other... Now that I think about it though, I might go with XFCE because the theming is a lot simpler than GNOME (the theme I use for GNOME is a tad bit broken and the XFCE theme is solid, not to mention the "Smallscreen" window border is much thinner than the one I hacked together).

Things I've learned:

• A good testing involves updating all the packages before drawing conclusions on usability
• Keep configurations to a bare minimum during a full testing phase
• Look for and read the fine print on themes
• I like RAVEfinity a lot more than I thought I did? (XD)

Manjaro Linux

Recently I've gotten fed up with having to test/install new versions of openSUSE (and/or debian), and decided to take a look at true rolling releases, but unfortunately it came down to Arch and Gentoo. Since I had a bit of experience with Gentoo, I wanted to avoid it, as nice as it would've been for the machine to run a kernel compiled for it, and so I ended up taking a look at Arch Linux. Unfortunately, Arch Linux isn't much different, and while I wouldn't mind going through all the steps, I also had to think about how many machines I would need to install on (about 6-8), and while the time it takes to install on each machine differs, it's a lot of man-hours I'm not willing to put in while I'm working full-time.

Eventually I looked around, and on a forum, someone else asked a similar question (they were looking for something Arch-like, but simpler), and I ended up checking out one of the two suggestions, which was Bridge Linux. Bridge Linux broke itself on the test hard drive after installing, so it was quickly ditched and so I checked out the other suggestion of Manjaro Linux.

Manjaro was a bit wonky when I tried to put it on a USB drive, so I ended up just writing it onto a DVD+RW instead. The initial test worked well, though during installation on the test drive, the screen turned off and locked, and something glitched out, which resulted in a broken picture. Luckily I was able to reboot and get into the system, but sometimes I'd get the "No operating system" message from BIOS, which was fixed by recycling the power (I think that drive has a faulty MBR or something, would explain why my friend had problems with it).

On the test partition of Triela's actual drive, I decided to not install GRUB2 from Majaro, seeing as that I didn't want to change the options from Manjaro if I were to ditch it, but I wasn't able to boot into Manjaro, so I had to do it anyway (without reinstalling Manjaro).

There were a lot of surprises with Manjaro, one being that I am able to use the user repository for Arch Linux (Arch User Repository or AUR for short), which allowed me to build and install Skype, FreeFileSync, and Atom (text editor) from the package manager. Another surprise was that I wasn't able to find the proper config file for the NTP hosts that Manjaro uses to update the time, so I'm not able to add a custom server (at least for the moment). I was surprised that I had used pacman before (probably for Sabayon), and after looking at the help, it seems that it's quite similar to zypper in simplicity, so it shouldn't be too hard to learn (compared with apt-get for Debian which becomes apt-cache for when you want to search for something...). A very nice surprise was that Manjaro doesn't make Triela idle hot like openSUSE does.

I tested Rhythmbox out and found that the random-crashing problem still exists, though (if I remember correctly) I don't think it had to do with cairo this time, so I decided to stick with Clementine as I have been.

After completing all the necessary tests on the test partition, I backed up all the files I needed to back up in the home folder of openSUSE before I went through with the install of Manjaro.

So far the only issue I've ran into with Manjaro on Triela is that Firefox would glitch GNOME out, but usually only for a second, but I found that it was just kernel 4.1.2-x that was causing the problem and just downgraded to 4.0.x instead.

For Lie-chan, I found that (for whatever reason) GRUB2 from Manjaro and the GPT partitioning table don't play along nicely (I wasn't able to boot into Manjaro at all), and so I had to change the partition table back to MBR (losing the copy of my music library in the process) and reinstall. So far, Lie-chan only has an initial installation (with the keyring being the only upgrade I think) and I haven't been able to test out VLC on her like I normally do (the video file I use for testing also got wiped), but I'll eventually get around to getting her up to date and fully tested. So far the only issue with Manjaro on Lie-chan is with the Sound Blaster sound card, but it might just be the fact that I haven't updated yet - we shall see.

I definitely will migrate my x64 computers (and maybe Ziggy though he's x86) eventually, but it'll be a slow processes.

As far as the 2(DrivePi) and Sae-chan goes, I'll probably sit through the Arch Linux installation with each of them, since I probably don't have much of alternative for them.

I may still test openSUSE from this point forward, but by no means will I have an installation of it that I will frequently use. As I make the transition to Manjaro, I will (figuratively) say my farewells to openSUSE. openSUSE has been good to me over these past 5-6 years, but it's time I move onto a true rolling distribution, so I'm not installing the new version of openSUSE every release cycle.

Fun fact: the distributions I've stuck with for a good amount of time all have a green theme to it (Linux Mint, openSUSE, and now Manjaro)... Maybe something trying to tell me something. (XD)

Website Adertisments Part 2

About a couple weeks ago, I wrote about blocking website advertisements, and about a week ago, I came across another article on it (Why Adblocking is the New Speeding).

I only wanted to revisit this because the author makes a very valid point:

.... Like pretty much everyone else on the outside three lanes of the four-lane motorway, I was over the speed limit.
And what happened? Nothing. I carried on going above the speed limit. Many of us that day were breaking the law. And nothing exceptional happened. No police stopped us. We broke the social compact – the one about obeying most laws – without compunction. None of the people on that motorway that day had an accident there, so is speeding harmless?
It’s also a fact that around one-third of car accidents can be ascribed to excessive speed. Going too fast is highly correlated with accidents.
Yet we ignore it. And we speed. ....

  Just like speeding, people that block ads are going to continue to block ads because there isn't really much immediate consequence to do so.

Similarly, there’s no retribution for adblocking. Nothing happens when you do it, except you get a better experience. Ditto for speeding: you get where you’re going sooner.

The only thing I disagree with this statement is that for speeding, you do get where you're going sooner (results differ a bit depending on distance if you're doing it on the highway or in the city), but the main consequence is that your gas mileage becomes worse above a certain speed (supposedly it's above 55mph, but I think it depends on other things, really). But it is what you intentionally give up to get where you want to sooner.

That was all that I wanted to revisit this topic for.

Cherry MX Ghetto Super Green Keyboard Modification.

Friday, I received the Cherry MX Blue and Cherry MX Gray switches that I ordered to make some Cherry MX Ghetto Greens (a proper Ghetto Green with 80cN force instead of 60cN) to make it harder to accidentally press certain keys (caps lock, scroll lock, num lock, insert, right shift, right click menu) across the two mechanical keyboards that I have (Logitech G710+ and Cherry MX-Board 3.0).

I found that it was quite easy to swap the parts around, but then found that the actuation force didn't seem to be enough for me when I tested the switch between my fingers. I was a bit unhappy with the results before I realised that I could double-up on the springs to get a stiffer response (at the cost of increasing the compressed length). I first tried the blue and the grey springs together, but it didn't work well because the blue springs had more wraps than the grey ones. Obviously, I tried two grey springs and it worked decently well (I think I had to play with it a bit), besides that it was quite stiff (160cN).

I then ran into another problem, I had only ordered 25 switches of each type and I was needing to modify 16 switches total; I was about to get back onto Allied Electronics's site before I realised I could drop 5 switches total. Originally I had planned to modify the super keys (aka Windows key), but since both keyboards have a way to disable the keys, it was an easy way to drop the switch count. I also decided against modifying the right click menu key on the Logitech G710+ keyboard, since the button that disables the super keys also disables that key as well (obviously not the same case for the Cherry keyboard). I then put together the ghetto super green switches together (11 of them total) and set them aside until I was actually able to work on it.

I began working on switching the switches this morning, opening up the G710+ first, as I remembered having difficulty opening it when I was checking it out a couple months after I first bought it. Fortunately, it disassembled quite easily, and I was able to remove the cable for the volume roller, since it's something I never use. The entire time from Friday, I was a bit worried about de-soldering the switches, but remembered that the LED is separate and the tough part would be the switch itself.

At first, I tried to heat up both switch legs simultaneously and also hold onto the plate retention latches to pull the switch away from the plate - needless to say it was a bad idea and didn't work at all. I then decided to try the de-soldering braid on it, and it worked very well to my surprise; I replaced one switch at a time for two switches before doing a step at a time for the remaining three.

The Cherry keyboard was much easier to disassemble, since the keyboard has a detachable cord. It also uses (zener) diodes, but since I was just using the de-soldering braid, it didn't slow me down any. The only trouble I ran into when making the modifications was that the top housing piece of the switches with the LED (the three locks) has a sort of "extension" (presumably to help guide the legs of the LED), and it wasn't compatible with the switch with the diode in it - this was quickly remedied by pulling out the switches with the LED (which hadn't been soldered in at the time) and removing the top housing piece to find the correct one (luckily on the first try).

Since the MX switches I ordered were for PCB mounting (and not plate mounting), the bottom of the housing has a couple extra pegs, which I could have cut off, but I went for just putting the spring and stem into the switch I pulled from the keyboards.

It is very extremely obvious if I'm trying to hit the key by accident, as the force I use to activate keys isn't too much (I'm going to estimate about 45cN, since that's the force required for brown and red keys). I'm quite pleased with the modification, as I won't have to worry about hitting those keys by accident and causing some sort of undesired operation.

Before I begin showing pictures, I'll go into a bit of depth about why I disabled each key.

• Caps Lock: I disable this because I very rarely use it. When I used to use Logitech's Illuminated Keyboard (K740, Y-UY95), Set Point allowed me to disable the Caps Lock key, which was very nice, but when I got the 710+, I wasn't able to do this with Set Point or the Gaming Software).
• Scroll Lock: I don't think I hit this by accident very often, but it is next to the print screen key, which I use on occasion. It's also a key that's hardly used any more, so why not?
• Num Lock: I normally keep it on, as I do use the 10-key for numeric entries, but sometimes when I try to hit slash (/), I'll accidentally hit num lock instead and screw up whatever I was trying to enter. The other reason is that it's the auto-run hotkey in Mabinogi and Mabinogi is programmed with the caps/num lock keys as toggles ("off" when Mabinogi's started, "on" when it is pressed outside of the chat box) instead of just reading the state of the keys (which would have been much smarter in my opinion).
• Insert: I strongly dislike this key when I'm... Rather I should say that overstrike text entry is highly annoying when trying to type things up, especially when it goes unnoticed for a while. That said, it's accidentally hit when I'm trying to use the delete key that's underneath it
• Right Shift: When I learned to type, I never made a habit of using the right shift key for the three left pinky keys (Q, A, and Z) and instead adapted by rotating my hand at the wrist so that my ring finger would hit those three keys while my pinky holds down the left shift.
• Right Click Menu: I'm not sure what this key's supposed to be called, but it's (usually) the one to the left of the right control key. I haven't hit this on accident from what I remember, but it's a key that I've only used a few times in my life, so might as well just modify it anyway.

Cherry MX Blue and Cherry MX Grey, comparison of the plate-mounted bottom housing and PCB-mounted bottom housings, comparison of the brown stem and spring with the blue stem and doubled grey springs.

Doubled spring sitting in the housing, blue stem sitting on the spring, completed plate-mounted ghetto super green.

Fully mounted and soldered.

One other modification I did before this was get some o-rings to change the travel distance of the keycaps, putting two of them on each key (for most of them) so that it would stop the key from travelling further than the necessary actuation distance. Unfortunately, I had to remove one of the rings from certain keys because either I don't use enough force to press the key down for those specific keys, or the total ring thickness is just slightly more than the actuation distance.

If you want to modify your mechanical keyboard, go for it (as long as you have a puck of 1mm de-soldering braid) because it's actually a lot easier than it seems.

---

I redid the springs, read about it in this post.

LED Tester (Version 3)

I took two outdated boards from work (the newer version of the board has solder pads for an added SOT-23 diode) to make one of them into a LED Tester. For quite some time, I was using was an old project box from Radio Shack, one of the 8-pin IC holders and a 2-AA battery holder to test LEDS.

Part of the reason why I didn't like it was that it required batteries, another part was that it's a lot bulkier than it needed to be, and the last is that the IC holder is meant to be put through a perfboard and not a plastic box.

The newer version of the board was being used for the prototype of a different project, but the electrical engineer decided to add some more parts to it to reduce the load of the voltage regulator on the main board. When he received the prototype boards, I was to remove the board from the main board and toss it into the electrical waste bin.

With a fully-functioning LM317 on the board, there was no way I could do that, so I (painstakingly) de-soldered the voltage regulator and one of the 8-pin headers from it before storing the board elsewhere if i needed the other parts from it.

One of the two outdated boards I took home already had parts on it (I didn't realize it was an outdated board until I noticed the missing diode (how I missed it when I was putting the SMD parts on, I haven't a clue) and brought it to the attention of the electrical engineer, who told me it was the older revision of the board (the board that superseded it has ".B" marked with the part number). I had left it alone, since I didn't want to just toss it in with the electrical waste, so I held onto it until I needed it.

The board is the board that sits between the main board and LCD panel (that is made by some other company that we purchase), and was going to be much easier to use than the old prototype board that I used for the adjustable voltage regulator project because of the "built-in" spot for the LM317.

The first thing I had to figure out was what voltage to output so that an LED with a 3.3 volt forward voltage and an LED with a 1.6 volt forward voltage can agree on. With the adjustable voltage regulator, I toyed with it a bit before doing some maths to find that 2.5 volts should be a decent median for both types.

The initial test was fine, and I found it quite nice that it was the exact same resistor value needed for 2.5 volts (Vout=1.25 * x/x), so whatever I was able to find (between 100 and 1k ohms) for the power LEDs would work just fine.

The board has three spots for LEDs, one for power, one for use indication, and one for reversed power. For my case, I only needed two of the three LEDs, but I figured I might as well use all three; I set up the central LED to be the power and the outer LEDs to be a reversed power indicator (so that it's quite obvious if the LED testing board is plugged in "backwards".

With some calculations, I figured I'd need a resistance of about 500 ohms for each of the power indicator LEDs (since I'm running it off of 12 volts), so my best bet would be to either find a resistor close to 500 or to put two 1k ohm resistors in parallel (which is theoretically easy with SMD). When I dug around at the unused parts during lunch, I found the 1k ohm resistors and held onto them as I dug around more. I then found a 700-something ohm resistor reel (remember, this are SMD resistors) before finding 600-something ohms, but then I was quite elated when I found 475 ohm resistors and proceeded to put the other two reels away.

On the board, the two outer LEDs use SMD resistors with a 1206 case code and the centre one uses 0805, which was something I was partially looking for, but because I was able to use the 0805 sized resistors in the 1206 slot, I didn't have a need for the 1k ohm resistors that I brought home with the 475 ohm resistors.

I soldered most of the components onto the board and soldered the LM317 on the "wrong side" (but in the correct pin order) to make the bottom as minimalistic as possible. The next day I thought of adding some diodes to protect the circuit and LEDs so that when the board is hooked up incorrectly, the voltage regulator circuit is protected, and when the board is hooked up correctly, the reversed polarity LEDs are protected. After getting home, I added the diodes in and hooked up the jumper wire to make it work and it did indeed work.

Except for one little problem: the LM317 became really hot even though the output voltage was correct. When I soldered the LM317, I soldered it so that the plastic side was against the board and the tab was in the air, and so I though maybe I needed to actually solder it to the correct side so that the pad on the underside of the board can absorb the heat. I moved the LM317 to its correct position on the board, but nothing changed, it was still getting hot.

I poked with the adjustable voltage regulator project and the tab didn't get hot at all - not even slightly warm - and so I decided to think for a bit. I decided to double check the power path and found that I had not added the jumper wire that connected the ground to the actual ground pin, and after remedying the problem, all was well.

I forgot to mention that I put some header pins into the unused ports of the header to make it obvious which of the header holes to use. I also marked an arrow on the board pointing toward the positive hole, but since it is on the "outside" side of the header, it can't be seen in the following pictures.

Finished top and bottom.

Board has power and is plugged in correctly; board has power, but has power is reversed; board showing an LED being tested.

I forgot to cover the point of the device (and it's convoluted predecessor), which is to test if LEDs are working (which is probably fairly obvious) and to be able to discern the LED's colour (for clear or frosted LED cases). Before having a case that allowed me to organize my LEDs by colour (and case type), it used to be thrown together in a section of another case. This obviously made it horrible because I had to check the colour of the LED every time I needed one.

The first version of the preceding LED tester used a 9 volt battery, the project box, a resistor, and the IC holder - it did the job when I needed it. Eventually I changed it so that it ran off of a pair of AA batteries so that it would be easier to replace the batteries (whenever that would happen) and to reduce the voltage delivered to the LED being tested greatly. For the second version, I also added one of those plastic battery pull-tabs that come with some electronics with pre-installed batteries, so that the drain on the batteries would be further slowed down from air-based discharge (probably really unnecessary, but why not?)

While preparing an LED for the picture, I blew up a dual-coloured LED that was going to be used for my soldering light/fan switchbox, but luckily there were plenty spares at work, since it no longer being used.

The diodes I used are the 4007 (the one further away from the header) and the 5817 (one closest to the header) since that's all I had at home that would be easy to use.

The things I learned from this project is to check the paths before checking the parts, and to keep the LED in the tester for the minimum amount of time so that it doesn't blow up.

Google Standalone Clock App For Android

The article I read is: Google further embraces custom Android with standalone clock app.

I'm not sure if that is the article I first read a couple days ago, but I did also read the one I linked.

Recently Google's been releasing more of the apps that are built into Google's Android "ROMs" that are seen in the line of their Nexus phones.

The couple days before May ended this year, I recently got a 64GB ASUS Zenfone 2 (ZE551ML) to replace my Galaxy Nexus. I was greeted with apps that I thought were Google's, but were actually ASUS's version of them, and I promptly installed the Google version of the things I use most (Calender, Keep, Gmail).

This article piqued my interest, as I was curious to see what Google's released, and when I looked at the reviews in the Play Store, I saw that it was very simple, had an ability to dismiss alarms early and had the "material" design that launched with Lollipop.

I opened it up and it was definitely simple and basic. The background is a dark steel blue, the text is white and the buttons/sliders are (deep?) pink, it was much better than the black on white scheme of ASUS's clock that blinded me every morning when the alarm went off to get up for work. One of the reviews I read said it was a bad colour scheme, but from what I remember of Friday morning, it's still better than the black on white ASUS clock scheme.

The early dismissal is quite interesting, it is (probably) designed for when you wake up before the alarm goes off and want to dismiss the alarm since you're up - instead of the alternative options of either waiting for the alarm to go off to dismiss it (bad if you share a room/bed) or turning the alarm off (bad if you forget to turn it back on sometime after the time of the alarm has passed and before it's needed again).

While the article states that Google is giving Android users a choice, I think the other part of the reason behind Google doing this is because (if I remember correctly) Android M will be the last version of Android that Google will make their own phone - what better way to preserve the legacy of a clean version of Android than to release as many of the "stock" apps that's possible?

Before Google released their clock app, they released their camera app, and while I liked it better than ASUS's, I ended up installing "Open Camera" instead (I still use ASUS's from the lock screen when/if I need it).

Website Advertisments

There was an article I read a month or so ago where someone said that it's "immoral" to use an adblocker for sites you frequently visit, because it is those ads that generate money to keep that site up.

While I understand this, in my opinion I don't think it's immoral at all because it's really more on what you believe - if you believe it's immoral, then it's immoral, and if you don't, then it isn't.

Depending on the ad provider, the advertisements can vary greatly by type and target, and with marketing surveys (or marketing data) ad companies can refine what ads belong to whatever site is requesting ads for revenue. In other words, you'll have ads of baby-related products targeted for women on a maternity forum as an example. There are also the the search-based ads (e.g. text ads when you search something on Google), and the generic ads (that target the majority of people).

I'm not sure if he really understands the point of view from people who use adblockers to block ads. The look of the ad itself can vary from a static image to a flash video, along with deceptive ads that try to fool you by making you think you're navigating where you wanted to go but is (usually) a place so that your computer can get infected with malware.

My main point for blocking ads are four main things:

1. Ad placement
2. Animated/Video ads
3. Malware
4. Privacy

Ad placement can "break" the layout of a site and can be quite obtrusive in some cases. When I used to have my own website hosted with 0catch.com, I had no say in where the ads would be placed, so it ended up breaking my layout to where I had to spend (unnecessary) time tweaking the changed HTML to either remove or move the ad from the frame/page. The size of the ad is also part of this, since an ad that is placed well, but is obtrusively large is still obtrusive. Placement also plays a role, because a poorly placed ad can interfere with the usability of the site.

Animated and/or Video ads can be quite irritating. If you're trying to read an article (let's say) and there's a little ad banner off to the side (or worse, scrolling with the page) and it's constantly flashing and trying to pull your attention away from the article, isn't that at least a bit annoying? Animated ads in Android/iOS applications are probably the worst, as some of them may actually induce an epileptic response for those who are epileptic. While I haven't seen modern desktop-browser based animated ads, I'd like to avoid doing so.

Video ads take animated ads one step further and add sound into the mix (often along with an auto-play function). Let's take that same article reading scenario and toss the animated ad out and replace it with a video ad. I'm not sure about others, but I find it hard to read when listening to someone talk or some annoying sound is playing. Luckily, most of the time you can pause/stop the video ad (or just not have Flash installed, though it might still play with HTML5), but sometimes it doesn't allow you to.

Some ads are just there to confuse you and take you to sites that inject malware into your computer, usually claiming that your computer has some sort of performance issue. When I'm on a clean Linux installation (or live environment), I laugh at these types of ads that are directed towards installation of Windows ("Windows running slow?" is usually something I see), since it's too obvious when using Linux.

Privacy is a big issue that has recently popped up, but not too many people quite understand it well enough. Ads can store browser cookies and in turn allow the ad company to find out what sites you visit to be able to figure out your demographic and what sort of ads to put on sites that they have ads on that you visit. Blocking ads may not give you complete web privacy, but it's at least a start. For cases like this, you definitely want an addon/extension that protects you from ad cookies as well (Ghostery for example).

Besides all that, I do also block ads because they're just an eyesore... I am viewing the page for content, not so that marketers can come out and try to get me to purchase a product or service. It's the same reason I prefer to watch a movie or show on DVD/BD rather than on television, I don't want to watch ads for a total of about 10 minutes per 20 minutes of showtime.

All I'll say is to think about it for yourself and make a decision based on what you feel is right.

SourceForge

The article I read is: Why big open-source projects are fleeing SourceForge's free software hub.

For the past few years or so since I've been trying to migrate the programs I use to open-source (preferably also multi-platform), SourceForge has been one of the places I visit often (or have been directed to). I'm not sure when they began wrapping junkware into some of the software that they host, but I don't recall ever seeing it in any of the things I have downloaded from SourceForge.

I believe it was FreeFileSync that I was first introduced to FossHub, and I liked it better than downloading it from FossHub instead of SourceForge, as it was much easier to do, along with it being quite easy to grab the checksum to make sure the download is fine (via DownThemAll Firefox extension).

I don't remember when I was introduced to GitHub, but I do remember going there a few times to try to download something and ending up horribly confused (I think?). I don't want to say I don't like it, but I will say I really ought to spend some time so that I can become more familiar with it.

Back in the early 2000's, CNET used to be my main source of shareware/freeware, and I do occasionally end up there when searching for software. I'm not sure when they began to push their own download manager, but when I did download some things from CNET, I found that I had downloaded their download manager installer instead of whatever I was wanting. Though a "proprietary" download manager is fairly different from injecting junkware into open-source software installers, it's still the same sort of annoyance.

The only thing with FossHub I haven't figured out yet (as I haven't been on it too much, beside to update FreeFileSync) is where the older downloads are kept (if they are even kept) in the (very) rare occasion that I need an older version of a software for whatever reason.

I, obviously, will join this "boycott" because I believe that people should be able to download the software they want in an unadulterated form directly.

Adjustable Voltage Regulator

Originally, I wanted to make an adjustable voltage regulator with an LM317, 1k ohm potentiometer (variable resistor... same thing), and a 10k ohm potentiometer. Unfortunately, we didn't have any 1k ohm pots at work, but I had found some old 100 ohm pots - exactly nine of them. I thought it was great, since I can put them all in series with a 100 ohm resistor and be able to adjust the resistance between the adjustment leg and voltage out of the LM317. The 10k ohm pot I found was enough for the resistance between the adjustment leg LM317 and ground, since I don't really work with anything over 12 volts. I also used some old prototype boards to make it easier to assemble, but even with that it took some time to figure out and make certain that the paths were correct.

For the main board, I used some salvaged 0 ohm jumpers to make a couple jump to be able to use a couple of the through holes, but was quite pleased that I was able to fit everything that I needed to fit on it. And for the secondary board, it was nice taht I only had to use half of the salvaged board, as the hole placement allowed two pots to be fitted per section.

The finished "super" adjustable regulator.
Unfortunately, the actual size of the image is blurry and unfixable at this point.

It worked quite well and gave me good results, but then I found that all the 100 ohm pots weren't really doing much in terms of adjustment, so then I decided to remove the nine 100 ohm pots and make the necessary changes. Since eight of the pots were on the secondary board, I just de-soldered the jumper wires to/from the main board to save time.

The second version adjustable regulator.
You'll be able to read all the notes I've written on the board to make it easier for myself.

After testing it, it worked okay, but was a bit wonky when I turned the 10k pot down too far (since the 100 ohm resistor actually measured below 100 ohms). At this point, I decided to try one of the extra 470 ohm resistors I had in place of it, and it worked much better. Since the only thing that changed was the resistor, I didn't take a picture of it.

I slightly figured out that a larger resistor between the adjustment leg and output voltage legs made it easier to fine tune the voltage than with a smaller resistor, and once I was able to get hold of a 1k ohm resistor, I swapped the 470 ohm for it.

The finished adjustable regulator.

Once I tested it, I found that I was indeed correct, as it was even easier to fine tune the voltage. After using an LM317 voltage calculator I had found sometime before this project (so that I could understand how to use an LM317), I found that 1k and 10k were all I really needed, since it would (theoretically) give me 13.75 voltage output maximum (assuming I have an input of roughly 15 volts or greater). With a 12 volt source, I get an output range between 1.255 and 11.33 volts (according to the multimeter I have anyway).

About a day or two after putting the 1k ohm resistor in, I took a look at the equation for calculating the output voltage from the resistors used, and the resistor(s) between the adjustment and output voltage legs of the LM317 (aka R1) is the divisor, so it would make sense that using a larger resistance for "R1" would give a lower variance for the output voltage when the pot (R2) is changed.

Along with gaining a voltage regulator to make it much easier to test designs and whatnot (I was limited to using a AC/DC transformer with an output voltage close to whatever I needed it at), I learned that I should just use a 1k ohm resistor for "R1" if I'm going to be using a pot for "R2", because an adjustable R1 doesn't do much good.

I do want to also say thank you to the folks at the reuk site for making such a nice page for the LM317/LM338, as it was quite handy on several occasions along with being simple.

I don't remember when off the top of my head, but I plan on buying some LM350 to allow me to properly utilise my breadboard once I have an adjustable power supply. I'll probably be making a fixed voltage output for 9, 5, and 3.3 volts (the adjustable power supply will be outputting 12 volts), but I'll probably the last "channel" as an adjustable voltage (probably using the above project) for anything arbitrary.

Updates & PWM Circuit

I haven't been writing recently, but I have been working on the projects I mentioned in previous posts; the reason why I haven't actually written about the current projects is because I think it'd be more efficient to write about them once they're complete.

NTPi (aka TestPi) is nearly complete, but I just need a clear day to double check the offset

The Banana Pi & Raspberry Pi 2 box (dubbed as "2(DrivePi)" is mostly complete. If I haven't mentioned this, I kinda did now....

That's all I can remember for the moment, so if I did forget any aforementioned projects, it's not complete and still a work in progress.

---

One of the projects I have planned is a hold-open latch for the door of my entertainment room, which will be attached to a motorized pulley, so that I can press a button to lift the latch and let the spring hinge close the door.

My main problem with the motor is that the RPM is too high, and with the proposed latch being plastic (about 4mm thick), I'd have to hold the button for less than a second before the string is at it's shortest length (and could possibly break).

A couple days ago, I had though of using a PWM circuit to control the speed of the motor (the alternative is to reduce the voltage, which doesn't exactly help much), and I searched for one, finding a fairly simple one.

I first looked at an old IC that I used for a correspondence electronics course (I was trying to make a remote-controled "flashlight"), and found that it was the 555 timer IC that I needed for the PWM, which was nice. I then thought about the 100nF (.1uF) capacitors that I would need and remembered that I can reduce the capacitance of capacitors in a series - unfortunately though, it's impossible to make 100nF from values 1uF and over.

At work, I had found some stray 100nF SMT capacitors in 0603 and 0805 case codes and took them home with me to see if either would be large enough to use, and luckily, the 0805s were. I also grabbed an unused 10k variable resistor even though the schematic on the page uses 100k (I figured it wasn't going to be a big deal).

The schematic also called for 1N4148, which I was very lucky to find in the pile of salvaged diodes I have (I thought I had substituted for T4148, but it's the same thing).

After getting it built, I first tested the circuit with an LED to make sure the 555 IC wasn't dead, and luckily it wasn't, then changed the LED out for a 5.9V motor (I was using USB power, so I was under-volting it a bit) to check the actual PWM cycle. Needless to say, it worked and I could tell the PWM was working because of the screeching noise at the lower setting (anti-clockwise). While I could take it to work and test it on the oscilloscope, it's not really necessary, since I already confirmed that it works.

The board I used was the same RadioShack board from the previous 555 IC, and although it works, it's a cheap board (the pads come off with just the right circumstances. I also used some salvaged 0 ohm SMT resistors and some 24 AWG wire (from a Cat5e cable) to make the necessary jumps.

I'd like to make a good board for it, but from my experience with the PCB Artist program from Advanced Circuits, it still seems a bit daunting. I probably will eventually, since it'd be nice to have the capacitors on their own solder pads instead of between the solderpads on the underside of the board (not to mention I can just have traces running around the board instead of jumpers). Once I do though, I think OSH Park would be my best bet price-wise.

The PWM circuit page says that I can adjust the frequency by changing C1, but it'd be easier to just stick with the 100nF... Though I might play around with it later.

While the circuit itself is complete (in a usable state), the project that it's part of is not.

---

That's all for now, hopefully the weather will clear up enough soon so I can get the NTPi project up here.

New Theme!

Well, just a change of background and middle layer along with a bit of colour tweaking, nothing else otherwise.

Logitech MX Master & Logitech Product Rant

The article I read is: Logitech MX Master Wireless Mouse Unveiled.

I'll give a fair forewarning for this post will be quite long, as I'll be covering a lot.

It has an interesting design and style, and as much as I'd like to have one, I wouldn't need or have much use for it. While it does allow me to control 3 devices with it, the only place it'd see use is my bedroom - it would connect to the  Raspberry Pi 2 and Banana Pi via Bluetooth and then to Mei-chan via the Unifiying receiver. The problem is that it's a regular mouse, so I'd need some sort of space to move it around to control the cursor, and with the limited space, that's not exactly entirely possible. The other reason why I wouldn't want it for my bedroom is because I have already bought a Logitech M570 to replace the Cordless Optical TrackMan for Mei-chan. What I'm planning is that the Raspberry Pi 2 is going to use the Cordless Optical TrackMan and the Banana Pi will be using the V470 that's paired with Taiga at the moment (the Banana Pi will be taking over Taiga's duties). I may get it in the future, but that's about all I have left to say about it.

---

I own and have owned numerous Logitech products over the past 15 years, and I've never had any reason to switch to any other company. I'm not exactly sure when I began my brand loyalty to Logitech, but perhaps it was when the MX1000 was released.

The first Logitech mouse I owned was the Value Optical Mouse, which I eventually gave to a friend, because of my adaptation of the "first" generation of Logitech's Marble Mouse.

The third mouse would (probably) be the MX1000, as it was quite interesting to have something that used a laser instead of an LED light for surface tracking, but the battery eventually degraded to where it didn't hold a charge very well (perhaps it was a bad thing that I had it on the charger if I wasn't using it?). I eventually gave it to my best friend as a mouse for backup/test rig/something else.

Next would be the Mini Optical Mouse Plus for Sae-chan, which I used for quite a while until I didn't have Sae-chan for a couple years, and during that time, I gave the mouse to my best friend so that he can bundle it with a laptop he was selling.

After that came the white V470 for Shizuma, which I used for a while until it was replaced with the Performance Mouse MX (more on this mouse later).

I bought another V470 for the netbook, but in the blue colour, and this one went to my best friend again, until he retired and (possibly) sold it.

While I'm not sure exactly when I got the "third" generation of the Marble Mouse, I bought it to replace the "first" generation because of the button count increase. For those wondering, the "second" generation is the same as the "first", but with different colours, and the "fourth" is like the "third" with different colouring as well. Generation numbers are in quotes, as I can't say for sure if that's how Logitech released them.

I've also bought an M310 for something, but I don't recall what - though I do know that I gave it to my parents to use on the Intel build and the VAIO it replaced.

The Performance Mouse MX was very interesting to me because of it's ability to track on 4mm (and thicker) glass, and I bought it to use with Shizuma along with a N305 for numeric entry (the Unifying receiver is quite nice). I originally had a couple Bluetooth (non-Logitech) numeric pads, but the first one died after I accidentally spilled a bit of water on it, and the second one was just kinda cheap and annoying to use.

When I got Triela, I also got the Anywhere Mouse MX (first generation), since it uses the same Darkfield technology and my best friend had a glass desk at that time (though I only tested it on glass for fun and used it seriously on a mousepad).

When I got Sae-chan back (I think this was when I had the netbook) and "modded" her to have Bluetooth, I bought another white V470, since the other was paired with Shizuma.

For Lie-chan (when she became a Media PC), I bought the M505 because I wanted laser mouse that had Unifying (so I could pair it with the K360).

I also got the Cordless Optical TrackMan at some point, just not sure when (I think when Ziggy was my bedroom compy).

And the latest mouse would be the M570, which is still a bit weird to get used to, since it's a thumb-controlled trackball instead of the index finger-controlled trackball (using the middle finger in concurrency for more precise movement). The first week or two was the hardest, because my brain had been so hardwired to using the Marble Mouse and Cordless Optical TrackMan, so I had to slow down a bit to make my hand control the M570 correctly (instead of making clicks/scrolls when trying to move the cursor).

A total of thirteen Logitech mice, but that only concludes the list of mice. For keyboards, I own/have owned a total of 5. For speakers, I've own the X-540 and owned the X-530. For miscellany, the HD Pro Webcam C920 and the Harmony 650 Remote.

I'll more than likely continue to buy Logitech products when I need/want them, keeping myself from early adoption to avoid any possible issues that may arise (the G910 would be a good example).

Linux 4.0

The article I read is: Linux 4.0 brings Skynet closer to existence, offers reboot-free kernel patching.

While it probably won't be mainstream all that soon, I do look forward to reboot-free kernel upgrades, since it will make things a bit more convenient than it already is (considering that a Linux user can reboot/relog at their own convenience without a nag message).

The other thing that will be nice about 4.0 is the audio over HDMI with the open-source AMD Radeon driver; this will be quite nice for a media PC or HTPC, since it doesn't require the workaround. To make it work with 3.x, you would have to tweak a setting or two, but it can cause issues (I tried it once for the heck of it, but it was a long while ago, so I don't remember all that much of what happened).

As for the numerical numbering, it doesn't matter to me if it's 4.0 or 3.2 because it's just a numerical sequence after all.

Micro SD Card Adapter

I recently bought GeauxRobot Raspberry Pi Premium Low-profile MicroSD (TF) to SD Card Adapter and received it yesterday.

After writing Raspian to the 4GB micro SD card, I stuck it in the adaptor, stuck the adaptor into the Testpi, then plugged it in. Pi didn't boot and I cycled the power before using the stock adaptor, which worked.

I did a continuity test on the parts of the board that I was able to and found nothing conclusive. After the initial Raspbian setup, I decided to try again, with no new results. I then decide to pop the hood up enough, and eventually one of the solder joints for the hood broke, and enabled me to access the micro SD contact pins. At that point as well, I lost a piece for the click-lock retention/ejection, but I wasn't paying too much attention, since my focus was trying to diagnose the adaptor.

I'm not sure what I did, but I took it to my soldering iron to remove the hood by melting the solder of the other joint for the hood, and then ran another continuity test with the pins itself, which is when I found that one of the pins wasn't properly soldered - probably a bad reflow. I checked the rest of the pins (which turned out fine) before double checking the bad pin again. I took the adaptor back to my solder station and heated the joint a couple times to make sure the solder reflowed well enough.

I went back to my room to stick the micro SD card into it to find that the hood didn't want to stay on, and so I had to keep pressure on the hood as I did a quick boot test. Once confirmed, I took the micro SD card out of the adaptor and soldered the hood back on. Unfortunately, the initial tinkering of the hood (where it popped the solder joint) also shaved off the retention clips on that side of the micro SD card holder (thin metal, thin plastic, and some force does not mix well), and at that point I was at a loss of how to fix it.

After a minute or two of looking at the adaptor, I saw the weird solder joint that the hood makes contact with when a card isn't present (the joints aren't connected to anything), which could just be a stabilization or positioning thing, I don't know for sure. Anyway, I had saw the thing before and found it slightly weird when it didn't connect to it via continuity test, but I found that to be the only way to hold that corner of the hood down; I went back out to the soldering iron to solder the hood to the solder joint. I accidentally soldered the contact arm along with it, but the micro SD card fits and reads just fine, so I left it.

It was nice that I was able to fix a "dead" unit, since it's a very simple design - with nothing more than contact points and some PCB traces - and I didn't want to try a different brand (along with the fact that I was unable to return it once I opened the hood). It also saved me the disappointment of a DOA product looming around until I forgot about it.

It was definitely one of the more interesting turnouts for a potentially bad product.

Sound Card Switchbox Version 2

After finding a nice, new box and the type of audio jacks that I was originally wanting, I decided to remake the sound card switchbox for Melty. The project took about 140 minutes (about 7 days and about 20 minutes per day) since I needed access to the heatshrink and heat gun at work (I'd rather not have to use the soldering iron or a lighter on the heatshrink) - I obviously worked on it a bit at a time during my lunch break, but I did drill out the holes and trim away part of the inside plastic at home; the 140 minutes does not include the amount of time that I spent planning it out.

I reused the cables (and switches) from version 1 along with using 27cm lengths of extra stereo cable to increase the length a bit, which turned out to be slightly excessive. The heatshrink I used around the cable splice didn't turn out too well, but I didn't want to waste time cutting all the heatshrink off to try the smaller-sized heatshrink. When I drilled the holes for the cables, the plastic chipped a bit, so I was forced to countersink the imperfections away, which ended up making it look kinda nice (it's very hard to see the hole past the countersink).

I used some scrap pieces of ribbon cable to connect the switches to the jacks, which makes it look much cleaner than the previous version. The ground/sleeve wires (whatever you want to call it) from the cables are not covered with heatshrink (except for the ribbon), since it wasn't entirely necessary and none of them are touching one another.

While I wanted to take a picture of the switch loose like I did with version 1, I didn't want to waste any time, so it wasn't possible at work, and disassembly wasn't an option because of the thread-locking compound on the switches (and jacks).

Sometimes it's surprising how nice something can look with some new parts.

Finalized schematic (which was originally done in pencil, but had to be inked due to smudging). "Scuffed" refers to the side I scuffed a bit while filing excess plastic away on the box and lid.

Insides and close-up view.

Front and rear 3/4 view (apologies for the massive glare on the rear 3/4 view).

Rear view (apologies for the lens flare). I decided against making/placing a "P" label since I'm one of those that can extrapolate from incomplete data.

View of the splices and a close-up view of the gap between the heatshrink and cable.

Front and rear 3/4 view after "installation" (The side with the "Lin/M$W" label will be visible to me when I move Melty into the closet of the other room).