New (To Me) Programming Toy: Async/Await Pattern

Several different motivating factors have aligned for me to dust off something long on my to-do list of software development skill-building: learning then getting hands on with the async/await programming pattern. In this world of multitasking, multithreading, and multicore CPUs communicating with each other over the network, asynchronous programming is required everywhere. However, historically my programming projects have either (1) not dealt with asynchronous behavior, as it was handled elsewhere or (2) had to be written explicitly and unable to use syntactic niceties like async/await.

I knew experience structuring code for async/await is a gap in my toolbox, but I never had enough of a motivation to sit down and patch that gap until now. And like every new area of knowledge, it helped to get some more background on this development in programming languages before I dove in. Contributors to Wikipedia credited futures and promises as the theoretical research foundation where this work began, but it has since evolved through several forms until there was consensus async/await pattern was the way to go.

I don’t know which programming languages first put the theory into practice, but I personally first learned of this evolution from JavaScript introducing futures and promises some years ago. It sounded interested but I was not impressed by how it was implemented at the time, and apparently enough people agreed that JavaScript has now adapted them to the newer async await pattern. Available to the web development world both on the server side via Node.JS and on the client side via modern browsers.

I haven’t played with JavaScript as much as I’ve wanted, it’s still on the to-do list. I’ve been spending more time on the other modern language darling: Python. I had never used async/await with Python, but it is there so I’ll be able to use it in Python once I learn enough to make it a part of my programming toolbox.

One concern with novel programming techniques is that people may get bored and move on to the next shiny object. It is definitely a worry with ideas under rapid evolution, so how does a grumpy old programmer know something has sufficiently stabilized? By seeing if it’s in the latest version of C++, of course. And while the answer is a “no” today, it appears to be more of a “not yet” which gives me confidence in stability. It may still evolve, but I am unlikely to get whiplash from future developments.

Confident that it’s not going to disappear tomorrow, I surveyed the field of options and decided to start with C# as my first exploration into this programming pattern. Also called TAP or Task-based Asynchronous Pattern in Microsoft’s documentation. Part of this decision was informed by learning why Microsoft was motivated to recommend it.

Notes on Exploring Curio ROS: ros_control

When learning something new, I always find it useful to find a part that I could use as a foundation. Something I can use to build my new information on top of. I had trouble finding such a foundation for ROS as it was such a big system. So it was a great gift to have the chance to look at Rhys Mainwaring’s ROS stack for Curio rover, a sibling of my Sawppy rover. This meant the rover I designed and built was my foundation for learning Curio’s ROS software stack.

Such a foundation was less critical when I had explored Curio’s interaction between Arduino Mega and Raspberry Pi. But it was very useful when I explored how command messages were sent around inside the system. This was built using ros_control, a set of ROS packages that help abstract the concepts of robot motor control from the actual details of motor controller commands.

The promise here is allowing a robot builder to swap around different motor controllers without changing the logic about how a robot would use those motors. Conveniently, Sawppy has both of the basic categories: “Joints” specify a position, and that fits Sawppy’s four corner steering servos. Whereas “Transmission’ specify rotational motion like Sawppy’s six wheel motors.

The idea of abstracting motor control from implementation is common, I even had a primitive form of it inside SGVHAK_Rover software allowing us to hack a servo into a RoboClaw placeholder, and later adapted to Sawppy’s LX-16A serial bus servos. The power of such abstraction comes when it becomes open and flexible enough for software modules implementing either side of the abstraction to be reusable beyond its original author’s use. That certainly was not going to happen with a homebrew pack of servo software, but a convention in ROS is a different story.

Which is why I was puzzled to learn ros_control does not appear to be in the works for ROS 2. It is absent from the index, and I found only a discussion thread with no commitment and this page with a dead link. I thought ros_control would be a fundamental part of the platform, but it is not. Its absence tells me there’s an important gap between my expectation and ROS community’s actual priorities, but I don’t know what it is just yet. I’ll need to find its successor in the ROS2 ecosystem before I understand why ros_control is being left behind.

Notes on Exploring Curio ROS: Arduino Mega

I was very excited when I learned Rhys Mainwaring created ROS software for Curio rover, a sibling of my Sawppy rover. An autonomous Sawppy on ROS has always been the long-term goal but I have yet to invest the time necessary to climb the learning curve. Rhys has far more ROS experience, and I appreciated the opportunity to learn from looking over the Curio Github repository. Here are some of my notes. written with the imperfect accuracy and completeness of a ROS beginner learning as I go.

The most novel part of Curio is obtaining odometry data from LX-16A’s position sensor with the use of a filter that recognizes when we’re in the dead zone of that position sensor and rejects bad data. I believe Rhys has ambition to extrapolate position data while within the dead zone but I didn’t find the code to make it happen. Either I missed it or that is still yet to come.

I love the goal of odometry calculation without requiring additional hardware, but Rhys ran into problems with bandwidth and a little extra hardware was brought in to help as (hopefully?) a short term workaround. While Sawppy didn’t need to communicate with the servos very frequently, Curio needed to also poll servo positions far more frequently for the odometry filter. Rhys found that the LewanSoul BusLinker board’s serial to USB bridge could not sustain the data rate necessary for the filter to obtain good data.

As a workaround, Curio makes use of an Arduino Mega 2560 to communicate with BusLinker via its 5V UART TX/RX pins, and then translating that to USB serial for the Raspberry Pi. The Arduino Mega is necessary for this role because it has multiple hardware UART necessary to communicate with both BusLinker and Raspberry Pi at high speed. I only have Arduino Nano on hand, with a single UART, and thus unsuitable for the purpose.

