Showing posts with label Hardware. Show all posts
Showing posts with label Hardware. Show all posts

Thursday, 20 August 2020

General computing update - week 34, 2020.

 Since writing early July about about the need to replace the disks in mainpc I have finally progressed towards this stage by purchasing the first of two disks. As noted in the earlier post, this was prompted by an I/O failure of one of the disks that resulted in it dropping out of the RAID array. However I was eventually able to add it back into the array and it has worked properly ever since. The first disk has been added to the existing array which is currently a three disk mirror. As soon as mdadm has synced this disk completely, I can then remove one of the existing disks off the array and then take it out of the computer, as I need backup disks right now. As noted at previous article the disk array will be the same size as current. I am expecting to buy the second disk in about another month and install it in the same way so that when it is also installed, the old disks can be removed completely, and all without actually copying any files. Last time when I did an installation I manually copied the files, but that was mainly because I doubled the disks from 1 TB to 2 TB; this time I will be staying at 2 TB.

Another techical task I have been working on around the house is erecting a TV aerial on the outside of the house. This has meant installing a cable duct and two faceplates between the inside wall and the underside of the soffit to take the aerial cable. That was the hard part as running the cable through the duct was very simple as was putting the aerial itself up. The TV itself is wall mounted and the cable comes through directly behind it. As I am in a prime reception area, the aerial does not need actual line of sight to the transmitter – there is actually another house in the direct line, but the signal is so strong that there is enough signal to get a good picture on every channel.

A few weeks ago I had some problems with a new package-based version of Qgis that would crash every time I tried to run it, on more than one computer. I had to install a flatpak-based version of Qgis, although I could have also run it in a virtual machine. The project developers built a new release after several weeks and it started working again, as did the next edition. Due to the disruption, I have implemented an extra precaution of testing every new release on a VM before installing it onto a working computer.

Google has again heaped glory all over themselves by implementing an arbitrary and dictatorial change to the Youtube platform. As of last week, they stopped making it possible for Youtube to send out notification emails whenever a new video is uploaded or streamed onto a channel. This has left a lot of people, including me, very annoyed by the decision. It is similar to the nonsense of the new Blogger user interface that is badly broken and which has forced me to copy and paste all my posts from another editor like LibreOffice. As I am doing right now with this post. Contrast that with the approach taken by Wordpress.com with a new editor system introduced a few months back; it was pushed through, but they did a lot of consultation with their users. In this case, Google has just announced the changes, but if there are any issues, it’s a one way conversation filing a problem report, just like the way you cannot actually have a conversation with Facebook about bugs or problems on their platform most of the time.




Tuesday, 21 July 2020

General update week 30, 2020

I wrote about a lot of fun getting a system to work with static IP addressing (it is running Debian 10 with LXQt). Since it was able to be made to statically configure its IP with no issues, I configured the other Debian10-LXQt system with a static configuration also. The second computer only has one network adapter, but the benefit is that since the network router and wireless broadband router are only switched on when needed, I do not need to wait for the network router to come online each time and be ready to supply DHCP addresses to the client computers when they start up. Everything is working well now.

At the present time the backups are all being done locally on each computer as previously referenced using rsync since I have yet to do further work to make an rsync daemon function as planned for trial for backups. Another option I could look at for backups is the BackInTime application, however I have been generally wary of using anything that does not do straight file by file backups to the destination but instead creates its own archive format. This is not such an issue with commercially supported proprietary software, but I am very insistent that I do not get locked into archive formats with open source software that may not be supported forever. Probably this is the reason why lots of people prefer just to use rsync.

mainpc had an issue a couple of weeks ago when some sort of timeout on one of the RAID array disks caused mdadm to push it out of the array. It was then coming on and off line seemingly randomly for a time, but then stabilised and stayed online. Smartctl testing showed there were no errors on it. After a week it was readded to the array which is now functioning at 2 disks again seemingly with no problems. However as these disks are 4 years old (last replaced 2016) I am currently planning to buy 2 new disks for the array as soon as I can, this will be at the rate of 1 disk per month with the old ones being available for backups although it would still be preferred to buy completely new backup disks. 

The disks in the array currently are WD Black and that is the proposed replacement at $250 each. SSD is considerably more expensive but by the time I next have to replace any of these disks the cost of SSD could well have come down and be more affordable. WD Black SSDs in the size needed are  very expensive at around $1000 regular pricing each (four times the HDD price) and are only M.2 format which is problematic since it is rare for a board to have more than one M.2 slot at least in the price range I have. I have checked and the H-97 and B250M-D3H boards do have one M.2 slot each but not two. There are adapters available but another option is simply to switch to another SSD brand such as Intel which is considerably cheaper although with lower performance, if the performance at least equals standard HDD it would be a big reduction in cost to around $400 each. As I think, in a few more years getting a pair of SSDs for the array will be within the same price range as the regular HDD. I am still keeping the lid on the amount of storage on this computer resisting the temptation to buy bigger disks as in spite of growing photo and general data storage, so far it has proved possible to manage existing storage sufficiently well to avoid running out of space.

Monday, 13 July 2020

Building a Linux PC for under $1000 (TechRepublic)

TechRepublic have an interesting article on building a great Linux PC for under $1000. Although it's clear the article refers to US dollars, which in price terms is usually lower, the prices are mostly comparable with what we pay in NZ. 

My last couple of build experiences were different. I built a low cost system using a Gigabyte H110-S2H board, my usual choice of a Pentium G CPU, and 8 GB of RAM for around $300 about 3 1/2 years ago. I think initially it was installed with Windows 10. It was cheap because I recycled a case, power supply and hard disk, so I only had to pay for the board, CPU and RAM which cost about $100 each at the time. The board was taken out since then and put into a different chassis and it has been repurposed for video playback, because it only has 2 DIMM slots. I must have been really strapped for cash at the time as all the other systems I have built used slightly more expensive board with 4 DIMM slots.

Last builds I did were buying a pair of Gigabyte B250M-D3H boards and Pentium G CPUs for a total of about $500, just about 18 months ago. I had planned on getting newer B360 boards and Pentium Gold CPUs, but there was a shortage of the CPUs at the time, and I discovered Dove Electronics, a wholesaler we used to use when I worked in high schools, had only two of the B250 boards left, probably the last stock of this model in the country. I managed to get these shipped to me along with the CPUs and 32 GB of RAM for one of the boards (another $500), then rearranged a whole lot of things. The aforementioned H110 board being taken out of a chassis and replaced by one of the B250s with all the new RAM, and the other one going into a new system with some RAM from the H110 board (this had had 16 GB previously but that was split between it and one of the B250s). 

