Automated Bed Warmer Control For Chilly Nights

January 4, 2015 by Bryan Cockfield 13 Comments

For most of the Northern Hemisphere, winter is in full swing right now. That means long, chilly nights. We assume [LC] is in one of these climes because it seems like his bed warmer wasn’t doing quite a good enough job of getting his bed up to a reasonable temperature before he climbed in. To alleviate some of his discomfort, he hacked into the control unit and added some automation.

The original controller uses a mechanical potentiometer to set the heat level. [LC] added a digital potentiometer which he can switch to in order to allow the automation (using a real-time clock to handle scheduling) to take over control of the bed warmer. This also preserves the original functionality of the controller. There is also an Arduino involved which handles the override from mechanical to digital potentiometer when a capacitive touch sensor is activated. This means that when someone attempts to take manual control of the device, the Arduino can switch the override circuit off.

There is quite a bit of detail on the project site about this hack, including the source code for the controller. [LC] also mentions that this could be interfaced to the web to allow remote control of the bed warmer. This is a great hack, and also fits into the idea of heating the person, not the room.

One Way To Get Rid Of That Fluorescent Buzzing Sound

January 4, 2015 by James Hobson 38 Comments

Tired of the persistent hum his fluorescent desk lamp made, [Andres Lorvi] decided he had to fix it. And by fix, we mean get rid of altogether. He liked the lamp though so he decided to convert it to LED — that way he’d save some money on electricity too!

Besides wanting to get rid of the hum, [Andres] had also been reading up on the effect of light temperature at night — bluish light is typically bad for your eyes when you’re trying to go to sleep. So he also took this opportunity to change the color temperature of the light in his room. Unfortunately it wasn’t as simple as just replacing the fluorescent with the LEDs — no, that would be far too easy…

Continue reading “One Way To Get Rid Of That Fluorescent Buzzing Sound” →

Hackaday Links: January 4, 2015

January 4, 2015 by Brian Benchoff 17 Comments

Chips as furniture is now a thing. It started off with a 555 footstool from Evil Mad Scientist and moved on to an EPROM coffee table. Now [msvm] over on the War Thunder forums has constructed a Nixie tube driver table. It’s based on the K155, and as a neat little addition, he’s included a real vintage chip under glass in the table.

Have some tongs, an anvil, and a blowtorch? Make some bottle openers out of framing nails. There’s a lot of variety here in the shapes of the bottle openers.

[Stephen] used a solid state relay he found on eBay to drive some Christmas lights. The SSR failed. That meant it was time to see inside of this relay looked like. The short answer is, ‘a lot of goop and epoxy’, but the traces look big enough to support the current it’s rated for.

Imagine a part of your 3D printer breaks. That’s alright, just print another…. oh, yeah. Well, I guess it’s time to make a bearing bracket out of wood.

The Electronica MK-54 and MK-61 (actually the Электроника МК-54) were incredibly popular Soviet programmable calculators. Now there’s an emulator for them.

[Rue Mohr] found a very cheap TFT display on an Arduino shield. The chip for the display was an SPF5408, a chip that isn’t supported by the most common libraries. He eventually got it to work after emailing the seller, getting some libraries, and renaming and moving a bunch of stuff. If you have one of these displays, [Rue] just saved you a bunch of time.

Ask Hackaday: A Robot’s Black Market Shopping Spree

January 4, 2015 by Sarah Petkus 75 Comments

It was bad when kids first started running up cell phone bills with excessive text messaging. Now we’re living in an age where our robots can go off and binge shop on the Silk Road with our hard earned bitcoins. What’s this world coming to? (_sarcasm;)

For their project ‘Random Darknet Shopper’, Swiss artists [Carmen Weisskopf] and [Domagoj Smoljo] developed a computer program that was given 100 dollars in bitcoins and granted permission to lurk on the dark inter-ether and make purchases at its own digression. Once a week, the AI would carrying out a transaction and have the spoils sent back home to its parents in Switzerland. As the random items trickled in, they were photographed and put on display as part of their exhibition, ‘The Darknet. From Memes to Onionland’ at Kunst Halle St. Gallen. The trove of random purchases they received aren’t all illegal, but they will all most definitely get you thinking… which is the point of course. They include everything from a benign Lord of the Rings audio book collection to a knock-off Hungarian passport, as well as the things you’d expect from the black market, like baggies of ecstasy and a stolen Visa credit card. The project is meant to question current sanctions on trade and investigate the world’s reaction to those limitations. In spite of dabbling in a world of questionable ethics and hazy legitimacy, the artists note that of all the purchases made, not a single one of them turned out to be a scam.

Though [Weisskopf] and [Smoljo] aren’t worried about being persecuted for illegal activity, as Swiss law protects their right to freely express ideas publicly through art, the implications behind their exhibition did raise some questions along those lines. If your robot goes out and buys a bounty of crack on its own accord and then gives it to its owner, who is liable for having purchased the crack?

If a collection of code (we’ll loosely use the term AI here) is autonomous, acting independent of its creator’s control, should the creator still be held accountable for their creation’s intent? If the answer is ‘no’ and the AI is responsible for the repercussions, then we’re entering a time when its necessary to address AI as separate liable entities. However, if you can blame something on an AI, this suggests that it in some way has rights…