Curio’s Arduino Mega also has a second job: that of interpreting PWM commands from a remote control receiver, relaying user commands from a remote control transmitter. This is an alternative to my HTML-based control scheme over WiFi.

Curio’s Arduino communicates with its Pi over USB serial, using the rosserial_arduino library. Rhys has set up Curio’s Arduino firmware code such that its two jobs can easily be separated. If a rover builder only wants one or the other function, it should be as easy as changing the values of ENABLE_ARDUINO_LX16A_DRIVER  or ENABLE_RADIO_CONTROL_DECODER to trigger the right #ifdef to make it happen.

Ubuntu and ROS on Raspberry Pi

Since I just discovered that I can replace Ubunto with lighter-weight Raspbian on old 32-bit PCs, I thought it would be a good time to quickly jot down some notes about going the other way: replacing Raspbian with Ubuntu on Raspberry Pi.

When I started building Sawppy in early 2018, I was already thinking ahead to turning Sawppy from a remote-controlled toy to an autonomous robot. Which meant a quick survey to the state of ROS. At the time, ROS Kinetic was the latest LTS release, targeted for Ubuntu 16.

Unfortunately the official release of Ubuntu 16 did not include an armhf build suitable for running on a Raspberry Pi. Some people would build their own ROS from source code to make it run on Raspbian, I took one attempt and the build errors took more time to understand and resolve than I wanted to spend. I then chose the less difficult path of finding a derived released of Ubuntu 16 that ran on the platform: Ubuntu Mate 16. An afternoon’s worth of testing verified basic ROS Kinetic capability, and I set it aside for revisiting later.

Later on in 2018, Ubuntu 18 was released, followed by ROS Melodic matching that platform. By then support for running Debian (& deriviatives) on armhf had migrated to Ubuntu, and they released both the snap-based Ubuntu Core and Ubuntu ‘classic’ for Raspberry Pi. These are minimalist server images, but desktop UI components can be installed if needed. Information to do so can be found on Ubuntu wiki but obviously UI is not a priority when I’m looking at robot brains. Besides, if I wanted an UI, Ubuntu Mate 18 is still available as well. For Ubuntu 20 released this year, the same choices continue to be offered, which should match well with ROS Noetic.

I don’t know how relevant this is yet for ROS on a Raspberry Pi, but I noticed not only are 32-bit armhf binaries available, so are 64-bit arm64 binaries. Raspberry Pi 3 and 4 have CPU capable of running arm64 code, but Raspbian has remained 32-bit for compatibility with existing Pi software and with low-end devices like the Raspberry Pi Zero incapable of arm64. More than just an ability to address more memory, moving to arm64 instruction set was also a chance to break from some inconvenient bits of architectural legacy which in turn allowed better arm64 performance. Though the performances increase are minor as applied to a Raspberry Pi, ROS releases include precompiled arm64 binaries so the biggest barrier to entry has already been removed and might be worth a look.

Debian with Raspberry Pi Desktop on HP Mini (110-1134CL) and Dell Latitude X1

I went hunting for a lightweight Linux distribution for old computers. With a CPU running at about 1 GHz and 1GB of RAM, the HP Mini (110-1134CL) I had on hand was the approximate league of a modern Raspberry Pi. I wished for something like Debian-based Raspbian and was delighted to find that the Raspberry Pi foundation does release a Debian distribution for x86 that is a counterpart to Raspbian. This meant much of my knowledge about working with Raspbian on a Raspberry Pi could be applied.

Obviously all the work specific to Pi hardware are absent, such as video playback hardware acceleration and the GPIO pins. Still, I think I’m in better shape here than in many other lightweight Linux distributions, because I believe the Debian roots meant I can draw from the extensive library of drivers.

Installing on the HP Mini (110-1134CL) the installer reminded me of this fact by informing me I would need ucode15.fw. I thought I would have to install it manually but by the time installation completed and I got to Raspberry Pi desktop, WiFi was working. I guess installation was taken care of for me! A huge plus in favor of beginner friendliness of this distribution.

Generally speaking, it worked well on this HP Mini, feeling more responsive than Ubuntu Mate on the same machine. It is still no speed demon, but at least it is no longer an exercise in frustration. My general impression of user experience is on par with a Raspberry Pi 3 but with the notable exception of video playback: lacking the specially tailored hardware accelerated video engine, it can only consistently play YouTube videos at 480p. Trying to run 720p (most closely matching the screen resolution) dropped a lot of frames. This is a downside as so many instructional videos are online now, but 480p should still be enough to get the point across.

Encouraged by this result, I prepared to install on my Dell Latitude X1. Before I erased Ubuntu Mate, though, I wanted to get some objective numbers. I measured Ubuntu Mate boot on the Latitude X1, and the time from power button to desktop ready for user interaction was 2 minutes 37 seconds.

Installing on the Latitude X1 encountered similar driver issues, this time with ipw2200-bss.fw. Again, after informing me, the installer took care of installing it and setting it up without requiring any action from me. And once it was up and running I measured it took only 1 minute 26 seconds. This operating system is ready for user input in almost half the time of Ubuntu Mate.

Repeating the measurement, I found that the younger HP Mini had the performance edge, taking just 58 seconds to go from power button to desktop ready. Both of these numbers are impressive considering both are running mechanical hard drives and not modern flash storage.

With these impressive results, Debian with Raspberry Pi desktop has now become my go-to operating system for computers with old 32-bit Intel CPUs.

