On the outside, a Geiger counter seems like a complicated thing. And you might think a device that detects a dangerous, mostly invisible threat like radiation should be complicated. But they’re actually pretty simple. The Geiger-Muller tube does most of the work, which boils down to detecting brief moments of conductivity caused by chain reactions of charged particles in radioactive materials.
[Prabhat_] wanted to build a unique-looking Geiger counter, and we’d say that this slick, Star Trek-esque result succeeds. A well-organized display shows the effective dose rate, counts per minute, and cumulative dose, which can be displayed in either microsieverts or millirems. We dig the 3D printed case design, because we like to see form follow function.
The counter is powered by an 18650 cell that’s DC-to-DC boosted to 400+ volts. A NodeMCU processes the signal coming in from the G-M tube and expresses it in both clicks and LED blinks, both of which can be toggled on or off from the home screen. The alert threshold can be customized in the settings, which means the point at which green changes to red.
Click-click-click past the break for [prabhat_]’s great walk-through video, where he tests it with uranium ore and a thoriated gas lantern mantle.
[Zack] had trouble getting his six-month-old to sleep through the night. That was before he found out about ‘shh’ videos on YouTube. These are exactly what they sound like: eight hours of someone whooshing white noise into a microphone. He set a phone up on a charger in the nursery and let one of these play overnight. But the phone was unreliable. It would lock up, or just crash completely, making the baby’s distress worse.
To restore peace in the house, he built a sound machine that both simplifies and fortifies the white noise shh-loution. It uses an ESP8266 and a DFPlayer Mini to loop a lone MP3 file of shh-video audio and play it from a small speaker. By integrating the machine with Home Assistant, he’s able to trigger the sound remotely at baby’s bedtime. ESP Home has no module for the DFPlayer, but [Zack] built one that he’s happy to share.
If you are mired in early parenthood, this is a nice, simple solution. The DFPlayer does all the work of reading from the SD card and converting the signal to analog for speaker output, so there’s no need to get your hands dirty wasting valuable sleeping or kid-playing time.
Once the kid starts toddling out of babyhood, [Zack] could turn to ESP8266-based ambient lighting to help establish the difference between sleep and wake time.
The modern hacker wields a number of tools that operate on the principle of heating things up to extremely high temperatures, so a smoke alarm is really a must-have piece of equipment. But in an era where it seems everything is getting smarter, some might wonder if even our safety gear could benefit from joining the Internet of Things. Interested in taking a crack at improving the classic smoke alarm, [Vivek Gupta] grabbed a NodeMCU and started writing some code.
Now before you jump down to the comments and start smashing that keyboard, let’s make our position on this abundantly clear. Do not try to build your own smoke alarm. Seriously. It takes a special kind of fool to trust their home and potentially their life to a $5 development board and some Arduino source code they copied and pasted from the Internet. That said, as a purely academic exercise it’s certainly worth examining how modern Internet-enabled microcontrollers can be used to add useful features to even the most mundane of household devices.
In this case, [Vivek] is experimenting with the idea of a smoke alarm that can be silenced through your home automation system in the event of a false alarm. He’s using Google Assistant and IFTTT, but the code could be adapted to whatever method you’re using internally to get all your gadgets on the same virtual page. On the hardware side of things, the test system is simply a NodeMCU connected to a buzzer and a MQ2 gas sensor.
So how does it work? If the detector goes off while [Vivek] is cooking, he can tell Google Assistant that he’s cooking and it’s a false alarm. That silences the buzzer, but not before the system responds with a message questioning his skills in the kitchen. It’s a simple quality of life improvement and it’s certainly not hard to imagine how the idea could be expanded upon to notify you of a possible situation even when you’re out of the home.
[Mirko Pavleski] has put together a little weather station for himself that combines Internet-sourced forecasts with physical sensor data to give him a complete view of his local conditions. There’s no shortage of weather applications for our smartphones and computers that will show us the current local conditions and the forecast for the next couple of days. It’s so easy to pull weather data from the various APIs out there that you even see the functionality “baked in” to different gadgets these days. Of course, you can dig through every weather API in the world and not find the temperature and humidity inside your office; for that, you need your own sensors.
[Mirko] took a somewhat unconventional approach by essentially building two totally separate weather devices and packing them into one enclosure, which gives the final device a rather unique look thanks to the contrasting display technologies used.
Local conditions are detected by an Arduino Nano connected to a BMP180 sensor and displayed on a Nokia 5110 LCD. The screen shows not only real-time temperature and barometric pressure, but the change in pressure over the last several hours. The three-day forecast, on the other hand, is provided by a NodeMCU ESP8266 development board connected to the increasingly ubiquitous 0.96 inch OLED.
The increase in network-connected devices the past years has been something of a dual-edged sword. While on one hand it’s really nice to have an easy and straight-forward method to have devices talk with each other, this also comes with a whole host of complications, mostly related to reliability and security.
With WiFi, integrating new devices into the network is much trickier than with Ethernet or CAN, and security (e.g. WPA and TLS) isn’t optional any more, because physical access to the network fabric can no longer be restricted. Add to this reliability issues due to interference from nearby competing WiFi networks and other sources of electromagnetic noise, and things get fairly complicated already before considering which top-layer communication protocol one should use. Continue reading “Transcending The Stack With The Right Network Protocol”→
Last year, we saw quite a bit of media attention paid to blockchain startups. They raised money from the public, then most of them vanished without a trace (or product). Ethics and legality of their fundraising model aside, a few of the ideas they presented might be worth revisiting one day.
One idea in particular that I’ve struggled with is the synthesis of IoT and blockchain technology. Usually when presented with a product or technology, I can comprehend how and/or why someone would use it – in this case I understand neither, and it’s been nagging at me from some quiet but irrepressible corner of my mind.
The typical IoT networks I’ve seen collect data using cheap and low-power devices, and transmit it to a central service without more effort spent on security than needed (and sometimes much less). On the other hand, blockchains tend to be an expensive way to store data, require a fair amount of local storage and processing power to fully interact with them, and generally involve the careful use of public-private key encryption.
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.