EPROM Timer

April 7, 2016 by Bryan Cockfield 29 Comments

[glitch] had a cheap EPROM eraser with very few features. Actually, that might be giving it too much credit: it’s barely more than a UV light that turns on when it’s plugged in and turns off when it’s ~~plugged out~~ unplugged. Of course it would be nice to implement some safety features, so he decided he’d hook it up to a software-controlled power outlet.

Of course, controlling a relay that’s wired to mains is old hat around here, and in fact, we’ve covered [glitch]’s optoisolated mains switch already. He’s gone a little beyond the normal mains relay project with this one, though. Rather than use a microcontroller to run the relay, [glitch] wrote a simple Ruby script on his computer to turn the EPROM eraser on for the precise amount of time that is required to erase the memory.The Ruby script drives the relay control directly over a USB to serial adapter’s RTS handshake pin.

[glitch]’s hack reminds us that if you just need a quick couple bits of slow output, a USB-serial converter might be just the ticket. You could imagine driving everything from standard lamps to your 3D printer’s bed heater (provided you use similar hardware), but it’s especially helpful for [glitch] who claims to forget to turn off the eraser when it’s done its job, which leaves a potentially dangerous UV source just lying about. It’s always a good idea to add safety features to a dangerous piece of equipment!

Impressive StarCraft 2 AI More Fair To Fleshy Opponents

March 31, 2016 by Gerrit Coetzee 18 Comments

There was a discussion in the comments when the Alpha Go results were released. Some commentors were postulating that AI researchers are discounting more fluid games such as the RTS StarCraft.

The comments then devolved into a discussion of what would make the AI fair to consider against a human player. Many times, AI in RTS games win because they have direct access to the variables in the game. Rather than physically looking at the small area of the screen where a unit is located and then moving their eye to take in strategic information like exact location, health, unit level, etc, the AI just knows that it’s at 120x,2000y,76%,lvl5, etc instantly. The AI also has no click lag as it gets direct access to the game’s API, it simply changes the variables and action queue of a unit directly.

So we were interested to see [Matt]’s Star Craft AI that required the computer to actually look at the game board and click. [Matt]’s AI doesn’t see using OpenCV, which in its own way is forcing the computer to look in a way that’s unnatural to it. He instead wrote some code to intercept the behind the scenes calls to the DirectX library.

The computer is then able to make determinations about what it is looking at using the texture information and other pieces sent to the library. Unlike AI’s that get a direct look at the variables, it has to then translate this and keep its own mental picture of the map and the situation. If a building is destroyed, for example, it has to go over and look at that part of the map, test what it’s seeing against a control, and then remove the building from its list.

The AI’s one big advantage are its robot fingers. Even though this AI has to click on the interface, it doesn’t do it with a weak articulated fleshy nub like the rest of us. This allows the AI to get crazy Actions Per Minute (APM) in the range of 500 to 2000.

The AI has only been tested against StarCraft’s built in cheater bots. So far it can win most games against the hard level bots. If you want to see a video of what the AI is looking at, check after the break.

Continue reading “Impressive StarCraft 2 AI More Fair To Fleshy Opponents” →

Museum Shows Off Retro Malware

March 25, 2016 by Bryan Cockfield 21 Comments

There’s some debate on which program gets the infamous title of “First Computer Virus”. There were a few for MS-DOS machines in the 80s and even one that spread through ARPANET in the 70s. Even John von Neumann theorized that programs might one day self-replicate. To compile all of these early examples of malware, and possibly settle this question once and for all, [Mikko Hypponen] has started collecting many of the early malware programs into a Museum of Malware.

While unlucky (or careless) users today are confronted with entire hard drive encryption viruses (or worse), a lot of the early viruses were relatively harmless. Examples include Brain which spread via floppy disk, the experimental ARPANET virus, or Elk Cloner which, despite many geniuses falsely claiming that Apples are immune to viruses, infected Mac computers of the 80s. [Mikko] has collected many more from this era that can be downloaded or demonstrated in a browser.

Retrocomputing is an active community, with users keeping gear of this era up and running despite it being 30+ years old. This software, while malicious at the time, is a great look into what the personal computing world was like in its infancy. And don’t forget, if you have a beige computer from a bygone era, you can always load up our Retro Page.

Thanks to [chad] for the tip!

KiCAD BOM Management

March 16, 2016 by Bryan Cockfield 17 Comments

KiCAD remains a popular tool for designing PCBs and other circuits, and with good reason: it’s versatile and it’s got pretty much everything needed to build any type of circuit board you’d want. It also comes with a pretty steep learning curve, though, and [Jeff] was especially frustrated with the bill of materials (BOM) features in KiCAD. After applying some Python and Kivy, [Jeff] now has a BOM manager that makes up for some of KiCAD’s shortcomings.