The oldest thing I have here is a Gigabyte Z97 which is the computer I am writing this on, with a heap of RAM, I can't quite put a date on when I got it, but it is still going strong and probably has years of life left in it unless the board blows up or something. Because it has still got heaps of performance for everything I can throw at it.  The hard disks are the only parts I have had to replace and as one has been a bit finicky lately I might have to scrape together some cash to replace both of them soon which is a bit stiff with my current resources. This system is also the only one of my computers (apart from the Mini-ITX system) for which I have actually purchased a chassis, all the others being recycled from schools. The B250 that had only 8 GB recently got a boost to 16 GB which cost around $70. 

Anyway going from the article, pricing is pretty similar and if you had to buy everything new it soon adds up. The only really different cost I can see in there is for RAM; 32GB at current pricing in NZ is about double what he quotes ($275 at PBTech, which itself is a fair drop in price from what I paid 18 months ago). 

Building your own PC is actually pretty straightforward and well worth while. The most complicated task you would typically expect to encounter is installing the CPU and fan, and I have never had any issues there despite the potential for damaging the chip or board. I usually build my systems on a wooden base on a table (nude) and then install them in the chassis once I have verified everything is working properly. 

Considering that in 1997 my first serious PC cost nearly $4000 from a shop (with a cheap inkjet printer) it is amazing that the cost of parts has come down so much (no allowance for inflation). Even having a shop build you a PC today wouldn't cost anything like that much, maybe $1500 for a system built in NZ. Of course some companies are having systems built to order overseas and then shipped directly to the customer. If you use Windows you can get it for next to nothing with a shop or OEM built PC, the retail edition of it that you can buy for adding to an existing computer being a bit pricey (I have one here for the one and only Windows computer - the Mini-ITX system - that I still use occasionally for compatibility reasons). Running Linux on all my home built systems takes the OEM licensing cost advantage out of the picture completely, besides all the other benefits that Linux brings.

Tuesday, 7 July 2020

Reinstall KDE system with LXQt [3]

This is the third article in a series about problems with KDE leading to a reinstallation with LXQt. Both running on top of Debian 10.

The computer concerned is running two NICs because it needs to access both networks that I have here. I have the main one based on a corporate wireless link from next door, which is filtered and throttled, and a second networtk based on a Skinny cellular broadband network modem, which is not filtered or throttled, although speed is moot since there are limitations inherent with 4G cellular data. The Skinny modem is connected to the local devices through a Ubiquiti AirRouter, which includes a DHCP server and network switch. It also provides the wireless network for phones or tablets. The capabilities of the AirRouter are much better than those built into the Huawei Skinny modem for internal networks and that is why I am using it.

There are some issues with LXQt mainly in panels but apart from that the reinstallation of software has gone well on the platform. One issue with this computer in general is that it needs more installed RAM and I am planning to address that in the next week or two, since I need it to be able to run a virtual machine at the same time as the range of stuff I normally use it for. One issue was reinstalling Gimp, I had difficulty in working out where Gimp keeps its config data as I wanted to copy over the config from my existing computer. It turns out that Gimp uses ~/.config/Gimp as a path, but apparently it also used a Flatpak specific path in ~/.var/ to store some data and there is considerable confusion over why it maintains these two paths especially as the user interface of the Preferences dialog doesn't actually point to the ~/.config path when it appears it should.

One of the interesting experiments this week has been to work with the mounting arms that I use to hold some displays. I have used Brateck wall mount arms with VESA adapters on them for this for some years. The key has been to modify these to allow fine control of the height so that when displays are stacked vertically, it is easy to put them close together. 

This photo shows how the attachment of the arm to the "wall" (in this case a vertical post attached to the desk) has been modified to allow its height to be adjustable. This is done with two right angle brackets which are bolted together using 80 mm length M6 gutter bolts, which gives theoretically an adjustment range of 80 mm.

I have to work around issues with the backup system from one of my computers at the moment. rynsc has not been able to connect over the network between the computers and running the backup locally on a computer seems to be the way to go at the moment.

Wednesday, 1 July 2020

Reinstall KDE system with LXQt [2]; KDE network and display configuration extremely difficult with numerous bugs

As related yesterday I found various issues with KDE on a computer and decided to reinstall Debian 10 with LXQt as the user interface. After completing the installation I attempted to use ConnMan, which is the network configuration manager that comes with LXQt on Debian, to do a manual configuration of the 1.x network adapter to set its IP address manually without using DHCP. However, my experience has repeated that found in another computer where I had used ConnMan in the past, where it has continued to send DHCP requests for this network adapter despite the manual setting and overridden the blank "gateway" setting specified in the manual settings, with the DHCP settings. In this case, the setting that was overridden was the DNS server; it was configuring the system to use the 1.x network's DNS server address obtained via DHCP instead of the 4.x network's DNS server obtained via DHCP for the 4.x network adapter. 

As I have noted the Lubuntu network configuration manager does not have this problem and is definitely the best out of all three. However as I am not sure at this stage of being able to install this on the computer, my next step was to uninstall ConnMan and set the network parameters in the /etc/network/interfaces file. After uninstalling ConnMan, dhclient could not complete any DHCP requests for any interfaces; it seems that dhclient is configured to use settings provided by ConnMan and would have to be reconfigured to work with it. 

The interfaces file entries ended up looking similar to this

auto enp0s31f6
allow-hotplug enp0s31f6
iface enp0s31f6 inet static
           address 192.168.4.173/24
           gateway 192.168.4.11
auto enx00500b60c1eb7
allow-hotplug enx00500b60c1eb7
iface enx00500b60c1eb7 inet static
           address 192.168.1.173/24

In addition, /etc/resolv.conf contains the entry
nameserver 192.168.4.11

After completing these entries the system was rebooted and further checking confirmed the settings had been applied. In addition it was confirmed there had been no further lease requests to any DHCP servers, the lease for the 1.x network adapter (the problematic one that was pushing through unwanted default gateway and DNS server settings) had expired and had not been renewed. 

It therefore appears I have resolved so far the display issues and also the network issues. The only remaining issue out of 3 mentioned in the original article to be resolved is to get x11vnc running. Then there are the separate matters of reinstalling the software that was on this computer before I reinstalled it.

