Over the last five years, Bluetooth's growth has been undeniably
phenomenal. However, most consumers still think of Bluetooth as a
wireless communication medium for cellphones to talk to headsets.
Although this is still largely true, Bluetooth is finding its way
into more routine forms of communication such as industrial data logging.
This article discusses the design of a Bluetooth data logger that
takes data from an AS1530 12bit ADC via an MCU and a Bluetooth link to
a PC, which collects the data in a spreadsheet.
The trend in industrial process control has been to
reduce the communications wiring across a plant with parallel data,
paving the way for serial "Profibus" data. This
design extrapolates
that trend and completely removes the communications wiring.
The data logger circuit has an AS1530 ADC
connected to a PIC MCU
that communicates via an RS-232 cable to a BlueGiga
WT12 Bluetooth
module. This module transmits data over the Bluetooth link to a
second
identical BlueGiga WT12 module connected via an RS-232 cable to a PC
running a Windows program written in Visual Basic Version 6 (Figure 1 below). The Windows program
loads the received data into an Excel spreadsheet for results to be
analyzed and graphed.
The data logger is powered from a 5V bench power supply. To ensure
safe operation of the MCU, the logger power supply is monitored using a
very lowpower supervisor, the AS1904.
This device typically consumes 150 nA of supply current. The current
consumption of the data logger circuit is measured at 16mA, and the
average current consumption of the BlueGiga module is specified as
44.7mA. So if the whole circuit has to be powered from a linear regulator, an AS13985
150mA low dropout linear regulator would more than suffice.
Analog front-end
The analog front-end consists of a 12 bit successive
approximation register (SAR)
ADC such as the AS1230. If the input signal is less than the supply
voltage of the ADC (in this case, 5V) and of suitably low source
impedance, it can be fed directly into the ADC's input.
The ADC's input circuit can be modeled as a simple RC circuit,
with R representing the source impedance of the signal and C the
sampling capacitor of the ADC. An RC circuit under charge is
represented by the equation:
where Vmax is the charging voltage and V is the voltage
across the capacitor. The sampling capacitor is 18pF and the sampling
time (t) is 390ns.
Now, the worst-case change in voltage that the ADC input has to deal
with is when one input channel is set at 0V, and the adjacent channel
is set at 2.5V. In this case, the input capacitor has to charge to 2.5V
within an accuracy of half LSB in 390ns.
This yields a minimum source impedance of R = 2.4 kohms. Now, the
input impedance of the mux is 800 ohms, so the source impedance of the
signal has to be less than 1.6 kohms. If the source impedance of the
signal to be digitized is too high, it can be amplified and/or buffered
using an op amp.
The PIC16F627 MCU reads data
into and out of the AS1530 using an SPI with a chip select (CSN),
serial clock (SCLK), data input (Din) and data output (Dout). The CSN
line frames the data, while data is clocked into and out of the device
using the rising edge of the SCLK line.
The data stream is made up of eight control bits that select the
input channel, the input range and the power mode, and 16 subsequent
bits that contain the output data. Once the conversion is completed,
the ADC goes into its programmed power mode (full power down, reduced
power or normal operation).
To achieve the desired accuracy, pay close attention to the board
layout and decoupling of the supply pins to the chip and the reference.
The analog and digital supplies must be kept separate, although both
supplies can originate from the same source.
This is best achieved by routing two tracks from the main board
supply, a thick track to the analog supply (pins VDD1 and VDD3) and the
same for the digital (pin VDD2). The current taken by the digital
supply modulates a voltage onto the digital supply line.
If this also powers the analog supply to the chip, this voltage
modulation could corrupt the LSBs of the ADC. Providing separate
supplies eliminates this problem.
The ground supply to the AS1530 is just as important as the analog
and digital supplies. A thick track running from the GND pin to the
main board supply ground provides low impedance for the return current
and is essential for best performance.
Decoupling capacitors should be placed close to each of the analog
and digital supply pins of the chip, with their ground connections
close to the GND pin of the AS1530. This ensures that the AC voltage
seen across the power supply pins of the chip remains at zero.
A 10 microfarad tantalum capacitor in parallel with a 100
nanofarad ceramic provides optimum broadband attenuation of any noise,
which may appear on the line and provide a low impedance path for any
current surges that may be demanded by the AS1530.
This design uses the internal reference of the AS1530. If an
external reference is desired, it needs to be decoupled with a local
low-impedance capacitor of 4.7 microfarads close to the REF pin. The
input impedance to the reference pin of a SAR ADC changes with digital
code due to it being connected directly to the R-2R ladder.
 |
