Saturday, September 23, 2017

How Fast? Test how fast you are!

How fast? is a project I made for the 2017 Jerusalem Mini Maker Faire.It consists of four different tests:

The Drum Test

Use the sticks to drum as fast as possible. The faster the drumming is, the higher the green bar goes.

The Swipe Test

Swipe your hand (any direction) above the tester as fast as you can. The faster you move your hand, the higher the green bar goes.

The Chase Test

Press the two buttons one after another. The order does not matter, but the first button pressed must be released before the other button is pressed. The faster you hit the buttons, the higher the green bar goes.

The Response Test

Hit the button as fast as you can immediately after the light on the board turns on. The faster your response time to that light, the higher the green bas goes.


All the games share a common overall construction.
The base is made from a piece of thick (~25mm) chipboard, about the size of 30x30cm. In the back side of the board, I milled a rectangular hole, holding a 3D printed ABS box. The box contains an Adafruit Trinket board on which the game software is implemented. 

Beside this common structure, each base board was drilled to milled with features required for each particular test. 
The chase test was the simplest with only two holes for two buttons. I used arcade style buttons which are both robust and give a nice feeling of a game.
The response test is also simple, with a drilled through hole for a button, a drilled through hole for a LED, and a few millimeter deep circular hole that is used to hold a LED cover. The cover was 3D printed from translucence ABS.
The swipe test posed a problem. In order to detect the hand proximity, I used a pair of optical proximity sensors, mounted on a tiny PCB. Unfortunately, the PCB does not have any mounting holes. In order to mount them, I designed and printed mounting accessories, which held the sensor in place while permitting it to be screwed to the base board.

The drum test is made of a round rubber pad (which actually came from an electronic drum system) to which an Adafruit accelerometer sensor board is attached. Interestingly, the hole in the rubber pad in which the board resides looks very much like Adafruit's logo... Finally, the rubber pad was glued to the base board.

All four games are connected to a "Result Bar" - a bar graph showing the result. The design is identical to all four games - a 1M long piece of foam board, to which a common WS2812 LED strip is attached. The bottom area of the board, where the strip is terminated, is covered with another small piece, to hide the solder points. The connection between the two units (the game and the result bar) is made with a Servo Extension Cable, that has exactly three conductors, as requires, and is cheap and easily available.

Full mechanical models can be found on the project's document at OnShape.


The circuits here are quite trivial. As mentioned earlier, I used Adafruit Trinket board. I chose the 5V version, because it easily interfaces the LED strip (WS2812 LEDs) used to show the results.
Trinket is a tiny board, with very few I/O pins available . Pin #1 is used in all circuits to drive the LED strip. Two additional pins are used differently for each specific test for the buttons, LEDs, proximity sensors and accelerometer.

Swipe Test Schematic

Chase Test Schematic

Drum Test Schematic

Response Test Schematic


Overall, the software used in this project is quite simple. The only two pieces of hardware that require software libraries are the WS2812 LEDs and the LIS3DH accelerometer. Both libraries are available in Arduino ecosystem, so chosing that path is very convenient.
Instead of writing directly in the Aruduino IDE, I used PlatformIO. This environment solves two major drawbacks that exist in the original Arduino environment - the IDE and dependency management. 
The IDE used by PlatformIO is Atom, GitHub's extensible text editor. While not being my favorite editor, it is much better than Arduino's editor, with full directory management, GIT interface, code completion and everything else that one would expect from a modern programmer's text editor.
The library dependency management is solved by a kind of manifest file, called platformio.ini that  exists in any PlatformIO project. This file specifies, among others, the libraries required to compile the project. The builder fetches those libraries and with other pieces of information in that file (such as the location of the source files), builds any specified target automatically.
The only serious drawback I found was the fact that the builder does not print, or keep track of the final file size. With Trinket, I've accidentally overwritten the bootloader. This situation is not irreversible, but causes major inconvenience.

The full source code is available in the project's GitHub repository.

