GameBox Using Arduino

Individual Project

Synopsis:

Surfing across the internet, as I am usually found to be, I came across an article to develop your own Retro Gamebox, by APC Magazine (But I have modified the design a bit, to suit to my requirements). Well, it shouldn’t be difficult to guess, what might have happened next? I went scavenging for the parts, and then spent the next day assembling and running the Gamebox. Well and then there were a lot of days of playing on that console.

Although implementing this project itself wasn’t challenging, what was interesting was to understand the interface between the Arduino and the Television both from a hardware and software end. And the excitement increased manifolds as this was my first project on working with graphics on an embedded platform.

Note: None of the games were designed by me.

Video: Demo of the Gamebox

Technical Description:

The components used in this Retro Gamebox are as follows:

  • Four-way digital switch or 2 Four-way potentiometers
  • Push Switch
  • RCA Port and Cable for video and mono audio
  • Arduino UNO R3
  • Television capable of RCA interface and running NTSC/PAL
  • Male and Female Connecting cables

The circuit diagram for connecting these components is as shown:

Retro Gamebox Circuit Diagram1

Fig: This is the updated circuit diagram for my design

Although the APC Magazine mentions using an arcade joystick which is essentially a combination of four digital switches which provide direction and movement control. But I am currently using four way potentiometer switches instead. (The kind of arcade joystick mentioned on APC magazine was not available in local markets, and I was willing to experiment with these). These work exactly in the same way as the arcade joystick, and provide the possibility of gameplay where variable speed may be required (But some tweaking would be required). The center position of these potentiometer is kept below the threshold level, so that the Arduino does not pick up false signals. Although two switches are required, one for up and left, and the second for right and down. (And trust me the gameplay doesn’t get affected a lot)

Note: The two potentiometric switches could be replaced by a single one, using analog input pins of Arduino and tweaking input control section of the code. I shall upload the schematics and the updated code library for the same. The two extreme values of the analog input could act as the two opposite direction digital inputs.

Coming to the analog video and audio hardware. The Arduino essentially generates the analog video data and the synchronization pulses on its D9 and D7 pins, which are then combined into a single composite signal via resistors and finally connected to an RCA port. The audio is generated by the Arduino using 8-bit PWM pulses on its D11 pin and are passed on to another RCA port.

These signals from the RCA port can be connected to any TV running NTSC. I had an NTSC running television, but for those having PAL based television you will have to connect the D12 pin of the Arduino to ground.

This is how my final system looked like:

This is the Final Designed Project

Fig: This is the final designed project

The games and the software required to run the device were built for the Nootropic Design Hackvision board, but work well with this system. While most of the software which pertained to taking inputs from the switches was fairly simple and easy to implement for anyone with an intermediate experience on Arduino, the parts that caught my interest were the games and the TVout Library of Arduino that connected this system to the Television.

I haven’t worked on building games (But this is something, that I am willing to try my hand at, when an opportunity arrives), I tried doing a thorough study of the TVout Library and am writing some details of the same here.

The library is built up of functions that are bundled up into intuitive categories. A short description of these functional categories is as follows:

  1. Setup Functions
    • These functions are responsible for sending the output on the screens at specified resolution and also to set the number of times, time and the line to output the data
  2. Flow Control Functions
    • These are essentially two functions that provide delay in units of ms or frames
  3. Accessor Functions
    • This is a set of three functions that usually access data related to resolution and the number of characters that can fit on a line
  4. Basic Graphics Functions
    • These are a set of functions that let you draw graphics on screen. Pixel draw, basic shapes, lines, and bitmaps can be outputted on the screen using these functions
  5. Text Handling Functions
    • These functions provide you with print functionality for characters, string. Also it helps you set preselected font style or custom fonts and the cursor position
  6. Audio Handling Functions
    • These functions help you set audio tones by setting the frequency and duration of the tone

Note: The code and other details for this project are available on the APC Magazine page for this project.

