When Pong hit the scene in the early 70s, there was something about the simplicity of the 2D monochrome tennis game that made it engaging enough that enthusiastic proto-gamers shorted-out machines by stuffing their coin boxes to overflowing. But even with the simplicity of Pong’s 2D gameplay, the question becomes: could it by made simpler and still be playable?
Surprisingly, if this one-dimensional Pong game is any indication, it actually seems like it can. Where the original Pong made you line up your paddle with the incoming ball, with the main variable being the angle of the carom from your opponent, [mircemk]’s version, limited to a linear game field, makes the ball’s speed the variable. Players take control of the game with a pair of buttons at the far ends of a 60-LED strip of WS2812s. The ball travels back and forth along the strip, bouncing off a player’s paddle only if they push their button at the exact moment the ball arrives. Each reflection back to the opponent occurs at a random speed, making it hard to get into a rhythm. To add some variety, each player has a “Boost” button to put a little spice on their shot, and score is kept by LEDs in the center of the play field. Video of the game play plus build info is below the break.
With just a Neopixel strip, an Arduino Nano, and a small handful of common parts, it should be easy enough to whip up your own copy of this surprisingly engaging game. But if the 2D-version is still more your speed, maybe you should check out the story of its inventor, [Ted Dabney]. Or, perhaps building a clock that plays Pong with itself to idle the days away is more your speed.
Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.
A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.
To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.
Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.
Broken Promises
For most users, this is little more than a minor annoyance. Sure it was nice to have Chromium available in your distribution’s package repository, but popping over to the official website and downloading the latest stable is hardly the end of the world. Those running older machines may be in for a rude awaking however, as Google no longer makes 32-bit builds available. They also don’t provide a native BSD build at the time of this writing. For those users, it may be time to give Firefox a shot.
Soon to be a memory of simpler times?
The people that are actually hurt the most by this decision are the ones who’ve spent years packaging Google’s open source browser. They’ve put in considerable time and effort to compile, distribute, and support a custom built Chromium, only to have Google pull the rug out from under them without so much as a call for comments. You might think that’s just one of the risks you take on when supporting a BSD-licensed project, which by definition offers no implied warranty, but in this case things are a little less cut and dry.
As developer Eric Hameleers explains in a lengthy blog post, he was supplied with a dedicated API key for his Slackware Chromium builds by the Google Chrome Team in 2013. He was granted “official permission to include Google API keys in your packages”, and was told that the usage quota for that particular key would be increased “in an effort to adequately support your users”, as normally the key he was assigned would only be for personal development use. Evangelos Foutras, the maintainer for the Arch Linux Chromium package, has indicated he received a similar email at around the same time.
There’s no question that Google understood how these individuals intended to use their API keys. They were even given special dispensation to circumvent API limits, a decision which must have gone through several layers of approvals. The framework for giving distribution-specific Chromium packages the same level of functionality as official builds was agreed upon and put into operation years ago, that much is certain. What’s less clear is what happened internally at Google that prompted them to terminate these existing agreements with little more than a vague blog post to serve as notification.
Keys to the Kingdom
We may never get the full story in this situation, and since a Google representative has made it clear that the decision is final, there’s not much sense fretting over it. Ultimately, Google is going to run their business as they see fit. If they think allowing unofficial builds of Chromium to tap into their cloud services such as Sync isn’t worth it, it’s their prerogative to block them. Those who believe firmly in the concept of free and open source software would tell you that this is a perfect example of why you should have been using Firefox or another truly libre browser in the first place.
On the other hand, hackers as a whole aren’t overly fond of being told what to do. Finding unconventional solutions to arbitrary limitations is the name of the game, so what options exist for those who can’t or won’t use the official Chromium builds from Google? Foutras has put forward an interesting suggestion that, at least on the surface, doesn’t seem to run afoul of Google’s Terms of Service. Though that certainly doesn’t mean they’ll be happy about it.
Put simply, there doesn’t appear to be any technical reason that a third-party build of Chromium couldn’t simply use the official API keys that ship with Chrome. These keys have been publicly known since at least 2012, and in all that time, have never been changed. While actually distributing a build of Chromium using these keys may be enough of a gray area that mainline distributions would steer clear, a separate script that executes on the end-user’s machine and slips the keys into the relevant environment variables may be a loophole Google wasn’t expecting.
If you ever watched Dr. Who, you probably know that the TARDIS looked like a police call box on the outside, but was very large on the inside. When asked, the Doctor had some explanation of how something can look small when it is far away and large when it is close up, which never made much sense. However, [iQLess] has been 3D printing boxes in a small area, that fold out to be much larger boxes. (Video, embedded below.) The design comes from someone called [Cisco] who has a lot of interesting print in place designs.
You can find the design on the Prusa site or Thingiverse. The boxes do take a while to print, according to the video below. What was interesting to us, though, is that you should be able to print a design like this to create a box larger than your printer.
There are two versions of the box, a large one and a small one. The small box took about 10 hours to print with an estimated cost of just over a dollar. The large box takes about 24 hours to print on the machine [iQLess] uses.
Of course, any time you are printing hinges in place, you need your printer well calibrated so you don’t wind up with an immobile blob.
If engineering choices a hundred years ago had been only slightly different, we could have ended up in a world full of steam engines rather than internal combustion engines. For now, though, steam engines are limited to a few niche applications and, of course, models built by enthusiasts. This one for example is built entirely in LEGO as a scale replica of a steam engine originally produced in 1907.
The model is based on a 2500 horsepower triple-expansion four-cylinder engine that was actually in use during the first half of the 20th century. Since the model is built using nothing but LEGO (and a few rubber bands) it operates using a vacuum rather than with working steam, but the principle is essentially the same. It also includes Corliss valves, a technology from c.1850 that used rotating valves and improved steam engine efficiency dramatically for the time.
This build is an impressive recreation of the original machine, and can even run at extremely slow speeds thanks to a working valve on the top, allowing its operation to be viewed in detail. Maximum speed is about 80 rpm, very close to the original machine’s 68 rpm operational speed. If you’d prefer your steam engines to have real-world applications, though, make sure to check out this steam-powered lawnmower.
Now that it is relatively cheap and easy to create a PCB, it is a common occurrence for them to be used in projects. However, there are a lot of subtleties to creating high-performance boards that don’t show up so much on your 555 LED blinker. [Robert Feranec] is well-versed in board layout and he recently highlighted an animation on signal crosstalk with [Eric Bogatin] from Teledyne LeCroy. If you want a good understanding of crosstalk and how to combat it, you’ll want to see [Eric’s] presentation in the video below.
Simplifying matters, the heart of the problem lies in running traces close together so that the magnetic fields from one intersect the other. The math is hairy, but [Eric] talks about simple ways to model the system which may not be exact, but will be close enough for practical designs.
The models use inductors and capacitance to represent different modes of crosstalk, and it’s likely you already know how to deal with those quantities. The video shows some simulations and also suggests methods to control the problem.
Even though the topic is PC boards, some of the same ideas apply to cables. Ethernet cables, for example, have specifications for FEXT for similar reasons.
The Mavic Mini uses I2C to communicate with official packs, making the hack relatively straightforward. [aeropic] built a board nicknamed B0B, which tells the drone what it wants to hear and lets it boot up with unofficial batteries installed. The circuit uses a PIC12F1840 to speak to the drone, including reporting voltage on the cells installed. Notably, it only monitors the whole pack, before dividing the voltage to represent the value of individual cells, but it shouldn’t be a major problem in typical use. Combined with a few 3D printed components to hold everything together, it allows you to build your own cheap pack for the Mavic Mini with little more than a PCB and a few 18650 cells.
It’s always good to see hackers getting out and doing the bread and butter work to get around restrictive factory DRM measures, whether its on music, printer cartridges, or drone batteries. We’ve even seen the scourge appear on litter boxes, too. Video after the break.
Piezo elements have the useful property of being bidirectional; that is they can move when you apply electricity to them, but they can also generate electricity when you move them. [Carl] takes advantage of this fact to make buttons that can provide haptic feedback. You can see a video of his efforts below the break.
He made two versions of the buttons. One uses a 3D printed housing and the other used a 3D printed spacer in a sandwich configuration. It took a few tries to get it right, as you’ll see. The elements take and produce relatively high voltages, so the bulk of the work was adapting the voltages back and forth. In fact, he even managed to fry his CPU chip with some of the higher voltages involved.
We’d probably look for an easier way to sense the button push, since it seems like a good bit of circuitry just to do that. But the whole circuit provides an input button, haptic feedback, and the option of using the buzzer as a buzzer, so at least it is relatively economical if you need all of those features.
The last time we saw a piezo speaker detecting something it was looking for knocks on a door. If you want to know more about how transducers like this work, you’ll enjoy this video.
Every nation has icons of national pride: a sports star, a space mission, or a piece of architecture. Usually they encapsulate a country’s spirit, so citizens can look up from their dreary lives and say “Now there‘s something I can take pride in!” Concorde, the supersonic airliner beloved by the late 20th century elite for their Atlantic crossings, was a genuine bona-fide British engineering icon.
But this icon is unique as symbols of national pride go, because we share it with the French. For every British Airways Concorde that plied the Atlantic from London, there was another doing the same from Paris, and for every British designed or built Concorde component there was another with a French pedigree. This unexpected international collaboration gave us the world’s most successful supersonic airliner, and given the political manoeuverings that surrounded its gestation, the fact that it made it to the skies at all is something of a minor miracle.
A Bright Future Of Supersonic Travel
Boeing’s Dash 80 prototype sets the template for today’s jet airliners. Boeing Dreamscape, Public domain
In the 1950s, the direction of post-war aviation had been set by the first generation of four-engined jet passenger aircraft. Planes such as the De Haviland Comet, Tupolev TU-104, Sud Aviation Caravelle, and Boeing Dash-80 prototype are the visible ancestors of today’s airliners, but just as the future of jet fighter aircraft lay in supersonic designs it was envisaged that so too would the future of civil aviation.
By the 1980s, we would zip around the world at twice the speed of sound, and naturally the aircraft manufacturers of the day wanted a slice of that market. Governments and major manufacturers worldwide set their designers researching the feasibility of transforming design elements created for supersonic military aircraft into civilian airliners. By the end of the 1950s the French Sud Aviation and British BAC had advanced to the point of in 1960 investigating a joint venture, and were surprised to find that each other’s designs had arrived at a substantially similar shape and configuration.
A common design was agreed, and the respective governments contemplated a formal treaty. At this time, the British government was being blocked by the French from European Community membership, and was seeking anything that would sweeten their eventual membership. They thus pushed for a deal, and inserted punitive clauses for breaking it in the resulting 1962 treaty. The aircraft would be built as a cooperative effort between the two countries, with both governments funding the development in the expectation that they could get a head start over the Americans in equipping the airlines of the 1970s.
The Battle Of The Extra “E”
The aircraft that emerged had the familiar thin fuselage and long curved delta wing, and had four Rolls-Royce Olympus 593 turbojet engines derived from those used on the Avro Vulcan bomber mounted under the wings. For use at supersonic speeds, these engines had special intake ducts designed to slow the air down to subsonic speeds. And although they were fitted with afterburners for the climb to cruising altitude, these intakes gave the Concorde the ability to “supercruise”, or cruise at mach 2 supersonic speeds without afterburners engaged.
One of the prototype Concorde aircraft complete with “e” is in the Imperial War Museum, Duxford. Ronnie Macdonald from Chelmsford, United Kingdom, CC BY 2.0
It is inevitable that such a project, at the edge of what is possible, will incur significant overruns. The Concorde was no exception. The first estimate of £70 million soared to a billion and beyond. That the project survived at all was due only to the expense of pulling out due to that punitive clause.
The sometimes testy relationship between the two countries’ political leadership was reflected in its name, variously being referred to with the French spelling of “Concorde” or the English “Concord”. The version with an “e” was finally adopted.
The two prototype aircraft made their maiden flights in 1969, with the French Concorde in Toulouse being the first. These two planes flew into a different environment from that envisaged in the 1950s. Concerns about noise and pollution, as well as the Oil Crisis in the early 1970s, led to much of the interest of the airlines in supersonic luxury travel melting away, and by the time the first production aircraft were under way only the two national airlines remained. The two governments were left having spent eye-watering sums to produce only a few aircraft, and opted to swallow the loss by passing them to the airlines. They were sold to the public as that source of national pride, and to this day that is how they are seen rather than as a colossal sinkhole of public money.
The Unthinkable Happens
The memorial to those killed in the Concorde crash, Gonesse, France. Marbus1966, CC BY-SA 4.0
Concorde’s use for special charter flights meant that it would often fly over parts of the UK outside of its normal scheduled routes, and even when it was a couple of decades old it would cause people to stop and watch it go by. “National icon” is a phrase that is sometimes used inappropriately, but for Brits and presumably the French too, it definitely applied to Concorde during those decades. It seemed to be a fixture without an end to its service.
But in July 2000, the aircraft suffered its first and only fatal crash. An Air France charter flight hit a piece of runway debris at Paris Charles de Gaulle airport, causing a fuel tank failure and fire that led to the aircraft crashing with the loss of all on board after only two minutes of flight.
The fleet was grounded while investigations were carried out and all aircraft were fitted with fuel tank modifications, but their return to the air was short-lived. In 2003 the entire fleet was retired by both airlines, causing a brief controversy. Civilian supersonic airline flight had not become travel for the masses as was once predicted, and while still a source of national pride, the aircraft had become something of an anachronism. Meanwhile we’re left to queue for our twin-engined subsonic widebody aircraft flights, and hope that one day Reaction Engines might rekindle the dream.
It’s always an event when we have Adafruit on the Hack Chat, and last time was no exception. Then, the ESP32-S2 was the new newness, and Adafruit was just diving into what’s possible with the chip. It’s an interesting beast — with a single core and no Bluetooth or Ethernet built-in, it appears to be less capable than other Espressif chips. But with a faster CPU, more GPIO and ADCs, a RISC-V co-processor, and native USB, the chip looked promising.
Among their other duties, the folks at Adafruit have spent the last six months working with the chip, and they’d now like to share what they’ve learned with the community. So Limor “Ladyada” Fried, Phillip Torrone, Scott Shawcroft, Dan Halbert, and Jeff Epler will stop by the Hack Chat to show us what’s under the hood of the ESP32-S2. They’ve worked on a bunch of projects using the chip, and they’ve taken a deep-dive into the chip’s deep-sleep capabilities, so stop by the Chat with your burning questions about low-power applications or anything ESP32-S2-related and ask away.
Plus, a late and exciting addition to the agenda: they’ll be talking about the recently released RP2040, the first custom chip from the folks at Raspberry Pi. We’ve already started talking about the Raspberry Pi Pico, the dev board that uses the chip, and Adafruit will share what they’ve learned about the RP2040 so far.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
It’s always an event when we have Adafruit on the Hack Chat, and last time was no exception. Then, the ESP32-S2 was the new newness, and Adafruit was just diving into what’s possible with the chip. It’s an interesting beast — with a single core and no Bluetooth or Ethernet built-in, it appears to be less capable than other Espressif chips. But with a faster CPU, more GPIO and ADCs, a RISC-V co-processor, and native USB, the chip looked promising.
Among their other duties, the folks at Adafruit have spent the last six months working with the chip, and they’d now like to share what they’ve learned with the community. So Limor “Ladyada” Fried, Phillip Torrone, Scott Shawcroft, Dan Halbert, and Jeff Epler will stop by the Hack Chat to show us what’s under the hood of the ESP32-S2. They’ve worked on a bunch of projects using the chip, and they’ve taken a deep-dive into the chip’s deep-sleep capabilities, so stop by the Chat with your burning questions about low-power applications or anything ESP32-S2-related and ask away.
Plus, a late and exciting addition to the agenda: they’ll be talking about the recently released RP2040, the first custom chip from the folks at Raspberry Pi. We’ve already started talking about the Raspberry Pi Pico, the dev board that uses the chip, and Adafruit will share what they’ve learned about the RP2040 so far.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
It’s always an event when we have Adafruit on the Hack Chat, and last time was no exception. Then, the ESP32-S2 was the new newness, and Adafruit was just diving into what’s possible with the chip. It’s an interesting beast — with a single core and no Bluetooth or Ethernet built-in, it appears to be less capable than other Espressif chips. But with a faster CPU, more GPIO and ADCs, a RISC-V co-processor, and native USB, the chip looked promising.
Among their other duties, the folks at Adafruit have spent the last six months working with the chip, and they’d now like to share what they’ve learned with the community. So Limor “Ladyada” Fried, Phillip Torrone, Scott Shawcroft, Dan Halbert, and Jeff Epler will stop by the Hack Chat to show us what’s under the hood of the ESP32-S2. They’ve worked on a bunch of projects using the chip, and they’ve taken a deep-dive into the chip’s deep-sleep capabilities, so stop by the Chat with your burning questions about low-power applications or anything ESP32-S2-related and ask away.
Plus, a late and exciting addition to the agenda: they’ll be talking about the recently released RP2040, the first custom chip from the folks at Raspberry Pi. We’ve already started talking about the Raspberry Pi Pico, the dev board that uses the chip, and Adafruit will share what they’ve learned about the RP2040 so far.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Sure it is a cheap stage trick, but using a lenticular lens at the right angle and in front of the right background can render what’s behind it invisible. That’s not news, but [Ian] spent some time investigating how to make the best one he could. His instructions cover how to create your own with polycarbonate, the right lens, and some optically clear adhesive. You can see some details about the shield along with some demonstrations in the video below.
The first iteration of the design worked, but it had some distracting lines and curvatures. The second version uses a large sheet of polycarbonate and liquid adhesive to attach the lens. It looks much better.
The effect works best when you have a bold horizontal pattern behind you and, of course, only works from certain sight angles. Even then, you can see when [Ian] is moving behind the shield, but it is pretty muted. However, the final version did look better even though UV curing that big sheet of plastic looked painful.
The final few minutes of the video shows some real world user testing that looked like a lot of fun. There are other ways to bend light to get limited invisibility. We’ve seen these lenses used for faux holograms, too.
The January 16th “Green Run” test of NASA’s Space Launch System (SLS) was intended to be the final milestone before the super heavy-lift booster would be moved to Cape Canaveral ahead of its inaugural Artemis I mission in November 2021. The full duration static fire test was designed to simulate a typical launch, with the rocket’s main engines burning for approximately eight minutes at maximum power. But despite a thunderous start start, the vehicle’s onboard systems triggered an automatic abort after just 67 seconds; making it the latest in a long line of disappointments surrounding the controversial booster.
When it was proposed in 2011, the SLS seemed so simple. Rather than spending the time and money required to develop a completely new rocket, the super heavy-lift booster would be based on lightly modified versions of Space Shuttle components. All engineers had to do was attach four of the Orbiter’s RS-25 engines to the bottom of an enlarged External Tank and strap on a pair of similarly elongated Solid Rocket Boosters. In place of the complex winged Orbiter, crew and cargo would ride atop the rocket using an upper stage and capsule not unlike what was used in the Apollo program.
The SLS core stage is rolled out for testing.
There’s very little that could be called “easy” when it comes to spaceflight, but the SLS was certainly designed to take the path of least resistance. By using flight-proven components assembled in existing production facilities, NASA estimated that the first SLS could be ready for a test flight in 2016.
If everything went according to schedule, the agency expected it would be ready to send astronauts beyond low Earth orbit by the early 2020s. Just in time to meet the aspirational goals laid out by President Obama in a 2010 speech at Kennedy Space Center, including the crewed exploitation of a nearby asteroid by 2025 and a potential mission to Mars in the 2030s.
But of course, none of that ever happened. By the time SLS was expected to make its first flight in 2016, with nearly $10 billion already spent on the program, only a few structural test articles had actually been assembled. Each year NASA pushed back the date for the booster’s first shakedown flight, as the project sailed past deadlines in 2017, 2018, 2019, and 2020. After the recent engine test ended before engineers were able to collect the data necessary to ensure the vehicle could safely perform a full-duration burn, outgoing NASA Administrator Jim Bridenstine said it was too early to tell if the booster would still fly this year.
What went wrong? As commercial entities like SpaceX and Blue Origin move in leaps and bounds, NASA seems stuck in the past. How did such a comparatively simple project get so far behind schedule and over budget?
The Rocket to Nowhere
Arguably, the most pressing problem with the SLS program is that it has no clear purpose. As a congressionally mandated project, NASA must continue on with its development regardless of whether or not they actually have a use for it. Critics have often referred to the program as the “Senate Launch System”, as they believe the Shuttle-derived concept was conceived primarily as a way to make sure the manufacturing facilities used to build the engines, propellant tanks, and solid rocket boosters for the Space Shuttle would remain in operation even after the program was retired.
The deep space asteroid mission was canceled in 2017.
Without a clear mission for the SLS, it’s been difficult for NASA engineers to make any long-term development plans. What payload does the booster need to carry, and to where, are key questions that need to be answered. NASA is no longer pursuing the mission to recover a near Earth asteroid, and a human mission to Mars is still decades away. The SLS is scheduled to launch the Europa Clipper to Jupiter in 2025, though the Falcon Heavy is already being considered as a backup should it not be ready in time.
While its ultimate effectiveness is debatable, the design of the Space Shuttle was driven by a very specific goal: to transport large objects to and from low Earth orbit inside of its cargo bay. Every decision made during the program’s lifetime revolved around that core tenet. Without similar guidance, the Space Launch System has found itself adrift.
Put simply, the single defining characteristic of the SLS is the sheer mass it’s capable of putting into space. The rocket’s base Block I configuration is designed to put 95,000 kg (209,000 lb) into low Earth orbit, and the later Block II version 130,000 kg (290,000 lb). But while these are impressive figures, it’s not immediately clear what type of mission architecture would require such massive modules to be launched in a single-shot. The 50 years of experience gained since the Apollo era has taught us that modular systems, launched on competitively priced boosters and assembled in orbit, is the key to creating a sustainable space infrastructure.
Squandered Reusability
From the beginning, the Space Shuttle was designed to be an almost completely reusable architecture. Aside from the External Tank, every component of the system could be recovered, refurbished, and flown again. The idea being that it would be cheaper and faster to reuse the same vehicle than it would be to build a new one for each mission.
Unfortunately the complexity and cost of the refurbishment process was greatly underestimated, due in part to technical and material limitations of the era. In the end, the Shuttle never launched as affordably and as rapidly as its designers had hoped, but the lessons learned during the program helped shape modern reusable spacecraft such as Sierra Nevada Corporation’s Dream Chaser and the Boeing X-37B.
But despite the current trend towards reusable rockets and spacecraft, NASA is taking a step backwards with the SLS by using components which were designed for refurbishment and discarding them the end of each flight. The RS-25 engines installed on the first SLS rocket are not newly manufactured, they are literally the same engines that were pulled from the Shuttle Orbiters when they were put into museums. The same is true with the Solid Rocket Boosters (SRBs); the new elongated boosters are using segments from the Shuttle’s original SRBs, but instead of coming down on parachutes to be recovered, they will smash into the ocean and sink.
Each flight of the SLS will destroy four Shuttle-era RS-25 engines and two SRBs, simply because they were taking up space in a NASA warehouse. From a historical standpoint, this is abhorrent. But more practically speaking, integrating these decades-old components into a modern launcher has proven to be far more difficult than anticipated. While they’ve seen some upgrades since the retirement of the Shuttle, it’s no exaggeration to say that some of the people working on the SLS today were not born when its engines were built.
As of right now, NASA only has enough RS-25 engines leftover from the Shuttle program to support four SLS flights. To address this, the agency has already contracted Aerojet Rocketdyne to produce a new version of the engine called the RS-25E that’s designed to be expendable. Unfortunately, these design changes come at a steep price. Each RS-25E will cost NASA nearly $150 million, which is more than what SpaceX charges for a flight on the Falcon Heavy. With a per-launch price that will easily exceed that of the infamously expensive Space Shuttle, it’s difficult to imagine how SLS can possibly remain competitive with reusable commercial vehicles set to begin operation within the current decade such as SpaceX’s Starship and Blue Origin’s New Glenn.
A Calculated Risk
After examining the data, NASA says the automated abort during the January 16th engine test was due to intentionally conservative test limits intended to avoid unnecessary stress on the booster. In a press conference, Administrator Bridenstine said that had this been a real flight, the engines would have remained firing for the full duration necessary to reach orbit. He went on to explain that there is an inherent risk involved should NASA or prime contractor Boeing decide to rerun the full duration test fire, as the propellant tanks can only be filled and drained a finite number of times.
Orion heading to the Moon during Artemis I
While nothing has been determined yet, these statements would seem to indicate that NASA may decide not to repeat the test fire and push ahead with the Artemis I mission to ensure they make the current November 2021 launch date. Conventional wisdom would say this is unwise, but as the first flight won’t have any human occupants, the usually risk-averse space agency might be willing to roll the dice if it means they can avoid another costly delay on a program that’s already facing fierce criticism.
On the other hand, live streaming the explosion of their first Space Launch System rocket to millions of viewers all over the world is hardly going to improve matters. A catastrophic failure during Artemis I would also very likely result in a delay to the crewed Artemis II that’s tentatively scheduled for August 2023. The resulting domino effect would likely make it all but impossible that NASA could make the already ambitious deadline for putting the first woman and next man on the lunar surface by 2024.
If somebody told you they recently purchased over 200 Raspberry Pis, you might think they were working on some kind of large-scale clustering project. But in this case, [James Dawson] purchased the collection of broken single-board computers with the intention of repairing them so they could be sent to developing countries for use in schools. It sounds like the logistics of that are proving to be a bit tricky, but we’re happy to report he’s at least made good progress on getting the Pis back up and running.
He secured this trove of what he believes to be customer returned Raspberries or the princely sum of £61 ($83 USD). At that price, even if only a fraction ended up being repairable, you’d still come out ahead. Granted all of these appear to be the original Model B, but that’s still a phenomenal deal in our book. Assuming of course you can find some reasonable way to triage them to sort out what’s worth keeping.
To that end, [James] came up with a Bash script that allowed him to check several hardware components including the USB, Ethernet, I2C, and GPIO. With the script on an SD card and a 3.5″ TFT plugged into the Pi’s header for output, he was able to quickly go through the box to get an idea of what sort of trouble he’d gotten himself into. He was only about half way through the process when he wrote his blog post, but by that point, had only found 40 Pis which wouldn’t start at all. He suspects these might be victims of some common issue in the power circuitry that he’ll investigate at a later date.
The majority of Pis he checked were suffering from nothing worse than some bent GPIO pins or broken SD card slots. Some of the more abused examples had their USB ports ripped off entirely, but were otherwise fine. Another 10 had dead Ethernet, and 4 appear to have damaged traces leading to their HDMI ports. While we’re interested in hearing if [James] can get those 40 dark Pis to fire back up, so far the results are quite promising.
Machine learning has come a long way in the last decade, as it turned out throwing huge wads of computing power at piles of linear algebra actually turned out to make creating artificial intelligence relatively easy. OpenAI have been working in the field for a while now, and recently observed some exciting behaviour in a hide-and-seek game they built.
The game itself is simple; two teams of AI bots play a game of hide-and-seek, with the red bots being rewarded for spotting the blue ones, and the blue ones being rewarded for avoiding their gaze. Initially, nothing of note happens, but as the bots randomly run around, they slowly learn. Over millions of trials, the seekers first learn to find the hiders, while the hiders respond by building barriers to hide behind. The seekers then learn to use ramps to loft over them, while the blue bots learn to bend the game’s physics and throw them out of the playfield. It ends with the seekers learning to skate around on blocks and the hiders building tight little barriers. It’s a continual arms race of techniques between the two sides, organically developed as the bots play against each other over time.
It’s a great study, and particularly interesting to note how much longer it takes behaviours to develop when the team switches from a basic fixed scenario to an changable world with more variables. We’ve seen other interesting gaming efforts with machine learning, too – like teaching an AI to play Trackmania. Video after the break.
Machine learning has come a long way in the last decade, as it turned out throwing huge wads of computing power at piles of linear algebra actually turned out to make creating artificial intelligence relatively easy. OpenAI have been working in the field for a while now, and recently observed some exciting behaviour in a hide-and-seek game they built.
The game itself is simple; two teams of AI bots play a game of hide-and-seek, with the red bots being rewarded for spotting the blue ones, and the blue ones being rewarded for avoiding their gaze. Initially, nothing of note happens, but as the bots randomly run around, they slowly learn. Over millions of trials, the seekers first learn to find the hiders, while the hiders respond by building barriers to hide behind. The seekers then learn to use ramps to loft over them, while the blue bots learn to bend the game’s physics and throw them out of the playfield. It ends with the seekers learning to skate around on blocks and the hiders building tight little barriers. It’s a continual arms race of techniques between the two sides, organically developed as the bots play against each other over time.
It’s a great study, and particularly interesting to note how much longer it takes behaviours to develop when the team switches from a basic fixed scenario to an changable world with more variables. We’ve seen other interesting gaming efforts with machine learning, too – like teaching an AI to play Trackmania. Video after the break.
Machine learning has come a long way in the last decade, as it turned out throwing huge wads of computing power at piles of linear algebra actually turned out to make creating artificial intelligence relatively easy. OpenAI have been working in the field for a while now, and recently observed some exciting behaviour in a hide-and-seek game they built.
The game itself is simple; two teams of AI bots play a game of hide-and-seek, with the red bots being rewarded for spotting the blue ones, and the blue ones being rewarded for avoiding their gaze. Initially, nothing of note happens, but as the bots randomly run around, they slowly learn. Over millions of trials, the seekers first learn to find the hiders, while the hiders respond by building barriers to hide behind. The seekers then learn to use ramps to loft over them, while the blue bots learn to bend the game’s physics and throw them out of the playfield. It ends with the seekers learning to skate around on blocks and the hiders building tight little barriers. It’s a continual arms race of techniques between the two sides, organically developed as the bots play against each other over time.
It’s a great study, and particularly interesting to note how much longer it takes behaviours to develop when the team switches from a basic fixed scenario to an changable world with more variables. We’ve seen other interesting gaming efforts with machine learning, too – like teaching an AI to play Trackmania. Video after the break.
In the early and mid 1990s there were a host of big players in the nascent public Internet that played their part in guiding the adventurous early Web users on their way. Many of them such as Netscape or Altavista have fallen by the wayside, while players such as Lycos and Yahoo are still in existence but shadows of their former selves. Some other companies broadened their businesses to become profitable and still exist quietly getting on with whatever they do. An example is Tucows, now a major domain name registrar, who have finally announced the closure of their software library that was such an essential destination in those times.
The company name was originally an acronym: “The Ultimate Collection Of Winsock Software”, started in 1993 by a library employee in Flint, Michigan. As its name suggests it was a collection of mostly shareware Windows software, and the “Winsock” refers to Windows Sockets, the API used by Windows versions of the day for accessing network resources. It seems odd to modern eyes, but connecting a 486 PC running Windows 3.1 to the Internet was something of a complex process without any of the built-in software we take for granted today. Meanwhile the fledgling Linux distributions were only for the extremely tech-savvy or adventurous, so the world of open-source software had yet to make a significant impact on consumer-level devices.
The passing of a Windows shareware library would not normally be a story of interest, but it is the part that Tucows played in providing a reliable software source on the early Web that makes it worthy of note. It’s something of a shock to discover that it had survived into the 2020s, it’s been so long since it was relevant, but if you sat bathed in the glow of a CRT monitor as you waited interminably for your CuteFTP download over your 28.8k modem to finish then you probably have a space for Tucows somewhere in your heart. If you fancy a trip down memory lane, the Internet Archive have a very period-ugly-looking version of the site from 1996.
It sometimes seems as though antennas and RF design are portrayed as something of a Black Art, the exclusive preserve of an initiated group of RF mystics and beyond the reach of mere mortals. In fact though they have their difficult moments it’s possible to gain an understanding of the topic, and making that start is the subject of a video from [Andreas Speiss]. Entitled “How To Build A Good Antenna”, it uses the design and set-up of a simple quarter-wave groundplane antenna as a handle to introduce the viewer to the key topics.
What makes this video a good one is its focus on the practical rather than the theoretical. We get advice on connectors and antenna materials, and we’re introduced to the maths through online calculators rather than extensive formulae. Of course the full calculations are there to be learned by those with an interest, but for many constructors they can be somewhat daunting. We’re shown a NanoVNA as a useful tool in the antenna builder’s arsenal, one which gives a revolutionary window on performance compared to the trial-and-error of previous times. Even the ground plane gets the treatment, with its effect on impedance and gain explored and the emergence of its angle as a crucial factor in performance. We think this approach does an effective job of breaking the mystique surrounding antennas, and we hope it will encourage viewers to experiment further.
Code can be beautiful, and good code can be a work of art. As it so happens, artful code can also result in art, if you know what you’re doing. That’s the idea behind Programming Posters, a project that Michael Fields undertook to meld computer graphics with the code behind the images. It starts with a simple C program to generate an image. The program needs to be short enough to fit legibly into the sidebar of an A2 sheet, and as if that weren’t enough of a challenge, Michael constrained himself to the standard C libraries to generate his graphics. A second program formats the code and the image together and prints out a copy suitable for display. We found the combination of code and art beautiful, and the challenge intriguing.
It always warms our hearts when we get positive feedback from the hacker community when something we’ve written has helped advance a project or inspire a build. It’s not often, however, that we learn that Hackaday is required reading. Educators at the Magellan International School in Austin, Texas, recently reached out to Managing Editor Elliot Williams to let him know that all their middle school students are required to read Hackaday as part of their STEM training. Looks like the kids are paying attention to what they read, too, judging by KittyWumpus, their ongoing mechatronics/coding project that’s unbearably adorable. We’re honored to be included in their education, and everyone in the Hackaday community should humbled to realize that we’ve got an amazing platform for inspiring the next generation of hardware hackers.
Hackers seem to fall into two broad categories: those who have built a CNC router, and those who want to build one. For those in the latter camp, the roadblock to starting a CNC build is often “analysis paralysis” — with so many choices to make, it’s hard to know where to start. To ease that pain and get you closer to starting your build, Matt Ferraro has penned a great guide to planning a CNC router build. The encyclopedic guide covers everything from frame material choice to spindle selection and software options. If Matt has a bias toward any particular options it’s hard to find; he lists the pros and cons of everything so you can make up your own mind. Read it at your own risk, though; while it lowers one hurdle to starting a CNC build, it does nothing to address the next one: financing.
Like pretty much every conference last year and probably every one this year, the Open Hardware Summit is going to be virtual. But they’re still looking for speakers for the April conference, and just issued a Call for Proposals. We love it when we see people from the Hackaday community pop up as speakers at conferences like these, so if you’ve got something to say to the open hardware world, get a talk together. Proposals are due by February 11, so get moving.
And finally, everyone will no doubt recall the Boston Dynamics robots that made a splash a few weeks back with their dance floor moves. We loved the video, mainly for the incredible display of robotic agility and control but also for the choice of music. We suppose it was inevitable, though, that someone would object to the Boomer music and replace it with something else, like in the video below, which seems to sum up the feelings of those who dread our future dancing overlords. We regret the need to proffer a Tumblr link, but the Internet is a dark and wild place sometimes, and only the brave survive.
SD cards were developed and released just before the turn of the millenium. Since then, we’ve seen smaller formats, miniSD and microSD, become popular for portable devices. However, sometimes bigger is better. [Useless Mod] dared to dream that dream, and put together a (physically) gigantic SD card.
In card is a full 10x scale reproduction of a SanDisk Extreme Pro SD card, complete with packaging, too. Built out of layers of laser cut MDF, it’s spray painted and given a high-quality label to complete the effect. The write protect slider instead serves in this case as a latch to open the assembly. Inside, there’s a simple regular SD card slot, wired up to the bigger card’s giant contacts made with copper tape. These interface with an huge 10x scale SD card slot, which acts as an adapter, allowing the giant SD to be used with regular hardware like cameras.
The giant SD might seem silly, but it has plenty of useful features. There’s flashing LEDs behind the label that make it easy to find if you drop it, along with an Apple Watch hidden inside that means it can be located using the Find My iPhone service. We’d have loved if it featured a RAID array full of 10 or more SD cards, as well, just to justify its enormous size. That said, [Useless Mod] points out that it’s big enough to keep a DSLR dry in a rainstorm when fitted to the hotshoe, so there’s that.
It’s a fun build, not a serious one, but one that we enjoyed on its merits. We suspect that, regardless of the card inside, you’ll have little luck recording at 4K with such long wire lengths in play. If you’ve ever had more normal compatability problems with the format, consider that it could be size causing your issues. Video after the break.
It’s fantastic that we’re living in the age of downloadable PDF patterns, it really is. But printing out a bunch of sheets of paper and taping them together is a tedious and tiresome process that can introduce error right from the start. This goes for any type of pattern, from sewing to R/C planes.
[Quinn]’s quarantine project is designed to cover both of those and everything in between. It’s a pattern projector made from stuff already on hand — a couple of offset projectors to scavenge parts from, and a large, trapezoidal mylar mirror from an old rear projection TV. At maximum zoom it projects a 4′ x 3′ image onto the tabletop, which sounds perfect for a whole lot of sewing patterns. At minimum zoom, the projected image fits on a foam core board.
We love that this dreamy setup can be stowed away so easily on hooks in the ceiling. [Quinn] had to perform a few hacks to make it all work together, including fabricating a bracket and some adjustable ties to hold the mirror aloft at just the right correct angle.
It’s fantastic that we’re living in the age of downloadable PDF patterns, it really is. But printing out a bunch of sheets of paper and taping them together is a tedious and tiresome process that can introduce error right from the start. This goes for any type of pattern, from sewing to R/C planes.
[Quinn]’s quarantine project is designed to cover both of those and everything in between. It’s a pattern projector made from stuff already on hand — a couple of offset projectors to scavenge parts from, and a large, trapezoidal mylar mirror from an old rear projection TV. At maximum zoom it projects a 4′ x 3′ image onto the tabletop, which sounds perfect for a whole lot of sewing patterns. At minimum zoom, the projected image fits on a foam core board.
We love that this dreamy setup can be stowed away so easily on hooks in the ceiling. [Quinn] had to perform a few hacks to make it all work together, including fabricating a bracket and some adjustable ties to hold the mirror aloft at just the right correct angle.
It’s fantastic that we’re living in the age of downloadable PDF patterns, it really is. But printing out a bunch of sheets of paper and taping them together is a tedious and tiresome process that can introduce error right from the start. This goes for any type of pattern, from sewing to R/C planes.
[Quinn]’s quarantine project is designed to cover both of those and everything in between. It’s a pattern projector made from stuff already on hand — a couple of offset projectors to scavenge parts from, and a large, trapezoidal mylar mirror from an old rear projection TV. At maximum zoom it projects a 4′ x 3′ image onto the tabletop, which sounds perfect for a whole lot of sewing patterns. At minimum zoom, the projected image fits on a foam core board.
We love that this dreamy setup can be stowed away so easily on hooks in the ceiling. [Quinn] had to perform a few hacks to make it all work together, including fabricating a bracket and some adjustable ties to hold the mirror aloft at just the right correct angle.
The NES Classic Mini was one of the earlier releases in what became a wider trend for tiny versions of classic retro consoles to be released. Everybody wanted one but numbers were limited, so only the lucky few gained this chance to relive their childhood through the medium of Donkey Kong or Mario Brothers on real Nintendo hardware. Evidently [Albert Gonzalez] was one of them, because he’s produced a USB adapter for the Mini controller to allow it to be used as a PC peripheral.
On the small protoboard is the Nintendo connector at one end, an ATtiny85 microcontroller, and a micro-USB connector at the other. The I2C interface from the controller is mapped to USB on the ATtiny through the magic of the V-USB library, appearing to the latter as a generic gamepad. It’s thought that the same interface is likely to also work with the later SNES Classic Mini controller. For the curious all the code and other resources can be found in a GitHub repository, so should you have been lucky enough to lay your hands on a NES Classic Mini then you too can join the PC fun.
