Syndicate content Hackaday
Fresh hacks every day
ถูกปรับปรุง 1 ชั่วโมง 21 min ก่อน

Color changing clock uses PCB digits

พฤ, 12/14/2017 - 07:00

There’s an old saying, that you should do everything at least twice. Once to learn how to do it, and then a second time to do it right. Perhaps [Zweben] would agree, since he wasn’t satisfied with his first Neopixel clock and proceeded to build another one. One lesson learned: soldering 180 tiny solder joints isn’t much fun. This time, [Zweben] set out to make a printed circuit board and redesign the clock to make it easier to assemble.

The clock uses multiple copies of a single circuit board. The board holds Neopixel strips in a 7-segment arrangement. Each board can also hold all of the electronics needed to drive the clock. Only the first board gets the microcontroller and other circuits.

This allowed [Zweben] to design a single PCB which he did with EasyEDA. The hardware itself was similar enough to his original clock, that the software didn’t require changes.

Speaking of hardware, the clock is a pretty standard mashup of an Arduino Pro Mini clone and a DS3231 I2C clock. The Neopixel strips are 60-per-meter WS2812B LEDs with two LEDs per digit segment. That’s a total of 14 on each digit and 58 individually-addressable lights on the entire clock.

This reminded us of a similar clock from [decino] where he also got tired of soldering connections. We also liked the clock that used Neopixel rings instead of strips.

Filed under: clock hacks

Guitar Game Plays with Enhanced Realism

พฤ, 12/14/2017 - 04:00

There’s a lot more to learning how to play the guitar than just playing the right notes at the right time and in the right order. To produce any sound at all requires learning how to do completely different things with your hands simultaneously, unless maybe you’re a direct descendant of Eddie Van Halen and thus born to do hammer ons. There’s a bunch of other stuff that comes with the territory, like stringing the thing, tuning it, and storing it properly, all of which can be frustrating and discouraging to new players. Add in the calluses, and it’s no wonder people like Guitar Hero so much.

[Jake] and [Jonah] have found a way to bridge the gap between pushing candy colored buttons and developing fireproof calluses and enough grip strength to crush a tin can. For their final project in [Bruce Land]’s embedded microcontroller design class, they made a guitar video game and a controller that’s much closer to the experience of actually playing a guitar. Whether you’re learning to play for real or just want to have fun, the game is a good introduction to the coordination required to make more than just noise.

In an interesting departure from standard stringed instrument construction, plucking is isolated from fretting.  The player fingers notes on four strings but plucks a special, fifth string with a conductive pick that closes the plucking circuit. By contrast, the fretting strings are normally high. When pressed, they contact the foil-covered fingerboard and the circuit goes low. All five strings are made of carbon-impregnated elastic and wrapped with 30AWG copper wire.

All five strings connect to an Arduino UNO and then a laptop. The laptop sends the signal to a Bluefruit friend to change Bluetooth to UART in order to satisfy the PIC32. From there, it goes out via 2-channel DAC to a pair of PC speakers. One channel has the string tones, which are generated by Karplus-Strong. To fill out the sound, the other DAC channel carries undertones for each note, which are produced by sine tables and direct digital synthesis. There’s no cover charge; just click past the break to check it out.

If you’d like to get into playing, but don’t want to spend a lot of money to get started, don’t pass up those $30-$40 acoustics for kids, or even a $25 ukulele from a toy store. You could wind your own pickup and go electric, or add a percussive solenoid to keep the beat.

Filed under: Arduino Hacks, Microcontrollers, Musical Hacks

Extraterrestrial Autonomous Lander Systems to Touch Down on Mars

พฤ, 12/14/2017 - 02:31

The future of humans is on Mars. Between SpaceX, Boeing, NASA, and every other national space program, we’re going to Mars. With this comes a problem: flying to Mars is relatively easy, but landing a large payload on the surface of another planet is orders of magnitude more difficult. Mars, in particular, is tricky: it has just enough atmosphere that you need to design around it, but not enough where we can use only parachutes to bring several tons down to the surface. On top of this, we’ll need to land our habitats and Tesla Roadsters inside a very small landing ellipse. Landing on Mars is hard and the brightest minds are working on it.

At this year’s Hackaday Superconference, we learned how hard landing on Mars is from Ara Kourchians (you may know him as [Arko]) and Steve Collins, engineers at the Jet Propulsion Laboratory in beautiful Pasadena. For the last few years, they’ve been working on COBALT, a technology demonstrator on how to use machine vision, fancy IMUs, and a host of sensors to land autonomously on alien worlds. You can check out the video of their Supercon talk below.

There are a few methods that have been used to land on Mars over the years. The first successful landing, Viking, in 1976, simply dropped the lander off at the top of the atmosphere with the hope of not landing on top of a gigantic boulder or on the side of a cliff. Curiosity, the car-sized rover that’s been going strong for half a decade, was a little more complex. The entry vehicle had an offset mass, and as the lander was plunging through the atmosphere, the computer could roll around its center of mass, imparting a little offset to its trajectory. This is also how the Apollo modules came back from the moon, and proof you can fly a brick, provided it doesn’t have a homogenous density.

But there are Mars rovers being built right now. The Mars 2020 rover is currently being assembled, and with that new landing techniques are needed to put the rover next to interesting geological formations. For Mars 2020, this means having the lander take pictures of the landing area during its descent through the atmosphere, compare those to maps created by one of the many Mars orbiters, and have the lander figure out if it’s going to land on a pile of rocks. If the lander senses it’s going to land in a dangerous area, it can divert its landing site a few hundred meters away towards safer terrain.

COBALT — the CoOperative Blending of Autonomous Landing Technologies — is a project to improve this technology. Eventually, we’re going to want to land on even more dangerous terrain on Mars or even Europa. These are challenging environments, and we don’t even have high-resolution maps of Europa. We probably won’t have high-resolution maps of Europa until we try to land there.

The COBALT payload package

To manage this, COBALT is a payload package loaded up with LIDAR, cameras, IMUs, and a beefy computer providing real-time sensing for where a rocket will land. The COBALT team actually got a chance to test their payload out last spring in the Mojave aboard a Masten Xodiac rocket. This rocket shot upward, turned down its engine, then moved off to the side and landed on a pad a few hundred meters downrange.

This test was a complete success. You can check out a few videos of the test from the Armstrong Flight Research Center in the Mojave where the rocket goes up, figures out where it is, and directs the engine to a precise landing point.

