Skip to main content


Peter Loy- pel29, Stephanie Pancoast- slp56

Overall picture of our project.

Introduction

The goal of our project was to design a low cost and user-friendly FM radio receiver.

Our project uses a FM receiver integrated circuit to perform the pre-processing units that are needed before the desired audio signals can be heard. The radio frequency is too fast for processing with our available hardware and the ATMega644. We integrated a LCD to communicate with the user and a keypad to allow the user to interact with the receiver and change stations. Our initial project idea was to create a receiver that could store audio, and later to design a radio that could create a playlist of the given radio station. The song title information is sent along with the modulated audio signal through a system referred to as RBDS (Radio Broadcast Data System). Although we were unable to get the RBDS feature working, we have included some of the background, hardware, and software components in the RBDS section of the Appendix so that perhaps a future group can expand on our project to implement a feature using RBDS.

High Level Design

Background Information

FM (frequency modulated) radio signals are broadcasted on a carrier frequency within the range of 87.5MHz to 108.0MHz. Each station is provided 0.2MHz to broadcast their signal (in the United States), however, a maximum of .15MHz is typically used to prevent interference with adjacent channels. The incoming signal needs to first be demodulated, which involves multiple stages including the Low-Noise Amplifier, Frequency mixer, and other hardware-level FM signal processing units. We used an AIROHA AR1010 Single Chip FM Radio Receiver to perform these preprocessing stages for us. It is worth mentioning at this point that we at times refer to the AR1010 FM Receiver and documents for the AR1000 receiver interchangeably. Both the AR1010 and AR1000 are receivers from AIROHA. The only difference between the two is that the AR1000 supports RBDS while the AR1010 does not. We were unable to obtain an AR1000 which would have been useful for the purposes of our project, but much of the supporting literature for our FM receiver design is specified for the AR1000.

Functionality

keypad

Keypad used to control radio.

Our radio receiver can perform the following functions:

  • Tune up or down a frequency
  • Scan up or down for the next station with a strong signal
  • Set up to 3 favorite stations which will be available later for quick tune
  • Adjust the scanning threshold to pick up stronger or weaker stations

As mentioned, the United States separates frequencies by .2MHz (100.1, 100.3, 100.5 ect). However, in other regions of the word, the stations may be separated by only .1MHz. Therefore, to accommodate for both possibilities, we decided to allow the user to tune up or down by 0.1MHz increments.

The user controls the receiver through the keypad shown in the figure to the right. The buttons are mapped to the functionality as follows:

  • 1, Tune up
  • 2, Scan up
  • 3, Increase scanning threshold
  • 4, Tune down
  • 5, Scan down
  • 6, Decrease scanning threshold
  • 9, Reset scanning threshold
  • 0, Go to/ store favorite station 1
  • F, Go to/ store favorite station 2
  • E, Go to/ store favorite station 3
  • D, Set favorite station

The rest of the buttons are not hooked up and pressing them will have no effect on the receiver. To set a favorite station, the user must perform the followings steps:

  1. Tune to the desired station
  2. Press the Set button (D)
  3. Press one of the favorite buttons (0, F, or E) in which the station will be stored. Any station previously stored at that button will be overwritten.

Overall Architecture

Our design can be broken into four main subcomponents: communication with the receiver, favorite station storage, the keypad, and the LCD. Although we were unable to incorporate the RBDS features into the final product, we also have included the work we have done with the hardware and software aspects that would support that additional functionality. These components and the communication between them is shown in the diagram below.

Logic diagram of receiver.

The incoming radio signal is transferred through the antenna to the AR1010 FM radio receiver. The breakout board with the receiver then processes the signal, and from that extracts the left and right outputs, which we connected to an audio jack. The user can simply plug in a speaker to hear the station. However, some type of amplifier is needed. Without one the output is not strong enough to be heard through headphones, even with the receiver set to full volume. Any button presses from the keypad get processed by the microcontroller, which will send the corresponding controls to the receiver and the appropriate message to the LCD.

Program/ Hardware Design

Software

Each of the four components of our design have software components: the communication with the AR1010 FM Receiver, interpreting button presses from the keypad, setting favorite stations in long-term memory, and displaying message on the LCD.

FM Receiver

