Hacking an AUX Port for a Google Home Mini

Even if you don’t want to add an AUX audio output port to your Google Home Mini, you’ll still want to see a pair of videos from [SnekTek]. After all, you’ll eventually want to open it up, and putting it over some boiling water might not have been your first idea. You can see both videos, below.

However, he did want to add an AUX port. The biggest challenge was finding a place to put the connector. Even after identifying a likely spot, a bolt interfered with the case closing and so he removed it. The one bolt didn’t seem to bother the final result.

Electrically, he found that to keep the AUX out to about 1V, he needed a reduction in voltage. Two small resistors put right in the speaker line took care of that. Although, be sure to watch the second video if you plan to recreate this hack since the value of the resistors changed.

Truthfully, the AUX jack part isn’t nearly as interesting as opening the thing up, although we have to admit, we wouldn’t mind putting a BlueTooth adapter in that plug to stream to a big speaker that isn’t cast-enabled. However, we have noticed it is getting harder and harder to break into consumer electronics, and you never know when you’ll need to get into one of these to hack, repair, or cannibalize.

With the cheaper mini version of the Google smart device, we expect to see more hacks for it. We’ve seen some creative mash ups and, of course, you can always roll your own hardware.

Posted in aux, google hacks, google home mini, jack socket, voltage divider | Leave a comment

This Coin Cell Can Move That Train!

[Mike Rigsby] has moved a train with a coin cell. A CR2477 cell to be exact, which is to say one of the slightly more chunky examples, and the train in question isn’t the full size variety but a model railroad surrounding a Christmas tree, but nevertheless, the train moved.

A coin cell on its own will not move a model locomotive designed to run on twelve volts. So [Mark] used a boost converter to turn three volts into twelve. The coin cell has a high internal resistance, though, so first the coin cell was discharged into a couple of supercapacitors which would feed the boost converter. As his supercaps were charging, he meticulously logged the voltage over time, and found that the first one took 18 hours to charge while the second required 51 hours.

This is important and useful data for entrants to our Coin Cell Challenge, several of whom are also going for a supercap approach to provide a one-off power boost. We suspect though that he might have drawn a little more from the cell, had he selected a dedicated supercap charger circuit.

Posted in coin cell, coin cell challenge, model railroad, railroad, supercapacitor, toy hacks | Leave a comment

Using Gmail with OAUTH2 in Linux and on an ESP8266

One of the tasks I dread is configuring a web server to send email correctly via Gmail. The simplest way of sending emails is SMTP, and there are a number of scripts out there that provide a simple method to send mail that way with a minimum of configuration. There’s even PHP mail(), although it’s less than reliable.

Out of the box, Gmail requires OAUTH2 for authentication and to share user data, which has the major advantage of not requiring that you store your username and password in the application that requires access to your account. While they have an ‘allow less secure apps’ option that allows SMTP access for legacy products like Microsoft Outlook, it just doesn’t seem like the right way forward. Google documents how to interact with their API with OAUTH2, so why not just use that instead of putting my username and password in plaintext in a bunch of prototypes and test scripts?

Those are the thoughts that run through my head every time this comes up for a project, and each time I’ve somehow forgotten the steps to do it, also forgotten to write it down, and end up wasting quite a bit of time due to my own foolishness. As penance, I’ve decided to document the process and share it with all of you, and then also make it work on an ESP8266 board running the Arduino development environment.

Before we continue, now would be a good time for a non-technical refresher on how OAUTH works. The main differences between OAUTH and OAUTH2 are that the latter requires HTTPS, and the access tokens that allow an application to use specific services in a user account have an expiry.

To use Gmail with OAUTH2, we will need to start with five things: An application registered in the Google APIs, its client ID and client secret, a computer running LAMP (a by-the-hour VPS works just fine here), and a domain name that points to it.

Registering an application with Google API is easy. Go to the Google API console, log in, create a new project, and enter it. Enable the Gmail API; it should be suggested on the front page.

With the project created and the Gmail API enabled, the dashboard should look something like this

Then click on ‘credentials’ on the sidebar, create credentials, and finally ‘create OAUTH Client ID’. Before you can continue, you need to create a consent screen. The only entry you really need to fill out at this time is ‘Product Name Shown to Users’.

After saving that form, select ‘Web Application’ as your application type. Note the field called ‘Authorized redirect URIs’, we’ll return to it later. It’s important that it be correctly set for us to be able to receive a refresh token later on in this process.

For now, just press ‘Create’. A pop-up will display containing your Client ID and Client secret. You’ll need them soon, so best to copy/paste them into a local file on your computer for now.

Next, we will use those two pieces of data to request an access token and refresh token. We may as well accomplish two things at the same time here by installing the popular PHP email sender called PHPMailer on our web server. It includes a tool to request an OAUTH2 access/refresh token as well as being easily capable of sending a quick test email. To install it, we’ll use the Composer PHP dependency management tool:

$sudo apt-get install composer

Then we should navigate to our web-accessible directory, in my case /var/www/html, and install a few PHP scripts. Note that this should not be done as root, so create another user if needed and give them access to the directory:

$composer require phpmailer/phpmailer
$composer require league/oauth2-client
$composer require league/oauth2-google

Now enter the directory vendor/phpmailer/phpmailer. There will be a script called get_oauth_token.php. Move this script up three directories into the directory you just ran the ‘composer’ commands from. The location of this script as seen from the web needs to be entered into the ‘Authorized redirect URIs’ field of the Google API that we saw earlier. In this case it would have been https://mydomain.com/get_oauth_token.php. Public IP addresses will not work, this is why a domain name pointed to your web server is a requirement.

Now, open get_oauth_token.php in a text editor and paste in your Client ID and Client Secret where needed. Don’t try to run the script locally, it will fail. Open up a web browser on any computer, and navigate to the URL you entered as the ‘Authorized redirect URI’. Then select Google from the list of email services – at this point if it worked you will be asked to log in and then authorize the unverified application, under ‘Advanced’ under the warning prompt, at which point you will finally receive a refresh token. If you only want an access token for some reason you’ll have to edit the script to echo it back.

If that didn’t work, there are two common reasons: a wrong redirect URI or the script cannot find its dependencies. In the former case, the error message from Google will tell you the script URL as it sees it, and you can use that information to update the redirect URI in the Google API Console to fix the issue. For the latter, check your apache error log, probably located in /var/log/apache2/error.log, to see what dependency is not being found. You might see something like this:

PHP Warning: require(vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/mydomain/get_oauth_token.php on line 59, referer: http://mydomain.com/get_oauth_token.php

If you have received your refresh token, congratulations: the painful part is over. You can just go to the PHPMailer Github page and fill out their OAUTH2 example (gmail_xoauth.phps), and it ought to just work. If all you needed to do is send mail from a project on your VPS, you’re more or less ready to move on to more interesting parts of your project:

$email = 'someone@gmail.com';
$clientId = 'RANDOMCHARS-----duv1n2.apps.googleusercontent.com';
$clientSecret = 'RANDOMCHARS-----lGyjPcRtvP';
//Obtained by configuring and running get_oauth_token.php
//after setting up an app in Google Developer Console.
$refreshToken = 'RANDOMCHARS-----DWxgOvPT003r-yFUV49TQYag7_Aod7y0';

Remember to clean up any unnecessary scripts that contain your refresh token and other sensitive data before continuing.

ESP8266: We Don’t Need No Stinking Servers

Now what if we wanted to use these tokens to send email directly from project on a Raspberry Pi without needing a server in the middle? It turns out that once we have the client ID, client secret, and refresh token, we no longer require the server and domain name we’ve been using so far, and a mail-sending application, e.g. PHPMailer, can be installed on a computer anywhere with Internet access as long as it is configured with those values.

Things get a little more complicated when we try to do this on an ESP8266. OAUTH2 requires that we use SSL, and access tokens regularly expire and need to be refreshed. Thankfully, [jalmeroth] generously wrote a proof-of-concept and published it on GitHub. If provided with an access token, it can access your Gmail account and use it to send an email. It can also directly update/get data from Google Sheets, but I didn’t test this. However, if the access token was expired, it couldn’t detect that, although it did include working code to actually request a new token, but not parse it out and use it.

In an attempt to add to the functionality of that proof of concept, I forked the project and made a few changes. First, I changed to order of operations in the code to make it check if the current access token was valid before doing anything else. Second, Google API was responding ‘400 Bad Request’ if the access token was invalid, and everything but ‘200 OK’ responses were being filtered out by the code. Finally, I wrote a couple of JSON parsers that check the reason for the ‘400 Bad Request’ and extract and use the access token returned by Google API when a new one is requested.

It works, but it’s hardly reliable – not surprising considering I’ve never really used the Arduino platform before. Notably, the SHA1 fingerprint for Google API fails often. Checking from my local machine, the SHA1 fingerprint varies between two signatures there too. It would be fairly easy to check for either of them, or just keep trying, but I’d rather understand what’s going on first. (Is it just a CDN or something else?) Or perhaps I should rewrite the whole application in Lua where I’m more competent.

A fun little application built on the above was to place a button on my office that sends an email to my phone. I don’t want people to contact me at that email address frivolously, but do want to know immediately if someone is waiting outside my office. The big red button is for normal requests, but urgent requests require lockpicking. If it’s urgent it better also be interesting.

Finally, did you know that Hackaday provides an API for accessing hackaday.io? It uses the simpler OAUTH (not OAUTH2) authentication, so should be more straightforward than the above to implement on the ESP8266. Have any of you used it?

Posted in Arduino Hacks, Arduino-compatible, ESP8266, Gmail, Google API, google hacks, how-to, NodeMCU, oauth, oauth2, Original Art | Leave a comment

Friday Hack Chat: Eagle One Year Later

Way back in June of 2016, Autodesk acquired Cadsoft, and with it EagleCAD, the popular PCB design software. There were plans for some features that should have been in Eagle two decades ago, and right now Autodesk is rolling out an impressive list of features that include UX improvements, integration with MCAD and Fusion360, and push and shove routing.

Six months into the new age of Eagle, Autodesk announced they would be changing their licensing models to a subscription service. Where you could pay less than $100 once and hold onto version 6.0 forever, now you’re required to pay $15 every month for your copy of Eagle. Yes, there’s still a free, educational version, but this change to a subscription model caused much consternation in the community when announced.

For this week’s Hack Chat, we’re going to be talking about Eagle, one year in. Our guest for this Hack Chat is Matt Berggren, director of Autodesk Circuits, hardware engineer, and technologist that has been working on bringing electronic design to everyone. We’ll be asking Matt all about Eagle, with questions including:

  • What new features are in the latest edition of Eagle?
  • What’s on the Eagle wishlist?
  • What technical challenges arise when designing new features?
  • Where can a beginner find resources for designing PCBs in Eagle?

Join the chat to hear about new features in Eagle, how things are holding up for Eagle under new ownership, and how exactly the new subscription model for Eagle is going. We’re looking for questions from the community, so if you have a question for Matt or the rest of the Eagle team, put it on the Hack Chat event page.

If you’re wondering about how Altium and KiCad are holding up, or have any questions about these PCB design tools, don’t worry: we’re going to have Hack Chats with these engineers in the new year.

join-hack-chat

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down on noon, PST, Friday, December 15th. Time Zones got you down? Here’s a handy count down timer!

Click that speech bubble to the left, and you’ll be taken directly to the Hack Chat group on Hackaday.io.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Posted in autodesk, cadsoft, eagle, EagleCad, Hack Chat, Hackaday Columns, pcb, PCB design, software | Leave a comment

The Zombie Rises Again: Drone Registration Is Back

It’s a trope of horror movies that demonic foes always return. No sooner has the bad guy been dissolved in a withering hail of holy water in the denoeument of the first movie, than some foolish child in a white dress at the start of the next is queuing up to re-animate it with a careless drop of blood or something. If parents in later installments of popular movie franchises would only keep an eye on their darn kids, it would save everybody a whole lot of time!

The relevant passage can be found in section 1092(d) of the National Defense Authorization Act, on page 329 of the mammoth PDF containing the full text, and reads as follows:

(d) RESTORATION OF RULES FOR REGISTRATION AND MARKING OF UNMANNED AIRCRAFT
.—The rules adopted by the Administrator
of the Federal Aviation Administration in the matter of registration
and marking requirements for small unmanned aircraft (FAA-2015-
7396; published on December 16, 2015) that were vacated by the
United States Court of Appeals for the District of Columbia Circuit
in Taylor v. Huerta (No. 15-1495; decided on May 19, 2017) shall
be restored to effect on the date of enactment of this Act.

This appears to reverse the earlier decision of the court, but does not specify whether there has been any modification to the requirements to prevent their being struck down once more by the same angle of attack. In particular, it doesn’t change any of the language in the FAA Modernization Act of 2012, which specifically prevents the Agency from regulating hobby model aircraft, and was the basis of Taylor v. Huerta. Maybe they are just hoping that hobby flyers get fatigued?

We took a look at the registration system before it was struck down, and found its rules to be unusually simple to understand when compared to other aviation rulings, even if it seemed to have little basis in empirical evidence. It bears a resemblance to similar measures in other parts of the world, with its 250 g weight limit for unregistered machines. It will be interesting both from a legal standpoint to see whether any fresh challenges to this zombie law emerge in the courts, and from a technical standpoint to see what advances emerge from Shenzhen as the manufacturers pour all their expertise into a 250 g class of aircraft.

Thanks [ArduinoEnigma] for the tip.

Posted in drone, drone hacks, drone law, drone registration, multirotor, news | Leave a comment

Binary Clock Build

This Binary Clock Build project by JD is enclosed in a custom acrylic enclosure. 3 buttons are used to adjust the time, the binary clock is displayed for your leet friends. For the regular folk there is also a time display on the LCD. The System is powered by a Parallax Popeller. With 40 pins the Propeller has enough pins to drive each LED direct, the buttons are also all connected direct. The LCD is a serial LCD so that just required one data line but there are still available pins so chances are a standard LCD would also work.

 





Posted in Electronic Hacks | Leave a comment

Guitar Game Plays with Enhanced Realism

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.

Posted in arduino, Arduino Hacks, bluetooth, dds, guitar, guitar hero, Karplus-Strong, Microcontrollers, musical hacks, pic32 | Leave a comment

Extraterrestrial Autonomous Lander Systems to Touch Down on Mars

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.

Posted in 2017 Hackaday Superconference, autonomous, Extraterrestial, Hackaday Columns, jpl, mars, Mars Landing, nasa | Leave a comment

Statistics and Hacking: A Stout Little Distribution

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.

Posted in dht11, hardware, how-to, math is beautiful, NodeMCU, python, statistics | Leave a comment

The Tiniest Of 555 Pianos

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.

Posted in 555, coin cell, coin cell challenge, music, musical hacks, piano, synth | Leave a comment