Micro Sawppy Beta 1 Electronics

The past several posts have described various aspects of Micro Sawppy Beta 1 (MSB1) that are explorations of new ideas for a little rover. Since there were already many new ideas piled onto the little guy, I decided the control electronics and software should step back and reuse known quantities. Even though I don’t intend this to be the final approach, I wanted to reuse existing components here just to keep things from going too wild and confused if the little rover should encounter problems.

Hence the onboard electronics of MSB1 is very close to those used on Sawppy, which was in turn adapted from code written for SGVHAK Rover. Not from the official JPL Open Source Rover instructions, but the hack I hastily slammed together for its world premier at Southern California Linux Expo. Back then we faced the problem of a broken steering gearbox a week ahead of the event, and it would take over a week for replacements to arrive. So while Emily hacked up a way for a full-sized RC servo to handle steering, I hacked up the rover software to add option to control a servo via what I had on hand: the Adafruit PWM/Servo HAT.

Years later, I still have that same HAT on hand and now I have a rover full of micro servos. Putting them together was an obvious thing to try. My software for that servo steering hack turned out to be very easy to adapt for continuous rotation servos powering the wheels. (Only a single bug had to be fixed.)

There was another happy accident: since the SGVHAK rover software already had software provisions for steering trim, it was easy to use that for throttle trim as well. This was useful to compensate for the fact that the converted continuous rotation servos in the six wheels aren’t necessarily centered like they theoretically were. Resistors with identical markings don’t actually offer perfectly equal resistance, and the control circuit of a cheap micro servo isn’t very good about precise voltage measurements anyway. If I didn’t have this software throttle trim control, it might have been much more difficult to get MSB1 up and running.

For power supply I had a small 2-cell Lithium Polymer battery on hand, previously seen on these pages in exploration of a thrift store Neato. Dropping its voltage (8.4V when fully charged) down to something that wouldn’t fry the micro servos was the job of MP1584 buck converters. I had discovered these worked well for powering a Raspberry Pi and one of them is again enlisted into that role. In order to reduce the chances of a power sag causing the Raspberry Pi to reset, I added a second buck converter to give the micro servos an independent power plane. Both buck converters are soldered onto the little prototyping area Adafruit provided on their HAT. Once I had the electronics circuit stack assembled, I could start wiring up all the components.

Goodbye and Good Riddance To This Generation of Hybrid Drives

I have successfully upgraded a HP Pavilion Split X2 (13-r010dx) to use a modern M.2 SATA SSD with the help of an adapter circuit board. The results were stellar and, even though the adapter does not mount inside the computer properly, I have no plans to put the original drive back in. It was a compromised solution of its era and times have moved on.

A little over ten years ago, flash-based solid state drives started edging towards price levels affordable to normal computer buyers. A few bargain basement devices were released, and they were terrible. I had two JMF602-based drives that lasted through their 90-day warranty periods but not much beyond that. The big breakthrough in affordable and durable performance is credited to the Intel X25-M, but the capacity was quite small. SSD performance is something that I had to experience to be converted to a fan, and it was hard to get non-converts to accept living with 80GB of capacity when we had become accustomed to hundreds of gigabytes.

The compromised solution was the SSD/HDD hybrid drive: there is a magnetic platter hard disk drive, but there is also a small piece of flash memory acting as a small solid-state drive cache. The advertising proclaimed that we would get the capacity of a HDD with all the performance of a SSD. I thought the concept was enticing, but never actually got one to try.

I’m glad I did not, if this computer’s stock WD5000M21K hybrid drive is representative of the breed. Its performance was absolutely terrible. Maybe modern workloads overwhelmed its meager 8GB of flash cache. Maybe years of use has worn out the flash and there was no caching anymore. Whatever the reason, its performance was no better than a HDD, definitely nowhere near the performance of a real solid state drive.

Now solid state drives with plenty of elbow room are quite affordable, giving old computers a new lease on life. The hinderance of oddball connectors like the SFF-8784 become just a speed bump with help of adapters, so we don’t need to put up with the compromises of SSD/HDD hybrid drives anymore.

No Good SSD Adapter Mounting Option

