Upgrading M.2 SSD on Luggable PC

When Luggable PC Mark II was constructed in Fall 2017, the industry was experiencing a shortage of flash memory. Most of the fabrication facilities were switching to over to make the next generation “3D NAND” flash, following the lead of industry leaders like Samsung who got their 3D NAND flash up and running first. Taking fabs offline meant a shortage in supply and, with the technical glitches that always come with a big upgrade, the shortage in supply started driving prices upwards.

Industry news sources estimated the supply crunch will ease sometime around first quarter of 2018. So used a 256GB M.2 SSD already on hand for the project expecting to upgrade later. Well, it’s the end of 1Q2018 and prices have indeed started dropping. 256 was getting awfully cramped so even though prices are likely to drop further, today it has dropped enough for impatience to win out. Time to double the capacity with a WDS500G2B0B.

This is a unit from Western Digital’s Blue line, the economy alternative to their high performance Black line. From a technical perspective, the biggest differentiation is the NVMe interface used in the Black line. We won’t get top of the line performance with a Blue drive, and ~500GB can still feel cramped at times, but it’s enough elbow space while we wait for 1TB NVMe 3D NAND SSD prices to drop. (That’s a lot of acronyms all strung together…)

The Luggable PC chassis was originally designed for easy SSD replacement by cutting an access port in the back plane to make SSD accessible by removing the monitor. Unfortunately, complications were found after assembly, requiring extra clamps to keep the monitor in place. Which sadly also made it much more difficult to remove, defeating the purpose of the access port. We’re back to plan A, removing motherboard to replace the M.2 SSD underneath.

Four screws were removed so we could lift the center panel.

1 - Center panel removed

Taking a good look at the insides, we see that one of the monitor mounting screws has gone AWOL. We’ll have to replace it during re-assembly.

2 - screw missing

After the wireless network cables were detached, along with the four motherboard mounting screws, carefully lifting the motherboard exposed the M.2 SSD underneath for replacement.

3 - SSD accessible

With the SSD upgraded, the biggest remaining pain point is the old GPU. We’ve waited six months for the 3D NAND transition to ramp up and drop SSD prices. We’re still waiting for the cryptocurrency fad to blow over so we can get a reasonably priced GPU…

(Cross-posted to Hackaday.io)

Resolving Plex Update Failure in FreeNAS Jail “repository FreeBSD contains packages for wrong OS version”

plex-logo-e1446990678679I’ve been happily running Plex in a FreeNAS (FreeBSD) Jail for a while, picking up the periodic updates via “pkg update”. But now there’s a snag. Apparently a breaking change was introduced in a recent FreeNAS update and now binaries in the old jail are out of sync with the underlying operating system. The visible symptom is the following error message trying to run pkg update.

pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:11:amd64
Processing entries: 100%
Unable to update repository FreeBSD  
Error updating repositories!

Thankfully we get a detailed and specific error message. A web search using that error output found this discussion thread on FreeNAS user forums, which points to ixsystems issue tracker #27904. Reading the information, this break is not considered a bug in FreeNAS that will be fixed. Instead, the onus is on the user to manually update the jail (pointing to this page on how to do so) or to create a new jail.

After reading over the instructions on updating a jail, it seems easier to create a new jail and migrate my Plex server over to the new instance. None of the media need to be moved because they were a read-only mapping between directories on NAS volume and jail running Plex. It is simple to recreate the mapping after following FreeNAS manual for creating a new jail.

The only parts that needed moving were Plex server’s internal data, which Plex has documented here. Thankfully there are no tricky database operations involved – it is a straightforward copy operation to transfer from the old jail to the new one.

Once the new jail completed running pkg install plexmediaserver, a quick browse through Plex library seems to show everything is in order. The old Plex jail will be kept around in a non-running state for a while, just in case there’s something left behind in the move that we might want retrieve later.

Someone Put a USB Plug Inside a USB Plug

