The new Raspberry Pi 4 is out, and slowly they’re working their way from Microcenters and Amazon distribution sites to desktops and workbenches around the world. Before you whip out a fancy new USB C cable and plug those Pis in, it’s worthwhile to know what you’re getting into. The newest Raspberry Pi is blazing fast. Not only that, but because of the new System on Chip, it’s now a viable platform for a cheap homebrew NAS, a streaming server, or anything else that requires a massive amount of bandwidth. This is the Pi of the future.
The Raspberry Pi 4 features a BCM2711B0 System on Chip, a quad-core Cortex-A72 processor clocked at up to 1.5GHz, with up to 4GB of RAM (with hints about an upcoming 8GB version). The previous incarnation of the Pi, the Model 3 B+, used a BCM2837B0 SoC, a quad-core Cortex-A53 clocked at 1.4GHz. Compared to the 3 B+, the Pi 4 isn’t using an ‘efficient’ core, we’re deep into ‘performance’ territory with a larger cache. But what do these figures mean in real-world terms? That’s what we’re here to find out.
The story of Linux so far, as short as it may be in the grand scheme of things, is one of constant forward momentum. There’s always another feature to implement, an optimization to make, and of course, another device to support. With developer’s eyes always on the horizon ahead of them, it should come as no surprise to find that support for older hardware or protocols occasionally falls to the wayside. When maintaining antiquated code monopolizes developer time, or even directly conflicts with new code, a difficult decision needs to be made.
Of course, some decisions are easier to make than others. Back in 2012 when Linus Torvalds officially ended kernel support for legacy 386 processors, he famously closed the commit message with “Good riddance.” Maintaining support for such old hardware had been complicating things behind the scenes for years while offering very little practical benefit, so removing all that legacy code was like taking a weight off the developer’s shoulders.
The rationale was the same a few years ago when distributions like Arch Linux decided to drop support for 32-bit hardware entirely. Maintainers had noticed the drop-off in downloads for the 32-bit versions of their distributions and decided it didn’t make sense to keep producing them. In an era where even budget smartphones are shipping with 64-bit processors, many Linux distributions have at this point decided 32-bit CPUs weren’t worth their time.
Given this trend, you’d think Ubuntu announcing last month that they’d no longer be providing 32-bit versions of packages in their repository would hardly be newsworthy. But as it turns out, the threat of ending 32-bit packages caused the sort of uproar that we don’t traditionally see in the Linux community. But why?
With all the hoopla surrounding the recent launch of the new Raspberry Pi 4, it’s easy to overlook another event in the Pi calendar. July will see the fifth anniversary of the launch of the Raspberry Pi Model B+ that ushered in a revised form factor. It’s familiar to us now, but at the time it was a huge change to a 40-pin expansion connector, four mounting holes, no composite video socket, and more carefully arranged interface connectors.
As the Pi 4 with its dual mini-HDMI connectors and reversed Ethernet and USB positions marks the first significant deviation from the standard set by the B+ and its successors, it’s worth taking a look at the success of the form factor and its wider impact. Is it still something that the Raspberry Pi designers can take in a new direction, or like so many standards before it has it passed from its originator to the collective ownership of the community of manufacturers that support it?
There’s a new embedded hacking tool on the scene that gives you an interactive Python interface for a speedy chip on a board with oodles of GPIO, the ability to masquerade as different USB devices, and a legacy of tricks up its sleeve. This is the GreatFET, the successor to the much loved GoodFET.
I first heard this board was close to launch almost a year ago and asked for an early look. When shipping began at the end of April, they sent me one. Let’s dig in for a hands-on review of the GreatFET from Great Scott Gadgets.
Spaceflight is inherently dangerous. It takes a certain type of person to willingly strap into what’s essentially a refined bomb and hope for the best. But what might not be so obvious is that the risks involved aren’t limited to those who are personally making the trip. The construction and testing of space-bound vehicles poses just as much danger to engineers here on the ground as it does to the astronauts in orbit. Arguably, more so. Far more individuals have given their lives developing rocket technology than have ever died in the cockpit of one of them.
Reddish brown exhaust of hydrazine thrusters
Ultimately, this is because of the enormous amount of energy stored in the propellants required to make a rocket fly. Ground support personnel need to exercise great care even when dealing with “safe” propellants, such as the classic combination of kerosene and liquid oxygen. On the other end of the spectrum you have chemicals that are so unstable and toxic that they can’t be handled without special training and equipment.
One of the most dangerous chemicals ever used in rocket propulsion is hydrazine; and yet from the Second World War to the present day, it’s been considered something of an occupational hazard of spaceflight. While American launch vehicles largely moved away from using it as a primary propellant, hydrazine is still commonly used for smaller thrusters on spacecraft.
But soon, that might change. NASA has been working on a project they call the Green Propellant Infusion Mission (GPIM) which is specifically designed to reduce modern spacecraft’s dependency on hydrazine. In collaboration with the Air Force Research Laboratory at California’s Edwards Air Force Base, the space agency has spearheaded the development of a new propellant that promises to not just replace hydrazine, but in some scenarios even outperform it.
So what’s so good about this new wonder fuel, called AF-M315E? To really understand why NASA is so eager to power future craft with something new, we first have to look at the situation we’re in currently.
Imagine a tub overflowing with bubble bath, except it’s a club dancefloor and music is pumping all night. This is what is known as a “foam party” — a wild and exciting concept that nonetheless many are yet to experience. The concept exploded in popularity in Ibiza in the 1990s, and foam parties are regularly held at nightclubs and festivals the world over.
Foam is generated with the obviously-named foam machine, and these can be readily purchased or hired for anyone wishing to host such an event. However, that’s not the hacker way. If you’re a little ingenious and take heed of the safety precautions, here’s how you can do it yourself.
Cyclic redundancy codes (CRC) are a type of checksum commonly used to detect errors in data transmission. For instance, every Ethernet packet that brought you the web page you’re reading now carried with it a frame check sequence that was calculated using a CRC algorithm. Any corrupted packets that failed the check were discarded, and the missing data was detected and re-sent by higher-level protocols. While Ethernet uses a particularly common CRC, there are many, many different possibilities. When you’re reverse-engineering a protocol that contains a CRC, although it’s not intended as a security mechanism, it can throw a wrench in your plans. Luckily, if you know the right tool, you can figure it out from just a few sample messages.
A case in point was discussed recently on the hackaday.io Hack Chat, where [Thomas Flayols] came for help reverse engineering the protocol for some RFID tags used for race timing. Let’s have a look at the CRC, how it is commonly used, and how you can reverse-engineer a protocol that includes one, using [Thomas’] application as an example.
