Commercially available motorized window blinds are a nice high-end touch for today’s automated home, but they tend to command a premium price. Seems silly to charge so much for what amounts to a gear motor and controller, which is why [James Wilcox] took matters into his own hands and came up with this simple and cheap wireless blind control.
[James] started his project the sensible way, with a thorough analysis of the problem. Once COTS alternatives were eliminated – six windows would have been $1200 – he came up with a list of deliverables, including tilting to pre-determined positions, tilt-syncing across multiple windows, and long battery life. The hardware in the head rail of each blind ended up being a Moteino on a custom PCB for the drivers, a $2 stepper motor, and a four-AA battery pack. The Moteino in one blind talks to a BeagleBone Black over USB and wirelessly to the other windows for coordinated control. As for battery life, [James] capitalized on the Moteino’s low-power Listen Mode to reduce the current draw by about three orders of magnitude, which should equate to a few years between battery changes. And he did it all for only about $40 a window.
Window blinds seem to be a tempting target for hacking, whether it’s motorizing regular blinds or interfacing commercial motorized units into a home automation system. We like how compact this build is, and wonder if it could be offered as an aftermarket add-on for manual blinds.
Continue reading “Compact Controllers Automate Window Blinds”
There’s a lot to be said for open source software. The ability to change code to suit one’s needs, the fact that security vulnerabilities can be easier to find, and the overall transparency are just the tip of the iceberg when it comes to the strengths of using open source software. And, while Microsoft is no Apple when it comes to locking down their source code, their operating system is still, unfortunately, closed.
Don’t despair, though! There is a project out there that aims to change this. No, they’re not stealing anything or breaking into any computers to obtain Microsoft’s code. They’re writing their own version of Windows called ReactOS that aims to be binary-compatible with Windows. The software has been in development for over a decade, but they’re ready to release version 0.4 which will bring USB, sound, networking, wireless, SATA, and many more features to the operating system.
While ReactOS isn’t yet complete for everyday use, the developers have made great strides in understanding how Windows itself works. There is a lot of documentation coming from the project regarding many previously unknown or undocumented parts of Windows, and with more developers there could be a drop-in replacement for Windows within a few years. It’s definitely worth a shot if you fondly remember the frontier days of Linux where doing things like reading information on a CD required extensive experience using the terminal. If this is a little too much, though, there are other unique operating systems out there to investigate.
Thanks for the tip, [Matt]!
Over the past few months, a number of companies and designers have started picking up the newest Intel SoCs. Intel has to kill ARM somehow, right? The latest of these single board x86 computers is the Lattepanda. It’s a tiny board that can run everything a 5-year-old desktop computer can run, including a full version of Windows 10.
This isn’t the first time we’ve seen a tiny x86 board in recent months. Last October, an x86 board that takes design cues from the Raspberry Pi 2 hit Kickstarter. These are proper PCs, with the ability to run Windows 10, Linux, and just about every other environment under the sun.
The specs for the Lattepanda include a quad-core Cherry Trail running at 1.8GHz. the RAM is either 2GB or 4GB depending on configuration, and 32GB of eMMC Flash. Peripherals include USB 3.0, Ethernet, WiFi, Bluetooth, and integrated graphics supporting either HDMI or a DSI connector.
But of course a computer is just a computer, and you can’t sell a machine that only runs Skype to the ‘maker’ market. The Lattepanda also includes an ATMega32u4 as a coprocessor, giving this board ‘Arduino functionality’. In my day we walked uphill both ways to get a parallel port, but I digress.
While these tiny x86 boards might not be available in a year’s time, and the companies behind them may fall off the face of the planet, the introduction of these devices portends a great war over the horizon. Intel wants the low-power SoC market, a space until now reserved entirely for ARM-based devices.
Programmers and software engineers will always use the latest development environments, the trendiest frameworks, and languages they learned only 21 days ago. What if this weren’t the case? What if developers put care into their craft and wrote programs with an old world charm? What if Windows executables were made with the same patience as artisanal firewood, or free range granola? [Steve] has done it. He’s forging a path into the wilds of truly hand crafted executables.
The simplest executable you could run on a Windows box is just a simple .COM file. This is an extremely simple file format that just contains code and data loaded into 0100h, and a jump to another point in the code. The DOS .EXE file format is slightly more complicated, but not by much. [Steve]’s goal was to build a proper Windows executable without a compiler, assembler, linker, or anything else.
Continue reading “Bespoke, Artisanal, Hand Made Executables”
Manufacturers of 3D printers have a lot to do before they catch up with makers of the cheapest 2D, paper-based printers. If you’ve ever taken an inkjet apart, you’ll most likely find some sort of closed-loop control on at least one of the axes. The 2D printer will tell you when you’re out of ink, when a 3D printer will go merrily along, printing in air without filament. File formats? Everything is Gcode on a 3D printer, and there are dozens, if not hundreds of page description languages for 2D printers.
The solution to some of these problems are drivers – software for a 3D printer that slowly consumes the slicing of an object, printer settings, and placing an object on the bed. It’s coming, and the people who are responsible for making your 2D printer work with your computer are busy at work messing up the toolchain for your 3D printer.
The latest version of CUPS (C Unix Printing System) adds support for 3D printers. This addition is based on meetings, white papers, and discussions in the Printer Working Group (PWG). There has already been a lot of talk about what is wrong with the current state of 3D printer toolchains, what can be improved, and what should be completely ignored. Let’s take a look at what all of this has accomplished.
Continue reading “Drivers for 3D Printers and Why We Need Them”
[Voltagex] was fed up with BSODs on his Windows machine due to a buggy PL2303 USB/serial device driver. The Linux PL2303 driver worked just fine, though. A weakling would simply reboot into Linux. Instead, [Voltagex] went for the obvious workaround: create a tiny Linux distro in a virtual machine, route the USB device over to the VM where the drivers work, and then Netcat the result back to Windows.
OK, not really obvious, but a cool hack. Using Buildroot, a Linux system cross-compilation tool, he got the size of the VM down to a 32Mb memory footprint which runs comfortably on even a small laptop. And everything you need to replicate the VM is posted up on Github.
Is this a ridiculous workaround? Yes indeed. But when you’ve got a string of tools like that, or you just want an excuse to learn them, why not? And who can pass up a novel use for Netcat?
[Daniel] found himself with a need to connect a single USB device to two Linux servers. After searching around, he managed to find an inexpensive USB switch designed to do just that. He noticed that the product description mentioned nothing about Linux support, but he figured it couldn’t be that hard to make it work.
[Daniel] started by plugging the device into a Windows PC for testing. Windows detected the device and installed an HID driver automatically. The next step was to install the control software on the Windows system. This provided [Daniel] with a tray icon and a “switch” function. Clicking this button disconnected the HID device from the Windows PC and connected the actual USB device on the other side of the USB switch. The second computer would now have access to the HID device instead.
[Daniel] fired up a program called SnoopyPro. This software is used to inspect USB traffic. [Daniel] noticed that a single message repeated itself until he pressed the “switch” button. At that time, a final message was sent and the HID device disconnected.
Now it was time to get cracking on Linux. [Daniel] hooked up the switch to a Linux system and configured a udev rule to ensure that it always showed up as /dev/usbswitch. He then wrote a python script to write the captured data to the usbswitch device. It was that simple. The device switched over as expected. So much for having no Linux support!