Posts | Comments

Planet Arduino

We’re digging these daisy-chainable encoders built by [fattore.saimon]. Each module consists of a rotary encoder attached to a PCB with a PIC16F15386 on the back. As we’ve covered in the past, the Microchip released their feature-rich PIC16 microprocessor just this year, and it’s great to see them start to crop up in projects. With 4 address jumpers on the back of each PCB, [fattore.saimon] is able to connect up to 16 of the encoders on the bus. The modules also have male and female plugs so he can connect them physically as well, to simplify wiring. Each module also has a PWMable bicolor LED for keeping track of each encoder’s setting.

If you’re interested in making your own you can buy the PCBs from Tindie or download the project files from the creator’s GitHub, including an Arduino library.

We love encoders here on Hackaday — building DIY encoders, as well as using them in projects like this precision cutting jig. And definitely read our colleague [Al]’s great piece on encoders.


Filed under: Arduino Hacks

Quick Charge, Qualcomm’s power delivery over USB technology, was introduced in 2013 and has evolved over several versions offering increasing levels of power transfer. The current version — QCv3.0 — offers 18 W power at voltage levels between 3.6 V to 20 V.  Moreover, connected devices can negotiate and request any voltage between these two limits in 200 mV steps. After some tinkering, [Vincent Deconinck] succeeded in turning a Quick Charge 3.0 charger into a variable voltage power supply.

His blog post is a great introduction and walk through of the Quick Charge ecosystem. [Vincent] was motivated after reading about [Septillion] and [Hugatry]’s work on coaxing a QCv2.0 charger into a variable voltage source which could output either 5 V, 9 V or 12 V. He built upon their work and added QCv3.0 features to create a new QC3Control library.

To come to grips with what happens under the hood, he first obtained several QC2 and QC3 chargers, hooked them up to an Arduino, and ran the QC2Control library to see how they respond. There were some unexpected results; every time a 5 V handshake request was exchanged during QC mode, the chargers reset, their outputs dropped to 0 V and then settled back to a fixed 5 V output. After that, a fresh handshake was needed to revert to QC mode. Digging deeper, he learned that the Quick Charge system relies on specific control voltages being detected on the D+ and D- terminals of the USB port to determine mode and output voltage. These control voltages are generated using resistor networks connected to the microcontroller GPIO pins. After building a fresh resistor network designed to more closely produce the recommended control voltages, and then optimizing it further to use just two micro-controller pins, he was able to get it to work as expected. Armed with all of this information, he then proceeded to design the QC3Control library, available for download on GitHub.

Thanks to his new library and a dual output QC3 charger, he was able to generate the Jolly Wrencher on his Rigol, by getting the Arduino to quickly make voltage change requests.


Filed under: Arduino Hacks, hardware

As our lives become more and more automated, we tend to rely on computers and unseen algorithms to “protect” us from unapproved experiences. In order to illustrate this concept, and hopefully introduce serendipitous events to our digital lives, David Columbini has come up with an installation that feeds information to users via a web app, available only when it’s on display.

Instead of implementing a carefully designed algorithm, what users experience is based on constantly evolving local weather data sensed by a physical machine equipped with an Arduino Mega, a Raspberry Pi, various sensors, and some other components.

“The Weather Followers” is comprised of four different instruments: a wind-driven messaging app, a pollution-distorted selfie tool, a music player based on the rhythm of rain, and even a device that erases your feed depending on the sun’s intensity!

The installation is comprised of two elements, the four weather instruments and the webapp. Users are invited to connect to the weather machine through the webapp and choosing between one of the four weather instruments: Windy encounters (when your digital social life follows the wind), Polluted Selfie (when your digital individual life follows the pollution), Drizzly Rhythms (when your digital audio life follows the rain) and finally Sun(e)rase (when your digital overwhelming life follows the sun).

More details on the project can be found here. If you want to see another weather/digital world combination by Columbini, be sure to check out this balloon messaging system!

Now that I have xLights being built fine within docker (see Automatic testing of xLights builds via Travis-CI/Docker/Github) the next step is to package up the application as an appimage binary so that it can easily be run on varied linux systems.

