There’s a trend in corporate America that has employees wear a step counter — technically a pedometer — and compete in teams to see who can get the most number of steps. We wonder how many people attach the device to an electric drill and win the competition easily. However if you want to do your own measurements, [Ashish Choudhary] has plans for making a pedometer with an Arduino. The device isn’t tiny, but as you can see in the video below it seems to work.
For the extra size, you do get some features. For one, there is a 16×2 LCD display and an ADXL335 accelerometer, and you can probably imagine some other cool features for such a device.
Around these parts, seeing a classic laptop or desktop computer get revived with the Raspberry Pi is fairly common. While we’re not ones to turn down a well-executed Pi infusion, we know they can be controversial at times. There’s an impression that such projects are low-effort, and that the combination of old and new tech gains little in the way of usability due to the usability quirks of the Pi itself.
But we think even the most critical in the audience will agree that this build by [Tylinol], which sees the internals of a circa 1993 PowerBook 165c get replaced with that of a 2014 Mac Mini, is something else entirely. For one thing, there’s no question that packing a modern (relatively) desktop computer motherboard into a laptop’s body takes a lot more planning and effort than hot gluing the comparatively tiny Pi into the same space. Plus as an added bonus, anyone who counts themselves among the Cult of Mac will be happy to see the vintage machine retain its Cupertino pedigree.
So how do you get a Mac Mini inside of a PowerBook? Very carefully. As explained by [Tylinol], the inside of the PowerBook’s case was coated in graphite and conductive enough to be a problem. So after the original hardware was removed, a layer of tape was added to insulate it; though we imagine a suitably thick spray-on coating could be used as well if you don’t have that kind of patience.
Once the case was gutted and insulated, [Tylinol] added new stand-offs to mount the Mac Mini motherboard and hard drive. For anyone wondering, the 2014 model was used because the shape of the board almost perfectly fits around the trackball PCB. A board from a newer Mac could be used, but it would likely mean using an external mouse.
Which would have been a problem for [Tylinol], because one of the main goals of this build was to get the original input working. That meant adapting the Apple Desktop Bus (ADB) devices to USB, which turns out to be something of a Dark Art. But with the help of some contemporary information about the long-forgotten protocol and a Teensy 3.5, both devices are now picked up as standard USB HID.
But of course, that’s just scratching the surface. [Tylinol] also had to figure out how to swap the original display out for a modern panel, and then get the whole thing running on internal battery power. Even if you’re not particularly interested in retro Apple hardware, this is really a phenomenal build that deserves a thorough read-through.
Embarrassing confession time: I never learned my multiplication tables in grade school. Sure, I had the easy tables like the twos and the fives down, but if asked what 4 x 7 or 8 x 6 was, I’d draw a blank. As you can imagine, that made me a less than stellar math student, and I was especially handicapped on time-limited tests with lots of long multiplication problems. The standard algorithm is much faster when you’ve committed those tables to memory, as I discovered to my great woe.
I was reminded of this painful memory as I watched Charles Lohr’s 2019 Supercon talk on the usefulness and flexibility of lookup tables, or LUTs, and their ability to ease or even completely avoid computationally intensive operations. Of course most LUT implementations address problems somewhat more complex than multiplication tables, but they don’t have to. As Charles points out, even the tables of sines and logarithms that used to populate page after page in reference books have been ported to silicon, where looking up the correct answer based on user input is far easier than deriving the answer computationally.
Yes, this is a Minecraft server all thanks to LUTs.
One of the most interesting examples of how LUTs can achieve the seemingly impossible lies in an old project where Charles attempted to build a Minecraft server on an ATMega168. Sending chunks (the data representations of a portion of the game world) to clients is the essential job of a Minecraft server, and on normal machines that involves using data compression. Rather than trying to implement zlib on an 8-bit microcontroller, he turned to a LUT that just feeds the raw bytes to the client, without the server having the slightest idea what any of it means. A similar technique is used by some power inverters, which synthesize sine wave output by feeding one full cycle of values to a DAC from a byte array. It’s brute force, but it works.
Another fascinating and unexpected realization is that LUTs don’t necessarily have to be software. Some can be implemented in completely mechanical systems. Charles used the example of cams on a shaft; in a car’s engine, these represent the code needed to open and close valves at the right time for each cylinder. More complicated examples are the cams and gears once found in fire control computers for naval guns, or the programming cards used for Jacquard looms. He even tips his hat to the Wintergatan marble machine, with its large programming drum and pegs acting as a hardware LUT.
I found Charles’ talk wide-ranging and fascinating. Originally I thought it would be an FPGA-heavy talk, but he didn’t actually get to the FPGA-specific stuff until the very end. That worked out fine, though — just hearing about all the cool problems a LUT can solve was worth the price of admission.
And for the curious, yes, I did eventually end up memorizing the multiplication tables. Oddly, it only clicked for me after I started playing with numbers and seeing their relationships using my first calculator, which ironically enough probably used LUTs to calculate results.
All through the cold war, there was a high-stakes game of cat and mouse in play. Nuclear powers like the United States and the Soviet Union would hide submarines armed with nuclear missiles underwater. The other side would try to know where they were so they could be targeted in the event of war. The common wisdom was that the United States had many high tech gadgets to help track enemy submarines, but that the Soviet Union was way behind in this area. This was proven false when a Soviet Victor-class boat followed a US missile submarine for six days. Now, a recently declassified CIA report shows how the Soviets didn’t use sonar at all but developed their own technology.
There is something fascinating about submarines. Like an old sailing ship, submarines are often out of touch with their command bases and the captain is the final authority. Like a space ship, the submarine has to survive in an inimical environment. I guess in all three cases, the crew doesn’t just use technology, they depend on it.
Although the submarine has some non-military uses, there are probably more military subs than any other type. After all, a sub is as close to a cloaking device as any real-life military vehicle has ever had. Before modern technology offered ways to find submarines using sonar or magnetic anomalies, a completely submerged submarine was effectively invisible.
There was a lot of speculation that the Soviet Union lacked sufficient technology to use sonar the way the US did. However, in some cases, they had simply developed different types of detection — many of which the West had discarded as impractical.
Networked cameras keep making the news, and not in the best of ways. First it was compromised Ring accounts used for creepy pranks, and now it’s Xiaomi’s stale cache sending camera images to strangers! It’s not hard to imagine how such a flaw could happen: Xiaomi does some video feed transcoding in order to integrate with Google’s Hub service. When a transcoding slot is re-purposed from one camera to another, the old data stays in the buffer until it is replaced by the new camera’s feed. The root cause is probably the same as the random images shown when starting some 3D games.
Python is Dead, Long Live Python
Python 2 has finally reached End of Life. While there are many repercussions to this change, the security considerations are important too. The Python 2 environment will no longer receive updates, even if a severe security vulnerability is found. How often is a security vulnerability found in a language? Perhaps not very often, but the impact can be far-reaching. Let’s take, for instance, this 2016 bug in zipimport. It failed to sanitize the header of a ZIP file being processed, causing all the problems one would expect.
It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2. Continue reading “This Week In Security: Camera Feeds, Python 2, FPGAs”→
Hackaday editors Mike Szczys and Elliot Williams sort through all of the hacks to find the most interesting hardware projects you may have missed this week. Did you know you can use machine learning without a neural network? Here’s a project that does that on an ATtiny85. We also wrap our minds around a 3D-printed press brake, look at power-saving features of the ESP32 that make it better on a battery, and discuss the IoT coffee maker hack that’s so good it could be a stock feature. Plus we dive into naturally occurring nuclear reactors and admire the common, yet marvelous, bar code.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Sorry to bear sad tidings, but your car’s extended warranty is about to expire. At least that’s what you’ll likely hear if you answer one of those robocalls that have descended like a plague upon us. We applaud any effort to control the flood of robocalls, even if it means supplementing a commercial blocking service with a DIY ring-blocker.
The commercial service that [Jim] engaged to do his landline blocking is called Nomorobo – get it? It uses the Simultaneous Ringing feature many VoIP carriers support to intercept blacklisted robocallers, but with a catch: it needs caller ID data, so it lets the first ring go through. [Jim]’s box intercepts the ringing signal coming from his Xfinity modem using a full-wave rectifier and an analog input on an Arduino. Once the ring pattern is received, the Arduino flips a relay that connects all the phones in the house to the line, letting the call ring through. If Nomorobo has blocked the call, he’ll never hear a thing. There were a few glitches to deal with, like false positives from going off- and on-hook, but those were handled in software. There’s also a delay in displaying caller ID information on his phones, but it’s a small price to pay for peace.
Any escalation in the war on robocalls is justified, and we applaud [Jim] for his service. Should you feel like joining the fray, step one is to know your enemy. This primer on robocalling will help.
