What do you do when you want to rock out on your keytar without the constraints of cables and wires? You make your own wireless keytar of course! In order to get the job done, [kr1st0f] built a logic translator circuit. This allows him to transmit MIDI signals directly from a MIDI keyboard to a remote system using XBEE.
[kr1st0f] started with a MIDI keyboard that had the old style MIDI interface with a 5 pin DIN connector. Many new keyboards only have a USB interface, and that would have complicated things. The main circuit uses an optoisolator and a logic converter to get the job done. The MIDI signals are converted from the standard 5V logic to 3.3V in order to work with the XBEE.
The XBEE itself also needed to be configured in order for this circuit to work properly. MIDI signals operate at a rate of 31,250 bits per second. The XBEE, on the other hand, works by default at 9,600 bps. [kr1st0f] first had to reconfigure the XBEE to run at the MIDI bit rate. He did this by connecting to the XBEE over a Serial interface and using a series of AT commands. He also had to configure proper ID numbers into the XBEE modules. When all is said and done, his new transmitter circuit can transmit the MIDI signals wirelessly to a receiver circuit which is hooked up to a computer.
Smartwatches are the next big thing. Nobody knows what we’re going to use them for, but that’s never stopped a product from being the hottest item around. The WeLoop Tommy isn’t the Apple Watch, it isn’t the Moto360, and it isn’t the Microsoft Band. It is, however, a nice smartwatch with a Sharp memory display and a battery that lasts longer than a few days. For his Hackaday Prize entry, [Krzysiek] is making an open source firmware for the WeLoop Tommy that will add capabilities no other smartwatch has.
This project is a complete reverse engineering of the WeLoop Tommy smartwatch. [Krzysiek] is tearing everything down to the bare components and figuring out how the RAM, Flash, buttons, LCD, and accelerometer connect to the processor. After that, it’s time for custom firmware.
Already [Krzysiek] has a test app that displays [OSSW] on the Sharp memory display. It’s not much, but the hardware is solid. With the right firmware, the WeLoop Tommy will be able to do just about everything an Android, Apple, or Microsoft smartwatche can do using repurposed hardware and open source firmware.
The Apple IIGS is the 16 bit upgrade to the popular 8 bit Apple II computer line, and with its massive boost in graphics, an Ensoniq sound system, and backwards compatibility with the 8 bit machines makes this box desirable to many retro enthusiast. The last OS update, 6.0.1, was released over 22 years ago. While it worked well for the early 90s, it was by no means perfect.
Last Sunday, a post popped up on callapple.org, announcing Apple IIgs System 6.0.2. Updates include a driver for the unreleased Apple II Ethernet card, fixes various bugs in the file system translation system, various bugfixes to existing system programs, fast drawing and animation tools, and of course an update to the finder to show the new revision number.
With a hope for even more bug fixes in a possible 6.0.3 revision its good to see people still giving the old Apple II line some love, as the old Apples don’t have as large of a following as their Atari and Commodore brethren.
L.A. artist [Jonathan Fletcher Moore] sent us this fantastic tech-art piece on dehumanization and drone warfare. Talking too much about art is best left to the artists, so we’ll shut up and let you watch the video below the break.
The piece is essentially a bunch of old cap guns with servos that pull their triggers. A Raspberry Pi with an Internet connection fetches data on US drone strikes from www.dronestre.am and fires off a cap every time someone is killed. At the same time, the story version of the data is printed out in thermal paper that cascades onto the floor.
Viewers are encouraged to sit underneath all the cap guns and wait. Talk about creepy and suspenseful. And a tiny reflection of the everyday fears that people who live under drone-filled skies.
[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.
The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.
The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.
How Echo Communicates with WeMo Devices
[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.
[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.
There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?
Last weekend saw the announcement of ProxyHam, a device that anonymizes Internet activity by jumping on WiFi from public libraries and cafes over a 900MHz radio link. The project mysteriously disappeared and was stricken from the DEFCON schedule. No one knows why, but we spent some time speculating on that and on what hardware was actually used in the undisclosed build.
[Samy Kamkar] has just improved on the ProxyHam concept with ProxyGambit, a device that decouples your location from your IP address. But [Samy]’s build isn’t limited to ProxyHam’s claimed two-mile range. ProxyGambit can work anywhere on the planet over a 2G connection, or up to 10km (6 miles) away through a line-of-sight point to point wireless link.
The more GSM version of ProxyGambit uses two Adafruit FONA GSM breakout boards, two Arduinos, and two Raspberry Pis. The FONA board produces an outbound TCP connection over 2G. The Arduino serves as a serial connection over a reverse TCP tunnel and connects directly to the UART of a Raspberry Pi. The Pi is simply a network bridge at either end of the connection. By reverse tunneling a TCP connection through the ‘throwaway’ part of the build, [Samy] can get an Internet connection anywhere that has 2G service.
Although it’s just a proof of concept and should not be used by anyone who actually needs anonymity, the ProxyGambit does have a few advantages over the ProxyHam. It’s usable just about everywhere on the planet, and not just within two miles of the public WiFi access point. The source for ProxyGambit is also available, something that will never be said of the ProxyHam.
The handlebars of this Honda CL175 ended up being perfect for holding two Nixie tubes which serve as the speedometer. There are two circular cavities on the front fork tree which are the same size as the Nixies. Wrapping the tubes in a bit of rubber before the installation has them looking like they are factory installed!
This isn’t a retrofit, he’s added the entire system himself. It starts with a hall effect sensor and magnets on the rear wheel and swing arm. Right now the result is 4 MPH resolution but he plans to add more magnets to improve upon that. For now, the driver and speedometer circuitry are hosted on protoboard but we found a reddit thread where [Johnathan] talks about creating a more compact PCB. If your own bike lacks the fork tree openings for this (or you need help with the drivers) check out this other Nixie build for a slick-looking enclosure idea.
The link at the top is a garage demo, but last night he also uploaded a rolling test to show the speedometer in action. Check out both videos after the break.