There will be a lot of ways we’re going to land on Mars. SpaceX is going all-in with lifting bodies and offset centers of mass. Boeing will probably go Thrust or Bust. Who knows what China and India will do. We will eventually get there, though, and when it comes to worlds other than Mars or the moon, this is probably what we’ll be using.

Filed under: Hackaday Columns

Statistics and Hacking: A Stout Little Distribution

พฤ, 12/14/2017 - 01:01

Previously, we discussed how to apply the most basic hypothesis test: the z-test. It requires a relatively large sample size, and might be appreciated less by hackers searching for truth on a tight budget of time and money.

As an alternative, we briefly mentioned the t-test. The basic procedure still applies: form hypotheses, sample data, check your assumptions, and perform the test. This time though, we’ll run the test with real data from IoT sensors, and programmatically rather than by hand.

The most important difference between the z-test and the t-test is that the t-test uses a different probability distribution. It is called the ‘t-distribution’, and is similar in principle to the normal distribution used by the z-test, but was developed by studying the properties of small sample sizes. The precise shape of the distribution depends on your sample size.

The t distribution with different sample sizes, compared to the normal distribution (Hackaday yellow). Source: Wikipedia

In our previous example, we only dealt with the situation where we want to compare a sample with a constant value – whether a batch of resistors were the value they were supposed to be. In fact there are three common situations:

  1. You want to compare a sample to a fixed value: One sample t-test
  2. You want to compare two independent samples: Two sample t-test
  3. You have two measurements taken from each sample (e.g. treatment and control) and are interested in the difference: Paired t-test

The difference mainly affects how you might set up your experiment, although if you have two independent samples, there is some extra work involved if you have different sample sizes or one sample varies more than the other. In those cases you’re probably better off using a slight variation on the t-test called Welsh’s t-test.

In our case, we are comparing the temperature and humidity readings of two different sensors over time, so we can pair our data as long as the sensors are read at more or less the same time. Our null and alternate hypotheses are straightforward here: the sensors either don’t produce significantly different results, or they do.

The two DHT11 sensors were taped down to my desk. They were read with a NodeMCU and the data pushed to a ThingsBoard server.

Next, we can sample. The readings from both sensors were taken at essentially the same time every 10 seconds, and sent via MQTT to a Thingsboard server. After a couple of days, the average temperature recorded by each sensor over 10 minute periods was retrieved. The sensor doesn’t have great resolution (1 °C), so averaging the data out like this made it less granular. The way to do this is sort of neat in ThingsBoard.

First you set up an access token:

$curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"username":"yourusername", "password":"yourpassword"}' 'http://host.com:port/api/auth/login'

Then you request all data for a particular variable, averaged out every 10 minutes in JSON format (timestamps will be included):

$curl -v -X GET "http://host.com:port/api/plugins/telemetry/DEVICE/devicekey/values/timeseries?keys=variablename&startTs=1510917862000&endTs=1510983920000&interval=600000&limit=10000&agg=AVG" \ --header "Content-Type:application/json" \ --header "X-Authorization:Bearer (token goes here)" > result.txt

What’s cool about using an API like this is that you can easily automate data management and testing as parts of a decision engine. If you’re using less accurate sensors, or are just measuring something that varies a lot, using statistical significance as the basis to make a decision instead of a single sensor value can really improve reliability. But I digress, back to our data!

Next, I did a little data management: the JSON was converted to a CSV format, and the column titles removed (timestamp and temperature). That made it easier for me to process in Python. The t-test assumes normally distributed data just like the z-test does, so I loaded the data from the CSV file into a list and ran the test:

import scipy.stats as stats import csv import math as math import numpy as numpy #Set up lists tempsensor1=[] tempsensor2=[] #Import data from a file in the same folder with open('temperature1.csv', 'rb') as csvfile: datareader = csv.reader(csvfile, delimiter=',', quotechar='|') for row in datareader: tempsensor1.append(float(row[1])) with open('temperature2.csv', 'rb') as csvfile: datareader = csv.reader(csvfile, delimiter=',', quotechar='|') for row in datareader: tempsensor2.append(float(row[1])) #Subtract one list from the other difference=[(i -j) for i, j in zip(tempsensor1, tempsensor2)] #Test for normality and output result normality = stats.normaltest(difference) print "Temperature difference normality test" print normality

In this case the normality test came back p>0.05, so we’ll consider the data normal for the purposes of our t-test. We then run our t-test on the data with the below. Note that the test is labeled ‘ttest_1samp’ in the statistics package – this is because running a 1-sample t-test on the difference between two datasets is equivalent to running a paired t-test on two datasets. We had already subtracted one list of data from the other for the normality test above, and now we’re checking if the result is significantly different from zero.

ttest = stats.ttest_1samp(difference, 0, axis=0) mean=numpy.mean(difference) print "Temperature difference t-test" print ttest print mean

The test returns a t-test statistic of -8.42, and a p-value of 1.53×10-13, which is much less than our threshold of p=0.05. The average difference was -0.364 °C. What that means is that the two sensors are producing significantly different results, and we have a ballpark figure for what the difference should be at a temperature of around 30 °C. Extrapolating that result to very different temperatures is not valid, since our data only covered a small range (29-32 °C).

I also ran the above test on humidity data, but the results aren’t interesting because according to the datasheet (PDF warning), the relative humidity calculation depends on the temperature, and we already know the two devices are measuring significantly different temperatures. One interesting point was that the data was not normally distributed – so what to do?

A commonly used technique is just to logarithmically transform the data without further consideration and see if that makes it normally distributed. A logarithmic transformation has the effect of bringing outlying values towards the average:

difference=[(math.log1p(i) - math.log1p(j)) for i, j in zip(humidity1, humidity2)] normality = stats.normaltest(difference) print "Humidity difference (log-transformed) normality test" print normality

In our case, this did in fact make the data sufficiently normally distributed to run a test. However, it’s not a very rigorous approach for two reasons. First, it complicates exactly what you are comparing (what is the meaningful result if I compare the logarithm of temperature values?). Secondly, it’s easy to just throw various transformations at data to cover up the fundamental fact that your data is simply not appropriate for the test you’re trying to run. For more details, this paper points out some of the problems that can arise.