Today we point our spotlight at one method of supporting multiple USB plug form factors in the most compact layout possible: putting a (micro) USB plug inside a USB (type A) plug. It doesn’t look terribly robust or reliable for the long term, but it is indeed extremely compact and clever in its own Rube Goldberg way.

Gigastone 32GB USB Contraption

The mechanical engineer who devised this contraption took advantage of the fact a micro USB plug’s entire outer dimension is physically smaller than the “tongue” part of a USB type A plug. And conveniently, all the pins are electrically identical so they are easy to route. From there it’s a matter of creating the small sheet metal hinge for the exterior surround of type A portion of the plug so the user can swing it out of the way and expose the micro USB plug embedded within.

Usually smaller flash memory brands assemble their product from spot market purchases and other similar existing large volume products. Gigastone is not one of the bigger names.  Given this, the initial assumption (fair or not) was that this plug is a catalog item somewhere. But if so, it’s not obviously available from Digi-Key or Mouser.

Given the lack of immediately obvious source, we’ll tentatively assign credit for this clever design to Gigastone and their team behind this particular flash drive. Good job, guys, this item’s cleverness managed to stand it out amongst the crowd of commodity flash drive offerings.

SCaLE 16X Day 4: CTF Security Competition

The fourth and final day of Southern California Linux Expo (SCaLE) is a slower-paced and less intense day. Some attendees from out-of-town need to leave earlier to return to work Monday morning, and much of the rest are tired out by the preceding days. The E-ALE people are all gone, presumably to Portland, OR for their next training session at Embedded Linux Conference.

My personal education goal for the day is to understand more about “Capture the Flag” events that have been going on. I understand the idea is to make a fun competition for people to practice computer security concepts in a game arena, but the concrete details are still fuzzy. I’ve known that security CTF isn’t one thing – it’s a category that covers different implementations. And since it takes place on a computer, algorithms have joined the party. The highest profile event I knew about was a DARPA “Cyber Grand Challenge” where, instead of teams of people competing directly against each other, the teams compete indirectly by building AI software to compete against software written by other teams.

Penguin Red Flag2But the focus for SCaLE are about people, and not AI algorithms. The conference held three rounds of CTF hosting beginners, intermediate, and advanced competitors. Sadly I had a time mixup of my own fault and missed the beginner round that would have been the best fit. (SCaLE weekend happened to also be the weekend when daylight savings time switched over and not all clocks automatically adjusted.) The beginner and intermediate rounds were hosted using Facebook’s CTF platform. I wished I could have seen it in action and maybe even got some hands-on participation time, but at least I now know about Facebook’s CTF platform and can look into it later on Github.

As an alternate activity, I attended a talk titled “Gamify Security Training with Developer CTFs.” The subject of this talk was yet another variant on the CTF concept. Instead of an abstract competition arena and all teams competing with the same code, this particular competition was designed to be immediately relevant to the developer team by using their own product code. In effect, they were holding a CTF competition where they were trying to compromise their own commercial products. This particular event took a lot more effort to set up than run than something like the Facebook platform, but it was far more engaging to the participants and they found real product bugs to fix. It’s a great concept that can be well worth the higher up-front setup cost.

SCaLE 16X Day 3: Microsoft Was Not Boo-ed Out Of The Room

Well, I never thought I would see this – an engineer from Microsoft presents a keynote to open the third day of SCaLE and the crowd was completely civil about it. John Gossman of Microsoft Azure told the story of Microsoft’s evolving attitude to open-source software, in response to both external market forces and internal cultural change.

Gossman Keynote

John emphasized that open source advocates need not to take his word for Microsoft’s changing attitude towards open source. Judge Microsoft by its actions and, by the attitude of the crowd present, the attitude of open source advocates towards Microsoft has changed as well. (Though John asks people to skip their “hell has frozen over” jokes… he’s already heard them all.)

