The Less Famous Rovers Marie Curie, Dusty, and Maggie

While I’m on the subject of rover suspension and ground clearance, I want to take a detour to recognize the less famous rovers that didn’t make the trip to Mars. My rover fandom has mostly been focused on siblings Curiosity and Perseverance, but those rovers would not exist if it weren’t for the twin rovers Spirit and Opportunity. Formally the Mars Exploration Rover program, they followed Sojourner the rover technology demonstrator. Each rover generation was larger and more sophisticated than the last, but one thing all those rovers had in common was the rocker-bogie suspension design that I replicated with my own Sawppy rover using references like a rover family portrait published by NASA.

But the real rovers are on Mars. Who are the rovers in this picture? The little one is named Marie Curie, and is a “Flight Spare” for Sojourner (Truth). Meaning it is fully equipped and qualified to be sent to Mars as an alternate if necessary, but there was no need so Marie Curie stayed on Earth. I assume it played a role during the mission as a testbed as the other two rovers did.

Representing Spirit and Opportunity is the MER Surface System Test Bed. This rover duplicates many of the mechanicals of Spirit and Opportunity, but is not fully equipped to go to Mars. For one thing, it runs on a power tether and have no functioning solar panels, just passive stand-ins. This machine stayed at JPL’s Mars Yard to help scientists and engineers on Earth test ideas and solutions before commands are sent to Mars.

MER SSTB is a mouthful, and I remember seeing JPL people on Twitter calling the test rover “Dusty” but I found no official confirmation of this name. After the Mars Exploration Rover program ended, Dusty(?) was given to the Smithsonian where it will continue to represent the MER program when put on display.

The Mars Science Laboratory (MSL) mission included the Earthbound Vehicle System Test Bed counterpart to Curiosity shown in the family photo, again with some differences such as powered by a tether instead of faithfully duplicating an onboard radio-thermal nuclear reactor. According to this article, the MSL VSTB counterpart to Curiosity is “Maggie”, and the Mars 2020 test bed counterpart to Perseverance is “Optimism”.

And since these are engineering tools, both names are officially engineering acronyms. Or more likely, “backronyms” where the acronym was chosen first, then words were chosen to fit it. That’s why we have convoluted names like “Mars Automated Giant Gizmo for Integrated Engineering” and “Operational Perseverance Twin for Integration of Mechanisms and Instruments Sent to Mars.”

These rovers won’t get nearly as much fame as their Mars-bound counterparts, but they all play vital roles contributing to mission success.

[Image credit: NASA/JPL-Caltech]

Sawppy Rover Ground Clearance

When it comes time for Ingenuity to demonstrate Mars helicopter technology, it will be dropped to the surface then wait for Perseverance to move a small distance away to prepare for the experiment. This arrangement is possible because the rover’s rocker-bogie suspension gave it more than enough ground clearance for a hitchhiking helicopter to ride along, holding on to the belly of the rover.

This ample ground clearance is also visible in the Mars 2020 Mission Identifier. The first I saw of this logo was on the side of the rocket payload aerodynamic fairing protecting the rover against the atmosphere during launch. I love this blocky minimalist design of the rover’s front view and believe this little logo hasn’t been used nearly enough.

Anyway, back to ground clearance: it is something obviously useful for a wheeled vehicle traversing off-road, which is desirable given the lack of roads on Mars. But raising the height of rover’s main body is only part of the equation, because it’s not the only thing that might collide with obstacles on the ground. We also have to worry about suspension components. This is something I noticed with JPL’s Open Source Rover design: if a ground obstacle is offset from a wheel, there’s a chance it will collide with aluminum structure. This picture uses a Roomba virtual wall marker to represent a rock on the ground, which is about to collide with suspension structure:

When I designed Sawppy, I thought I could improve upon this specific issue by taking advantage of the flexibility of 3D printing. I also chose Sawppy wheel motors with the requirement they must fit within the wheel with no protrusions. If Sawppy should encounter a Roomba virtual wall marker slightly offset from a wheel, there is no risk of collision:

