Pushing all of your data into “The Cloud” sounds great, until you remember that what you’re really talking about is somebody else’s computer. That means all your hard-crunched data could potentially become inaccessible should the company running the service go under or change the rules on you; a situation we’ve unfortunately already seen play out.
Which makes this project from [Zoltan Doczi] and [Róbert Szalóki] so appealing. Not only does it show how easy it can be to shuffle your data through the tubes and off to that big data center in the sky, but they send it to one of the few companies that seem incapable of losing market share: Google. But fear not, this isn’t some experimental sensor API that the Big G will decide it’s shutting down next Tuesday in favor of a nearly identical service with a different name. All your precious bits and bytes will be stored in one of Google’s flagship products: Sheets.
It turns out that Sheets has a “Deploy as Web App” function that will spit out a custom URL that clients can use to access the spreadsheet data. This project shows how that feature can be exploited with the help of a little Python code to push data directly into Google’s servers from the Raspberry Pi or other suitably diminutive computer.
Here they’re using a temperature and humidity sensor, but the only limitation is your imagination. As an added bonus, the chart and graph functions in Sheets can be used to make high-quality visualizations of your recorded data at no extra charge.
You might be wondering what would happen if a bunch of hackers all over the world started pushing data into Sheets every few seconds. Honestly, we don’t know. The last time we showed how you could interact with one of their services in unexpected ways, Google announced they were retiring it on the very same day. It was probably just a coincidence, but to be on the safe side, we’d recommend keeping the update frequency fairly low.
Back in 2012, before the service was even known as Google Sheets, we covered how you could do something very similar by manually assembling HTTP packets containing your data. We’d say this validates the concept for long-term data storage, but clearly the methodology has changed considerably in the intervening years. Somebody else’s computer, indeed.
People unfamiliar with shooting sports sometimes fail to realize the physicality of getting a bullet to go where you want it to. In the brief but finite amount of time that the bullet is accelerating down the barrel, the tiniest movement of the gun can produce enormous changes in its trajectory, and the farther away your target is, the bigger the potential error introduced by anticipating recoil or jerking the trigger.
Like many problems this one is much easier to fix with what you can quantify, which is where this DIY rifle accelerometer can come in handy. There are commercial units designed to do the same thing that [Eric Higgins]’ device does but most are priced pretty dearly, so with 3-axis accelerometer boards going for $3, rolling his own was a good investment. Version 1, using an Arduino Uno and an accelerometer board for data capture with a Raspberry Pi for analysis, proved too unwieldy to be practical. The next version had a much-reduced footprint, with a Feather and the sensor mounted in a 3D-printed tray for mounting solidly on the rifle. The sensor captures data at about 140 Hz, which is enough to visualize any unintended movements imparted on the rifle while taking a shot. [Eric] was able to use the data to find at least one instance where he appeared to flinch.
[G6EJD] wanted to design a low power datalogger and decided to look at the power consumption of an ESP32 versus an ESP8266. You can see the video results below.
Of course, anytime someone does a power test, you have to wonder if there were any tricks or changes that would have made a big difference. However, the relative data is interesting (even though you could posit situations where even those results would be misleading). You should watch the videos, but the bottom line was a 3000 mAh battery provided 315 days of run time for the ESP8266 and 213 days with the ESP32.
There has always been a need for electronic graph paper – a digital device that records ones and zeros, writes bits, and keeps track of analog voltages. Many moons ago, this sort of device was graph paper, wrapped around a drum, slowly spinning around once per day. With the advent of cheap, powerful microcontrollers and SD cards these devices have become even more capable.
For their entry to the Hackaday Prize, [Kuldeep] and [Sandeep] have built Box0. It’s a lab in a bag, an open source data acquisition unit, and a USB device that toggles pins, all in one simple device.
The hardware for this devices consists of an STM32F0 microcontroller, a USB port, and enough pins to offer up a few SPIs, an I2C bus, eight channels of digital output, two PWM channels, a UART, analog in, and analog out.
Between Tesla Motors’ automobiles and SpaceX’s rockets, Elon Musk’s engineers just have to be getting something right. In part, SpaceX’s success in landing their first stage rockets is due to analysis of telemetry data. You can see some of the data from their launch vehicles on the live videos and there is surely a lot more not shown.
An article in MIT Technology Review provides similar insights in how Tesla came from behind in autonomous vehicle operation by analyzing telemetry from their cars. Since 2014 their Model S received an increasing number of sensors that all report their data over the vehicle’s always-on cellular channel. Sterling Anderson of Tesla reported they get a million miles of data every 10 hours.
The same approach can help us to improve our systems but many believe creating a log of key data is costly in time and resources. If your system is perfect (HA HA!) that would be a valid assessment. All too often such data becomes priceless if analysis explains why your drone or robot wanted to go left into a building instead of right into the open field.
You can write with a fifty cent disposable pen. Or you can write with a $350 Montblanc. The words are the same, but many people will tell you there is something different about the Montblanc. Maybe that’s how [armin] feels about meat thermometers. His version uses a Raspberry Pi and has a lengthy feature list:
8 Channel data logging
Webcam (USB or Raspicam)
Alarms via a local beeper, Web, WhatsApp, or e-mail
Temperature and fan control using a PID
You can even use a Pi Zero for a light version. There’s plenty of information on Hackaday.io, although the full details are only in German for the moment. As you can see in the video below, this isn’t your dollar store meat thermometer.
Even though a disposable pen does the same job as a Montblanc, most of us would rather have a Montblanc (although Hackday would have to hand out some pretty steep raises before we start using the Meisterstück Solitaire Blue Hour Skeleton 149).
We might have done more with an ESP8266 and then done more work on the client, but we have to admit, this is one feature-packed thermometer. We’ve seen simpler ones that use Bluetooth before, along with some hacks of commercial units.
Laying hands on the supplies for most hacks we cover is getting easier by the day. A few pecks at the keyboard and half a dozen boards or chips are on an ePacket from China to your doorstep for next to nothing. But if hacking life is what you’re into, you’ll spend a lot of time and money gathering the necessary instrumentation. Unless you roll your own mini genetic engineering lab from scratch, that is.
Taking the form of an Arduino mega-shield that supports a pH meter, a spectrophotometer, and a PID-controlled hot plate, [M. Bindhammer]’s design has a nice cross-section of the instruments needed to start biohacking in your basement. Since the shield piggybacks on an Arduino, all the data can be logged, and decisions can be made based on the data as it is collected. One example is changing the temperature of the hot plate when a certain pH is reached. Not having to babysit your experiments could be a huge boon to the basement biohacker.