Radio telemetry is an efficient and sometimes necessary means of data logging in remote environments. This project outlines the design of an RF telemetry system where temperature, vibration, and compass data are sent from a transmitter unit to a receiver unit and displayed.
External hardware used in our project includes a 10k thermister, a Dinsmore 1490 compass, a piezo film vibration sensor, and two BIM-433-F transceiver modules each with a standard antenna. The design of the data latching and transmission / reception blocks was implemented with the use of Maxplus2 over two Altera EPF10K20RC240-4 FPGAs. A static interface to a VGA monitor was also implemented as an aid to introduce our project.

For our project we have designed and interfaced compass, vibration, and temperature sensor blocks with the Altera 10K20 FPGA. The Altera UP1 board then displays (via its hex 7 segments and LEDs) the data from each sensor, formats each sensor data into a stream for broadcast and then transmits it to a transceiver at the data rate of 12.3 KB/s for broadcast at 418 MHz. A synchronization frame is created to identify the beginning of a data broadcast and is generating by sending the number '552' at the beginning of each broadcast. Identifiers are also created to head each data frame as an aid to ensure correct data is being received.
The receiver unit checks the incoming data for the synchronization frame. Once this frame is detected, 48 bits of data from the transmission stream are stored in the receiver. The receiver then checks each frame for a correct identifier and stores correct data in buffers for display over LEDs and the hex 7 segments. The receiver also controls the VGA monitor to display static project information.

The primary accomplishment of this project was the successful implementation of a unidirectional transmission of serial data. A transmitter and a receiver were built via two transceiver modules. The transmitter was capable of transmitting an encoded stream of serial data to the receiver, and the receiver then decoded the serial data into displayable format onto the different I/O devices. For example, the LEDs, and the hexadecimal 7-segment display were used to indicate that the modules were working properly. Furthermore, there were the vibration sound buzzer and the VGA display that gave the project additional I/O features.
In this project, there were mainly three sensors: temperature, vibration, and compass. The three sensors provided the transmitter with the data to transmit. For example, the temperature sensor was a Keystone 10 KO thermister that output different analog voltage corresponding to the surrounding temperature. The temperature was classified into three categories, namely, cold, warm, and hot. The room temperature was warm, and it stayed around the ADC output of "100000". Note that only six out of the seven segments were used, hence the "g" segment was unused. The relationship between the 7-segments and the bit pattern was as follows: "100000" corresponds to "fedcba". So the bit pattern "100000" would have the "f" segment "on", with the other five segments "off". If the temperature sensor was exposed to a colder temperature, its bit pattern would increase, for example, "110000", whereas if it was exposed to a hotter temperature, its bit pattern would decrease, for example, "011000". To illustrate that transmission was successful, the sensor was lit with a lighter, and the 7-segment display did decrease in value, hence validate that transmission was successful and correct.
The vibration sensor was cheap and easy to implement. It created an analog signal whose power corresponded to the vibration strength. The classification of the output for this sensor was "none", "slight", and "heavy". "None" meaning that the sensor did not detect any vibration, "slight" meaning that there was a slight vibration and "heavy" meaning that there was a heavy vibration. Basically, each class of output was designated an output format on the two 7-segment displays. The "right" 7-segment display on the UP1 board represented "slight" vibration, and the "left" 7-segment display on the UP1 board represented "heavy" vibration. If the two 7-segment displays matched one of the classes of vibration input at the transmitter end, then transmission was successful and correct. For example, the sensor was tapped slightly and then heavily, and the output at the receiver end did conform to the specifications. It turned the "right" 7-segment "on" and then turned the "left" 7-segment "on", respectively. Note that either the "right" or the "left" 7-segment was "on" at one time, and if there were no vibration, then both 7-segment displays would be "off". After the test, it was concluded that the vibration sensor was working properly and transmission was successful.
The compass was a Dinsmore 1490 8-way compass. It had 4 pins to correspond to north, east, south, and west. Combining the pins allowed the detection of northeast, northwest, southeast, and southwest. Eight LED lights were assigned to each direction as shown below:

Figure 1 LED-to-Compass Direction