I this was a pretty good Sawppy feature. However, after looking at how other Sawppy builders have customized their rovers, it appears this feature isn’t as valued as I thought it would be. There have been many Sawppy modifications that did not preserve this clearance.

For example, Marco Walther [mw46d] replaced wheel motors with much longer units that risks collision. He is aware of the risk, because he designed shielding to protect the motor encoders from damage. It’s a different approach, shielding vs. avoidance. Steve [jetdillo] adopted Marco’s design to good effect.

Chris Bond swapped out the wheels for RC monster truck wheels, similar to those used by JPL Open Source Rover. However, my wheel mounting arm design does not fit within the wheel. To compensate for this, Chris decided to push the wheels out. This leaves almost the entire wheel mounting arm out where it could collide with ground obstacles. It also means the steering axis is no longer aligned with the wheel, but Chris seems happy with his design so I guess it works well enough.

My lesson is that ground clearance isn’t as important as I thought it was. Or at least, not seen as important enough relative to features other builders wanted for their own rovers. This is valuable feedback for future iterations.

On the topic of rover iterations, I want to take a quick detour from my own rover to recognize some lesser-known counterparts to our robotic Mars explorers.

Ingenuity the Mars Helicopter Technology Demonstrator

One of the most exciting part of the Mars 2020 mission is not visible on the Perseverance rover interactive 3D web page. It is Ingenuity, officially named the Mars Helicopter Technology Demonstrator. (It has its own online interactive 3D model.) For people like myself who want to really dig into the technical details, NASA JPL published many papers on the project including this one for the 2018 AIAA Atmospheric Flight Mechanics Conference. (DOI: 10.2514/6.2018-0023)

Ingenuity is the latest in a long line of technology demonstrator projects from JPL, where ideas are tested at a small scale in a noncritical capacity. Once proven, later missions can make more extensive use of the technology. Perseverance rover itself is part of such a line, tracing back to Sojourner which was the technology demonstrator for the concept of a Mars rover. Reflected in its official name, the Microrover Flight Experiment.

Most of the popular press has covered Ingenuity’s rotors and how they had to be designed for Mars. It has the advantage that it only had to lift against Martian gravity, which is much weaker than Earth gravity. But that advantage is more than balanced out by the disadvantage of having to work in Martian atmosphere, which is much much thinner than Earth air. Designing and testing them on Earth was a pretty significant challenge.

Mechanically, the part I find the most interesting were motor and control system for the coaxial helicopter. It has been simplified relative to coaxial helicopters flying on Earth, but still far more complex than the category of multirotor aircraft commonly called drones. Most multirotor aircraft have no mechanical control linkages at all, their propellers rigidly attached to a motor and control is strictly electronic via motor power. The paper describes the challenges of implementing a coaxial helicopter control system for Mars, but it didn’t explain why the design was chosen in the first place. I’m sure someone worked through the tradeoffs. Since mechanical simplicity (and hence reliability) is highly valued in planetary missions, I am very curious what factors outweighed it. Perhaps that information was published in another paper?

Electronically, the most exciting thing is Ingenuity’s brain, which is from the Snapdragon line of processors better known as the brains for cell phones and tablets here on Earth. If it works on Mars, it would offer a huge increase in computing power for planetary missions. Perseverance itself runs on a RAD750 computer, which has proven its reliability through many successful spacecraft but is roughly equivalent to a 20-year old PowerPC desktop. Having more powerful CPUs for future missions will allow our robotic explorers to be more autonomous instead of being dependent on brains back here on Earth to tell them what to do.

Perseverance Rover Interactive 3D Model

NASA released a 3D printable static display model of Mars rover Perseverance, which seems to have some improvements over the earlier Curiosity model. But that’s not the only 3D resource for the rover currently on its way to Mars. There is also a version designed for on-screen display rather than 3D printing.

