In a project, repetitive tasks that break the flow of development work are incredibly tiresome and even simple automation can make a world of difference. [Simon Merrett] ran into exactly this while testing different stepper motors in a strain-wave gear project. The system that drives the motor accepts G-Code, but he got fed up with the overhead needed just to make a stepper rotate for a bit on demand. His solution? A grbl man-in-the-middle jog pendant that consists of not much more than a rotary encoder and an Arduino Nano. The unit dutifully passes through any commands received from a host controller, but if the encoder knob is turned it sends custom G-Code allowing [Simon] to dial in a bit acceleration-controlled motor rotation on demand. A brief demo video is below, which gives an idea of how much easier it is to focus on the nuts-and-bolts end of hardware when some simple motor movement is just a knob twist away.
If you’ve read about Meltdown, you might have thought, “how likely is that to actually happen?” You can more easily judge for yourself by looking at the code available on GitHub. The Linux software is just proof of concept, but it both shows what could happen and — in a way — illustrates some of the difficulties in making this work. There are also two videos in the repository that show spying on password input and dumping physical memory.
The interesting thing is that there are a lot of things that will stop the demos from working. For example a slow CPU, a CPU without out-of-order execution, or an imprecise high-resolution timer. This is apparently especially problematic in virtual machines.
Those who fancy themselves as infrastructure nerds find cell sites fascinating. They’re outposts of infrastructure wedged into almost any place that can provide enough elevation to cover whatever gap might exist in a carrier’s coverage map. But they’re usually locked behind imposing doors and fences with signs warning of serious penalty for unauthorized access, and so we usually have to settle for admiring them from afar.
Some folks, like [Mike Fisher] aka [MrMobile], have connections, though, and get to take an up close and personal tour of a couple of cell sites. And while the video below is far from detailed enough to truly satisfy most of the Hackaday crowd, it’s enough to whet the appetite and show off a little of what goes into building out a modern cell site. [Mike] somehow got AT&T to take him up to a cell site mounted in the belfry and steeple of the 178-year old Unitarian Church in Duxbury, Massachusetts. He got to poke around everything from the equipment shack with its fiber backhaul gear and backup power supplies to the fiberglass radome shaped to look like the original steeple that now houses the antennas.
Next he drove up to Mount Washington in New Hampshire, the highest point in the northeast US and home to a lot of wireless infrastructure. Known for having some of the worst weather in the world and with a recent low of -36°F (-38°C) to prove it, Mount Washington is brutal on infrastructure, to which the tattered condition of the microwave backhaul radomes attests.
We appreciate the effort that went into this video, but again, [Mike] leaves us wanting more details. Luckily, we’ve got an article that does just that.
One of the things we like about ARM processors is that there are a variety of options for library support. You can write your own code at the bare metal, of course, but you can also use many different abstraction libraries to make things easier. At the other end of the spectrum, there is Mbed, similar to the sort of libraries that Arduino supplies. Easy to use, although not always the best possible performance. Mbed now has an Mbed Labs site with a lot of extra goodies that go with the Mbed ecosystem, and it has quite a few interesting things.
You’ve always been able to write Mbed code in your browser — some people love that and some hate it and use locally-hosted tools like Platform.io. However, with the Mbed Lab, you can build and most importantly simulate your code in the browser (something we covered last year). There’s also a Javascript interpreter that runs on your chip, a small implementation of TensorFlow for deep learning, and a few other projects on the page.
Here’s a fun entry into our coin cell challenge. The power source is the actuating force in [Frank]’s blinky LED Christmas tree, which takes advantage of the physical structure of coin cells and our old pal gravity to roll out some holiday cheer. Talk about forward voltage!
We love the concept, and the circuit couldn’t be more simple. A coin cell is released at the top of the tree and rolls down a series of angled foam board railings covered with 1/4″ copper tape. As the coin cell travels, the negative terminal shimmies along the face of the tree, which has corresponding ground rail tapes. There’s no microcontroller here—all that’s needed for blinks are breaks in the negative rail tape.
The challenging part of a project like this is the execution. Getting a coin cell to ride the rails without falling off required angle experimentation prior to and during the build. Now that it’s done, keeping the tree tilted back against the wall is key. [Frank] explored several options for returning the coin cell to the top using a camera motor and the gear assembly from an old inkjet, but for now, his six-year-old does the job without complaint. Check out his work ethic after the break.
Hackaday reader [Don] dropped by the tip line recently to let us know about the latest version of his color-changing LCD clock project. This is his second version of the hardware which makes some pretty big improvements over the original, including moving from the Pi B to the Pi Zero and an internal simplification of the wiring. He mentions the next revision of the project will focus on Google Home integration, which should be interesting to see.
As a father of two pre-school age children, he was looking for a way to help his kids understand the concept of time and scheduled activities. Colors and shapes come fairly easy to children of this age, but time and how it relates to the day is a bit more difficult for them especially as their comprehension of numbers is still developing. [Don] reasoned that even if they couldn’t read the numbers on the clock yet, if he had the display change colors to indicate different periods of the day (sleep, play, cleanup, etc), it would not only keep them on schedule, but reinforce the meaning of the numbers on the screen.
The project was made infinitely easier by a lucky find at a local retailer. For $10 he got a kid-friendly looking clock that utilized a simple projector to backlight the LCD display. This meant [Don] would just need to swap out the stock lighting module for a controllable RGB LED, and the hardware modifications would essentially be complete.
Even the Pi Zero fits perfectly inside the case of the clock, the only modification necessary was cutting a little hole in the back for the Pi’s micro USB port. His earlier version used an external Pi B connected to the clock via CAT5, so getting it all integrated into the one device is a huge improvement, especially when little kids are involved. Moving the Pi and its 5 V pins into the clock itself also allowed [Don] to drop the voltage regulator required previously.
With the basic hardware for a color changing LCD clock together, the rest of the project was just a matter of software. After some research, [Don] came across RPi-ShiftBrite by [Hive13] and made his own fork which added some features necessary for his project, namely the ability to quickly set the ShiftBrite to a specific color on the command line. To schedule the color changes, he used the very slick minicron: a web-based tool to create and monitor Linux cron jobs.
The Pi itself does not actually interface with the clock, and with no onboard RTC it’s necessary to keep it updated with NTP or else the times will become desynchronized. It can be necessary to sync the Pi’s clock to the Internet as often as every hour to make sure the colors shift at the appropriate times. The addition of a RTC module like the DS1307 could alleviate this issue and might be something to consider for a future revision.
All told, a fantastic project and something we’ll be sure to keep our eyes on as it progresses. We’ve seen our share of unique Raspberry Pi powered clocks, and even a few color changing ones, but this approach is easily the most straight-forward we’ve seen.
It’s becoming abundantly clear that [Colin Merkel] doesn’t know the definition of “good enough”. Not only has he recently completed his third (and most impressive) wristwatch build, but he also managed to put together one of the most ridiculously romantic gifts ever conceived. While some of us are giving our significant others a gift card to Starbucks, he made his girlfriend a watch with a chart on the face representing the position of the stars at the time and place of their first meeting.
As per his usual style, the documentation on this build is phenomenal. If paging through his gallery of build images doesn’t make you want to get a lathe and start learning metal working, nothing will. A chunk of stainless steel rod miraculously becomes a gorgeous wrist watch over the course of a few dozen images, perfectly encapsulating that old adage of “making it look easy”.
Certainly the highlight of this build is the star chart on the face. To make it, he used PyEphem to plot the position of the brightest stars that were visible at the time and place of their first meeting. He then wrote a script to take those stars and convert their positions to G-Code the CNC could use to drill holes in the appropriate locations. The depth of the hole even corresponds to the magnitude (brightness) of each star, giving the chart a subtle 3D effect.
Unfortunately, [Colin] made a couple of mistakes during this build, to the point that he’s not exactly sure how to proceed. He mentions he might even be forced to start over from scratch. It’s hard to imagine how something that looks this good could ever end up being a failure, but the world of watch making is unkind.
To start with, he used 304 stainless instead of 303. This made machining the case much more difficult, and from his very first cut he realized it was going to be a problem. While it was an annoyance he mentions a couple times during the build log, he was at least was able to work through it.
The real problem came at the end, when he put the watch together. He originally made his designs assuming a front glass which was 0.5 mm thick, but in actuality used a piece that is 0.8 mm thick. This slight difference is just enough to cause the seconds hand to rub up on the glass, putting drag on the movement. The end result is that the battery dies extremely quickly, effectively rendering the watch useless.
We can’t imagine the heartbreak [Colin] felt when he realized what happened; we felt bad just reading about it. But given his track record, we have no doubt he’ll get the issue sorted out. It would be a shame to start over completely, but there’s some consolation in knowing it’s part of the learning process: you don’t become a master of your craft without making a couple mistakes along the way.