We decided to the I2C protocol to communicate with the AR1010. The main reason we chose I2C over SPI was that the sample code available online used I2C. Also, the 3-Wire Interface used 26 clock signals to perform a simple write function, which would have complicated the SPI support on the ATmega644. Much of our code involving the I2C communication with the receiver was modified from the AR1000 ATMega168 Example Code available from Sparkfun Electronics.

We ran into significant difficulties with the I2C communication with the AR1010, the main issue was that a flag sent from the slave (AR1010) to the master (Mega644) was never being sent to signal that the start condition was received, and therefore the microcontroller was getting stuck in the wait state. We went through numerous other sets of sample code, including the one provided by request from NKC Electronics and tried to creat a program from scratch,incorporating information from the Programming Guide and the available code samples for the AR1010/AR1000. However, our problem persisted until we returned back to our original sample code. While we are still unsure why exactly the STC flag was not being set for the other codes, we have concluded that the initial attempt failed due to hardware errors, most likely a lack of pull-up resistors (discussed in the Hardware section below) on the data and clock line, which were remedied in our attempt to find a sequence of I2C commands that would work for our chip.

The registers on the AR1010 needed to first be initialized before any communication could follow. The values for the registers were recommended by the Programming Guide, and we determined that the Mega644 running on 16MHz did not require any modifications to these values. Once the AR1010 signaled that the registers had been written, we were able to begin communication.

All I2C functions were provided in the sample code, and also are modeled of the TWI protocols as provided in the Mega644 datasheet. The volume of the receiver is by default set to maximum, and as this still results in an output too quite to be heard on headphones, we did not feel the need to adjust the register determining the volume.

The receiver allows for easy and quick tuning to a given frequency. The channel of the receiver is stored in the second register. We chose to store the current frequency of the station in a global variable, as we wanted to be able to access the station we were listening to in other aspects of the program without having to read the register each time. The frequency will always have a minimum of one decimal place (in MHz) and will be between 87.5MHz (875KHz)and 108MHz (1808KHz), so storing the station in KHz allows the value to be represented with a 16 bit integer. The channel to be written to register 2 that corresponds to the given frequency can be calculated as follows:

RF Frequency (in KHz) = 690 + CHAN

This function was also provided by the Programming Guide. Once the new channel was written, a message was sent to the LCD to notify the user of the updated station. The tuning function takes in a simple value of 1 or 0 to determine whether or not the tuner should go up (1) or down (0).

The sample code also provided a function to allow for more dynamic tuning. The Tune Hi-Lo feature looks at the RSSI (register value reflecting signal strength) to help it fine tune the frequency. By testing this function, we did not notice a significant difference in the tuning, so decided to use the more direct method as previously described.

The main algorithm for scanning is outlined in the Programming Guide, and implemented in the sample code. Like the tuning function, the receiver can scan up or down, depending on the input parameter. In addition, the minimum strength of the radio station needed for the scan to halt on that particular frequency is dependent on a threshold value set in a register. We modified the code so that the user can increase, decrease, or reset the threshold to its original value. This way, should the user decide that the receiver is skipping over the stations that are still audible, maybe just not ideal, he or she can decrease the threshold through the changeThreshold function.

We experimentally determined the best default value for the threshold by trying different values and performing a scan to determine which threshold picked up true stations in the area. The results from this are discussed further in the FM Receiver Sensitivity Analysis section.

Keypad

Our program, once done initializing all components of the project, enters a loop which scans the keypad for button presses. Modeling off the Lab 2 KeytestGCC644.c, the code recognizes when a push may have occurred and confirms the push through a state machine. Then, it processes which button was pressed before executing the appropriate functions for that button, as discussed in the functionality section above.

Favorite Station Memory

Most radios allow the users to store favorite radio stations which can be accessed with a single button push. To support this feature, we designated the bottom four buttons to the favorite station memory storage. The left three were for storing the stations. A global flag determined whether or not a press signaled that the user wanted to listen to the station currently stored, rather than set the station. This flag could be toggled by the bottom right-most button of the keypad.

