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. Continue reading “Statistics And Hacking: A Stout Little Distribution”→
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.
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.
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.
[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
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.
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.
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.