Both the 3D printable (in STL file format) and 3D render (GLB file format) models were listed on the Mars 2020 rover page, which as of this writing has curiosity disappeared from the index page of NASA 3D resources. I’m not sure what’s going on there, but hopefully it’ll be fixed shortly.

When I listed 3D resources for Curiosity there was also a model suitable for 3D rendering. Available as download files for Blender the open source 3D graphics tool and as files embedded in a web page for interactive viewing. The latter is again available: The Mars 2020 mission page has a 3D model of Perseverance that we can interact within a web browser.

This browser interactive model is the most easily accessible version, there’s no need to install Blender or any other piece of software. It serves as an index page to many other pieces of information talking about the rover. While it has a lot of detail missing from the 3D printable model, it still has a few minor flaws. One of them I noticed only because I’ve been a fanatic of the rover: the online interactive rover’s right side wheels are reversed from the actual rover.

Perseverance, like Curiosity before it, has wheel spokes that are curved to absorb impact. I simplified the idea and translated it into a 3D-printable shape for Sawppy’s wheel. For both rovers, the direction of curvature for wheel spokes are the same for all six wheels, clearly visible in rover test footage. Shot in JPL’s vehicle assembly bay, we can see that the wheel spoke curvature is “clockwise” on all six wheels of Curiosity and Perseverance.

On the online interactive 3D model, its left side wheels match the real rover but its right side wheels had been flipped so the spokes point counter-clockwise.

It’s a tiny detail that would only be noticed by the most particular of rover fans, which I certainly am. Surprisingly, I’m not the only one! Because I’ve received questions about whether Sawppy’s wheels should be printed in mirrored orientation. Some Sawppy builders choose as I did, to have six identical wheels matching the real rover. Others chose to mirror three of the wheels as the web page interactive model did.

But one of the most exciting parts of the Mars 2020 mission is not visible at all here. Riding along with Perseverance rover is the first aircraft built by humans to fly in the atmosphere of another planet.

Window Shopping: NASA Perseverance Rover 3D Print Static Model

After finishing a model of Mars rover Curiosity, the obvious question is: did NASA release a 3D print static model of its successor Perseverance? And the answer is yes! Curiously, the web site page points to a 3D file suitable for graphics rendering, not for 3D printing. But poking around the GitHub repository revealed there’s a “M2020” 3D print model. (Before receiving its name, Perseverance was called Mars 2020.)

Armed with my recent experience, I looked over the files for this printable rover. First the good news: the rocker-bogie suspension is represented in much higher fidelity on this model. The full rocker bogie geometry is represented, including a differential bar that is designed for some bent paperclips to serve as critical linkages. The wheel tracks appear to be correct with the center pair of wheels having wider tracks than the front and rear pairs. And the geometry is more accurate, no weird right angle bends as concession to ease of printing.

The lack of concession to ease of printing is also the bad news. Unlike the previous model, none of the geometry has been modified to fit flat on a print bed. Printing this model will require, at a minimum, printing with supports which is always problematic. Dual-material printer with dissolvable supports should make such designs easy to print, but I don’t have one of those.

Another change from the previous model is that this one doesn’t use snap-together construction. Parts are designed to be glued together instead. It also means these files assume a much higher printing precision, since superglue requires a much tighter fit than snap-together construction.

If I saw these traits on a Thingiverse item, I would be skeptical that the model is even buildable. That site is littered with too many things that are obviously impossible, merely the dream someone created in CAD and never test printed.

But this one appears to be real, since among the STL files is a picture of this rover design that has been built. Looking over the print quality of its parts, it was obviously printed at high detail quality on a good printer. Likely better than mine! I think I’ll hold off printing this rover design for the moment. Maybe later, when I have a well dialed-in printer that I can trust to meet precise tolerance requirements. In the meantime, I can admire the Perseverance 3D Model released by NASA that lives strictly in the digital realm.

Built NASA’s Curiosity Rover 3D Printed Static Model