LXQt has some obvious differences from KDE and one of those is the panel configuration is different and at present it will not support more than one panel on the desktop and will not support a panel being in the top position on the lower display, which in the configuration I have with my displays is the ideal place to have just one panel that is shared between both screens. Although a panel can be placed there and used normally, the panel cannot be right clicked and configured using any of the usual menu options for configuration because the menu is truncated. The only fix being to move the panel to the bottom using the panel.conf file, stop and restart the panel and then configure at the bottom then move back to the top when finished configuring. I will have to check with the LXQt project to see if they have any fixes for this problem.

The other key issue of course is fewer widgets available yet for LXQt. The main one I do not have is the disk free space. I can simulate the CPU monitor bars like I am using on KDE (they show CPU usage, memory usage and swap usage) with some of the built in widgets. So apart from some niggling issues related to the differences between the desktop environments I expect to proceed quickly to having this system up and running again fairly soon and to be able to have a more reliable and easier to use system than I was experiencing with KDE.

Tuesday, 30 June 2020

Reinstall KDE system with LXQt [1]; KDE network and display configuration extremely difficult with numerous bugs

KDE has some great reputation as a desktop environment in Linux and has won considerable plaudits. It however has numerous unresolved bugs which I have observed in the display and network configurations that are leading me to ditch KDE on one of my desktop computers in favour of LXQt. I have had three computers running KDE and one running LXQt all on top of Debian but I will be taking two computers onto LXQt and therefore only having two running KDE.

The concerning issues that are being observed with KDE mainly concern non standard configurations in both display and network, and also the inability to use x11vnc on KDE which somehow blocks it from running. The problem can be summed up as KDE not being sufficiently versatile to allow different configurations where the standard ones are insufficient. For example the VNC client designed for KDE, Krfb, will only buffer one display on a two display computer, making it inferior compared to x11vnc.

The summary of the issues experienced to date is:
  • Networking. Unable to configure a static IP address and route for a network adapter and stop the automatic configuration of an adapter via DHCP. Unable to disable a network adapter and stop it from connecting as KDE ignores the disable setting and creates another new adapter with the same settings as the disabled one (the only option then is to disable or remove the adapter at hardware level).
  • Display. Unable to save the configuration of two displays on my computer. The displays are stacked vertically. KDE is unable to remember these settings and after each reboot, defaults to side by side displays.
  • Remote Frame Buffer. As mentioned above, KDE stops x11vnc from working. Krfb will only buffer one display in a dual display system.
My networking requirement is special as the computer has two network adapters due to being required to connect with two different networks. On LXQt this is relatively easy to set up. On KDE I have experienced the problems mentioned that it keeps ignoring the manual settings. Only one of the adapters can be a default gateway because there can only be one default route to the internet. I have made it clear that the manually configured adapter will not have a default gateway but KDE ignores the instruction to use the manual settings and keeps sending DHCP requests on that network. The net result is it has become impossible to enforce the required network configuration of the computer. 

To illustrate that this is not difficult on other desktop environments, I have set up a virtual machine on the same computer which is set up in VirtualBox settings with the two network adapters with the appropriate configuration in LXQt (the VM is running Lubuntu). This has worked flawlessly without all the dramas that KDE is creating. The network configuration on LXQt on the virtual machine is implemented as the option "Shared to other computers" which allows the specification of an IP address and netmask without gateway settings. In other words that adapter does not have a gateway specified and must not send DHCP requests on the network.

Another difference between LXQt and KDE with regard to networking is the list of configuration methods and their implementation. In the connection manager that is provided with Lubuntu, which is admittedly different from LXQt on Debian, "Shared to other computers" lets a manual IP address and netmask be specified. But this information can't be put in when selecting the same configuration method in KDE. The KDE network manager in this case automatically creates its own IP address on the 10.x.x.x network and you obviously have to configure the rest of your network to match.

The key problem with KDE is it takes over too many things in a computer and makes it difficult to work around its default settings. In LXQt it is extremely straightforward to configure a non standard dual display and save the settings in a config file, extremely straightforward to install and manage x11vnc and it can be more straightforward to configure a network adapter. However ConnMan is a bit more tricky to configure than the Lubuntu network manager - the Lubuntu one is one of the best ones I have used on Linux overall.

I have started a complete reinstall of Debian 10 on the computer despite my misgivings over having to reinstall all the software (including the tricky iscan software for the Epson scanner), because KDE has such an impact on the system, that it is difficult just to put LXQt over the top of it.

Wednesday, 10 June 2020

Raspberry Pi or HPTC For Livestream Player [5]

Last time I wrote on this subject I took a look at whether to continue using a Raspberry Pi to play livestreams and video clips, or to take a look at a more conventional HPTC setup with a normal computer. Original attempts to use a normal computer were with the Mini-ITX board and chassis I have, which had similar challenges to the Pi from being underpowered, and also failing to support the latest codecs, resulting in playback performance problems.

I then looked at building a HTPC using a Silverstone ML03 chassis. For a variety of reasons this has not progressed, one of those reasons being that chassis seems to be unavailable any longer. I then took at look at using a computer attached to my desk, which is a Gigabyte H110M-D3H board. This has been used for these same purposes from my desk, and I have felt it can be dual purposed, as it is doing the same things as I require from a bedside accessible PC for. This meant shifting the main playback screen from above the desk, to a location where it is readily visible from the bedside, with the computer controlled using a Logitech multimedia wireless keyboard with a trackpad.

Initial trials used only this one screen, but I eventually realised it was desirable to keep a second screen to enable the computer to double up for other work. So it now has the same screen configuration it always had, with a 1440x900 Dell screen above the desk and the 1360x768 Sony 32" monitor for playback which is visible from both desk and bed. The speakers for now have been left in the same location above the desk.

Meanwhile the front room is now fitted with an old Bravia LCD TV that I was fortunate to pick up on Trademe for $80. Since it does not have Freeview, it is set up to play from a NUC, satellite or Chromecast.

Another possible option previously considered for the Pi is to fit it into a chassis that is designed with much better heat dissipation characteristics. As discussed previously, PB Tech have these for about $20. I plan on getting one of these for the Pi as soon as possible, but even if it makes the Pi work properly, I won't be changing the bedside setup, as it is a good use of existing resources to have the computer on the desk set up for both roles. I would however have the possibility open of being ble to find another use for the Pi that means it isn't sitting round here gathering dust.

Thursday, 28 May 2020