If you have any questions regarding the hardware or the implementation please do feel free to contact me via the form below.

Object Recognition using Correlation

Individual Project

Synopsis:

While taking a course on Discrete Time Signals and Systems at college, I completed the following project as a part of the curriculum. In this project an image is taken and a template is cropped out of it. Then correlation is performed using Fourier transform and the locations where the templates match has a higher pixel value. Then we define a threshold which is used to separate these high pixel value locations from the rest of the image and thus we get locations of the template on the image.

This technique of character recognition has some drawbacks though. The most prominent of them being, that the template image must be a near match to the objects in the image. Thus when parsing documents for handwritten text, this technique does not give the required results (I have tried this, and it failed to give a reliable result). The second drawback being that the threshold although can be taken as a value just lower than the maximum pixel value. But this usually has to be set by the programmer as the automated procedure doesn’t always gives the desired result. The problem also multiplies when you move from black and white images to color images.

This project was designed in MATLAB R2011b. I have attached the codes and results of the same at the end of this post.

Technical Description:

The Fourier transform can also be used to perform correlation. Following are the steps while matching a template to the image using the above said procedure.

  1. Read in the sample image.
  2. Create a template for matching by extracting it from the image. You can also create the template image by using the interactive version of imcrop.
  3. Compute the correlation of the template image with the original image by rotating the template image by 180oand then using the FFT-based convolution technique. To match the template to the image, use the fft2and ifft2 functions. This technique was described on a forum on MathWorks and greatly helped in understanding the functions.

C = real(ifft2(fft2(bw) .* fft2(rot90(a,2),256,256)));

  1. To view the locations of the template in the image, find the maximum pixel value and then define a threshold value that is less than this maximum. The locations of these peaks are indicated by the white spots in the thresholded correlation image.

Here is a link to the zip folder containing the MATLAB files and images I had used in this project. Project 1. Project 2.

EasyBraille

Team Members:

Malhar Chaudhari, Siddharth Agrawal

Synopsis:

What began as a simple idea to explore, has now turned into a passion to bring that idea to perfection (not that we claim it is perfect, but yes certainly better than our last attempt). This idea for bringing the vast expanse of electronic text to the visually impaired in an e-braille format began with the Kindle for the Blind, and has now taken another shape based on a unique way to display the characters. EasyBraille was result of relentless pursuit to achieve a drastic reduction is size and cost, making it portable and within affordable reach of the average braille user. Making the device easy to use, has been another core area of interest in development.

Now coming to the unique innovation we spoke about:

Based on our interaction with braille trainers and some braille readers, we realized that instead of having multiple characters and the user scrolling his fingers over them, we have a single character which would scroll the characters beneath the forefinger to display text. Now we know that many advanced braille readers, use both their hands and about three fingers to read braille text. But usually the less dominant hand is used to locate the next line (which is redundant in a refreshable braille display as most displays are single line displays) and the second and the third finger, of the three fingers used, are predominantly used to maintain pace, while the first one does the reading. Thus keeping these insights in mind, we have designed the following prototype.

What is the impact of this innovation?

Affordability

Today majority of the braille readers cost in the range of $ 3,000 – $ 15,000, largely limiting their access to common braille users. With our single character display, we believe EasyBraille to cost around INR (symbol) 7,000 or roughly aroud $100 making it more affordable and more accessible to the braille readers across the spectrum without having to compromise on quality or ease of access.

Portability

Replacing the hardware required to support a multi-character display by a single character display greatly reduces the size of the device. Thus the average braille user can easily carry it with him anywhere and use it at his convenience making it more portable and lasting a longer duration than many of the existing products.

EasyBraille 3D Model

Fig: 3D Depiction of EasyBraille