I’ve completed assembly of a 3D-printed static display model, released by NASA, of Mars rover Curiosity. It had a lot of details that were demanding when printed in PETG. In hindsight, I should have printed with PLA for fewer printing problems like stringing and overhangs. It is only a display model, it’ll just sit on a shelf and not stand out in the sun as Sawppy has done (and suffered for it.) Better dimensional accuracy with cleaner printing PLA would also help make the snap-together construction more effective. PETG is more ductile and so there wasn’t a “click” to announce successful assembly.

The demanding details were fitting for a static display model. Unlike its smaller sibling, this one is even poseable with corner wheels that steer and a robot arm that can articulate through the same degrees of freedom as the robot arm of the real thing.

With its emphasis on appearance, I was disappointed at the representation of my favorite feature of NASA JPL’s Mars Rovers: their rocker-bogie suspension. The first complaint is cosmetic: this model placed all three pair of wheels with the same track (distance between left and right wheels.) Curiosity’s front and rear wheel pairs actually have a narrower track than the middle pair, which I speculated was done that way so the suspension can fold up for flight. While a static model does not need to fold up for flight, it should at least accurately represent the layout.

The next complaint is a combination of cosmetic and functional: the suspension rockers do not articulate. Their angle is fixed relative to the body. On Curiosity, the left and right rockers are connected via the differential bar which keeps the two rockers in sync with complementary movement: if one moves up, the other moves down the same amount. But on this model, the differential is a surface feature and not a functional one, without connection to the suspension rocker.

On the upside, at least this model has articulation for suspension bogies. This was also missing from its smaller sibling. With articulating bogies, this rover model can at least pretend to handle rough terrain capability even if it lacks full rocker-bogie capability. In this picture, the middle wheel is raised by a piece of 3D-printed plastic I had on hand.

And finally, the suspension arms leading up to corner steering wheels have right-angle bends that are not an accurate representation of Curiosity’s suspension. I suspect this was done as a compromise to make these parts 3D-printable without supports, but it further reduces fidelity of this model.

There are several additional print problems with this first draft. If I were excited about this model I would reprint in PLA to see if it improves as expected. But given my lack of enthusiasm about representation of rocker-bogie suspension, I am content to stop here and look around for the next project.

NASA’s Curiosity Rover Model Print Cleanup and Assembly

NASA published a 3D printable static display model for Curiosity rover, and one of the things they offered to make printing easier are STL files that have already laid out many parts so they can be printed all at once. The upside is a lot less work on setup and less time tending to the printer. The downside is that if one part fails, it dooms the entire print.

The rover suspension parts are all in a single large multipart print. The real Curiosity rover suspension structure is cylindrical, and this model tries to maintain that shape, meaning there’s very little surface area contacting the print bed at the bottom of the cylinder. In the first few failed attempts, one of the suspension parts (and never the same one twice) would pop free from the print bed and wreck havoc.

To work around this, I told MatterControl to add a brim on all parts to increase surface contact area. It allowed the print to complete, but now I have to cut all those brims off before I could proceed to assembly.

I started by cleaning up the wheel hubs and pressing them into wheels.

Following my tradition of rover building, I proceeded to build a rover wheel on a stick.

Which quickly led to a rocker-bogie assembly for one side of the rover.

Unfortunately, the rocker does not articulate on this model. Its angle relative to the body is fixed. So this particular portion of the model is no more functional than the smaller version. However, the bogie does articulate, and all four of the corner wheels can steer.

Having built one side, it was easy to build the mirror side and put everything together. I noticed I had two extra steering brackets left over. Reviewing the large multipart print, I now notice there are six steering brackets even though only four rover wheels could steer. I shrug and move on.

Assembly of the robot arm was straightforward following the directions, leaving rover head installation as the final step. The static model is complete and I can admire it in its entirety.

3D Printing NASA’s Curiosity Rover Model