The compass on the transmitter was then pointed at different directions to illustrate that the compass was working properly. For example, if the compass was pointing north, then the upper-left corner of the LED light should be "on", and if the compass was rotated 90 degree left, then the light below north should be "on", since the direction would be east, and so on. All tests were performed on the compass, and they all passed the test.
Two other I/O devices were also implemented. One was the vibration sound buzzer, and the other was the VGA monitor. The vibration sound buzzer was on the transmitter side. A dipswitch controlled it. For example, if the dipswitch were high, the buzzer would buzz if it detected a slight vibration, whereas if it were low, then the buzzer would buzz if it detected a heavy vibration. This additional feature verified that a vibration was detected, and it should confirm with the 7-segment displays on the receiver side. And according to our tests described above on the vibration sensor, the buzzer did agree with the 7-segment displays.
The VGA monitor was an additional feature that supposed to give the project a visual flavor. Initially, the monitor was supposed to display sensors information in real time, hence the screen would refresh every tens of seconds as new data arrived to the receiver. But the implementation was complicated, and the project had a deadline to meet, hence the VGA monitor was designed to serve as a look-up table instead. It displayed the team logo, and the individual members in the team. Furthermore, it displayed the values that each sensor was bound to. For example, for the compass sensor, it could only have the values: north, east, south, west, northeast, southeast, southwest, and northwest.

Over the course of the project, there were many ideas and attempts. In most cases, they were unsuccessful because they were either too complicated, or because of time-constraint. Some of these ideas included bi-directional transmission, LCD display, FSK transmission, and real-time update of sensors' data on the VGA monitor.

The hardware schematics and design implementation for the external sensor circuitry are included in appendix A. Spec. Sheets for each part is included in appendix B.
Compass data is taken in parallel to an internal FPGA buffer, temperature and vibration data require serial data latching from the analog-to-digital converter before being manipulated or stored in their respective buffers.
Each analog-to-digital converter is clocked with a 1.25 MHz clock. From experimentation, we were only able to latch every other bit of the 12-bit ADC in effect treating it as a 6-bit ADC with a resolution of 64 levels. Each of the bit width lasts for 680ns with latching occurring in the middle of each bit. Since the data throughput from the ADC is different than the input clock, there was some difficulty in knowing when to latch data. If there were more time, further experimentation would have allowed us to latch all 12 bits.
Our project uses two levels of vibration: heavy vibration and slight vibration. This was implemented using a rate counter, which measures threshold crossings of a predefined value. Experimentally, we determined that two crossing of 4.37 volts (on a 5 volt reference) each second would adequately define a slight vibration while 100000 crossings of 4.37 volts would be defined as a heavy vibration. A heavy vibration is stored in a two bit buffer as "10" (and two LEDs are turned on), a slight vibration is stored as "01" (and two other LEDs are turned on) and no vibration is stored as "00" (with the LEDs off).
Sound was added as an extra feature for the vibration sensor. When a dipswitch was kept high, a beep was emitted whenever a heavy vibration was sensed. When the dipswitch is low, sound was only emitted for slight vibrations. File vibadc.vhd in appendix C illustrates how vibration data was latched and moved into a buffer.

In order to test the accuracy of the temperature data latching, the 6 temperature bits of data are sent to 6 LEDs of a hex 7-segment display. Input to the ADC was varied through a power supply and the appropriate reactions over the hex 7 segments were observed. Next, a lighter and a cool can of pop were each applied to the thermister and appropriate reactions were also observed on the hex 7-segment display. Note: in ambient temperatures the last two bits appear to continuously change even without input being applied. This change is attributed to sensitivity to temperature changes. Our temperature sensor is approximately sensitive to a range of 10'C to 50'C with each bit representing 0.6 'C File tempadc.vhd in appendix C controls how temperature data was latched, moved into a buffer, and displayed.

The Dinsmore compass has four output pins, each pin connecting directly to a buffer bit and its respective LED. Rotating the compass by 360' was observed to light up the corresponding LED.