Some of the distinguishing features of EasyBraille are:

  • Extensive Support for all types of E-book formats
  • Flash Drive based E-book storage
  • Portable, light weight, battery powered (rechargeable)
  • Completely VOICE GUIDED NAVIGATION (Personal Digital Assistant, with natural language processing)
  • Audio Playback also available
  • Add and remember Bookmarks
  • Variable Adjustable Reading Speed
  • Playback from particular chapter in a book, or last reading point
  • Auto refreshable braille display with touch sensor to judge reader presence
  • Affordable and more accessible than any available solution in market

EasyBraille is powered by the Raspberry Pi Model 2. R-Pi was chosen primarily because of its capability to provide extensive support for most of our features. Voice Navigation, audio notification and playback has been implemented using the Jasper Personal Assistant on the Raspberry Pi. An open source e-book reader with wide support for different formats is being considered for reading the e-books. Another important feature of EasyBraille is the speed, at which the characters are read from the device, can be configured by the user as per his preference. Moreover as soon as the user removes contact of his finger with the display, the capacitive sensor would get deactivated and the text would stop scrolling. This would let the user continue from where he left, even if he is interrupted due to any task. This feature helps to maintain continuity for the readers.

The most important part of the device, the refreshable display, is implemented using mini solenoids, instead of fabricating or using custom made solutions, to achieve high performance and keep the costs low. Factors like refresh time, size, weight and cost were taken into consideration while choosing this solution. The required assembly for this part of the device is being currently 3D modeled, and subsequently will be given for printing.

Although the design is under development, we are sure that we would be coming out with our first prototype in the next two months. We are eager to test our first prototype with braille readers and know the response.

Also we are currently using EasyBraille as an e-book reader, but are not oblivious to the fact that it has a large potential to act as a personal assistant to the visually impaired, greatly bridging the digital divide and are designing it in such a way that we are able to leverage that potential without much adjustments required at the user end.

And lastly and the most important part, we plan to release all the schematics, STL files, and the code written as a part of the process to the open source community. This would enable us to leverage the enthusiasm and skill set of members of the open source community in order to improve the product iteratively and enable us to help the visually impaired more efficiently and effectively without worrying much about licensing and other hassles. We will share the link for the same in due time.

You can download a small presentation HERE which gives a synopsis of the complete idea.

Front End VLSI Design of 16 Bit Processor

Group Members:

Malhar Chaudhari, Akshay Mote, Suhit Pai, Mayuresh Mhase, Aishwarya Natarajan, Shweta Shetty

Synopsis:

The front-end design of this processor was undertaken as a part of the capstone project for the VLSI front end design course, I had enrolled in from August – October 2013 (Not a part of college curriculum)

The five stages of Pipelined processor are:

  • Instruction fetch stage
  • Decoding stage
  • Execution stage
  • Memory stage
  • Write-back stage

The various instructions that the Processor should execute are as below:

  • Addition
  • Subtraction
  • Increment
  • Decrement
  • AND/NAND
  • OR/NOR
  • XOR/XNOR
  • Shift Left/Right
  • Buffer/Negate
  • Multiplication (8-bit, higher-higher bytes or lower-lower bytes)
  • LOAD from Memory
  • STORE to Memory
  • MOV (move data between GPRs as well as immediate data) (16-bit, 8-bit higher/lower byte)
  • JUMP (unconditional forward jump, incrementing Program counter by specified jump value)
  • NOP (no operation, disallowing write operations)
  • EDP (end of program, disabling of Program counter)

All instructions related to Arithmetic and Logical Unit are capable of carrying out both 16 bit and 8 bit (options for choosing lower or higher byte) operations. A total of 47 Instructions were found to be executable on this processor.

This processor was designed using the Xilinx ISE. The memory units were taken from the inbuilt libraries, and the rest of the processor components were written in Verilog.

We also understand that some specific instructions if executed one after the other could result in yielding absurd results. On account of that, we will need to implement a Hazard aversion Scheme for the Processor.

Technical Specification:

The following is the list of components in the processor that were designed in verilog:

  • Instruction Memory: A 256X16 bit memory is used as the instruction memory with input as 8 bit instruction address and 16 bit instruction.
  • REG file: An 8X16 bit register file has 3 bit addresses of two sources, address of destination, 16 bit destination, 2 reconfiguration bits, 2 write enable bits and clock as input. It also has two 16 bit sources as the output.
  • Control unit: The control unit is designed as per the opcodes decided for the instructions.
  • ALU: The ALU is designed as per the ALU control logic decided by Control unit.
  • Memory unit: An 8X16 bit data memory unit is already provided to store the data.
  • Buffers: Since, it is 5 stage pipeline, we use the buffers for the 5 stages. Buffers are nothing but flip-flops giving out data held by them at the positive clock edge.

The 16 Bit Instruction Format is as follows:

Opcode

Fig: 16 Bit Instruction Format

Datapath Design:

Initially, we designed the data paths for individual instructions. We found that Datapaths for most of the Arithmetic and logical instructions were same. It turned out that most of the Instructions have similar Datapaths. In all, hardly 4-5 Datapaths were required to be made. Later, we merged these Datapaths to a single datapath for all the instructions.

Implementation:

Final Datapath

Fig: Final Datapath of the designed Processor

The components that we have used in this datapath are as follows:

Stage 1:

Buffer0: Buffer0 is a component of Program counter (PC) loop. It holds the Program counter value until next positive edge of clock. It acts as a pointer to desired instruction in instruction memory.

Instruction memory (256X16): Instruction memory stores the set of Instructions to be executed.

MUX and adder combinational logic for updating PC: The PC loop needs to be modified for EDP and JUMP instructions. The PC needs to stop or execute dummy cycles upon receiving EDP instruction and for JUMP instruction it needs to increment by specified count. For that we have included an additional Adder in the loop which is responsible for handling the Program count if JUMP is encountered. We have also taken care of JUMP 0 hazard here itself by using a combinational logic which upon coming across JUMP 0 i.e. recursion, breaks the recursive loop and continues by incrementing the Program counter by 1. This increment by 1 shows that JUMP 0 had occurred but was ignored. For EDP instruction we keep checking for the occurrence of the Opcode of EDP and then clear the Buffer0 subsequently disallowing the PC operation. Note that the program counter does not completely terminate its operations.

Buffer1: This buffer is responsible for forwarding the 16-bit Instruction to the next stage upon receiving a positive edge of clock pulse.

Stage 2:

Register file (8X16): Register file has 8 general purpose registers out of which register with address 000 is special as it holds the value received from MVI instruction. The Register file can output 16-bit as well as 8-bit data. Actually the 8-bit data is 16-bit data only but with appropriate byte masked. The reconfig bits are active low and decide whether 16-bit or 8-bit data (higher or lower byte) is to be given at output. The write enable bits are also active low and decide whether the data to be written is 16-bit or 8-bit (higher or lower byte). The data to be written and address of GPR is also received by the Register file.

Control unit: The control unit issues commands in response to received Instruction. It provides the signal to ALU to select desired operation. It also provides ctrl bit output which is used to distinguish between two operations with same Opcode. It also provides sel[1:0] which is used as select line for MUX in write-back stage. The Register write enable (regwren) output acts as write enable bits to Regfile. The memory read/write output is used to issue a command for reading/writing to the memory. We have taken up one additional one bit shift output which instructs the Shifting block in logical unit of ALU to perform either left shift or right shift.

Hazard unit: This unit consists of a 3 stage pipeline. It stores the received Instruction word and pushes it along pipeline. Pipelining makes available to us the source address, destination and Opcode of upto 3 instructions. We use if-else ladder to detect various hazards. Depending upon hazard, respective select line outputs are given out by this unit. These outputs act as Select line inputs to two MUXes in execution stage i.e. at input of both ALU inputs and to a MUX in memory stage.

Hazard Unit