It is being built based on Ubuntu Trusty and has been tested to work on Ubuntu 16.04, 16.10, Fedora 25 and OpenSuse 42.2 (and should hopefully work pretty much anywhere else as well)

The creation of the AppImage is done by the Recipe.appimage file that I included in the docker image.  This means that building of the appimage is simply:

$ docker pull debenham/xlights
$ docker run --name buildvm debenham/xlights /bin/bash Recipe.appimage

I’ll break down the Recipe now to explain how it works:

First up we run the Recipe script to build xLights (as shown in previous post).

#!/bin/bash
./Recipe

Next up we setup the environment ready for later on.  The $VERSION number is generated using the version number in the xLights_4_64bit.iss (which is where the version number is explicitly set for the windows install and so is a good/safe place to grab from).   If I am generating a release version (by passing ‘release’ as the command-line option) it will leave it at that.  If this is not a release version (such as for testing/development) then it will also add the short hash of the last commit.  This is handy so I can easily tell which commit the package was built from.

export BASEDIR=/xLights
cd ${BASEDIR}/xlights-git
APP=xLights
COMMIT=`git log --pretty=format:'%h' -n 1`
VERS=`grep AppVersion xLights_4_64bit.iss |sed -e 's/^.*=//g'`
if [ "$1" = "release" ]
then VERSION=${VERS}
else VERSION=${VERS}-${COMMIT}
fi

Now we install xLights into the target AppDir directory

rm -rf ${BASEDIR}/$APP/
 mkdir ${BASEDIR}/$APP/
 make install DESTDIR=${BASEDIR}/$APP/$APP.AppDir PREFIX=/usr

Okay, we have xLights installed in ${BASEDIR}/$APP/$APP.AppDir so the next step is to setup this directory ready to be packaged up.  To do this we import the functions.sh script which contains a bunch of handy functions needed for building AppImages

cd ${BASEDIR}/$APP/

wget -q https://raw.githubusercontent.com/AppImage/AppImages/master/functions.sh -O ./functions.sh
 . ./functions.sh

Lets put the appicons/desktop launcher in place ready to go

cd ${BASEDIR}/$APP/$APP.AppDir

cp usr/share/icons/hicolor/256x256/apps/xlights.png .
cp usr/share/icons/hicolor/256x256/apps/xschedule.png .
cp ./usr/share/applications/xlights.desktop .

Next we need to grab the AppRun binary (which is basically a wrapper which takes care of setting up all the environment so the binary inside the AppImage uses the right libraries/paths etc).   Since xLights needs a newer libstdc++.so.6 than is included in Ubuntu Trusty we needed a specially patched AppRun which allows for the bundling of the newer library without breaking systems which already have a newer library.  See https://github.com/darealshinji/AppImageKit-checkrt/ for details of why this is needed.

wget -O AppRun https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/AppRun-patched-x86_64
 chmod +x AppRun

Now we need to find all the libraries needed by xLights and put them in place.  This is handled automatically by the copy_deps function we imported previously from functions.sh.  I have to manually move the pulseaudio libraries to the common directory (so AppRun doesn’t need to be modified further) and also remove libharfbuzz.* as it causes xLights to be unable to run if it is included.  I also manually copy libstdc++.so.6 to the special path as needed by the modified AppRun.  We finish up by stripping the libraries to save space.

export LD_LIBRARY_PATH=./usr/lib/:$LD_LIBRARY_PATH

copy_deps ; copy_deps ; copy_deps # Three runs to ensure we catch indirect ones
 move_lib
 mv usr/lib/x86_64-linux-gnu/pulseaudio/* usr/lib/x86_64-linux-gnu
 rm usr/lib/x86_64-linux-gnu/libharfbuzz.*
 mkdir -p usr/optional/libstdc++
 cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 usr/optional/libstdc++/
 delete_blacklisted

strip usr/lib/* usr/lib/*/* || true

 

Almost done now. Just tell AppImageKit what the target launcher will be

get_desktopintegration xlights