Personally I’ve seen a reduction in the religious zealotry that used to permeate these discussions. Many developers in the open source world now approach Microsoft in a strictly merit-based manner. The old instinctive animosity is gone… but the Microsoft brand itself isn’t a plus, either. If a Microsoft open-source offering can’t stand on its own merits, the pragmatic developer moves on. It’ll take a lot more work to earn admiration from this crowd.

Don’t discount the progress, though. Having seen some of the attitudes firsthand in the past (and still present in some of the graybeard of the crowd) there’s been a lot. In this context, going from animosity to apathy is a big and healthy step. Will Microsoft work its way up to admiration? We’ll have to stay tuned.

SCaLE 16X Day 2: More Fun With BaconBits Cape for PocketBeagle

The hardware component for Embedded Apprentice Linux Engineer (E-ALE) program is a PocketBeagle board paired with an accessory board named BaconBits. The PocketBeagle was released a few months ago and is now available for purchase from the usual retailers that cater to the electronic hobbyist & engineer market. BaconBits is more rare – this project was only recently completed to turn the PocketBeagle (which does very little by itself) into a development board for easy experimentation.

When we power up the PocketBeagle for this course, we are presented with an introductory screen offering to take us through a few tutorials that serve as an introduction to the world of physical world programming. In the interest of size and cost, the PocketBeagle  itself has very few physical peripherals, so interaction with the physical world requires wiring up external components.

BaconBits consolidates components required for many examples into a single circuit board so we won’t have to worry about breadboard wiring for the relevant exercises. From simple LED and potentiometer to peripherals beyond the basics. There’s an accelerometer available to practice I2C communication, and a 2-digit 7-segment LED to practice SPI communication.

PocketBeagle with BaconBits

What turned out to be the most important, at least in several E-ALE sessions, is the FTDI serial to USB bridge on board the cape. Serial console to the PocketBeagle is a lower-level interface and absolutely required when we got into the USB Gadget unit of the training. Configuring PocketBeagle’s USB behavior requires taking the existing USB functionality (network connection and mass storage) offline and replacing them with the interfaces in the labs. This means PocketBeagle’s HTTP-based Cloud9 IDE and other network-dependent connections like SSH won’t work. Low level serial is all we have left to communicate with PocketBeagle and work through exercises.

SCaLE 16X Day 1: Stumbled Into E-ALE Training

The 16th Southern California Linux Expo (SCaLE 16X) is underway. I attended SCaLE 15X last year but frankly I was too new to Linux to get very much out of it. With a year’s worth of Linux fiddling under my belt, I hope to learn more this time. At the very least, I know more of the words used in the session descriptions!

e-ale-logo-belly2-200xI had planned out a tentative schedule and the first session was a walk through of the PocketBeagle device. This turned out to be the start of a three-day course titled Embedded Apprentice Linux Engineer (E-ALE) that was an additional, separate $75 charge on top of the conference fee, which I was unaware of. Most of that additional charge goes towards the included hardware:

  • PocketBeagle with headers already soldered to its I/O pins.
  • BaconBits assembled and ready to plug into a PocketBeagle
  • MicroCenter-branded 16GB microSD card flashed with BeagleBone’s Debian distribution.
  • Two micro-USB cables.
  • One USB microSD card reader/writer

The parts and labor involved doesn’t quite add up to $75, but it’s close enough for me to decide to register on the spot. (Taking the final available slot.) This way I learn about embedded Linux and I’ll have a little pocket Linux computer to experiment and learn on.

I had thought the two micro-USB cables were redundant but they actually serve different purposes. One part of BaconBits is a serial over USB capability, and plugging in one cable to this port allows low-level serial communication to the PocketBeagle. The other micro USB port is on the PocketBeagle itself, where it presents its normal high-level network and mass storage device interfaces. Some of the exercises were made much easier by having both interfaces available.