Fig: Hazard Unit Component Design

The list of hazards detected by Hazard unit:

  • ADD ADD
  • ADD X ADD
  • LOAD ADD
  • LOAD X ADD
  • ADD STORE
  • ADD X STORE
  • LOAD MOV
  • MOV STORE
  • LOAD STORE
  • MVIH MVIL MOV

Black Box: Black box extracts the 8-bit data provided in the Instruction word in case of MVI instruction. It also takes care to place data in higher byte or lower byte in case of MVIH or MVIL respectively. It also issues address to the Regfile to make available data at specified address. Blackbox includes a 16-bit 2:1 MUX which has the 8-bit immediate data (with other byte as 0, so in total 16-bit data) as one input and Regfile extracted data as another, depending upon the received instruction appropriate MUX input is selected.

Buffer2: The outputs of Control unit, Hazard unit and Register file are passed on to next stage at positive clock edge.

Stage 3

ALU: The ALU is designed to perform Addition, Subtraction, Multiplication, Increment, Decrement, Logical operations (AND/NAND, OR/NOR, XOR/XNOR) and shift. It also deals with buffer and negate operation. Here’s the block diagram for ALU implementation.

ADD, SUB, INC and DEC share a common adder/subtractor. Input A is always fixed. Input B of Adder/Subtractor can be ALU input B or a hardwired 1. ALU input B is used for ADD/SUB (A+B/A-B) operations and hardwired 1 is used for INC/DEC (A+1/A-1) operations. This explains the second input selection logic shown above.

Logical operations include AND, OR, XOR and shift. All logical operations are performed but only the desired output is selected using a 4:1 MUX. For generating NAND, NOR, XOR ctrl bit is used as select line for a 2:1 MUX shown above to select the proper output (buffered or negated). An additional shift input is present where shift [3] gives direction of shift and shift [2:0] gives amount of shift.

Multiplication block is used to perform 8-bit multiplication. The byte selection logic is used to choose appropriate byte from each input and only that is passed on to the multiplier .We are passing either both lower bytes or higher bytes, higher/lower bytes and lower/higher bytes cases are not included. It would have been possible to do so using byte selection logic.

Direct data (Input A of ALU) is passed to execute buffer instruction or negate instruction.

Input selection logic for ALU inputs: Input selection logic for ALU inputs consists of one MUX each for both ALU inputs. It works to ensure proper input is received by ALU in case of a hazard. These MUXes receive select line input from Hazard unit.

Buffer3: The outputs of ALU, immediate data of MVI, data to be stored in Memory and some control logic outputs are passed on to next stage at the positive clock edge.

Stage 4:

Data Memory (8X16): It is used to store a maximum of 8 16-bit words. It receives data input from MUX logic to select appropriate input with view of avoiding hazards. It receives read/write input from control unit.

Buffer4: This buffer forwards the ALU outputs, data read from memory, immediate 8-bit data upon receiving positive clock edge.

Stage 5:

MUX logic for write-back input selection: This MUX is needed to select proper data to be selected for write-back. It receives the select line input from control logic unit. These select line values also pass from buffer2, buffer3 and buffer4. It selects which of the three data is to be outputted- data read from memory, ALU output or direct data (immediate).

MUX logic for write-back address selection: The special of MVI invokes the need of this MUX. The MVI instruction necessitates that the immediate data be written into register with address 000 in Register file. This condition is taken care of using this MUX. For rest of the operations, desired address is directly passed

Conclusion:

The Processor design was a challenging job in terms of Area and Speed optimization as well as Hazard aversion. There are still more hazards which have a dependency similar to ADD ADD hazard or even ADD X ADD hazard. These hazards can be surely avoided upon further detailed implementation of hazard unit. We also figured out some Instructions that could have been added like XCHG i.e. interchanging lower and higher bytes of a word by inserting a 2:1 MUX in the direct data line where both direct data and byte reversed data would have been available. The functionality of Multiplication Instruction can also be further enhanced to perform multiplication of higher and lower or lower and higher bytes of two words.