HOWTO: Set laptop screen brightness in Lubuntu

Some laptops have function keys that can be used to adjust screen brightness. These may not be supported on all laptops, however. In that case, there may be the controls in monitor settings or power management to adjust the brightness.

In my case I wasn't able to find anything, so I discovered how to adjust this using a command line setting. Install the xbacklight package and then invoke it with a command like this

xbacklight

By itself, this will give you the current reading.

xbacklight -set <x>

Pass some number after the -set parameter and it will set the brightness. I found 50 to be a good number after discovering the default is just 12.5.

Friday, 8 November 2019

Power Tools: Best brand of home power tools?

If you are working at the cheap end of power tools there are a few brands to choose from. I have bought Ryobi stuff a few times, weedeaters have been good, also a good 1200 watt electric drill (a knockoff of a Bosch or Hitachi drill) with variable speed, hammer, 2 speeds, reverse etc. I used this some years ago to drill a lot of holes in desks to run cables through and it did a great job. 

Then there is Makita, I have owned a few Makita products but not anything that I bought myself. Orbital sanders, mains powered and cordless drills have been some of their products that I have had, some of which are still in use today.

Then there is Bosch. Their home stuff has been quite good, from a range of cordless drills, saws, heat guns and sanders.

The problem seems to be these days that all three of these brands, plus Black and Decker, have gone mad and are now producing cheap rubbish that only lasts a short time. Well, B&D stuff was always cheap and nasty but now there is a race to the bottom. Some examples:
  • Mouse sanders (triangular detail sanders for sanding into corners): Bosch have two models that are of very poor quality, the base plate is made of foam onto which the sanding pad is held with velcro, the pad being a soft material disintegrates and is then expensive to replace. A ludicrously poor design with also the dust collector box being either difficult to remove and empty, or falling off all the time. 
  • 1/4 sheet detail sander: Makita have done a very poor job with their BO4555/4556 models. Numerous reviews worldwide attest that the paper clamps on these will break off after only a few uses, whilst there have also been a number of people who have found the whole base plate has broken off completely.
  • Any sander that uses Velcro fastening: there are too many of these where the hooks and loops wear down quite quickly and will no longer hold the sanding sheet into place. This also includes the sanding pads that can be bought for multitools.
Seeing these situations for these brands of tools which have previously been fairly well regarded is a big deal for me. It seems these manufacturers are just producing throwaway junk with a life that can be measured in hours.

These situations are hard to understand because I have here an older Bosch random orbital sander that has a velcro pad for attaching sandpaper and not only is the pad made of good quality material (hard rubber) but also the velcro works very well and holds the sheets in place properly and they don't fall off. Generally the older Bosch tools are well made and don't break. The Makita detail sander I have is well made and has given a lot of use (except for the dust bag which has a flimsy internal support that broke). 

So I have to look at some other choices:
  • Metabo (which now has taken over Hitachi)
  • Bosch Professional
  • Hikoki ?
  • DeWalt
Metabo is the only one of these that doesn't seem to be specifically geared at the professional trade (but I could be mistaken in that assumption). Their gear is going to cost twice as much as Bosch but about the same as Makita, yet it looks to be of better quality. They have a mouse sander that Mitre 10 carries in stock for about $175 that appears to be quite well made although reviews are hard to find.

Dewalt don't have a mouse sander but they do have a 1/4 sheet sander and also a random orbital sander which price around $175-225 in NZ and appear to be well made. Bosch have some professional products which can be hard to find here.

Mostly what I see in reviews for certain home user Bosch and Makita products is people questioning why these manufacturers now turn out cheap junk when they used to produce good quality stuff. At least everyone already thought Black and Decker was low end but it seems Bosch and Makita are falling over themselves to emulate B&D and see who can produce the cheapest flimsiest tools that don't last much longer than the ones you can buy from The Warehouse.

I don't need to have any more sanding gear at the moment so this is an interesting discussion / conversation for future reference.

Wednesday, 23 October 2019

Red/green/white handheld signalling lamp

Anyone who is associated with rail heritage knows that on the professional railways in New Zealand, train crews used hand held signalling lamps that could produce red, green and white light, for use when shunting a train. The older style lamps of this type worked with a mechanical rotating filter holder to move red and green filters in front of a torch bulb when a knob was turned on top of the lamp. I've often thought about how easy would it be to make an electronic version out of parts.

When I first started to get interested in electronics, LEDs were only available in red and green, and didn't put out much light. It has only been with advances in LED technology in recent years being able to invent a blue LED to make up the missing primary colour to produce white light, and being able to do it at a very high brightness, that it has been possible to easily make your own lamp that can put out a reasonable amount of light and thus be visible.

To make a handheld signalling lamp, the parts needed are basically some LEDs for each colour, batteries, switches and a case and perhaps a handle. You could use tri colour LEDs that are available and program the proportions of colours that are needed to produce red, green and white, by switching in resistors using a  multi pole rotary switch. You could also use separate red, green and white LEDs to produce the colours. My first thought is to go with the second option. Jaycar has suitable LEDs for about $4 each. I would go for the 10 mm size and possibly at least four of each colour, maybe more, or spread them out a bit. 

For switches it is a question of reasonably waterproof ones and maybe more than one. The most important colour you want to display is red, which means stop as this is the most significant safety action. The main problem with many IP rated switches is they are only SPST. Jaycar does have some momentary pushbuttons that are DPDT. These are important if you want to be sure only one colour can be illuminated at a time. There would be a toggle switch for on/off, and push buttons for green and white, wired (hopefully) so as to cut off power to other colours when one is pressed.

A case would have to be clear plastic, and there are a limited range of these from Jaycar and other suppliers. A power pack would be a battery holder to hold some AAs. 

Well that is the theory anyway and at the moment I'll leave this idea there and spend a bit of time looking in more detail into costs and so forth.

Arlec Plug In Heater Controls [2]

In my previous post in this series I described the PC900 2 hour plugin countdown timer which Bunnings have been selling for some time. The oddity of this product is that it is described on the packaging as having "adjustable switching increments". This is a rather clumsy phrase more worthy of adjustable 24 hour timers and is referring to the fact the timer can be set for any time between 120 minutes and 1 minute each time it is used.

In the same post I referred also to the new THP401 plug in thermostat which Arlec's packaging describes as a "temperature controlled programmable timer". The problem with using the wrong terminology to describe a product is that it sends people up the garden path. The description as above is, once again, carried through into the product packaging. Someone at Arlec needs to improve their knowledge of the English language.