Currently, the tool handles schematic import, like-component consolidation, and a user-managed parts database that can be used to store and retrieve commonly used parts for the future. All of the changes can be saved back to the original schematic. [Jeff] hopes that his tool will save some time for anyone who makes more than one PCB a year and has to deal with the lack of BOM features native to KiCAD.

[Jeff] still has some features he’d like to add such as unit tests, a user guide, and a cleaner user interface. What other features are you anxious to see added to KiCAD?

This script is a great tool for anyone who has had similar frustrations. KiCAD is popular to modify and expand, too: there have been tools for mechanical CAD export, a parts-generator and cost-tracker, and an Eagle to KiCAD converter if you’re thinking of making the switch.

StickerBOM For KiCad

February 9, 2016 by Anool Mahidharia 28 Comments

When boards were larger and components mostly through hole, designers could put a lot of information on the silk legend – reference designator, values, additional text and so on. But with surface mount components becoming smaller and board real estate at a premium, modern boards do not have a lot of information marked on the silk layer. If you are building and distributing a short run of kits, perhaps for a round of beta testing, then [Adam Greig]’s StickerBOM python script for KiCad can be really handy. StickerBOM is a KiCad BOM exporter designed for people stuffing boards by hand. It generates a PDF for printable sticky labels, where each label reflects one BOM line from a supplier. You then stick these labels on the bags from your supplier, and they show you where the parts go.

The labels get printed with the reference designator, quantity, component value, package, vendor and part number. It also adds a drawing of the PCB with the relevant parts highlighted for easy location identification. To use it, schematic symbols must have the supplier field and part number added. The script can be run from the command line, or from the BOM manager in eeschema. The script is set up for Avery L7164 labels, but this setting can be changed. It’s still work in progress so there’s a couple of bugs to be aware of. It cannot process the bottom layer of the board, and the result is only as good as the data you provide. And if you have a large board with components spread all over, the resultant graphic printed on the label may not be ideal.

We are hoping this, and other scripts such as the Part generator and Cost spreadsheets or the script for mechanical CAD export, get added to future releases of KiCad. The KiCad version 5 Developer’s road map document already has some really nice feature additions in the works.

Shmoocon 2016: Efficient Debugging For OS X

January 19, 2016 by Brian Benchoff 27 Comments

Developers love their macs, and if you look at the software that comes with it, it’s easy to see why. OS X is a very capable Unix-ey environment that usually comes on very capable hardware. There is one, huge, unbelievable shortcoming in OS X: the debugger sucks. GDB, the standard for every other platform, doesn’t come with OS X and Apple’s replacement, LLDB is very bad. After crashing Safari one too many times, [Brandon Edwards] and [Tyler Bohan] decided they needed their own debugger, so they built one, and presented their work at last weekend’s Shmoocon.

Building a proper tool starts with a survey of existing tools, and after determining that GDB was apparently uninstallable and LLDB sucked, their lit review took a turn for the more esoteric. Bit Slicer is what they landed on. It’s a ‘game trainer’ or something that allows people to modify memory. It sort of works like a debugger, but not really. VDB was another option, but again this was rough around the edges and didn’t really work.

The problems with the current OS X debuggers is that the tools used by debuggers don’t really exist. ptrace is neutered, and the system integrity protection in OS X El Capitan has introduced protected locations that can not be written to by root. Good luck modifying anything in /Applications if you have any recent Mac.

With the goal of an easy-to-use debugger that was readily scriptable, [Brandon] and [Tyler] decided to write their own debugger. They ended up writing the only debugger they’ve seen that is built around kqueue instead of ptrace. This allows the debugger to be non-invasive to the debugged process, inject code, and attach to multiple processes at once.

For anyone who has every stared blankly at the ‘where is GDB’ Stack Overflow answers, it’s a big deal. [Brandon] and [Tyler] have the beginnings of a very nice tool for a very nice machine.

Raspberry Pi Wind Measurement

January 16, 2016 by Rud Merriam 18 Comments

A well organized approach to a project is a delight to see. [Pavel Gesyuk] takes just that approach with the experiments on his blog. Experiment 13 is a multi-part series using a Raspberry Pi as the heart of a weather station. [Pavel] is looking at wind speed and direction, and temperature measurement, plus solar power for the station. One of his videos, there are many, is after the break.

The anemometer and direction sensors are stock units wired to a Raspberry Pi A+ using an analog to digital daughter board. The data from the temperature sensor is acquired using I2C. During one part of the experiment he uses an EDIMAX WiFi adapter for collecting the data.

Python is [Pavel’s’ language of choice for development and freely shares his code for others to see. The code collects the data and displays it on a monitor connected to the Pi. The experiment also attempts to use solar power to charge batteries so the station is not dependent on mains power.

The mechanical assembly shows attention to detail commensurate with his project presentation and we respect how well organized the work is.

Continue reading “Raspberry Pi Wind Measurement” →