A shift register controls how data is sent to the external transmitter module. 50% of the time is spent pulling data into the register by parallel from the buffers while the other 50% of the time is spent shifting data out at the data rate of 12.3 KB/s (while data is being refreshed at the buffers). A 'refresh' clock is used to determine when buffer data needs to be refreshed versus when data has to be sent to the shift register.

Various rates to refresh data were tried. The problem is that a rate must be selected that would allow all data from the ADC to be buffered before being pulled into the shift register. At the same time, the rate must be long enough to allow full data to be shifted out without metastability in the register. Connecting a frequency generator into the FPGA, an ideal refresh data frequency of 54 Hz allowed all 12 bits of each 5 frames to be received.

Initial attempts to combine 12 bit words into a coherent stream resulted in strict VHDL code that tried to control how data was multiplexed into a single stream. A multi-input (parallel & serial) 60-bit shift register with wrap-around allowed many of the previous code to be eliminated. Parallel input eliminated the need for a multiplexer and a predefined register size eliminated the need to count bits. A pattern encoder was originally created as a separate module (and treated like a buffer). The pattern encoder was also eliminated with the successful operation of the shift register. When data is loaded by parallel into the register "552" is fixed as a constant. File sh_reg.vhd in appendix C contains the code for the 60-bit transmitter shift register.
Figure 2 below illustrates how each 12-bit word is formatted into the 60-bit shift register.

Figure 2 Shift Register Framing

Due to time constraints we had to abandon the design of analog circuit / digital phase-lock-looping for reception and FSK modulated transmission. Following the advice from the Driver's Ed. Group we employed two digital transceivers for transmission and reception. The transceivers operate at a maximum data rate of 40KB/s over a carrier frequency of 933MHz allowing transmission of up to 30m indoor and 120m outside.

The top-level file of the transmitter takes in data from the sensor buffers and combines it into a bit stream for the shift register to pull in as parallel input. This top-level file also creates the clock for the ADC and controls the clocking for the shift register. A 12.3 KB/s clock shifting is required to shift data out while a much faster clock (the global clock) is used to pull data in as parallel input. File transmit.vhd in appendix C contains the code for the top-level transmitter file.

Figure 3 Transmitter Design Hierarchy

The RF receiver block diagram is shown in Fig. 4. A digital modulated FM signal is sent from the transmitter. FM transceiver modules from ABAcom Inc. were used for transmitting and receiving the FM signal (data sheet attached in the appendix). The detected FM signal is then passed to a pattern detector. The pattern detector detects a 12 bit "552" encoded signal which indicates the start of a frame. Each frame is composed of the 12 bit "552 " encoded signal and four 12-bit words representing data from sensors.
Once the "552" encoded frame has been detected the receiver is ready to accept new data. New data words are first stored in the 48 bits shift register. Data words are then checked for errors. If no errors are detected a buffer is updated with the new data. If errors are detected, the buffer is not updated with the newly received data. Data from the buffer is then sent to a data decoder to extract information from the raw digital data. The extracted information is then passed to a 7 segments display and leds for display. A VGA monitor is used as a static display to present group member's names and information about types of data received.

Figure 4 Receiver Block Diagram

In this project, three 12 bit words were used for data transmission. The forth does not contain sensor data and can be used for future expansions. Two entities, multiplex.vhd and push button.vhd are added to test the reception of the raw data.

If no errors are detected in the received data, data is passed to the buffer. Otherwise, the buffer is not updated with the new incoming data. Data is then passed to the data decoder. Data is then displayed on 7-segments display and on the LEDs. One data word is displayed on the LEDs. A Push button selects one of the remaining data words to be displayed on the 7 segments display. Detailed receiver description is included in appendix D.

Figure 5 Receiver Hierarchy

Figure 6 Component List

Transmitter's I/O Pins

Receiver's I/O Pins

Top-Level File
transmit.vhd
logic cells required: 919/1152 (79%)
total I/O pins used: 23/183 ( 12%)
minimum clock period: 130.2ns
maximum clock frequency: 7.68 MHz

sh_reg.vhd
logic cells required: 38/1152
minimum clock period: 15.3ns
maximum clock frequency: 65.35 MHz

