hardware

84 Articles

Adding In-Game Reset To Classic Playstations

June 1, 2021 by 4 Comments

The first Playstation is quickly approaching three decades since its release, and while this might make some of us who were around for that event feel a little aged, the hardware inside these machines isn’t getting any younger either. Plenty of people are replacing the optical drive in the original hardware with an optical drive emulator as they begin to fail, and with that comes the option for several other modifications to the hardware like this in-game reset mod.

In-game reset is a function that allows a console to be reset via a controller button combination rather than pressing the console’s reset button directly. Especially for devices modified with either the XStation or PSIO drive emulators, this can be a handy feature to have as this method can more easily take the user back to the emulator menu as well as physically reset the device. The modification is a small PCB which attaches to the controller port and, unlike previous versions, only requires a single pin to be soldered to the Playstation’s control board.

If you’re someone who enjoys playing games on original hardware rather than a patchwork of emulators, this could be an excellent addition to your PS1 that still allows most of the original feel and experience the PS1 offered. The drive emulator can greatly expand the range of the hardware as well, much like this NES cartridge which similarly expands the capabilities of that much older system.

DOOM On A Bootloader Is The Ultimate Cheat Code

April 16, 2021 by 13 Comments

Porting DOOM to run on hardware never meant to run it is a tradition as old as time. Getting it to run on embedded devices, ancient computers, virtual computers, and antique video game consoles are all classic hacks, but what DOOM ports have been waiting for is something with universal applicability that don’t need a bespoke solution for each piece of hardware. Something like DOOM running within a bootloader.

The bootloader that [Ahmad] works with is called Barebox and is focused on embedded systems, often those running Linux. This is the perfect environment for direct hardware access, since the bootloader doubles as a bare metal hardware bring-up toolkit. Now that DOOM runs on this bootloader, it effectively can run anywhere from embedded devices to laptops with minimal work, and although running it in a bootloader takes away a lot of the hard work that would normally need to be done during a port, it may still need some tweaking for specific hardware not otherwise supported.

For those already running Barebox, the bareDOOM code can be found on [Ahmad]’s GitHub page. For those not running Barebox, it does have a number of benefits compared to other bootloaders, even apart from its new ability to play classic FPS games. For those who prefer a more custom DOOM setup, though, we are always fans of DOOM running within an NES cartridge.

Photo: AntonioMDA, CC BY-SA 4.0 via Wikimedia Commons

Orphaned IoT Sleep Tracker Resurrected As An Air Quality Monitor

April 10, 2021 by 9 Comments

If you have a Hello Sense sleep tracking device lying around somewhere in your drawer of discards, it can be brought back to life in a new avatar. Just follow [Alexander Gee]’s instructions to resurrect the Hello Sense as an IoT air quality data-logger.

In 2014, startup “Hello” introduced the Sense, an IoT sleep tracking device with a host of embedded sensors, all wrapped up in a slick, injection molded spherical enclosure. The device was quite nice, and by 2015, they had managed to raise $21M in funding. But their business model didn’t seem sustainable, and in 2017, Hello shut shop. Leaving all the Sense devices orphaned, sitting dormant in beautifully designed enclosures with no home to dial back to.

The original Sense included six sensors: illumination, humidity, temperature, sound, dust / particulate matter on the main device, and motion sensing via a separate Bluetooth dongle called the Pill. [Alexander] was interested in air quality measurements, so only needed to get data from the humidity/temperature and dust sensors. Thankfully for [Alexander], a detailed Hello Sense Teardown by [Lindsay Williams] was useful in getting started.

The hardware consisted of four separate PCB’s — power conditioning, LED ring, processor, and sensor board. This ensured that everything could be fit inside the orb shaped enclosure. Getting rid of the LED ring and processor board made space for a new NodeMCU ESP8266 brain which could be hooked up to the sensors. Connecting the NodeMCU to the I2C interface of the humidity/temperature sensor required some bodge wire artistry. Interfacing the PM sensor was a bit more easier since it already had a dedicated cable connected to the original processor board which could be reconnected to the new processor board. The NodeMCU board runs a simple Arduino sketch, available on his Git repo, to gather data and push it online.