I know you might wonder, where is the Verilog code I mentioned about? If you want to know the complete details of my implementation, do drop me a mail on malharchaudhari@gmail.com

Innovative Approach to Location Based Services

Team Members:

Malhar Chaudhari, Sarvesh Patkar, Virag Doshi, Moumita Dey

Synopsis:

Innovative Approach to Location based services and Traffic Management System, is an alternative to the Global Positioning System (GPS), which provides navigation services as well as traffic regulation, which in turn would prove to be a massive help to the traffic controlling authorities. This project was designed keeping in mind the shortcomings of GPS, and by incorporating some additional features, such as, positioning and navigation using offline maps, and vehicle tracking, makes it a multipurpose standalone device.

Video : Project Demo

Video: On Field Demo

Some of the limitations of GPS that have been explored in this project are:

  • The first limitation with GPS is the process of locating the satellites, receiving the data and achieving a position fix, which can take several minutes. This delay is problematic for many critical applications, especially during driving if there is a break in link due to poor signal. Our project uses the durable on ground RF beacons which gives highly reliable service and faster speed of response.
  • Another problem with GPS is that the receiver needs a clear view of the sky to successfully receive signals from the satellites. Thus the GPS would fail in navigating in cities having large skyscrapers. This is not the case with the RF beacons used in this project which can have a strong signal at distances of tens of feet’s with obstacles between the receiver and beacon.
  • Civilian GPS signal is limited by low accuracy in identifying position. This limited accuracy can be a problem in navigating in urban areas. Our project can be used in such areas requiring high accuracy and can give current location within 10 -15 feet accuracy.

The project also has an emergency service feature which routes the driver to the nearest hospital and also sends an emergency SMS with the vehicle’s location details to the paramedics. This is a feature currently not available integrated with vehicular navigation system. This device has been designed with the aim of making implementation of various additional services easier.

Technical Description:

 

RF Positioning System-Top Level Block Diagram

Fig: Block diagram of the system

Our project uses a network of Radio Frequency based beacons to form the navigation system’s backbone architecture. The user can find the route to a particular location from his current location which is also plotted on the map. Another feature of the project is to dynamically update this route in case the user takes a wrong turn. The device is equipped with a GSM module which can be used to send an SMS to the nearest hospital in case of an emergency, either requested by the user himself, or from the feedback from the emergency vehicle sensors. This same module can be used for tracking down a device, with a simple command sent to the receiver module from the user’s phone. This feature is of particular importance to traffic authorities to also track down vehicles in case of theft. Although the device currently uses a GSM module to achieve this functionality, it can be further extended to use the backbone network consisting of RF beacons to achieve this functionality. The project is currently in prototype stage to which more features can be added.

This system is completely within the control of the concerned law and order authority which allows it to build various customizations in the system as well as have data security features.

The main components of this system are:

  1. Backbone Network Architecture of RF Beacons These beacons would provide the location ID to identify the current location. Also other real time data as required by the application and the particular traffic regulation data would be provided by them.
  2. Receiver Device: This device would be fitted in the car, and would contain a RF receiver to communicate with the beacons. It also has a LCD display to display the maps which are stored in a mass storage device (SD card). The LCD used in the display also has a touchscreen which makes interacting with the GUI easier. The device is equipped with a GSM Module to communicate with the external world.

Applications:

Towards the end of this project, we realised the true potential of this project lied more in the following type of applications:

  • Navigation in closed spaces, like campus, big malls other such spaces featuring closed spaces and tight navigation limitations, our system could present a higher resolution navigation support. Moreover the device could be replaced with a smart phone connected to an inexpensive RF receiver, which would help users in navigation. This system could be a boon to deaf-blind users.
  • Positioning, Navigation and Emergency Assistance for National Park Trails
  • Emergency Service Assistance, Positioning and Navigation for Mines
  • Positioning Services for Public Transport Buses