I decided to build the 3D printed Curiosity rover model released by NASA, and ran into some problems with print bed adhesion. Whoever designed this model had a 3D printer with better print bed adhesion than mine. My first few printed parts would lift from my print bed.

Some of this is unavoidable, the natural orientation of some parts dictate minimal surface area. The wheels, for example, have to sit with their narrow side edges on the bed because that is the only flat side. Fortunately wheels are round and produced minimal stress.

In contrast, the body of the rover is a large rectangular solid with sharp corners. This is a recipe for lifts and they released the STL files with some pre-generated brims to help the corners stick. Unfortunately that was not enough for me, because some of the corners still lifted off the print surface. Fortunately this was only a minor cosmetic issue, since the bottom does not need to be absolutely flat to mesh with any other part.

Another cosmetic issue is the radiothermal generator at the back, which ramped up more aggressively than my Pulse XE revision D printer could handle with PETG. Fortunately this is a bottom-facing surface and shouldn’t be too much of a detraction.

The wheel spokes were the most problematic with their fine detail requiring a lot of filament retraction as the print head moves from one tiny feature to another. In my experience, retraction-heavy prints work much better in PLA than PETG, in hindsight that’s what I should have used.

An interesting nod to convenience is that, in addition to publishing STL for individual parts, the creator of this project also included STL files with many parts laid out to be printed all at once. The upside is that there’s a lot less overhead. The downside is that failures can be troublesome.

NASA’s 3D Printable Curiosity Rover

When I take Sawppy out for some publicity, people frequently ask about the 3D printable Curiosity rover static model released by NASA. Some mistakenly thought Sawppy was the NASA-released design, others wanted to know how the rovers compared. I couldn’t answer the latter because I never printed the NASA rover, to the surprise of some, so I thought I should do it at least once.

NASA’s 3D printing resources page for a printable Curiosity points to a GitHub directory that actually has two printable models. I’ve seen the smaller one at a MatterHackers event, printed by another attendee who left her little rover on Sawppy’s table to keep my rover company.

The small model has limited articulation. All six wheels can roll, but cannot steer and it could only sit on a flat surface because its rocker-bogie suspension joints are fixed. I also noticed the robot arm joint articulation doesn’t match that of the real rover’s. Still, it is undeniably a representation of Curiosity and a cute little model.

Since I’ve seen the little one, I decided to skip it and try building the larger one. “Large” is relative, of course, it would still be much smaller than Sawppy. Another important difference is that it is an unmotorized static display model, which is actually the main reason I had not tried to build it. I wanted a rover that moved!

But I’m glad I’ve built it, because it was a good study into the different compromises this model made for the sake of being 3D printing friendly.

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 terrible bargain basement devices were released, and I had two JMF602-based drives that lasted through their 90-day warranty periods but not much beyond that. The big breakthrough in affordable 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.

I Started Learning Jamstack Without Realizing It

My recent forays into learning about static-site generators, and the earlier foray into Angular framework for single-page applications, had a clearly observable influence on my web search results. Especially visible are changes in the “relevant to your interests” sidebars. “Jamstack” specifically started popping up more and more frequently as a suggestion.

Web frameworks have been evolving very rapidly. This is both a blessing when bug fixes and new features are added at a breakneck pace, and a curse because knowledge is quickly outdated. There are so many web stacks I can’t even begin to track of what’s what. With Hugo and Angular on my “devise a project for practice” list I had no interest in adding yet another concept to my to-do list.

But with the increasing frequency of Jamstack being pushed on my search results list, it was a matter of time before an unintentional click took me to I read the title claim in the time it took for me to move my mouse cursor towards the “Back” button on my browser.

The modern way to build [websites & apps] that delivers better performance

Yes, of course, they would all say that. No framework would advertise they are the old way, or that they deliver worse performance. So none of the claim is the least bit interesting, but before I clicked “Back” I noticed something else: the list of logos scrolling by included Angular, Hugo, and Netlify. All things that I have indeed recently looked at. What’s going on?