For the online data display dashboard, [Alexander] found a nice solution by [Nilhcem] for home monitoring using MQTT, InfluxDB, and Grafana. It could be deployed via a docker compose file and have it up and running quickly. Unfortunately, such projects don’t usually succeed without causing some heartburn, so [Alexander] has got you covered with a bunch of troubleshooting tips and suggestions should you get entangled.

If you have an old Sense device lying around, then this would be a good way to put it some use. But If you’d rather build an air-quality monitor from scratch, then try “Building a Full-Fat Air-Quality Monitor” or “An Air-quality Monitor That Leverages the Cloud“.

Direct Memory Access: Data Transfer Without Micro-Management

March 31, 2021 by 16 Comments

In the most simple computer system architecture, all control lies with the CPU (Central Processing Unit). This means not only the execution of commands that affect the CPU’s internal register or cache state, but also the transferring of any bytes from memory to to devices, such as storage and interfaces like serial, USB or Ethernet ports. This approach is called ‘Programmed Input/Output’, or PIO, and was used extensively into the early 1990s for for example PATA storage devices, including ATA-1, ATA-2 and CompactFlash.

Obviously, if the CPU has to handle each memory transfer, this begins to impact system performance significantly. For each memory transfer request, the CPU has to interrupt other work it was doing, set up the transfer and execute it, and restore its previous state before it can continue. As storage and external interfaces began to get faster and faster, this became less acceptable. Instead of PIO taking up a few percent of the CPU’s cycles, a big transfer could take up most cycles, making the system grind to a halt until the transfer completed.

DMA (Direct Memory Access) frees the CPU from these menial tasks. With DMA, peripheral devices do not have to ask the CPU to fetch some data for them, but can do it themselves. Unfortunately, this means multiple systems vying for the same memory pool’s content, which can cause problems. So let’s look at how DMA works, with an eye to figuring out how it can work for us.
Continue reading “Direct Memory Access: Data Transfer Without Micro-Management” →

Open-Source Thermostat Won’t Anger Your Landlord

February 6, 2021 by 51 Comments

[Nathan Petersen] built a Hackable Open-Source Thermostat to smooth out temperature fluctuations caused by the large hysteresis of the bimetallic strip thermostat in his apartment. While it may be tempting to adjust the “anticipator” to take care of the problem or even replace the bimetallic thermostat with an electronic version, building your own thermostat from scratch is a good way to add to your project portfolio while making your way through college. Plus, he got to hone his hardware and software design chops.

The hardware is designed around the STM32, using a cheap, minimal variant since the device just needs to sense temperature and control the furnace in on-off mode. The TMP117 high-accuracy, low-power, temperature sensor was selected for temperature measurement since accuracy was an essential feature of the project. Dry-contact output for the furnace is via a normally-open solid state relay (opto-isolator). For the user interface, instead of going the easy-route and using an I2C/SPI OLED or LCD display, [Nathan] used three 7-segment LED displays, each driven by an 8-channel constant current driver. The advantage is that the display can be viewed from across the room, and it’s brightness adjusted via PWM. Temperature set-point adjustment is via a simple slide potentiometer, whose analog voltage is read by the micro-controller ADC. To remind about battery replacement, a second ADC channel on the micro-controller monitors the battery voltage via a voltage divider. The PCB components are mostly surface mount, but the packages selected are easy enough to hand solder.

[Nathan]’s Github repo provides the hardware and firmware source files. The board is designed in Altium, but folks using KiCad can use either the awesome Altium2KiCad converter or the online service for conversion. (The results, with some minor errors that can be easily fixed, are quite usable.) Serendipitously, his PCB layout worked like a charm the first time around, without requiring any rework or bodge wires.

