Wireless Data Acquisition using Bluetooth

Mohammed Rana Basheer

Department of Electrical and Computer Engineering

University of Missouri-Rolla

World without wires

Over the years wireless technology has been promising a world without wires but look around, you will see lots of interconnecting wires. Look at your good old PC isn’t it cluttered with wires? Wires connecting your PC to the printer, scanner, mouse, keyboard etc. It is a total mess. Some initial solutions using short range wireless connectivity with frequencies in the scientific, industrial and medical bands has resulted in some success in reducing this mess but there was very little scope for interoperability between devices due to their proprietary standards. A printer and a laptop could only be interconnected if they are bought from the same manufacturer. These and a host of other problems made these initiatives less feasible. But this is going to change for better. Bluetooth technology, originally developed by Ericsson but now controlled by the Bluetooth SIG (Special Interest Group), a consortium of 1000+ tech companies, offers the promise of a global standard for short range wireless communication between an ever-increasing variety of devices and peripherals.

The fancy name for this short-range wireless connectivity protocol comes from the tenth-century Viking king, Harald Bluetooth, who united Scandinavia after years of fighting and destructive competition. Today Bluetooth is following the same symbolic path to establish a common platform for communicating between disparate types of computing devices. Beyond the colorful origin of its name, Bluetooth is a compelling new radio technology that opens up a new world of opportunity for uniting and empowering mobile device users.

Bluetooth Specification in Brief

· Maximum data rate 750 kbps

· Master-Slave communication model..

· Operating Frequency is globally available 2.4-2.5 GHz free ISM band with spread spectrum technology

· Frequency hopping, full duplex signal at 1600 hops/sec.

· 79 frequencies with 1 MHz interval to provide noise immunity

· A device can be master of 7 slaves forming network called piconet. Several piconets can interconnect to form a large network called scatternet.

· Royalty free standard

ROK 101 007 is a Bluetooth module from Ericsson and in this article I will demonstrate how this module could be interfaced to an 8051 microcontroller variant from Cygnal C8051F022. Since this microcontroller comes with a built in ADC and DAC, my circuit could be used as a wireless analog data acquisition and generation unit. I am currently using the board shown in figure 3 as “smart sensor” for my master’s thesis work. Smart sensors are nothing but a bunch of analog sensors connected to a microcontroller which provides some local processing of collected data before sending it to the master unit. These modules are interconnected by a low power short range wireless network forming what is called ad-hoc networks.

ROK 101 007 TO THE RESCUE

Years ago when I built my first robot, wireless communication was a big issue. I used an AM transmitter/receiver working at 330 MHz as my short range wireless data link, though plagued with lot of data transmission errors it provided me with an almost reliable half duplex point to point wireless link. But as my ambition grew and thought about building a cooperative network of robots, my temporary solution was not enough. I was on the lookout for a more concrete solution which can provide me the ability to wirelessly network my robots and at the same time provide a uniform standard so that I could write my networking protocol above this standard without the hassle of rewriting it each time I buy a new wireless device from some other vendor.

I was introduced to ROK 101 007 as a part of my master’s thesis work and suddenly I realized that this tiny beast is what I have been looking for. ROK 101 007 offered me all that I bargained. A reliable full duplex communication link, ability to form small networks called piconets, compliant with Bluetooth version 1.0B, low power consumption and has a range of 10 meters (0 dBm). Though priced slightly at the higher range of 70 USD a piece, it is expected to come down to 5 USD a piece when the technology catches up. The module is very compact with a dimension of 3.3 x 1.7 x 0.365 cm. The golden colored metal covering in figure 1 provides excellent RF shielding. It also has a 50Ω antenna interface for the best signal strength performance. The only problem with this module was that it is hard to solder. Its leads are beneath the module and I did not have the equipments to do that kind of surface mount soldering. So I attached my module to my PCB using wires as shown on figure 3.d

Figure 1. ROK 101 007 Module. (Top View)

Figure 2. Bottom view and dimension. (Leads protrude from beneath the module making it very difficult to solders.)

Figure 3. Data acquisition board (Notice the yellow wires protruding from beneath the bluetooth module)

ROK 101 007 Internals

Three major sections constitute the ROK 101 007 module a baseband controller, flash memory and a radio that operates at the globally available 2.4-2.5 GHz ISM band. The baseband controller includes firmware for Host Controller Interface (HCI) which handles all communication with an external host such as a microcontroller. The host and the baseband controller communicate with each other through an UART or an USB interface.