Thursday, November 24, 2016

Update to the Arduino TM1637 Module

A few years ago, I've written a small Arduino module to drive displays based on the TM1637 chip. The module has gained some popularity and I got a lot of requests to add some means to control the decimal point segments (which actually connects to a colon in most display modules). So, here it is. Version 1.1.0 of the library is available on GitHub, and includes some minor fixes (mostly spelling) as well.

Thursday, April 21, 2016

Getting Started with RedBearLab's Wifi Micro and CCS

Recently, I've been playing around with RedBearLab's Wifi Micro board. Essentiallu, it's a TI CC3200MOD with some bare minimum components required to make it work, all mounted on a small PCB with conveniently .100" spaced pins.

RedBearLab recommends Energia as a coding environment for that board. Energia is TI's spin-off of the Arduino IDE. Arduino lovers will feel at home, with one-click-to-run and the huge Arduino ecosystem. On the other hand, the IDE is quite limiting for power users - with inefficient multi-file support, lack of modern IDE features like code completion and lack of control of the compilation process. One additional problem is that the chip is pre-configured in a certain manner that may not suit all applications. For example, the pin mapping is fixed and cannot be changed.

Luckily, TI also provides Code Composer Studio - a full-blown, Eclipse based IDE that can be used to develop software for the CC3200, as well as other TI processors. Here's a step-by-step tutorial on how to set things up to get started with the development quickly and easily.

Step 1: Installation

In order to develop for the CC3200, several tools and packages have to be downloaded and installed:
  • Code Composer Studio - When installing, make sure that all CC3200 stuff is marked for installation, including TI ARM compiler
  • CC3200 SDK
  • Uniflash (optional, but highly recommended, see below)
All the above tools are available both for Windows and Linux. One small exception is the CC3200 SDK, where only a Windows package is available. The solution is to install the package on a Windows machine and copy the whole directory tree to the Linux machine (see also here).
Two more recommendations - install everything in the default location (c:\ti), it will save a lot of time configuring search paths; on Linux - install the software locally, not as root.

Step 2: Importing the base project

I have created a boilerplate project that includes some very basic facilities that are required to get started with CC3200  programming. The project can be found on GitHub. In order to use it, the first step is to import it into CCS. This can be easily accomplished using the built-in git support. First, select "Import ..." from the file menu. Then, select "Projects from Git" and "Clone URI" at the next screen. At the URI input box in the next screen, type the repository's URI:, select the (only) master branch, the local working directory, and finally check the project name.

Step 3: Building the project

If all the tools were set up correctly, building the project is a matter of clicking the "build" button. The relevant result of the project is the bin file <Proj. Name>.bin (in our case - RBL_CC3200_BASE.bin).
The project can be built either in Debug or Release configurations. Unless your'e using a JTAG adapter for debugging, the Debug configuration is useless, and should not be used. To change the active configuration, right click on the project name, select "Build Configurations", "Set Active" and then select the appropriate one.

Step 4: Programming

The CC3200 module contains a bootloader that enables programming using only a serial port (logic level USB to serial adapter), similar to the way Arduinos are programmed. The hardware I'm using is a small board that comes with RedBearLab's WiFi Micro Kit, but I think (not verified) that a regular USB-to-Serial will be sufficient.
There are two possible ways to program the device:

  • cc3200prog - This little program can be found in the Energia distribution (in hardware/tools/lm4f/bin). It is invoked from command line in the following way:
    cc3200prog <PORT> <BIN> h
    Note the "h" at the end of command line - without it the process fails! PORT is the COM port number in windows or the complete path to the tty device on Linux (for example /dev/ttyUSB0). BIN is the binary filename, generated in the previous step. This program is easy to use and works great, but from my experience it has a log of bugs. For example, it crashes when the binary filename includes underscores or spaces, and sometimes it just crashes in the middle of the process with no apparent reason. This instability plagues both the Windows and the Linux versions.

  • Uniflash - Uniflash is a tool provided by TI. It has both a GUI and a CLI. It is much more flexible than cc3200prog - it can access and program not only the program image, but also auxiliary files that can be accessed later from the CC3200 firmware and are very handy for board-specific configuration. The downside of Uniflash is that it does not reset the board after it finishes its task - it has to be manually reset using the physical button. It's also not completely free of bugs as well - sometimes the programming task becomes very slow and goes on for a few minutes (instead of a few seconds) - but it's relatively rare.