PocketBeagle’s high-level web and mass-storage interfaces were straightforward, but I had little prior experience with low-level serial and stumbled a bit. The first (of many potential) solution that worked for me was to use minicom and configure it (minicom -s) to talk to the serial port /dev/ttyUSB0 at 115200 baud, 8/N/1. This was enough to read the output, but in order for my keyboard input to be acknowledged, I also had to turn OFF hardware flow control. Otherwise it would act as read-only without the ability to interact with serial prompt. Can’t follow along with the exercises that way!

For Cheap Commodity Bearings, Search For 608

My thoughts went to bearings while contemplating a mechanical project. I have the luxury of adjusting the design to fit a bearing thanks to the wonders of 3D printing. Given this flexibility, the obvious first path to investigate is to learn where to get bearings – cheap!

I’ve learned to not kill myself on a roller blade some years back, so I started looking for roller blade bearings based on the logic that there’s enough roller blade production volume – and each pair of blades use 16 bearings – to drop the price of bearings. I quickly found that skateboard wheels use the same size bearing, then I learned that fidget spinners also use the same size bearing.

608-bearingEventually I realized I had the logic backwards – these bearings are not cheap because they’re used in skates, they are used in skates because they were cheap. These bearings have been around far longer than any of those consumer products.

The industrial name for these mass volume commodity bearings seems to be “608“. The 60 designate a series (Google doesn’t seem to know the origin of this designation) and the 8 designate the interior diameter of the bearing. Letter suffixes after the 608 describe the type of seal around the bearings but does not change the physical dimensions.

Another misconception I had from roller blade advertising was the ABEC rating. It has come to imply smoother and faster bearings but technically it only describes the manufacturing tolerances involved. While higher ABEC rated bearings do reduce the tolerance range, that by itself does not necessarily mean faster bearings. There are more variables involved (the lubricant used inside, etc) but somebody decided the mechanical engineering details were too much for the average consumer to wade through, so its meaning was distorted for marketing. Oh well, it’s not the first time that has happened.

Such details may or may not be important, it depends on the project requirements. Strict project demands (temperature, speed, load, etc) will require digging deeper for those details. For projects where pretty much any bearing would do, the 608 designation is enough to guarantee physical dimensions for CAD design and we’re free to order something cheap. Either off Amazon (~$25 for 100 of them) or for even larger quantities, go straight to the factories on Alibaba.

Remo+ DoorCam Cleverly Solves Installation Challenges

Personally I’m on the skeptical side of the current smart home wave. The cost/benefit ratio still doesn’t work well enough to justify the purchase, with the single exception of a Nest Thermostat which has paid for itself by turning down the heat when I am away. But skepticism doesn’t prevent me from appreciating a clever design when I see it.

There’s been a few products that try to make a smart front door. From a digital keypad lock to a fully internet connected front door monitoring system. The problem is that most products require some sort of hardware (in the Home Depot sense) modification that is not always possible. For example people living in apartments are not allowed to replace locks, drill holes in the door, or run wires in the walls. A nondestructive stick-on solution outside the front door would meet those requirements, but is in turn vulnerable to theft.

As soon as I saw a picture of the Remo+ DoorCam I realized their proposed solution and its simplicity: hook it over the top of the door. This keeps the majority of electronics inside while still presenting the camera outside, and installation is a quick and easy job which does not require anything from a home improvement store. The design has some limitations on the thickness of door, and the camera lens is still vulnerable to vandalism, but thieves can’t just pull the whole unit and walk off with it.

Simple and effective: hallmarks of a cool innovative design.



Does PocketBeagle Need a Heat Sink? Probably Not.

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).

PocketBeagle Thermal Graph

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.

Noncontact PocketBeagle Temp

Launching a Flask Web App on Startup

flaskThe first few experiments with Flask has been successful. A simple user interface can be created in HTML and accessed from local as well as remote clients over HTTP. One of the downsides bit us today: a web app isn’t as easy to launch as a native local application. When running locally, we still need to get two parts up and running: the server-side code and the web browser pointing to http://localhost.

raspberry-pi-logoThis is especially problematic when the desire is to launch the app on power-up of the Raspberry Pi 3 that will run the server side. “Run on startup” is one of those tasks that have many different approaches across different flavors of Linux. Each with their advantages and disadvantages, benefits and gotchas.