vibadc.vhd
logic cells required: 500/1152
minimum clock period: 143.1ns
maximum clock frequency: 6.98 MHz
components used: 4 x timer.vhd
logic cells required: 59/1152
minimum clock period: 63.4ns
maximum clock frequency: 15.77 MHz

1 x debounce.vhd
logic cells required: 4/1152
minimum clock period: 3.6ns
maximum clock frequency: 277.77 MHz

tempadc.vhd
logic cells required: 246/1152
minimum clock period: 68.8ns
maximum clock frequency: 14.53 MHz
components used: 2 x timer.vhd
logic cells required: 59/1152
minimum clock period: 63.4ns
maximum clock frequency: 15.77 MHz

1 x debounce.vhd
logic cells required: 4/1152
minimum clock period: 3.6ns
maximum clock frequency: 277.77 MHz

compass.vhd
logic cells required: 8/1152
longest internal delay: 14.2 ns

makeclks.vhd
logic cells required: 180/1152
minimum clock period: 56.7ns
maximum clock frequency: 17.63 MHz

Top-Level File

Rec2.vhd
Logic cells required: 763/1152 (66%)
Total I/O pins used: 55/183 (30%)
maximum clock to output delay 131.1 ns

buff.vhd
logic cells required: 49/1152
maximum clock to output delay 12.7 ns

er_det.vhd
logic cells required: 100/1152
maximum clock to output delay 12.5 ns

myvids.vhd
logic cells required: 303/1152
maximum clock to output delay 12.5 ns

multiplex.vhd
logic cells required: 36/1152
maximum clock to output delay 23.8 ns

button.vhd
logic cells required: 18/1152
maximum input to output delay 27.2 ns

div8.vhd
logic cells required: 11/1152
maximum input to output delay 68ns

patterndetector.vhd
logic cells required: 141 /1152
maximum input to output delay 12.5ns

This project has been an enriching experience. We have faced many challenges and learned a lot about the UP1 board. More importantly, it has forced us to make some design decisions that we would not have, if it were not because of time-constraint. For example, we have decided to switch to transceiver the modules from FSK, and VGA from LCD. We should have made our decisions carefully at the beginning of the project, so we would have saved a lot of time.

[1] Digital phase-locked loop design using SN54/74LS297
http://www.ti.com/sc/docs/products/logic/sn74ls297.html#Datasheets

[2] R. E. Best ., "Phase locked loop: Design, Simulation and application," McGraw Hill

[3] J. Forcadas, A. Snip., "Digital synthesized radio transmitter," EE552 project.
http://www.ee.ualberta.ca/~elliott/ee552/projects/97f/radiotx/radiotx.html

[4] N.Bo, K.Leung, D. Ritter., "Radio frequency PSK transmitter," EE552 project.
http://www.ee.ualberta.ca/~elliott/ee552/projects/99w/RFTx_Rx/

[5] A. sedra, K. smith, "Microletronic circuits," Oxford University press.

[6] B.Razavi, "Phase locked loops and clock recovery circuits, theory and design," IEEE press.

[7] RF Monolithics, Inc,
http://www.rfm.com

[8] EE552 Drivers Ed. Group . Fall 99
Students: Raymond Sung, Patrick Chan, Jason Mah, and Andrew Sung

[9] "How to Write an LCD With Minimal Pain and Anguish"
http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/97f/lcd/lcd.html
Students: Jeremy Kierstead, Dave McMillan

[10] "HD44780, HD44780A (LCD-II) (Dot Matrix Liquid Crystal Display Controller and Driver"
http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/98f/LCD_Driver/app.htm
Students: Edward Wong, Patrick Li, Edgar Wong, Howard Shum

[11] "EE552 APPLICATION NOTE"
http://www.ee.ualberta.ca/~elliott/ee552/studentAppNotes/98w/dicerace_video_display
Students: Hao Luan, Bo Liu, Albert Chan

[12] "Using the Video on the Altera UP1 Board"
http://users.ece.gatech.edu/~hamblen/ALTERA/onedge/gatech/video.htm

Last revision: December 8, 1999