Debian with Raspberry Pi Desktop Promising For Old Computers

During my first pass evaluation of a HP Mini (110-1134CL) I tried a few modern graphical operating system options and failed to find anything satisfactory. Ubuntu Mate is designed to be a lighter weight alternative to mainline Ubuntu, but it still felt sluggish. Chrome OS (available as Neverware CloudReady) now only supports 64-bit CPUs, which excluded old 32-bit machines.

It works fine as a text-only command line machine, but that seems like a shame as it has a perfectly operable screen and video subsystem. All it needs is a Linux distribution even lighter weight than Ubuntu Mate. I’m sure there are many options out there — historically there has never been a shortage of options for Linux distributions, and websites like this one help sort through options.

But I’d rather not learn yet another Linux distribution. I’m already juggling through more than I strictly wanted, plus some time in FreeBSD as part of my FreeNAS explorations. If only there was a Linux variant that I’m already familiar with, optimized for minimalist low end hardware.

The poster child for minimalist low end hardware is the Raspberry Pi, which is so minimalist it doesn’t even have a power switch. Raspbian, their Debian-derived Linux distribution, has been cut down so it runs on Pi hardware less powerful than the cell phones we’re carrying around nowadays. What if someone took that work and put it in a distribution I can run on old x86 computers? At 1GB of RAM and 1GHz CPU, the hardware spec of a HP Mini is quite similar to a Raspberry Pi.

An online search quickly found that such a thing exists. Not only had “someone” done the work, that “someone” is Raspberry Pi foundation itself. This was the result of someone at the foundation thinking of the exact same “What if….?”question, but they thought of it a few years earlier and had the resources to make it happen.

Thus old computers with 32-bit Intel CPU have the option of running what they’re currently calling Debian with Raspberry Pi Desktop. A beginner-friendly super lightweight variant of Debian with almost all of the software packages that come pre-installed on Raspbian. Only Wolfram Mathematica and Minecraft are missing due to licensing. It all sounds very promising. Time to try it on some old 32-bit machines and see how they run.

Samsung 500T Now Runs On Solar Power

I wanted to have a screen in my house displaying current location of the international space station. I love ISS-Above but didn’t want to dedicate a Raspberry Pi and screen, I wanted to use something in my pile of retired electronics instead. I found ESA’s HTML-based ISS tracker, tested it on various devices from my pile, and decided the Samsung 500T would be the best one to use for this project.

One of the first device I tried was a HP Mini (110-1134CL) and I measured its power consumption while running ESA’s tracker. I calculated my electric bill impact to keep such a display going 24×7 would be between one and two dollars a month. This was acceptable and a tablet would cost even less, but what if I could drop the electric bill impact all the way to zero?

Reading the label on Samsung 500T’s AC power adapter I saw its output is listed at 12V DC. The hardware is unlikely to run on 12V directly, since it also has to run on batteries when not plugged in. It is very likely to have internal voltage regulators which should tolerate some variation of voltage levels around 12V. The proper way to test this hypothesis would be to find a plug that matches the AC adapter and try powering the tablet from my bench power supply. But I chose the more expedient path of beheading the AC adapter instead and rewiring the severed plug.

A quick test confirmed the tablet does not immediately go up in flames when given input voltage up to 14.4V, the maximum for lead-acid batteries. Whether this is bad for the device long term I will find out via experience, as the tablet is now wired up to my solar powered battery array.

This simple arrangement is constantly keeping tablet batteries full by pulling from solar battery. This is not quite optimal, so a future project to come will be to modify the system so it charges from solar during the day and runs on its own internal battery at night. But for now I have an around-the-clock display of current ISS location, and doing so without consuming any electricity from the power grid

ESA ISS Tracker on Nexus 5

When I tried a Nokia Lumia 520 to see if I could use it as ESA ISS Tracker display, I found its screen couldn’t quite manage. Displaying the entire map in a clear and legible way requires more than the 800×480 resolution of a Lumia 520’s screen. Which led to the next experiment: dust off an old Nexus 5.

Nexus 5 Android support was discontinued several releases ago, but when new it was quite a compelling device. One of the signature features was a full HD 1920×1080 resolution screen packed into just five inches of diagonal length. And given Google’s track record of mobile Chrome browser, I was confident it would be capable of rendering ESA’s HTML ISS tracker.

Unfortunately it proved to be even less suitable than the Lumia 520, due to the lack of hardware navigation buttons. This meant the Android navigation bar is always on screen, obscuring part of the map. This was similar to how a Kindle behaves, except the Kindle bar is across the bottom while the phone is over on the right.

Nexus 5 sleep timeouts

Another problem shared with the Kindle was the inability to keep the screen on. Screen inactivity sleep timeout could be set anywhere from 15 seconds to 30 minutes, but there isn’t a “Never” option like there is on Windows tablets or Windows Phone. It seems to be a persistent trend in Android devices, which is reasonable for portable personal electronics but annoying when I want to repurpose one as an around-the-clock status display. Android being Android, there’s probably a way around that limitation, but that’s not a very interesting project right now when I already have more cooperative devices at my disposal.

ESA ISS Tracker on Nokia Lumia 520

While the unfortunate Samsung 500T will be dropped from Windows 10 support in 2023, I don’t need to wait that long for a Microsoft end-of-life product. I have several old Windows Phone 8 devices on hand, and they’ve already ventured beyond the bounds of supported systems which is bad for security if I wanted use these devices for general internet activities. But if I have only a specific web property in mind that I trust to be safe, then all I care about is if it works. ESA’s online HTML ISS Tracker fits this bill.

