Over the years, we’ve seen a good number of interfaces used for computer monitors, TVs, LCD panels and other all-things-display purposes. We’ve lived through VGA and the large variety of analog interfaces that preceded it, then DVI, HDMI, and at some point, we’ve started getting devices with DisplayPort support. So you might think it’s more of the same. However, I’d like to tell you that you probably should pay more attention to DisplayPort – it’s an interface powerful in a way that we haven’t seen before.
By [Belkin+Abisys], CC BY-SA 3.0The DisplayPort (shortened as DP) interface was explicitly designed to be a successor to VGA and DVI, originating from the VESA group – an organization created by multiple computer-display-related players in technology space, which has previously brought us a number of smaller-scale computer display standards like EDID, DDC and the well-known VESA mount. Nevertheless, despite the smaller scale of previous standards, DisplayPort has since become a hit in computer display space for a number of reasons, and is more ubiquitous than you might realize.
You could put it this way: DisplayPort has all the capabilities of interfaces like HDMI, but implemented in a better way, without legacy cruft, and with a number of features that take advantage of the DisplayPort’s sturdier architecture. As a result of this, DisplayPort isn’t just in external monitors, but also laptop internal displays, USB-C port display support, docking stations, and Thunderbolt of all flavors. If you own a display-capable docking station for your laptop, be it classic style multi-pin dock or USB-C, DisplayPort is highly likely to be involved, and even your smartphone might just support DisplayPort over USB-C these days. Continue reading “DisplayPort: A Better Video Interface”→
The DIY Commodore 64 cartridge. (Credit: Linus Åkesson)
When you want to write software for a system like the Commodore 64, the obvious and safe choice is to create an image that can be used with a tape or floppy drive emulator. Yet these come with the obvious disadvantage of loading time and manual steps, much like with the original hardware. Unfortunately, if you crave that instant-on experience that cartridges offer – courtesy of them being plugged directly into the system’s CPU bus – you better get an EE diploma to figure it all out. Or maybe not, as [Linus Åkesson] found out when he created a custom cartridge to boot his Commodordian project from.
For the core of the cartridge a bit of stripboard was sufficient to interface with the C64’s cartridge slot. Despite being single-sided, all the required signals were on one side of the slot. These include the EXROM line that informs the system that a cartridge is present, the ROML line that informs the cartridge when the system is trying to read from it, and of course the data bus. After this the interaction gets somewhat interesting, due to the use of the single-sided stripboard, as the address bus and other signals are on the non-connected side.
Working around this was the biggest challenge, but by creatively using the ROML and DotClk lines and by disabling the display output, the ATmega88 and 74HC541-based cartridge a working solution was created. There is still room for improvement here, naturally, but it would appear that if the goal is simply to autoload software on boot, this is definitely a workable solution. One could also splurge on double-sided stripboard, but that would strip away most of the fun of this solution.
Interfacing biological and electrical systems has traditionally been done with metal electrodes, but something flexible can be more biocompatible. One possible option is 3D-printed bioelectric hydrogels.
Electrically conductive hydrogels based on conducting polymers have mechanical, electrical, and chemical stability properties in a fully organic package that makes them more biocompatible than other systems using metals, ionic salts, or carbon nanomaterials. Researchers have now found a way to formulate bi-continuous conducting polymer hydrogels (BC-CPH) that are a phase-separated system that can be used in a variety of manufacturing techniques including 3D printing.
To make the BC-CPH, a PEDOT:PSS electrical phase and a hydrophilic polyurethane mechanical phase are mixed with an ethanol/water solvent. Since the phase separation occurs in the ink before deposition, when the solvent is evaporated, the two phases remain continuous and interspersed, allowing for high mechanical stability and high electrical conductivity which had previously been properties at odds with each other. This opens up new avenues for printed all-hydrogel bioelectronic interfaces that are more robust and biocompatible than what is currently available.
If you want to try another kind of squishy electrode gel, try growing it.
[Joren] recently did some work as part of an electronic music heritage project, and restored an 80s-era NeXTcube workstation complete with vintage sound card, setting it up with a copy of MAX, a graphical music programming environment. But there was one piece missing: MIDI. [Joren] didn’t let that stop him, and successfully created hardware to allow MIDI input and output.
The new panel provides all the connectors necessary to interface with either classic MIDI devices, or MIDI over USB (where it appears as a USB MIDI device to any modern OS.)
Interestingly, the soundcard for the NeXTcube has an RS-422 serial port and some 8-pin mini DIN connectors. They are not compatible with standard MIDI signals, but they’re not far off, either.
A metal enclosure with a 3D-printed panel rounds out the device, restoring a critical piece of functionality to the electronic music-oriented workstation.
MIDI as a protocol isn’t technically limited to musical applications, though that’s one place it shines. And just in case it comes in handy someday, you can send MIDI over I2C if you really need to.
[Jeff Lau]’s Mitsubishi 3000GT comes with all the essential features you’d expect in a fancy sports car from 1993: pop-up headlights, movable spoilers, and a fully-functional telephone handset in the center console. The phone was fully functional until North America’s first-generation AMPS cellular network was shut down back in 2008, since then, it hasn’t done much but show “NO SVC” on the display. That is, until [Jeff] decided to build a Bluetooth adapter that lets it connect to a modern smartphone.
The easy solution would have been to simply connect the handset’s speaker and microphone to a standard Bluetooth headset, but that would have destroyed the 1990s aesthetic it had going on. So what [Jeff] did instead was construct a plug-in module that hooks up to the phone’s base station in the trunk and communicates directly with all the existing systems. That way, the phone works in exactly the same way it always did: the radio is automatically muted during calls, the buttons on the steering column work as expected, and you can even dial and store numbers using the buttons on the handset.
No modifications required: the BlueTooth module is connected using the factory-installed cabling
It took a lot of reverse-engineering to figure out the technical details of the DiamondTel Model 92 that came with the car as a factory option. [Jeff] helpfully documented all of his findings on the project’s GitHub page, making it easy for anyone with a similar system to implement their own upgrades. The main components of the upgrade kit are a BM62 Bluetooth module that connects to a modern phone, a PIC18F27Q43 microcontroller to implement the car phone’s interface and menus, and several analog chips to process the audio. All of these are mounted on a piece of prototype board and housed in a standard plastic enclosure that neatly fits on top of the existing equipment in the trunk.
While the hardware mod is a pretty neat job already, the real strength of this project is in the software. [Jeff] worked hard to implement all relevant features and mimic the original interface as much as possible, even using 1G phone test equipment to simulate incoming calls from the long-gone network. He also added menu features to enable Bluetooth pairing, use voice assistants, and even play games including versions of Snake and Tetris stripped down to match the handset display’s constraints.
As classic phone conversions go, this is definitely one of the most impressive. [Jeff]’s extensive documentation should come in handy if you’ve got a similar model, but if you don’t, there’s still plenty of ways to connect modern electronics without defacing your classic ride’s interior.
One day in the future, we may interact with our electronic devices not with physical input or even voice commands, but simply by thinking about what we want to do. Such brain–computer interfaces (BCIs), combined with machine learning, could allow us to turn our ideas into reality faster and with less effort than ever before — imagine being able to produce a PCB design simply by thinking about how the completed circuit would work. Of course as an assistive technology, BCIs would be nothing less than life-changing for many.
Today BCIs are in their infancy, but that doesn’t mean there isn’t room for hackers and makers to experiment with the concept. [Ildar Rakhmatulin] has been working on low-cost open source BCIs for years, and with the recent release of his PiEEG on Crowd Supply, thinks he’s finally found an affordable solution that will let individuals experiment with this cutting edge technology.
Implemented as a shield that can be connected to a Raspberry Pi 3 or 4, the PiEEG features 8 channels for connecting wet or dry electrodes that can measure biosignals such as those used in electroencephalography (EEG), electromyography (EMG), and electrocardiography (ECG). With the electrodes connected, reading these biosignals is as easy as running a Python script. While primarily designed for neuroscience experimentation, [Ildar] says the device is also useful for learning more about signal processing, filters, and machine learning.
There’s a naming overload here, as two bits of security news this week are using the “MacStealer” moniker. We’re first going to talk about the WiFi vulnerability, also known as Framing Frames (pdf). The WPA encryption schemes introduced pairwise encryption, ensuring that not even other authenticated users can sniff each others’ traffic. At least that’s the idea, but this attack finds a couple techniques to bypass that protection.
A bit more background, there are a couple ways that packets can be delayed at the sender side. One of those is the power-save message, that signals the access point that the given client is going into a low power state. “Hold my calls, I’m going to sleep.” That message is a single bit in a frame header. And notably, that bit isn’t covered by WPA encryption or verification. An attacker can send a message, spoof a victim’s MAC address, and the access point marks that client as being in power-save mode.
This observation leads to a question: What happens when the encryption details change between the packet joining the queue, and actually transmitting? Turns out, the specifications on WiFi encryption don’t spell it out, and some implementations do the last thing you’d want, like sending the packets in the clear. Whoops. This behavior was the case in the Linux kernel through version 5.5.0, but starting with 5.6.0, the buffered packets were simply dropped when the encryption key was unavailable. Continue reading “This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key”→