Upgrading to a SATA SSD was a hugely successful transformational upgrade for this old HP Pavilion Split X2 (13-r010dx). Physically, it was only a tiny improvement to the problems of heavy weight and it doesn’t nothing to help the low 1366×768 resolution screen, but the computer is now immediately responsive to user input and no longer miserable to use. That is the good news.

The bad news is that Sintech’s SSD adapter didn’t have mounting holes to line up to original mounting brackets. I originally thought I could 3D-print something to adapt its vertical mounting holes to horizonal, a simple rectangular loop should do the trick. Then I took a closer look at the dimensions and realized it’s not so simple.

The circuit board height where the interface plugs into is fixed and that height is in the middle of the screw holes. In order to clear mounting screws I would have to cut into the circuit board, which I’m not prepared to do. I already had to wait for a replacement to be shipped to me once, I didn’t want to ruin a board and have to wait again.

I considered offsetting vertically to clear the screw holes, moving in one direction or the other. But the overall height of this adapter + M.2 socket is barely any thinner than the original hard drive, leaving very little margin to work with. Pushing towards the screen, I could not move far enough to clear the screws. Pushing towards the back, clearing the screws would bump against the back cover.

So no 3D-printed adapter bracket for me. I ended up using double-side tape sold for attaching Raspberry Pi heat sinks, and used that to attach the SSD to the chassis. This solution is not ideal, but I’m not willing to revert to the stock hard drive because it was something better left to the past where it belongs.

HP Split X2 (13-r010dx) Transformed with SSD Upgrade

With a SSD adapter circuit board temporarily held in place with painter’s tape, I powered up this old HP Split X2 (13-r010dx) to see if it’s willing to run on a modern M.2 SSD. The answer is yes — and quite well!

I have a USB flash drive prepared by the Windows Media Creation Tool for installing Windows 10 2004, and I could select it as the boot device by holding down F9 upon power-up. From there it was an uneventful Windows 10 installation, automatically activated by a Windows 8 license embedded in hardware.

Here is the “Before” picture, taken a few minutes after the computer has booted up on the original WD5000M21K hard drive. The computer is completely saturated with Windows startup tasks and it takes a few minutes to even get Task Manager up and running and a screenshot tool. From here we can see we’re doing well on memory, with only half used. The CPU is largely idle. They are all waiting for the disk.

Here is the “After” picture, taken shortly after the computer started up for the first time running Windows 10 freshly installed on the M.2 SSD. Disk overhead has stopped being a constraining factor. The memory is about the same, and now the humble low power Core i3 CPU is the constraining factor as this computer is chewing through information to decide what to download from Windows Update.

Once Windows was up to date, all drivers were automatically installed, and this computer was ready to go. A reboot verified that startup time has gone from several minutes down to less than 30 seconds. Launching and switching between applications are nearly instantaneous. When the meager 4GB RAM starts running low, virtual memory on the SSD is perfectly usable and not the molasses slow torture session it used to be.

The Core i3 might be the low end of the Core line, but it is far faster than an Atom chip of similar vintage. Freed from the shackles of its molasses slow stock HDD, this computer is now perfectly comfortable running up-to-date Windows 10 and modern applications. This SSD upgrade has proven to be a hugely beneficial transformation for this old computer. Which was fantastic! Except for one problem… how do I make sure it doesn’t rattle around inside the machine?

HP Split X2 (13-r010dx) SSD Upgrade: Round 2

I now have a M.2 SATA SSD available for experimentation, mounted on a Sintech ST-NG8784 adapter circuit board that lets me plug a M.2 SSD into a SSF-8784 connector. This unusual slim connector is used by a HP Pavilion Split X2 (13-r010dx) tablet/laptop convertible computer, which foiled an earlier attempt at SSD upgrade. This time I am better prepared.

Here’s the “Before” picture, with the stock SFF-8784 hard drive in the center. From the factory the interior of this device had a lot more tape and foil, including foil completely wrapping the hard drive. They’ve all been pulled off in earlier adventures.

In addition to disconnecting the AC adapter, the connector at the center of the image (with black wires, not white ribbon cable) is for the battery and should be disconnected before working on this machine.

Four screws held the drive in place using some metal brackets, which were in turn mounted to the drive via some screws on the side. Removing them were trivial, but that exposed the next problem: the PCB could match bottom mounting holes, but we need horizontal ones, so there’s no good way to fasten the drive.

