Posts | Comments

Planet Arduino

Archive for the ‘arduino hacks’ Category

Remember the Girl Tech IM-me? It was a hot-pink clearance rack toy that suddenly became one of the hottest commodities in the hacking world when it was discovered they could be used for all sorts of radio frequency shenanigans. Now they go for triple digits on eBay, if you can even find one. Well, we’re probably about to see the same thing happen to the Smart Response XE.

Thanks to the work of a hacker named [ea], this cheap educational gadget is finally starting to live up to the potential we saw in it back when a teardown revealed it was powered by an Arduino-compatible ATmega128RF chip. With a big screen, a decent QWERTY keyboard, and integrated wireless hardware, it seemed obvious that the Smart Response XE was poised to be the next must-have repurposed piece of kit.

Though as it turns out, [ea] isn’t using the device’s built-in wireless hardware. Step one in this exceptionally well documented and photographed project is to tack a CC1101 transceiver module to the SPI pins on the ATmega128RF. Then with the appropriate firmware loaded up, that nice big screen will show you what’s happening on the 300 MHz, 400 Mhz and 900 MHz bands.

But the fun doesn’t stop there. With the CC1101-modified Smart Response XE, there’s a whole new world of radio hacks you can pull off. As a proof of concept, [ea] has also included a POCSAG pager decoder. Granted the RTL-SDR has already made pulling pager messages out of the air pretty easy, but there’s something to be said for being able to do it on something so small and unassuming.

If you can’t tell, we’re exceptionally interested in seeing what the community can do with the Smart Response XE. At the time of this writing, the going rate on eBay for a good condition unit looks to be about $10 USD, plus the $3 or so for the CC1101 module. But the prices went through the roof when we first posted about it, so get them cheap while you still can.

[Thanks to bburky for the tip.]

While the Arduino has a very vocal fan club, there are always a few people less than thrilled with the ubiquitous ecosystem. While fans may just dismiss it as sour grapes, there are a few legitimate complaints you can fairly level at the stock setup. To address at least some of those concerns, Arduino is rolling out the Arduino Pro IDE and while it doesn’t completely address every shortcoming, it is worth a look and may grow to quiet down some of the other criticisms, given time.

For the record, we think the most meaningful critiques fall into three categories: 1) the primitive development environment, 2) the convoluted build system, and 3) the lack of debugging. Of course, there are third party answers for all of these problems, but now the Pro IDE at least answers the first one. As far as we can tell, the IDE hides the build process just like the original IDE. Debugging, though, will have to wait for a later build.

We were happy to see a few things with the new IDE. There’s some autocompletion support, Git is integrated, and there’s still our old friend the serial monitor. The system still uses the Arduino CLI, so that means there isn’t much danger of the development getting out of sync. The actual editor is Eclipse Theia. People typically either love Eclipse or hate it, however, it is at least a credible editor. However, Theia uses Electron which makes many people unhappy because Electron applications typically eat a lot of resources. We’ll have to see how taxing using the new Pro IDE is on typical systems with normal workloads.

On the future feature list is our number one pick: debugging. They are also promising support for new languages, third party plugins, and synchronization with the Web-based editor. All good features.

This is just an alpha preview release, but it is a great start. Our only question is will existing users really care? Most people already write code in another editor. Many use an external build system like PlatformIO. Eclipse already has a plug in for Arduino that supports debugging with the right hardware. So while new users may appreciate the features, advanced users may be wondering why this is so late to the party.


Sometimes debugging just doesn’t go the way you want it to. When USB problems arise, you can usually use a protocol analyzer to find the issue causing trouble. For [Paul Stoffregen], it was only the first step in a long process to find the culprit.

Procotol Analyzer

The complaint that came up was from a customer whose 2 port USB hub wasn’t working on their Teensy 3.6. The hub had been tested on Linux, Mac, and Windows, so it made sense to test what was different about the Teensy. Furthermore, all other USB hubs worked on the Teensy. As it turns out, these weren’t the most helpful assumptions to make when finding the bug.