The UART implemented on the module is an industry standard 16C450 and supports the following baud rates: 300, 600, 900, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400 and 460800 bits/s. TxD and RxD pins provide the data flow while RTS and CTS are used for the flow control.

The USB is a high speed (12 Mbps) slave device which is compliant with USB specifications 1.1. Data transfer occurs through the bi-directional ports, D+ and D-. Additionally two side band signals wakeup and detach are also provided for proper interface with host such as laptops or microcontrollers which employ power management features. The flexibility in using either the UART or the USB interface makes this module ideal for interfacing with a variety of microcontrollers.

Since my objective was to interface ROK 101 007 to a Cygnal microcontroller, C8051F022, which did not have any USB interface I had no option but to go for the ubiquitous serial communication interface, UART. But using UART has a speed penalty. The maximum baud rate possible through UART interface is only 460.8 kbps which is less than the theoretical maximum baud rate of 760 kbps specified in the Bluetooth specification. Another practical problem that I faced was that my microcontroller is not fast enough to generate such high baud rate of 460.8 kbps so I programmed my microcontroller’s UART to send data at the default baud rate for ROK 100 007 which is at 57.6 kbps, further reducing the communication speed. By default baud rate I mean the baud rate ROK 101 007 module’s firmware configures its UART after a reset. To achieve higher baud rate the module could be configured through software to one of the supported higher values. These configuration settings are send through the serial interface to the Bluetooth module at the default baud rate. Hence any microcontroller acting as the host should support a baud rate of 57.6 kbps.

ROK 101 007 supports two types of connections Asynchronous Connectionless Link (ACL) for data and the synchronous connection oriented link (SCO) for voice. Since I was more interested in transmitting data rather than voice the software that I wrote supports only ACL links.

Figure 4. ROK 101 007 block diagram

Pin Description
Pin	Pin Name	Type	Direction	Description
A1	PCM_IN	CMOS	In	PCM data, see notes 7,9
A2	PCM_OUT	CMOS	Out	PCM data, see notes 7,9
A3	PCM_SYNC	CMOS	In/Out	Sets the PCM data sampling rate, see notes 7,9
A4	PCM_CLK	CMOS	In/Out	PCM clock that sets the PCM data rate, see notes 7,9
A5	RXD	CMOS	Input	RX data to the UART, see note 9
A6	RTS	CMOS	Input	Flow control signal, Request To Send data from UART, see notes 7,9
B1	D+	CMOS	In/Out	USB data pin, see notes 9,10
B2	D-	CMOS	In/Out	USB data pin, see notes 9,10
B3	GND	Power	Power	Signal ground
B4	WAKE_UP	CMOS	O utput	Indicates that the modules wants to be attached to the USB, Active High, see notes 9,10
B5	TXD	CMOS	Output	TX data from the UART, see note 9
B6	CTS	CMOS	Output	Flow control signal, Clear To Send data from UART, see note 9
C1	DETACH	CMOS	Input	Indicates that the USB wants to detach the module, Active High, see notes 7,9
C2	ON	Power	Input	When tied to Vcc the module is enabled
C3	I2C_CLK	CMOS	Output	I2C Clock signal, see note 9
C4	VCC_IO	Power	Power	External supply rail to the Input/Output ports
C5	NC	-	-	Do not connect
C6	VCC	Power	Power	Supply Voltage
R1	GND	Power	Power	Signal ground
R2	GND	Power	Power	Signal ground
R3	RESET#	CMOS	Input	Active low reset, see notes 8,9
R4	NC	-	-	Do not connect
R5	NC	-	-	Do not connect
R6	NC	-	-	Do not connect
T1	GND	Power	Power	Signal ground
T2	ANT	RF	In/Out	50Ω Antenna Connection
T3	GND	Power	Power	Signal ground
T4	NC	Power	Power	Test point, internal voltage regulator-Do not connect
T5	NC	-	-	Do not connect
T6	I2C_DATA	CMOS	In/Out	I2C data signal, see note 9

NOTES

Figure 6. Pin Layout. (Bottom view)

1. Current consumption is based upon when the module is when ‘ON’ is low and ‘VCC_IO’ is grounded.

2. During the TX mode, the VSWR specification states the limits that are acceptable before any other RF parameters