The first attempt is to write a shell script that launches the Flask web server and the Chromium web browser. This works when executed interactively at the command line logged in as the default user pi. But it didn’t work when executed as a cron @reboot job, probably something to do with the fact it would run as root.

The next effort led to Raspberry Pi documentation, which pointed to the file /etc/rc.local. We seem to have better luck here – the Flask web server does launch but Chromium web browser still did not.

Further hunting eventually found this page for setting up a Raspberry Pi running Chromium web browser as a web kiosk. Not quite the project at hand, but close enough for the answer to be applicable. This meant leaving Flask startup in /etc/rc.local and editing the file /home/pi/.config/lxsession/LXDE-pi/autostart to have it launch chromium-browser with the parameter --kiosk http://localhost:5000/

Upon power-up, this Pi will now launch Flask web server and Chromium web browser to point at that server running on the same device. It works, but it’s not clear why these hoops were necessary. It’s pretty bewildering for a beginner to try to understand the why behind all these different startup mechanisms. A few hours of reading (sometimes contradictory) documentation did not make the situation any more clear. Sadly, time constraints dictate that we can’t get to the bottom of this issue today. Perhaps later.

Exploring Flask, a Python Web Framework

flaskToday’s exploration centers around Flask, a framework for building web sites with the Python programming language. The motivation was a new project that will be discussed separately, the important detail for now is that it needed to interact with some existing Python libraries and desired a user interface accessible from multiple different (and separate) devices. It seemed to make sense to turn the central device into a web server and expose the user interface to its clients using HTML.

There had been previous explorations into writing web server software using Ruby on Rails, which is not the best fit for this project. The first issue is the language – we need to talk to a Python library and there’s no need to jump through language translation layers for a simple project. The second issue is complexity – Rails is a full MVC framework for building an app on a database and we don’t need that here, either.

If we wanted the Python equivalent to Ruby on Rails, the popular choice of the day is Django. But since we don’t, Flask is the lighter-weight framework we’ll play with today. Sometime in the future, when a project is right for Django, we’ll explore using the right tool for the job.

Flask is a thin layer that’s a short step above having to call Python’s HTTP and URL classes directly, and can be very quick to get started.  A simple Hello World type of app requires only a single Python file and a few lines of code, no database configuration and project generation necessary. The developer builds up from this simple foundation. This is great for keeping things simple and easy to work with. For the most part, features that a developer would want can be added piecemeal.

The downside is that Flask also skips out on a lot of web practices that aren’t explicitly features, but are very nice to have by default. For example, the default Ruby on Rails generator for HTML <form> includes a token to prevent cross-site request forgery. This is not explicitly a feature a developer would think of adding, and could easily get overlooked especially when the forms are generated manually. Fortunately most of the Flask add-ons to generate forms – like this one – automatically includes CSRF protection.

Some caution would be warranted if the Flask application is going to be a public web site, but for a local network project prototype it should be good enough.

Twitter API Newbie Wades Into The Pool

Twitter DeveloperTwitter trends are easy to follow by searching for the hashtag. The default view given by Twitter shows the most popular tweets with that tag, and there are options to see the most recent tweets first, or browse them by photo, etc. But what if someone wants the tweets organized another way? Fortunately Twitter knows they can’t cover everybody’s desires and offers a developer API for those with creative ideas on tweets.

Twitter’s API is a “RESTful” design. It follows many of the ideas of REpresentational State Transfer (REST) but not strictly adhering to all of it. Functionally, it is built around HTTP GET and POST requests and returns information in the text-based JavaScript Object Notation (JSON) format. The details of those HTTP requests – and the JSON that it retrieves – are documented on Twitter’s developer site.

Before the aspiring Twitter app author can get anywhere, though, one needs to register with Twitter for access to these APIs. Once an app is registered, it is assigned a set of secret access keys and tokens. This allows Twitter to monitor usage and limit/disable Twitter access by individual applications.