Final steps now.  First we check if we are running within Docker. This is needed so that the generate function knows to not use FUSE to mount the image (since FUSE doesn’t work properly within a standard docker container)

cd ..

########################################################################
 # AppDir complete
 # Now packaging it as an AppImage
 ########################################################################

if [[ ! $(cat /proc/1/sched | head -n 1 | grep init) ]]; then {
 echo in docker
 DOCKER_BUILD="yes"
 } fi

And the very last step is to call generate_type2_appimage to actually create the appimage file itself

generate_type2_appimage

After all this is done we are left with a xLights.xxxxxx.AppImage file sitting in ${BASEDIR}/out – ready for uploading to the web and people to use!

For me I then scp them to my web server and wordpress will show the new file automatically at https://www.adebenham.com/xlights-linux/

Now that I have xLights being built fine within docker (see Automatic testing of xLights builds via Travis-CI/Docker/Github) the next step is to package up the application as an appimage binary so that it can easily be run on varied linux systems.

It is being built based on Ubuntu Trusty and has been tested to work on Ubuntu 16.04, 16.10, Fedora 25 and OpenSuse 42.2 (and should hopefully work pretty much anywhere else as well)

The creation of the AppImage is done by the Recipe.appimage file that I included in the docker image.  This means that building of the appimage is simply:

$ docker pull debenham/xlights
$ docker run --name buildvm debenham/xlights /bin/bash Recipe.appimage

I’ll break down the Recipe now to explain how it works:

First up we run the Recipe script to build xLights (as shown in previous post).

#!/bin/bash
./Recipe

Next up we setup the environment ready for later on.  The $VERSION number is generated using the version number in the xLights_4_64bit.iss (which is where the version number is explicitly set for the windows install and so is a good/safe place to grab from).   If I am generating a release version (by passing ‘release’ as the command-line option) it will leave it at that.  If this is not a release version (such as for testing/development) then it will also add the short hash of the last commit.  This is handy so I can easily tell which commit the package was built from.

export BASEDIR=/xLights
cd ${BASEDIR}/xlights-git
APP=xLights
COMMIT=`git log --pretty=format:'%h' -n 1`
VERS=`grep AppVersion xLights_4_64bit.iss |sed -e 's/^.*=//g'`
if [ "$1" = "release" ]
then VERSION=${VERS}
else VERSION=${VERS}-${COMMIT}
fi

Now we install xLights into the target AppDir directory

rm -rf ${BASEDIR}/$APP/
 mkdir ${BASEDIR}/$APP/
 make install DESTDIR=${BASEDIR}/$APP/$APP.AppDir PREFIX=/usr

Okay, we have xLights installed in ${BASEDIR}/$APP/$APP.AppDir so the next step is to setup this directory ready to be packaged up.  To do this we import the functions.sh script which contains a bunch of handy functions needed for building AppImages

cd ${BASEDIR}/$APP/

wget -q https://raw.githubusercontent.com/AppImage/AppImages/master/functions.sh -O ./functions.sh
 . ./functions.sh

Lets put the appicons/desktop launcher in place ready to go

cd ${BASEDIR}/$APP/$APP.AppDir

cp usr/share/icons/hicolor/256x256/apps/xlights.png .
cp usr/share/icons/hicolor/256x256/apps/xschedule.png .
cp ./usr/share/applications/xlights.desktop .

Next we need to grab the AppRun binary (which is basically a wrapper which takes care of setting up all the environment so the binary inside the AppImage uses the right libraries/paths etc).   Since xLights needs a newer libstdc++.so.6 than is included in Ubuntu Trusty we needed a specially patched AppRun which allows for the bundling of the newer library without breaking systems which already have a newer library.  See https://github.com/darealshinji/AppImageKit-checkrt/ for details of why this is needed.

wget -O AppRun https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/AppRun-patched-x86_64
 chmod +x AppRun

Now we need to find all the libraries needed by xLights and put them in place.  This is handled automatically by the copy_deps function we imported previously from functions.sh.  I have to manually move the pulseaudio libraries to the common directory (so AppRun doesn’t need to be modified further) and also remove libharfbuzz.* as it causes xLights to be unable to run if it is included.  I also manually copy libstdc++.so.6 to the special path as needed by the modified AppRun.  We finish up by stripping the libraries to save space.