I decided not to worry about proper fastening for the moment, because I had no idea if the computer would even accept this drive with adapter. Some temporary painter’s tape is enough to make sure the board doesn’t flop around while I experiment.

Examining Sintech M.2 to SFF-8784 SATA Adapter (ST-NG8784)

It took a second try before I received an adapter card that looked good enough to proceed. The objective of the exercise is to put a common M.2 2280 SATA SSD into an old HP Pavilion Split X2 (13-r010dx) convertible laptop which came with an unusually thin (5mm) spinning platter hard drive in the super rare SFF-8784 form factor. The form factor foiled my first attempt at an SSD upgrade for this computer, but now I have a M.2 SATA SSD available for experimentation and now I have the adapter card I bought (*) for the project.

This card is made and sold by Sintech, which has a product page for this item where I learned it is designated model ST-NG8784. I was fascinated by how simple the adapter is. There are only a few surface mount components and very few traces on the circuit board. C1 and C2 are obviously capacitors, but I’m not sure what U1 is. Searching on “84-33 2012DC” didn’t result in anything enlightening, but by its general shape and arrangement of nearby capacitors I guess it is a voltage regulator.

The M.2 connector has many, many pins but the SFF-8784 plug has significantly fewer, resulting in a superficially simple layout. I guess that makes sense, after all the S in SATA stands for Serial, so it wouldn’t need many pins to do its thing. I count just two differential pairs on top for data. Most of the other connections are either power or ground. But it does highlight the fact there is no active signal conversion on this adapter: this would only work for SATA M.2 SSDs and I would not expect it to work with NVMe M.2 SSDS.

Mechanically, this adapter card has provisions for several of the popular M.2 card lengths. A threaded standoff has been press-fit into the spot corresponding to the longest supported size M.2 2280. If the user has a SATA SSD in one of the shorter form factors, there is a small Ziploc bag with a screw-on standoff to be installed in the appropriate slot. Since my M.2 SATA SSD is in the 2280 format, I did not need the Ziploc bag. I installed my SSD into this adapter and turned attention to the laptop.


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

SSD Upgrade Project Delayed By Shipping Damage

I’ve been aware that the performance of an old HP Pavilion Split X2 (13-r010dx) is constrained by its hard drive to some degree. But when I tried to remove that constraint by upgrading it to a commodity SATA SSD, I found that it did not use the connector type I was familiar with. Rather, it used a much thinner and rarer variant called SFF-8784. Native SFF-8784 drives are expensive due to their low volume, but I found an Amazon vendor selling SFF-8784 adapter circuit boards to use mSATA or M.2 SATA SSDs. I resolved to come back to this project later, when I have a spare M.2 SATA SSD to try.

It is now later. Thanks to some end-of-year sales, my computers received upgrades and the cascade of hand-me-down freed up a M.2 SATA SSD for this experiment. I proceeded to order the M.2 to SFF-8784 adapter board I found earlier (*) eager to see how it might improve the old HP’s responsiveness.

Unfortunately, the first adapter arrived damaged. It was shipped in an anti-static bag and enclosed in a padded envelope. The padding was apparently not enough, because the M.2 connector was crushed out of shape. I doubted it would accept a M.2 SATA SSD and I didn’t want to risk a perfectly functioning SSD to try.

I contacted Sintech and they sent a replacement. When the replacement arrived, I noticed a modification. It was still in an anti-static bag in a padded envelope, but there was the additional padding of a block of pink foam to protect the M.2 connector.

With the help of this pink foam block, the onboard M.2 connector survived shipping and looked good enough for this SSD upgrade project to begin.


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

Raspberry Pi GPIO on Node-RED Needs Raspberry Pi OS

I didn’t manage to get Bluetooth Low Energy (BLE) running in Node-RED on a Windows PC, so experimentation moved on to other hardware platforms. Specifically the hardware hacking darling Raspberry Pi. I knew it was possible because of the number of projects that already existed, plus Node-RED has an instruction page dedicated to Raspberry Pi installation. This would be straightforward… except I intentionally made things difficult for myself.

