[Joedefa] had a Griffin Beacon Universal Remote that was collecting dust, and decided that it needed to stop collecting dust. He had a growing number of wireless devices in his house and found himself in need of a remote to control them all. The Griffin Beacon fit the bill, but most of his lights and outlets were RF controlled. So he did what hackers do best… broke out the screw driver and soldering iron and rewired it!
[Joedefa] is using an Attiny85 as the brains between an infrared LED and a RF transmit module (if anyone can identify the source of this module, please let everyone know in the comments). A pair of red and green LEDs lets him know if the remote has received commands successfully.
It’s always nice to see a discontinued product made useful once more with a little ingenuity and
an Arduino some hacking skill. Hat’s off to [Joedefa] for a righteous hack!
If you’re looking for a simple way to make an RF transmitter, check out [Tomasz]’s Morse code transmitter. His design uses nothing more than a microcontroller and a 16MHz crystal to transmit CW Morse code on 96MHz. We’ve seen some similar designs that work at lower frequencies, but transmitting up at 96MHz is pretty impressive.
[Tomasz] used an STM32L microcontroller for this project, which isn’t specced to run up at the high frequencies he wanted to transmit at. To get around this, [Tomasz] wired a 16Mhz oscillator up to microcontroller’s clock input. The clock input is run into the micro’s PLL which is capable of generating high frequencies. He mentions that you can use the internal oscillator instead of a crystal, but it has a ton of phase noise and splatters all over the spectrum.
[Tomasz] chose to start transmitting at 96MHz, which can be picked up by a standard FM radio. To generate this frequency, he set the PLL to multiply the 16MHz crystal up to 192MHz followed by a clock divide of 2 which brings it down to 96MHz. The microcontroller’s CPU runs on the 16MHz crystal input before it goes into the PLL. Next [Tomasz] enabled the MCO clock output pin which routes the 96MHz signal to the outside world.
Transmitting CW is pretty simple; it just involves turning a fixed-frequency transmitter on and off. [Tomasz] wrote a function that enables and disables the MCO output pin. This has the effect of keying any Morse code string you throw at it. Check out the video after the break to see the transmitter in action.
Continue reading “Morse Code RF Transmitter from a Micro’s Clock Output”
Injection molding machines are able to form very detailed plastic parts, simply by squirting plastic into a mold. 3D printers squirt plastic. Why no one thought of using a 3D printer extruder to push plastic into a mold until now is something we’ll never know.
[bfk] has been working on a way to produce very small, very detailed parts for a while now, and realized the extruder of a 3D printer serves most of the functions of an injection molding machine. It takes plastic, melts it, and forces it through an orifice. Whether that plastic goes to a build platform or into a mold is beside the point; but with a simple silicone mold, anyone can replicate extremely small parts with a tool every hackerspace already has.
The tools required are RTV rubber, which is the most popular mold material around. Aside from that, it’s just silicone lubricant, dowels and LEGO to make sprues, and of course something to make a mold from. Once the mold is made, it’s a simple matter of holding the mold up to the nozzle of a printer and extruding a bit of plastic.
The resulting ‘print’ is as detailed as the best prints that will ever come off a resin printer. It’s great for making parts for very small models like [bfk]’s current project, but this technique could be expanded to anything that needs a lot of small plastic parts with tight tolerances.
Video of the process below.
Continue reading “Turning a 3D Printer into an Injection Molding Machine”
The Useless Machine – a machine with a toggle switch, a mechanical arm, and something that only exists to turn itself off – is a staple of Instructables and builds from random workbenches the world over. It’s cliché, and now hackaday.io has a better project: The Annoying Machine, a machine that exists purely to annoy.
According to [unigamer], the Annoying Machine is the evil cousin of the Useless Machine. On the outside, it’s extremely simple: a switch labeled ‘on’ and ‘off’, and a hole for an LED. Turn the switch on, and the Annoying Machine will emit an annoying buzzing sound. Switch the Machine off, and the buzzing will go away. Then the switch will flick itself back to on. Insidious.
A switch and buzzer is easy enough, but the key component of this build is an actuated rocker switch. It’s basically a normal toggle switch with two additional terminals for a coil that can move the switch back and forth electronically. Throw in an Arduino, buzzer, battery, and a boost converter for the switch, and that’s just about all there is to it.
How to deactivate the Annoying Machine? There’s an accelerometer attached to the Arduino, and by throwing the box up in the air after flicking the switch off, it will reset. There are already plans for a Version 2 of the Annoying Machine that will be even louder and made out of aluminum. Anything to protect it from the inevitable hammers of frustration.
Continue reading “The Annoying Machine”
The BeagleBone Black has a powerful featureset: decent clock speed, analog inputs, multiple UART, SPI and I2C channels and on-board memory, to name a few. One missing feature seems to be the lack of support for the two on-board Programmable Real-time Units (PRU’s). Each of these 32-bit processors run independently of the main processor, but are able to interface with the main processor through the use of shared RAM and some interrupts. Unfortunately, PRU’s are not supported and in the absence of information, difficult to program. Enabling the PRU’s will allow them direct access to external sensors via the GPIO pins, for example. Perhaps most enticing is the idea that the PRU’s add real-time processing capability to the BBB.
[Thomas Freiherr] is working on the libpruio project to allow PRU support on the BBB. It is “designed for easy configuration and data handling at high speed. libpruio software runs on the host (ARM) and in parallel on a Programmable Realtime Unit SubSystem (= PRUSS or just PRU) and controls the subsystems”. Additional information about the project is available on the libpruio wiki, and files can be downloaded from here (German Page).
This paper presented at inter.noise2014 (PDF) a couple of months ago has a nice comparison of various small computer/controller boards and outlines the advantages of the BBB once its PRUs are enabled. If readers come across applications of the BBB with PRUs enabled, let us know in the comments. If you want to work your way into the world of the PRU we highly recommend this tutorial series.
Thanks for sending in the tip, [Patrick]
[Image Source: libpruio stepper motor example]
People implementing the Scrum Methodology for project management often record all their tasks on a big whiteboard. However, it’s useful to have up-to-date graphs to ensure projects are on track. [Sprite_TM] augmented the whiteboard by building an Wi-Fi connected E-Ink Display.
Interfacing with E-Ink displays isn’t easy. A variety of voltages are needed, and the connectors used are tiny. We’ve seen some nice solutions, such as the RePaper
display. [Sprite_TM] chose the ED060SC4 display which is available from eBay and has been throughly reverse engineered
. A custom breakout board was built up to connect to the tiny FPC pins and generate the required voltages using the LT1945
The next step was adding on Wi-Fi. The ESP12 module was an obvious solution. This module provides Wi-Fi connectivity and a processor capable of controlling the display. The display is powered by a tablet battery, which makes it totally wireless and operates for about 200 days.
A simple laser cut enclosure holds all the bits together, and contains magnets that stick the screen to the whiteboard. On the software side, images are streamed to the ESP12’s processor and loaded directly to the screen, since the ESP12 doesn’t have enough RAM to store an entire screen worth of data. All the firmware can had by cloning a Git repository.
Hackers everywhere are having a lot of fun with SDR – as is obvious from the amount of related posts here on Hackaday. And why not, the hardware is cheap and easily available. There are all kinds of software tools you can use to dig in and explore, such as SDR# , Audacity, HDSDR and so on. [illias] has been following SDR projects for a while, which piqued his interest enough for him to start playing with it. He didn’t have any real project in mind so he focused on studying the methodology and the tools available for analyzing 433MHz RF transmission. He describes the process of using MATLAB to recover the transmissions being received by the SDR
He started off by studying the existing tools available to uncover the details of the protocol. The test rig uses an Arduino UNO with the rc-switch library to transmit via a common and inexpensive 433MHz module. SDR# is used to record the transmissions and Audacity allows [illias] to visualize the resulting .wav files. But the really interesting part is where he documents the signal analysis using MATLAB.
He used the RTL-SDR package in conjunction with the Communications System Toolbox to perform spectrum analysis, noise filtering and envelope extraction. MATLAB may not be the easiest to work with, nor the cheapest, but its powerful features and the fact that it can easily read data coming from the SDR makes it an interesting tool. For the full skinny on what this SDR thing is all about, check out Why you should care about Software Defined Radio.