export LD_LIBRARY_PATH=./usr/lib/:$LD_LIBRARY_PATH

copy_deps ; copy_deps ; copy_deps # Three runs to ensure we catch indirect ones
 move_lib
 mv usr/lib/x86_64-linux-gnu/pulseaudio/* usr/lib/x86_64-linux-gnu
 rm usr/lib/x86_64-linux-gnu/libharfbuzz.*
 mkdir -p usr/optional/libstdc++
 cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 usr/optional/libstdc++/
 delete_blacklisted

strip usr/lib/* usr/lib/*/* || true

 

Almost done now. Just tell AppImageKit what the target launcher will be

get_desktopintegration xlights

Final steps now.  First we check if we are running within Docker. This is needed so that the generate function knows to not use FUSE to mount the image (since FUSE doesn’t work properly within a standard docker container)

cd ..

########################################################################
 # AppDir complete
 # Now packaging it as an AppImage
 ########################################################################

if [[ ! $(cat /proc/1/sched | head -n 1 | grep init) ]]; then {
 echo in docker
 DOCKER_BUILD="yes"
 } fi

And the very last step is to call generate_type2_appimage to actually create the appimage file itself

generate_type2_appimage

After all this is done we are left with a xLights.xxxxxx.AppImage file sitting in ${BASEDIR}/out – ready for uploading to the web and people to use!

For me I then scp them to my web server and wordpress will show the new file automatically at https://www.adebenham.com/xlights-linux/

When the Power Glove was released in the early 1990s, the idea that you could control games with hand motions was incredible, but like the Virtual Boy that followed years later, the hardware of the day just couldn’t keep up. Today, hardware has finally gotten to the point where this type of interface could be very useful, so Teague Labs decided to integrate a Power Glove with an HTC Vive VR headset.

While still under development, the glove’s finger sensors have shown great promise for interactions with virtual touchscreen devices, and they’ve even come up with a game where you have to counter rocks, paper, and scissors with the correct gesture.

Making this all possible is the Arduino Due, which supports the library for communicating with the Vive tracker.

We took a Power Glove apart, 3D scanned the interfacing plastic parts and built modified parts that hold the Vive Tracker and an Arduino Due on the glove. After some prototyping on a breadboard, we designed a shield for the Due and etched it using the laser-cutter transfer technique. We then soldered all components and spray-painted the whole shield to protect the bare copper. After mounting the tracker and tweaking the code by matzmann666, we had the glove work.

If you’d like to see the details of what has been accomplished so far, check out the Teague Labs team’s design files and code on GitHub.

When you’re sick or have a headache, you tend to see things a bit differently. An ill-feeling human will display a cognitive bias and expect the world to punish them further. The same is true of honey bees. They are intelligent creatures that exhibit a variety of life skills, such as decision-making and learning.

It was proven back in 2011 that honey bees will make more pessimistic decisions after being shaken in a way that simulates an attack by varroa destructor mites. The bees were trained to associate a reward of sugar-water with a particular odor and to associate foul-tasting punishment water with another odor—that of formic acid, a common treatment against varroa mites. When a third stimulus created by mixing the two odors was presented, the experimenters found that the aggravated bees were more likely to expect the bad odor. Sure enough, they kept their tongues in their mouths when they smelled the third odor. All the bees that weren’t shaken looked forward to sucking down a bit of sugar-water.

So, how does one judge a honey bee’s response? Whenever their antennae come in contact with something appetizing, they stick out their proboscis involuntarily to have a taste. This is called proboscis extension reflex (PER), and it’s the ingrained, day-one behavior that leads them to suck the nectar out of flower blossoms and regurgitate it to make honey.

[LJohann] is a behavioral biologist who wanted to test the effects of varroa mite treatment on bee-havior by itself, without agitating the bees. He built a testing apparatus to pump odors toward bees and judge their response which is shown in a few brief demo videos after the break. This device enables [LJohann] to restrain a bee, tantalize its antennae with sucrose, and pump a stimulus odor at its face on the cue of an LED and piezo buzzer. A fan mounted behind the bee helps clear the air of the previous scents. We especially like the use of a servo to swing the tube in and out of the bee’s face between tests.

