A table saw is one of those tools that aren’t strictly necessary to have, but immensely helpful if you do happen to have one around. The folks at [I Build It] have made a three part series that features a homemade table saw build, so you can finally get around to adding one to your makerspace.

The build uses a real table saw arbor and is made from Baltic birch plywood and solid wood, with some plastic sheets for the trunnions and top. The blade is housed in a blade lift made out wooden panels with a pivot point and slot for the lift mechanism. Bearings allow the blade the freedom of movement, while a curved cutout allows it to stay flat against the wall of the slot while the blade lift mechanism moves.
Meanwhile a reused motor from a previous table saw is dusted, cleaned, and rewired to run in reverse. While most table saws only need two trunnions, a third is used for supporting the motor, since it has to move with the lift and tilt. Once the lift/tilt mechanism is complete, the frame for the table saw is more straightforward, with many steps involving clamping, measuring, cutting, fitting, and painting the assembly. For the final few steps, a switched is mounted outside the table saw in a small box that connected to the power supply and motor, as well as a shop vac for handling dust collection from the saw. While the enclosure isn’t a metal box, as long as the connections are secured properly the wires shouldn’t come loose.
If you want to see other examples of homemade table saws, check out this teeny tiny saw and this kid-friendly table saw build.
source https://hackaday.com/2020/01/11/building-a-real-wooden-table-saw/
While Christmas may have just passed, there’s just enough time left in winter to justify wearing your ugly Christmas sweaters for a few more days. If you’re not one of the lucky ones with an old sweater from Grandma, you can still turn your least favorite sweater into the most epic flame-throwing Christmas sweater there ever was.
[JAIRUS OF ALL], maker of explosive and other dangerous ideas, came up with a DIY ugly Christmas sweater that shoots flames on command. In order to produce the flame-throwing effect, he uses piping from a fish tank airline hose with a T connector attached to one end and epoxied to the middle of the sweater. The piping runs down the sweater to a can of butane fuel that he can control from the nozzle. Once the fuel is being released, he uses a lighter to initiate the flames from the sweater.
The flames are quite impressive, so definitely use caution if you intend to replicate this build in any way. It would be helpful to have a friend with a CO2 fire extinguisher nearby as well.
For a less life-threatening build, fellow builder [Price] created a Christmas tree-themed sweater lined with LEDs and USB-powered figurines, connected to a power supply in his pocket.
source https://hackaday.com/2020/01/11/this-ugly-christmas-sweater-can-set-you-on-fire/
POV builds come in all shapes and sizes, and typically rely on LEDs for their high light output and fast response time. With this in mind, [Great Scott] grabbed some LED strip off the shelf and set about whipping up a POV LED globe.
Being a spinning POV build, it’s necessary to consider how to get power to the rotating elements. [Great Scott] decided to go with a simple solution of putting a LiPo battery on the rotating assembly, which runs the LEDs and Arduino Nano at the heart of the operation. The LEDs in question are of the APA102 type, making them readily addressable and capable of a wide color gamut. It’s all spun by a simple brushed DC motor, running from a separate supply at the base of the platform.
It’s very much a hacker build, held together with duct tape and zipties. Despite this, it looks tidy when in operation, as all of the important hardware is hidden at the centre of the globe. There’s a bit of a vibration problem, but [Great Scott] reckons this can be fixed with some frame modifications.
We’d love to see the build run some more advanced operations, like a representation of the Earth, or some kind of sun clock. If you’re interested in learning more about POV displays, we’ve got the primer you need. Video after the break.
source https://hackaday.com/2020/01/10/a-simple-pov-globe-via-apa102/
In an age of flashy jQuery scripts and bulky JavaScript front-end frameworks, loading a “lite” website is like a breath of fresh air. When most of us think of lightweight sites, though, our mind goes to old-style pure HTML and CSS sites or the intentionally barebones websites of developers and academics. Low-tech Magazine, an intentionally low-tech and solar-powered website, manages to incorporate both modern web aesthetics and low-tech efficiency in one go.
Rather than hosting the site on data centers – even those running on renewable power sources – they have a self-hosted site that is run on solar power, causing the site to occasionally go off-line. Their model contrasts with the cloud computing model, which allows more energy efficiency at the user-side while increasing energy expense at data centers. Each page on the blog declares the page size, with an average page weight of 0.77 MB, less than half of the average page size of the top 500,000 most popular blogs in June 2018.
Some of the major choices that have limited the size of the website include building a static site as opposed to a dynamic site, “dithering” images, sparing a logo, staying with default typefaces, and eliminating all third-party tracking, advertising services, and cookies. Their GitHub repository details the front-end decisions including using unicode characters for the site’s logo rather than embedding an SVG. While the latter may be scalable and lightweight in format it requires distribution to the end-user, which can involve a zipped package with eps, ai, png, and jpeg files in order to ensure the user is able to load the image.
As for the image dithering, the technique allows the website to maintain its characteristic appearance while still minimizing image quality and size. Luckily for Low-tech Magazine, the theme of the magazine allows for black and white images, suitable for dithering. Image sprites are also helpful for minimizing server requests by combining multiple small images into one. Storage-wise, the combined image will take up less memory and only load once.
There are also a few extraneous features that emphasize the website’s infrastructure. The background color indicates the capacity of the solar-charged battery for the website’s server, while other stats about the server’s location (time, sky conditions, forecast) also help with making the website availability in the near future more visible. Who knows, with the greater conscience on environmental impact, this may be a new trend in web design.
source https://hackaday.com/2020/01/10/building-a-low-tech-website-for-energy-efficiency/
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.
The Arduino computes the magnitude of the acceleration, and if it exceeds a certain threshold it adds a step to the step count. Honestly, this is a fun project but it cries out for a more compact form factor. An ESP8266 for example could ditch the display and connect via WiFi to your phone. Then again, your phone can probably do the same job, as could not to mention many smartwatches. But those don’t have nearly as much geek cred as this project.
This is a little large for a hamster. On the other hand, there’s plenty you can do with the accelerometer after you’ve had enough fun counting steps.
source https://hackaday.com/2020/01/10/arduino-pedometer-counts-your-steps/
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.
For those of you who don’t mind getting a Pi in a PowerBook, we recently saw a recreation of Lord Nikon’s laptop from Hackers that went that route.
source https://hackaday.com/2020/01/10/retro-powerbook-gets-a-mac-mini-transplant/
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.

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.
source https://hackaday.com/2020/01/10/using-lookup-tables-to-make-the-impossible-possible/
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.
Oddly enough, people have been trying to figure out how to operate underwater since the time of Alexander the Great. The first submarine that has features similar to a modern sub was the Catalan Ictineo II. It ran on a steam engine when on the surface, but submerged used chemicals to fire the boiler. The chemical reaction not only created heat for the steam engine that turned the screw but also released oxygen for the crew. A few German submarines used a similar system known as the Walter turbine.
Things progressed from there (you’ll find plenty of historical detail in the video above). The biggest problem was always how to power the craft when submerged. Prior to atomic energy, most subs ran on diesel on the surface and had batteries to power it underwater. A snorkel would allow the engine to run while staying mostly submerged, but once the ship sank completely beneath the waves, it had to use batteries which don’t last very long — especially 1940-era batteries.
The technical side of the submarine directly influenced the tactical side. Although a submarine on the surface isn’t in a particularly safe place, World War II-era subs spent a lot of time on the surface, allowing them to make better speed. If a sub crew thought it might encounter the enemy, the vessel would submerge, at least to snorkel depth, to try to avoid detection.
Approaching an enemy convoy submerged, it would try to sink as many ships as possible using torpedos or whatever weapons it had. It had to work fast, though, because firing usually gives away your position and the inevitable counterattack would be swift. The Navy gave a lot of thought about how to locate and attack submarines, as you can see in the video below.
In modern times, though, submarines may use a different form of power: nuclear power. In that case, the sub can stay submerged for a very long time. This has led to military subs having two main categories: attack subs and missile subs, sometimes known as boomers.
The idea behind a missile sub is to have it leave port with a stockpile of nuclear missiles. Usually, the sub will do some crazy maneuvers to try to shake any enemy ships following it. Then it will go deep and wait. The idea is that if an enemy tries to attack first, it could wipe out ground-based missile launchers. But they can’t strike a submarine unless they know where it is, so the submarine fleet could retaliate no matter how successful a first strike was. Under the doctrine of mutually assured destruction, this would prevent either side from thinking a first strike is their best option.
The United States relied on advanced sonar, radar, and infrared detection to find subs. It also could use very sensitive magnetic detectors to locate submerged metal objects. Some of the sensors are on ships, subs, or airplanes.
All of these have some limitations. However, the SOSUS (sound surveillance) line deployed ultrasensitive hydrophones on the ocean floor at key locations to identify and locate submarines. These microphones were connected to the shore using the same sort of cables used for long-distance circuits. Using state-of-the-art signal processing and microphones, the US could reasonably track the relatively noisy subs. You can learn more about SOSUS in the video below.
However, nuclear boomers posed some unique challenges. They can sit quietly on the bottom for a very long time. They can attack without approaching the enemy. A single submarine can launch well over 100 warheads, each with enormous destructive power.
The CIA pointed all of this out way back in 1973. Even though the Soviets had some unique technology, the CIA deemed that the “…capabilities for antisubmarine warfare fall far short of the minimum requirements…” That is to say the US boomers had nothing to fear from the Soviets. The video below shows some of the ways the US located submarines.
On page 14 of the CIA report, there is an assessment of Soviet detection capabilities. There are several pages in that area completely redacted, so you can only wonder what is there that is still secret.
The report details Soviet sonar and magnetic detection capability, but they were not overly impressed with the equipment or how the Soviets used them. They do mention briefly that circumstantial evidence indicated that some aircraft could have an infrared wake detector. But thanks to the redactions it isn’t clear what the evidence is.
Since the Soviets lacked a widespread underwater detection system like SOSUS, their best bet — according to the CIA — was to find a submarine and follow it. This is known as “trailing.”
The real interesting bits of the report begin on Page 63 where Annex A starts. This annex analyzes methods the Soviets use to detect subs. The fact that the Soviets didn’t have something similar to SOSUS the CIA attributes to their lack of access to deep ocean and a deficiency in cable technology. In addition, the report cites a lack of signal processing ability and the predominant use of rigid hydrophones. Besides that, US subs were significantly quieter than Soviet subs of the time. Even SOSUS could not reliably detect US subs, so for the USSR to build a useful capability like SOSUS, they would have to do a better job of it than the United States had.
Perhaps the Soviets knew that, too. Instead of trying to spend more money to develop better active and passive SONAR, they turned to other ways to track subs. For example, there was interest in detecting 5 Hz noise generated by a sub’s wake. They also relied on magnetic detection using similar technology to the United States. There was also work to use radar to detect things as subtle as a submarine’s disturbance of the water on the surface above it.
Of course, the subs most valuable to track have reactors. They produce a lot of neutrons, but the water absorbs most of them so it is hard to detect them from any distance away. Antineutrinos, on the other hand, are very hard to absorb. So hard, that it is difficult to detect them, too. The CIA didn’t rule out the Soviets using such a system even though there was no evidence that they had.
However, some other radiation effects are easier to track. The Soviets claimed success tracking their own nuclear subs by measuring radioisotopes in seawater, but there is no evidence they used this technique operationally. They also could detect a submarine’s wake optically or acoustically — possibly useful if a Soviet sub was trailing another sub. There are also methods using chemical residue from a sub’s hull or using infrared.
Wake detection is how the K-147 probably followed the US sub. A system known as SOKS (System Obnarujenia Kilvaternovo Sleda) had been on some Soviet boats since 1969. The cluster of probes measured several things including nuclear byproducts and other parameters mentioned in the CIA report.
The boomer subs were a key part of cold war strategy. The US had the Ohio class submarine and its Trident missile with eight 100 kiloton warheads. The Soviets had the huge Akula with its larger R-39 missiles. The Akula — known as the Typhoon class in the West — was the largest sub ever and could hold up to ten 100-200 kiloton devices (see the video below).
The sub was known to be pretty noisy, though, so SOSUS supposedly knew where they were all the time.
We don’t miss the cold war. But it did produce some amazing hardware and technology. Besides, there’s something thrilling about reading a document that would have been full of highly classified information in its time. Even though none of it is secret almost 50 years later, if you ever needed to detect submarines, this document would give you a lot of ideas on areas to research.
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 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.
Certain commercial sectors are constantly pushing for more performance, and as a result, Intel has begun shipping servers that have FPGA co-processors. These FPGAs have direct access to system memory, and can operate at very high data rates. Could it be that this integration has led to unforeseen security problems?
A group of researchers have identified at least one such problem: Jackhammer. Yes, it’s another fancy name for a vulnerability. This is essentially the Rowhammer attack, launched from an FPGA. In best-case scenarios, they demonstrated an attack speed of three times what could be accomplished on a CPU alone.
A very detailed attack on the Tesla Model S WiFi stack caught my attention this week. Published by the Tencent Keen Security Lab, this is a very impressive walk-through of how to compromise the Linux system at the heart of that vehicle.
It starts by knocking the Tesla off whatever WiFi network it’s connected to, and capturing the reconnection. With the information gathered, an attack can be launched against the WiFi chip itself. Once that is compromised, a vulnerability in the Linux wifi driver is triggered to gain execution on that system. It’s worth asking, how many drivers are written to be defensive against the very chip they support? The entire write-up is impressive, go read the whole thing.
TikTok is all the rage among the young folk these days. The guys at Checkpoint Research decided to take a look at the app and infrastructure, and found a handful of vulnerabilities.
Cisco made public another round of security goofs. It’s full of flaws like static shared keys and hard coded credentials.
Firefox released an unexpected point release, only a day after a scheduled release. 72.0.1 was pushed out in response to a 0-day being actively exploited. Not much is known about the vulnerability yet, other than Mozilla’s statement that it was a type confusion bug.
source https://hackaday.com/2020/01/10/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!
Direct download (58 MB)
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.
Thanks to [Phil] for the tip.
source https://hackaday.com/2020/01/10/hardware-hack-makes-robocall-blocking-service-even-better/
Mowing the lawn is one of those repetitive tasks most of us really wish we had a robot for. [Kenny Trussell] mowing needs are a bit more strenuous than most backyards, so he hacked a ride-on mower to handle multi-acre fields all on it’s own.
The mower started out life as a standard zero turn ride on lawn mower. It’s brains consist of a PixHawk board running Ardurover, an Ardupilot derivative for ground vehicles. Navigation is provided by a RTK GPS module that gets error corrections from a fixed base station via an Adafruit LoRa feather board, to achieve centimetre level accuracy. To control the mower, [Kenny] replaced the pneumatic shocks that centred the control levers with linear actuators.
So far [Kenny] has been using the mower to cut large 5-18 acre fields, which would be a very time-consuming job for a human operator. A relay was added to the existing safety circuit that only allows the mower to function when there is weight on the seat. This relay is wired directly to the RC receiver and is controlled from the hand-held RC transmitter. It will also stop the mower if it loses signal to the transmitter. To set up mowing missions, [Kenny] uses the Ardupilot Mission Planner for which he wrote a custom command line utility to create a concentric route for the mower to follow to completely cover a defined area. He has made a whole series of videos on the process, which is very handy for anyone wanting to do the same. We’re looking forward to a new video with all the latest updates.
This mower has been going strong for two years, but in terms of hours logged it’s got nothing on this veteran robotic mower that’s been at it for more than two decades and still runs off an Intel 386 processor.
source https://hackaday.com/2020/01/10/diy-autonomous-mower-in-the-wild/
Today, computers are separated into basically two categories: desktops and laptops. But back in the early 1980s, when this ideological line in the sand was still a bit blurry, consumer’s had a third choice. Known as “portable computers” at the time, and often lovingly referred to as luggables by modern collectors, these machines were technically small enough to take with you on a plane or in the car.
Improvements in miniaturization ultimately made the portable computer obsolete, but that doesn’t mean some people still don’t want one. [Dave Estes] has been working on his own modern take on idea that he calls Reviiser, and so far it looks like it checks off all the boxes. With the addition of a rather hefty battery pack, it even manages to be more practical than the vintage beasts that inspired it.
In the video after the break, [Dave] walks us through some of the highlights of his luggable build, such as the fold-down mechanical keyboard, gloriously clunky mechanical power switches, and the integrated touch screen. We also really like the side-mounted touch pad, which actually looks perfectly usable given the largely keyboard driven software environment [Dave] has going on the internal Raspberry Pi 4. With a removable 30,000 mAh battery pack slotted into the back of the machine, he’ll have plenty of juice for his faux-retro adventures.
[Dave] mentions that eventually he’s looking to add support for “cartridges” which will allow the user to easily slot in new hardware that connects to the Pi’s GPIO pins. This would allow for a lot of interesting expansion possibilities, and fits in perfectly with the Reviiser’s vintage aesthetic. It would also go a long way towards justifying the considerable bulk of the machine; perhaps even ushering in a revival of sorts for the luggable computer thanks to hardware hackers who want a mobile workstation with all the bells and whistles.
Right now there isn’t a lot of detail on how you can build your own Reviiser, but [Dave] says more info will be added to his site soon. In the meantime, you can check out some of the similar projects we’ve seen recently to get some inspiration for your own Luggable Pi.
source https://hackaday.com/2020/01/10/a-luggable-computer-for-the-raspberry-pi-era/