The firmware is a few hundred lines of custom bare-metal C code, consisting of drivers to interface with the hardware peripherals, a UI section to handle the user interface, and the control section with the algorithm for running the furnace. [Nathan] walks us through his code, digging into some control theory and filtering basics. After making a few code tweaks and running the thermostat for some time, [Nathan] concludes that it is able to achieve +0.1°F / -0.5°F temperature regulation with furnace cycles lasting about 10-15 minutes (i.e. 4-6 cycles per hour). Obviously, his well insulated apartment and a decent furnace are also major contributing factors. Moving on, for the next version, [Nathan] wants to add data collection capabilities by adding some memory and SD card storage, and use an RTC to allow seasonal adjustments or time-based set-points.

This is his first attempt at a “functional’ useful project, but he does love to build the occasional toy, such as this POV Top.

Ask Hackaday: What’s In Your Fastener Bin?

January 11, 2021 by 142 Comments

A Saturday afternoon. The work week was done, the household chores were wrapped up, and with almost a week left until Christmas, there was just enough wiggle room to deny that there was still a ton of work left to prepare for that event. It seemed like the perfect time to escape into the shop and knock out a quick project, one that has been on the back burner since at least March. I’m nothing if not skilled in the ways of procrastination.

This was to be a simple project — adding an aluminum plate to a plastic enclosure that would serve as an antenna entry point into my shack. Easy as pie — cut out an rectangle of aluminum, cut and drill a few holes, call it a day. Almost all of my projects start out that way, and almost every time I forget that pretty much every one of those builds goes off the rails at exactly the same point: when I realize that I don’t have the fasteners needed. That’s what happened with this build, which had been going swimmingly up to that point — no major screw-ups, no blood drawn. And so it was off to the hardware store I trundled, looking for the right fasteners to finish the job.

Finding hardware has long been where my productivity goes to die. Even though I live a stone’s throw from at least half a dozen stores, each with a vast selection of hardware and most open weekends and nights, the loss of momentum that results from changing from build-mode to procure-mode has historically been deadly to my projects. I’m sure I’m not the only one who has run into this issue, so the question is: what can a hacker do to prevent having to run out for just the right fasteners?

Continue reading “Ask Hackaday: What’s In Your Fastener Bin?” →

Hardware Vs Software: Fight!

October 10, 2020 by 41 Comments

It’s one of the great cliches in the hacker world: the hardware type and the software type. You can tell which of these two you are quite easily. When a project is actually 20% done, but you think it’s 90% done, and you say to yourself “And the rest is a simple matter of software”, you’re a hardware type. Ask anyone who has read my code, and they’ll tell you, I’m a hardware type.

Along with my blindness to the difficulties of getting the code right, I’ve also admittedly got an underappreciation of what powers lie in the dark typing arts. But I am not too proud to tip my hat when I see an awesome application of the soft stuff. Case in point: this Go board sequencer that we ran last week. An overhead webcam parses players’ moves as they put black and white stones down while playing the game of Go, and turns this into music.

The pure software type will be saying “but there’s a webcam and a Go board”. And indeed, that’s true. There are physical elements to this project that anchor it in the shared reality of the two people playing. But a hardware project this isn’t; it’s OpenCV and Max/MSP that make it work.

For comparison, look at the complexity of this similar physical sequencer. It’s got a 16 x 16 array of LEDs and switches and a CNC milled, primed, and painted surface that’s the size of a twin bed. Sawdust and hand-soldering: that’s a hardware project.

What I love about the Go sequencer is that it uses software just right. The piece is still physical. It could have just as easily been a VR world, where the two people would interact with each other only inside their goggles. But somehow that’s not quite as human as putting stones on a wooden board, sitting across from, and maybe even looking at, your opponent. The players aren’t forced to think about the software. They don’t feel like they’re playing a video game.

But at the same time, the software side of things makes all of the horrible hardware problems go away. Nobody is soldering a rat’s nest of 169 switches. There’s a webcam plugged into the USB port of a laptop. There’s a deep simplicity there.

Should you always trade out arcade buttons for OpenCV? Absolutely not! But is it worth considering the soft side when doing it in hardware is just too, well, hard? I’m open.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!