Once registered, the code experimentation can begin. As a RESTful API communication via JSON, any web-friendly development framework can be used. (And if it is not web friendly… why would it have anything to do with Twitter?) As a starting point, Twitter has a non-exhaustive list of libraries that cater to different programming environments.

Out of this list, Python-Twitter was chosen as the first step into this world. Python language is fun and easy to experiment with. Python-Twitter installs easily via Python’s pip package manager. And yes – it also happens to be the first entry on the list.

A few commands into Python interactive console was rewarded with immediate results, though sadly also a few issues. Text of some tweets were truncated. Perhaps this has something to do with the recent increase in Twitter’s character limit? Whatever the root cause, it is tracked as an open issue in Python-Twitter’s repository.

The first few search queries returned only 15 results, even when there were definitely more than 15 answers. This turned out to be the default limit which is easily increased up to 100 results per search query. Going any further, unfortunately, is not possible with the standard search API. As of a few months ago, the only option to do more is to subscribe to the very expensive Twitter Enterprise API. This is out of the question for a hobbyist! Fortunately people have already complained and this past November Twitter responded with a premium search API to bridge the gap. Even though it is free, access is restricted so a registered developer has to apply for access.

Even if access is obtained, premium search is a new feature accessible via a new endpoint that is not yet supported by any of the Python libraries on Twitter’s list. Searching with a unique part of the API URL (“30day”) found this Python search tweet API that might be worth a look. If it doesn’t fit the bill for whatever reason, it might be time to build a custom solution.

Old ElectriFly Triton Sheds Light On Battery Condition

Today’s enlightenment comes courtesy of an old ElectriFly Triton battery charger unearthed from the dusty equipment shelf. This particular charger was purchased years ago to feed an interest in electric remote-control aircraft. At the time, the RC aircraft field was in a period of transition. The lowest-cost aircraft came with NiCad batteries, the mainstream used NiMH batteries, and the premium segments started adopting lithium-ion chemistries. To work in this world, the charger is designed to be used out at a remote control air park, hence it was designed to run on a 12 volt lead-acid battery instead of an AC outlet that might not be at the airfield.

Born into this confusion, the Triton charger was a jack of all trades. It knows how to properly charge all of the above types of batteries. It even has the capability to do a charge/discharge cycle to measure capacity. The latest models appears to have picked up even more features, but this old one is already on hand and can tell us interesting things.

Triton was first used to quantify behavior of an old 12Ah lead-acid battery dug up for solar panel investigation. It had discharged down to 6V while in storage and its voltage curve did not behave as expected. The good new is that even degraded, Triton deemed it within acceptable behavior range for a lead-acid battery. The bad news: Triton discharge test added up to only about 3.5Ah of usable capacity remaining out of the original 12Ah. There might be interesting projects where a degraded lead-acid battery can be useful, but it’s equally likely to end up in battery recycle.

After the old lead-acid battery was examined, the Triton was employed for the NiCad battery cells pulled out of the recent Dustbuster project. These cells suffered from chronic overcharging and exhibited depressed voltage levels when trying to deliver the current demanded by the Dustbuster motor. This condition might possibly be cured by individually charging and discharging the cell multiple cycles according to NiCad best practices, but that didn’t seem worth the expense of buying a NiCad charger/discharger. Fortunately, with the rediscovery of the Triton, we now have one. We’ll see if these NiCad cells can be recovered to a point to be useful for future projects, or if they should just go into battery recycle.

Triton NiCad

DSO 138 Simple Case by chibikuma2

The DSO 138 purchase was ultimately decided by seeing one in person, assembled by a local maker. That unit was first encased in an acrylic case, which cracked under use and was replaced by a 3D-printed case. Learning from the pioneer’s experience, I’ll skip the acrylic case and go straight to the 3D-printed one. If it works out, I’ll have something useful to protect the DSO 138. If it doesn’t, at least I could see one in action and decide what improvements to make.