A more rigorous approach that is increasing in popularity (just my opinion on both counts), is the use of non-parametric tests. These tests don’t assume a particular data distribution. A non-parametric equivalent to the paired t-test is the Wilcoxon signed-rank test (for unpaired data use the Wilcoxon rank-sum test). It has less statistical power than a paired t-test, and it discards any datum where the difference between pairs is zero, so there can be significant data loss when dealing with very granular data. You also need more samples to run it: twenty is a reasonable minimum. In any case, our data was sufficient, and running the test in Python was simple:

import scipy.stats as stats list1=[data__list_goes_here] list2=[data__list_goes_here] difference=[(i -j) for i, j in zip(list1, list2)] result=stats.wilcoxon(difference, y=None, zero_method='wilcox', correction=False) print result

When we ran it, the measured humidity difference was significant, with an average difference of 4.19%.

You might ask what the practical value of all this work is. This may just have been test data, but imagine I had two of these sensors, one outside my house and one inside. To save on air conditioning, a window fan turns on every time the temperature outside is cooler than the temperature inside. If I assumed the two devices were exactly the same, then my system would sometimes measure a temperature difference when there is none. By characterizing the difference between my two sensors, I can reduce the number of times the system makes the wrong decision, in short making my smart devices smarter without using more expensive parts.

As a side note, it has been overstated that it’s easy to lie with statistics. To borrow an idea from Andrejs Dunkels, the real issue is that it’s hard to tell the truth without them.

Filed under: hardware, how-to

The Tiniest Of 555 Pianos

พุธ, 12/13/2017 - 23:30

The 555 timer is one of that special club of integrated circuits that has achieved silicon immortality. Despite its advanced age and having had its functionality replicated and superceded in almost every way, it remains in production and is still extremely popular because it’s simply so useful. If you are of A Certain Age a 555 might well have been the first integrated circuit you touched, and in turn there is a very good chance that your project with it would have been a simple electric organ.

If you’d like to relive that project, perhaps [Alexander Ryzhkov] has the answer with his 555 piano. It’s an entry in our coin cell challenge, and thus uses a CMOS low voltage 555 rather than the power-hungry original, but it’s every bit the classic 555 oscillator with a switchable resistor ladder you know and love.

Physically the piano is a tiny PCB with surface-mount components and physical buttons rather than the stylus organs of yore, but as you can see in the video below the break it remains playable. We said it was tiny, but some might also use tinny.

We could take you to any of a huge number of 555 projects that have graced these pages over the years. But since this is a musical instrument, maybe it’s better to suggest you accompany it on a sawtooth synth, or perhaps a flute.

Coin Cell Challenge   Build something cool powered
by a coin cell, win prizes!
Filed under: Musical Hacks

Accident Forgiveness Comes to GPLv2

พุธ, 12/13/2017 - 22:01

Years ago, while the GPLv3 was still being drafted, I got a chance to attend a presentation by Richard Stallman. He did his whole routine as St IGNUcius, and then at the end said he would be answering questions in a separate room off to the side. While the more causal nerds shuffled out of the presentation room, I went along with a small group of free software aficionados that followed our patron saint into the inner sanctum.

When my turn came to address the free software maestro, I asked what advantages the GPLv3 would have to a lowly hacker like myself? I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. Was there something in the new version of the GPL that would make it worth adopting in personal or hobby projects?

Yes, he really dresses up like this.

Interestingly, a few years after this a GPLv2 program of mine was picked up by a manufacturer and included in one of their products (never underestimate yourself, folks). So the Tivoization clause was actually something that did apply to me in the end, but that’s not the point of this story.

Mr. Stallman responded that he believed the biggest improvement GPLv3 made over v2 for the hobbyist programmer was the idea of “forgiveness” in terms of licensing compliance. Rather than take a hard line approach like the existing version of the GPL, the new version would have grace periods for license compliance. In this way, legitimate mistakes or misunderstandings of the requirements of the GPL could be resolved more easily.

So when I read the recent announcement from Red Hat that said they would be honoring the grace period for GPLv2 projects, I was immediately interested. Will the rest of the community follow Red Hat’s lead? Will this change anyone’s mind when deciding between the GPL v2 and v3? Is this even a good idea? Join me below as I walk through these questions.

Defining Forgiveness

The title of the Red Hat announcement is “Providing a Fair Chance to Correct Mistakes”, which is basically the perfect way to summarize the grace period added to the GPLv3. But for our purposes, let’s take a look at the full text, taken from the “Termination” clause of the GPLv3:

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

OK, so what does that mean?

Basically, the first paragraph is saying that if you distribute a GPLv3 covered work and violate any of the license terms, you forfeit your license and therefore the right to distribute the work. Under the GPLv2, this would have been the end of the road. You broke the license, now deal with it.

But the next paragraphs give you a way back. It says that if you stop violating the license, and the upstream license holder (generally speaking, the original developer) doesn’t want to push the issue, your rights are reinstated. Further, if you fix your license violation in a timely manner (30 days) after the original developer notifies you, and assuming you aren’t a repeat offender, then you’re also in the clear.

It’s important to note that this clause protects you whether or not the license holder contacts you about the violation. If you realize on your own that you messed up and fix it, you’re covered. If they do contact you, you just need to fix the issue within a reasonable amount of time.


This may not seem like that big of a deal at first. After all, how hard is it to follow the terms of the license, right? Well, if we were talking about something simple like the 3-Clause BSD license, then no problem. But the GPL is a considerably more wordy license than others, and also asks more of the user.

Did you include a full copy of the license with the program? Does each source code file in the program contain a header that says it’s licensed under the GPL? Did you make sure all of the files modified from the upstream version contained dated comments that highlight the changes you made? If you’re distributing only a binary, did you make sure the source is hosted somewhere that the user can reasonably find it?

These are just a handful of the requirements contained in the ~2,500 word GPLv2. It’s easy to see how somebody who is not well versed in the license could easily skip some of the more esoteric requirements, especially in the click-and-fork era of GitHub. Any one of these infractions could (at least in theory) lead to forfeiture of your rights as granted by the license.

But with the clauses added to the GPLv3, these problems can be solved with a simple email or Tweet. Notify the developer who made a mistake, give them 30 days to fix it, and the problem goes away. It’s a much friendlier way of handling licensing mistakes, made possible in part by the ease of communication we now enjoy; a situation which could hardly be imagined 30 years ago when the GPLv2 was being written.

Will Everyone Get Onboard?

The new mechanisms for handling licensing issues introduced in the GPLv3 are a benefit for developers and take some of the stress out of using the GPL, and retroactively honoring them for older versions of the GPL is no doubt a great thing for the community. But will it stick?