The version of Internet Explorer built into Windows Phone 8 is far more compatible with web than IE of old, though it still had enough incomplete/missing features to make its web experience a little bumpy. It’s fine for most sites and a quick test on a Nokia Lumia 520 proved that the ESA tracker is one of them.

Since this phone had hardware navigation buttons, there was no need to keep a navigation bar on screen as the Amazon Kindle did. This allowed the ISS tracker to actually have the full screen as intended. The is one cosmetic problem: the map occupied top part of the screen leaving a little black bar at the bottom instead of vertically centered. But that’s a tiny nit to pick.

I could tell this the phone never to turn off the screen even after some period of inactivity, better than I could with my Kindle. The phone should be able to run indefinitely on USB power making it suitable for an around-the-clock display. The only thing I can gripe about is screen resolution. The 800×480 screen of this Windows Phone is just a little too low resolution for all the ISS tracking details to be clearly legible. I think a HTML-based status display will be a promising way to reuse obsolete Windows Phone hardware, but maybe a different project preferably with lower information density. This shortcoming of the Lumia 520 motivated me to repeat the same experiment on a Google Nexus 5, another phone that has fallen out of support.

Inspiration From Droids of Star Wars

Today is the fourth day of the month of May, which has grown into “Star Wars day” due to “May the Fourth” sounding like that film’s popular parting line “may the Force be with you.” A quick search confirmed I’ve never explicitly said anything about Star Wars on this blog and that should be corrected.

By the time I saw Star Wars, I had already been exposed to popular science fiction concepts like space travel, interstellar commerce, and gigantic super-weapons. And the idea of a cult that promises to make their followers more special than regular people… we certainly didn’t need science fiction for that. So none of those aspects of Star Wars were especially notable. What left a lasting impression was R2-D2.

R2-D2 had its own expression of duty and loyalty. Companion to humans, and a Swiss Army knife on wheels. A character that managed to convey personality without words or a face. R2-D2 was the most novel and compelling character for me in the film. I wouldn’t go far as to say R2-D2 changed the path of my life, but there has definitely been an influence. More than once I’ve thought of “does this help me get closer to building my own R2” when deciding what to study or where to focus.

I was happy when I discovered there’s an entire community of people who also loved the astromech droid and banded together to build their own. But that turned to disappointment when I realized the dominant approach in that community was focused on the physical form. Almost all of these were remote-controlled robots under strict control of a nearby human puppeteer, and little effort was put into actually building a capable and autonomous loyal teammate.

I can’t criticize overly much, as my own robots have yet to gain any sort of autonomy, but that is still the ultimate long-term goal. I love the characters of R2-D2 and the follow-on BB-8 introduced in the newest trilogy. Not in their literal shape, but in the positive role they imagined for our lives. This distinction is sometimes confusing to others… but it’s crystal clear to me.

Oh, I thought you loved Star Wars.

Star Wars is fine, but what I actually love are the droids.

I still hope the idea becomes reality in my lifetime.

Samsung 500T Disappointments

I pulled out my old Samsung 500T to see if it could run ESA’s ISS tracker. It could, and quite well, so I think the role might be the best use of this machine. Because it has proven to be a huge disappointment in so many other ways.

I knew of the machine when it launched alongside Windows 8. This was when Microsoft also launched the original ARM-powered Surface tablet to demonstrate what’s possible by using ARM chips: look at how thin and light they are! Samsung & friends launched the 500T as counterpoint: just as thin and light as the Windows RT tablets, but with an Intel CPU for full x86 compatibility. Judging by the spec sheet, it was a spectacular device to undercut and humiliate the “Windows on ARM made thin and light possible” story.

But that’s only on the spec sheet and not on the price tag. The 500T was expensive and Surface tablets sold for far less. Due to that fact, I didn’t get my 500T until much later when it showed up as a secondhand refurbished unit on Woot. When it arrived, I was sure there was something wrong with the machine. Maybe it somehow slipped past testing in refurbishment? It was completely unusable, taking several minutes to boot and user commands took many seconds (5-10) to respond or were ignored entirely. I went online and found a firmware update, which took all night to apply and upgraded performance from “disastrous” to “merely horrible”.

The screen was another cool feature that didn’t panned out. Not just a touchscreen for fingers, it was also a pen digitizer. Compatible with passive Wacom stylus used by the much thicker Surface Pro tablet, the 500T also had a tiny stylus holder built in. It held the promise to be a digital sketchpad with pressure sensitivity making it superior to a contemporary iPad. But slow system response killed that dream. Who wants to sketch on a pad when strokes don’t show up until a few seconds after we draw it?

Judging by Windows Task Manager, this device’s major implementation flaw was its eMMC flash storage, constantly showing 100% activity. The Atom CPU was not exactly a stellar performer, but it wasn’t the reason for delay as the 500T was constantly waiting to read from or write to storage. Generally ruining user experience across the board.

Not to let Intel entirely off the hook, though, as its Atom Z2760 CPU turned out to be a long term liability as well. This CPU was part of Intel’s Clover Trail family, and they had problems running Windows 10 features newly introduced in 2016. Intel had discontinued that line and declined to do anything about it, so Microsoft blocked Clover Trail devices from advancing beyond Windows 10 build 1607. They will still receive security fixes until January 2023, but features are stuck at July 2016 levels forever.