I happened to visit Bunnings again today and one of these was on the shelf at $29.95. The product is, very clearly not a "timer", but a plug in heater thermostat, and obviously a very useful thing to have. The problem is whether people will understand what it does with the wrong labelling.

Friday, 4 October 2019

Arlec Plug In Heater Controls [1]

Arlec is an old established Australian brand of electrical products (such as extension cords and plugboxes, timers etc) that has been available in NZ for many years - at least 40 to my recollection, their innovative designs and features continue to the present day.

With plug in electric heaters sometimes certain desirable features that would be easy to fit for a wired in heater, such as a time delay switchoff or a thermostat, are not always easy to find. I can recall various brands having come and gone, for example countdown timers from BenQ and HPM come to mind. Likewise various brands of plug in thermostat. Arlec is now making both types of product and selling them through Bunnings. (I also remember Kambrook plug in timers with some affection from my youth but they have diversified more into household appliances nowadays). I do have still a Honeywell plug in timer fitted with a cord and interrupted phase tapon plug which can be mounted on a wall some distance from the heater and this is still going strong more than 30 years later.

The Arlec PC900 plug in countdown timer is a mechanical timer giving 2 hours delay and simply plugs into a 3 pin outlet and the heater or other device plugs into it. 

The timer appears to do what is expected of it. However due to its design, it will block an adjacent outlet in a plugbox or multi outlet wallplate. This appears to be a design factor with Arlec products in this range (several different types of timer including the PC697 digital 7 day timer).

Newly available from Bunnings is the THP401 which is clumsily described as a "temperature controlled programmable timer". 