Google, IBM, and Facebook have announced they will join Red Hat in honoring the grace period for GPLv2 covered works, and even Linux kernel developers are adopting a similar approach, but that still leaves a whole lot of companies and developers who aren’t obligated to do anything outside of what the license says. With luck, more and more companies will adopt this attitude towards supporting the GPLv2, and in time perhaps even individual developers will; but surely not all of them.

That said, the situation becomes murky when you have certain subsets of the community following the spirit of the law, and others following the letter of the law. Allowing a few heavy hitters in the industry to essentially add terms to an existing license (even if they have the best of intentions) could be seen as a slippery slope.

In the end, if you like the clauses added in the latest version of the GPL, then you should probably just use the latest version of the GPL, rather than relying on industry to pick and chose which parts they will or won’t honor. But if you can’t, or won’t, then at least there’s a chance you’ll get a pass; depending on who you deal with.

Filed under: Business, Current Events, Featured, Original Art, Slider, Software Development

Bluetooth Gun Safe Cracked By Researchers

พุธ, 12/13/2017 - 19:00

Believe it or not, there are quite a few people out there who have purchased gun safes that can be remotely unlocked by Bluetooth. Now we can understand why somebody might think this was a good idea: the convenience of being able to hit a button on your phone and have your weapon available in the heat of the moment is arguably a big selling point for people who are purchasing something like this for home defense. But those with a more technical mind will likely wonder if the inherent risks of having your firearm (or other valuables) protected by a protocol that often relies on security by obscurity outweighs the convenience of not needing to enter in a combination on the keypad.

Well, you can wonder no more, as researchers at [Two Six Labs] have recently published a detailed document on how they managed to remotely unlock the Vaultek VT20i with nothing more exotic than an Ubertooth. In the end, even the Ubertooth wasn’t actually required, as this particular device turned out to be riddled with security issues.

[Two Six Labs] has not publicly released the complete source code of the software demonstrated in their YouTube video for very obvious reasons, but the page on their site does go into fantastic detail on how they uncovered the multiple vulnerabilities that allowed them to write it. Even if you’re not the kind of person who would ever need a gun safe, the information contained in their documentation about analyzing Bluetooth communications is fascinating reading.

It was discovered that the PIN for the safe was actually being transmitted by the accompanying smartphone application in plain-text, which would be bad enough normally. But after further analysis, it became clear that the safe wasn’t even bothering to check the PIN code anyway.

Scripting app interactions with ADB and Python

For extra style points, [Two Six Labs] also show a way to brute force the PIN using the Vaultek Android application by writing a Python script that punches in codes sequentially until it hits on the right one; the developers didn’t even bother to put in limits on failed attempts.

For a device that is ostensibly designed to contain a deadly weapon, the security flaws the team at [Two Six Labs] discovered are absolutely inexcusable. But there is a positive outcome, as the manufacturer has vowed to update the vulnerable safes and make a better effort in the future to more rigorously design and test their Bluetooth implementation. This is the goal of responsible disclosure, and we’re encouraged to see the manufacturer doing the right thing

The security concerns of Bluetooth controlled locks are well known, so it’s a bit disappointing that devices like this are still slipping through the cracks. We suggest you remain skeptical of any security device utilizing Bluetooth until the industry starts taking things a little more seriously.

Filed under: News, Security Hacks, Wireless Hacks

Generate Random Numbers The Hard Way

พุธ, 12/13/2017 - 16:00

Your job is to create a random number generator.

Your device starts with a speaker and a membrane. On this membrane will sit a handful of small, marble-size copper balls. An audio source feeds the speaker and causes the balls to bounce to and fro. If a ball bounces high enough, it will gain the opportunity to travel down one of seven copper tubes. Optical sensors in each of the tubes detect the ball and feed data to an Ardunio Mega. When the ball reaches the end of the tube, a robotic hand will take the ball and put it back on the speaker membrane. The magic happens when we write an algorithm such that the audio output for the speaker is a function of how many balls fall down the pipes.

The above is a rough description of [::vtol::]’s art piece: kinetic random number generator. We’re pretty sure that there are easier ways to get some non-determinstic bits, but there may be none more fun to watch.

[::vtol::] is a frequent flyer here on Hackaday Airlines. Where else would you showcase your 8-bit Game Boy Photo Gun or your brainwave-activated ferrofluid monster bath? Would it shock you to find out that we’ve even covered another kinetic random number generator of his?  Fun stuff!

Filed under: Arduino Hacks

It’s Curtains for Blu Chip

พุธ, 12/13/2017 - 13:00

In theory, there is no reason you can’t automate things all over your house. However — unless you live alone — you need to consider that most people won’t accept your kludgy looking circuits on a breadboard hanging everywhere. Lighting has become easy now that there are a lot of commercial options. However, there are still plenty of things that cry for automation. For [jeevanAnga], the curtains were crying out for remote control.

Since cellphones are ubiquitous, it makes sense to use the phone as a controller and BlueTooth Low Energy (BLE) is perfect for this kind of application. But you can’t hang a big ugly mess of wires off the curtain rods. That’s why [jeevanAnga] used a tiny (16.6 x 11.5 mm) BLE board knows as a BluChip.

We didn’t verify it, but [jeevanAnga] claims it is the smallest BLE board available, and it is certainly tiny. You can see the result in the video below.

Of course, the BluChip only talks to the phone. A stepper motor does the hard work with the help of a belt, a pulley, and gears. The BluChip also requires a separate programmer and that’s not so tiny, but of course, you only need it while you configure the device.

Inside, the BluChip is an ARM processor (Cortex M0 with 256K of flash and 32K of RAM). It works on 1.8 to 3.6 volts and is FCC certified, so you could easily use it in a commercial product. Most of the useful signals are brought out to pins on 0.1 inch centers, which is handy.

You still need a bit of supporting hardware (like a stepper driver) so the challenge is to make the device attractive enough to reside in the living room. The good news is that you can sneak that tiny BLE board almost anywhere.

If you want a primer on BLE, you can read up on the basics. We’ve also seen non-BLE boards hacked to work with the protocol.

Filed under: ARM, Cellphone Hacks

Connecting Cherry MX Key Switches To LEGO Just Got Easier

พุธ, 12/13/2017 - 10:00
The Cherry MX Blue keyswitch

