Data Encryption and Decryption System using 74XX Logic Gates

This project won the first place in 7400 Competition by Dangerous Prototypes

Electronics Mail

Encryption and decryption plays a vital role in today’s digital world. So we thought of implementing an encrypting and decrypting device using only 74xx logic chips. The encryption algorithm is based on cellular automaton. Rule 30 of the cellular automaton produces can be used as a random number generator. A cellular automaton is basically an array containing 1s and 0s whose next value depends on the previous value of the array based on a particular rule. You can read more about cellular automaton here.

Here we take an 8-bit array. The initial state of the array will be stored in a parallel-load parallel-out register. The next state of the register is also stored in a parallel-load parallel-out register. The next state is derived from the initial state. So between the registers, we have the logic section that implements the rule. Since this is an iterative process, there will be…

View original post 693 more words



I have attached a video and a picture – a single player pong game and a two player version. The two games are written in Processing. I didn’t find a way to convert it into an exe package. So, to run it you must have Processing installed in your PC. The entire code is available at


It is fun to play your own game. But after sometime I started having a few ideas. What if the path the ball traces is made visible. The answer to that is that the screen will be white pretty soon and you won’t be able to play. But what if the path of the ball had nice colors like red, green and blue? What would it look like? I tried it out and here is what I got.




What I did was to change the ball color every time it hit the paddle and also more importantly made the colors translucent. Opaque colors would be very boring.


I recently got this sensor ADXL345, a digital accelerometer. I immediately set out on doing something with this sensor, simple yet not pointless.

The first thing to do is to read the accelerometer values. The sensor supports I2C and SPI. I decided to go with SPI. On reading the sensor values, I classify the sensor reading into three different categories. Sensor pointing along the X, Y or the Z axis. Once this is done, the microcontroller sends either 1, 2 or 3 to the serial port of the PC. On the PC a Processing code is running which receives the value from the serial port. Depending on the received value, the orientation of a cuboid is varied such that the orientation of the cuboid is same as the sensor.

The code running on the Arduino and the Processing code are both available on my GitHub repo.




The image looks interesting right? So how did I do it? Pretty easy! Just use three light sources – red, green and blue. Wrong! This is done using a slightly more sophisticated procedure. I took three images with different lighting conditions. Then I wrote a MATLAB script to extract the red channel from the first image, green channel from the second image and blue channel from the third image. Combine these three and you get wonderful effects.

Green Chennal
Green Chennal
Blue Channel
Blue Channel
Red Channel
Red Channel
Combined Image
Combined Image

The first set of photos here are taken with a table lamp which does not give a focused beam. Switch on the light, take picture, change light position and so on.

Blue Channel
Blue Channel
Green Channel
Green Channel
Red Channel
Red Channel
Combined Image
Combined Image

The second set of pictures are taken using the same table lamp but with a convex lens in front of it. So I get a somewhat focused beam and clearly it has a more impressive effect.

The MATLAB code for this is available on GitHub. I feel comfortable using the GUI builder in MATLAB for dialog boxes. For these, I have uploaded the ‘.m’ files on GitHub but I am yet to find a way to upload the ‘.fig’ files. Apologies for that.

Image Converters

From the title you can see that I have written a converter for images. But what does it convert? To what? The title says ‘converters’. So does it imply more than one converter? To get answers for all these, read ahead.

The first program converts a ‘.bin’ file to a ‘.bmp’ file. You might ask me why I have written it. What is the use of such a converter? Well, if you have worked with image sensors you will realize that it’s a very handy program. The output of an image sensor is in hex values, called as raw data. Most sensors allow some kind of formatting such as RGB565 and some even provide JPEG output. But raw data is something that is available from all sensors. Let’s say we are using an image sensor with a micro-controller. Once the data is captured by the sensor, it sends this data to the micro-controller and this data has to be stored. Once stored, you want to view the image; most likely on your computer. Will Picasa open this file? Sadly, it won’t. Because the file is not in any recognized format. It’s just a huge collection of hex data and any image viewing software cannot make sense out of it.

The hex data has to be converted into some format that can be recognized by image viewing software. This is where BMP fits in. BMP is a very simple format created by Microsoft. The bitmap file consists of two main sections: the header and the data.

This can be broken into four sections as follows


  • File Header
  • Confirms that the file is a BMP file
  • File size
  • Exact location of the image data


  • Image Header
  • Number of rows and columns in the image
  • Number of bits per pixel
  • Type of compression used


  • Color Table
    • Provides the (optional) bit masks for bit depths of 16 and 32
    • Not used for 24-bit images


  • Pixel Data
    • Pixel by pixel color information
    • Row by row bottom to up
    • Each row is column by column, left to right


All multibyte values are stored in Little Endian format. This means that the bytes within the value are stored starting with the least significant byte first and the most significant byte last.



Color Table

When dealing with 16-bit or 32-bit images, then the Color Table contains a set of bit masks used to define which bits in the pixel data to associate with each color. The color masks are 32-bits long with the green mask being first and the blue mask being last. In both cases the bit masks start with the most significant bits, meaning that for the 16-bit images the least significant two bytes are zero. The format requires that the bits in each mask be contiguous and that the masks be non-overlapping.


Pixel Data

The pixel data is organized in rows from bottom to top and, within each row, from left to right. Each row is called a “scan line”. In case of a 16-bit format, each pixel is represented by two bytes. A common representation is RGB555 which allocates 5 bits to each color allowing for 32K colors while leaving one bit unused. Since the eye is most sensitive to green, another common representation is RGB565 which allocates this unused bit to the green component.


To convert our hex values to an image, all we need to do here, is to add a header to the hex data. The file is now a ‘.bmp’ file and you can view it in your computer. As you can imagine, the program is pretty simple. It works for only images of size 320×240 and for any other size, lower or higher, the header has to be suitably modified. I forgot to mention one important thing. The converter I have written is for RGB565 hex data. If you attempt to use this program for uncompressed RGB888 hex data, you will not get a proper image. Again to make it work for RGB888 is single change in the header.


Now for the second converter. Now this finds a jpeg image in a long list of messy data. When I wrote the above program, I was working with sensors which gave uncompressed outputs. When I moved to sensors with compressed outputs, the above program wasn’t sufficient. So I set out to write a converter for jpeg images.

The most popular compression technique is probably the JPEG standard. Now I will not be explaining about the JPEG standard here. But the one important thing to know is that a jpeg image always begins with ‘FF D8’ and ends with ‘FF D9’. This makes writing this converter extremely simple. All I have to do is find ‘FF D8’. This is where the image begins. Then I have to find ‘FF D9’. This is where the image ends. All the data outside of this we are not bothered with.

Let me give a little background here. A lot of sensors provide jpeg output. But there is usually extra stuff with it, like response sequences to various commands. These extra data can either be eliminated before saving the image data or you can save the entire thing and eliminate the extra sequences later. I did the latter and hence this program.