So instead of clicking “Back”, I continued reading and learned proponents of Jamstack are not promoting a specific software tool like I had ignorantly assumed. They are actually proponents of an approach to building web applications. JAM stands for (J)avaScript, web (A)PIs, and (M)arkup. Tools like Hugo and Angular (and others on that scrolling list) are all under that umbrella. An application developer might have to choose between Angular and its peers like React and Vue, but no matter the decision, the result is still JAM.

Thanks to my click mistake, I now know I’ve started my journey down the path of Jamstack philosophy without even realizing it. Now I have another keyword I can use in my future queries.

Sawppy Documentation: Change Preview and Other Notes

I am optimistic that one of the popular static site generators can help me reach my goals for an improved Sawppy documentation site. But the site generator itself is not enough, there are a few other details I’ll have to investigate. The primary one being ability to preview changes to pages earlier rather than later in the pipeline.

Today’s flow of editing markdown files can deliver immediate feedback because GitHub has a “Preview” tab on its built in Markdown editor. But once we’re no longer directly using GitHub’s simple Markdown transformation, we’ll lose that ability. Contributors should not be expected to set up a SSG environment on their computer in order to see the results of their work, and asking maintainers to review every change on their own SSG environment would not scale. (I say this using plural as if Sawppy has a big maintenance staff… it’s actually just me.)

The answer is to bring in tools from the continuous integration world, where tools exist to preview changes to a website before deploying live. Some use services like Netlify, which is not itself open source but there is a free tier available.

One example: look at the repository for Write the Docs website. Open one of the pending pull requests and click on “Show all checks”. One of them is “Read the Docs build succeeded!” and clicking “Details” will bring up a version of the site built with changes in the pull request. This is an interesting venue of investigation to learn more about.

This was the point where I ran out of steam, and the Write the Docs meeting ran out of time, but I have a big treasure trove of pointers to investigate and keep me busy for a while.

Other miscellaneous notes:

Sawppy Documentation Suggestion: Static Site Generators

I’m glad I had the chance to learn about terminology and tools of industrial-strength documentation. They are great for their respective niches, but adopting any of them would require major changes and I’m not ready to take such a big leap just yet. Which brings us to static site generators. (SSG) This category of software tools see a lot of open source development, giving us many options to choose from.

Background: As input, SSGs take content in various formats. A set of rules and templates are applied to that content, generating as output a set of HTML and CSS (and maybe JavaScript) files that can be served by any web server. “Static” in this context means the web server does not have to run any code to modify the files, they are transmitted directly to users’ web browsers as-is. (As opposed to a dynamic systems like PHP.)

A large number of SSGs accept Markdown as a text content input format, so Sawppy’s existing Markdown documentation could be used with small modifications rather than complete rewrites. This also preserves the advantages of using Markdown, meeting the ease-of-use challenges A and B.

Every SSG offers customization of the rules and templates that it applies to content. At the minimum there are themes for cosmetic appearance, but plugins and extensions allow more extensive functionality. This is where I hope to create something that meets my challenge C including a lightweight BOM tool. Around this point Eric spoke up that the JPL Open Source Rover documentation system has a script that generates parts list from document content, but the generated dependency tree is not exposed to the viewer. I want to build upon that precedent and also make this kind of information available to rover builders.

To be pedantic, Sawppy documentation is already using a SSG because GitHub does not display raw Markdown files. A simple transformation to HTML has been applied for display. However, the reason I started this investigation is because the simple GitHub transformation is very limited. GitHub is aware of this, and as an upgrade, has built-in support for a SSG called Jekyll for generating GitHub Pages.

As another example, most of us had experience reading technical software documentation on some subdomain of ReadTheDocs. All of these content were generated by a SSG. MkDocs and Sphinx are two popular SSGs for ReadTheDocs, and a lot of the default functionality (automatic indexing, references, etc.) useful for technical software documentation would be useful for Sawppy as well.