Before I get ahead of myself though, this whole notion circulates around the idea of intent. Can we assign an artificial form of life with the capacity to have intent?

Arduino Vs. Phidgets – Dev Time Trials

January 4, 2015 by Matt Freund 38 Comments

Is developing on an Arduino too slow? Are Phidgets too expensive? When might you use one or the other? Hackaday regular [Ken] breaks down what he learned from three experimental time trials.

The main development differences between Arduino and Phidgets are a mix of flavor preferences and some hard facts. The Arduino is open source, Phidgets are proprietary. Arduino requires a mix of hard- and software where Phidgets only needs (and only allows) a connection to a full computer but enables high level languages – it is expected to get the job done sooner and easier. And finally, Arduinos are cheap, Phidgets are 3-5x the cost.

The three time trials were common tasks: 1. Blink an LED. 2. Use a pot to turn a servo. 3. Build a pedometer. For [Ken], the Phidgets won in each of the three experiments, but not significantly: 37%, 45%, and 25% respectively. The difference is only minutes. Even considering time value, for most hackers it is not worth the cost.

In context, the advantages of a mildly more rapid development on the simplest projects are wasted away by needing to rebuild a permanent solution. Chained to a PC, Phidgets are only useful for temporary or fixed projects. For many of our readers that puts them dead in the water. Arduinos may technically be dev kits but are cheap enough to be disposed of in the project as the permanent solution – probably the norm for most of us.

[Ken] points out that for the software crowd that abhor electronics, Phidgets plays to their preferences. Phidgets clips together their pricey peripherals and the rest is all done in code using familiar modern languages and libraries. We wonder just how large this group could still be; Phidgets might have been an interesting kit years ago when the gulf between disciplines was broader but the trend these days is towards everyone knowing a little about everything. Hackaday readers probably represent that trend more than most, but let us know if that seems off.

[Ken]’s article has much more and much better detailed explanations of the experiments and the tradeoffs between the platforms.

If you enjoy watching parallel engineering, see the time-lapse video below for a split screen of the time trials.

Continue reading “Arduino Vs. Phidgets – Dev Time Trials” →

Upgrading DJI Flight Controllers

January 4, 2015 by Brian Benchoff 147 Comments

DJI, the company that gave us the far too popular Phantom line of quadcopters, doesn’t just make the most popular line of FPV quads. Their top of the line flight controller, The Naza V2, is very good, able to connect to flight planning software that will set waypoints, talk to peripherals over a CAN bus, and has improved flight algorithms. On the other hand, their ‘reduced price’ model, the Naza Light, can’t connect to these nifty CAN bus peripherals and has a bit of a problem with drifting the quad from one side or another.

The Naza V2 sells for around $300, and the Naza Light sells for about $170, both with a GPS module. The hardware inside the V2 and Light is exactly the same. We all know how this is going to go down, right?

[udnham] over on the RC Groups forum figured out a way to load the more capable Naza V2 firmware on the Naza Light, giving the cheaper flight controller features that were, until now, only found in the more expensive V2 hardware. The upgrades include better algorithms for GPS position and altitude hold, the ability to connect to DJI peripherals including the Bluetooth module, the iOSD, and camera gimbals, Octocopter support, the DJI datalink modem, and a bunch of other features.

Even though DJI is using the same hardware in the $170 Naza Light and the $300 Naza V2, upgrading the firmware requires an Internet connection to the DJI servers. [udnham] wrote a utility that modifies the /etc/hosts file on your computer, runs a service, and allows you to upgrade your firmware on the Naza Light. It’s basically a $130 firmware upgrade for a DJI flight controller that’s a single download away.

[udnham] set up a site where you can download the firmware flashing tool with a few videos showing the upgrade process and the improvement over the stock firmware. You can check those out below.

Continue reading “Upgrading DJI Flight Controllers” →

800 X 600 VGA With The STM32F4

January 4, 2015 by Brian Benchoff 12 Comments

Generating VGA is a perennial favorite on the Hackaday tips line, and it’s not hard to see why. Low-res video games, of course, but sending all those pixels out to a screen is actually a pretty challenging feat of coding. The best most project have attained is the original VGA standard, 640×480. Now that we have fast ARMs sitting around, we can bump that up to 800×600, like [Karl] did with an STM32F4 Discovery board.

The problem with generating VGA on a microcontroller is the pixel frequency – the speed at which pixels are shoved out of the microcontroller and onto the screen. For an 800×600 display, that’s 36 MHz; faster than what the 8-bit micros can do, but a piece of cake for the STM32F4 [Karl] is using.

[Karl] started his build by looking at the VGA project Artekit put together. It too uses an STM32, but a 36-pin F103 part. Still, it was fast enough to generate a line-doubled 800×600 display. [Karl] took this code and ported it over to the F4 part on the Discovery board that has enough space for a full 800×600 frame buffer.

With all that RAM on board the F4 part, [Karl] was able to expand the frame buffer and create a relatively high-resolution display with DMA and about a dozen lines of code. It looks great, and now we just need a proper application for high-resolution VGA displays. Retrocomputing? A high-resolution terminal emulator? Who knows, but it’s a great use for the STM32.

If circles and some text aren’t your thing, Artekit also has Space Invaders running on the 36-pin STM32.