All of the above are things that I might be able to overlook as unfortunate result of things outside Samsung’s control. The eMMC storage might have performed well when new but degraded with time as solid state storage sometimes do. (The TRIM command could help, but they had to make use of it.) And Samsung had no way of knowing Intel would just abandon Clover Trail.

But let’s talk about what Samsung have chosen to install on the machine. As is typical of machines around that age, there was the usual useless bucket of trials and discount offers. There are also Samsung features that duplicate existing Windows functionality, others thinly veiled advertisement for Samsung products, and more. The worst part? I could not get rid of them. I thought they would be gone once I wiped and installed Windows 10, but they were bundled with critical device drivers so I had no choice but to reinstall them as well. Holding device drivers hostage to force users to accept unrelated software is consistent with Samsung’s anti-user behavior I saw across the board.

The image at the top of this post is just one example. SWMAgent.exe appears to be some sort of Samsung software update engine (What’s wrong with Windows Update?) and it asks for elevation. If the user declines to grant elevated privileges, the software is supposed to respect that choice and go away. But not Samsung! We see a black border visible around that dialog box, which might look strange at first glance. Windows 10 adds a subtle dark shadow to dialog boxes, why this ugly black thing? It is because we’re not looking at a single SWMAgent.exe dialog box, but a huge stack of of them. Each popping on top of the last, and another one added every minute or so. The thick black border is a result of that subtle dark shading stacked deep and combining, because Samsung would not take no for an answer.

I don’t need that in my life. The upside of this machine being disappointing was that I had no motivation to put up with it. Into the unused bin it went, and I haven’t bought a Samsung computer since.

ESA ISS Tracker on Samsung 500T

Setting aside the HP Stream 7 as unsuitable for my current project, we reach the final piece of x86 Windows hardware in my pile of unused devices: the Samsung 500T. I guess 500T was a shorthand for its full designation XE500T1C, though I don’t think it made the name roll off the tongue much easier.

This device has a 11.6 inch diagonal touchscreen. It was designed for Windows 8 and launched at around the same time. Its primary focus is on tablet workloads, but can become a convertible tablet/laptop like the HP Split X2 with purchase of an optional keyboard base. Since the keyboard is optional, the 500T has more peripherals packed along its edges. Not just the microSD expansion slot like the HP but also a full-size type A USB and micro HDMI connectors. HP delegated the latter tasks to its included base, which has two type A USB ports and a full sized HDMI connector.

As a piece of Windows 8 hardware like HP Split X2 and HP Stream 7, the 500T has a Windows license in embedded hardware. Thus I was also able to install Windows 10 erasing the existing installation of Windows 8 which was protected by a password I no longer remember. Once device drivers were installed, all features functioned as expected including the ability to run on plug-in power and charge its battery.

That capability was inexplicably nonfunctional in my HP Stream 7. Which meant unlike the HP Stream 7, I could run this display continuously on wired power around the clock. And showing the ESA HTML live space station tracker might be the best way to make use of this hardware. It would be a better end than collecting dust, as my past experience of this tablet has failed to live up to its potential and generally soured me on buying any more computers from Samsung.

HP Stream 7 Hardware Internals

I opened up my HP Stream 7 because I wanted to see if I could run it without the battery. The answer is no, but since I had it open anyway it is an opportunity to look over the mechanical design of this little tablet. The general electrical architecture is not surprising, similar to most tablets majority of interior volume was allocated to the battery and a PCB smaller than the battery held most of the electronics.

The mechanical engineering, however, showed evidence of more attention than I would have expected in an entry level design that must have been designed for cost. The rearmost removable plate to access microSD slot was nothing special, but as soon as I started looking at the next layer I was impressed by how rigid it was with only a few clips and screws. This attention to mechanical design carried across a few other elements.

HP Stream 7 05 reinforcement plate

This metal plate had two of the enclosure screws dedicated to holding it in place. This plate is immediately adjacent to the micro USB power port and the headphone jack. It reinforces the part of the PCB most likely to see mechanical stress, reducing the chances that a clumsy user would tear out these plugs by accident. Unfortunately while the mechanical engineers did great work, somebody dropped the ball on the electrical front. The headphone jack is so noisy as to be unusable, a trait highlighted in reviews so I know it’s not just this unit.HP Stream 7 06 side switches

For the side buttons, I had expected to see sideways switches on the main PCB. I’ve seen those small surface mount buttons before and they are at risk of breaking if the mechanical design doesn’t redirect stress elsewhere. But they are cheap, so we keep seeing them, and they keep breaking off in poorly designed devices. But there’s no such cost-cutting shortcut for this stout tablet. Its buttons are on a separate PCB mounted such that it can take the force face-on instead of letting the force shear off a sideways switch. This adds parts count, and adds steps to assembly, which adds cost, in order to give us more durable buttons. I appreciate it.

HP Stream 7 07 solder and pads why

Behind the switch is this puzzling field of copper pads and solder. Pads and solder like this are usually for surface mount electronics components, but this large field is completely devoid of hardware. I have no idea why this is here or what it does.

HP Stream 7 08 flash sound touch display cable

Lower down we see a SK hynix chip with “NAND” label, presumably the onboard flash memory storage. Adjacent to that chip is the microSD slot where the user can add more storage. Adjacent to those chips I see the crab I associate with RealTek audio chips. Two flexible PCBs round out the bottom. One of these is probably for touch and the other for display.

HP Stream 7 09 speaker

At the very bottom, a small speaker that is actually quite sizable for such a tiny tablet, but there are fundamental handicaps to sound quality at such sizes. I’m thankful for the speaker, but I would have much rather have had a better headphone jack.