3. are strongly effected, i.e. frequency deviation and initial frequency error.

4. Frequency deviation measurements are now recorded differentially, (f Mod1 - f Mod0 ) / 2.

5. Provided that the TX INV register (bit 0) has been set in the enable register at startup.

6. Tolerance for the system clock takes into accounts both the complete temperature range and aging of the crystal.

7. LPO_CLK frequency is pre-trimmed within a tolerance of ±250ppm.

8. 100k. pull-up resistors to VCC_IO are used on the module. PCM signals direction is programmable

9. RESET# signal must be fed from an open drain output.

10. CMOS buffers are low voltage TTL compatible signals.

11. To be compliant with the USB specification, VCC_IO = 3.11V

CONTROLLING ROK 101 007

Data and Parameter Format

The software that is provided along with this article enables the setting up of a simple piconet using the HCI commands. The HCI provides a uniform command interface to the baseband controller, link manager and also to hardware status registers. The different groups of commands supported by HCI are:

1. Link Control & Policy Command

2. Host Controller & Baseband Command

3. Informational Commands

4. Status Commands

5. Testing Commands

The HCI link control and Policy commands provide the host with the ability to make connections to other Bluetooth devices in its vicinity. The Host Controller & Baseband, Informational and Status commands provide the Host to access various registers in the Baseband Controller. Testing Commands as the name suggests provides the ability to test various functionalities of the Bluetooth hardware.

The structure of an HCI command packet is as shown below. The maximum size of an HCI command packet is 255 bytes. According to Bluetooth specification all parameters had to be send or received in little-endian format. This means a hex word like 0x1234 is send/received as (0x34 0x12). If you are writing the Bluetooth controlling software in windows environment there is no need for endian conversion while the Keil compiler I use for the 8051 microcontroller uses big-endian format and needs conversion to little-endian before the parameters could be transferred to the Bluetooth module.

Figure 6. HCI Command Packet

· OpCode (2 Bytes): Uniquely identifies different types of commands. It is divided into Opcode Group field (OGF) and Opcode Command Field (OCF). OGF identifies the different groups of command as mentioned above while OCF identifies a command within a group.

· Parameter Total Length (1 Byte): Length of all parameters contained in the packet measured in bytes.

· Command Parameters: Each command has a specific number of parameter associated with it. These parameters and the size of each of the parameter are defined for each command.

Since the HCI commands take different time to complete, the result of a command is reported back asynchronously in the form of event packets. For e.g. Most of the commands will return the Command Complete event with necessary return parameters piggy backed on it. The maximum size of such an event packet is up to 255 bytes. The format of an HCI Event Packet is shown below.

Figure 7. HCI Event Packet

· Event Code (1 Byte): Used to uniquely identify events.

· Parameter Total Length (1 Byte): Length of all parameters contained in this packet, measured in bytes.

· Event Parameters: Each event has a specific number of parameters associated with it. These parameters and the size of each of the parameter are defined for each event.

Most of the HCI commands receive Command Complete event on completion of execution of that command but some of the commands such as “CreateConnection” command, which is issued for establishing a connection with the remote Bluetooth device, do not return the command complete event instead they receive the Command Status event when it has started executing the command. On completion of the action associated with the command, which in this case is the rejection or the acceptance of the connection request by the remote Bluetooth device, an event (Connection Complete) associated with the sent command(CreateConnection) is send to the host. But if the command status event has returned an error then the event associated with the command will not be send. The command status event in this case will return an appropriate error code.

The third type of packet the HCI layer handles is the data packet which is used to exchange data between Bluetooth modules. Data packets are associated with both ACL and SCO data types. There can be only one ACL connection between two Bluetooth modules while three simultaneous 64kbps SCO link could be setup between any two Bluetooth modules. The format of the HCI ACL data packet is as shown below.

Figure 9. HCI ACL Data Packet

· Connection Handle (12 Bits): An ACL connection with any remote Bluetooth module is uniquely identified by the connection handle. This handle is received in the “ConnectionComplete” event after a “CreateConnection” command or “AcceptConnection” command has been issued and the connection was successfully completed.

· Packet Boundary Flag (2 Bits): Identifies whether this packet is a fragmented packet of a higher layer or it is the first packet of a higher layer.

Value	Parameter Description
00	Reserved for future use
01	Continuing fragment packet of Higher Layer Message
10	First packet of Higher Layer Message (i.e. start of an L2CAP packet)
11	Reserved for future use

· Broadcast Flag (2 Bits): Identifies whether this packet is a broadcast to all the active slaves or a broadcast to all the slaves in the parked mode (low power) mode or just a point to point transmission.

· Data Total Length (2 Bytes): Length of data measured in bytes.

SCO packets are used for transmitting voice data. As mentioned earlier ROK 101 007 can support three simultaneously 64 kbps voice channels. The format of an HCI SCO connection is shown below.

Figure 10. HCI SCO Data Packet.

In short the four kinds of HCI packets that can be sent via the UART are HCI Command Packet, HCI Event Packet, HCI ACL Data Packet and HCI SCO Data Packet. Command packets can only be send to the Bluetooth module, HCI Event Packets can only be send by the Bluetooth module to the Host microcontroller while the HCI ACL and SCO data packets can be send in both the directions. Since all these packets are send via a common physical interface which in this case is our UART a packet indicator is used to identify the packet type. The packet indicator is the first character that will be send through the serial interface before the data corresponding to that packet is send. This helps the receiver to identify the format of the subsequent data arriving via the UART.

HCI Packet Type	HCI Packet Indicator
Command	0x01
ACL Data	0x02
SCO Data	0x03
Event	0x04

Figure 11. HCI UART Packet Identifiers

HCI State Machine

Like most protocol, the communication with the HCI layer can be implemented effectively with a finite state machine. Figure 12 shows the HCI state machine I implemented, with circles representing states and arrows representing transitions between them. The label on each transition shows what HCI receives to cause the transition. The software starts in IDLE state. On reception of an appropriate packet identifier the state machine switches to ACL_HDR, SCO_HDR or the EVT_HDR state. In this state the HCI state machine receives the packet header. The header contains information about the size of the data packet following it or the size of the parameters in case of events. After reading this information the state machine switches to ACL_DATA, SCO_DATA or EVT_DATA state. In ACL_DATA or SCO_DATA state the data packets are read and stored on a buffer while in the EVT_DATA state the event parameters are read and action taken on them. Currently the software does not handle SCO data packets. Hence when a SCO packet indicator is received, the data and header that follows the SCO packet indicator is simply dropped. The ACL data is stored on a 255 byte ACL data buffer and when the buffer overflows the HCI flow control mechanism prevents further data being send to this Bluetooth device till the application program start empting the data from the ACL data buffer.

Figure 13. HCI State Machine.

How the code works

The entire source code is written in C compiled using the Keil 8051 compiler. The most important component of the software is the implementation of the HCI finite state machine. You can find the complete implementation of HCI state machine in HCI.c file. “HCI_event_handler” function is the entry point for this state machine. The global variable “hci_current_state” holds the current state of the state machine. “HCI_event_handler” function is periodically called from a timer interrupt service routine which is set to a moderate period of 2ms. This will ensure that the HCI state machine will work in the background while the application program can work in the foreground. All the HCI events are handled by the state machine in the “process_event” function. Since this is a minimal Bluetooth implementation only some of the HCI event handlers are implemented.

It is very interesting to study the sequence of events that will result in a connection being established with another Bluetooth device. After hard reset the microcontroller sets up its UART for 57.6 kbps baud rate and also starts a periodic timer. The timer interrupt service routine calls the state machine entry point function “HCI_event_handler” periodically.

The ROK 101 007 Bluetooth module’s firmware is written to configure its UART to 57.6 kbps baud rate after hard reset. Since both devices are configured at the same baud rate they are now ready to talk. In order to initialize the Bluetooth module’s buffers, the microcontroller issues a soft reset command to the Bluetooth module by sending the “reset” HCI command through the UART. After the Bluetooth module has been reset the immediate task is to setup a flow control between the two devices. Without the flow control there is a high probability of overwhelming the data buffers of the receiver by sending data to it at a rate faster than it could consume. The flow control implemented in Bluetooth module is very simple. Just notify the other one about your limitation. First the microcontroller learns about the Bluetooth modules buffer limitation and then advertises his buffer limitation to the Bluetooth module. The microcontroller issues the “read_buffer_size” HCI command to read the maximum size of the ACL or the SCO packet that could be send from the microcontroller to the Bluetooth module. After that the microcontroller issues the “Host_buffer_size” command to notify the Bluetooth module about the maximum size of the ACL or SCO packet that could be send to it. Now the devices know about each others buffer space limits hence it should segment the data according to theses sizes before sending to the other.

Once the flow control has been setup the Bluetooth devices can enable authentication or setup the encryption to have a more secure communication, but the minimal Bluetooth implementation that I have written does not use any of these. Before the Bluetooth modules can start searching for neighbors to connect, couple of time out parameters has to be setup. These timeout parameters are analogous to the TCP connection timeout parameters.

The final two commands which configures the Bluetooth module to either search for neighbors or just do nothing but wait for a master to connect are the “inquire” command and “write_scan_enable” command respectively. “inquire” command results in the Bluetooth device becoming a master searching for other Bluetooth device in its vicinity to connect while “write_scan_enable” command results in the Bluetooth device periodically scanning for masters who are trying to connect to it. The slave Bluetooth device should not issue the “inquire” command it should stop after the “write_scan_enable” command. The master Bluetooth device should issue both the commands.

The moment a master finds a slave Bluetooth module in its vicinity, “process_inquiry” event handler gets called. One drawback of the Bluetooth module is that the devices have to be in complimentary mode before a connection could be established. That is, one module has to be the master and the other has to be the slave then only a connection could be established. This is particularly bad when you are trying to build a dynamically configuring network where all modules are equal and has to automatically configure to form a network.

As mentioned above the “inquire” HCI command, issued by the master will result in all Bluetooth devices in its vicinity being reported to it through the “process_inquire” event. The default implementation for the “process_inquire” event that I have written is to issue the “create_connection” command to establish a connection with the Bluetooth device that it found. You could provide some value addition to this event handler by checking for the class of the slave device before allowing the connection to be established. The slave will receive the “process_connection_request” event when the master issues the “CreateConnection” command. The slave has the option to reject the connection request or accept it. Again the default implementation that I wrote was to accept the connection. Once again you could check for the class of the master device before accepting the connection. “reject_connection_request” command rejects the connection request while “accept_connection_request” command will accept the incoming connection. But if the slave accepts the connection then both the master and the slave will receive the “process_connection_complete” event signaling the end of the connection establishment procedure. The two Bluetooth devices are now ready to transfer data packets between them.

Once a connection has been established application program can call the “HCI_receive_data” function to read the ACL data packets and use the “HCI_send_to_bd_addr” or “HCI_send_to_handle” function for sending ACL data to a Bluetooth device. “HCI_broadcast” command is also provided to send the data to all the connected Bluetooth devices.

The software along with this article contains a visual C++ based program for real-time plotting of the analog data on a PC. This is in addition to the entire 8051 program for controlling the Bluetooth module written in C. I have used Keil compiler for compiling the C code.

The best part about the source code is that with very minor changes on the supporting files, UART.C and timer.C you can run it on almost any microcontroller. The only requirement is that the microcontroller should be fast enough to generate the required baud rate of 57.6 kbps.

Figure 14. Windows program for real-time plotting of Analog data transmitted by the Bluetooth wireless. (The ADC input is connected to a signal generator producing a damped sine wave)

The Controller

C8051F022 microcontrollers are fully integrated mixed signal System-on-a-Chip microcontroller unit with 64 digital IO pins. It has a high speed, pipelined, 8051 compatible microcontroller core which can provide up to 25 MIPS. With a JTAG (IEEE 1149.1) serial adapter you can have the flexibility of an in-system, non-intrusive debug interface. 64kbytes of in-system programmable flash memory and 4kbytes of on-chip RAM provides enough code and data space for medium sized program to completely reside within the microcontroller and work with no additional hardware. It has a 12 bit, 8-channel ADC and two 12 bit DACs. By adding an external 22 MHz crystal the microcontroller can generate the required baud rate of 57.6 kbps. The operating voltage range for this microcontroller is 2.7V to 3.6V which is entirely within the operating voltage range for the Bluetooth module.

Perhaps the most unique enhancement over other 8051 microcontrollers is the Digital Crossbar. This is essentially a large digital switching network which allows the mapping of internal digital system resources to port IO pins on P0, P1, P2 and P3. The on-chip counter/timers, serial buses, HW interrupts, ADC Start of Conversion input, comparator outputs, and other digital signals in the controller can be configured to appear on the Port I/O pins specified in the Crossbar Control registers. This allows the user to select the exact mix of general purpose Port I/O and digital resources needed for the particular application.

Figure 15. TQFP-100 pinout diagram

Before you can start working with this microcontroller I would suggest you to have some basic development tools. First it will be better to download the latest IDE from the Cygnal website as it provides excellent debugging facilities. You also need the JTAG EC2 serial adapter and the standard JTAG cable for exploiting the full potential of in-system debugging facility. The cable and the serial adapter are available at the Cygnal website for a nominal price.

Figure 16. EC2 JTAG serial adaptor

Figure 17. Standard JTAG serial cable

Circuit Diagram

As you can see from figure 18 the entire circuit is very simple. Bluetooth module and the microcontroller are just the major components in it. Though C8051F022 has an internal clock it is not capable of generating the required baud rate of 57.6 kbps so I have used an external 22.1184 MHz crystal for generating the required baud rate. A 5000mAH 3V non-rechargeable lithium battery was used as the power supply source. You could use two AA batteries to generate the required voltage. The only reason I used lithium battery was for longer life. With lithium battery the entire module is expected to work continuously for at least a week.

C8051F022

Name	Pin Number	Description
VDD	37,64,90	Digital Supply voltage
AV+	11,14	Analog Supply Voltage
VREF0	16	ADC0 voltage Reference Input
VREF1	17	ADC1 Voltage Reference Input
VREFD	15	DAC Voltage Reference Input
AGND	10,13	Analog ground
DGND	38,63,89	Digital ground
P0.0 (TXD)	62	P0.0 of port 0 used as TXD
P0.1 (RXD)	61	P0.1 of port 0 used as RXD
P3.7 (RTS)	47	P3.7 of port 3
P3.6 (CTS)	48	P3.6 of port 3
TDI	3	JTAG test data input
TMS	1	JTAG test mode select
TDO	4	JTAG test data output
TCK	2	JTAG test clock
AIN0-7	36 to 29	Analog to Digital Converter.
DAC0-1	100,99	Digital to Analog Converter.
XTAL1	26	Crystal Input
XTAL2	27	Crystal Output
RESET	5	Device Reset

Figure 18. Circuit Diagram

One important thing to be taken care is the antenna. You could use a traditional whip antenna but such an antennae will be large and obtrusive. I used an integrated inverted F-antenna (IIFA) so that it can be printed entirely on top of the PCB. Figure 19 shows the IIFA geometry the feed point and the ground connection for the antenna.

Figure 19 IIFA geometry

Building the Prototype

There is not much components to be soldered. A double sided PCB was designed and fabricated in our college lab. Care should be taken to avoid any ground or power plane line going beneath the antenna. The first prototype I built had lots of routing mistakes. Tracks were missing, unnecessary pins were connected together overall a result of bad layout design. I corrected them temporarily by breaking some tracks which were not needed and soldering wires were tracks were missing. I hope you will do a better job. The finished board was not so clean but looked cute. I had also provided an expansion memory slot for adding more memory in case if I became ambitious in future. A ten pin standard JTAG male connector was also provided for in-system programming and debugging facility.

Once all the components are placed and double checked for missing tracks and connections, you can download the software onto the microcontroller. First reset the Bluetooth module then start the software. Your Bluetooth module is ready to start sending the data. If you want the data to be seen on real time on your PC the only thing you need to do is remove the microcontroller from the circuit instead connect the UART pins from the Bluetooth module to the RS232 serial port of your PC through a MAX233 chip. Make sure that you interconnect the UART/RS2323 pins in the null-modem fashion.

Conclusion

In future article I will explain how this wireless data acquisition unit can be used to form an ad-hoc sensor network. Ad-hoc sensor networks using Bluetooth will find application in military, chemical industries and lots of other areas were a rapidly deployable distributed data acquisition modules called “Smart Sensors” are needed. Updates, if any on the article will be posted here

Reference

ROK 101 007 Module Specification
C8051F022 Specification
Bluetooth Specification ver 1.1 Feb 22, 2001
Design of Integrated Inverted F Antennas Made of Asymmetrical Coplanar Strips

Author Information

Mohammed Rana Basheer is a graduate research assistant at the Intelligent Systems Center, University of Missouri-Rolla, USA. He can be contacted at ranabasheer[at]hotmail[dot]com