Introduction
The project “Morse Code CODEC” is composed of two major parts, encoder and decoder. The encoder takes input from Hyperterm and translates this input into morse code, to be output as sound. This audio output will be driven through a standard speaker. The decoder takes the audio output produced by the encoder and translates or decodes the morse code message back to its original form and displays the message back to hyperterm. The decoder uses a uni-directional microphone as the input mechanism for the morse code that it is to translate. Through a analog to digital conversion, it is able to translate the message.
High Level Design
We planned to create an encoder and decoder functions, which operate independently from each other. This idea came around as we thought and discussed about information transfer and how over times, compression, codecs, and signal speed has changed, and we though about one of the most basic, yet still used codec: Morse code. The encoder takes normal alphabet inputs from hyperterm, and creates a string consisting of 0, 1, 2, and 3 to encode the alphabet. This is because the Morse code consists of four different types of outputs. The “dit” (short signal 1 in our code), the “dah” (long signal, 3 times the length of the dit, 2 in our code), letter space (same length as the dit, to distinguish the end of a letter, 0 in our code), and word space (7 times the length of the dit, used to distinguish ends of words, 3 in our code). From this string that we made, we control the length of the signal set to be about 720Hz. Outputting a signal at 720Hz on the Mega32 was easy: it was something we did for a different lab. However, the hard part was the decoder, which on the other hand, takes samples of sound signals through a microphone, filters and digitizes the signal with a threshold value, and depending on the lengths of the signals, creates a string consisting, of again, 0,1,2, and 3, which is decoded into the alphabet to be displayed on hyperterm. To parse the microphone signal, we needed to use a buttersworth filter to be implemented within the MCU. This incurred some trade off, as a very accurate calculation lagged our output, as it lagged the whole MCU, which we used matlab’s butter function to calculate the coefficients for. We have made it so that the amount that the MCU can decode at a time is very limited (couple of words). In the end, we were able to have everything run concurrently and smoothly, with ISR’s implemented with different timers. The decoder, as will be explained later, ran in multiple steps, required the system to calculate much faster than the system sampling what the microphone picked up, but this also ran well since we restricted the sampling rate.
Link: http://instruct1.cit.cornell.edu/courses/e...page/index.html
The project “Morse Code CODEC” is composed of two major parts, encoder and decoder. The encoder takes input from Hyperterm and translates this input into morse code, to be output as sound. This audio output will be driven through a standard speaker. The decoder takes the audio output produced by the encoder and translates or decodes the morse code message back to its original form and displays the message back to hyperterm. The decoder uses a uni-directional microphone as the input mechanism for the morse code that it is to translate. Through a analog to digital conversion, it is able to translate the message.
High Level Design
We planned to create an encoder and decoder functions, which operate independently from each other. This idea came around as we thought and discussed about information transfer and how over times, compression, codecs, and signal speed has changed, and we though about one of the most basic, yet still used codec: Morse code. The encoder takes normal alphabet inputs from hyperterm, and creates a string consisting of 0, 1, 2, and 3 to encode the alphabet. This is because the Morse code consists of four different types of outputs. The “dit” (short signal 1 in our code), the “dah” (long signal, 3 times the length of the dit, 2 in our code), letter space (same length as the dit, to distinguish the end of a letter, 0 in our code), and word space (7 times the length of the dit, used to distinguish ends of words, 3 in our code). From this string that we made, we control the length of the signal set to be about 720Hz. Outputting a signal at 720Hz on the Mega32 was easy: it was something we did for a different lab. However, the hard part was the decoder, which on the other hand, takes samples of sound signals through a microphone, filters and digitizes the signal with a threshold value, and depending on the lengths of the signals, creates a string consisting, of again, 0,1,2, and 3, which is decoded into the alphabet to be displayed on hyperterm. To parse the microphone signal, we needed to use a buttersworth filter to be implemented within the MCU. This incurred some trade off, as a very accurate calculation lagged our output, as it lagged the whole MCU, which we used matlab’s butter function to calculate the coefficients for. We have made it so that the amount that the MCU can decode at a time is very limited (couple of words). In the end, we were able to have everything run concurrently and smoothly, with ISR’s implemented with different timers. The decoder, as will be explained later, ran in multiple steps, required the system to calculate much faster than the system sampling what the microphone picked up, but this also ran well since we restricted the sampling rate.
Link: http://instruct1.cit.cornell.edu/courses/e...page/index.html