As part of the retro computing theme, the Hackaday Badge offers a BASIC interpreter and an emulated Z80 computer running CP/M. However, there’s also provision for people who want to get closer to the hardware. This took the form of a “User Program” option on the main menu, which points to a sample C program for modification and experimentation. This C program has access to all the badge system infrastructure utilized by the aforementioned BASIC interpreter and Z80 emulation.
Since I had the luxury of a badge on hand, the easy thing to do first is to launch the sample program and see what it does. I can see some text printed on screen, and a prompt for a key press. Once I pressed a key (no need to hit ENTER) the program switched over to a graphics drawing demonstration.
The colorful patterns cycled through with a very visible scan rate, taking roughly two seconds to update pixels from the top to bottom of the screen. My first reaction was: “Gosh, I hope 0.5 frames per second is not the fastest it can go.”
Once I saw it in action, it was time to dive into the source code. Here the text I saw was drawn using the same commands to draw the main menu: clear screen, set color, set X/Y position, and output text.
The first bit of novelty was processing the key press. Unlike the menu, the non-blocking keyboard check is interleaved with text drawing commands that could continue executing while waiting for a key press. This will be useful in things like game loops, where we want the action to keep going even if the user hasn’t pressed anything.
After the key press is the drawing demo. It is using a bitwise operator to update screen contents on every pass. And here we have good news: Not only is there an explicit delay in here (there’s a code comment that says “less than 1 ms”) the screen update is also taking place one pixel at a time, the least efficient method possible.
So the graphics demo update rate is definitely NOT the fastest the badge can go. How fast can we push it? That’s something to test in the near future.
When exploring a new codebase, it’s a great luxury to also reference it in running form, a luxury I have with the Hackaday badge code project and a physical badge on hand to see it run. What’s the first point of interaction with running code? The main menu! So that’s where I decided to start looking at details of the code.
From the main() function, the main menu is handled by function badge_menu() in file badge.c. The first thing it calls is showmenu() in the same file which draws everything visible onscreen for the main menu. Including title bar, screen border, menu entries, and the user input prompt. This is a great reference for writing code to output text on screen.
Most of the code in badge_menu() reads user key presses and builds up the typed command in menu_buff. Upon pressing ENTER, the command is checked against the list of known commands. This is a chunk of code that can easily be recycled for processing user text input.
When a user enters a command that’s none of the recognized list items, the badge selects one of a set of error messages at random. This pseudo-random number is seeded with the standard srand() call using a PIC chip’s timer counter value at the time of user’s first key press. Seeding with a time value is common practice, but usually done with a real-time clock on the assumption that the current time is unpredictable. Here, the unpredictability comes from the amount of time a human user would take before pushing their first key after powerup, every person has a slightly different reaction time.
When an user command is recognized, badge_menu() calls into corresponding code to make things happen. The menu entries are straightforward, but there are a series of “easter egg” behavior. Rather than a direct string comparison, which spoils the surprise by embedding the secret code in source code, the responses are actually keyed against a hash of the string.
Now that the Hackaday badge project compiles successfully on my computer, it’s time to look around and get oriented with the structure of this code project. Part of the orientation is actually getting re-oriented with Microchip’s own MPLAB X IDE for developing software running on their chips, like the PIC32MX chip that’s at the center of the badge.
I only use MPLAB X when dealing with PIC code. While it’s not exactly my favorite, I would agree it is sufficient to be a productive tool. The features most relevant to me right now are for code navigation. MPLAB parses the project files enough to knows how pieces of code are linked and lets me traverse those links easily.
For exploration, the following two key combinations are super useful:
Control + B: Go to declaration/definition
Alt + Left: Go back
While it is possible to use a text search to do both of these things, having an IDE that understands the project and makes navigation simple is a real time saver. With these keystrokes I could take a deeper look inside a particular function to see what it does, repeating to trace calls further if necessary. And when I’ve had enough with a particular area of code, go back to where I was before I started digging.
But of course, these tools are only useful once I have a starting point. Looking over the project files, I thought main.c sounded like a great place to start and indeed it was. There was just a short snippet of code in the main() function but it is the root of all functionality.
hw_init(); badge_init(); if (KEY_BRK==0) post(); if ((SHOW_SPLASH)&(K_SHIFTR==1)) boot_animation(); badge_menu();
hw_init() initialize all the PIC settings upon startup. What the pins do, which peripherals are activated, set things to default values, etc.
badge_init() seemed redundant but Control+B lets me see its comment saying this is work done whenever badge wakes up from sleep. So hw_init() is for a cold boot, and badge_init() is for resuming from sleep.
If a specific key is pressed upon power-up, there’s post(). The code looks like some sort of self-test, which implies POST = Power-On Self-Test.
The badge does have a little startup animation, which is apparently launched by boot_animation() if a compile-time flag and a runtime key both agree it should be run.
Finally, badge_menu() which is a loop for the badge main menu. This call never returns.
Most of main.c actually consist of comments which invites hackers to look around, find certain items discussed in the comment by using Control + Shift + F to search on strings in comments.
The first task is to get the badge firmware project file up and running. There is a repository up on Github. I see the device is built around Microchip’s PIC32 line of processors, so obviously I needed to get my MPLAB X IDE updated and running.
When I tried to build the project as-is, my first errors were related to C standard compliance, which I’ve seen before in the context of working with Microchip’s 8-bit chips but could be addressed the same way.
Then I ran into the second compiler error:
fatal error: peripheral/adc10.h: No such file or directory
An internet search found this thread on Microchip’s developer forums, which indicated I need to download something called “PIC32 Legacy Peripheral Libraries” which is a separate download link on the same page as the XC32 compiler download.
It is an archive file that, once unpacked, is an executable installer. Everything was relatively straightforward except for the installation path. By default it puts all the library files under my home directory and used version number of an old compiler. (On my Ubuntu machine, that translated to /home/roger/microchip/xc32/v1.40) which I guess could work given some project path updates. But it made more sense to install into the directory for my currently installed compiler, so the project path doesn’t have to be updated. (On my Ubuntu machine, that translated to /opt/microchip/xc32/v2.10.)
When I did my brief survey of potential robotic brains earlier, I was dismissive of single-board computers competing with the Raspberry Pi. Every one I knew about had sales pitches about superior performance relative to the Pi, but none could match the broad adoption and hence software library support of a Raspberry Pi. At the time the only SBC I thought might be worthwhile were the Nvidia Jetson boards with specialized hardware. Other than that, I believed the growth path for robot brains that can run ROS is pretty much restricted to x64-based platforms like Chromebooks, Intel NUCs, and full-fledged laptop computers.
What I didn’t know at the time was that someone has actually put an Intel CPU on a Raspberry Pi sized circuit board computer: the Up board.
Well, now. This is interesting!
At first glance they even worked to keep the footprint of a Raspberry Pi, including the 40-pin GPIO headers and USB, Ethernet, and HDMI ports. However, the power and audio jacks are different, and the camera and display headers are gone.
It claims to run Windows 10, though it’s not clear if they meant the restricted IoT edition or the full desktop OS. Either way it shouldn’t be too much of a hurdle to get Ubuntu on one of these things running ROS. While the 40-pin GPIO claims to match a Raspberry Pi, it’s not clear how they are accessed from an operation system not designed for a Raspberry Pi.
And even more encouragingly: the makers of this board is not content to be an one-hit wonder, they’ve branched out to other tiny form factors that give us the ability to run x86 software.
The only downside is that the advantage is from size, not computational power. None of the CPUs I’ve seen mentioned are very fast. At best, they are roughly equivalent to the one in my Dell Inspiron 11 3180, just tinier. Still, these board offer some promising approaches to robot hardware. It’s worth revisiting if I get stuff running on my cheap Dell but need a smaller board.
While in the process of obtaining proof that a Raspberry Pi 3 is under-powered for certain ROS processing tasks like mapping, I took a little side trip into the world of Raspberry Pi thermal management. Anyone who has pushed the limits of a Raspberry Pi would have seen a thermometer icon in the upper right corner. A quick search finds that it is put on-screen by firmware and not visible to the operating system. So when a Raspberry Pi is mounted on a robot and not attached to a monitor, we can’t see this icon. However, it is still possible to detect high temperature condition by using the command line tool vcgencmd.
This tool appears to be specific to the Raspberry Pi hardware and wraps a collection of tools to query hardware information. Official documentation seems pretty slim, not even an official name. Raspberry Pi forum users hypothesize it stands for “VideoCore General Commands” which is good enough for me.
The first useful tool is to measure temperature. vcgencmd measure_temp will return a temperature in Celsius. This internal number is more useful than attaching an external physical temperature measurement because this internal number is what the firmware will use to decide what to do. When temperature rises above 80°C, a thermometer icon overlay with a half-full bar of red is shown on-screen and the system starts pulling itself back. When it hits the target ceiling of 85°C that icon is replaced by one with full bar of red, and the firmware becomes more aggressive throttling things down to stay below 85°C.
It’s possible to keep an eye on temperature by running the tool continuously at a regular interval, something like watch -n 0.5 vcgencmd measure_temp. But once it gets into the 80-80°C range, we can’t tell if the Pi is approaching its limits, or if those limits had been exceeded and the chip slowed itself down to stay in temperature range. For that information, we’ll need a different command.
Running vcgencmd get_throttled will return a hexadecimal number representing a set of binary flags. There is no official documentation of these bits, but a lot of Raspberry Pi user documentation link to this post as reference. If any of the throttling bits are set, the Pi is working at less than maximum potential on account of overheating.
Knowing throttling occurred was enough for my experiment, but if I ever need to go one step further and find out how much throttling has occurred, there are tools for that, too. It’s possible to retrieve CPU clock frequency via vcgencmd get_config arm_freq and also by looking at /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq. But that’s beyond the scope for today.
The good news is that my new budget laptop Dell Inspiron 11 3000 (3180) can run ROS inside Windows 10 WSL. The bad news is that, with only 32GB of storage, space is really tight for accommodating two operating systems. (OK… one and a half.) Since this computer was purchased to run ROS, the next step is to wipe the entire drive for a clean installation of Ubuntu. Before I do that, though, I wanted to make sure I don’t burn my bridge for a return to Windows.
It used to be that Microsoft makes it difficult to download Windows, and even when I have a copy of the software it’s a paper records keeping hassle to keep track of license codes. Nowadays Microsoft makes it easy to download Windows, and computers like this Dell now have the license embedded in hardware so it can never get lost. These advances make it much easier to install Windows from scratch.
Installing the version of Windows 10 direct from Microsoft avoids annoying add-on trial software, but it will also lack power management optimizations from Dell. These optimizations can make a tremendous difference in battery life. When my Lenovo Y480 received a clean install, battery life dropped from four hours to one. Perhaps in time all the power management tricks will be standard and supported by standard Windows, but until then, I need to keep the Dell version.
The best tool in this situation is the system image backup option built into Windows 7. It seems to have been pushed into the background behind newer data retention features, but it keeps a full copy of all partitions of my storage, which is what I wanted to record before it all gets erased to make room for Ubuntu.
I’m sure part of the reason this backup option is less favored is because it’s a hassle to restore from. Not only does the system image backup drive need to be available, the computer needs to recover by booting with something that can make use of system image, meaning the user needs to plug in two drives to perform a recovery. (I’ve tried several times to make the “recovery boot drive” and “system image drive” the same drive and have never succeeded.)
In times of Windows 7, the recovery disk would be a bootable CD-ROM. This can be created by clicking “Create a system repair disc” in the menu above, but this Dell laptop has no optical drive and hence the optical disc creation tool is useless. What I need to do is create a bootable recovery USB flash drive instead.
Strangely, the utility to create a bootable USB recovery drive has been cut off from any menu I’ve looked in. I’ve only been able to launch it by pressing the Start button, typing “Recovery”, and hope Windows search can find it. This tool is probably getting phased out since the Windows 10 installation USB (created by “Media Creation Tool” linked above) also has the ability to restore from system image. However, I’ve had problems with version mismatch errors trying to recover using Windows installation USB. So a recovery drive created with the same computer best guarantees this drive boots on this computer to restore this image.
Creating a system image plus a bootable USB recovery drive preserves my option to return to Windows 10. Not just any version, the Dell tuned version with power consumption optimized for this specific hardware. Now I can erase this small 32GB eMMC for Ubuntu’s exclusive use.
My Dell Inspiron 11 3000 (3180), super-discounted as part of Dell’s Labor Day sales, has arrived. It is a compact little machine very comparable to the old Acer Aspire 10 and Latitude X1 I already had on hand. Upon powering it up, I was treated to the familiar Windows 10 setup routine which I had to complete before I could get into Windows and poke around.
The biggest performance limitation is, no surprise, the modest processor. While it is faster than either of its compact predecessors, it falls short of what I expect for lightweight everyday computing needs. Earlier I had praised the Acer Aspire 10 for running Windows 10 but that’s because it was a computer from 2014. A computer from 2018 faces higher expectations. The saving grace here is that this chip is a 64-bit CPU and Dell had installed the 64-bit edition of Windows 10. This makes Windows Subsystem for Linux possible here, whereas it was not available to the other two machines and their 32-bit only processors.
The next limitation was also as expected from the specifications: its 32GB of eMMC storage. It is faster than microSD cards, USB flash drives, or spinning platter hard drives, but those are low bars to clear for modern solid state storage. That didn’t matter, though, as space rather than speed turned out to be the limiting factor. Dell shipped this machine with Windows 10 Fall 2017 edition instead of the expected Spring 2018 version. When I tried to update to Windows 10 Spring 2018, the upgrade process failed due to lack of space.
Well, I bought this machine expecting to put a SATA SSD inside, after the Dell service manual indicated this chassis had space for such a drive. That’s the main reason I gambled on this purchase. (Enabled by the other big reason: Dell always provide excellent service manuals.)
As soon as I opened it up I saw I had been foiled by cost-cutting. Yes, this chassis has empty physical volume for a standard 2.5″ laptop SSD, but the connectors are absent. Not just the physical brackets on the chassis, but also the electronic SATA and power port connector. On the system board for this machine, we can clearly see where a SATA connector was designed to go, but on this low-end budget Dell (unlike a higher-end model) they’ve skipped over the cost of not just the connector but also several electronics components nearby to support that connector.
If only the SATA connector was missing, I might boldly solder something together. But those un-populated component pads nearby tells me getting SATA online won’t be easy. Oh well, no SATA SSD for this guy! I knew it was a gamble, that’s why there were backup plans. Time to go back into Windows 10 and get ROS up and running in WSL. If that fails then I will contemplate erasing Windows 10 from the built-in 32GB eMMC storage in favor of Ubuntu.
Well, I should have seen this coming. Right after I wrote I wanted to be disciplined about buying hardware, that I wanted to wait until I know what I actually needed, a temptation rises to call for a change in plans. Now I have a Dell Inspiron 11 3000 (3180) on its way even though I don’t yet know if it’ll be a good ROS brain for Sawppy the Rover.
The temptation was Dell’s Labor Day sale. This machine in its bare-bones configuration has a MSRP of $200 and can frequently be found on sale for $170-$180. To kick off their sale event, Dell made a number of them available for $130 and that was too much to resist.
This particular hardware chassis is also sold as a Dell Chromebook, so the hardware specs are roughly in line with the Chromebook comments in my previous post. We’ll start with the least exciting item: the heart is a low-end dual-core x86 CPU, an AMD E2-9000e that’s basically the bottom of the totem pole for Intel-compatible processors. But it is a relatively modern 64-bit chip enabling options (like WSL) not available on the 32-bit-only CPUs inside my Acer Aspire or Latitude X1.
The CPU is connected to 4GB of RAM, far more than the 1GB of a Raspberry Pi and hopefully a comfortable amount for sensor data processing. Main storage is listed as 32GB of eMMC flash memory which is better than a microSD card of a Pi, if only by a little. The more promising aspect of this chassis is the fact that it is also sometimes sold with a cheap spinning platter hard drive so the chassis can accommodate either type of storage as confirmed by the service manual. If I’m lucky (again), I might be able to swap it out with a standard solid state hard drive and put Ubuntu on it.
It has most of the peripherals expected of a modern laptop. Screen, keyboard, trackpad, and a webcam that might be repurposed for machine vision. The accessory that’s the most interesting for Sawppy is a USB 3 port necessary for a potential depth camera. As a 11″ laptop, it should easily fit within Sawppy’s equipment bay with its lid closed. The most annoying hardware tradeoff for its small size? This machine does not have a hard-wired Ethernet port, something even a Raspberry Pi has. I hope its on-board wireless networking is solid!
And lastly – while this computer has Chromebook-level hardware, this particular unit is sold with Windows 10 Home. Having the 64-bit edition installed from the factory should in theory allow Windows Subsystem for Linux. This way I have a backup option to run ROS even if I can’t replace the eMMC storage module with a SSD. (And not bold enough to outright destroy the Windows 10 installation on eMMC.)
Looking at the components in this package, this is a great deal: 4GB of DDR4 laptop memory is around $40 all on its own. A standalone license of Windows 10 Home has MSRP of $100. That puts us past the $130 price tag even before considering the rest of the laptop. If worse comes to worst, I could transfer the RAM module out to my Inspiron 15 for a memory boost.
But it shouldn’t come to that, I’m confident even if this machine proves to be insufficient as Sawppy’s ROS brain, the journey to that enlightenment will be instructive enough to be worth the cost.
The original research hardware for ROS is the Willows Garage PR2, a veryexpensive robot. To make ROS accessible to people with thinner wallets, the TurtleBot line was created. The original TurtleBot was based on the iRobot Create, a hacking-friendly variant of their Roomba home robot vacuum. Even then, the “low-cost” robot was still several thousand dollars.
The market has advanced in that time. TurtleBot 3 has evolved beyond a robot vacuum base, and the iRobot Create 2 itself is available for $200. Not exactly pocket change but far more accessible. The market pioneered by Roomba is also no longer dominated by iRobot, with lots of competitors, which brings us to cheap Chinese clones. Some of which are sold by Monoprice, and right now, it seems like Monoprice is either abandoning the market or preparing for new products – their robot vacuums are on clearance sale presenting tempting targets for robotic hacking.
The low-end option is the “Cadet“, and looking at the manual we see its basic two-wheel differential drive mechanism is augmented by three cliff sensors in addition to the bump sensors. The hardware within only has to support the basic random walk pattern, so the expectation is not high. But that might be fine at its clearance sale price of $55.
The higher-end option is the “Intelligent Vacuum“. It has a lot more features, some of which are relevant for the purposes of robot hacking. It still has all the cliff sensors, but it also has a few of those proximity sensors pointing outwards to augment the bump sensors. But most interesting to robot hacking – it is advertised to vacuum in one of several patterns and not just random walk. This implies wheel encoders or something to track robot movement. There’s also a charging base docking station that the robot can return to charge, backing up the speculation there exists mechanisms on board the robot for odometry. Its clearance sale price of $115 is not significantly higher than the cost of building a two-wheeled robot with encoder, plus its own battery, charger, and all the sensors.
As tempting as they are, though, I think I’ll go down a different path…
When shopping for the Dell Inspiron 15 7000 (7577) I browsed the various configurations available. It was clear the chassis has provision for two storage devices: One M.2 slot (with NVMe support) that is home to a SSD, plus one 2.5″ drive bay that is sometimes populated by a spinning platter hard drive.
This was an attractive feature of the chassis. Having two drives would allow dual-boot between Windows and Linux while keeping each operating system completely independent. This is how I typically set up my desktop (and luggable) computers, but historically laptops only had one drive bay so this is a new luxury.
Since I don’t intend to use a spinning platter drive, I ordered the configuration with only a M.2 SSD. And while the chassis has provision for a 2.5″ drive, buying with only a M.2 means I’m not guarantee to receive all the support hardware necessary to use that 2.5″ bay. I held my breath when I first opened up the computer and exhaled a sigh of relief when I saw that all the hardware was present.
Here are the 2.5″ bay hardware that Dell shipped in this chassis:
Drive installation bracket, featuring metal plates on either side, each with two shock-isolation grommets. The plates are joined by a thin sheet of plastic that I thought was a cosmetic cover, but is actually part of the structure. Don’t rip it out by its perforations like I almost did!
Four screws to fasten that bracket to the system chassis.
SATA adapter electrically connecting the 2.5″ drive to the system motherboard.
All of these parts are highly specific to this chassis and would have been a real pain to procure separately. I might have been able to fabricate a drive bracket, and maybe find some screws that worked to hold it to the chassis. But the SATA adapter is well beyond my skills to build my own.
A special happy surprise were these four hard drive mounting screws. They are standard M3 fasteners and easy to procure separately. (Some 2.5″ drives even come with a set in their package.) But Dell decided it made sense to keep a set on hand inside the computer ready to go. Sitting in a row here, they serve no structural purpose. They’re just waiting for a 2.5″ drive.
The 2.5″ bay accepts only slim 7mm drives, so full size 9mm drives would not fit. I installed an Intel 530 series SSD as it was the most convenient 7mm drive already available on hand.
Unfortunately this drive did not play well with the laptop. 530 Series were known to be finicky and has caused problems in a few of my other computer projects. (Which is partially why it’s sitting around gathering dust…) And the problems continued inside this Dell. It was so unhappy, in fact, that not only would it stop responding to the computer, it would also occasionally knock the M.2 drive offline. Whatever it was doing, it wasn’t good.
I had an Intel 320 series SSD also sitting around, whose metal case would also work in a 7mm bay but it had the plastic spacer to make it fit snugly in a 9mm bay. Removing the plastic spacer was as simple as removing four screws (though it would have voided the warranty if it hadn’t already expired) but it also meant the drive fell apart. I ended up pulling two screws out of the 350 Series drive. That was good enough to hold the drive together in the laptop’s 7mm bay.
The 320 series was much happier working inside the Dell laptop, so now I could proceed to install the latest Ubuntu LTS (18.04) on that drive. Though I ended up having to erase 18.04 and go back to the much older 16.04.4, that story is coming up next.
After waiting for almost a year for GPU prices to return to sanity, I gave up waiting for a discrete card I can install in my Luggable PC. I’ve been waiting to get started playing with CUDA-accelerated TensorFlow training and the best way to get an NVIDIA GPU at the moment is to get it inside a laptop. Since it’s not terribly practical (or price effective) for cryptocurrency miners to build huge racks of laptops for mining, the laptop variants of those chips are easier to come by, and at less crazy prices.
The laptop arrived and everything worked as advertised. But two items are worth calling out because they were details not found on a Dell specification sheet. I had my hopes but there’s no way to know until I open it up!
Happiness #1: Memory
Visible in the upper right corner of the picture are the two memory slots on this laptop chassis. Dell only advertised that the machine will come with 8GB of RAM, they did not specify the arrangement. I had expected them to fill up both slots each with an 4GB memory module because that’s usually cheaper for them. The downside of having two 4GB modules is when it comes to upgrade: with only two memory slots, any upgrade means removing an existing module and losing that capacity.
Fortunately, Dell shipped this computer with a single 8GB module, leaving the other slot open for future upgrade. I don’t have to remove any capacity when I upgrade – just plop a new module into that second slot and I’m good to go. This is great news.
Happiness #2: Hardware for 2.5″ Storage Drive
Visible in the lower left corner of the picture is the 2.5″ drive bay. Some configurations of this laptop are sold with a combination of a 2.5″ spinning disk hard drive augmenting the capacity of a small M.2 SSD. This particular model comes with a 256GB M.2 SSD and no hard drive. I had expected the 2.5″ bay to exist in my chassis, but empty. With not just the 2.5″ drive absent but also missing all the support hardware necessary to install one after purchase.
Fortunately, Dell shipped this computer with all the support hardware in place. This includes the metal bracket along with four screws to secure it to the chassis. It also includes the electronic ribbon cable necessary to connect the drive to the motherboard. Both of these items are specific to this laptop chassis and expensive to obtain if they weren’t already included. It’s good to see them present so I don’t have to hunt.
Extra nice touch from Dell: The M3 screws to fasten a 2.5″ drive to the metal bracket is a standard item and easily obtained elsewhere. Given the absence of a 2.5″ drive, I expected I’d have to find standard fasteners on my own. But I don’t need to! The chassis actually has a place to hold these four screws when not in use, and the computer came with these screws, too. This is a feature I’ve only seen before in a premium engineering laptop from their Precision workstation line, never on their consumer Inspiron line.
With these two thoughtful touches, Dell has made me a happy customer. In the near term I’ll install one of my old 2.5″ SSDs for extra storage capacity (and/or Linux dual-boot) and I’ll keep my eyes on DDR4 memory prices for a future memory upgrade.
Battery: Dell 33YDH
Not exactly a note of happiness, but just one bit of trivia I couldn’t find online: the battery module has a designation 33YDH, useful when shopping for a replacement. All batteries have a cycle life – how many times they can be charged and discharged. Some battery types like lithium-ion also have a calendar life. They will degrade over time no matter how much they are (or aren’t) used. So, in a few years, if I like this laptop enough to want to keep using it, I will need to shop for a replacement 33YDH battery.
My first experience with stepper motors is with this very inexpensive Amazon offering. I’ve since learned that these stepper motors are termed “unipolar” which incurs some trade-offs. From the price tag I knew they were cheap, and from the description I knew they were easy to control from a simple program. What I did not know about is the fairly significant headwinds if one wishes to get beyond the basics.
The simple driver module that goes with these simple motors only works for straightforward on/off control. When I tried to modulate the power to be somewhere between on and off, mysterious electromagnetic stuff started happening causing erratic motor behavior. At the time I decided to postpone solving the issue and to look into it later. Well, now is later and I’m going to solve my problem by ignoring unipolar motors entirely. Because it’s more productive to look at the bipolar stepper motors used by pretty much every halfway decent piece of hardware.
The motors themselves are more expensive, and the drivers are as well. Fortunately economies of scale meant “more expensive” is still only a few dollars. Pololu sells a line of stepper motor driver modules that are popular with the 3D printing crowd. (Or at least that’s where I learned of them.) The module’s physical form factor and pinout has become something of a de-facto industry standard. And a bipolar stepper motor for experimentation is equally easy to obtain as pretty much any stepper motor salvaged from consumer electronics will be a bipolar motor. For the purposes of my experiment, this motor came from a dead inkjet printer’s paper-feed mechanism.
Hooking up the electronics is a fairly straightforward exercise in reading data sheet and following instructions. The only thing I neglected was a capacitor across the motor input pins, something pointed out to me when I brought this experimental rig to a local maker meet. Fortunately I had been playing with a small enough motor that the absence of said capacitor didn’t fry everything.
All I needed to do was generate two data signals: direction and step. This is apparently a fairly common interface, even industrial-type stepper motor controllers accept similar inputs, so a Pololu is a great way to start. I created a small program to run on an 8-bit PIC microcontroller to generate these pulses, and the motor is off and running. It was super easy to get started, and this setup is enough for me to play around and build some basic understanding of stepper motor behavior. How they trade torque for speed, and how they respond to higher voltage/amperage. It’s a good foundation for designing future robotics projects.
For the purposes of experimenting with a Pololu stepper motor driver, I wanted to generate pulses from a PIC running a simple program. This meant downloading and installing the latest tools from Microchip for 8-bit PIC development: The MPLAB X IDE, the XC8 compiler, and the MPLAB Code Configurator (MCC).
With these tools set up, I pulled down my previous PIC stepper motor project intending to use it as a starting point. The stepper driver portion will be different, but I wanted the analog dial capability to adjust speed and direction. Before I start modifying code, though, I hit “Build” to make sure everything still compiled.
It did not.
In file included from mcc_generated_files/mcc.c:74: In file included from mcc_generated_files/mcc.h:52: mcc_generated_files/interrupt_manager.h:110:6: error: variable has incomplete type 'void' void interrupt INTERRUPT_InterruptManager(void); ^ mcc_generated_files/interrupt_manager.h:110:15: error: expected ';' after top level declarator void interrupt INTERRUPT_InterruptManager(void); ^ ; 2 errors generated. (908) exit status = 1
Since “void” is a very fundamental type for C programs, this error tells me this isn’t the matter of a minor typo, something is wrong at a very basic level. As a test, I created a new MPLAB project with a bare skeleton generated by MCC. This “Hello World” program failed to compile in the same way, indicating the problem is a system configuration issue.
A little digging around found the issue was introduced with XC8 compiler version 2.0, introduced just a few months ago in May. It moves C language support up to C99, keeping up with industry standards. However, this change also broke compatibility with old code. Not just old code sitting on a hobbyist’s Github page, but also old boilerplate code generated by MCC.
I expect that Microchip will eventually update these templates in a future MCC update, but for now, PIC programmers that use MCC for rapid prototyping will need to change their project settings to fall back to the older C90 standards. See xc8 2.0 migration document here for more details on this workaround.
The typical rule of thumb is that building your own computer from components is far cheaper than buying a prebuilt machine. Buying parts from Newegg.com, Amazon, Fry’s Electronics, etc. results in a better machine for less money than getting something from Dell. This was certainly true when I embarked on the Luggable PC project but a few notable events have since occurred to make an exception to the rule.
The blockchain fad is the biggest disruption. Cryptocurrency miners’ demand for graphics processors drove up their prices tremendously. At the beginning of my Luggable PC project, a NVIDIA 1060 card with 6 GB memory is considered a good mid-range GPU. (Or an entry-level unit for the more demanding world of virtual reality). A desktop 1060 video card was available for around $200 and I expected its price to drop as I designed and built my luggable PC. Instead, it spiked up to over $400 at times and is now hovering around $300.
The second disruption is in 3D-NAND flash memory. It is a big step change in price/performance so flash memory makers had no choice but to switch to 3D NAND technology or risk going out of business long-term. In the short-term, chip fabrication facilities have to be taken offline for this conversion, which meant a shortage of flash memory, 3D and otherwise, across the market. Driving up prices of solid state drives.
The third disruption is in DDR4 memory. There isn’t as clearly a single factor here but manufacturing capacity seems to be lagging market demand over the past year or so. Right now, DDR4 memory is nearly double the price of similar capacity DDR3 memory when historically they should be closer to price parity at this stage of technology maturity.
There are a few other factors at play, but the short-term trend is clear: many computer components have risen in price over the past year, counter to the long-term historical trend of ever-cheaper electronics.
Computer manufacturers like Dell deal in large quantities, and therefore they buy through supply contracts whose prices are independent of day-to-day market disruption. The upside of this approach is that, in times of supply shortages, Dell pays far less for their parts than market price.
Today’s example: a particular configuration of Dell Inspiron 15 7000 Gaming laptop is available for $750 after promotional discount codes. Let’s look at the components and the current (approximate) market price for their desktop counterparts.
NVIDIA GTX 1060 with 6GB: Admittedly the laptop variant of this GPU is slightly less capable than its desktop equivalent, but for the purposes of this comparison we’ll count it at the full $300.
Intel Core i5-7300HQ: Again this is a laptop-only part. It is similar to the desktop i5-7400 processor in that they both have a peak speed of 3.5 GHz, so $200.
256GB NVMe M.2 SSD: Unlike the other parts, desktop machines are happy to use the exact same M.2 form factor solid state drives using the NVMe interface. 256 is a little cramped but on a laptop it should be fine. (I stuck with 256 until the flash memory crunch eased a bit for me to upgrade to 512.) Let’s call it $100.
8GB DDR4 memory at 2400MHz: The smaller laptop-sized DDR4 modules are a little more expensive than their desktop counterparts, but we’ll round up to $100.
With these rough estimates, we’re already up to $700 and we’re still missing some major components necessary for a working computer.
Motherboard with M.2 SSD slot and built-in WiFi: Bottom of the line units are available for $70-80 but a reputable unit will be $100 and up. (It is the backbone of the system so not the best place to economize.)
Power supply: We can pinch a bit here, reliable though not super powerful units can be had for around $50.
Display: A 1920×1080 IPS monitor will be around $100.
Keyboard, Mouse, case (luggable or otherwise) and other miscellaneous parts: Round to $50 for a nice even tally.
That’s $1000 to build a desktop or luggable PC with similar specs as this $750 Dell laptop. And while the screen might be physically larger, the whole computer definitely won’t be as lightweight and portable. Such laptop-only traits – light weight, tight integration, ability to run on battery – usually demand a price premium over equivalent desktops.
In the single-board computer field, the Raspberry Pi 3 has been the benchmark for high performance devices: A newcomer SBC has to provably outperform the Pi 3 to build a compelling case on superior performance. One big asterisk in these comparisons is the thermal conditions during comparison. When run hard, a default stock Raspberry Pi 3 can drive itself up to the self-imposed thermal limit of 85 degrees Celsius, at which point it throttles performance.
The BeagleBoard people has released their smallest form factor yet – the PocketBeagle. Performance of their standard sized BeagleBoard are not thermally constrained like the Pi 3. But their claims of BeagleBone level of performance in a small form factor leads to the question whether packing into a tiny space also increased the thermal load. And if so, perhaps a heat sink will help performance as it would on a Raspberry Pi 3.
For this test, we ran a PocketBeagle at 100% CPU using the ‘stress’ tool available as part of its Debian distribution and measured its temperature with a non-contact infrared thermometer over a period of six minutes. The ambient air temperature was 28° C. Two runs were performed, and their average value plotted out against time (in number of seconds).
The temperature rise visibly started to taper off at six minutes. Gauging by the trend, it may approach but is unlikely to surpass 60° C. The Octavo OSD335x datasheet page 28 listed the operating temperature range of 0 to 85°C. We have plenty of thermal headroom on a PocketBeagle without use of any heat sinks when operating at normal room temperature.
Perhaps a PocketBeagle would need a heat sink in some high-temperature environments, but for normal use, anybody trying to sell a heat sink to improve performance is probably just selling snake oil. The thermal profile here is not anything like a Raspberry Pi 3.
We had an earlier success tearing down a Dell laptop battery pack, where the six salvaged cells still have 70% of original capacity after ten years of service. However, that was from a laptop that could still boot and run from its battery pack. This XPS M1330 battery pack is in far worse shape. How much worse, we were about to find out.
The first critical detail was realizing the battery pack was not the original Dell battery pack. It is an aftermarket type of unknown manufacture. The earlier battery pack tear down yielded Samsung cells, we’re probably not going to get anything nearly as nice this time around.
Once the case was cracked open the suspicion was confirmed: These appear to be generic 18650-sized lithium cells with no manufacturer branding. The nine cells of the battery pack were divided into three modules in series, each module had three cells wired in parallel. The module in the worst shape exhibited severe corrosion and had no voltage across their terminals.
The other two modules were in slightly better shape, but they have self-discharged down to approximately 1 volt DC, well under the recommended voltage range. A web search found some details on what happens to overly discharged lithium cells. In short: the chemistry inside the cell starts dissolving itself. If recharged, the dissolved metals may reform in inconvenient ways. Trying to use these cells has three potential outcomes:
Best case: The metals dissolved into the electrolyte will hamper chemical reaction, resulting in reduced capacity.
Medium case: The dissolved metals will reform in a way that damages the cell, causing it to fail as an open-circuit. (As if no battery was present.)
Worst case: The dissolved metals will reform in a way that damages the cell, but causing it to fail as a closed circuit. Short-circuiting the internals will release a lot of energy very quickly, resulting in high-pressure venting and/or fire.
The corroded cells that have discharged down to zero volts have the highest risk and will be discarded. The remaining cells will be slowly (and carefully) charged back up to gauge their behavior.
Recently a dead Dell XPS M1330 came across the workbench. The battery was dead and the machine fails to boot. After some effort at reviving the machine, it was declared hopeless and salvage operations began. Today’s effort focuses on the motherboard port for the AC power adapter.
The power plug on this Dell different from the typical Dell laptop AC adapter: octagonal in shape rather than round. The shape meant it could not be used on other Dell laptops designed for the round plug. However, the dimensions of the octagon are such that an AC power adapter with the typical round Dell plug fits and could be used to charge the laptop. So while the laptop could be charged with any existing Dell-compatible AC adapter, the AC adapter that came with this machine is specific to this Dell.
Once the XPS M1330 died, its octagonal plug power adapter is not useful for other Dell laptops. It still functions as a power supply transforming household AC to ~19V DC so it might be useful for future projects. To preserve this possibility, the octagonal power port will be recovered from the system board.
The solder used in Dell assembly was possibly one of the lead-free types and is definitely reluctant to melt and flow. Trying to desolder the power port using hand tools (desoldering wick and hand suction pump) had no luck. So this project was chosen as a practice run of using a dedicated desoldering tool, in this case a Hakko 808. The tip of this tool heats up to melt the solder, and with a press of the trigger an electric vacuum pump pulls the melted solder through center channel of the heated tip and into a chamber for later disposal.
The desoldering pump was able to remove more solder than hand tools could, but was still not quite enough to free the port. Using a soldering iron, some user-friendly leaded solder was worked back into the joints to mix with the remaining Dell factory solder. Upon second application of the electric desoldering tool, enough solder was removed to free the port from the system board with only minimal damage.
A test with the voltage meter confirmed this port is now ready to be used to provide ~19V DC power to a future project.
When the Acer SW5-012 (Aspire Switch 10) was received in a non-functioning state, it had a sticker covering the webcam lens applied by the previous owner. This is a common modification from owners who are concerned about malicious hackers activating the camera at unauthorized times. Some computer makers are finally meeting customer demand by placing physical shutters over webcams, but until that becomes commonplace, we’ll continue to have stickers/tabs/post-it notes covering webcams.
Removing the camera module would be a far more secure solution if the webcam is not to be used anyway. While impractical for some difficult-to-disassemble devices like an Apple iPad, we’ve already cracked open this Acer and test the concept. It turned out to be a straightforward exercise. The camera module is a distinct unit, the ribbon cable detaches from the motherboard easily, and it was only held in place by what felt like double-sided tape.
With five minutes of removing the back panel of the machine, the camera module was removed. The only lettering on it said CIFDF31_A2_MB and a web search on that designation returned several vendors happy to sell a replacement module. Sadly no technical information was found in a cursory search, so we won’t be trying to drive it with a PIC micro controller or anything. It’ll just sit in a zip lock bag for now.
And this intentionally-blinded Acer tablet is now available for use by house guests who are wary of hackers getting into the camera: no hacker in the world can activate a camera that is sitting in a zip lock bag in another room.
Our recent project with the Acer Aspire Switch 10 laptop had concluded with one mystery: how did it get the license key? Because we didn’t have the password for the installation of Windows 8 on the machine, the hard drive was wiped clean and Windows 10 installed from scratch. We expected we’d need to purchase a new license of Windows to activate on this computer. Fortunately, Windows 10 proclaimed itself activated without the need for a new license.
At the time we did not understand, but we were also not going to complain.
A second data point came in the form of a Dell laptop, which also shipped with Windows 8 but purchased by someone who decided they did not like it. A Windows 7 license was purchased and installed on this computer, which was then upgraded to Windows 10 during the free upgrade period. The original Windows 8 was lost. Recently a new SSD was installed on this computer and Windows 10 was installed from scratch. And like the Acer, Windows 10 proclaims itself to be activated even though no product license key has been entered.
Curiosity now demands a web search for answers, where we learn both of these computers participated in a new licensing scheme launched with Windows 8. Instead of a counterfeit-resistant license sticker attached to the bottom of the computer, their product license is embedded in the hardware instead. We will never have to worry about the license key becoming illegible, or getting lost and separated from the corresponding hardware.
Windows 8 could access this key and activate itself. Windows 7 installed on the Dell laptop could not. Windows 10 could access this key and, more importantly, are willing to activate on it even though the license was technically for Windows 8. The official free Windows 10 upgrade period has ended but we can still get a free step up under these circumstances.