After experiencing both methods above I would recommend using Uniflash for its stability and flexibility.

Understanding and Extending the base project

The base project is very minimal. It includes a console facility which can print messages to the serial port. The console is buffered and interrupt based, so it can be used freely without causing large unexpected delays in the program execution.
The pinmux is identical to the one provided in the WiFi Micro product documentation, but it can be change easily using TI's online pinmux utility, or its local version. The base project includes a CC3200.pinmux file which can be used as a base file and modified according to one's requirements.
The base project does not include any WiFi capability - TI provides a large collection of examples that are relatively easy to understand, copy and modify

Thursday, January 1, 2015

Numato Mega New Year Give Away

Again that time of the year has come. Christmas is here, New Year 2015 is around the corner. And one more reason to be happy, this is the time Numato hosts the largest give away of the year. That is right! We hosted our 2014 Christmas/New Year give away during December 2013/ January 2014 time and we saw overwhelming response from our readers. We gave away random gifts to every single person participated in the event, 250+ electronics enthusiasts. We hope that everyone who received the gifts put it to good use and learned something from it. 


Read all about it here

Tuesday, September 23, 2014

Is Edison a [Something] killer?

No, it's probably not.
Ever since the Edison broke into our lives, people keep comparing it to boards from the makers world - like Raspberry Pi and even to Arduino. I think it's a total miscomprehension of what this module is and what is its purpose.
Edison is not primarily targeted at makers. It is targeted at IoT manufacturers with medium-high manufacturing volume, that need some real computation power, which even high end microcontrollers can't offer, along with some serious connectivity.

Intel® Edison (Source)
Intel chose to introduce the module through the makers community, partnering with major names in this area such as Sparkfun. This is a tactical marketing move, and an obvious question arises - why? I can think of two reasons. The first one is that Intel truly believe that this is where innovation comes from. The second is that Intel does not want to lose another market segment to ARM, as it did with mobile platforms (cellular, tablets etc.), understanding that future engineers may prefer familiar technologies from their making days. On the way, it's trying to fix its absence from this small, but very loud market.
The true competition to the Edison will not come from Pi nor from Arduino - it will come, once again, from ARM with ultra-cheap, connectivity-centric modules such as HE and HLK-RM04. While not providing half as much computation power offered by Edison, they do allow both makers and manufacturers to enable product connectivity easily and on-the-cheap.

Saturday, July 26, 2014


ASTROGUN is an Asteroid shooting game I developed along with Maayan Dreamer for the Jerusalem Mini Maker Faire (the link is in Hebrew), held in June 2014.
 The game is pretty simple - the player stands and has to shoot Asteroids that are coming towards him from any direction, before they hit him. A RADAR-like view helps the player locate the Asteroids around him.
The most interesting thing is the display system.  We build a HUD - heads up display - which is a display that shows an image overlaid on the background.

Check out how it looks like in the video below:

How it Works