The favorite stations are stored in the EEPROM of the Mega644. We chose to use EEPROM so that when the microcontroller is reset, or turned on after being off (a reasonable usage) the favorite stations will still be set. The only way the stations could be erased is with a re-programming of the microcontroller. We wrote the three favorite stations as three words (the station is in KHz so needs 16 bits) in even locations, since memory is byte addressable. However, before storing stations, we checked a designated byte (address 1 since EEPROM's memory location 0 is not completely reliable) to ensure that the favorite station memory locations contained meaningful values. At a re-program, these could be set to any value, so in this case we initialized all favorite stations to 88.0MHz.

LCD

All the functions we used to control the LCD were from the LCD library provided in Lab 1. To ensure that the user is informed as to what the receiver was doing at all time, we designated the top line to be one of the below messages:

  • LCD Initialized: upon reset, lets user know everything is ok with the display
  • Currently on…: you are tuned to the station below
  • Still looking…: the scan is still in process and has not settled on a station yet
  • Set favorite to: if you press one of the favorite keys it will be set to current station
  • Scan Thresh +: increase scanning threshold by 1
  • Scan Thresh -: decrease scanning threshold by 1
  • Reset Thresh (set scanning threshold to the original value
  • Uh oh: an error occurred in retrieving or setting a favorite station from memory, this message can be incorporated in another debugging aspects of the program as well

The second line of the LCD displays the currently set station. Every time the tune function is called (signaling that the receiver is on a new frequency), the bottom line of the LCD is updated. Some of examples of the LCD displays are shown to the right.

Hardware

Three of our components require hardware: the AR1010 FM radio receiver, the LCD, and the keypad. Each of these main components has its own corresponding hardware. The connections for the LCD and keypad were modeled off the schematics in Lab 1 and Lab 2 respectively.

AR1010

The AR1010 needs to be powered by a 3V power supply. In order to create this power supply, we created a voltage shifter circuit, which took our 5V power supply and created a constant 3V source. See 3V converter in appendix for schematic. The voltage shifter consists of a transistors, which creates a constant voltage of the voltage at the base - 0.7V. The voltage at the base is created by a 10k ohm trimpot. Therefore, we adjusted the voltage coming from the trimpot until it was 3.7V and, thus, created the 3V power supply.

The AR1010 talks to the Mega644 through a two-wire interface using I2C protocol. In order for the two-wire interface to operate, the connecting data and clock lines must be connected to pull-up resistors. We used 10k ohm resistors for the pull-up resistors, as was recommended by the AR1010 set-up schematic.

Finally, the AR1010 requires an antenna in order to receive the radio signal. NKC Electronics, the distributors who donated us with a sample of the AR1010 chip and breakout board, recommended a 31", 22 gauge wire. We first tried about 3 feet of lab wire and it worked perfectly. A picture of our hardware

LCD and Keypad

The LCD was set-up exactly as in the ECE 4760 lab 1 description. We connected it to Port A of the STK500 board. We controlled the contrast by using a 10k Ohm trimpot.

The keypad was set-up exactly as in the ECE 4760 lab 2 description. We connected it to Port D of the STK500 board.

Results

Overall, with the exception of our RBDS implementation, both our hardware and our software designs worked very well. In the end, our FM receiver, LCD, and keypad worked exactly as planned. We analyzed the overall function of the FM receiver, the functionality of the FM receiver's sensitivity threshold, the evolution of our FM receiver design, and the functionality of our design. Our RBDS implementation, including its failures, is in the appendix.

FM Receiver Functionality Analysis

In testing each of the functions of our FM receiver we found no problems. The keypad controls the functions without any problems and the LCD correctly displays the appropriate messages. The only function that required more testing was the scan function and the effect of the sensitivity threshold.

FM Receiver Sensitivity Threshold Analysis

One of the software design considerations we tested was the effect of the sensitivity threshold on what stations the FM receiver was able to pick up. The sensitivity threshold was a 7-bit variable, allowing settings ranging from 0 to 127. The following table shows what stations we could pick up at varying thresholds:

TH=1 TH=5 TH=20 TH=30 TH=50
88.1 88.1 88.1 88.1 NONE
91.7 91.7 91.7 91.7
92.8 92.8 93.5 93.5
93.5 93.5 96.0 96.0
96.0 96.0 97.3 97.3
103.7 100.3 103.7
107.1 103.7 108.0
108.0 107.1
108.0

As expected, setting the sensitivity threshold very low allowed more stations to be detected, but the problem is that some of these radio stations did not actually exist. The stations 100.3, 103.5, and 107.1 are not actual radio stations in the Ithaca, NY area. While 92.8, 96.0, and 108.0 are not actual radio stations, 92.7, 95.9, 96.1, and 107.9 exist and the receiver was actually picking up those stations. Also, setting the threshold too high resulted in no stations being detected.

FM Receiver Design Problems

We encountered many problems during our development of the FM receiver. These included both hardware and software problems. When we first tried the AR1010 chip with the sample code from Sparkfun, we hooked it up and nothing happened. There was no communication through the two-wire interface. Not knowing whether it was a hardware or software problem, we tried to debug both at once. First, we discovered that we were giving it a 5V power supply, rather than the required 3V. This led to the development of our voltage shifter. Next, as mentioned previously in the program section, we saw that we had not included the pull-up resistors on the I2C lines. During the process of these hardware fixes, we managed to burn out one of our AR1010 chips. This was caused when we had the pull-up resistors accidentally hooked up as pull-down resistors. While debugging the hardware, we also tried debugging the software. A full description of this problem was discussed previously in the software section. From that we concluded that our problem was not with the sample code from Sparkfun, but, instead, with the implementation of the code.

Analysis of Functionality

Our design is very functional and usable by most people. Our LCD screen tells the user what station they are listening to and what functions they are performing at the time. The only group of people who could possibly struggle with our design are the visually impaired. Our design will have no effect on other projects as it does not create any interference. The only functionality consideration that must be taken into account is whether an FM radio signal is receivable in the area you are planning on using it.

Conclusion

Overall, our project did not meet our initial expectations. Our original project idea was our final product with the additional features of displaying the song title on our LCD and being able to store songs and have playback. We realized we did not have enough time for a project of this magnitude, so we eliminated the storing and playback of songs and, instead, decided to have the ability to store the names of songs and create a playlist from the radio. These functions relied on a Radio Broadcast Data System (RBDS) decoder. But we had to abandon the storing of the song title feature and the ability to display the song title because we ran out of time. Getting the FM receiver to work took too much time and we did not have enough time to debug the problems we had with the RBDS decoder. Therefore, we could not implement a playlist feature because, without the RBDS decoder, we could not get the song title from the radio signal. I'm not sure how we could have improved on our approach to our project. If we could have avoided the initial hardware problems in setting up our FM receiver, we might have had enough time to debug the RBDS decoder and have it operational.

The only standard used in our project is the I2C standard for two-wire interfacing. Our FM receiver claimed to be I2C capable and we found that it complied with the standard. If not for initial hardware issues, the sample code given to us by Sparkfun would have worked with their I2C implementation.

In our original project idea, the only legal consideration we had was copyright infringement in that we were allowing people to store songs. People possibly could have permanently saved those songs and distributed them illegally. But once we changed our project idea to creating a playlist from the radio, we eliminated the only legal consideration we had.

In all aspects of the development of this project, we followed the IEEE Code of Ethics. First, in the development of our code, we give credit to every contributor. We cited not only the sample code we built on, but also the authors of other code that inspired our design. In addition to citing contributors, we also refrained from commenting on their code, so as to avoid falsely damaging their reputations. Also, when we were obtaining the FM receiver module and the RBDS decoder, we were upfront and honest with what we were planning on using the chips for. We explained that we were going to be using the chips for our senior design project, we would include their names in our project report, and would not use the chips commercially. Also, throughout our project, we sought input from Bruce Land and the teaching assistants of ECE 4760. They helped us fix problems we did not know how to fix and to avoid oversights in our designs. In order to improve technical knowledge on all of the subjects we studied, including the AR1010, I2C, and RBDS, we are publishing this report online on the ECE 4760 website. We hope that people looking for information on FM receivers, I2C implementation, and RBDS implementation can find our work both as a guide to get started and as a stepping stone to further developments.

Appendix

Radio Broadcast Data System (RBDS)- Not Included in Final Design

Background

RBDS is a standard used in radio transmissions to transmit other data along with the song. This other data includes the call letters of the transmitting radio station, the name of the song that is playing, the genre of the song, weather warnings, and advertisements. It was published in 1998 by the National Radio Systems Committee.

Functionality

An RBDS decoder works by receiving a radio signal and then decoding the RBDS information that is being sent with it. RBDS data consists of 4 packets of data that are continuously sent with radio signals. Each of these packets consists of an group identifier, which identifies what information this group contains, and the 16-bit data message. Using the group identifier, you can translate the data message by using the appropriate character set given in the RBDS standard document.

For our project, we were going to use the song title information from the RBDS message and display it on the LCD. We were also going to allow the user to create a play list from songs on the radio by saving the names of songs that the user indicated. This feature would have been very useful, as we could find no device that performed this function other than through internet radio streams.

Hardware Design

Our RBDS decoder was a TDA7333N from STMicroelectronics. See appendix for circuit schematic. This chip required a 3V supply voltage, three reference voltages of 2.65V, 1.65V, and 0.65V, an external crystal oscillator, I2C data and clock lines, and the radio signal. We used the same 3V supply from the FM receiver. We created the reference voltages by using potentiometers. The reason for the external crystal oscillator is that TDA7333N required a specific system frequency of 8.55MHz or 8.664MHz. In order to create this frequency, we used an external frequency of 16Mhz and then adjusted the PLL values within the TDA7333N to create the desired frequency. The I2C lines are the same lines from the AR1010 and the radio signal comes from the antenna connected to the AR1010.

Software Design

Our idea was to use software to check for the RBDS group that contains the song title information and display that to the LCD. This is a simple check, as the TDA7333N gives the group identifier number.

Our software allowed the Mega644 to control the TDA7333N through the use of an I2C two-wire interface. See the TDA_I2C.c code in the appendix. WARNING: THE CODE DOES NOT WORK. We were given no sample code to start from and could find no code written for this chip anywhere, so all of the code for this is ours. The code implements the same I2C functions as the FM receiver code. Our code does not yet check for the RBDS group that contains the song title information, nor does it display this information to the LCD. The reason for this is we needed to figure out which group contained the song title information, which required communication along the I2C line between the Mega644 and the TDA7333N. This I2C communication was not working.

Right now, the code is able to write to the registers on the TDA7333N, but we are not able to read from them. When a read command is given, the ACK is never received by the Mega644. One reason for this is the TDA7333N does not exactly follow the I2C standard of how to read the slave's registers. I2C protocol says to first send a write command in order to initialize the register you are going to read from, then you send the read command. The TDA7333N does not operate in this manner. For it, just a read command is given, and the registers are read out in a specific order. You must read all of the registers before the desired register and then you can stop the transaction after you have read from the desired register. We think this discontinuity between the TDA7333N and I2C protocol is what is causing our communication problems

Conclusion

More time was needed for us to implement the RBDS decoder. We were unable to solve the communication issues between the Mega644 and the TDA7333N and, therefore, were unable to receive the RBDS data.

Commented Code

Schematics

Schematic for 5V to 3V constant voltage converter.

Parts List

PART# AND DESCRIPTION SOURCE QUANTITY COST/EACH COST
Total $50.24
AR1010, FM Single Chip Radio Receiver NKC Electronics 1 $0 $0
Breakout Board for AR1010 NKC Electronics 1 $0 $0
STK500 ECE 4760 Lab 1 $15 $15
ATmega644 ECE 4760 1 $8 $8
White Boards ECE 4760 Lab 2 $6 $12
Header Pins ECE 4760 Lab 25 $0.05 $1.25
LCD,16x2 Liquid Crystal Display ECE 4760 Lab 1 $8 $8
Keypad ECE 4760 Lab 1 $6 $6
10KOhm Trimpots ECE 4760 Lab 5 $0 $0
Audio Jack ECE 4760 Lab 1 $0 $0
Other small parts (resistors, BJT, ect) ECE 4760 Lab - $0 $0
(TDA733N, RBDS Decoder) (STMicroelectronics) (1) ($0) ($0)

Task Distribution

Peter worked closer with the components for the keypad and RBDS features, while Stephanie focused on the LCD and user interface aspects. However, both members were involved in all aspects of the project.

Helpful Documents

The AR1010 Datasheet, Programming Guide, and sample C code were very useful, and are available by request from NKC Electronics or SparkFun Electronics

Our project borrowed lcd_lib.c and lcd_lib.h, and was modeled off the design of ar1000test.c and KeytestGCC644.c.

We would like thank again NKC Electronics for donating three AR1010 with the breakout boards. We would also like to thank Bruce Land, the and the ECE 4760 Spring 2010 TAs for providing us with many of the small components we needed for our project, as well as helping us with other design decisions (including the 5V to 3V converter) and assisting us with the debugging process.