So you went to a tradeshow and heard about this cool new idea called the Internet Of Things; now it’s time to build an IoT product of your own. You know that to be IoT, your Widget D’lux® has to have a network connection but which to choose?
You could use WiFi or Bluetooth but that would be gauche. Maybe LoRaWAN? All the cool kids are using LoRa for medium or long range wireless these days, but that still requires a base station and Widget D’lux® will be a worldwide phenomenon. Or at least a phenomenon past your bedroom walls. And you know how much user’s hate setting things up. So a cell modem it is! But what do you have to do to legally include one in your product? Well that’s a little complicated.
The GePS is a musical project that shows how important integration work is when it comes to gesture controls. Creators [Cedric Spindler] and [Frederic Robinson] demonstrate how the output of a hand-mounted IMU (Inertial Measurement Unit) and magnetometer can be used to turn motion, gestures, and quick snap movements into musical output. The GePS is designed to have enough repeatability and low enough latency that feedback is practically immediate. As a result, it can be used and played like any other musical instrument that creates sound from physical movements in a predictable way. It’s not unlike a Theremin in that way, but much more configurable.
To do this, [Cedric] and [Frederic] made GePS from a CurieNano board (based on Intel’s Curie, which also has the IMU on-board) and an XBee radio for a wireless connection to software running on a computer, from which the sounds are played. The device’s sensitivity and low lag means that even small movements can be reliably captured, meaning that the kind of fluid and complex movements that hands do every day can be used as the basis for playing sounds with immediate feedback. In a very real sense, the glove-based GePS is an experimental kind of new instrument, which makes it a fascinating contender for the Musical Instrument Challenge portion of the 2018 Hackaday Prize.
Sensor network projects often focus primarily on electronic design elements, such as architecture and wireless transmission methods for sensors and gateways. Equally important, however, are physical and practical design elements such as installation, usability, and maintainability. The SENSEation project by [Mario Frei] is a sensor network intended for use indoors in a variety of buildings, and it showcases the deep importance of physical design elements in order to create hardware that is easy to install, easy to maintain, and effective. The project logs have an excellent overview of past versions and an analysis of what worked well, and where they fell short.
One example is the power supply for the sensor nodes. Past designs used wall adapters to provide constant and reliable power, but there are practical considerations around doing so. Not only do power adapters mean each sensor requires some amount of cable management, but one never really knows what one will find when installing a node somewhere in a building; a power outlet may not be nearby, or it may not have any unoccupied sockets. [Mario] found that installations could take up to 45 minutes per node as a result of these issues. The solution was to move to battery power for the sensor nodes. With careful power management, a node can operate for almost a year before needing a recharge, and removing any cable management or power adapter meant that installation time dropped to an average of only seven minutes.
That’s just one example of the practical issues discovered in the deployment of a sensor network in a real-world situation, and the positive impact of some thoughtful design changes in response. The GitHub repository for SENSEation has all the details needed to reproduce the modular design, so check it out.
There are a multitude of radio shields for the Arduino and similar platforms, but they so often only support one protocol, manufacturer, or frequency band. [Jan Gromeš] was vexed by this in a project he saw, so decided to create a shield capable of supporting multiple different types. And because more is so often better, he also gave it space for not one, but two different radio modules. He calls the resulting Swiss Army Knife of Arduino radio shields the Kite, and he’s shared everything needed for one on a hackaday.io page and a GitHub repository.
Supported so far are ESP8266 modules, HC-05 Bluetooth modules, RFM69 FSK/OOK modules, SX127x series LoRa modules including SX1272, SX1276 and SX1278, XBee modules (S2B), and he claims that more are in development. Since some of those operate in very similar frequency bands it would be interesting to note whether any adverse effects come from their use in close proximity. We suspect there won’t be because the protocols involved are designed to be resilient, but there is nothing like a real-world example to prove it.
Sometimes great projects keep evolving. [Bithead942] built himself an R2-D2 to accompany him when he goes a-trooping — but something didn’t feel quite right. Turns out, R2 was missing its signature beeping banter, so he made it more contextually responsive by implementing a few voice commands.
[Bithead942]’s main costume is that of an X-Wing pilot, and the replica helmet works perfectly; it already has a fake microphone — easily replaced with a working model — and the perfect niche to stash the electronics in the ‘mohawk.’
Even though the helmet has the perfect hiding spot for a circuit, space is still at a premium. Services like Alexa tend to be pretty accurate, but require WiFi access — not a guarantee on the convention floor. Instead, [bithead942] found that the EasyVR Shield 3.0 voice recognition board provided a suitable stand-in. It needs a bit of training to work properly(cue the montage!), but in the end it compares fresh audio commands to the ‘training’ files it has stored, and if there’s a match, triggers a corresponding serial port. It’s not perfect, but it most certainly works!
If you still have a drawer full of slap bracelets from the 1990s because, you know, they might come back, then you’ll appreciate [Vorticon’s] latest project. Sure, we see lots of weather stations, but this one is controlled by a TI 99/4A computer. This home computer from the 1980s was actually ahead of its time with a 16-bit processor.
The sensors use Xbee modules and an Arduino Uno. Of course, the Uno has more power than the TI computer, but that’s not really the point, right? He’s made a series of videos detailing the construction (you can see the first one below, but there are five, so far).
Sometimes the journey is as interesting as the destination, and that’s certainly the case with [Marc]’s pursuit of measuring his sleep apnea (PDF, talk slides. Video embedded below.). Sleep apnea involves periods of time when you don’t breathe or breathe shallowly for as long as a few minutes and affects 5-10% of middle-aged men (half that for women.) [Marc]’s efforts are still a work-in-progress but along the way he’s tried a multitude of things, all involving different technology and bugs to work out. It’s surprising how many ways there are to monitor breathing.
His attempts started out using a MobSenDat Kit, which includes an Arduino compatible board, and an accelerometer to see just what his sleeping positions were. That was followed by measuring blood O2 saturation using a cheap SPO2 sensor that didn’t work out, and one with Bluetooth that did work but gave results as a graph and not raw data.
Next came measuring breathing by detecting airflow from his nose using a Wind Sensor, but the tubes for getting the “wind” from his nose to the sensor were problematic, though the approach was workable. In parallel with the Wind Sensor he also tried the Zeo bedside sleep manager which involves wearing a headband that uses electrical signals from your brain to tell you what sleep state you’re in. He particularly liked this one as it gave access to the data and even offered some code.
And his last approach we know of was to monitor breathing by putting some form of band around his chest/belly to measure expansion and contraction. He tried a few bands and an Eeonyx conductive textile/yarn turned out to be the best. He did run into noise issues with the Xbee, as well as voltage regulator problems, and a diode that had to be bypassed.