So far as I can ascertain (it wasn't on the shelf at the Bunnings store I visited today) this should really be described as a digital plug in thermostat. Because Arlec do not appear to have added this model to their website yet and because there was not one on the shelf at Bunnings I was unable to verify the description of the unit.




Friday, 20 September 2019

How to PERMANENTLY disable an input device in Linux (Xorg Display Server)

About 2 months ago I posted on how to use the xinput command (on Ubuntu and derivatives) to disable an input device. This, however, only works until the next time the computer is restarted. In addition, not all distros provide the xinput command; Debian doesn't, and I haven't done any research to determine whether this command needs to be installed or if there is a Debian specific alternative. For the time being, the device in which I need this function to work is my Dell E6410 laptop with an Alps pointing stick which is drifting. By default this is enabled alongside the touchpad, so you can use either of these devices, but there is no simple way to disable the touch stick, even if you plug in a USB mouse as I often do.

The answer for when the Xorg display server is used (generally this is the default display server based on X11 for many years, that is now gradually being superseded by Wayland) is to change the configuration settings in a file that is stored in /usr/share/X11/xorg.conf.d/ and in this case the file name to be edited is 40-libinput.conf . In order to effect the disablement, the xinput list command was first used to get the name of the touchpad device, and then this section making use of that name was added to the bottom of the aforementioned file:
Section "InputClass"
        Identifier "disable touch stick"
        MatchProduct "AlpsPS/2 ALPS DualPoint Stick"
        Option "ignore" "on"
EndSection

So that section in the file is pretty straightforward. The MatchProduct entry contains the exact device name string that we got from xinput list and the Option specified "ignore" "on" tells the Xorg server to ignore the device and not enable it.

After doing a reboot the touch stick was found to be out of operation and the xinput list command no longer lists this device.

As I noted in my previous post, the flaky touch stick on this laptop has been a significant issue since it will cause the mouse pointer to drift across the screen quite randomly even when an external mouse is in use and possible options to disable the touch stick at a hardware level (there is for example a Bios setting that in theory would disable it with an external mouse connected) have not worked so far. I did not investigate any possibility however of physically disconnecting the device inside the laptop, but I believe this could be quite difficult as the touch stick is physically located between the keyboard keys and thus it is probably at a hardware level integrated into the keyboard itself and therefore could not be unplugged.

Having this option to disable the touch stick is proving extremely useful since the laptop is otherwise in very good condition for its age and with the installation lately of a 160 GB SSD in place of the regular hard drive and the replacement a few years ago of the original battery, with the limited amount of use since then meaning the new battery should still have at least 90% of its life left, if carefully looked after it will keep going for another decade probably.

I am guessing this xorg.conf.d file entry will work with most distros (including Debian) even if xinput command doesn't work on some.

Monday, 13 May 2019

Escaping Google's walled garden on handhelds [3]: Using Lineage OS - 1

So last time I wrote about the installation experience for Lineage, now it is time to have a look at early impressions of using it. Along the way I discovered some stuff about the Nexus 5X. It turns out that it was first shipped with Android and the final official release of Android for it was 8.1. Also that the last time Google sent a security update package for it was last December. So as far as Google is concerned they no longer feel a need to continue updating Android on this phone.

On the other hand the version of Lineage I was able to flash to it is 15.1 corresponding to Android 8.1 and they are currently working on a release called 16.0 which will be Android 9 so it is possible I could get a later version of Android for this phone that what Google is prepared to support, provided the developers are able to produce an Android 9 release for the "bullhead".

Although I am not using it as a full replacement for the Nexus running Google Android just yet, as I haven't yet switched back to using it as my day to day phone, initial impressions of Lineage are pretty good. It doesn't come with many apps of its own, but one can choose to install one's own from various sources. Of course you have to be sure the sources are reputable and are not going to contain spyware or malware or whatever. I was able to access a site called apkmirror to get first of all the Youversion Bible app and install that. I then didn't install any more apps for a while.

I am currently planning to install the F-Droid app to be able to access their app store (and possibly the Amazon app store as well, although I will be carefully considering that option since I want to steer clear of apps from big multinationals that could do unwanted things on the phone). For further security certain things that are built into Lineage will be activated and the app store apps will be disabled when they are not actually being used. In addition the phone will not be rooted as this is not really necessary as I only plan to use regular apps on it, not ones that need root permissions. All of these measures mean hopefully no security issues with apps from outside the Play Store. However there are many apps that use Google Play Services, and those simply will not run on Lineage.

At the same time I deliberately chose not to have social media apps on my phone and only one email account that is being checked regularly because I simply decided I don't need to have access to social media when away from home. This means apart from the phone and text messaging, the main thing the phone would be used for when not actually at home is reading my Bible or possibly listening to music (it depends on how well the battery lasts). Any time I was away from home for any period of time I can take my tablet with me and use all these apps on it but for regular day to day stuff I won't need any social media apps on my phone. Also I intend to use an Open Street Maps app instead of Google Maps.

So yes it is possible if one is willing to make a few sacrifices about what apps are really essential, to escape the "rat race" of having your phone taken over by gigantic multi national corporations to make enormous profits and just get back to the basics of the convenience of having a phone you can carry with you and which can perform a small number of additional functions.

One of the bonuses so far which is partly because Lineage gives control of the ability to run an app in the background is very much increased battery life. Although I haven't used my phone much in the last couple of days, it is currently 37 hours since the last charge and the battery capacity is 73% which is absolutely unheard of for this phone. If I used it I could expect it to go down a bit faster, but I am still going to get heaps more use out of the battery than I have before. So this phone will probably last a lot longer. Then I suppose I will have to work out what I can replace it with.

I am also planning to install the Android Studio app developer software and maybe some other F/OSS app developers to see what I can do with them, and whether I can develop an app to replace the Auto DND app that I use. But ultimately the replacement for a lot of apps is to use a web browser instead.

Saturday, 11 May 2019

Escaping Google's walled garden on handhelds [2]: Installing Lineage OS

So after further investigation I decided Lineage OS would be the most straightforward means of getting my Nexus 5X off Google. This is quite a lengthy process that involves replacing the installed Google bloatware on the phone with the LineageOS installation images.

LineageOS provides guides, which are pretty good except that like me, you can get some steps wrong the first time. And of course the instructions differ depending on your version of Android.

The most important points found are as follows:
  • When you install adb you will need to install the udev rules on Debian. Using the instructions for Ubuntu are what worked for me. But of course because Buster won't let us run all the commands in a bash shell, as usual we have to go out to a full screen terminal (Ctrl-Alt-F1) to do some of it, and then come back into KDE (Ctrl-Alt-F7) to finish things off.
  • When you go into recovery mode, the Lineage instructions have missed out a step or two. The steps you need to follow to boot into recovery mode are
    • Power off the Nexus
    • Hold down Volume Down and Power to boot into recovery mode
    • According to Lineage the next screen gives you "Recovery mode". This is not so. You actually have to press Volume Down button to get to Recovery Mode. By default it just comes up with "Start".
    • Then you see a Android icon tipped on its side with a exclamation point hovering over it. 
    • At that point you have to hold Power and then press and release Volume Up to get into recovery mode.
  • The recovery environment install is tricky because if you don't reboot properly, it seems that Google will conveniently replace the TWRP recovery environment with its own (Android Recovery). How you know this has happened is if recovery comes up to TWRP it is a graphical touchscreen environment. But Android Recovery is all text based and using the volume up/down keys to select options and the listed options do not match the ones for TWRP at all.
  • So you have to make sure you reboot properly to use TWRP to run the commands you need because Android Recovery will not let you flash anything into the system. So you can't use it to install.
  • So after you have flashed TWRP into the system then reboot properly.
    • On the recovery options DON'T CHOOSE REBOOT. Choose POWER OFF
    • Once the Nexus is off then turn it on by pressing Volume Down and Power together.
    • This will get you into TWRP with its graphical touchscreen and then you can get on with flashing Lineage and any other packages onto the phone.
I have chosen to flash only Lineage and the rooting package. I am no way absolutely never verboten from my cold dead hands etc NOT INSTALLING THE GOOGLE APPS PACKAGE. This means unfortunately not being able to use any app from the Play Store and anything that will rely on Google Play Services if from another source. However that is why I have other devices running regular Android but these devices are not a phone or do not have a cellular services SIM card installed or can be turned off when I am not using them thus preserving my privacy. 

After I had done the flashing I told TWRP to reboot the system. The most annoying thing at that stage was TWRP telling me that I had no OS installed and was I sure I wanted to reboot.  After rebooting you are going to see "Google" and then instead of the animated boot icon for regular Android you will see the Lineage one instead. Then there is a slightly scary moment when the whole screen is black and the system doesn't respond to pressing any buttons. Fortunately after a few more seconds your computer will pop up and tell you it recognises the Nexus (assuming the USB cable is still plugged in) and at that point checking the Nexus shows us that LineageOS boot screen has come up.

The setup steps are practically the same as for regular Android except you don't get asked to do any of the Google apps stuff but I was quite pleased to see it work with the fingerprint reader and allow me to enrol fingerprints just the same as before. After this it went into the home screen of Lineage and at that point was ready to go. I'll leave it there for this post and I am not going to do any more stuff on it right now, that will be covered in my next post after I have had plenty of time to play with Lineage and see what I can do with it. I will be using it initially with my tablet share SIM, which can make phone calls and send and receive texts but can't receive phone calls, until such a time as I might be ready to switch over to it becoming my regular phone again.

Friday, 10 May 2019

Escaping Google's walled garden on handhelds [1]: Intro

I've owned smartphones since 2012 when I was given one as part of a new employment role. It (HTC) was running Windows Phone 7. It was followed by a couple of Nokias running Windows Phone 8 (the later one since updated to 10) and then a low-end Motorola Moto E running Android 4. The next thing was a Samsung Galaxy J2 running Android 5 and a Galaxy Tab A 8" tablet also running 'Droid. My latest phone is a Nexus 5X which is currently on Android 8.

What has become particularly noticeable in handheld operating systems apart from Apple's (in a class of its own) in recent years is the extent to which vendors have sought to take ownership of the user's device and data. MS first did this with Windows 10 and went to extraordinary and obnoxious efforts to push users of older versions into upgrading to 10. 

Google has been sneaking upgrades into Android over the past few years, particularly in the "Google" app which in Android 5.1 has gone from 13 MB to 209 MB in size without any explanation or choice on the user's part as to the justification for installing this massive bloatware. But what we do know about Google's recent efforts is that voice recognition and the obnoxious Google assistant are now enabled by default with every new Android phone or upgrade and are very hard to disable. The assistant in particular is listening to everything that the microphone can pick up and transmitting it back to Google. In addition, it is becoming known that in Android 8, Google screen scrapes data from every app installed in the system, and that it tracks every location that the device travels to.

So we have entered an era where more than ever, operating system vendors are forcing updates onto systems to increase their ability to grab every possible piece of information they can collect on the device owners and transmit it back to the mothership so that it can be used to make increasingly bigger profits. And we are supposed to trust these gigantic multinational corporations that they have a benign intent and really are going to use our data to give us better products and services? LOL! 

So in much the same way as I have been through a journey of giving Windows the boot and installing open source software on my PCs, I am going to be doing the same sort of process with my handhelds. First of all, I will be switching my phone back to the Galaxy J2 with only a limited set of apps, and then the Nexus will be reinstalled with something else. At the moment, Lineage looks good, but I need to delve deeper into its architecture before making a final decision. The Galaxy Tab A will be left as is. If Lineage is what I want then it should be capable of becoming my day to day thing on the Nexus. Of course, it won't be running any of the Google apps or the Google Play Services. 

More to come...

Tuesday, 30 April 2019

Networking / Wireless with Debian LXQt

There are some issues possible with LXQt if you have Wifi because of limitations in the current Buster install. Some of these may be resolved by the time Buster is released...but not all, for reasons explained below.

First issue for Wifi is if the drivers are non-free, as is fairly likely. You'll notice this at setup if you get asked for a driver file to allow the wireless networking connection to be accessed (more likely if using the network based installation). This occurs because Debian is configured by default to have non-free stuff in separate repositories and access to those has to be specifically enabled in the sources.list file. Basically you have to change the first set of repository statements in the file that point to main, to point to main contrib non-free. This is due to the Debian licensing model and philosophy.

After that you can, for example, install firmware-iwlwifi which is the package for Intel wireless. 

The next issue is that there is no network connection manager installed by default in LXQt with Buster. Installing network-manager-gnome is the way to get this, along with nm-applet. Then you have to edit /etc/NetworkManager/NetworkManager.conf and change the following:

[ifupdown]
managed=false
 
change the false into true. This is necessary to ensure that you can manage the wired interface as by default you will not be able to manage this.

After that you should be able to get the wireless interface working on your computer. If you don't have wireless, having Network Manager installed is still useful if you need to set up anything non default with the wired networking such as a static IP address. 

UPDATE: I had a lot of trouble on this computer getting Network Manager to be able to set the IP address and parameters for the Ethernet cable port properly. The settings in the /etc/network/interfaces file read

iface enp3s0 inet dhcp

whereas in Network Manager I had changed to manual configuration which should have been shown in the file. So there is an ability to directly edit the parameters in that file so in our case we write something like

iface enp3s0 inet static
    address 192.168.1.222
    netmask 255.255.255.0

with no gateway or DNS servers or anything because this particular interface is only being used on the intranet and not to access the internet. But the question remains why Network Manager is not setting those parameters in the file. In other words it seems Network Manager was only able to configure the current session when it was used and not the configuration settings for next time. Network Manager was apparently able to handle the wireless connection. Possibly the issue of what is being managed in the Network Manager settings mentioned above.
 


Wednesday, 2 January 2019

Computing resources optimisation [2G]: Reinstall serverpc and mediapc

As we know when I upgraded everything last month I just put the disks back in with the new boards and just booted everything up and they just ran. I didn't reinstall either of the two new ones that I currently have running, serverpc and mediapc.

However as neither of these computers is able to hibernate, I have started reinstalling serverpc to see if I can get it to hibernate, and if this works, mediapc, which for some reason won't hibernate at the moment, will be reinstalled as well.

Both will be installed with KDE on Debian 9.6 , and reinstallation is not a really big job as neither of them has a lot of software installed, as those two are mainly used for specialised tasks.

Also it's been a useful time to get serverpc to be able to access all of its SSD swap space which is over 100 GB which will come in useful when doing really big jobs that exceed the 32 GB of memory that it has installed.

Hibernation in Debian seems to be quite reliable, and is enabled by default, one of my reasons for choosing it over Ubuntu or its variants, which have hibernation disabled by default. However there seem to be more issues with hibernation not working well when KDE is the desktop environment, compared to my experience with XFCE.

I would have installed mediapc first, since it doesn't have KDE at the moment, but as it doing the backups at the moment it is just easier to do serverpc first and then do mediapc later. I decided to leave serverpc's name as serverpc, and mediapc will stay with that name as well.

It is good that I don't need to enable UEFI on the two new boards as due to my negative experience with UEFI on Linux on the old serverpc, I am sticking to everything being BIOS for the time being. The exception being the NUC which remains UEFI.

The first attempt to hibernate on serverpc was a failure and the desktop environment would not load properly on resume so I flashed the BIOS with the latest version. This had the useful effect of getting rid of all the ACPI error messages at boot. It's interesting the BIOS was already at the second to latest version (Gigabyte F9) and putting it to the latest (F10) got rid of all those ACPI errors. There have been about six revisions of the BIOS for this computer and I was fully expecting to have quite an old version on this two year old board as it is so easy for the manufacturer to not bother updating the firmware at the factory and leave it to a user to fix.

To finish reinstalling serverpc I need to re-enable the root logon (which I haven't got around to doing on mainpc) to be able to get the RAID array online with my user profile so that is one step to be completed. However while resume from hibernation seems to be retrieving application data the KDE desktop environment often does not seem to be reloading properly as instead of the menus etc all you get is a black screen. This is obviously very odd and something I need to do more investigation into as regards KDE. However it seems to be a common issue and maybe it will be easy to resolve.

Monday, 31 December 2018

Computing resources optimisation [2F]: Managing Disk Space Usage

The completion of this computer upgrade project is close to finished. I do have to complete mounting the fourth computer, which is inching along at a glacial pace at the moment, and various small tasks. One of the important ones is that mainpc's disks which have a total capacity of 1.8 TiB or 2 TB are nearly full. The main increase in capacity use is to do with mapping. This is to some extent the Maps folder and to a lesser extent Oracle virtual machines that have been used to run different software versions. Each time I download more aerial photography for maps it takes up additional space. I am satisfied the usage is appropriate so I now have to look at whether other resources can be released to make more space for various uses.

In the past I did look at moving some stuff like photos or other media to mediapc. I am not sure this is going to be easy or actually possible because right now mediapc's disks are nearly full and there doesn't seem to be an easy way of freeing up capacity. It will probably be a case of cleaning up a few folders here and there on mainpc especially where duplicated on mediapc. The Downloads and DownloadArchive folders on mainpc together total more than 300 GB and I think working through them regardless of how tedious or slow it is, is going to be worthwhile. At the very least there are large volumes of LDS downloads that can be cleaned up. It shouldn't be too hard to free up at least 100 GB relatively quickly and take some of the pressure off the fact I only have 132 GB free at the moment.

serverpc is the other major disk space gobbler with for the most part the aerial mosaics using nearly half of the total disk. With more and more mosaics being put together as the maps progress, I have to take a hard look at whether I need to keep so many files. Cleaning up downloads will also yeild space savings on that computer. With it now having 32 GB of RAM there is less demand for swap space in the past and it does have the SSD available for swap, but still it is currently down to less than 100 GB free space available. It is actually so simple and quick to make mosaics that I don't really need to keep the last three files of each one and possibly I can cut back to just the most recent file.

Cleaning all these up will also speed up backups. With mediapc becoming the backup host, I have to get it set up to run some backups which are very overdue of late.

Well as it turned out  I was able to free up 400 GB on mainpc with only a little effort and easily get that on serverpc as well but it will soon be gobbled up with more mosaics so I will have to get creative with deciding how many mosaic files I need to keep on serverpc. The backups are underway again but I am only keeping one generation of backup for serverpc and two each of the other two computers, it can be slow as a full backup can take more than a day which is why I have a dedicated computer, in this case mediapc, which is running the backup while I can keep using the other computers that are being backed up as normal. Once mediapc has finished doing the backup of mainpc it will be reinstalled with Debian 9.6 with KDE on top as I only need one computer running XFCE and that will be playerpc. In the process mediapc gets its swap put back onto using all the SSD space as there have been issues that it can't hibernate at the moment and it needs to have that swap available if it is doing big tasks with only 8 GB of RAM. I am meanwhile pushing along finishing the installation of playerpc under the desk.

Thursday, 20 December 2018

Raspberry Pi [4]: Raspberry Pi vs Chromecast

I last wrote about my Raspberry Pi back in July, and since then it hasn't been used. I decided against using it to play videos because it had some trouble playing some of the ones in my collection. At this point I went back to playback from a computer, and subsequently pc4 was used for this role.

I am taking another look at the Pi as a media player for small group settings where you just need something that is small, compact, easy to carry around and quick to set up. At this point I am also making a comparison with a Chromecast.

Here is a quick comparison between the Pi and the Chromecast.


Raspberry Pi 3 Model BChromecast 2016
DescriptionSingle board computerStreaming media player
SOC / CPUBroadcom BCM2837 SOC, 1.2 GHz quad ARM Cortex-A53 processorsMarvell Armada 1500 Mini Plus 88DE3006 SoC, 1.2GHz dual ARM Cortex-A7 processors.
GPUBroadcom VideoCore IV?
RAM1GB LPDDR2 (900 MHz)512MB
Networking10/100 Ethernet, 2.4GHz 802.11n wireless802.11 ac (2.4GHz/5GHz)
BluetoothBluetooth 4.1 Classic, Bluetooth Low EnergyN/A
StoragemicroSD256MB flash, app based cloud
PortsHDMI, 3.5mm analogue audio-video jack, 4× USB 2.0, Ethernet, Camera Serial Interface (CSI), Display Serial Interface (DSI)Fixed HDMI cable 0.1 m
PowermicroUSB type BmicroUSB type B
Operating SystemRaspbian (Debian derivative) plus most Debian packages for ARM architectureUnknown proprietary
Core AccessoriesOptional case, optional power supplyIncluded power supply

The Raspberry Pi has a higher hardware spec overall. The Cortex A-53 quad processor is more powerful than the A-7 dual processor in the Chromecast; it is 64 bit capable (compared to 32 bit in the Chromecast). Power requirement for the Pi is greater if it needs to supply connected USB devices. The Pi's wifi only supports 2.4 GHz; the Chromecast is both 2.4 GHz and 5 GHz capable. The Pi can run ordinary Linux software and can store data on the microSD card and/or external USB devices; a Chromecast user does not have direct access to the small amount of internal flash storage and can only access cloud storage via apps. The Pi is a physically larger device, mainly due to the space taken up by the USB and network sockets attached to the board. If those sockets and the GPIO socket were taken off the board it would only be slightly larger than a Chromecast. The Pi can be booted off any available OS; the project homepage supplies Raspbian and also links to 3rd party OSs, including Windows 10 IOT.

I have both of these devices and have evaluated their performance for playing back videos. The Chromecast's main limitation is that it can only playback content via a compatible app. If you want to play your own videos they have to be on Google Drive or some other storage and there has to be a cast-enabled app that can play them. So far, while Google Photos was able to play my sample video clip, the video stuttered and there was no sound being played back. I now need to do some more research to discover if there are other apps available that may have better video performance and be able to play sound. The Chromecast uses your phone as a remote control for media playback, which is convenient since you don't need a multimedia keyboard. It is only possible to play back the audio via the HDMI connector to the TV; if your TV does not have HDMI audio capability or you need to connect an external audio device, you will need to purchase an HDMI splitter which costs itself more than a Chromecast. Setting up the Chromecast is easy. Plug in the HDMI cord to a socket on the TV and connect the power cable. Install the Google Home app on your phone, and it has some way of finding the Chromecast. Set up the Chromecast to connect to your wireless network and then add it in Google Home, and you're all set to go. In my case the Chromecast needed to download and install an update from Google, which happened automatically and seamlessly.

The Raspberry Pi can play back anything you want directly through its single HDMI output. There may be some issues with audio playback through the HDMI socket (due to general issues along this line in Debian) in which case the analogue audio/video socket is also available to connect to speakers. This is also an option if you don't want to use your TV's speakers. By default you would need to connect a multimedia keyboard to the Pi to control it. There are apps available for Android that can remote control various aspects of the Pi and eliminate the requirement for a keyboard. The Pi takes a lot more setup work than a Chromecast. Best outcome will be if you install one of the specialised Kodi-based distros for the Pi - either OSMC or LibreElec are choices. I have been testing both. My first attempt, with Raspbian, failed as I could not get any sound at playback. Once you have the image it has to be flashed onto the microSD card and then inserted into the Pi before turning it on. OSMC was able to play all my test videos with sound in the Kodi interface it provides. The sound came out of the HDMI and I haven't checked if there are any settings to split it to the analogue output socket.

My next steps in testing the Pi are to try out LibreElec as an alternative to OSMC to see if there is any real difference, and to see if a remote control app can be used on my phone instead of a keyboard. This is a much better option for a small media player. Another option is to fit a touchscreen to the Pi, as the board is designed to support one and they can be purchased. But I will leave that option and focus on the phone one. Next steps with the Chromecast are to try out some third party video apps and see if they can play back better than Google Photos.