The twist is that my Raspberry Pi 3 readily available for experimentation was most recently set up to check out ROS on arm64. Which meant it was running Ubuntu 20 for 64-bit Raspberry Pi instead of the default Raspberry Pi OS. (Formerly known as Raspbian.) I was confident all the fundamental parts of Node-RED such as flows and network I/O would continue functioning, which makes it a low-power alternative to running Node-RED on a PC. But the other reason to run Node-RED is to interface with devices via Raspberry Pi’s GPIO pins. I wanted to know how well that would work under arm64 Ubuntu.

And I got my answer: it does not work. It appears whatever means Node-RED employed to access Raspberry Pi GPIO is not available on Ubuntu arm64 builds. I assume it is possible to install and/or port over the components required for such support, but today’s experiment is just to see if it works out of the box and now I know it does not.

31 Aug 20:36:53 - [info] Node-RED version: v1.1.3
31 Aug 20:36:53 - [info] Node.js version: v12.18.3
31 Aug 20:36:53 - [info] Linux 5.4.0-1016-raspi arm64 LE
31 Aug 20:36:54 - [info] Loading palette nodes
/bin/sh: 1: /home/ubuntu/.node-red/node_modules/node-red-node-pi-gpio/testgpio.py: not found
31 Aug 20:36:56 - [warn] rpi-gpio : Raspberry Pi specific node set inactive

Arduino Interface for Mitutoyo SPC Data Port

I started looking for an inexpensive electronic indicator with digital output port, and ended up splurging for a genuine Mitutoyo. Sure it is over five times the cost of the Harbor Freight alternative, but I thought it would be worth the price for two reasons. One: Mitutoyo is known for high quality precision instruments, and two: they are popular enough that the data output port should be documented somewhere online.

The second point turned out to be moot because the data output port was actually documented by pamphlet in the box, no need to go hunting online. But I went online anyway to get a second opinion, and found this project on Instructables. Most of the information matched up, but the wiring pinout specifically did not. Their cable schematic had a few apparent inconsistencies. (Example: one end of the cable had two ground pins and the other end did not.) They also had a “Menu” button that I lacked. These may just be the result of different products, but in any case it is information on the internet to be taken with a grain of salt. I took a meter to my own cable to ensure I have the pinout described by the pamphlet in my own instrument.

Their Arduino code matched the pamphlet description, so I took that code as a starting point. I then released my derivative publicly on GitHub with the following changes:

  • Calculate distance within numeric domain instead of converting to string and back.
  • Decimal point placement with a single math expression instead of a list of six if statements.
  • Their code didn’t output if value is inch or millimeter, I added units.

A limitation of their code (that I did not fix) is a recovery path, should the Arduino falls out of sync. The Mitutoyo protocol was designed with a recovery provision: If the communication gets out of sync, we can sync back up using the opening 0xFFFF. But since there’s no code watching for that situation, if it falls out of sync our code would just be permanently confused until reset by the user.

For debugging I added the capability to output in raw hex. I was going to remove it once I had the distance calculation and decimal point code figured out, but I left it in place as a compile-time parameter just in case that would become handy in the future. Sending just hexadecimal data and skipping conversion to human-readable text would allow faster loops.

Note that this Mitutoyo Statistical Process Control (SPC) protocol has no interactive control — it just reports whatever is on the display. Switching units, switching direction, zeroing, all such functions are done through device buttons.

Once it all appears to work on the prototyping breadboard, I again soldered up a compact version and put it inside a custom 3D printed enclosure.

This image has an empty alt attribute; its file name is mitutoyo-spc-arduino-compact.jpg

Seeed Studio Odyssey X86J4105 Has Good ROS2 Potential

If I were to experiment with upgrading my Sawppy to ROS2 right now, with what I have on hand, I would start by putting Ubuntu ARM64 on a Raspberry Pi 3 for a quick “Hello World”. However, I would also expect to quickly run into limitations of a Pi 3. If I wanted to buy myself a little more headroom, what would I do?

The Pi 4 is an obvious step up from the 3, but if I’m going to spend money, the Seeed Studio Odyssey X86J4105 is a very promising candidate. Unlike the Pi, it has an Intel Celeron processor on board so I can build x86_64 binaries on my desktop machine and copy them straight over. Something I hope to eventually be a painless option for ROS2 cross compilation to ARM, but we’re not there yet.