Overall I feel the mechanical design on this tiny tablet is pretty good. Too bad its electrical and computational performance isn’t up to the mechanical design. And after this little detour through the world of hardware design, I return to trying the ESA ISS Tracker on other machines. Next on the list: Samsung 500T.

HP Stream 7 Battery Disconnect Test

I dusted off my HP Stream 7 tablet to see if it might be suitable for an always-on status display. I encountered some battery power management issues and wanted to see if I could try running it without a battery. Every Windows x86 laptop I’ve ever owned was happy to run without battery power and since my current intent is for a wired 24×7 display screen, I didn’t need the battery anyway.

HP Stream 7 00 back plate intact

This experiment was made possible by the design of the device. Relative to almost every other piece of modern portable electronics, the HP Stream 7 is easy to open up. The back plate can be opened without tools, just follow the gap they designed and start prying plastic clips apart.

HP Stream 7 01 back plate removed

This was how users could access its microSD slot for adding more storage space. And given how the battery is clearly visible when the back is removed, I thought it was also to enable easy battery replacement. My assumption was wrong! The battery appears to be glued in place and WARNING: BATTERY IS NOT REMOVABLE printed on the battery. Curiously that was printed with a dot matrix printer, implying this specific battery is not always non-removable, perhaps it is removable from another device but that won’t help us here today anyway so let’s move on.

HP Stream 7 02 bashed corner

I don’t remember ever dropping this tablet, but one corner tells a tale of my neglect.

HP Stream 7 03 inner plate removed

If I want to try running this device without battery, I will need to access its battery connector which is hidden underneath the next piece of plastic. That piece is fastened quite well by a large number of plastic clips, backed up by small screws. Together they created a pretty durable enclosure for this tablet while still being removable. There was nothing tricky about opening up this device. Once the second back plate was removed, the battery connector was accessible.

HP Stream 7 04 battery is not removable

Once exposed the connector easily popped free. I pressed the power button and… nothing. Unlike laptops, this device refuses to run without a battery. This makes it less useful for the current project. Nevertheless, such ease of access to durable internals has raised my opinion of this tablet. And since I had it open, I might as well look around a little more.

HP Stream 7 Power Problems

I wanted to see if I can employ my unused HP Stream 7 as an International Space Station tracker at home, displaying ESA’s HTML application. The software side looks promising, but I ran into problems on the hardware side. Specifically, power management on this little tablet currently seems to be broken.

The first hint something was awry is the battery runtime remaining estimate. It is unrealistically optimistic as shown in the screen image above: 46% battery may run this little tablet for several hours, but there’s no way it would last 4 days 4 hours. At first I didn’t think it was a big deal. Battery-powered devices that I’ve dusted off would frequently give wildly inaccurate initial readings on battery. It is common for power management module to require a few charge-discharge cycles to re-calibrate.

In the case of my tablet, a few battery cycles did not help. Battery estimates remained wildly inaccurate after multiple cycles. But I was willing to ignore that estimate, since battery life is not a concern in a project that intends to run tethered to power around the clock. The bigger problem was the tablet’s behavior when plugged in.

HP Stream 7 plugged in not charging

Once power is plugged in, the battery life estimate disappears and (plugged in) was added to the description. This is fine, but I had expected to see something about charging the battery and there was nothing. Not “charging”, not “2 hours until full”, not even the occasionally infuriating “not charging”. There is a complete lack of information about charging in any form.

Still I wasn’t worried: if the tablet wants to run off plug-in power and not charge the battery, that’s fine by me. In fact I am happy to leave the battery at around 50% charge, as that is the healthiest level for long term storage of a lithium chemistry battery. But that’s not the case, either: the tablet will run mostly on plug-in power, but still slowly drain the battery until it was near empty, at which time the tablet would power down.

Only after shutting down did this tablet begin to charge its battery. Now I am worried. If I can’t run this tablet on plug-in power alone, requiring a battery that can’t be charged while it is turned on, that combination would make it impossible to build an around-the-clock ISS tracker display.

What I wanted to do next was to poke around with the hardware of this tablet and see if I can run it without the battery. Fortunately, unlikely most modern compact electronics, the HP Stream 7 can be opened up for a look.

ESA ISS Tracker on HP Stream 7

After I found that Amazon Fire HD 7 tablet was unsuitable for an always-on screen to display ESA’s HTML live tracker for the International Space Station, I moved on to the next piece of hardware in my inactive pile: a HP Stream 7. This tablet was an effort by Microsoft to prove that they would not cede the entry-level tablet market to Android. In hindsight we now know that effort did not pan out.

But at the time, it was an intriguing product as it ran Windows 10 on an Intel Atom processor. This overcame the lack of x86 application compatibility of the previous entry level Windows tablet, which ran Windows RT on an ARM processor. It was difficult to see how an expensive device with a from-scratch application ecosystem could compete with Android tablets, and indeed Windows RT was eventually withdrawn.

Back to this x86-based tablet: small and compact, with a screen measuring 7″ diagonally that gave it its name, it launched at $120 which was unheard of for Windows machines. Discounts down to $80 (when I bought it) made it cheaper than a standalone license of Windows software. Buying it meant I got a Windows license and basic hardware to run it.

But while nobody expected it to be a speed demon, its performance was nevertheless disappointing. At best, it was merely on par with similarly priced Android tablets. Sure we could run standard x86 Windows applications… but would we want to? Trying to run Windows apps not designed with a tablet in mind was a pretty miserable experience, worse than an entry level PC. Though to be fair, it is impossible to buy an entry level PC for $120 never mind $80.

