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 "datasheet.com" 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.

Monday, January 6, 2014

Using an Android phone as a secure OpenVPN Gateway

I'm running a small OpenVPN setup at home, through which I can connect to my home network from various places securely and safely. I really like OpenVPN. It's robust, safe and fairly easy to set up. There is only one small caveat - it is not a standard VPN client in Windows. In order to use it, an OpenVPN client is required. Such client exists, of course, and it's can be downloaded and installed on any computer. There are occasions, though, that downloading and installing software is either impossible or inappropriate. For example, using a company provided notebook computer or a friend's computer.
One way to overcome this limitation is to use of an Android smartphone as a VPN gateway. The phone runs OpenVPN and has access to the private network. The client computer is tethered to the phone and set up in such way that access to the private network addresses from the PC is routed through the phone and forwarded over the secure tunnel. This is the ideal solution - the computer doesn't have to know anything about OpenVPN, no software has to be installed and no key has to be deployed. The only tweak required - sometimes - on the PC side is adding an entry to the routing table. In Windows 7 it seems that it can even be done without administrative privileges.
In order for this setup to work, some tweak are required on the phone side. The remaining of this post explains more about it.


First of all - a rooted Android phone. Mine is a Samsung Galaxy S-II (also known as GT-I9100) with CyanogenMod ROM. I've never tested this procedure on any other phone, but I'm sure it will work on most of them.
The second requirement is a working OpenVPN setup. I won't get into the details of this setup, there are plenty of tutorials on the Internet. When OpenVPN works computer-to-computer, it's very easy to migrate it to the phone - just install the OpenVPN client from Google Play, put the configuration files on an SD card and let OpenVPN on the phone know where the files are.


We will use the iptables utility to instruct the phone to forward IP traffic through the secure tunnel. For the sake of the discussion, let me assume that the private network is on the subnet.

The first step is instructing the phone to forward packets to/from the secure tunnel (tun0) and Masquerade them:

iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE     

These commands can be entered directly using a phone terminal software (such as the one installed by default when installing CyanogenMod on the phone), or better using an SSH server such as this one.

The second step is to enable packet forwarding from the interface tethered to the PC. There are multiple options here, and it may be necessary to detect which of the network interfaces is use for which purpose. This can easily be done with the netcfg command on the phone. Run it once, without the tethering and the once again with the tethering activated. The network interface that was used for this purpose should go from DOWN to UP state, and an address should appear. In my phone, the interfaces are wlan0, rndis0 and bt_pan for WLAN, USB and Bluetooth tethering respectively.
And now back to the iptables command:

iptables -I FORWARD -o rndis0 -j ACCEPT 
iptables -I FORWARD -i rndis0 -j ACCEPT

(replacing rndis0 with the appropriate interface name).

Finally, we have to tweak the routing table on the PC to redirect the traffic of the private network to the right place. This step is not always required - if the PC's only network connection is the phone, this will happen naturally.
For all other cases, a new route is required. The routing table on Windows is managed using the route utility. First, open a command line window. In Windows 8, it must be run as an administrator. Now, we'll have to identify the network interface used for the tethering:
route print

This command prints the routing table, but in this stage we're only interested in the header of the result, the one listing the network interfaces on the computer:

In the case of Bluetooth tethering the first interface in the example is the one being used. In the case of WLAN tethering we'll select the wireless LAN adapter (not shown) and in the case of USB tethering it is shown as USB to Ethernet adapter. The first number in each line is the interface number.
Now, the route is created as follows:

route add /p mask route if 23

This address is the address of the private network; the address is the phone's address (on the tethering interface, obtained with ipconfig) and the number 23 is the network interface number as demonstrated above. The /p switch makes the route permanent, meaning that we won't have to touch the routing table every time the phone is connected.

That's it! Now, you should be able to access the private network from the PC.

Just one additional note: to make the changes permanent on the phone side (that is, they will be available after the phone is being reset), create a file called userinit.sh in /data/local and put all the iptable commands  in it. For example:


# Add iptables rules for forwarding packets from tethered interface
# to OpenVPN connection
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

# For USB
iptables -I FORWARD -o rndis0 -j ACCEPT
iptables -I FORWARD -i rndis0 -j ACCEPT

# For Bluetooth
iptables -I FORWARD -o bt-pan -j ACCEPT
iptables -I FORWARD -i bt-pan -j ACCEPT

# For WLAN
iptables -I FORWARD -o wlan0 -j ACCEPT
iptables -I FORWARD -i wlan0 -j ACCEPT