Any protocol analyzer can be used, for instance the Beagle480. The way it works is by passing through USB communication, making a copy of the communication coming in and out, and sending it to the PC.


Normally, the analyzer has a small buffer memory and must sustain fast data flow. Unfortunately, this can occasionally cause software lockup. From what could be gathered from the verbose printing, USB descriptors were found for the hub. As it turns out, the faulty hub was a Multi-TT type hub, while most others are single TT (transaction translator).

Fixing Software Lockup

Since it was necessary to get the rest of the descriptor data, fixing the software lockup was the next step. Writing in a panic function – a breakpoint of sorts – into the code allowed the USB host’s power to terminate, and stepping through the program revealed that while the 2 port hub was initially being read, some issue arose afterwards.

As it turns out, the issue relied on USB split transactions, used only between USB hosts and hubs. Communication happens by tokens, which begins with a SPLIT-START token.


As it turns out, the issue was that the tokens weren’t being sent in the correct order. The other hubs seemed to be handle this nevertheless. By applying a fix to the C++ code of the bad hub, which had previously not been implementing the data structure for accessing register properly, the hub was able to work again.The hub appeared to be rejecting bad token, which was causing the issue in the first place.

All in all, while I’m sure this had to be a head scratching experience, at least it gives us some insight into the low-level design of USB communication.

All the cool projects now can connect to a computer or phone for control, right? But it is a pain to create an app to run on different platforms to talk to your project. [Kevin Darrah] says no and shows how you can use Google Chrome to do the dirty work. He takes a garden-variety Arduino and a cheap Bluetooth interface board and then controls it from Chrome. You can see the video below.

The HM-10 board is cheap and could connect to nearly anything. The control application uses Processing, which is the software the Arduino system derives from. So how do you get to Chrome from Processing? Easy. The p5.js library allows Processing to work from within Chrome. There’s also a Bluetooth BLE library for P5.

Once you know about those libraries, you can probably figure the rest out. But [Kevin] shows a nice example that you could easily replicate. The Arduino and Bluetooth code aren’t very hard to follow.  The Processing program looks a lot like an Arduino program with a setup and loop function, but it also has canvases, buttons, and other things you don’t usually have in an Arduino.

It is surprisingly easy to create a Chrome app that talks to the hardware. Our usual go to for phone apps is Blynk. We even used it as a joystick for a robot.

In the distant past, engineers used exotic devices to measure orientation, such as large mechanical gyros and mercury tilt switches. These are all still useful methods, but for many applications MEMS motions devices have become the gold standard. When [g199] set out to build their Balance Box game, it was no exception.

The game consists of a plastic box, upon which a spirit level is fitted, along with a series of LEDs. The aim of the game is to keep the box level while carrying it to a set goal. Inside, an Arduino Uno monitors the output of a MPU 6050, a combined accelerometer and gyroscope chip. If the Arduino detects the box is tilting, it warns the user with the LEDs. Tilt it too far, and a life is lost. When all three lives are gone, the game is over.

It’s a cheap and simple build that would have been inordinately more expensive only 10 to 20 years ago. It goes to show the applications enabled by ubiquitous cheap electronics like MEMS sensors. The technology has other fun applications, too – for example the Stecchino game, or this giant balance board joystick. We’re certainly lucky to have such powerful technology at our fingertips!

Light painting has long graced the portfolios of long-exposure photographers, but high resolution isn’t usually possible when you’re light painting with human subjects.

This weekend project from [Timmo] uses an ESP8266-based microcontroller and an addressable WS2812-based LED strip to paint words or custom images in thin air. It’s actually based on the Pixelstick, a tool used by professional photographers for setting up animations and photorealism shots. The equipment needed for setting up the light painting sticks runs in the order of hundreds, not to mention the professional camera and lenses needed. Nevertheless, it’s a huge step up from waving around a flashlight with your friends.