This board is larger than a Raspberry Pi, but still well within Sawppy’s carrying capacity. It’s also very interesting that they copied the GPIO pin layout from Raspberry Pi, the idea some HATs can just plug right in is very enticing. Although that’s not a capability that would be immediately useful for Sawppy specifically.

The onboard Arduino co-processor is only useful for this application if it can fit within a ROS2 ecosystem, and the good news is that it is based on the SAMD21. Which makes it powerful enough to run micro-ROS, an option not available to the old school ATmega32U4 on the LattePanda boards.

And finally, the electrical power supply requirements are very robot friendly. The spec sheet lists DC input voltage requirement at 12V-19V, implying we can just put 4S LiPo power straight into the barrel jack and onboard voltage regulators will do the rest.

The combination of computing power, I/O, and power flexibility makes this board even more interesting than an Up Board. Definitely something to keep in mind for Sawppy contemplation and maybe I’ll click “Add to Cart” on this nifty little board (*) sometime in the near future.


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

Why I Still Like The 8-Bit Chips

I was sad to see ROS2 seemed to be leaving rosserial behind, which also abandons the simple 8-bit microcontrollers they supported. They may not measure up on the megahertz or the megabyte numbers, but they still had their advantages for quick and simple prototyping.

My favorite part is the fact they tend to require minimal support components, or occasionally none at all. This feature allows me to do simple “deadbug” projects where I solder components directly to the pins of the chip skipping the circuit board. This advantage is directly linked to their disadvantages: modern processors usually require an external clock signal source because it’s hard to build an accurate fast clock on board the chip, in contrast the older and slower chips can make do with on board oscillators because they’re not as dependent on an accurate clock. Similarly, many modern chips require external voltage regulation support because they need to run within a narrow voltage range and the older chips are much more relaxed about it. The PIC16F18345 I occasionally play with can be hooked up directly to a couple of AA batteries (or a single lithium ion cell) and as the battery voltage drops, the chip doesn’t seem to care.

The older simpler chips also tend to be more robust. In addition to tolerating a wider range of voltage input, they also tolerate a large range of current output. Some of the modern controllers’ output pins can’t even sustain 20 milliamps, the standard amount to illuminate a LED. It felt very weird for me to wire up a transistor just to do a LED. In contrast, the PIC16F18345 is specified to support 50 milliamps.

And really, they’re just good simple tools for good simple projects. I was happy to dust off an old PIC program for the hacked-up VFD driver project. When I only needed to flip some pins around, I really don’t need a Swiss army knife of fancy peripherals.

Notes on ROS2 and rosserial

I’m happy to see ROS2 improve over the past several releases, each release more mature and suitable for adoption than the last. Tackling some long standing problems like cross compilation and also new frontiers. I know a lot of my current reservations about ROS2 are on the to-do list, but there’s a fairly significant item that appears to be deliberately absent: rosserial.

In ROS, the rosserial module is the default way of for something simple to communicate with the rest of a ROS robot. It’s been a popular way for robot builders to add small dedicated modules that serve their little niche simply and effectively with only an Arduino or similar 8-bit microcontroller. By following its conventions for translating ROS messages into simple serial byte sequences, robot builders don’t have to constantly reinvent this wheel. However, it is only really applicable when we are in control of both the computer and Arduino end of the communication. When one side is outside of our control — such as the case for LX-16A servos used on Sawppy — we can’t use the rosserial protocol and a custom node has to be created.

But while I couldn’t use rosserial for communication with the servos on my own Sawppy, I’ve seen it deployed for other Sawppy builds in different contexts. Rhys Mainwaring’s Curio rover ROS stack uses rosserial to communicate with its Arduino Mega, and Steve [jetdillo] has just installed a battery voltage monitor that reports via rosserial.

With its proven value to budget robotics, I’m sad to see it’s not currently in the cards for ROS2. Officially, the replacement for rosserial is micro-ROS built on the Micro XRCE-DDS Client. DDS is the standardized communication protocol used by ROS2, and XRCE stands for “eXtremely Resource Constrained Environment.” It’s an admirable goal to keep the protocol running with low resource consumption, but “low” is relative. Micro XRCE-DDS proudly listed its resource requirements as thus:

From the point of view of memory footprint, the latest version of this library has a memory consumption of less than 75 KB of Flash memory and 2.5 KB of RAM for a complete publisher and subscriber application.