Kindle for the Blind

Team Members:

Malhar Chaudhari, Sarvesh Patkar, Virag Doshi, Tushar Advani, Suchitra Sundararaman, Akshay Gharge, Moumita Dey, Vinayak Joshi

Synopsis:

This project aims at building a portable, light weight and low power device that converts the large ocean of e-knowledge into Braille format. It is a revolutionary upgrade to the current electronic Braille display devices which are not portable. It has an easy to use audio user interface for basic operations, like searching from a library of E-Books. Also, it provides a comprehensive set of audio notifications for informing the user. The device is connected to a USB Mass Storage Device loaded with E-Books whose text can be converted to standard Braille format and displayed on a Refreshable Braille Display. This device will increase literature access to the visually impaired through the development of a portable, hand-held Braille E-Book Reader. Please note that the current version of the project does not have a refreshable braille display due to some fabrication limitations.

You can follow my new design EasyBraille, which uses a unique innovation, in the way characters are displayed from the device.

For more details:

Why is “kindle for the blind” a pressing need?

  • The number of Braille printed books is very less
  • Even if they are available, the Braille version is quite larger than the normal book
  • The cost of blind education is very high, due to requirement of special aids and professionals
  • Refreshable Braille Display cost around 2000-3000 USD often requiring additional computing hardware

This leads to an overall reduced literacy rate for the visually impaired and subsequent lower standards of living around the world. This project was motivated by the fact that, all categories of visually impaired people should have equal access and opportunity to education.

While designing these products it was equally necessary to keep in mind that we don’t just design another refreshable braille display, but a product that addressed majority of the issues discussed above.

Thus the most major features of this product are:

  • Capable of Independent Operation without any external hardware or human help achieved with the help of audio navigation and smart search
  • Capable of reading multiple books in widely available digital text formats stored in an external flash drive
  • Low power battery supported and portable

Hardware Description:

Top Level Block Diagram

Fig: Top Level Block Diagram

  • The device gets an external supply from a battery which passes it through a regulator circuit, the DC Distribution Box (DCDB) to provide regulated power to the various sections of the device. It takes 12V unregulated supply from a battery and gives regulated supply voltages of 3.3V and 5V to the different components in the system.
  • The e-books are loaded into a Mass Storage Device (USB Flash drive) in a .txt format. This Flash Drive is connected to the device (VDrive module which uses VNCL FTDI-Vinculum Chip) which reads the .txt files and converts the text into braille format to be displayed on the designed LED matrix to verify the working of the device. This particular section of the device is of significant importance as the reading of books from a flash drive is a very common mode of data storage and helps in increasing the portability of the machine.
  • The selection of the books within the flash drive is done using the speech recognition functionality of the HM 2007 Voice recognition IC. This feature allows the blind user to navigate a plethora of E-books using simple voice commands.
  • A given file is selected only when the user speaks the title of the given file in the mic. An audio amplifier circuit is also designed using LM386 to play multiple monotone as notifications to the user.
  • Up-Down scroll buttons are provided to scroll between the lines of a given text files.
  • The control logic unit consists of the MSP430F5659 microcontroller. This particular IC was chosen because of the large number of IO ports requirements as per the design of our system.

Software Description:

Software Flow Chart

Fig: Software Flow Chart

The software implementation of the system is based on a sequential logic. The initialization of the system includes initialization port pins and verifying operation of various sub systems. To read any E-Book, hardware interrupt has to be raised by the user, which transfers the control to the voice recognition module which then takes a user input. Based on this input, a given E-Book file is copied from the USB Mass Storage Device and converted to braille format and stored in the RAM space of the MSP. These converted characters are then sent to the LED Matrix Display.

Note: I have been unable to include the exact technical details (for eg. Implementation etc), as I don’t have the permission to release the same from some of my other team members.