Several frames from Bad Apple

PineTime Smartwatch And Good Code Play Bad Apple

PineTime is the open smartwatch from our friends at Pine64. [TT-392] wanted to prove the hardware can play a full-motion music video, and they are correct, to a point. When you watch the video below, you should notice the monochromatic animation maintaining a healthy framerate, and there lies all the hard work. Without any modifications, video would top out at approximately eight frames per second.

To convert an MP4, you need to break it down into images, which will strip out the sound. Next, you load them into the Linux-only video processor, which looks for clusters of pixels that need changing and ignores the static ones. Relevant pixel selection takes some of the load off the data running to the display and boosts the fps since you don’t waste time reminding it that a block of black pixels should stay the way they are. Lastly, the process will compress everything to fit it into the watch’s onboard memory. Even though it is a few minutes of black and white pictures, compiling can take a couple of hours.

You will need access to the watch’s innards, so hopefully, you have the developer kit or don’t mind cracking the seal. Who are we kidding, you aren’t here for intact warranties. The video resides in the flash chip and you have to transfer blocks one at a time. Bad Apple needs fourteen, so you may want to practice on a shorter video. Lastly, the core memory needs some updating to play correctly. Now you can sit back and…watch.

Pine64 had a rough start with the single-board computers, but they’re earning our trust with things like soldering irons and Google-less Linux mobile phones.

Continue reading “PineTime Smartwatch And Good Code Play Bad Apple”

A Good, Hard Look At Pre-Stressed Concrete

From the looks of the average driveway or sidewalk, it may seem as though concrete is just destined to crack. But if concrete is so prone to cracking, how are we able to use it in so many high-stress applications like bridges and skyscrapers? This question came about while I was researching 3D-printed thermite for an article. Thermite is often used in welding railroad tracks, and I linked a video of fresh tracks being welded that had concrete ties. I knew I had to find out how concrete could be made to withstand the pressure of freight trains.

On its own, concrete is brittle and has no give to it at all. But that doesn’t mean it isn’t strong. Although concrete has good compression strength, the tensile strength is quite poor. Around the late 1800s, someone thought to fortify spans of concrete with steel reinforcing bars, better known as rebar. Steel can stretch, adding steel bars gives the concrete some tensile strength to go along with its compressive strength. Rebar also allows for thinner slabs and other members.

Rebar Only Goes So Far

Parking blocks are meant to be replaced occasionally. Image via Checkers Safety

Rebar or mesh-enforced concrete is good for things like parking lot blocks and roads, but it still fails before it ought to. In fact, it usually has to crack before the rebar can chip in any of its tensile strength.

In high-stress concrete applications like bridges and skyscrapers, it’s terrifically important to avoid deflection — that’s when a concrete member flexes and bends under load. Deflection can cause the modern glass skins to pop off of skyscrapers, among other problems.

A solid, rigid bridge is much nicer to walk, drive, and bicycle on than a bridge that sways in the breeze. But how do you do make a rigid bridge? One solution is to apply stresses to the concrete before it ever bears the load of cars and trucks or a steady schedule of freight trains.

Pre-stressed concrete is like rebar-enforced concrete, but with the added power of tension baked in. By adding stress to the concrete before it goes into service, deflection will be reduced or perhaps eliminated altogether. With the addition of tensile strength, more of the concrete’s own strength is able to come into play.

Continue reading “A Good, Hard Look At Pre-Stressed Concrete”

Table Held Up By Strings Teaches Physics

If you’ve never heard of a tensegrity structure, you should stop now and watch the video below. In it, [The Action Lab] shows a 3D printed table that is held up only with strings. We didn’t say suspended by strings but held up. Or so it appears. The model is from Thingiverse, but it is one of those things you have to see to believe.

The basic idea is pretty simple. Strings have a lot of tensile strength but collapse under the slightest compressive force. The arrangement of strings puts the force on the center string which is essentially hanging — the force is pulling the string down. The other three strings aren’t just for show, though, they keep the structure from tipping over in any one direction.

There are actually real-life examples of these kinds of structures. The video shows the Skylon at the Festival of Britain as one example and an Australian bridge. The video also makes the point that the human body uses tensegrity, since tendons are very similar to the strings in the model.

This would be a great experiment for a homeschooler or even kids cooped up in quarantine. The print itself doesn’t look very challenging, although the assembly might be a bit tricky.

This isn’t the first structure like this that we’ve seen. If the talk about tendons makes you think this might be useful in robotics, you’d be correct.

Continue reading “Table Held Up By Strings Teaches Physics”

Does Library Bloat Make Your Smartphone App Look Fat?