The printer is the Monoprice Maker Ultimate, and the STL files were sliced into G-Code using Cura 3.1, printed on top of a Cura-generated raft.

DSO138 Case Bits

The author of this particular case is Thingiverse user “chibikuma2“. And the dimensions of the design looked good – all the pieces lined up well with parts on the DSO 138. The top and bottom parts of the case is held by friction. There were no fasteners and no clasps or hooks. 3D printers with loose XY accuracy may have problems creating this tight fit – if the XY “ooze” is too large, the pieces would not fit together at all. And conversely, if the printer under-extrudes, the two halves would be too loose to hold together.

The fit is good enough on the Maker Ultimate printer to fit together tightly. Once assembled, a putty knife or similar tool would be needed to pry the halves apart again.

The other printer performance dependency is first-layer performance. The labels for the controls in this design were done as lettering recessed into the surface. For these words to be legible, the first layer must be accurately positioned since slight movements are enough to spoil the lettering. Cura’s raft is what I usually use when first layer is important, sadly in this particular case it was not enough.

DSO138 Case Reset

The lettering is cosmetic, but there’s also a functional requirement for first layer precision: the 3D printed sliders that cap over the multi position switches on the DSO 138. The square hole at the base must match up to the square peg on the switches. If the holes are too large, there will be unpleasant slop in switch operation. If the holes are too small, the slider would not fit. Again this printer fell short of ideal, and had to be cleaned up with a small sharp blade.

DSO138 Case Slider

This is a decently functional case for the DSO 138, but this experience has motivated thinking towards creating a different design. Some items on the feature wish list are:

  • Move away from 3D-printed lettering. We have a label maker and we’re not afraid to use it.
  • Expose the loop of wire that generates the test square wave form.
  • Include a battery pack to supply the 9-12V DC power, with associated auxiliary components like an on/off switch.
  • A removable screen cover to protect the screen while in transit.
  • Storage for the probes.

DSO 138 Oscilloscope Kit by JYE Tech

An oscilloscope has been on the tool wish list for a while, but good ones are really expensive. But occasionally a simple basic scope would have been better than no scope at all, which is where today’s project comes into the picture.

JYE Tech makes the DSO 138 oscilloscope kit perfect for electronics hobbyists who can make use of a simple scope and also willing to put in the time and effort to assemble one out of a kit. The kit is available at a very low-cost, a fair exchange for making their customers do their own assembly.

This product is popular enough to spawn counterfeit copycats, which was a concern. Not just out of fear of a problematic product, but also the desire to support the original authors. Fortunately JYE Tech offers the option to send in the serial number for authenticity validation. The serial number of this unit purchased from Amazon vendor Kuman checked out as authentic.

There are two versions of the kit that differ by their treatment of surface-mount components: pre-installed or not. This particular example is the variant with surface mount pieces already installed, the customer just has to take care of the remaining through-hole parts. All those parts to be soldered came in a single bag and had to be sorted and identified before assembly could begin.

DSO138 parts sorted

The instructions were straightforward enough for someone already familiar with basic electronics soldering. The only complaint with this kit is that some of the mount points were not designed for easy soldering. They connect directly to large pieces of copper trace that acted as a huge heat sink making it difficult to bring the solder joint up to temperature. It would have been nice if they etched a little more. Leave one contact sufficient to carry the current, and etched around the rest to serve as a thermal break.

Apart from that minor complaint, the soldering was not difficult, only tedious. The electronics hobbyist is reminded why manual assembly of circuit boards is not considered a great career. This particular example took roughly four hours to assemble. Thankfully, when power was connected, everything started running as they should. Here is the assembled DSO 138, showing the built-in square wave test signal.

DSO138 complete

