I’ll give you the circuit description and codes later.

This one was a group project of mine. The goal was to make a bangla voice calling bell, i.e. when a switch is pressed, the calling bell would actually play back some pre recorded voice. The project was done about 3 months back. It was quite childish, but was assigned to us, we didn’t quite choose it.

My group consisted of Sabih Omar (omar-sabih.blogspot.com), Mohammad Asif Zaman, and Atif Iqbal.

The concept of the project is quite simple. The Voice is first recorded into a PC. Then a matlab code is used to generate 8-bit PCM wave. This code is converted by MATLAB to some C-compatible code that can be readily pasted into the main coding part as a data array. When an interrupt occurs, the PCM is output via a port at a certain interval based on sampling rate (we did on 8kHz). This output is passed to an 8-bit DAC (Digital to Analogue Converter) and filtering and amplification is applied to the signal.

We didn’t have to submit any formal reports in the project, just a CD containing videos. So I don’t have it well documented.

• Sleep Mode in main routine to save power
• A pulled down switch as the bell’s push button used to drive interrupt and thus playback voice.
• Intelligently chosen response based on recurrent key presses.

If switch is pressed successively, the response changed automatically.

The responses were (remember this was a door-bell)
•অনুগ্রহ পূর্বক দরজা খুলুন (Please open the door)
•দয়া করে দরজাটা খুলুন (Kindly open the door)
•দোহাই আপনার দরজাটা খুলুন (I just beg you to open the door)
•আরে এতোবার টিপেন কেন? ভাগেন! (Why are you pressing so many times? Just get lost!)

This nice but utterly useless diagram was presented by me in my presentation:

Unfortunately, the project cannot be run by the Proteus VSM. The DAC there can synthesize a sine wave, but cannot synthesize human voice.

Another thing to note is that AVR microcontrollers keep variables in RAM and code in ROM like any Harvard Architecture device. The voice data are large (typically 8kb for 2 secs) so it is wise to keep them in Program memory.

Please remember to use the command pgm_read_byte to read from flash. We forgot this, and thought our microcontroller has gone crazy.

This is the report that we submitted to our teacher. Unfortunately it is not dubbed and is in Bengali Language.

Embedded Video

Finally I have decided to host all project files in EDA Board and AVR Freaks, (unless they decide to unhost them.) Please download if you must, and donate me some points there if you like my projects or find them useful.

http://www.edaboard.com/viewtopic.php?p=1084268

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1630&item_type=project

Here is a term project I did last month. The objective is simple. To transmit a IR message from PC to a receiver module few feet apart and show it on LCD. I created my own protocol for it, while another group used the RS232 protocol, just replacing the copper wire with IR beams.

The project mainly focuses on the development and implementation of a serial communication protocol. There are two parts for this purpose: the Software at the PC, and the firmware of the microcontroller, along with the circuitry. A text is entered at the PC end and a 32 character substring of the text is sent via infrared link to the microcontroller. The modulation technique employed is Pulse Duration Modulation for the data, and the character transmission rate for worst case is 18.18 / sec. The firmware supports to checking device ID. Each character sent must have the same device ID with the microcontroller in order to display it in the LCD.

Components Used:
Atmega32 Microcontroller 4MHz Crystal Shielded IR Receiver (3 pin)IRF840 MOSFET LCD Module (HD17238 Controller) 4081 And Gate 7805 Voltage RegulatorBC547 Transistor (2) 555 timer IC Resistors 10K, 1K, 100R Capacitors 0.01u, 4700uF, 4.7uFBreadboard & Breadboard wire

The text is first converted to a binary data stream. Each character is represented by 17 bits. Each Data frame sends the character, device ID and location of the character:

If the 1, 0 binary data were transmitted directly, it would be difficult to guess where the data stream is started. That is why the binary data were converted into a pulse duration modulated wave.

This data was output from the PC Parallel port. This signal was modulated at 38 kHz using On-Off-Keying (OOK). The IR receiver demodulates 38 kHz

Here a pulse duration modulation is used: A 4 sec high pulse means transmission start. A 2 ms high pulse means 1 A 1 ms high pulse means 0 A 4ms high pulse means the data-frame is starting to transmit The protocol is made from the scratch without any help from built in USART receivers of the microcontrollers. The protocol was implemented using the input capture feature of the microcontroller. A timer inside the microcontroller was configured to count up at 0.5MHz speed once in every 8 clock pulses.

Algorithm

Trigger in each transition of the IR receiver output.

1. Check: Is it rising or falling edge?

a. Falling Edge: Set Couter = 0

b. Rising Edge: pulseduration = counter_value

Is pulseduration = 4ms at 25% tolerance?

Yes: Was transmission going on (set transmissionstart = =true)?

Yes: Discard current packet and set transmissionstart = false

No: set transmissionstart = true; nbit = 0

Was transmission going on (set transmissionstart = =true)?

is pulseduration = 2ms at 25% tolerance?

Yes: nbit th bit is 1,

is pulseduration = 1ms at 25% tolerance?

Yes: nbit th bit is 0,

If none of the above pulsewidth conditions met then discard current packet

Increment nbit

is nbit is equals to 17?

Yes: form deviceID with first 3 bits

Is deviceID equals to programmed deviceID?

No: Discard data pa
cket and exit

Form character with next 8 bits, and locationint with next 5 bits

Calculate parity with XORing the 16 bits

Does Calculated parity match received parity?

No: Discard data packet and exit

Yes: Update the value of text string’s locationintth

Location with the received character.

Circuit Diagram:

Transmitter:

Receiver:

Limitation
1.The PC side software was written with Visual Studio 2008. But the PC used did not meet the minimum requirements to run the software. As a result the PC side software was very slow, and thus the data transfer rate needed to be slowed down.
2. The PC software sends 32 characters regardless of the number of characters in the input stream. The remaining characters are filled up with white space characters. This might be overcome by keeping a command for clearing screen in the firmware of the microcontroller.
3. The PC software was configured to send 32 characters only. It could not send more than that at a time.
Pictures:

Full Files:

http://www.edaboard.com/viewtopic.php?p=1084270

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1630&item_type=project