If we look at the ATmega328P chip at the heart of a basic Arduino, we see it has 32KB of Flash and 2KB of RAM and that’s just not going to work. A straightforward port of rosserial was aborted due to intrinsic ties to ROS, but that Github issue still sees traffic because people want the thing that does not exist. [UPDATE: Now we have a ROS Discourse discussion thread about it too.]

I found a ros2arduino library built on Micro XRCE DDS, and was eager to see how it managed to fit on a simple ATmega328. Disappointingly, it doesn’t. The “Arduino” in the name referred to newer high end boards like the Arduino MKR ZERO, leaving the humble ATmega328 Arduino boards out in the cold.

As far as I can tell, this is by design. Much as how ROS2 has focused on 64-bit computing platforms over 32-bit CPUs, their “low end microcontroller support” is graduating from old school 8-bit chips to newer designs like the ESP32 and various ARM Cortex flavors such as the STM32 family. Given how those microcontrollers have fallen to single digit dollar amounts of cost, it’s hard to argue for the economic advantage of old 8-bit chips. (The processing power per dollar argument was lost long ago.) So even though the old 8-bit chips still hold some advantages, I can see the reasoning, and have resigned to accept it as the way of the future.

Update on ARM64: ROS2 on Pi

When I last looked at running ROS on a Raspberry Pi robot brain, I noticed Ubuntu now releases images for Raspberry Pi in both 32-bit and 64-bit flavors but I didn’t know of any compelling reason to move to 64-bit. The situation has now changed, especially if considering a move to the future of ROS2.

The update came courtesy of an announcement on ROS Discourse notifying the community that supporting 32-bit ARM builds have become troublesome, and furthermore, telemetry indicated that very few ROS2 robot builders were using 32-bit anyway. Thus the support for that platform is demoted to tier 3 for the current release Foxy Fitzroy.

This was made official on REP 2000 ROS 2 Releases and Target Platforms showing arm32 as a Tier 3 platform. As per that document, tier 3 means:

Tier 3 platforms are those for which community reports indicate that the release is functional. The development team does not run the unit test suite or perform any other tests on platforms in Tier 3. Installation instructions should be available and up-to-date in order for a platform to be listed in this category. Community members may provide assistance with these platforms.

Looking at the history of ROS 2 releases, we can see 64-bit has always been the focus. The first release Ardent Apalone (December 2017) only supported amd64 and arm64. Support for arm32 was only added a year ago for Dashing Diademata (May 2019) and only at tier 2. They kept it at tier 2 for another release Eloquent Elusor (November 2019) but now it is getting dropped to tier 3.

Another contributing factor is the release of Raspberry Pi 4 with 8GB of memory. It exceeded the 4GB limit of 32-bit addressing. This was accompanied by an update to the official Raspberry Pi operating system, renamed from Raspbian to Raspberry Pi OS, is still 32-bit but with mechanisms to allow addressing 8GB of RAM across the operating system even though individual processes are limited to 3GB. The real way forward is to move to a 64-bit operating system, and there’s a beta 64-bit build of Raspberry Pi OS.

Or we can go straight to Ubuntu’s release of 64-bit operating system for Raspberry Pi.

And the final note on ROS2: a bunch of new tutorials have been posted! The barrier for transitioning to ROS2 is continually getting dismantled, one brick at a time. And it’s even getting some new attention in long problematic areas like cross-compilation.

Xbox One Is Part Of Universal Windows Platform

Independent of my interest in learning a new pattern for asynchronous programming, I started reading about Microsoft’s Universal Windows Platform (UWP) because I wanted to see their latest take on dynamic layout concepts. This is something that web designers are familiar with, since their users might be using anything from a small touchscreen phone to a tablet to a laptop to a desktop computer. But I found that UWP had ambitions to scale across an even wider spectrum. On the low end, they wanted to cover IoT devices with small (or even no) screen. On the high end, the ambition surpasses desktop computers with the big screen TV in a living room connected to a Xbox One.

I’m intrigued by the possibility of writing code to run on my Xbox One game console. At the moment I have no idea what I would do with that potential, but just the possibility adds to my motivation to continue exploring UWP. The part that I haven’t figured out is how much of UWP I’m reading on the documentation site is real, what is still coming, and what might have been aspirations fallen by the wayside. The now-defunct Windows Phone was supposed to be part of this spectrum, placing “UWP on phones” in the “fallen by the wayside” category.