The LED Lightpainter takes the Pixelstick a few notches lower for amateur photographers and hobbyists. It directly supports 24-bit BMP, with no conversion needed. Images are stored internally in Flash memory and are uploaded through a web interface. The settings for the number of LEDs, time for the image row, and STA/AP-mode for wireless connections are also set by the web interface. The project uses the Adafruit NeoPixel, ArduinoJson, and Bodmer’s TFT_HX8357 libraries for implementing the BMP drawing code, which also allows for an image preview prior to uploading the code to the microcontroller. Images are drawn from the bottom row to the top, so images have to be transformed before updating to the LED painter.

Some future improvements planned for the project include TFT/OLED support, rainbow or color gradient patterns in the LEDs, and accelerometer or gyroscope support for supporting animation.

There aren’t currently too many galleries of DIY LED-enabled light paintings, but we’d love to see some custom modded light painting approaches in the future.

This isn’t the first LED light stick we’ve seen, if you’re interested in such things.

This servo/gear reduction was assembled with almost all 3D-printed parts. Apart from a brushed 36 V DC-motor, a stainless steel shaft, and screws for holding the servo together, the only other non-printed part is the BTS7960B motor driver.

Some interesting stats about the plastic servo – its stall torque is about 55 kg/cm, reaching a peak current draw of 18 A when using a 6s LiPo battery outputting 22-24 V. The shaft rotates using two 20 mm holes and lubrication. (Ball bearings were originally in the design, but they didn’t arrive on time for the assembly.)

The holes of the gears are 6.2 mm in diameter in order to fit around the shaft, although some care is taken to sand or fill the opening depending on the quality of the 3D print.

This isn’t [Brian Brocken]’s only attempt at 3D-printing gears. He’s also built several crawling robots, a turntable, and a wind up car made entirely from acrylic. The .stl files for the project are all available online for anyone looking to make their own 3D-printed servo gears.

Just two weeks ago, the crew from the International Space Station released a photo of their nine crew members – an odd number considering that the facility only has space to house six astronauts at a time. In fact, the crew had just gathered for a celebratory dinner before three of the astronauts were to return home. The new astronauts joining including Hazza Al Mansouri, the first astronaut from the United Arab Emirates (who has since returned from his mission), as well as astronaut Jessica Meir and cosmonaut Oleg Skripochka.

Amidst the excitement over the upcoming 10 (!) spacewalks in the next three months, there’s also been some cool developments in the open source space, with one of the first ESP32s launched into space.

[Nico Maas] from the Microgravity User Support Center (MUSC) at DLR (German Aerospace Center) worked on an experiment launched by MORABA (Mobile Rocket Base) at DLR. The launch site was at the Esrange Space Center in Kiruna, Sweden, with the mission launching on June 13, 2019 at 4:21 am local time.

The experiment – APEX (Advanced Processors, Encryption, and Security Experiment) was onboard the ATEK / MAPHEUS-8, mission, rising to an altitude of 240km into space and returning back to earth after six minutes of microgravity.

[via AIP]
The goal of the research was to develop an off-the-shelf computer with a more powerful system for high-speed sensors and image acquisition than the Microchip ATmega328P, the current standard. The flight test measured the speed of the system as well as stress testing its ability to handle compute-intensive tests.

The main board included two ESP32s and a Raspberry Pi Zero W, running resinOS / balenaOS, an operating system designed to run parallel Docker containers and optimized for IoT fleet management.

Prior to the experiment, the standard for on-board computers for use in CubeSats was the ATmega/Arduino-based ARDUSAT. Since it was first made available for use in CubeSats in 2013, the performance has become limited, with improvements needed to perform higher throughput data sampling or operations requiring more computational power.

It’s also cool to note that the system, built using a 3D-printed holder, survived the re-entry (reaching up to 20.6g) with hardly a scratch.

While we certainly do love the Arduino Nano for its low-cost and versatility in projects, it’s unarguable that every tools has its gripes. For one maker in particular, there were enough complaints to merit a redesign of the entire board. While Arduino may or may not be interested in incorporating these changes into a redesign of the development board, there is certainly room for a new manufacturer to step in and improve some features.