The best I can say about this tablet was that it performed better than the far more expensive Samsung 500T (more on that later.) And with a Windows license embedded in hardware, I was able to erase its original Windows 8 operating system (locked with a password I no longer recall) and clean install Windows 10. It had no problems updating itself to the current version (1909) of Windows 10. The built-in Edge browser easily rendered ESA ISS tracker, and unlike the Kindle I could set screen timeout to “never”.

That’s great news, but then I ran into some problems with power management components that would interfere with around-the-clock operation.

ESA ISS Tracker on Kindle Fire HD 7 (9th Gen)

I wanted to play with old PCs and that’s why I tried ESA’s ISS Tracker on a HP Mini and Dell Latitude X1. But if I’m being honest, the job of a dedicated display is better suited to devices like tablets. They are designed for information consumption and are not hampered by the overhead of input devices like keyboards. I was not willing to dedicate my iPad to this task: it is too useful for other things. But I do have a pile of older devices that haven’t lived up to their promise.

Top of this pile (meaning most recent) is an Amazon Kindle Fire HD 7 tablet 9th generation (*) purchased during holiday sale for a significant discount. If there isn’t a sale today, wait a few weeks and another will be along shortly. I ended up paying roughly 20% of what I paid for my iPad, and I had been curious how it would perform. The verdict was that it had too many annoyances to be useful and I ended up not leaving it collecting dust. At 20% of the price with 0% of utility, it was not a win.

But maybe I could dedicate its screen for a live ISS tracker? I brought up Silk web browser and launched the ESA site. Switching to full screen mode unveiled a problem: Kindle never removes its device navigation buttons from the bottom of the screen. The triangle/circle/square obscures part of ISS tracker’s display.

I wondered if this behavior applied to native Kindle apps as it did full screen web pages, so I searched through the Amazon Kindle app store for an ISS tracker and found ISSLive (*) for experimentation. The answer: yes, the navigation bar is overlaid on top of native applications just as it did on web pages.

Kindle Fire HD 7 running ISSLive

But that was only visually annoying and not an outright deal breaker. That would be Kindle’s sleep behavior. There is no option to keep the screen display active. The user can choose from one of several time duration for the tablet to wait before it turns off the display and goes to sleep, but there is no “Never go to sleep” option.

Kindle Fire HD 7 Always Sleeps

The Kindle Fire HD 7 will not be suitable as a dedicated ISS tracker screen, so I’m moving on to the next device in the unused pile for investigation: a HP Stream 7.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

ESA ISS Tracker on Dell Latitude X1

My failed effort at an ISS Tracker web kiosk reminded me of my previous failure trying to get Ubuntu Core web kiosk up and running on old hardware. That computer, a Dell Latitude X1, was also very sluggish running modern Ubuntu Mate interactively when I had tried it. I was curious how it would compare with the HP Mini.

The HP Mini has the advantage of age: it is roughly ten years old, whereas the X1 is around fifteen years old. When it comes to computers, an age difference of five years is a huge gulf spanning multiple hardware generations. However, the X1 launched as a top of the line premium machine for people who were willing to pay for a thin and light machine. Hence it was designed under very different criteria than the HP Mini despite similarity in form factor.

As one example: the HP Mini housed a commodity 2.5″ laptop hard drive, but the Dell Latitude X1 used a much smaller form factor hard drive that I have not seen before or since. Given its smaller market and lower volume, I think it is fair to assume the smaller hard drive comes at a significant price premium in exchange for reduction of a few cubic centimeters in volume and grams of weight.

Installing Ubuntu Mate 18.04 on the X1, I confirmed it is still quite sluggish by modern standards. However, this is a comparison test and the Dell X1 surprised me by feeling more responsive than the five years younger HP Mini. Given that they both use spinning platter hard drives and had 1GB of RAM, I thought the difference is probably due to their CPU. The Latitude X1 had an ULV (ultra low voltage) Pentium M 744 processor, which was a premium product showcasing the most processing power Intel can deliver while sipping gently on battery power. In comparison the HP Mini had an Atom processor, an entry-level product optimized for cost. Looking at their spec sheet comparison shows how closely an entry level CPU matches up to a premium CPU from five years earlier, but the Atom had only one quarter of the CPU cache and I think that was a decisive difference.

Despite its constrained cache, the Atom had two cores and thermal design power (TDP) of just 2.5W. In contrast the Pentium M 733 ULV had only a single core and TDP of 5W. Twice the cores, half the electrical power, the younger CPU far more power efficient. And it’s not just the CPU, either, it’s the whole machine. Whereas the HP Mini 110 only needed 7.5W to display ESA ISS Tracker, the Latitude X1 reports drawing more than double that. A little over 17W, according to upower. An aged battery, which has degraded to 43% of its original capacity, could only support that for about 40 minutes.