Here on Hackaday, we like keyboard hacks. Given how much time we all spend pounding away on them, they’re natural hacks to come up with. If you’re pulling the circuitry from an existing keyboard then chances are the keys are pressed either by pushing down on rubber domes (AKA the membrane type), or on mechanical switches. [Jason Allemann] has just made it easier to do keyboard hacks using LEGO by building one for a circuit board with mechanical Cherry MX key switches. That involved designing parts to connect LEGO bricks to the switches.

For those custom parts, he recruited his brother [Roman], who’s a mechanical engineer. [Roman] designed keycaps with a Cherry MX stem on one side for snapping onto the key switches, and LEGO studs on the other side for attaching the LEGO bricks. The pieces also have a hole in them for any keys which have LEDs. Of the 100 which [Jason] ordered from Shapeways, around ten were a bit of a loose fit for the LEGO bricks, but only if you were doing extreme button mashing would they come off.

The easy part was the keyboard circuit board itself, which he simply removed from an old Cooler Master Quick Fire Rapid keyboard and inserted into his own LEGO keyboard base.

LEGO mechanical keyboard

We do like his creative use of bricks for the keys. For one thing, the letter keys have no letters on them and so is for toufh-typosts touch-typists only. The Caps Lock is a baseball cap, which would be awkward to press except that no one ever does anyway. ESC is a picture of a person running from a dinosaur and F1, which is often the help-key, is the Star of Life symbol for medical emergency services such as ambulances. Scroll Lock is, of course, a scroll. And to make himself type faster, he incorporated blue racing stripes into the frame, but you can judge for yourself whether or not that trick actually works by watching his detailed build-video below.

If you want to learn all about the subtleties of key switch technology, check out our recent write-up of a talk about mechanical keyboards given at the 2017 Hackaday Superconference. Then, to complete your skillset, check out our very own [Brian Benchoff]’s guide for building rubber dome keyboards.

Filed under: Peripherals Hacks

Car Lights for Reflow Heat Source

พุธ, 12/13/2017 - 07:00

If you only have a car and you need to unsolder some tricky surface mount components: what would you do? If you’re Kasyan TV, you’d remove your car’s halogen lights and get to town. That’s right: car lights for reflow.

When the friend of the host of Kasyan TV needed to remove some roasted toasted FETs from his motherboard but didn’t have anything for reflowing, she took some headlights and used them as an infrared source to desolder the FETs. Powered by a lab supply (although car batteries work too), the process works with 60 and 100-watt bulbs.

Now, reflowing with halogen bulbs isn’t new, and we’ve seen it done with the run of the mill 100-watt bulbs and a halogen floodlight. However, what we really like about using car lights is that they’re available everywhere and we already own some that we could (temporarily) repurpose. Now, don’t get us wrong – if you’re going to be reflowing more than just a little, there are plenty of alternative methods that don’t involve staring at “rather bright lights” for extended periods of time.

People ’round these parts can’t seem to get enough of reflow: from open source reflow oven controllers to reflowing with a hair straightener we’ve seen quite a bit. If you’re new to the reflow arena, we’ve got zero to hero: reflow style just for you. And if DIY at home reflow isn’t intense enough for you, we’ve got next level reflowing as well.

The full video is after the break, complete with Kasyan TV’s sponsored segment in the middle..

Filed under: hardware, how-to

Old TV Lends Case to Retro Magic Mirror

พุธ, 12/13/2017 - 04:00

Remember the days when the television was the most important appliance in the house? On at dawn for the morning news and weather, and off when Johnny Carson said goodnight, it was the indispensable portal to the larger world. Broadcast TV may have relinquished its hold on the public mind in favor of smartphones, but an information portal built into an old TV might take you back to the old days.

It seems like [MisterM] has a little bit of a thing for the retro look. Witness the wallpaper in the video after the break for proof, as well as his Google-ized Radio Shack intercom project from a few months back. His current project should fit right in, based on an 8″ black-and-white TV from the 70s as it is. TVs were bulky back then to allow for the long neck of the CRT, so he decided to lop off the majority of the case and use just the bezel for his build. An 8″ Pimoroni display sits where the old tube once lived, and replicates the original 4:3 aspect ratio. With Chromium set up in kiosk mode, the family can quickly select from a variety of news and information “channels” using the original tuning knob, while parts from a salvaged mouse turns the volume control into a scroll wheel.

It’s a nice twist on the magic mirror concept, and a little different from the other retro-TV projects we’ve seen, like a retro gaming console or an old-time case for a smart TV.

Filed under: classic hacks, Raspberry Pi

Christal Gordon: Sensors, Fusion, and Neurobiology

พุธ, 12/13/2017 - 02:31

Some things don’t sound like they should go together, but they do. Peanut butter and chocolate. Twinkies and deep frying. Bacon and maple syrup. Sometimes mixing things up can produce great results. [Dr. Christal Gordon’s] expertise falls into that category. She’s an electrical engineer, but she also studies neuroscience. This can lead to some interesting intellectual Reese’s peanut butter cups.

At the 2017 Hackaday Superconference, [Christal] spoke about sensor fusion. If you’ve done systems that have multiple sensors, you’ve probably run into that before even if you didn’t call it that. However, [Christal] brings the perspective of how biological systems fuse sensor data contrasted to how electronic systems perform similar tasks. You can see a video replay of her talk in the video below.

The precise definition of sensor fusion is taking data from multiple sensors to reduce uncertainty about measurements. For example, an autonomous car might want to measure its position relative to other objects to navigate and avoid collisions. GPS will give you a pretty good idea of where you are. However, you can better understand your position within the uncertainty of GPS using inertial methods although they tend to accumulate errors over larger time periods. By using both sources of data, it is possible to get a better idea of position than trying to use either one individually.

Another source of data might be a LIDAR or ultrasonic range finder. Fusion correlates all this data to develop a better operating picture of the environment. Navigation isn’t the only application, of course. [Christal] mentions several others, including fusing data to allow robotic legs to run on a treadmill.

One very important sensor fusion tool that [Christal] mentions is the Kalman filter. This algorithm takes multiple noisy sensor inputs with varying degrees of certainty and arrives at an estimate of the value that is more precise than the sensor inputs alone.

It makes sense that we would look to biological systems for inspiration for sensor fusion. After all, the best fusing system we know of is the human brain. Your brain processes data from a dizzying array of sensors and allows you to make sense of your world. It isn’t perfect, but it does work pretty well most of the time. Think about the navigation ability of, say, a migratory bird. Now think about the size and weight of that bird. Then realize the bird is self-fueling and can — with a little help — produce more birds. Pretty amazing. Our robots are lucky if they can navigate that well and they probably don’t refuel and rebuild plus they probably are much bigger and heavier.