[Kevin Timmerman] takes a look at lower-cost clones of the Nano made in China to highlight a few interesting key differences that make the clones – cheaper but still compatible with legacy systems – more attractive.

The PCB manufacturing for the Arduino Nano currently places components on both sides of the board, requiring two operations for solder paste, pick-and-place, and reflow. Naturally this increases costs, simply designing a two-layer PCB with components on top lowers the price of manufacturing.

Since the ATmega328PB was released, it has proven to be a better and cheaper MCU for manufacturing than the ATmega328P, the current MCU used by the Arduino Nano and clones. While the newer MCU is not backwards compatible like its predecessor, it has additional UART, GPIO, counters, and other features that allow users to take advantage of new libraries and peripherals.

Rather than featuring the typical voltage regulator used by Arduino boards (used to allow the board to be powered by a voltage source greater than 5V), a switching regulator allows for less energy loss but a higher component cost. A better solution than both of these would be to simply not have a voltage regulator. While this may be controversial, there are sufficient battery power sources for this design to work (4 cells of AA or AAA NiMh batteries or a mobile phone charger).

The Arduino Nano uses a bootloader for handling programming the MCU, which requires the USB to serial bridge to be disconnected from anything that could interfere with the programming. Thus, programs using the COM port on the computer must release the port, including the serial monitor. Rather than using the bootloader, ICSP (in-circuit serial programming) and DebugWire are possible alternatives that connect the ICSP pins to the CH551 development board or programming via the reset pin.

There are a number of other spec and firmware improvements suggested in the writeup, as well as comparison between the Arduino Nano, Arduino Every, and Chinese clones. It’s definitely worth a look!

Fans of D&D are surely aware of the significance of a good pair of dice. What if your dice were not only stylish, but smart? For anyone who’s ever had to deal with playing board games with less than reputable siblings or friends, the electric die just might be your savior.

The dice are configured via Bluetooth, tracking rolls and stats over the course of gameplay captured by an accelerometer.

The PCB had to have a flexible surface – specifically in the shape of an unfolded icosahedron – in order to form the shape of the die which constrains the design to two layers. Each face contains an LED facing outwards to light up the number on that side. The LEDs are directly powered by a rechargeable battery, which uses a small coil for wireless inductive charging. Rather than opting for a Qi charger chipset, which regulates the maximum amount of power transmitted if the efficiency falls below a threshold, [Jean Simonet] uses a simpler charger setup using a full bridge rectifier, capacitors, and a linear regulator to create a stable 5V supply for the receiving end.

While the initial design for the die required an injection molded plastic shell, an easier solution was to simply cast the designs in resin. The electronics are placed into a dice mold and cast just as a regular die would be.

This luckily also solved the issue of needing to fit the components inside a screw-on container with a removable lid, which presented a hassle in terms of finding a battery that would fit the dimensions. The LEDs – purchased for cheap on Alibaba – are daisy chained to reduce the complexity of the routing.

One issue with the LEDs, however, is that the internal PWMs modulating the intensity remain on even at an intensity of 0, constantly drawing 21 mA (for the 21 LEDs on the die). This causes the battery to die after 2-3 hours. The solution [Simonet] used was to add a transistor to cut off power to the LEDs and to have the MCU toggle the transistor when the LEDs are turned off. Even this solution didn’t solve the entire problem since the LEDs still drain current from the data and clock lines, so those lines had to be low before going to sleep.

There were some stability issues with using a small buck converter to bring the LiPo voltage down to 3.3V, so the power regulation was done directly by the MCU instead. Switching the die off is controlled by a magnetic switch connected to a power buck converter that turns off logic when a magnet is present. This initially caused the LED control lines to become floating when power was turned off, turning the LEDs to arbitrary colors. The solution was to wire the output of the magnetic sensor to the MCU and to allow the software to handle the LEDs as well.

Maybe it’s because creator [Simonet] happens to be a game developer as well, but the early development stages of the electronic die (CAD, circuit schematics, prototyping, hand soldering components) were streamed on Twitch, adding some interactivity to even the build phase. The end result may be small, but these dice certainly have large brains!

  • 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