| Figure
1. The program replicates Microsoft HyperTerminal and handles the
search, connection and disconnection of the link with the data logger. |
Software end
At the data logger end, the MCU is a PIC16F627A. Its code is written in
C using a Hi-Tech C compiler. The MCU's internal UART is set to a baud rate of
115.2Kbps to match the default baud rate of the Bluetooth module. Data
is sent over the RS-232 link via an industry standard (2Tx/2Rx) level
translator.
All communications to the Bluetooth modules are done over an RS-232
interface. As with many things in life, the simple aspects can cause
the most hardship, and RS-232 is no exception.
In the days when the RS-232 specification was
written, computers were called terminals and they sometimes linked to
communication devices like modems. Hence, it was decreed that two types
of equipment could be used to connect to each other using the RS-232
standard.
These were the data terminal equipment (DTE) and data communication
equipment (DCE). It was not surprising that computers (or terminals)
were configured as DTE, and most devices that connect to them were
configured as DCE (like modems).
They were mostly connected using a standard nine-way RS-232 cable,
with each pin at one end connected through its associated pin at the
other end. No wires cross over inside the cable.
Now, DTE sends data out on pin 3 and receives it on pin 2. On the
other end, DCE receives data on pin 3 and transmits on pin 2. There are
two other signals used in 90 percent of the RS-232 applications: ready
to send (RTS) and clear to send (CTS).
Putting Bluetooth to work
Both devices at each end of the cable have an RTS and a CTS signal. The
RTS at one end connects directly to the CTS at the other end and vice
versa. The RTS is an outgoing signal, while the CTS is an incoming
signal.
Before any data is sent, both ends set their RTS lines (as they are
both free to send and receive data). If the transmitter asserts RTS,
this in turn asserts the CTS line at the receiver since they are
directly connected.
When the transmitting device starts to send data, it de-asserts its
RTS line, hence de-asserting the CTS of the receiver. De-asserting the
CTS tells the receiver that it is not clear to send data. This tells
the receiver to hold off transmitting any information.
If the transmitter sends too much information (and overloads the
receiver), the receiver is free to de-assert its RTS line (de-asserting
the CTS line of the transmitter) to indicate the transmitter to stop.
The Bluetooth module is configured as DCE, so the MCU at the AS1530
end is configured as DTE. Thus, it transmits its data on pin 3 and
receives it on pin 2. It also uses RTS/CTS handshaking, transmits RTS
on pin 7 and receives CTS on pin 8 of the nine-way connector.
It should be noted that if the MCU is to be connected to
HyperTerminal on the PC (for testing), the Tx and Rx lines need to be
swapped over, as do the RTS and CTS lines. This converts the MCU from
DTE to DCE.
A standard RS-232 level translator was used to interface the MCU
with the RS-232 data line. It should also be noted that a carriage
return is needed at the end of every command sent to the Bluetooth
module.
This simple instruction is overlooked when typing on a keypad. If it
is not sent, the designer will have hours of undeserved diagnostics as
to why the module is not behaving itself.
Programming the Bluetooth
module
The Bluetooth module has the facility to be programmed with a
"friendly" name, allowing other Bluetooth devices to identify it by
something other than its 12- digit hex address. When the data logger
powers up, the 16F627A programs the Bluetooth module at the data logger
end to have a "friendly" name of AMS_ADC.
The Windows program was written in Visual Basic Version
6. The program replicates Microsoft HyperTerminal and handles the
search, connection and disconnection of the link with the data logger. Figure 1 earlier shows the Windows
screen.
The text screen in Figure 1
shows the message from the Bluetooth module once it has been reset. On
the left are the controls needed to communicate with the Bluetooth
module. After reset, the user clicks the Inquiry button, which tells
the Bluetooth module to send out an inquiry looking for all local
Bluetooth devices (Figure 2 below ).
 |
| Figure
2. After reset, the user clicks the Inquiry button, which tells the
Bluetooth module to send out an inquiry looking for all local Bluetooth
devices. |
Clicking the Inquiry button writes the text "INQUIRY 10 NAME" to the
Bluetooth module, telling it to wait for 10s before timing out and
inquiring for all the "friendly" names of the local Bluetooth devices.
The Bluetooth module then echoes back how many devices are found,
their 12-digit hex address and friendly names. It can be seen that the
device AMS_ADC has an address 00:07:80:80:c2:11.
The user highlights this address and copies it to the Address:
window. By clicking the Call button, the Windows program sends out a
CALL command to this address, and this is shown by the line: CALL
00:07:80:80:c2:11 1 RFCOMM.
The Bluetooth device echoes back with a CALL 0 statement, telling
the user that a CALL has been initiated. Once communication with the
remote logger has been established, a CONNECT statement is returned.
Once a connection is established, all future text is generated by
the data logger and not the Bluetooth module. The data logger then
sends out the text "LOGGER CONNECTED" to show that communication has
been established with the AS1530. The Windows program also opens a file
called C:\AMS_ADC.xls and loads the received data into it.
The user then clicks the Start Logging button to clear the screen
and switch the program to receive data and not text. All future data
received is loaded into the C:\AMS_ADC.xls file.
The Windows program also allows the users to override the command
buttons and enter their own text. The Clear Window button is clicked to
clear the text screen. Entering text in the text screen and then
clicking the Manual Text Entry button downloads all the text on the
text screen to the Bluetooth module.
Clicking the Close Link button sends the command "+++" to the
Bluetooth module, telling it to terminate the link. The Bluetooth
module then drops the link and returns a message telling the user the
link has been lost.
 |
| Figure
3. The data logger circuit has an AS1530 ADC connected to a PIC MCU
that communicates via an RS-232 cable to a BlueGiga WT12 Bluetooth
module. |
Figure 3 above shows the
circuit diagram of the data logger end. The PC end is simply a BlueGiga
WT12 evaluation kit connected to the PC via an RS 232 cable.
The software has been written in a way that enables easy expansion
of the system to allow the user to interrogate multiple data loggers.
The software in the data logger can be improved to enable it to
better handle commands from the host PC. Thus, it enables the PC to set
the friendly name, and the user to poll and/or reset the system.
Simon Bramble is austriamicrosystems North
European Applications Engineer. For a PDF version of this story, go to "Data
logging goes wireless."