But features like a lightweight BOM tool would be outside the scope of software documentation, so there were several recommendations for investigating Hugo. It is apparently the current darling for flexibly transforming content (including Markdown text) into varying different presentations. Associated with Hugo is Docsy, a Hugo theme focused on technical documentation.

Hugo and Docsy would be a bigger step up in complexity than something like Jekyll, but I’m optimistic that the benefit will justify the cost. I plan to use that as my starting point and expand my experimentation from there. But they’ll only be a part of the solution, because no matter the static generator I use I will still want a way to preview changes.

Sawppy Documentation Suggestion: BOM and UML

I had the dream of a documentation system for Sawppy that doesn’t seem to fit anything out-of-the-box, but I had the chance to ask a group of documentation experts for what they thought might apply. It looks like DITA is the super flexible Swiss army knife for documentation. It is a free open standard, but the only freely available DITA software tool I could find works at a low level and I would have to put in a lot of time to build up the system I dream of. In addition, some of the problems I wanted to solve edge into other well-established problem areas.

Bill of Materials

Similar to documentation, the challenge of tracking parts and components is well-tread ground for engineering projects. People at the meeting with industry experience suggested a few terms. MRP or Materials Resource & Planning was one, plus several variants on BOM or Bill of Materials. This area is big business! Sadly free open source tools are scarce. Someone gave a pointer to but upon further research I was disappointed to find that despite the name, this tool is not actually open.

That leaves us with few choices between “use a spreadsheet” and big ticket enterprise software. Even if numerous choices were available, such tools are focused on a very small subset of the overall problem. I do want to set up some kind of parts management, but bringing in a full fledged BOM tool adds a lot of complexity I’m not sure is justified for a small scale project like Sawppy.

Model All The Things

I had the same concern about another series of suggestions: fully model everything about Sawppy using a modeling language like SysML or PlantUML. I agree doing so will result in a complete picture, breaking down every part of the rover project. Such data could then feed into software packages that generate visualizations plotting dependencies between components. That sounds good, but the amount of work also felt disproportionate to the benefit it would bring to a project of this scale.

What I hoped would be a better fit for a project of Sawppy’s scale are the documentation systems already available for open-source software projects. While they would not have some of the hardware-focused features — such as BOM or UML above — they are more approachable than DITA and promise to be amenable to customizations. Perhaps even to give a lightweight subset of big BOM and UML tools.

Sawppy Documentation Suggestion: DITA

I outlined my Sawppy project and the challenges I want to tackle to the combined Write the Docs LA/SGVLUG meetup on the evening of October 8th. Sawppy’s current system of a loose set of Markdown files score highly on ease of contribution (challenge A) and ease of management (challenge B), but fall flat on querying dependencies (challenge C). What can I look into that helps improve information presentation without giving up the rest?

Fundamentally speaking, challenge C is not new, as it would be desirable in any large scale engineering project. The novel twist here is the desire to do it all with a system that is inviting for public contribution. As a general rule, documentarians for large engineering projects are professionals who have undergone training and have licenses for proprietary software tools.


Most such tools are excluded from consideration due to cost, but many of them deal with DITA, an open XML-based data model for authoring and publishing under the custody of the OASIS consortium. It is the standard answer to reassure customers wary of being locked in to proprietary file formats. And since it is an open format, there exists a DITA Open Toolkit to transform DITA data to desired output formats… HTML, PDF, even Markdown! There are learning resources at

As a XML (and thus text) based format, DITA would be GitHub friendly for branching and merging. It is very flexible for creating any organization we want (creating a “Subject Schema” for DITA) but taking advantage of that power will take work. DITA Open Toolkit functions at a lower level relative to the other tools discussed later. A quick web search found many commercial offerings built on DITA (example: but failed to find free open source counterpart.

So DITA is powerful, but that power comes at a cost, and I’ll have to decide if the cost/benefit analysis comes out in favor. This also applies to several other professional documentation concepts.