Device: /org/freedesktop/UPower/devices/battery_BAT0
native-path: BAT0
vendor: Sanyo
model: DELL T61376
serial: 161
power supply: yes
updated: Thu 23 Apr 2020 06:19:06 PM PDT (69 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 11.4663 Wh
energy-empty: 0 Wh
energy-full: 11.4663 Wh
energy-full-design: 26.64 Wh
energy-rate: 17.2605 W
voltage: 12.474 V
time to empty: 39.9 minutes
percentage: 100%
capacity: 43.0417%
technology: lithium-ion
icon-name: 'battery-full-symbolic'
History (rate):
1587691145 17.261 discharging

Putting a computer to work showing the ESA tracker is only using its display. It doesn’t involve the keyboard. Such information consumption tasks are performed just as well by touchscreen devices, and I have a few to try. Starting with an Amazon Kindle Fire HD 7.

Aborted Ubuntu Core Web Kiosk Adventure with HP Mini (110-1134CL)

I haven’t figured out how to get WiFi working on this HP Mini (110-1134CL) under Ubuntu Core 18, but that’s not the main objective of my current investigation so I’m moving on with wired Ethernet. What I wanted to do was to build an Ubuntu Core powered web kiosk appliance to show the ESA Live ISS Tracker web page. I thought this would be a pretty easy exercise, all I had to do is follow the steps I did earlier to build an kiosk appliance running on a Dell Inspiron 11 3180.

Nope! The tutorial I followed earlier is gone, its URL https://tutorials.ubuntu.com/tutorial/ubuntu-web-kiosk now forwards to https://ubuntu.com/tutorials/electron-kiosk which is a tutorial to build an ElectronJS application into a snap. I don’t have the ESA ISS Tracker in an ElectronJS app (yet) so I poked around trying to figure out what happened to the tutorial.

Both the earlier Chromium tutorial and the current Electron tutorial are built on top of the Mir Kiosk shell. I found a good collection of information on this page proclaiming itself “Configuring Mir Kiosk, a Masterclass.” That thread did mention the chromium-mir-kiosk snap used in the now-gone tutorial, but that no longer seems to run. I only get a blank screen instead of the earlier basic web kiosk.

Apparently that snap was always intended to be a short term tech demo and there was no effort to maintain it to keep it updated with latest versions of systems. This thread claimed replacement is wpe-webkit-mir-kiosk, but there’s a problem for my situation: there’s no 32-bit (i386) snap that would run on this old HP Mini’s CPU. They only had pre-built binaries for 64-bit (amd64) processors

It appears if I want to put the ESA ISS Tracker on this HP Mini as an Ubuntu Core appliance, I will need to learn how to build it into an ElectronJS application and compile a binary that would run on i386 architecture. I’m not sure how much work that will be yet, but if I put it up on Snap store I’m sure there are people who would appreciate it.

Which occurred to me… what if it is up there already? I had forgotten to check the easy thing first. I searched on the store and unfortunately didn’t see anyone who has done the work I specifically had in mind. I did find a snap termtrack that tracks ISS as well as other satellites, but there were two problems: First, it is a terminal (text mode) application so isn’t as graphically interesting. And second, it doesn’t have an i386 binary available, either. Darn.

$ snap install termtrack
error: snap "termtrack" is not available on stable for this architecture (i386) but exists on other architectures (amd64).

Oh well, so much for a low effort ESA HTML ISS tracker built on Ubuntu Core. Which reminded me to look at how it works on my other Ubuntu Core kiosk failure: the Dell Latitude X1.

Ubuntu Core WiFi Woes on HP Mini (110-1134CL)

Last time I played with Ubuntu Core, I followed through their tutorial for building a simple minimalist web kiosk whose state is wiped clean upon every reboot. At the time I had no idea why I would ever want to build such a thing, but now I have my answer: build an “appliance” for displaying ESA’s HTML Live International Space Station Tracker.

I had put Ubuntu Server and Ubuntu Core on this HP Mini (110-1134CL) earlier for a quick look to verify it works well for command line based usage. One thing I didn’t notice earlier was the fact Ubuntu Core only recognized the wired Ethernet port and not the WiFi hardware. It’s nice to have WiFi if I’m want to set up an ISS display away from my wired networking infrastructure.

I saw some red text flash by quickly upon boot. I had to retrieve the message after startup with the journalctl command to see what it complained about.

b43-phy0: Broadcom 4312 WLAN found (core revision 15)
b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1
b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0
b43 ssb0:0: Direct firmware load for b43/ucode15.fw failed with error -2
b43 ssb0:0: Direct firmware load for b43/ucode15.fw failed with error -2
b43 ssb0:0: Direct firmware load for b43-open/ucode15.fw failed with error -2
b43 ssb0:0: Direct firmware load for b43-open/ucode15.fw failed with error -2
b43-phy0 ERROR: Firmware file "b43/ucode15.fw" not found
b43-phy0 ERROR: Firmware file "b43-open/ucode15.fw" not found
b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.

I like error messages that point me to instructions telling me what to do. Unfortunately http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware is no longer a valid URL and returns a HTTP 404 error. Searching the web for combinations of “Broadcom WiFi b43 Linux driver” led me to this forum post by someone asking for help. A helpful response pointed to this Debian support page, and from there to Linux kernel information. Apparently there is a licensing issue, requiring extra steps to install these driver packages. Those extra steps are where I got stuck with Ubuntu Core as it only accepts software modules in the form of snaps.

First we need to identify the exact hardware to see if it is in the b43 or b43legacy package. The command is lspci -nn -d 14e4: but lspci is not part of Ubuntu Core. Flailing, I tried to snap find lspci and came up empty.

If I had been able to determine which hardware I had, I could look it up on this chart which determines if I should sudo apt install firmware-b43-installer or its legacy counterpart sudo apt install firmware-b43legacy-installer. But again Ubuntu Core does not allow installation of software via apt, only via snap.

For the moment I’m stuck on getting WiFi for Ubuntu Core on this HP Mini, but that is not the biggest obstacle: my showstopper is that the tutorial kiosk has gone away.