[LJohann] and his colleagues concluded that the varroa mite treatment by itself does not make the bees pessimistic. This is great news for concerned apiarists who might be skeptical about using formic acid in the fight against the honey bee’s worst predator. Check out the brief demo videos after the break.

Hackaday has long been abuzz about bees whether they produce honey or not. We’ve covered many kinds of sweet projects like intelligent hives, remote hive weight monitoring, and man-made bee nest alternatives.


Filed under: Arduino Hacks

Sometimes we see projects whose name describes very well what is being achieved, without conveying the extra useful dimension they also deliver. So it is with [Prasanth KS]’s Windows PC Lock/Unlock Using RFID. On the face of it this is a project for unlocking a Windows PC, but when you sit down and read through it you discover a rather useful primer for complete RFID newbies on how to put together an RFID project. Even the target doesn’t do it justice, there is no reason why this couldn’t be used with any other of the popular PC operating systems besides Windows.

The project takes an MRFC-522 RFID module and explains how to interface it to an Arduino. In this case the Arduino in question is an Arduino Pro Micro chosen for its ability to be a USB host. The supplied code behaves as a keyboard, sending the keystroke sequence to the computer required to unlock it. The whole is mounted in what seems to be a 3D printed enclosure, and for ease of use the guts of the RFID tag have been mounted in a ring.

As we said above though, the point of this project stretches beyond a mere PC unlocker. Any straightforward RFID task could use this as a basis, and if USB is not a requirement then it could easily use a more run-of-the-mill Arduino. If you’re an RFID newbie, give it a read.

Plenty of RFID projects have made it here before, such as this door lock. And we’ve had another tag in a ring, too.


Filed under: Arduino Hacks, The Hackaday Prize

If you’re really serious about car racing games, at some point you may want to upgrade your instruments from being on-screen to physically residing in your living room.

While this would appear to be an arduous task, displaying your in-game boost level on a physical gauge is actually as easy as connecting a few wires to an Arduino Nano, then using SimHub to tie everything together.

As seen in the video below around 2:45, it looks like a lot of fun! While a boost gauge by itself might not be as immersive costly sit-inside racing sims, one could see where this type of hack could lead to ever more impressive DIY accessories.

If Dorothy from The Wizard of Oz were to wake up in 2017, with her magic Ruby Slippers on her feet, she’d probably believe she had woken up in a magical world. But modern folks will need a little more magic to impress them. Like Clicking your heels thrice to get home with these Uber ruby slippers. [Hannah Joshua] was tasked by her employer to build a quirky maker project. She got an idea when a friend complained about having trouble hailing a cab at the end of a hard day at work.

[Hannah] started with ruby colored slippers with a platform toe and high heels to allow space to stuff in all the magic dust, err, electronic bits. The initial plan was to use an Arduino with a GSM/GPS shield but that would have needed a separate SIM card and data plan for the shoes. Instead, she opted for the 1Sheeld which connects to a smart phone over Bluetooth. The 1Sheeld gets access to all of the smart phone’s sensors including the GPS as well as the data connection. The Arduino and 1Sheeld are put in a cavity carved out in the toe section. The 9 V battery goes inside another cavity in the heel, where an activation switch is also installed. Three LED’s indicate when the shoe is active, the cab request is accepted, and when the cab is on its way.

The code is basic since this one of her first Arduino projects, but it gets the job done. It sends an http request to Uber’s API to request a cab. The destination is hard-coded, so the slippers only allow you to get from your current location to whatever destination is programmed. The GitHub repository provides code, as well as some additional information on construction. [Hannah] has also added notes explaining some of the design choices and things to take care about if you plan to build one of these magic slippers.

We covered the 1Sheeld when it was introduced several years back, and if you get your hands on one, try building this Hand Waving Door Unlocker.

 


Filed under: Arduino Hacks


  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook