Posts | Comments

Planet Arduino

Archive for the ‘how-to’ Category

It is pretty well-known that I’m not a big fan of the Arduino infrastructure. Granted, these days you have more options with the pro IDE and Platform IO, for example. But the original IDE always gives me heartburn. I realized just how much heartburn the other day when I wanted to something very simple: increase the receive buffer on an ATmega32 serial port. The solution I arrived at might help you do some other things, so even if you don’t need that exact feature, you still might find it useful to see what I did.

Following this experience I am genuinely torn. On the one hand, I despise the lackluster editor for hiding too much detail from me and providing little in the way of useful tools. On the other hand, I was impressed with how extensible it was if you can dig out the details of how it works internally.

First, you might wonder why I use the IDE. The short answer is I don’t. But when you produce things for other people to use, you almost can’t ignore it. No matter how you craft your personal environment, the minute your code hits the Internet, someone will try to use it in the IDE. A while back I’d written about the $4 Z80 computer by [Just4Fun]. I rarely have time to build things I write about, but I really wanted to try this little computer. The parts sat partially assembled for a while and then a PCB came out for it. I got the PCB and — you guessed it — it sat some more, partially assembled. But I finally found time to finish it and had CP/M booted up.

The only problem was there were not many good options for transferring data back and forth to the PC. It looked like the best bet was to do Intel hex files and transfer them copy and paste across the terminal. I wanted better, and that sent me down a Saturday morning rabbit hole. What I ended up with is a way to make your own menus in the Arduino IDE to set compiler options based on the target hardware for the project. It’s a trick worth knowing as it will come in handy beyond this single problem.

The Issue: Arduino Serial Buffer Size Limit

I won’t bore you with the details about getting the board to work since you will only care if you have one. Details are available in a discussion on Hackaday.io, if you really want to follow it. But the upshot was that for XModem transfers, [Just4Fun] felt like the default Arduino serial buffer wasn’t big enough to be reliable. It did seem to work with the default 64-byte buffer, but XModem sends more data than that and it would be easy to imagine it getting overrun.

How hard can it be to update the buffer? In one way, it is trivial. In another way, it is very difficult because the tools want to help you so badly.

Tool Chain

The little computer project uses a real Z80 chip and uses an ATMega32A for almost all the support functions. It generates the clock, acts like a serial port, acts like a disk drive, and so on. However, the ATMega32 doesn’t directly have Arduino IDE support so you have to install a toolchain for it. The project called for MightyCore so that’s what I used.

The libraries for hardware serial were all set up using #define statements to allow you to adjust the buffer sizes. By default, if you haven’t set up anything, you get a default based on the amount of RAM your processor provides:


#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif

Making the Change

So this is easy, right? Just define those symbols before HardwareSerial.h loads. Uh oh. That file is loaded by Arduino.h. The IDE wants to add that to your program and it forces it to be first. There seems to be some IDE versions that check if you already included it so they don’t include it twice, but version 1.8.5 didn’t seem to do that. Maybe I can add some options in the preferences to pass to the compiler. Nope. Not via the IDE, anyway.

Not that I didn’t try a lot of things. It was tempting, of course, to simply change the core libraries. But that’s bad. You might want the defaults later. If you update the tool chain, you’ll lose your updates. I wanted to avoid that. Some people on the Internet suggested making a copy of the platform files and modifying those. Still not ideal.

Test Your Assumptions With Custom Error Reporting

I could tell things I tried were not working because I would put #if statements and #error statements temporarily in HardwareSerial.cpp. For example:

#if SERIAL_RX_BUFFER_SIZE==256
#error 256
#endif

Now if a compile causes an error 256, I know I was able to set the size. If not, then the system was resisting my changes.

Compromise: Adding Menu Options At the Board Level

I really wanted a way to make a change just in my project and set the serial buffer sizes. I failed at that. What I did do was make a modification to the boards.txt provided by Mighty Core. Yes, I will have to watch for upgrades overwriting my changes, but they are simple and it will be obvious that it is missing.

The reason it will be obvious is that I created a menu for the IDE that only appears when using ATMega32 for Mighty Core. This menu lets you select a few preset buffer sizes.

There were three parts to making this work:

  1. You have to tell the IDE you have a menu item and what it looks like.
  2. The new item needs to set some compiler options.
  3. Because the existing system also sets some compiler options, you have to make sure not to clobber them.

The first part is easy. The boards.txt file was (for me) in ~/.arduino15/packages/MightyCore/hardware/avr/2.0.5/boards.txt. Near the top there’s a list of menu keys and I added mine to the end:


# Menu options
menu.clock=Clock
menu.BOD=BOD
menu.LTO=Compiler LTO
menu.variant=Variant
menu.pinout=Pinout
menu.bootloader=Bootloader
menu.SerialBuf=Serial Port Buffers (RX/TX)

Next, I moved down the file and added my menu before the existing LTO menu option for the ATMega32:


32.menu.SerialBuf.disabled=Default
32.menu.SerialBuf.disabled.compilerSB.c.extra_flags=
32.menu.SerialBuf.disabled.compilerSB.cpp.extra_flags=

32.menu.SerialBuf.SB64=64/64
32.menu.SerialBuf.SB64.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=64 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB64.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=64 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB128=128/128
32.menu.SerialBuf.SB128.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=128
32.menu.SerialBuf.SB128.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=128

32.menu.SerialBuf.SB12864=128/64
32.menu.SerialBuf.SB12864.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB12864.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB256=256/256
32.menu.SerialBuf.SB256.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256
32.menu.SerialBuf.SB256.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256

32.menu.SerialBuf.SB25664=256/64
32.menu.SerialBuf.SB25664.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB25664.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB25632=256/32
32.menu.SerialBuf.SB25632.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=32
32.menu.SerialBuf.SB25632.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=32

Menu Structure

You can see that the 32.menu object groups all the items together for this processor. The next part is our menu key (SerialBuf). After that is a unique key for each memory item. It is important that you don’t reuse these. So, for example, if you have two SB64 keys only one is going to work.

If you stop at that key and put an equal sign you can assign the menu item the text you want to display. For example “Default” or “64/64.” You can also extend the key with a property and that property will be set if the option is active.

So, for example, if you select 256/256 then the compilerSB.c.extra_flags property will get set. I made that name up, by the way, and you’ll see why in a minute.

Peaceful Coexistence

There is no property called compilerSB.c.extra_flags. The correct property is compiler.c.extra_flags. However, the Mighty Core LTO option uses the same key. That’s why it was important that the new menu appears first and also that it sets a fake property. Then the LTO code needs a slight modification:


# Compiler link time optimization
32.menu.LTO.Os=LTO disabled
32.menu.LTO.Os.compiler.c.extra_flags={compilerSB.c.extra_flags}
32.menu.LTO.Os.compiler.c.elf.extra_flags=
32.menu.LTO.Os.compiler.cpp.extra_flags={compilerSB.cpp.extra_flags}
32.menu.LTO.Os.ltoarcmd=avr-ar

32.menu.LTO.Os_flto=LTO enabled
32.menu.LTO.Os_flto.compiler.c.extra_flags={compilerSB.c.extra_flags} -Wextra -flto -g
32.menu.LTO.Os_flto.compiler.c.elf.extra_flags=-w -flto -g
32.menu.LTO.Os_flto.compiler.cpp.extra_flags={compilerSB.cpp.extra_flags} -Wextra -flto -g
32.menu.LTO.Os_flto.ltoarcmd=avr-gcc-ar

The big change is that each set of flags adds to whatever the new menu set in its custom property. This way, all the flags get put into the correct property, compiler.c.extra_flags.

I set up error traps to catch all the cases to make sure they were being set right. In addition, after removing those traps, I could see my memory usage go up accordingly.

Customize

Of course, you can modify the parameters if you want something different. You could also use this trick to set other parameters before the Arduino.h file takes over. There’s some documentation about how to set up the platform definitions, including boards.txt.

It would have probably been better for me to make a custom boards.txt file with the same information in it but then I’d need to take the rest of Mighty Core with me. Instead, I just keep a copy of the file called boards.txt.custom and if my menu disappears, I just have to compare that file with the boards.txt file to see what changed.

Of course, if you don’t have to support people using the IDE, maybe just give it up. The Pro IDE is better, even if it does have some shortcomings. Plus there’s always Platform.io.

Laundry. It’s one of life’s inescapable cycles, but at least we have machines now. The downside of this innovation is that since we no longer monitor every step — the rock-beating, the river-rinsing, the line-hanging and -retrieving — the pain of laundry has evolved into the monotony of monitoring the robots’ work.

[Adam] shares his wash-bots with roommates, and they aren’t close enough to combine their lights and darks and turn it into a group activity. They needed an easy way to tell when the machines are done running, and whose stuff is even in there in the first place, so [Adam] built a laundry machine monitor that uses current sensing to detect when the machines are done running and sends a text to the appropriate person.

Each machine has a little Hall effect-sensing module that’s carefully zip-tied around its power cable. The signal from these three-wire boards goes high when the machine is running and low when it’s not. At the beginning of the load, the launderer simply presses their assigned button on the control box, and the ESP32 inside takes care of the rest.

Getting a text when your drawers are clean is about as private as it gets. Clean underwear, don’t care? Put it on a scrolling marquee.

Experience — or at least education — often makes a big difference to having a successful project. For example, if you didn’t think about it much, you might think it is simple to control the temperature of something that is heating. Just turn on the heater if it is cold and turn it off when you hit the right temperature, right? That is one approach — sometimes known as bang-bang — but you’ll find there a lot of issues with that approach. Best practice is to use a PID or Proportional/Integral/Derivative control. [Electronoob] has a good tutorial about how to pull this off with an Arduino. You can also see a video, below.

The demo uses a 3D printer hot end, a thermocouple, a MAX6675 that reads the thermocouple, and an Arduino. There’s also an LCD display and a FET to control the heater.

The idea behind a PID controller is that you measure the difference between the current temperature and the desired temperature known as the setpoint. The proportional gain tells you how much output occurs due to that difference. So if the setpoint is way off, the proportional term will generate a lot of output to the heater. If it is close, only a little bit of output will result. This helps prevent overshoot where the temperature goes too high and has to come back down.

The integral term adds a little bit to the output based on the cumulative error over time. The derivative term reacts to changes in the temperature difference. For example, if something external causes the temperature to drop suddenly, the derivative term can goose the output to compensate.

However, the operative word is “can.” Part of setting up a PID is finding the coefficients for each term which for some systems could be zero or even negative (indicating a reverse effect).  There are a lot of other subtleties, too, like what happens if the output stops affecting the temperature for a long period and the integral amount grows to unmanageable magnitude.

By the way, we’ve covered a PID library for Arduino before. While this post talks about temperature, PID control is used for everything from flight control to levitation.

[Dickel] always liked tracked vehicles. Taking inspiration from the ‘Peacemaker’ tracked vehicle in Mad Max: Fury Road, he replicated it as the Mad Mech. The vehicle is remote-controlled and the tank treads are partly from a VEX robotics tank tread kit. Control is via a DIY wireless controller using an Arduino and NRF24L01 modules. The vehicle itself uses an Arduino UNO with an L298N motor driver. Power is from three Li-Po cells.

The real artistic work is in the body. [Dickel] used a papercraft tool called Pepakura (non-free software, but this Blender plugin is an alternative free approach) for the design to make the body out of thin cardboard. The cardboard design was then modified to make it match the body of the Peacemaker as much as possible. It was coated in fiberglass for strength, then the rest of the work was done with body filler and sanding for a smooth finish. After a few more details and a good paint job, it was ready to roll.

There’s a lot of great effort that went into this build, and [Dickel] shows his work and process on his project page and in the videos embedded below. The first video shows the finished Mad Mech being taken for some test drives. The second is a montage showing key parts of the build process.

Paper and cardboard are very versatile and accessible materials for making things. It’s what was used to do some target practice with this working paper and cardboard gun. With the right techniques foam core can be worked into an astonishing variety of shapes, and we also made a case for the value of a desktop vinyl cutter on any well-equipped hacker’s workbench.

[Dickel] always liked tracked vehicles. Taking inspiration from the ‘Peacemaker’ tracked vehicle in Mad Max: Fury Road, he replicated it as the Mad Mech. The vehicle is remote-controlled and the tank treads are partly from a VEX robotics tank tread kit. Control is via a DIY wireless controller using an Arduino and NRF24L01 modules. The vehicle itself uses an Arduino UNO with an L298N motor driver. Power is from three Li-Po cells.

The real artistic work is in the body. [Dickel] used a papercraft tool called Pepakura (non-free software, but this Blender plugin is an alternative free approach) for the design to make the body out of thin cardboard. The cardboard design was then modified to make it match the body of the Peacemaker as much as possible. It was coated in fiberglass for strength, then the rest of the work was done with body filler and sanding for a smooth finish. After a few more details and a good paint job, it was ready to roll.

There’s a lot of great effort that went into this build, and [Dickel] shows his work and process on his project page and in the videos embedded below. The first video shows the finished Mad Mech being taken for some test drives. The second is a montage showing key parts of the build process.

Paper and cardboard are very versatile and accessible materials for making things. It’s what was used to do some target practice with this working paper and cardboard gun. With the right techniques foam core can be worked into an astonishing variety of shapes, and we also made a case for the value of a desktop vinyl cutter on any well-equipped hacker’s workbench.

A few months ago we showed you a bar bot built by [GreatScott] that uses peristaltic pumps to food-safely move the various spirits and mixers around behind the curtain. The bar bot uses three of them, and at $30 each for pumps with decent flow rate, they added a lot to the parts bill. These pumps are pretty much the ideal choice for a bar bot, so what do you do? [GreatScott] decided to see if it was worth it to make them instead.

Peristaltic pumps are simple devices that pump liquids without touching them. A motor turns a set of rollers that push a flexible tube against a wall. As the motor turns, the rollers move liquid through the tube by squeezing it flat from the outside in turns. Typically, the more you pay for an off-the-shelf peristaltic, the higher the flow rate.

[GreatScott] figured it was cheaper to buy the motor and the control circuitry. He chose a NEMA-17 for their reputation and ubiquity and a DRV8825 controller to go with it. The pump is driven by an Arduino Nano and a pot controls the RPM. After trying to design the mechanical assembly from scratch, he found [Ralf]’s pump model on Thingiverse and modified it to fit a NEMA-17.

The verdict? DIY all the way, assuming you can print the parts. [GreatScott] was trying to beat the purchased pumps’ flow rate of 100mL/minute and ended up with 200mL/minute from his DIY pump. Squeeze past the break for the build video and demonstration.

Is there a bar bot build on your list? No? Is it because you’re more of a single-malt scotch guy? Build a peristaltic pachyderm to pour your potion.

A delightful version of a clever one-dimensional game has been made by [Critters] which he calls TWANG! because the joystick is made from a spring doorstop with an accelerometer in the tip. The game itself is played out on an RGB LED strip. As a result, the game world, the player, goal, and enemies are all represented on a single line of LEDs.

How can a dungeon crawler game be represented in 1D, and how is this unusual game played? The goal is for the player (a green dot) to reach the goal (a blue dot) to advance to the next level. Making this more difficult are enemies (red dots) which move in different ways. The joystick is moved left or right to advance the player’s blue dot left or right, and the player can attack with a “twang” motion of the joystick, which eliminates nearby enemies. By playing with brightness and color, a surprising amount of gameplay can be jammed into a one-dimensional display!

Code for TWANG! is on github and models for 3D printing the physical pieces are on Thingiverse. The video (embedded below) focuses mainly on the development process, but does have the gameplay elements explained as well and demonstrates some slick animations and sharp feedback.

Using a spring doorstop as a controller is neat as heck as well as intuitive, but possibly not quite as intuitive as using an actual car as a video game controller.

One of the tasks I dread is configuring a web server to send email correctly via Gmail. The simplest way of sending emails is SMTP, and there are a number of scripts out there that provide a simple method to send mail that way with a minimum of configuration. There’s even PHP mail(), although it’s less than reliable.

Out of the box, Gmail requires OAUTH2 for authentication and to share user data, which has the major advantage of not requiring that you store your username and password in the application that requires access to your account. While they have an ‘allow less secure apps’ option that allows SMTP access for legacy products like Microsoft Outlook, it just doesn’t seem like the right way forward. Google documents how to interact with their API with OAUTH2, so why not just use that instead of putting my username and password in plaintext in a bunch of prototypes and test scripts?

Those are the thoughts that run through my head every time this comes up for a project, and each time I’ve somehow forgotten the steps to do it, also forgotten to write it down, and end up wasting quite a bit of time due to my own foolishness. As penance, I’ve decided to document the process and share it with all of you, and then also make it work on an ESP8266 board running the Arduino development environment.

Before we continue, now would be a good time for a non-technical refresher on how OAUTH works. The main differences between OAUTH and OAUTH2 are that the latter requires HTTPS, and the access tokens that allow an application to use specific services in a user account have an expiry.

To use Gmail with OAUTH2, we will need to start with five things: An application registered in the Google APIs, its client ID and client secret, a computer running LAMP (a by-the-hour VPS works just fine here), and a domain name that points to it.

Registering an application with Google API is easy. Go to the Google API console, log in, create a new project, and enter it. Enable the Gmail API; it should be suggested on the front page.

With the project created and the Gmail API enabled, the dashboard should look something like this

Then click on ‘credentials’ on the sidebar, create credentials, and finally ‘create OAUTH Client ID’. Before you can continue, you need to create a consent screen. The only entry you really need to fill out at this time is ‘Product Name Shown to Users’.

After saving that form, select ‘Web Application’ as your application type. Note the field called ‘Authorized redirect URIs’, we’ll return to it later. It’s important that it be correctly set for us to be able to receive a refresh token later on in this process.

For now, just press ‘Create’. A pop-up will display containing your Client ID and Client secret. You’ll need them soon, so best to copy/paste them into a local file on your computer for now.

Next, we will use those two pieces of data to request an access token and refresh token. We may as well accomplish two things at the same time here by installing the popular PHP email sender called PHPMailer on our web server. It includes a tool to request an OAUTH2 access/refresh token as well as being easily capable of sending a quick test email. To install it, we’ll use the Composer PHP dependency management tool:

$sudo apt-get install composer

Then we should navigate to our web-accessible directory, in my case /var/www/html, and install a few PHP scripts. Note that this should not be done as root, so create another user if needed and give them access to the directory:

$composer require phpmailer/phpmailer
$composer require league/oauth2-client
$composer require league/oauth2-google

Now enter the directory vendor/phpmailer/phpmailer. There will be a script called get_oauth_token.php. Move this script up three directories into the directory you just ran the ‘composer’ commands from. The location of this script as seen from the web needs to be entered into the ‘Authorized redirect URIs’ field of the Google API that we saw earlier. In this case it would have been https://mydomain.com/get_oauth_token.php. Public IP addresses will not work, this is why a domain name pointed to your web server is a requirement.

Now, open get_oauth_token.php in a text editor and paste in your Client ID and Client Secret where needed. Don’t try to run the script locally, it will fail. Open up a web browser on any computer, and navigate to the URL you entered as the ‘Authorized redirect URI’. Then select Google from the list of email services – at this point if it worked you will be asked to log in and then authorize the unverified application, under ‘Advanced’ under the warning prompt, at which point you will finally receive a refresh token. If you only want an access token for some reason you’ll have to edit the script to echo it back.

If that didn’t work, there are two common reasons: a wrong redirect URI or the script cannot find its dependencies. In the former case, the error message from Google will tell you the script URL as it sees it, and you can use that information to update the redirect URI in the Google API Console to fix the issue. For the latter, check your apache error log, probably located in /var/log/apache2/error.log, to see what dependency is not being found. You might see something like this:

PHP Warning: require(vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/mydomain/get_oauth_token.php on line 59, referer: http://mydomain.com/get_oauth_token.php

If you have received your refresh token, congratulations: the painful part is over. You can just go to the PHPMailer Github page and fill out their OAUTH2 example (gmail_xoauth.phps), and it ought to just work. If all you needed to do is send mail from a project on your VPS, you’re more or less ready to move on to more interesting parts of your project:

$email = 'someone@gmail.com';
$clientId = 'RANDOMCHARS-----duv1n2.apps.googleusercontent.com';
$clientSecret = 'RANDOMCHARS-----lGyjPcRtvP';
//Obtained by configuring and running get_oauth_token.php
//after setting up an app in Google Developer Console.
$refreshToken = 'RANDOMCHARS-----DWxgOvPT003r-yFUV49TQYag7_Aod7y0';

Remember to clean up any unnecessary scripts that contain your refresh token and other sensitive data before continuing.

ESP8266: We Don’t Need No Stinking Servers

Now what if we wanted to use these tokens to send email directly from project on a Raspberry Pi without needing a server in the middle? It turns out that once we have the client ID, client secret, and refresh token, we no longer require the server and domain name we’ve been using so far, and a mail-sending application, e.g. PHPMailer, can be installed on a computer anywhere with Internet access as long as it is configured with those values.

Things get a little more complicated when we try to do this on an ESP8266. OAUTH2 requires that we use SSL, and access tokens regularly expire and need to be refreshed. Thankfully, [jalmeroth] generously wrote a proof-of-concept and published it on GitHub. If provided with an access token, it can access your Gmail account and use it to send an email. It can also directly update/get data from Google Sheets, but I didn’t test this. However, if the access token was expired, it couldn’t detect that, although it did include working code to actually request a new token, but not parse it out and use it.

In an attempt to add to the functionality of that proof of concept, I forked the project and made a few changes. First, I changed to order of operations in the code to make it check if the current access token was valid before doing anything else. Second, Google API was responding ‘400 Bad Request’ if the access token was invalid, and everything but ‘200 OK’ responses were being filtered out by the code. Finally, I wrote a couple of JSON parsers that check the reason for the ‘400 Bad Request’ and extract and use the access token returned by Google API when a new one is requested.

It works, but it’s hardly reliable – not surprising considering I’ve never really used the Arduino platform before. Notably, the SHA1 fingerprint for Google API fails often. Checking from my local machine, the SHA1 fingerprint varies between two signatures there too. It would be fairly easy to check for either of them, or just keep trying, but I’d rather understand what’s going on first. (Is it just a CDN or something else?) Or perhaps I should rewrite the whole application in Lua where I’m more competent.

A fun little application built on the above was to place a button on my office that sends an email to my phone. I don’t want people to contact me at that email address frivolously, but do want to know immediately if someone is waiting outside my office. The big red button is for normal requests, but urgent requests require lockpicking. If it’s urgent it better also be interesting.

Finally, did you know that Hackaday provides an API for accessing hackaday.io? It uses the simpler OAUTH (not OAUTH2) authentication, so should be more straightforward than the above to implement on the ESP8266. Have any of you used it?


Filed under: Arduino Hacks, google hacks, how-to, Original Art

[Allan Schwartz] decided to document his experience using Fritzing to design, fabricate, and test a custom Arduino shield PCB, and his step-by-step documentation makes the workflow very clear. Anyone who is curious or has been looking for an opportunity to get started will find [Allan]’s process useful to follow. The PCB in question has two shift registers, eight LEDs, eight buttons, and fits onto an Arduino; it’s just complex enough to demonstrate useful design features and methods while remaining accessible.

[Allan] starts with a basic breadboard design, draws a schematic, prototypes the circuit, then designs the PCB and orders it online, followed by assembly and testing. [Allan] had previously taught himself to use Eagle and etched his own PCBs via the toner transfer method, but decided to use Fritzing instead this time around and found it helpful and easy to use.

About a year ago we saw Fritzing put through its paces for PCB design, and at the time found that it didn’t impress much from an engineering perspective. Regardless, as a hobbyist [Allan] found real value in using Fritzing for his project from beginning to end; he documented both the process and his observations in order to help others, and that’s wonderful.


Filed under: Arduino Hacks, how-to

What do you get when you put an ultra-bright LED in the palm of a glove, and strobe it controlled by an accelerometer? A Time Control Glove! In creator [MadGyver]’s own words, it’s “just a stroboscope with frequency adjustment” but the effect is where all the fun is.

The Time Control Glove uses the stroboscopic effect, which many of us have seen used in timeless water drop fountains where the strobe rate makes drops appear to change speed, freeze in place, and even change direction. [MadGyver] made the entire assembly portable by putting it into a glove. An on-board accelerometer toggles the strobe in response to a shake, and the frequency is changed by twisting the glove left or right. The immediate visual feedback to the physical motions is great. The whole effect is really striking on the video, which is embedded below.

Schematics and bill of materials are available on GitHub. Brilliant work! And while we’re discussing the stroboscopic effect, find out how it can be used to tune guitar strings.

[via Arduino Blog]


Filed under: Arduino Hacks, how-to, led 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