In the heart of the Astrogun lies a Raspberry Pi computer. An IMU card connected to it (Sparkfun's MPU-9150 breakout board) providing it with the ability to sense the orientation the unit's orientation. Having this information, the Pi is able to draw the various elements (Asteroids, bullets, explosions), as seen from that specific angle. When the player moves, the graphics move ayour'ccordingly, giving the "object in the room" sense.

The display system comprises of two main elements: an LCD panel and a beamsplitter glass (also known as Teleprompter glass). This glass has a unique feature - it is both transmissive (like a window) and reflective (like a mirror). The player, looking through the glass sees both the image behind the glass and the image projected from the LCD.
Anyone who is familiar with basic optics will immediately notice that I'm a little bit cheating here. The system lacks one important component - a collimation lens. In real HUD systems, this lens projects the imager image to infinity, creating an illusion that the graphics is in fact "on" the object the user is looking at. In our case, the short development time hindered us from complex optical structures. Nevertheless, the experience of object-in-the-room is still there, to some degree.

As for the software, the game is not very computationally demanding (set aside the graphics rendering process, which is handled by the GPU). The development time, on the other hand, was definitely demanding. Therefore, Python was a natural choice. I used the excellent Pi3D library to create the graphics, while the rest of the game logic is written in pure Python. In order to determine the orientation, I used the RTIMULib library, which reads the sensors and fusions its data into orientation angles (I also contributed a Python binding module for that library, which was written for this project). Sound effects are played using the PyGame library.

Finally, the mechanics. Most of the electronics (RPi, IMU, power supplies and a few more) were fitted nicely within the body of a toy gun, which was sourced from a local toy store. The display system, which comprises the LCD, its controller and the beamsplitter glass are held in position by a glass epoxy structure which positions them in the location and angle required (the glass and the LCD must be positioned in a 45 degree angle, otherwise the image will be distorted). The Raspberry Pi is connected to the controller using an HDMI cable. The trigger of the gun had an electric contact for its original purpose (flashing LEDs and making noise), and it was re-routed to one of the GPIO pins.

Source Code

All the source code of the project is available through GitHub. Unfortunately, the mechanical structure is ad-hoc and not documented.

Thursday, March 6, 2014

Arduino library for TM1637 Display Module

Update: A new version has been released, includes control of the colon/decimal points.

I needed a small numerical display for a project I'm working on. I found this one on Dealextream. It looks great - a 4 digit module, with a driver and a serial interface - perfect match for my requirements. The product page mentioned that it is driven by a chip called TM1637. A quick search at Google lead me to an Arduino library, made by SeeedStudio that is capable of communicating with the module.

Three weeks later, I have the module at hand. I'm connecting it to an Arduino board, installing the library and uploading one of the example files. Nothing. Total blackness. On the hardware side, with only two digital pins, it's pretty hard to mess things up, so the suspicion falls on the software. The next step is trying to get the datasheet of the TM1637. The chip is made by a company called Titan Microelectronics, which holds a product page for it. Sadly, the link to the datasheet is broken. Searching again, filtering all the "" etc., I find this datasheet, in plain Chinese. With the help of Google Translate, and SeeedStudio's library, the communication protocol gets revealed. The chip uses the I2C protocol, and the sequence required to write display data is as follows (ST - start condition; SP - stop condition):

  • ST - COMM1 (0x40) - SP
  • ST - COMM2 (0xC0) + the first digit to be written
  • digit1 - digit2 - ... - digit4 - SP
  • ST - COMM3 (0x80) + the display brightness - SP

Having all that at hand, I wrote a new library, implementing this protocol. The library is available at GITHUB, including a sample sketch demonstrating its capabilities. The repository also includes a README file explaining how the library should be used and how the module should be connected to the Arduino.

Why did SeeedStudio's library fail?

Browsing through SeeedStudio's code, I found two problems that might cause it to malfunction.
The first one is this:

  digitalWrite(Clkpin,LOW); //wait for the ACK  

The digital output pins are bit-banged to create the I2C signal, but there's no delay. This gives a toggling rate much beyond the specified 400KHz. It's possible that Seeed were testing their module with an 8MHz Arduino, while my module was 16MHz, raising the toggle rate even further away from the specification.

The second problem also arises from the code snippet above. I2C is wired-and bus, meaning it should never be driven high.When a logic '1' is desirable, the output of the Arduino should be put in high-impedance state allowing the pull-up resistor to pull the line to its high level. This is unlikely to cause an immediate problem, but in the long term it may cause the reliability of the components to degrade.