There’s only so much you can cover in 40 minutes, but [Christal] will make you think about how our systems resemble biological systems and the ways we can combine data from multiple sources to get better sensor data in machines.

One of the great things about Superconference is being exposed to new ideas from people who have very different perspectives. [Christal’s] talk is a great example, and thanks to the magic of the Internet, you can watch it in your own living room.

Filed under: Engineering

Maria Mitchell: The First Woman Astronomy Professor

พุธ, 12/13/2017 - 01:01

On an October night in 1847, a telescope on the roof of the Pacific National Bank building on Nantucket Island was trained onto the deep black sky. At the eyepiece was an accomplished amateur astronomer on the verge of a major discovery — a new comet, one not recorded in any almanac. The comet, which we today know by the dry designator C/1847 T1, is more popularly known as “Miss Mitchell’s Comet,” named after its discoverer, a 29-year old woman named Maria Mitchell. The discovery of the comet would, after a fashion, secure her reputation as a scholar and a scientist, but it was hardly her first success, and it wouldn’t be her last by a long shot.

Maria Mitchell. Source: The Nantucket Atheneum

To say that Maria Mitchell’s life did not follow the typical path of a 19th-century woman’s life is something of an understatement. Nantucket Island was still decades away from the brief burst of prosperity it would find in the rise of the whaling trade when Maria — she pronounced her name with a long “I” sound — was born in 1818. Her parents were Quakers and much involved in Maria’s education, at a time when girls were not necessarily afforded the same opportunities as boys.

It was Maria’s father who would turn her eyes to the skies and serve as her mentor. William Mitchell was an educator, being principal of Maria’s grammar school and later starting his own school. He also had a keen interest in surveying and, suitably enough for life on a seafaring island, navigation and astronomy. William taught Maria how to use navigation instruments, with which she made observations and calculations. By the time she was 14, Maria’s navigational calculations were in demand by the island’s sailors as they set out on their journeys.

At the end of her formal education in 1836, Maria became the librarian of the brand new Nantucket Atheneum. A mix of library and museum, the Atheneum was to be a cultural and intellectual institution, and Maria would remain there for twenty years. With her father, she continued her studies of the heavens, with bigger and better instruments.

Miss Mitchell’s Comet

Maria’s comet discovery in 1847 was not without controversy. In 1832, Danish king Frederick VI established a gold medal prize for anyone who discovered a comet using a telescope. Maria was not alone in observing the comet that would bear her name. On October 3, 1847, Italian astronomer and Jesuit priest Francesco de Vico observed the same comet, quickly wrote up his findings, and posted them to the award committee. Being closer, news of the discovery reached Denmark sooner, and de Vico was awarded the medal. However, Maria had made her observations on October 1, and when the news eventually reached Europe, the prize was awarded to her.

“Miss Mitchell’s Comet” earned Maria a degree of international fame, and while she hated the attention, it provided her with opportunities. After resigning from the Atheneum, Maria traveled around the world, making observations at the Vatican Observatory and conducting several expeditions to study eclipses. As Maria’s reputation grew, she began to accumulate honors — in 1848, she was the first woman to be elected to the American Academy of Arts and Sciences, and two years later to the American Association for the Advancement of Science.

Founder and Pioneer Maria Mitchell (standing 3rd from right) and her first astronomy class at Vassar. Source: Vassar College

In 1865, Maria, who never married, moved to Poughkeepsie, New York to the campus of the newly founded Vassar College, the first degree-granting college for women in the United States. Maria would become the first faculty member hired, and along with her widowed father, she lived in the observatory that was built to her specifications to house the second largest telescope in the country at the time.

Her students were expected to do original research in the observatory and in the field, a novelty at the time for students at men’s colleges and unheard of for women students. She traveled with her students to Iowa in 1869 to observe a total solar eclipse, and again to 1878 for another eclipse in Colorado. Such trips were difficult and dangerous in those days, and the sight of a group of women lugging scientific instruments into a frontier town in the midst of a gold rush must have been something to see.

Maria continued teaching and making observations right up until she retired in 1888 due to poor health; she would die a year later at the age of 70. Her contributions to astronomy are many; along with her comet discovery and her eclipse observations, she and her students built an apparatus for making solar photographs and made important observations about sunspots. But perhaps her most important contribution was as an educator and a mentor to her students, just as her father mentored her.

Filed under: Featured

How Mini Can A Mini Lamp Be?

อังคาร, 12/12/2017 - 23:30

If there is one constant in the world of making things at the bench, it is that there is never enough light. With halogen lamps, LEDs, fluorescent tubes, and more, there will still be moments when the odd tiny part slips from view in the gloom.

It’s fair to say that [OddDavis]’ articulated mini lamp will not provide all the solutions to your inadequate lighting woes, as its lighting element is a rather humble example of a white LED and not the retina-searing chip you might expect. The lamp is, after all, an entry in our coin cell challenge, so it hardly has a huge power source to depend upon.

What makes this lamp build neat is its 3D-printed articulated chassis. It won’t replace your treasured Anglepoise just yet, but it might make an acceptable alternative to that cheap IKEA desk lamp. With the coin cell LED you’d be hard pressed to use it for much more than reading even with its aluminium foil reflector, but given a more substantial lighting element it could also become a handy work light.

If 3D printed articulated lamps are your thing, take a look at this rather more sophisticated example.

Coin Cell Challenge   Build something cool powered
by a coin cell, win prizes!
Filed under: 3d Printer hacks

Living On The Moon: The Challenges

อังคาร, 12/12/2017 - 22:01

Invariably when we write about living on Mars, some ask why not go to the Moon instead? It’s much closer and has a generous selection of minerals. But its lack of an atmosphere adds to or exacerbates the problems we’d experience on Mars. Here, therefore, is a fun thought experiment about that age-old dream of living on the Moon.

Inhabiting Lava Tubes Lava tube with collapsed pits near Gruithuisen crater

The Moon has even less radiation protection than Mars, having practically no atmosphere. The lack of atmosphere also means that more micrometeorites make it to ground level. One way to handle these issues is to bury structures under meters of lunar regolith — loose soil. Another is to build the structures in lava tubes.

