Proceedings of the Multi-Disciplinary Senior Design Conference Page 5

Project Number: 09311

Interface for Multi-purpose driver/data acquisition system

David Howe / Electrical Systems Development, Purchasing / Michael Doroski / FPGA logic design, Digital/Analog Interfacing
Adam Van Fleet / Team Lead, Documentation and Electrical System Support
Andrew Weida / Bluetooth Systems Development, GUI Development / T.J. Antonoff / USB Systems Development

Proceedings of the Multi-Disciplinary Senior Design Conference Page 5

Abstract

The goal of this project was to design and implement a functional interface for the multi-purpose driver/data acquisition system previously developed by P08311. This interface will allow for data acquisition via two different communication channels: USB and Bluetooth. The design should also allow for future expansion into Wireless USB and Ethernet communication channels. Motivation for this work stems from the desire for real-time data acquisition of critical systems in robotics. The desired result of the system design is to transfer a known data file via the FPGA based interface system to an ASIC or Robotic unit (for data manipulation), and to later receive the manipulated data to be stored in an additional file (stamped with the transfer device, transfer rate and packets lost). Major goals achieved included the re-design of the interface between the data acquisition board and FPGA, evaluation and implementation of the above-mentioned communication channels between personal computer (PC) and FPGA, and the design of a graphical user interface (GUI) on a PC.

Nomenclature

ADC: Analog to Digital Converter

ASIC: Application specific integrated circuit

DAC: Digital to Analog Converter
DAQ: Digital Acquisition

FIFO: First in First Out

FPGA: Field Programmable Gate Array

FTP: File Transfer Protocol

GUI: Graphical User Interface

HTTP: Hyper text transfer protocol

VHDL: Programming Language

KSp/s: Thousands of Samples per seconds

I/O : Input-output

PC: Personal Computer

PCB: Printed Circuit Board

PPB: Ping-Pong Buffer

OS: Operating System

RAM: Random Access Memory

MUX: Multiplexer

RS-232: Recommended Standard 232

DTE: Data Terminal Equipment

DCE: Data Circuit-terminating Equipment

CSV: Comma Separated Value file

introduction

The objective for the interface redesign was to increase the data transfer speed of the FPGA/DAQ system, as well as allow for Bluetooth and Wireless USB communication channels to be utilized. The original interface incorporated a Virtex-4 FX FPGA board for control logic, which required the use of compact flash memory storage. Because the data had to be stored before being transmitted or received, the original interface design team was only able to obtain transfer rates on the order of bits per second. In order to meet customer specifications for ASIC and robotics applications, however, the transfer rate is required to be on the order of kilobits per second (at a minimum). Ideally, the transfer rate would be in the megabits per second scale, as limited by the hardware capabilities.

Under development by this design team, the Xilinx Spartan-3 FPGA was selected to eliminate the requirement of flash memory storage while maintaining required pins and programming capabilities. Customer specifications were reissued to the minimum data transfer rates in the kb/s range, with the potential for additional Bluetooth or USB module expansion. From these requirements and system modifications, the design team began development.

process

A list of customer needs and project specifications drove the design and development of the project. Each need is a general requirement of the project capabilities, while the specifications attribute a measurable value to a customer requirement. The needs and specifications are shown in Figure 1 and Figure 2 respectively:

need / description
CN1 / Interfaces DAQ to FPGA
CN2 / Interfaces FPGA to PC
CN3 / Transfers data from data file
CN4 / GUI shows connection settings, speed and status, contains a data storage system and can select between devices.
CN5 / FPGA is interchangeable
CN6 / Option for multiple communication devices to improve transmission rate.
CN7 / Control Logic programmed in VHDL

Figure 1: Customer Needs

Spec. / description
ES1 / USB min. transfer rate of 1.5 Mb/s
ES2 / Bluetooth min. transfer rate of 1.2 kb/s
ES3 / 100% Data packet transfer
ES4 / 12-bit Analog data resolution
ES5 / 16 analog data channels utilized (as designed on DAQ)
ES6 / 12 digital data channels utilized (as designed on DAQ)
ES7 / Analog sampling rate of 20 kHz

Figure 2: Customer Specifications

By customer design, the DAQ requires the ability to handle a 10 kHz or less signal frequency for incoming data. In order to prevent aliasing, Nyquist’s Theorem is used to calculate the necessary sampling frequency to be implemented in the FPGA/DAQ system, found to be at least 20 kHz. By the theorem, the sampling frequency (Nyquist rate) must be greater than or equal to twice the signal frequency. This is shown in Equation 1:

(1)

The FPGA contains 216kb of block RAM and 16Mb of additional on-board memory. Utilizing the 16Mb would require an additional level of hardware and software development, for which the time was not available. To utilize the 216kb of buffer space, however, we follow equation 2:

(2)

By the equation, we can transfer data as long as we desire if the input rate is less than or equal to the output rate. For the Bluetooth device, this means limiting the input rate to less than the 330 kb/s that is theoretically achievable. For the USB device, which can transfer data at 8.0 Mb/s, we may input data to the system much faster.

To calculate the “Full Load” transfer rate of the system, we first used equation 3 to find the maximum digital data rate (2,880 kb/s). Afterward, we used equation 4 to calculate the analog data rate maximum (4,320 kb/s). Finally, we added the two to find the full system maximum data transfer rate (7,200 kb/s), as shown below:

(3)

(4)

(5)

These calculations inform us that in order to handle the system under full load, we must provide at least a 7.2 Mb/s output transfer rate.

The core of the system consists of an input and output subsystem. Each subsystem has two FIFO buffers set up in a ping pong scheme, as well as a state machine. The state machine is designed to either condense the data in packets and prepare it for being applied to the DAQ, or receive data from the DAQ and packetize it for transmission. The ping pong FIFOs consist of two normal FIFOs, each with a wrapper around them, controlling which FIFO is being read to and which is being written to. The basic functionality of these ping pong buffers is that only one of the internal FIFOs will be read from and one written to. When the one being written to becomes full, it switches roles, thus allowing it to be emptied while the other one gets filled. This scheme allows for the reading and writing of data to the FIFOs at the same time while insuring data order and integrity.

The digital interface effectively reads or applies voltages according to an onboard clock. The module itself is basically two processes, a read process and a write process. The read process will read the current state of the outputs of the ASIC on the rising edge of the internal clock and will write them to the internal FIFOs for sending after two samples are attained. Similarly, the read process will first read in data from the FIFOs then, over the course of two clock periods, apply the voltage on the rising edge.

The analog hardware interface is more complicated than the digital interface. In order to communicate with both the ADCs and DACs, several signals need to be generated on the FPGA, specifically a serial communication clock, a synchronization signal, and a load signal. The serial communication clock controls the speed of the communication from the ADCs and to the DACs. The synchronization signal controls when the ADCs convert a voltage and when a new sample is loaded into the DACs. Finally, the load signal resets the counter that acts as a select on the analog multiplexers and to update the voltage outputs of the DACs. In order to communicate with these devices, the overall analog interface utilizes both an ADC interface and a DAC interface. Over the course of 20 cycles of the serial communication clock (SCLK), the analog signals are converted to digital signals and digital signals to analog signals.

The Bluetooth module that was selected was the Parani-ESD 1000. The Parani enables wireless serial communication using Bluetooth technology and can communicate with other Bluetooth devices that support the Serial Port Profile. The Parani-ESD delivers better quality of communication than a standard RS-232 cable in working distances of 100m with the default antenna. Communication with the FPGA is achieved via RS-232 interface. RS-232 is a standard for serial binary data signals connecting between a DTE and DCE, most commonly used in serial ports. The format is asynchronous and self-synchronizing. Each byte is sent and received serially and independently from one another. When transmitting a character over an RS-232 interface, a start bit (0) is first sent, followed by the data bits (generally 8, but could be 5, 6, 7, or 8 bits). The bit stream starts with the LSB, continuing up to the MSB, and is followed by a parity bit for error checking (if parity is enabled). Finally, a stop bit (1) is sent, which can be 1, 1.5, or 2 bit lengths. The duration of each bit is equal to 1 sec / Baud Rate. The sequence is repeated for each byte sent, but the line may remain idle (1) for any duration.

Figure 3: RS-232 Character Transmission

Figure 4: RS-232 Timing Diagram. Transmission = String A2 = 01000001 00110010

The baud rate of a data communication system is the number of symbols per second transferred. A symbol can have more than two states, so it may represent more than one binary bit. Therefore the baud rate may not equal the bit rate. What baud really refers to is the modulation rate or number of times per second that a line changes state, as shown in Figure 3. From Figure 4, it is possible to see that the line changes 10 times for 8 data bits sent. Therefore the maximum effective bit rate (no parity, 8 data bits) is effectively Baud Rate * 0.8. This means that the theoretical maximum transfer rate though Bluetooth is 460800 * 0.8 = 368640 bits/s = 360 kilobits/s. Note that the baud rate of 921600 is not supported due to limitations of the FPGA clock speed as the baud rate generator in the FPGA is limited to 460800 by the 50Mhz clock on the Spartan 3. It should also be noted that to support the 460800 baud on the PC a USB to Serial Cable is needed as a typical COM port on the PC is limited to 115200 baud. Implementing the RS-232 Transmitter in HDL is a relatively simple task. The transmitter consists of a timer that generates ticks at the baud rate and a 10 bit shift register with the right-most bit connected to the TX output. To transmit a new character byte the shift register is loaded with 1 – byte – 0. The data is then shifted right ten times at each tick, shifting in a 1 from the left. When done shifting, it is ready to send another character. Designing an RS-232 is a little more complicated. A tick generator that can be restarted on demand and generate ticks at half bit period is required in addition to a shift register. The tick generator should be kept at zero, until the line goes low, signaling the beginning of the start bit. Loop 10 times: wait for the tick (mid-bit), Right-Shift in the data line (RX) in the register. If the last stop bit is reached exit the loop, otherwise just wait for the tick (end of bit). At the end of the loop the register’s MSB must be 1 (stop bit), otherwise there is a problem just as the line not being synchronized or incorrect baud rate.

The UART functionality was verified using a simple application created on the FPGA that simply read all data from the RX line, processed it and sent it out the TX line. The application that processed the data detected if the incoming data was numeric and memorizes the value as the offset (initially set to 0). Any characters that were received were incremented by the offset and sent out TX line. The FPGA’s serial port (with the UART and application loaded on it) was connected to the serial port of a PC with HyperTerminal and data was sent to the FPGA using character input from the keyboard. Results were as expected: upon initializing the serial connection any keyboard input sent have echoed back to HyperTerminal. If the offset was changed by entering numeric data, 2 for example, characters echoed back would be offset by two. This means that “Hello World” entered into HyperTerminal echoed back as “Jgnnq Yqtnf”.

The DAQ PC Interface was developed with Visual Studio 2008 using C#. Control of PC’s serial ports was obtained through the Microsoft .NET Framework Class Library’s System.IO.Ports Namespace. The main reason for selecting C# as our development language was due to the ease of serial communication through the System.IO.Ports Namespace. The most important class of this Namespace, SerialPort provides a framework for synchronous and event-driven I/O, access to pin and break states, and access to serial driver properties. It can be used to wrap Stream objects, allowing the serial port to be accessed by classes that use streams. The namespace includes enumerations that simplify the control of serial ports, such as Handshake, Parity, SerialPinChange, and StopBits. When data is received through the port a SerialDataReceivedEvent is thrown. To consume the SerialDataReceivedEvent an event handler was written that executes program logic in response to the event and registers the event handler with the event source. The event handler obtains the number of bytes waiting in the port’s buffer using the SerialPort.BytesToRead method. It then creates a byte array buffer to hold the incoming data and reads the data from the port and stores it in the byte array using the SerialPort.Read method. The data is then reassembled. Packet structure that is used between that DAQ board and PC is shown below in Figure 5.