There’s more hand-waving than I would like about the design guidelines for scaling UI all the way up to TV sizes. A website spanning the range of phones to computers has a hard enough time reconciling user input via touchscreens versus keyboard and mouse. The UWP range of IoT devices (with possibly no UI) up to an Xbox running UWP on the living room TV (with an Xbox game controller) is a very wide range to cover, and I didn’t find as much guidelines as I had hoped.

Still, it’s a possibility. The most likely way for me to put my UWP education to use is to create some prototypes of interfacing with electronics hardware. I started looking at platforms like UWP from the perspective of machine control. Does that path make sense for a Xbox? Other than the Nintendo R.O.B. there hasn’t been a lot of console-controlled peripherals. Maybe I can have Sawppy join me in a game?

I looked over the UWP Limitations on Xbox page, and I didn’t see USB and serial APIs explicitly listed in the “Doesn’t Work” list. It’s not on the explicit “Does Work” list, either, so investigating this gray limbo zone might be a fun future exercise. For now, though, it’s time to start running hardware I know works.

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.

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.

Key Press Timeline For Entering and Exiting Developer Mode on Toshiba Chromebook 2 (CB35-B3340)

When I got my hands on this Toshiba Chromebook 2 (CB35-B3340) its primary screen was cracked and unreadable. I was happy when I discovered I could use it as a Chromebox by an external HDMI monitor, but I quickly found the limitation of that approach when I tried to switch the device into developer mode: those screens were only visible on the screen I couldn’t read.

Google has published instructions for putting a Chromebook into developer mode, but they weren’t specific enough for use with an unreadable screen. It doesn’t say how many menus are involved, and it doesn’t say how much time to expect between events. Probably because these details vary from device to device and not suitable for a general document.

I looked around online for information from other sources and didn’t find enough to help me navigate the procedure. Most irritating are the sites that say things like: “And from this point just follow the on screen prompts” when the whole point was I couldn’t read those prompts at the time.

Now that I’ve installed a replacement screen, I can see what happens and more importantly, I can now document the information I wished I was able to find several weeks ago. The most surprising part to me was that it took roughly seven minutes to transition into developer mode, but less than a minute to transition out of it. Since all user data are erased in both of these transitions, I’m curious why the times are so different.

In any case, I’ve captured the process on video (embedded below) and here is the timeline for putting a Toshiba Chromebook 2 into developer mode even if the screen is not readable. Times are in (minutes:seconds)

  • Preparation: power down the device.
  • (0:00) While holding down [ESC] + [REFRESH], press [POWER].
  • (0:15) Press [CONTROL] + [D] to enter developer mode
  • (0:25) Press [ENTER] to confirm
  • (0:36) Press [CONTROL] + [D] to confirm
  • (6:52) Two beeps warning user the Chromebook is in developer mode.
  • (7:25) Chrome OS booted up into developer mode and ready to be mirrored to external monitor.

Following power-ups while in developer mode:

  • (0:00) [POWER] button as normal (no other keys needed)
  • (0:10) Press [CONTROL] + [D] to bypass 30-second developer mode warning screen, also skipping the two beeps.
  • (0:20) Chrome OS booted up into developer mode and ready to be mirrored to external monitor.

Exiting Developer Mode:

  • Preparation: power down the device.
  • (0:00) [POWER] button as normal
  • (0:08) Press [SPACE] to re-enable OS verification.
  • (0:15) Press [ENTER] to confirm
  • (0:48) Chrome OS booted up into normal mode and ready to be mirrored to external monitor.

Life with a Chromebook

Ever since I started looking at this Toshiba Chromebook 2 (CB35-B3340) I had been focused on how I can break out of constraints imposed by Chrome OS. Although I had occasionally acknowledged the benefits of a system architecture focused on the most popular subset of all computing activities, I still wanted to know how to get out of it.

Now that my research got far enough to learn of a plausible path to removing all constraints and turning this Chromebook into a normal Ubuntu laptop, I’m satisfied with my available options and put all that aside for the moment. I took the machine out of Chrome OS Developer Mode so I could experience using a Chromebook for its original intended purpose and seeing how well it fills its designated niche.