A lava tube is a tunnel created by lava. As the lava flows, the outer crust cools, forming a tube for more lava to flow through. After the lava has been exhausted, a tunnel is left behind. Visual evidence on the Moon can be a long bulge, sometimes punctuated by holes where the roof has collapsed, as is shown here of a lava tube northwest from Gruithuisen crater. If the tube is far enough underground, there may be no visible bulge, just a large circular hole in the ground. Some tubes are known to be more than 300 meters (980 feet) in diameter.

Lava tubes as much as 40 meters (130 feet) underground can also provide thermal stability with a temperature of around -20°C (-4°F). Having this stable, relatively warm temperature makes building structures and equipment easier. A single lunar day is on average 29.5 Earth days long, meaning that we’ll get around 2 weeks with sunlight followed by 2 weeks without. During those times the average temperatures on the surface at the equator range from 106°C (224°F) to -183°C (-298°F), which makes it difficult to find materials to withstand that range for those lengths of time.

But living underground introduces problems too.


One problem with living underground is that makes it difficult to communicate from one location to another, perhaps even between different lava tubes. To overcome this, cables could be run through the tubes and antennas could be located on the surface.

Lava tubes are often found on the boundaries between the highlands and the mares. Lunar mares are the uniform dark areas visible from Earth with the naked eye, mare being Latin for “sea”. The antennas could be located high up in those highlands. Ideally, there would always be at least one communications satellite within communications range and a network of them for transmitting anywhere on the Moon.

Electrical Ground And Charged Dust

The moisture in Earth soil aids conductivity by helping ions move around, making for a good electrical ground. Lunar soil, however, is dry and therefore is a poor electrical ground. Connecting structures together with cables can at least bring those structure to a common potential, creating a sort of ground.

Schmitt’s dusty suit while retrieving samples

But a bigger problem than that is moon dust. Apollo astronauts found that the dust clung to everything and they brought it with them into the lander. Harrison “Jack” Schmitt of Apollo 17, reacted to it strongly, saying that it caused his turbinates (long, narrow bone in the nose) to swell, though the effect diminished after a few hours. Even the vacuum cleaner they used to clean up the dust became clogged.

This dust also becomes charged by solar storms, only to then be discharged when solar radiation knocks the extra electrons off, but that discharging doesn’t happen during the long nights. Inferring from data collected by the Lunar Prospector during orbits in 1998-1999, charging also happens when the Moon passes through the Earth’s magnetic wake created by the solar wind. This happens in 18-year cycles and is currently at its peak.

With the Earth’s and Mars’ atmospheres, built up charge can be bled off to the atmosphere using sharp metal points which ionize the surrounding air. On the Moon, that approach is far less effective. Using all dwellings as a ground at least provides a large capacitor to take up stray charge. If you know of a good solution to this problem, we’d like to hear it.

Producing Oxygen From Soil

We’ll of course need oxygen to breathe and one source is the lunar soil. The process usually involves reacting certain oxygen-bearing minerals with hydrogen while heating to around 1000°C. Much work has been done with the mineral ilmenite (FeTiO3), making the process:

FeTiO3 + H2 + heat -> Fe + TiO2 + H2O Where to live and mine

This gives us water vapor which would be separated from the other components. We could then use the water as is, or we could use electrolysis to split apart the hydrogen and oxygen. We’d condense the oxygen for storage, and recycle the hydrogen back into the process. Hydrogen is scarce on the Moon and so the hydrogen could initially be shipped from Earth and then continuously recycled.

This ilmenite is abundant on the Moon, first having been found in moon rocks returned by the Apollo astronauts, and then other locations have been inferred by the Hubble Space Telescope, one such being in the area of Aristarchus crater. Luckily that’s also near the lava tubes with collapsed pits which we’d mentioned above near Gruithuisen crater. However, for abundant water, we’ll need to look to the north and south poles.

Water From The Poles South pole

The evidence is very strong that there’s a mix of hydroxyl (OH) and water (H2O) on the Moon’s surface. The theories are that it comes from comets impacting on the Moon and from hydrogen ions created when the solar wind interacts with oxygen in the soil.

But for most of the Moon, solar radiation would then free the hydrogen and oxygen atoms from their molecules and they would escape to space. However, the lunar poles have areas which are in perpetual shadow, forever free of the hydrogen-liberating solar radiation. After decades of spacecraft probing these regions, the evidence for water and hydroxyls there is very strong, though the quantity of it is still uncertain.

This means that a good location for a lunar mining outpost would be in sunlit areas adjacent to these areas of perpetual shadow. There are even some such locations around the poles that are high enough to be in perpetual sunlight. And that perpetual sunlight is ideal for generating electricity using solar panels which we could manufacture on the Moon from mined minerals.

Mining And Manufacturing Polaris lunar mining test vehicle via Astrobotics

The Moon is lacking in volatile chemicals, ones that have a low boiling point, having negligible amounts of hydrogen, nitrogen, and carbon. But it is rich in many other chemicals and minerals. Mining them is important for two reasons: for building the things we need and for exporting to the other off-Earth colonies either in raw form or in manufactured products.

We’ve already mentioned using ilmenite (FeTiO3) to produce oxygen, but the byproducts of that are iron (Fe) and titanium (Ti), both of which can be used for the construction of living spaces, vehicles and other rigid objects.

Examining a table of Earth and lunar crustal composition, you’ll see that the Moon contains an abundance of useful minerals.

Earth and lunar crustal compositions from LRU for Space Construction – 1979

The silicon can be used for producing solar cells along with phosphorus and boron for the dopants. The study that produced the table doesn’t include boron, but other studies have found it in Moon rock, albeit in the 25 PPM and lower range and so it may have to be imported.

Helium 3 distribution via Lunar Networks

Helium 3 is another valuable substance that can be mined on the Moon. The Chinese Chang-E1 lunar satellite estimated the amount in lunar regolith as 660 billion kg. It’s hoped that it can be used for future fusion reactors due to that fusion producing no radiation and more energy than other fusion reactions. However, it also requires a higher temperature. Just 6,700 kg would be required to power the US for one year. Luckily helium 3 is in abundance in the same area where we’ll be mining ilmenite.

Generating Electricity

We’ve already mentioned that there are areas around the poles that are in perpetual sunlight. So during the long nights, solar power farms in those areas could generate electricity as a product to sell throughout the Moon.

Geothermal energy isn’t an option for the Moon, at least not for the colonies’ early days as you’d have to drill down around 45 km (28 miles) before the temperature reaches the boiling point of water. Geothermal energy has been used to generate electricity in Chena Hot Springs, Alaska with only 57°C (135°F) but that’s still around 20 km (12.5 miles) deep.