A few simple tests followed the self test, clearly showing some limits of this little oscilloscope. For one thing, the voltage scale is quite unreliable. An AA battery at 1.22 volts (according to the Fluke multi meter) was interpreted by this oscilloscope as 1.67 volts. But we didn’t get this thing to read voltages – we want to use it to graph wave forms that we couldn’t see with a multi meter. (UPDATE: On the advice of the local maker who built a DSO 138 before I did, I ran the calibration routine to align Vpos with zero volt and now voltage levels are much closer to the Fluke meter readings.)

It’s now part of the toolbox. Thanks to its low-cost, it wouldn’t take much data to throw it in either of these two buckets:

  • Positive: “That was so much easier to diagnose with a scope, even a simple one. This was well worth the money.”
  • Negative: “The inaccuracy of the scope led us down the wrong diagnosis path. This was a waste of both time and money.”

While we wait for the verdict to come in, let’s work on an enclosure for this device.


Dell XPS M1330 Battery Pack Teardown

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.

Corroded 18650

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:

  1. Best case: The metals dissolved into the electrolyte will hamper chemical reaction, resulting in reduced capacity.
  2. 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.)
  3. 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.

Dell XPS M1330 Power Port Salvaged Using Desoldering Tool

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.

Dell Octagonal PowerThe 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.

Desoldering Tool

A test with the voltage meter confirmed this port is now ready to be used to provide ~19V DC power to a future project.

Socket Extraction Success


WebAssembly: A High Level Take On Low Level Concepts

webassemblyWebAssembly takes the concepts of low-level assembly language and brings them to web browsers. A likely first question is “Why would anybody want to do that?” And the short answer is: “Because not everybody loves JavaScript.”

People writing service-side “back-end” code have many options on technologies to use. There are multiple web application platforms that are built around different languages. Ruby on Rails and SinatraDjango and Flask, PHP, Node.JS, the list goes on.

In contrast, client-side “front end” code running on the user’s web browser has a far more limited choice in tools and only a single choice for language: JavaScript. The language we know today was not designed with all of its features and capabilities up front. It was a more organic growth that evolved alongside the web.

There have been multiple efforts to tame the tangle that is modern JavaScript and impose some structure. The Ruby school of thought led to CoffeeScript. Microsoft came up with TypeScript. Google invented Dart. What they all had in common was that none have direct browser support like JavaScript. As a result, they all trans-compile into JavaScript for actual execution on the browser.

Such an approach does address problems with JavaScript syntax, by staying within well-defined boundaries. Modern web browsers’ JavaScript engines have learned to look for and take advantage of such structure, enabling the resulting code to run faster. A project focused entirely on this aspect – making JavaScript easy for browsers to run fast – is asm.js. By limiting JavaScript to a very specific subset , sometimes adding hints to the browser it is so, allows JavaScript that can be parsed down to very small and efficient code. Even if it ends up being very difficult for a human to read.

Projects like asm.js make the resulting code run faster than general JavaScript, but that’s only once code starts running. Before it runs, it is still JavaScript transmitted over the network, and JavaScript that needs to be parsed and processed. The only way to reduce this overhead is to describe computation at a very low-level in a manner more compact and concise than JavaScript. This is WebAssembly.

No web developer is expected to hand-write WebAssembly on a regular basis. But once WebAssembly adoption takes hold across the major browsers (and it seems to be making good progress) it opens up the field of front-end code. Google is unlikely to build TypeScript into Chrome. Microsoft is unlikely to build Dart into Edge. Mozilla is not going to bother with CoffeeScript. But if they all agree on supporting WebAssembly, all of those languages – and more – can be built on top of WebAssembly.

The concept can be taken beyond individual programming languages to entire application frameworks. One demonstration of WebAssembly’s potential runs the Unity 3D game engine, purportedly with smaller download size and faster startup than the previous asm.js implementation.

An individual front end web developer has little direct need for WebAssembly today. But if it takes off, it has the potential to enable serious changes in the front end space. Possibly more interesting than anything since… well, JavaScript itself.

Remove Camera From Acer Aspire Switch 10

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.

Acer Aspire Switch 10 Blinded

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.