While earlier smartphones seemed to manage well enough with individual applications that only weighed in at a few megabytes, a perusal of the modern smartphone software store uncovers some positively monstrous file sizes. The fact that we’ve become accustomed to mobile applications requiring 100+ MB downloads on what’s often a metered Internet connection in only a few short years is pretty crazy if you stop to think about it.

Seeing reports that the Nest app for iOS tipped the scales at nearly 250 MB, [Alexandre Colucci] decided to investigate. On his blog he not only documents the process of taking the application apart piece by piece to find out just what’s eating up all that space, but lists some potential fixes which could shave a bit off the top. Even if you aren’t planning a spelunking expedition into your pocket supercomputer’s particular variant of the Netflix app, the methodology and tools he uses here are fascinating in their own right and might be something worth adding to your software bag of tricks.

By passing the application’s files through a disk usage visualizer called GrandPerspective, [Alexandre] immediately identified some rather large blocks of content. The bundled Apple Watch version of the app takes up 23 MB, video and audio used to walk the user through the device setup weigh in at 22 MB, and localization files for various languages consumes a surprising 33 MB. But the biggest single contributor to the application’s heft is the assorted libraries and frameworks which total up to an incredible 67 MB.

Of course the question is, how much of it is really necessary? It’s hard to be sure from an outsider’s perspective, but [Alexandre] notes that a few of the libraries used seem to be redundant or obsolete. In some cases this could be the result of old code still lurking in the project, but the four different libraries used for user tracking probably aren’t in there by accident. It also stands to reason that the instructional videos could be offloaded to something like YouTube, so that only users who need to view them have to expend their bandwidth on it.

Getting a little deeper into things, [Alexandre] notes that some of the localization images appear to be redundant. As a specific example, he points to the images of the Nest itself displaying Fahrenheit and Celsius temperatures. While logically this should only be two image files, there are actually eight copies of the Celsius image, each filed away as language-specific. These redundant localization images could easily be stripped out, but with gains measured in only a few hundred kilobytes, it probably wasn’t considered worth the effort during development.

In the end there’s really not as much bloat as we might like to believe. There were some redundant files, maybe a few questionable library inclusions, and the Apple Watch version of the app could surely be separated out. All together, it might get you a savings of 30 – 40%, but still not enough to bring it down under 100 MB.

All signs point to the fact that modern smartphone software development is just a lot more burdensome than us hackers might like. Save for projects looking to put control back into the hand’s of the users, it looks like mobile operating systems aren’t going to be slimming down anytime soon.

A Real Time Data Compression Technique

With more and more embedded systems being connected, sending state information from one machine to another has become more common. However, sending large packets of data around on the network can be bad both for bandwidth consumption and for power usage. Sure, if you are talking between two PCs connected with a gigabit LAN and powered from the wall, just shoot that 100 Kbyte packet across the network 10 times a second. But if you want to be more efficient, you may find this trick useful.

As a thought experiment, I’m going to posit a system that has a database of state information that has 1,000 items in it. It looks like an array of RECORDs:

typedef struct
{
  short topic;
  int data;
} RECORD;

It doesn’t really matter what the topics and the data are. It doesn’t really matter if your state information looks like this at all, really. This is just an example. Given that it is state information, we are going to make an important assumption, though. Most of the data doesn’t change frequently. What most and frequently mean could be debated, of course. But the idea is that if I’m sending data every half second or whatever, that a large amount isn’t going to change between one send and the next.

Continue reading “A Real Time Data Compression Technique”

Stretching My Skills: How (and Why) I Made My Own Compression Sleeves

Have you ever noticed how “one size fits all” often means “one size poorly fits all”? This became especially clear to me when I started using a compression sleeve on my arm. Like any hacker, this seemed like something I could fix, so I gave it a shot. Boy, did I learn a lot in the process.

A little over a year ago, I started dropping things. If I was holding something in my left hand, chances were good that it would suddenly be on the ground. This phenomenon was soon accompanied by pain and numbness, particularly after banging on a keyboard all day.

At best, my pinky and ring fingers were tired all the time and felt half dead. At worst, pain radiated from my armpit all the way to my fingertips. It felt like my arm had been electrocuted. Long story short, I saw a neurologist or two, and several co-pays later I had a diagnosis: cubital tunnel syndrome.

Continue reading “Stretching My Skills: How (and Why) I Made My Own Compression Sleeves”

Mechanisms: Mechanical Seals

On the face of it, keeping fluids contained seems like a simple job. Your fridge alone probably has a dozen or more trivial examples of liquids being successfully kept where they belong, whether it’s the plastic lid on last night’s leftovers or the top on the jug of milk. But deeper down in the bowels of the fridge, like inside the compressor or where the water line for the icemaker is attached, are more complex and interesting mechanisms for keeping fluids contained. That’s the job of seals, the next topic in our series on mechanisms.

Continue reading “Mechanisms: Mechanical Seals”