If helium 3 fusion is ever made to work then it could be used to provide electricity through the long lunar night when the local solar farms are down. And it might have to, because uranium is in short supply on the Moon.

Home Sweet Home

And so we’ll have a central colony in the lava tubes near Gruithuisen crater. Some of the inhabitants will spend time mining ilmenite just a little south around the Aristarchus crater to produce oxygen and mineral byproducts. Meanwhile, others will spend time working on the water mines at the north pole and maintaining the solar power farms there which sit in the perpetual sunlight.

When will you be ready to move? What would you do differently? We haven’t even touched on growing food, which will have its own challenges given the lack of volatiles such as nitrogen. What other issues can you think of? Let us know in the comments below.

Filed under: Engineering, Featured, Original Art

Cocktail Machine Mixes Perfect Drinks Every Time

อังคาร, 12/12/2017 - 19:00

For many of us. the holiday season is coming up and that means hosting parties and mixing drinks, which can get tiresome. [GreatScott] has come up with a solution, what he calls a crude cocktail mixing machine. But don’t be fooled — it may look crude on the surface, and vibrate a bit while working, but the mechanism is plenty sound and functional.

The machine can mix three different liquids and does so using three peristaltic pumps. In typical [GreatScott] style, while he tears apart the pumps to replace the tubes, he gives us a good glimpse of just how they work. Using a knob and LCD screen, you can enter any quantity you want for the three liquids, though you’ll have to edit the Arduino code if you want to change the liquids’ names.

Load cell

How does the machine know when to stop pumping a certain liquid? Each pump is rated for a specific quantity per second, though he tests this for each liquid anyway and finds a slight variation which he accounts for in the code. After the machine turns a pump on, a load cell located under the glass tells it when liquid has started arriving at the glass. A simple calculation based on the pump’s quantity per second and the desired quantity tells it how long to leave the pump on for. When the times up, it stops the pump. The result is a machine that’s sure to be a centerpiece for any hacker-filled party. Check out his build and the pump in action in the video below.

But parties need more than just drinks, they also need cookies. So to that end, check out [Ben Krasnow]’s equally cool cookie making machine.

Filed under: cooking hacks

Keep Track Of Your Weight While Sleeping

อังคาร, 12/12/2017 - 16:00

When the average person looks at a bed, they think about sleeping. Because that’s what beds are for. You cover them with soft, warm cloths and fluffy pillows and you sleep on them. [Peter] is not your average person. He’s a maker. And when he looks at a bed, he thinks about giving it the ability to track his weight.

The IKEA bed has four Chinese-made TS-606 load cells under each foot with custom aluminum enclosures. Each one goes to an HX711 analog-to-digital converter, which offers a 24 bit resolution. These feed an Arduino Nano which in turns connects to a Raspberry Pi via USB to UART bridge. Connecting to the Pi allows [Peter] to get the data onto his home network, where he plots the data to gnuplot.

This smart bed doesn’t just track [Peter’s] weight. It can also track the weight of other people in the house, including his pets. Be sure to check his GitHub for full source code.

Filed under: Arduino Hacks

Laser Cutter Alignment Mod Skips Beam Combiner

อังคาร, 12/12/2017 - 13:00

A lot of the DIY laser engravers and cutters we cover here on Hackaday are made with laser diodes salvaged from Blu-ray drives and projectors, which are visible lasers in the 400 – 450nm range (appearing as violet or blue). Unfortunately there is an upper limit in terms of power on visible diode lasers, most builds max out at 5W or so. If you need more power than that, you’ll likely find yourself looking at gas laser cutters like the K40. While the K40 is a great starting point if you’re looking to get into “real” lasers, it’s a very different beast from the homebrew builds using visible lasers.

With a gas laser the beam itself is invisible, making it much more difficult to align or do test runs. One solution is to add a visible laser to the K40 which can be used to verify alignment, but making sure it’s traveling down the same path as the primary laser usually requires an expensive beam combiner. Looking to avoid this cost, [gafu] wanted to see if it was possible to simply move the visible laser into the path of the primary beam mechanically.

An adjustable microswitch detects when the lid has been opened.

In the setup that [gafu] has come up with, a cheap laser module (the type from a handheld laser pointer) is moved into the path of the primary laser on an arm that’s actuated by a simple hobby servo. To prevent the primary and visible lasers from firing at the same time, an Arduino is used to control the servo given the current state of the K40’s lid. If the lid of the K40 is open, the primary laser is shutoff and the visible laser is rotated into position so the operator can see where the primary laser’s beam would be hitting. Once the lid is closed, the visible laser rotates out of the way and the primary is powered back up.

Running the cutting or engraving job with the lid of the K40 machine open now let’s [gafu] watch a “dry run” of the entire operation with the visible laser before finally committing to blasting the target with the full power beam.

We’ve covered many hacks and modifications for everyone’s favorite entry-level CO2 laser cutter. From replacing the controller to making it bigger, K40 owners certainly seem like a creative bunch.

Filed under: Arduino Hacks, hardware, Laser Hacks

Make Christmas Commercial Again with this Tiny TV Ornament

อังคาร, 12/12/2017 - 10:00

Readers of a certain age will remember a time when the Christmas season in the US officially kicked off after Thanksgiving. That was when advertisers began saturation bombing the communal mind with holiday-themed TV commercials night and day. Broadcast TV no longer holds sway like it did back then, and advertisers now start their onslaught in September, but you can put a little retro-commercialism back to Christmas with this 90s Christmas commercial-playing ornament for your tree.

The idea came to [SeanHodgins] after stumbling upon a collection of Christmas commercials from the 1990s on YouTube. With his content identified, he set about building a tree-worthy display from a Pi Zero W and a TFT LCD display. An audio amp and tiny speaker from an old tablet and a LiPo battery and charger form the guts of [Sean]’s TV, which were stuffed into a 3D-printed TV case, appropriately modeled after the TV from The Simpsons. The small fresnel lens that mimics the curved screens of yore is a nice touch. The software has some neat tricks, such as an HTTP server that accepts the slug of a YouTube video, fetches the MP4, and automatically plays it. We prefer our Christmas tree ornaments a little quieter, so a volume control would have been nice, but aside from that this looks like a ton of fun.

This isn’t [Sean]’s first foray into tricked-out ornaments, of course; readers might recall his IoT cheer-measuring Christmas ornaments from last season.

Thanks to [Kathryn Fortunato] for the tip.

Filed under: Holiday Hacks, News