Reviewing all the security protections of Chrome OS during the course of my adventure made me more willing to trust one. If I didn’t have my own computer on hand and needed to use someone else’s, I’m far more likely to log into a Chromebook than an arbitrary PC. Chrome OS receives frequent updates to keep it secure, raising the value of continued support. Since my original session to fast forward through four years of updates, I’ve received several more just in the few weeks I’ve been playing with this machine.

On the hardware side, this lightweight task-focused machine has lived up to the expectation that it would be more pleasant to use than a bulky jack of all trades convertible tablet of similar vintage. Its secondhand replacement screen‘s visual blemishes have not been bothersome, and the keyboard and trackpad had been responsive to user input. Its processing hardware is adequate, but not great. During light duty browsing the estimated battery life stretches past eight hours. But if a site is loaded down with ads and tracking scripts, responsiveness goes down and battery life estimate quickly nosedives under 4 hours.

The biggest disappointment in processing power comes from the display department. This machine was the upgraded model with a higher resolution 1920×1080 panel instead of the standard 1366×768. The higher resolution made for more pleasantly readable text, but constantly updating those pixels was too much for the machine to handle. It couldn’t sustain web video playback at 1080p. Short clips of a few seconds are fine, but settling down to watch something longer would be frustrated with stutters unless the video resolution was lowered to 720p.

And finally, there’s the fact that when the network connection goes down, a Chromebook becomes largely useless. This is unfortunately more common than I would like at the moment as I’m having trouble with my new router. In theory Google offers ways for web sites to remain useful on a Chromebook in the absence of connectivity (like Progressive Web Apps) but adoption of such techniques has not yet spread to the sites I frequent. So when the router crashes and reboots itself, the Chromebook becomes just a picture frame for showing the “No internet” error screen. This is not a surprise since network connectivity is a fundamental pillar of Chrome OS, but it is still annoying.

All things considered, a Chromebook is a nice lightweight web appliance that makes sense for the right scenarios. Its focused scope and multilayered security provisions mean I would heartily recommend one for the technically disinclined. If they learn enough technology to find Chrome OS limiting, there’s always Mr. Chromebox. If I should buy one for my own use, I would want a high resolution panel, and now I also know to get a more powerful processor to go with it.

Chrome OS Alternatives On Toshiba Chromebook 2 (CB35-B3340)

If I couldn’t solve the challenges getting ROS up and running with Ubuntu 18 under Crouton in Chrome OS, there is yet another option: erase Chrome OS completely and install Ubuntu in its place. I understand this would remove the developer mode warning and menu, and the software startup can go straight into ROS via an Ubuntu service just like any other Ubuntu machine.

The internet authority for this class of modification is Mr. Chromebox. I don’t know who this person is, but all my web searches on this topic inevitably points back to some resource on https://mrchromebox.tech. Starting with the list of alternate operating system options for a Chromebook. Ubuntu is not the only option, but for the purposes of a robot brain, I’m most interested in the option of a full UEFI ROM replacement allowing me to install Ubuntu like any other UEFI computer.

In order to install Mr. Chromebox’s ROM replacement, the hardware must on the list of supported devices. Fortunately the Toshiba Chromebook 2 (CB35-B3340) is represented on the list under its Google platform name “Swanky” so it should be eligible for the firmware utility script that makes the magic happen.

Before running the script, though, there are some hardware modifications to be made. Firmware replacement can undercut security promises of a Chromebook, even more than developer mode, so there are protections that require deliberate actions by a technically capable user before the firmware can be replaced. For “Swanky” Chromebooks, this hardware write-protect switch is in the form of a screw inside the case that makes an electrical connection across two contacts on the circuit board. Before the firmware can be replaced, that screw must be removed and the two pads insulated so there is no longer electrical contact.

Having a hardware component to the protection makes it very difficult for a Chromebook to be compromised by software bugs. Yet the screw + PCB design is a deliberate provision allowing modification with just simple hand tools. Such provisions to bypass hardware security is not found in many other security-minded consumer hardware, for example gaming consoles. I appreciate Google’s effort to protect the user, yet still offer the user an option to bypass such protection if they choose.

For the moment I am not planning to take this option, but it is there if I need it. In the near future I took this opportunity to get some first hand experience living with a Chromebook with its originally intended (non developer) use.