EGR 326 Project - Firing Range Audio Module
This project was developed for my EGR 326 class. This class involves working with a sponsor to develop an embedded system to fit their needs. I worked with another student in developing what we described as a "wireless mp3 player."
Magnum Engineering was sponsoring a redesign of the automated control system used by the Grand Rapids Rifle and Pistol Club and the Grand Valley State University Shooting Team. The Grand Rapids Rifle and Pistol Club hosts a variety of different shooting sport games. The control system needs to be able to control the flow of each match, such as telling the shooters when to fire, when to seize firing, keeping track of the elapsed time, etc. Various types of matches have different game requirements, rules and procedures. The system needed to be flexible enough to proctor the variety of different games hosted by the shooting range.
The control system was separated into four modules:
- the user input module
- the audio module
- the timer module
- the environmental controls module
Each of the different modules were designed by a different team. My team was responsible for the audio module.
The user input module acted as the master controller for the entire system. The user would select which match type to play using controls on the user input module. The user input module then sends various commands to other modules based on the procedure of the game selected. Each module needs to accept commands at various stages from the user input module and respond by doing its required tasks.
The audio module was designed to play audio files when designated by the user input module. The purpose of the audio module is to output voice commands to the shooters in the firing range. The audio module receives a command from the user input module to play a specific audio file. These commands are sent through wireless transceiver modules mounted on both the audio module and the user input module. The audio module will output a line level analog audio signal to drive external amplifiers. A LED will light when the audio module is receiving power from a wall transformer.
The following specifications were given by Magnum Engineering:
- The audio module will receive a filename from the user input module specifying which file to play.
- Use of a Microchip MRF24J40MA for wireless communication.
- The audio module must be capable of playing MP3 and WAV file formats.
- It was recommended to use either a VLSI VS1011 MPEG Decoder Chip or a STMicroelectronics STA013 MP3 Decoder for the codec chip.
- The audio module must output a line level analog audio signal to an amplifier with 10k input impedance.
- The volume of the output must be adjustable.
- The output connector must be a RCA Female type connector.
- Power must be provided from a wall transformer.
The audio files must be stored on a SD card located on the module. - The SD card must be formatted for a FAT32 filesystem for easy transfer of audio files from a PC.
Ultimately, we chose to go with the VLSI VS1011 audio decoder chip because it offered good documentation and included all the featured we required. We also chose to use an Atmel AVR (Atmega644p) because we both had experience writing applications for AVRs. We also used FatFs in order to talk to the SD card.
We used the Microchip MRF24J40MA to communicate with the user input module. This chip is a 802.15.4 transceiver which can communicate over 802.15.4 MAC, MiWi, and Zigbee. However, we used 802.15.4 MAC in order to avoid the unnecessary complications of MiWi and Zigbee when we were using such a simple network of devices.
In using 802.15.4 MAC, we had to design our own basic communication protocol. Our protocol assigned each node on the network a unique binary encoded ID. The IDs for the user input and audio modules are shown below:
| Module | Network ID |
|---|---|
| User Input Module | 0001 |
| Audio Module | 0011 |
When communicating, the sender would format the first 4 most significant bits of the transmission with the network ID of the device it was trying to communicate with. The transmission would be received by all the devices on the network, however, each device should filter out transmissions not intended for it. The following four bits would be an "action command" which would tell the receiver some action to perform.
The acknowledgment action code from the user input module ensures that the audio module is online and functioning properly. This will be sent at the beginning of every match. If the SD card missing action code is received by the user input module or if no response is received, the match will be allowed to continue, however, no audio will be played during the match.
The find file action code is used to ensure that a file is available for playing on the audio module. This command will be sent for each file that is required to be played at the beginning of every match. If a file is not available, the 0010 action code will be sent back to the user input module and the appropriate error message will be displayed. If the file is available, the 0100 action code will be sent to the user input module. Following the first byte of the transmission from the user input module, a filename will be sent from the user input module to the audio module. Each character of the filename will be sent using the ASCII definitions for each character. The ASCII definitions for characters specify one byte per character. Immediately following the first byte, the character code for a double quote will be sent to specify that a filename will be following. The user input module will send each character in the filename and send a double quote to signify that the transmission of the filename has ended.
The play file command from the user input module will tell the audio module to play a specific file at that time. The audio module will respond with either a success (1000) command after the file has been sent to the audio output or a failure (1100) command. The filename will be sent to the audio module in the same fashion as described above.
Once the project was completed, there were two major errors we noticed. The first error is that there was no pull-up resistor on the reset button connected to the Atmega644p microcontroller. Once the board was completely soldered, the lack of the pull-up resistor caused the Atmega644p to be in constant reset. Soldering a 10kΩ (R6) pull up resistor from the reset button to the 3.3V voltage regulator fixed this problem and was the solution used.
The second error was that the SO pin (pin 14) on the VS1011e decoder chip would draw too much current whether or not the decoder chip was selected using SPI. This caused communication from the Atmega644P to the SD card to fail. Placing a 2.2kΩ (R31) resistor in series with this pin fixed the problem.
Another fix that we would recommend to happen on future models of this project is to use a faster microcontroller or use a 32 bit, dual SPI microcontroller to allow faster bit rate mp3’s to be played. The SD card requires a lot of time to find the data bits that were to be transferred to the VS1011e Audio Codec.
Finally, here is our a zip of our source code, schematic and board files, and BOM. Sorry, too lazy to throw this up on Github.