Tomas Marek Semestral Project

______________________________________________________________________
1

USB interface for data recording
from the heat meter

TECHNICAL UNIVERSITY OF LIBEREC
Faculty of Mechatronics, Informatics and Interdisciplinary Studies

Study program: N2612 Electrical Engineering and Informatics
Branch: 2612T071 Engineering of Interactive systems

USB interface for data recording from the heat
meter

Semestral project

Author: Tom MAREK
Project Supervisor: Ing. Lubomr Slavk
Liberec 28.5.2010

2

from the heat meter
TECHNICAL UNIVERSITY OF LIBEREC
Faculty of Mechatronics, Informatics and Interdisciplinary Studies
Institute of Information Technology and Electronics Academic year: 2009/2010
SEMESTRAL PROJECT
Name: Bc. Tom Marek
Program: Electrical Engineering and Informatics
Branch: Engineering of Interactive Systems

Project Name:
USB interface for data recording from the heat meter
Project Supervisor: Ing. Lubomr Slavk

Tasks:
1. Study principle of USB communication
2. Study materials and datasheets of USB circuits of FTDI company and
microcontrollers PIC of Microchip company
3. Design and realize interface module RS232/USB of mass storage type
Literature:
[1] HRBEK, J.: Modern programming of microcontrollers PIC. BEN, Praha 2004,
ISBN 80-7300-136-5
[2] MATOUEK, D.: USB in practice with FTDI circuits. BEN, Praha 2003,
ISBN 80-7300-103-9
[3] Datasheets of circuits Vinculum. URL:<www.vinculum.com>
[4] Datasheets of PIC microcontrollers. URL:<www.microchip.com>
Final Report Size: from 10 to 15 pages

In Liberec 9. 3. 2010 Project Supervisor (signature)..................................

3

from the heat meter

Abstract
The aim of this project is to create interface for data storage from the double heat
meter MT200DS. Heat meter stores a lot of different data such as values from all
sensors or different working conditions to the day, month and year archive. These data
are stored in the on board implemented EEPROM data memory. From the heat meter is
also possible to obtain and store only actual values. In this project there is solved the
problem of actual values storage. As a memory medium was chosen today widely used
USB key (mass storage based on the flash memory). Data transaction between heat
meter and the memory is managed by microcontroller PIC18f452 (Microchip). Because
this microcontroller does not support USB directly, it was necessary to use some
converter. For this reason is used converter VNC1L (FTDI), which includes also
advanced features thanks to implemented firmware. VNC1L is placed on the module
VDIP2 for rapid prototyping. The module was in the end implemented with the
microcontroller on one board to provide an USB interface for the heat meter.

Key words:
VNC1L, VDIP2, Universal Serial Bus, data storage

4

from the heat meter
Contents
Terms and Abbreviations .............................................................................. 6
1. Introduction ................................................................................................... 7
2. Universal Serial Bus ..................................................................................... 8
1.1. Brief history .......................................................................................... 8
1.2. Hardware description ............................................................................ 9
1.3. Electrical description ............................................................................ 9
1.4. Voltage levels ..................................................................................... 11
1.5. Topology ............................................................................................. 12
1.6. USB transaction .................................................................................. 13
1.1.1. Introduction .................................................................................... 13
1.1.2. Common packet fields: .................................................................. 13
1.1.3. Types of USB Packets: .................................................................. 14
3. VDIP2 module ............................................................................................ 16
1.7. Introduction ......................................................................................... 16
1.8. Communication ................................................................................... 17
1.1.4. UART ............................................................................................. 17
1.1.5. SPI .................................................................................................. 18
1.1.6. FIFO ............................................................................................... 18
1.9. VNC1L chip ........................................................................................ 19
1.1.7. Basic features of the VNCL1 ......................................................... 19
1.1.8. Firmware ........................................................................................ 20
1.1.9. Upgrading firmware ....................................................................... 23
4. Heat meter ................................................................................................... 23
1.10. General description ............................................................................. 23
1.11. Communication ................................................................................... 24
1.1.10. RS232 interface ............................................................................ 25
1.1.11. RS232 interface module with analogue output ............................ 25
1.12. Communication protocols ................................................................... 25

5

from the heat meter
1.1.12. Simple .......................................................................................... 26
1.1.13. BitBus .......................................................................................... 27
1.1.14. Data archive ................................................................................. 28
5. Prototype board ........................................................................................... 29
6. Software ...................................................................................................... 30
1.13. Description of used software tools ...................................................... 30
1.14. Created functions ................................................................................ 31
1.15. Main program ..................................................................................... 33
7. Conclusion .................................................................................................. 33
Literature ..................................................................................................... 35
Appendix A - PCB ...................................................................................... 36
Appendix B - file......................................................................................... 38

Acknowledgement:
This text grew up by support of project ESF CZ.1.07/2.2.00/07.0247 Reflexe
poadavk prmyslu na vuku v oblasti automatickho zen a men.

6

from the heat meter
Terms and Abbreviations

EEPROM Electrically Erasable Programmable Read-Only Memory
USB Universal Serial Bus
FTDI Future Technology Devices Int. Ltd.
VNC1L Name of the chip (also called Vinculum)
VDIP2 Name of the module based on VNC1L
VMSC Name of the firmware
USB-IF USB Implementers Forum
WinHec Windows Hardware Engineering Conference
HID Human Interface Devices
NRZI Non Return to Zero Inverted
SE0 Single Ended Zero
PID Package Identifier
LVTTL Low Voltage Transistor Transistor Logic
TTL Transistor Transistor Logic
I/O Input/Output
BOMS Bulk Only Mass Storage
CDC Communication Device Class
HID Human Input Device
PCB Printed Circuit Board

7

from the heat meter
1. Introduction
The main task was to store data from the heat meter. Today are well known and
widely spread flash memories (USB keys) nearly everyone who has the computer has
at least one USB key. This memory provides very big data space for very low price in
my point of view. The only problem used to be the USB interface, because it is not so
easy to deal with the USB protocol in an ordinary microprocessor. To solve this
problem efficiently in the world were developed some 'clever' integrated circuits, which
provide functions for USB communication. One of these chips is VNCL1. VNCL1 is
implemented on the module called VDIP2, which is useful for rapid prototyping.
Module is connectable thanks to its compatibility with standard 40pin DIP socket.
VNC1L contains host controller, which means, that it can manage all USB
communication without any PC. Many other applications are available and depend
mostly on the implemented firmware. There are six different firmwares provided by the
manufacturer (FTDI). For example typical application of the VMSC firmware should be
reading music data from USB key and sending them via decoder to the headphones. In
the same time should be controlled volume by external microcontroller, which uses
access to the VNC1L via monitor command interface. Other possibility is to send data
from USB key to the USB printer via VNC1L. It is also possible to connect keyboard
and send data directly from keyboard to the printer. Sending data from one USB key to
another is also available with the VDFC firmware. In this application is used basic
VDAP firmware, which supports data transfers with USB keys (or USB hard disk
drives). To control the function of VNC1L are used commands, which are sent via
RS232, SPI or FIFO interface from the microcontroller. These commands can be sent
like ASCII characters (IPA mode) or like hex code values (IPH mode). There can be
chosen Shortened Command Set (SCS) or for more functionality Extended
Command Set (ECS).
As written above VNC1L is very powerful chip and it can be used in many
different ways. This work shows only one small part of possible usage.

8

from the heat meter

2. Universal Serial Bus
1.1. Brief history
History of the Universal Serial Bus (USB) is quite short compare to RS232 for
example. Development started in 1994 by effort of six companies IBM, Compaq,
Intel, Microsoft, NEC, Nortel and DEC. The first idea was to develop universal bus
simple to use with small and compact connectors (to reduce many connectors in the
personal computers). To have a possibility to connect devices such as digital cameras,
webcams (or any other devices with big data transfers in a short time), there was also
requirement for high transfer speeds.
1995 USB Implementers Forum (USB-IF) was formed on the First Windows
Hardware Engineering Conference (WinHec). During this conference Intel
introduced first USB silicon.
1996 USB Specification 1.0 was released.
1997 membership increased in the USB-IF to 400 members. In the world was
developed more than 500 USB products this year.
2000 USB 2.0 was released
2001 standardization of USB 2.0 by USB-IF
2008 USB 3.0 announced by USB 3.0 Promoter Group
Low speed and Full speed baud rates were included in the USB 1.1 specification.
High speed came with USB 2.0 in the year 2000. High speed USB was some attack to
compete with Firewire Serial Bus (IEEE1394a), which was developed and presented in
1995 by Apple. It was basically developed for big data transfers (e.g. digital video
transfers), so the baud rates were 100, 200, or 400 Mbit/s . In 1995 Firewire had no
competitors, because USB 1.0 could not compete with it. USB 2.0 was little bit faster
than Firewire400, but it was changed in the year 2002 by presenting Firewire800
(IEEE1394b with maximal baud rate 800 Mbit/s).

9

from the heat meter
1.2. Hardware description
On the Fig. 1 are shown the three most used types of USB connectors. Typically
we can find sockets type A on the computer main boards and on the hubs. Type B
sockets are situated on the devices (B plugs are always connected downstream). So

Fig. 1: USB connectors (source [1])
the upstream and downstream connectors are not mechanically interchangeable. Cables,
where are e.g. both connectors of the same type, are prohibited by the specification
(except cables for bridges used to connect two computers together). Because type B
connector is not suitable for small devices (because of its size), mini-usb B connectors
were developed. In the Table 1 there is shown connection of the pins.
Pin Name Cable color Description
1 Vcc Red +5 V DC
2 D- White Data-
3 D+ Green Data+
4 GND Black Ground
x may not be used, connected to GND
or used as attachment identification for some devices

Table 1: Description of the USB pins
1.3. Electrical description
Voltage levels of the USB communication depend of course on the baud rate. In
the USB specification are defined three different baud rates:
Low speed 1,5 Mbit/s
Full speed 12 Mbit/s
High speed 480 Mbit/s
Low speed is usually used for HIDs (Human Interface Devices) like a mouse,
joystick, keyboard. USB cable contains four wires. On the borders are wires V
BUS
and
GND, in the center is twisted pair marked as D+ and D- (see Fig. 2). Power supply
wires (V
BUS
and GND) are useful, because smaller devices can be powered directly

10

from the heat meter
from the bus by these wires. USB is a half-duplex bus with differential coding. Thanks
to this fact, it is robust to the electromagnetic disturbances. This bus uses NRZI (Non
Return to Zero Inverted) coding. This means, that small logical values are not directly
represented by different voltage levels. Important for this bus is changing state
(transition) from one voltage level to another. Transition means logical zero and steady
state means logical one. Although this bus is so fast, there is no extra wire for clock
synchronization, but if the state is not changed 6 (six log. ones), one synchronization
zero is added.

Fig. 2: USB cable structure (source [2])

Voltage levels for logical values are different for different baud rates. For full
and low speed devices are shown typical configurations on the Fig. 3 and Fig. 4.

Fig. 3: Typical configuration for the full speed devices (source [3])

11

from the heat meter

Fig. 4: Typical configuration for the low speed devices (source [3])
If no device is connected to the host, pull-down resistors (15 k) cause ground on both
data lines. This state is also called SE0 (Single Ended Zero) and because it can not
appear during ordinary data transfer, it is used for special events (e.g. reset, end of
packet). Full speed devices have installed pull-up resistor on the D+ line while low
speed devices on the D- line. If the device is connected to the host, only on one line will
be voltage different from the ground (voltage will be approximately 3 V thanks to the
voltage divider 1,5 k : 15 k). This is used to recognize baud rate of the device. If it
is high speed device, it has 1,5 k resistor on the D+ (as full speed device, but with
additional identification after reset). If both sides support high speed USB, 1,5 k
resistor in the device is unplugged by transistor and another 90 resistor is connected
between D+ and D-, that is necessary for impedance adjustment with the twisted pair.
1.4. Voltage levels
Voltage levels used in USB are not the same for different baud rates (see Table
2). In the next table (Table 3) is shown how are made combinations of voltage levels on
the D+ and D- line to make a differential voltage levels and events.
full and low speed devices high speed devices
logic level Vmin [V] Vmax [V] logic level Vmin [mV] Vmax [mV]
Low 0 0,3 Low -10 10
High 2,8 3,6 High 360 440

Table 2: Voltage levels on the USB

12

from the heat meter

As was written above, for the bus is important changing of state (instead of
differentialvoltage levels). On the bus can occur two states transition from log. H to L
and reversely.
voltage levels description
meaning on the bus D+ line D- line
SE0 (Single Ended Zero) L L end of the packet,
differential Low L H
differential High H L
SE1 (Single Ended One) H H prohibited - error

Table 3: All combinations of possible voltage levels on the bus
They are usually marked as J and K state and they are assigned to the transitions in
inverted way for low and for the full speed devices. From these reasons can occur on the
bus a lot of combinations, which are used for detection and indication (see Table 4).
Meaning Sequence on the D+ and D- lines
Idle for the low speed High on the D-, Low on the D+
Idle for the full speed High on the D+, Low on the D-
Resume state K state
Start Of Packet (SOP) Transition from Idle to K state
End Of Packet (EOP) SE0 state (2) followed by the J state
Disconnect SE0 state for more than 2 s
Connect Idle state for more than 2,5 s
Reset SE0 state for more than 2,5 s

Table 4: Some of possible events on the bus
1.5. Topology
USB is a host-based, that means that all devices must be connected to a
computer in order to communicate (this is different from Firewire, which is peer-to-peer
bus and where e.g. two cameras can communicate together without any computer). In
the USB network can be only one host controller per bus and to this controller are
connected special hubs in a tree-like fashion. Hubs should be cascaded up to the 5
th

level. Up to 127 devices including hubs can be connected to one bus. This is because
the address field is 7 bit long and the address 0 cannot be used. Standard maximal
length of USB between nodes is 5 meters (see Fig. 5).

13

from the heat meter

Fig. 5: USB topology (source [4])
1.6. USB transaction
1.1.1. Introduction
USB is made up by several layers and protocols (unlike e.g. RS232). Today
programmer cares only about higher layers, because about the management of the lower
layers usually care integrated circuits (e.g. FT232 or VNC1L). Each USB transfer
consists of a Token packet, an Optional data packet and a Handshake packet.
Communication is started by the host controller by sending the Token packet, which
describes what will follow (reading/writing). Data packet is followed by the
Handshake packet, where is confirmation of the transfer or an error detection. Main
USB packet fields:
1.1.2. Common packet fields:
Sync every packet has to start with this sequence. Sync sequence is 8 bit long
for low and full speed devices and 32 bit long for high speed devices. It
synchronizes clock of transmitter and receiver and last two bits indicate, where
PID sequence starts.
PID Packet identifier identifies the type of packet that is being sent. PIDs are
shown in the Table 5. In the table are just four bits, because the another four bits
in the PID byte are the previous ones, but complemented (to insure the transfer).

14

from the heat meter
Token 0001 OUT Token Host to device transfer
1001 IN Token Device to host transfer
0101 SOF Token Start Of Frame
1101 SETUP Token Device initialization
Data 0011 Data0 Data packet PID even
1011 Data1 Data packet PID odd
0111 Data2 For high speed USB
1111 Mdata For high speed USB
Handshake 0010 ACK Acknowledged
1010 NAK Not Acknowledged
1110 STALL Permanent error
0110 NYET Not responsible Yet
Special 1100 PREamble Host-issued preamble
1100 ERR Split transaction error
1000 Split High speed split transaction token
0100 Ping High speed flow control probe

Table 5: Packet Identifiers (PIDs)

ADDR this address specifies which device is this packet for. There should be
max. 127 different addresses as is written in the USB topology part above.
ENDP endpoint field consists of 4 bits (16 possibilities for the endpoints).
CRC Cyclic Redundancy Check. Data packets have 16bit CRC and Token
packets only 5bit CRC.
EOP End Of Packet is signalized by the SE0.
1.1.3. Types of USB Packets:
Protocol includes four packet types with different structure.
Token packets
o In host wants to read information from the device
o Out host wants to send information to the device
o Setup to begin control transfers
Data packets basically two types of data packages for low and full speed
specification (high speed specification has additional Data2 and MData). Their
capability is different for each specification (8, 1023 and 1024 bytes).
o Data0
o Data1

15

from the heat meter

Handshake packets
o ACK Acknowledgement (packet was successfully received).
o NAK Informs, that device is not temporarily able to send or receive
data.
o STALL Device is in state, which needs intervention by the host
controller.
SOF Start of Frame Packet consists of 11bit frame number, which is sent by
the host controller every 1 ms 500 ns on the full speed bus and every
125 s 0,0625 s on the high speed bus.
In the Table 6 are shown structures of the packets.
Token packets (exclude SOF) Sync PID ADDR CRC5 EOP
Data packets Sync PID Data CRC16 EOP
Handshake packets Sync PID EOP
Start Of Frame packets Sync PID Frame no. CRC5 EOP

Table 6: Structure of some PID packet

16

from the heat meter
3. VDIP2 module
1.7. Introduction
VDIP2 is an evaluation board based on the VNC1L chip, which is produced by
FTDI (Future Technology Devices International well known world producer of
different USB converters). The VDIP2 module was designed to be compatible with a
standard 40-pin DIP socket. On the VDIP2 module we can find only accessories
necessary to run the VNC1L chip like a 12 MHz crystal resonator with two capacitors,
then two vertically mounted USB A type sockets with their LED indicators. Another
features of the module are:
Different communication interfaces selectable by jumpers UART, SPI, parallel
FIFO
5V supply input
Auxiliary output for external logic (3,3 V / 200 mA)
Firmware update available via USB key or UART (firmware programming
control pins PROG# and RESET# are also brought out the interface)
The VNC1L needs +3,3 V power supply and USB interface needs +5 V, so on
the module is also implemented very low drop out (VLDO) linear voltage regulator,
which produces +3,3 V from +5 V with low losses. Because today are widely used low
power supplies based on the voltage levels from LVTTL (Low Voltage Transistor
Transistor Logic) about +3,3 V, the chip VNC1L was designed so. But USB and a lot of
another devices are still working on the TTL + 5 V logic, so the chip was designed to
accept also TTL logic. The module pin out is shown on the Fig. 6.

17

from the heat meter

Fig. 6: Assignment of the pins on the module (source [5])

1.8. Communication
In this part are described three different interfaces for communication
implemented in the VDIP2 module. One of the three interfaces has to be chosen by
jumpers as shown in the Table 1. For UART there are two possibilities, which means
that they are just inverted. These jumpers are used to pull up or down two pins (no.46
and 47) on the VNC1L chip.

I/O mode JUMPER3 JUMPER4
UART 1 - 2 1 - 2
SPI 2 - 3 1 - 2
FIFO 1 - 2 2 - 3
UART 2 - 3 2 - 3
Table 7: Possible jumper combinations to choose interface
1.1.4. UART
Classical RS232 interface (after voltage conversion) with full 9-pin serial port
For ordinary communication we need necessarily just 5 pins RxD, TxD, GND
(RTS and CTS have to be pulled down to the ground through resistors)
LVTTL (3,3 V) voltage levels, but TTL (5 V) tolerant
Baud rate is settable from 300 till 1 MBd (after reset is always set to 9600 Bd)
On the Fig. 7 is shown UART reception waveform (the upper part) and the
transmission waveform

18

from the heat meter
Fig. 7: Sequences on the pins during reception and transmition of one byte (source [6])
1.1.5. SPI
Uses four pins four pins SCLK (Serial Clock), SDI (Serial Data Input), SDO
(Serial Data Output), CS (Chip Select)
can operate with the clock (SCLK) frequency up to 12 MHz
differs from other implementations, because it uses 13clock sequence to transfer
a single byte of data
on the Fig. 8 is demonstrated slave data read cycle (the upper part) and slave
data write cycle (VNC1L is in the slave mode)

Fig. 8: Slave data read cycle (upper part) and slave data write sequence on
the SPI bus (source[6])
1.1.6. FIFO
parallel FIFO (First In First Out) bus

19

from the heat meter
contains data pins D0 D7 and pins RXF#, TXE#, RD#, WR to control the data
transaction
on the Fig. 9 is FIFO read cycle (the upper part) and FIFO write cycle (time
values of the data transaction (T1 T6) are different for the read write cycle
see [6]

Fig. 9: Read cycle (upper part) and write cycle sequence via FIFO interface (source [6])
1.9. VNC1L chip
1.1.7. Basic features of the VNCL1
This chip is embedded dual USB host controller. On its block diagram (Fig. 10),
we can see these features:
two independent USB host ports compatible with USB 2.0 (Low and Full
speed), each can be configured as a host or a slave (USB protocol implemented
on the chip)
MCU processor core (8/32 bit, using enhanced CISC technology)
64 kB embedded flash (E-FLASH) for the firmware storage (firmware upgrade
possible via USB key or via UART)
4 kB data SRAM

20

from the heat meter
two DMA (Direct Memory Access) controllers (one for each USB host) to
accelerate data flow from USB to external bus
up to 28 pins of general purpose Input/Output (four fully configurable data and
control I/O buses)
Chip also supports bus, self and high powered USB configurations. VNC1L was
optimized for low consumption (25 mA operational, 2 mA in the standby mode) with
+3,3 V single supply, but with 5 V safe operation. Everything is packed in the 48-pin
LQFP (RoHS compliant) and can be used in the wide temperature range (from -40 C
till +85 C).

Fig. 10: Block diagram of the VNC1L chip (source [6])
1.1.8. Firmware
Functionality of the circuit mostly depends on the program (Firmware), which is
written in the E-Flash memory. For the rapid prototyping and developing new
applications were made different firmwares by FTDI. In this time manufacturer
provides six different types of firmware:
VDAP Disk And Peripheral Firmware V3.68 it was designed to provide USB
host functions to microcontrollers. For this reason are supported BOMS devices
on the Port2 and USB Slave Peripherals on the Port1.

21

from the heat meter
VMSC Music Firmware (for VMUSIC modules) V3.68 it is similar to the
VDAP, but new commands were added for playback through an MP3 decoder
chip (e.g. VLSI VS1003 MP3 decoder communicates via SPI with the
Vinculum, which has data from USB key, and Vinculum communicates with
the main processor through command monitor)
VDPS Disk or Peripheral Firmware V3.68 provides connection with the
computer on the Port1. If the computer is connected, VNC1L enumerates as an
FT232B device and loads drivers. In this case it is necessary to use voltage
divider to synchronize the voltage from the computer to the Vinculum.
VCDC Communication Device Class Firmware was developed primary to
provide modem-like functionality to microcontrollers. Communication Device
Class (CDC) must support sub-class of Abstract Control Model and have
compatible bulk endpoints.
VDIF Disk Interface Firmware it works like VDAP until FTDI peripheral
(suitable are FT232B, FT232R and FT2232) is detected on the USB Port1. Then
command monitor stops communication via standard pins and becomes active
on the USB Port1 with the same baud rate like on the serial UART interface.
VDFC Disk File Copy Firmware supports Bulk Only Mass Storage (BOMS)
on the both Ports. Then is possible to manipulate with data from one BOMS to
another one.
In the Table 8 is shown the functionality for each firmware for each USB port
(CDC Communication Device Class, BOMS Bulk Only Mass Storage, HID Human
Input Device FTDI means another FTDI peripherals, monitor means the access to the
command monitor, which accepts commands). The chip supports only these devices and
then it is also constrained by specification of the USB 2.0, which is supported precised
description of these devices is in the firmware datasheet [7] in the chapter 9.2. Some
problems should be solved by connecting devices via HUB, because HUB is usually
supported except the VDIF firmware (see Table 8).

22

from the heat meter
device type BOMS FTDI HID Printer HUB PC Host Monitor CDC
USB port 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2
VDAP y y y y y y y y y y y
VDIF y y y y y
VMSC y y y y y y
VDPS y y y y y y
VCDC y y y y y y y
VDFC y y

Table 8: Features of different firmwares for VNCL1 chip

Typical applications and wiring diagrams are shown in the Table 9 for each
firmware.

VDAP VMSC

VDPS VCDC

VDIF VDFC
Table 9: Typical applications of the different firmwares (source [7])

23

from the heat meter
1.1.9. Upgrading firmware
Firmware should be upgraded in the two different ways. One possibility is to use
VPROG programmer (ROM programmer), which communicates via serial port with the
VNCL1. During programming using this method has to be PROG pin pulled down to
activate a special mode for the FlashROM upgrading. Second choice is to use an USB
key. In the root directory has to be the firmware file named FTRFB.FTD. After
connecting USB key is necessary to reset the module, then the file is automatically
detected and firmware after few seconds upgraded.

4. Heat meter
1.10. General description
MT200 is designed for measurements in heating and residual applications, but it
can be used for measurements of the cooling water consumption as well. For the flow
sensing are used inductive flow sensors. These sensors do not contain any mechanical
accessories (no moving parts and no orifice plates) placed inside the piping, so they do
not cause any pressure losses. Despite this they have still good accuracy (from the
specification for the heat consumption meters flow sensors are placed in the second
class pursuant to EN 1434,
min
= 2 C). In the Table 10 are shown all accessories,
which can be added and combined according to the customers requirements.

24

from the heat meter
Two inductive flow sensors ( rated inner diameters DN can be different )
Inductive flow sensors with flanges to DN800
Two-line underlit alphanumeric display, display control button
Two matched pairs of temperature sensors, 2.5m or 6m cables, 4 wires, shielded
Four temperature sensor wells, 54mm or 100mm length, G1/2"
Installation accessories and four weld-on lugs for temperature sensor wells
Separate dual calorimeter without temperature and flow sensors
Two analogue inputs 4-20mA ( measurement of pressure, temperature, ... )
Two impulse heat outputs 10 imp per GJ or optional 100, 1, 0.1, 0.01 imp per GJ
Two adjustable flow rate frequency / impulse outputs
Two adjustable impulse inputs for external water meters No 4 and 5 ( or 1 and 2 )
Two adjustable impulse inputs for external water meters ( No.4 and 5 )
Adjustable 4-20mA or 0-10V output ( flow rate, t1 , t 2 , Lt or thermal power )
RS232 or RS485 serial interface or M-Bus interface
IrDA serial interface ( optical infrared )
Data registries ( daily 365 days, hourly 54 days ) + status changes ( 2880 events )
Custom setting as per order
Official calibration ( billing consumption metering )
VIEW32 software to interface with a heat consumption meter

Table 10: Possible accessories to the MT200DS heat meter`
1.11. Communication
Communication with the heat meter is possible through four different interfaces:
RS232, RS458, M-Bus or INFRA (IrDA). For IrDA communication is necessary to use
external terminal called ESTER. This portable module can be used to get and store data
from the individually installed heat and flow meters. RS458 and M-Bus are suitable for
longer distances and are more robust for the disturbances. From this reasons I naturally
chose RS232, which is suitable for my case (small distance and easy voltage
conversion). On the meter are prepared two slots XC13 (COMM2) and XC14
(COMM1), so it is possible to have simultaneously connected two interface modules. In
this case slot COMM1 has higher priority over COMM2. In the service mode and also
by default the baud rate is set to 9600 Bd. Baud rate can be of course chosen to different
values. For the COMM1 is set BitBus protocol by default, for COMM2 protocol
SIMPLE. For communication is usually used software VIEW32.

25

from the heat meter
1.1.10. RS232 interface
This module uses simple communication without any hardware handshake, so it
needs only three wires TXD, RXD and GND. This communication line uses
galvanically separated power supply. For connecting heat meter to a PC is necessary to
use 9-pin female D-sub connector (connection of the pins is shown in the Table 11).

COMM1 COMM2 RS232 D-Sub
9 3 GND 5
10 4 RXD 3
11 5 TXD 2
Table 11: RS232 heat meter interface
1.1.11. RS232 interface module with analogue output
These modules are similar to previous RS232 interface module, but it has
additional outputs for direct measuring of analogue value. This value is chosen by
software VIEW32 via RS232 communication (it is possible to measure directly one of
these quantities: flow rate in the flow sensor (no. 1 or no. 2), instant thermal power (no.
1 or no. 2), temperature from the particular sensor, difference of the temperatures in the
input and in the return pipe, flow rate in the external flow meter (no. 4 or no. 5),
pressure on the pressure sensor (no. 1 or no. 2)). The analogue output is standardized
current output (4 20 mA) or voltage output (0 10 V).
1.12. Communication protocols
Three different protocols are implemented: protocol Simple for RS232,
protocols BitBus and ASCII for RS485.

26

from the heat meter
1.1.12. Simple
In the Simple protocol are used 8 bits without any parity and just one stop bit. In
the Table 12 is shown a structure of message, which we have to transmit to the heat
byte no.
1 total message length = (n+5)h
2 code of the message (in hexa code)
30 Hot water volume total
31 Hot water flow rate
33 Return temperature (C)
34 Input temperature (C)
35 Temperature difference (C)
36 Consumed heat energy
A5 Thermal power
D3 Pressure
38 Status and error log
39 Operation time (min)
3A Idle time (min)
42 RTC date (ddmmyy)
43 RTC time (hhmm)
46 Software version
50 Heatmeter ID number
3 different data (in hexa code)
00 for data from the second heat meter or for common data
01 for data from the first heat meter
03 for data from flowmeter no.5 and pressure sensor no.2
.
. n bytes long further report - only if required
.
penultimate byte 00 indicates the end of the transmittion
ultimate byte CHSUM - check sum
CHSUM = NOT (1st byte XOR 2nd byte XOR
XOR 3rd byte XOR.XOR penultimate byte)+01h

Table 12: Structure of transmitted message Simple protocol
meter to obtain the correct information. Type of information depends on the code,
which we send in the second byte of the message. In the third byte we can specify from
which meter we want to receive the data (from the first or second or some information,
which is common for both heat). Immediately after transmission, we will receive
message with the structure as follows: first byte is 00h, then we receive the actual value
from the display in ASCII (in the units actually chosen on the display) length of this
message depends on the type of the value. The last byte is 00h too. The last zero can be
useful for detecting end of string in the memory. In the Table 13 is an example of
transmitted and received data. In this message is sent the requirement for the consumed

27

from the heat meter
heat energy (second byte is 36h) from the first heat meter (third byte is 01h). Received
message is simple code between first and the last zero.
transmitted data in hexa code: 05 36 01 00 CE
received data in hexa code: 00 31 32 33 2E 34 35 36 37 00
received message translated to ascii: 123.4567

Table 13: An example of data transaction via RS232
1.1.13. BitBus
BitBus protocol uses eight bits with one parity bit and also one stop bit. When
the address is transmitted, the parity bit is set to logical I. In the other cases (during
other transmissions or receptions) is the parity bit set to logical 0. The structure of the
transmitted message is the same like for Simple protocol, but first byte is sent meters
address in the RS485 network (this byte is not computed to the total length) and the
other bytes are naturally shifted by one position further as shown in the Table
14.
byte no.
1 heat meter address in the network
2 total message length without the first address = (n+5)h
3 code of the message (the same as in RS232 protocol)
4 different data (in hexa code)
00 for data from the second heat meter or for common data
01 for data from the first heat meter
.
. n bytes long further report - only if required
.
penultimate byte 00 indicates the end of the transmittion
ultimate byte CHSUM - check sum
CHSUM = NOT (1st byte XOR 2nd byte XOR
XOR 3rd byte XOR.XOR penultimate byte)+01h

Table 14: Structure of transmitted message BitBus protocol

28

from the heat meter
transmitted data in hexa code: 0 F 0 5 3 6 0 0 0 0 C D
received data in hexa code: 0 F 0 C 0 0 3 1 3 2 3 3 2 E 3 4 3 5 3 6 3 7 0 0 E E
received message in ascii code: 123.4567

Table 15: An example of data transaction via RS485
1.1.14. Data archive
For the data storage was developed registry module. This registry module stores
data in the four ways. The first part memory also called hour registry stores on the end
of each hour the following data: date, time, heat consumption, heating water
consumption, average temperatures measured by the temperature sensors, consumption
measured by the external flow meters, average pressures, status code and time of
meters inactivity. Another two registers daily registry (365 days), monthly registry
(24 months) store the same data except the status code. The last fourth registry stores
date and time, when occurs any change in the operational parameters of the heat meter.
It should be for example error in the temperature sensors, outage of the power supply,
exceeding of the maximum flow of the inductive sensors and the other disturbances
(recorded can be last 2880 values). On the Fig. 11 is shown a part of the hour registry.

Fig. 11: Sample of the data archive

29

from the heat meter
5. Prototype board
Printed Circuit Board (PCB) was made to simplify the connection between heat
meter and other devices (PIC, VDIP2). This is only prototype version so it is not
optimized for high integration. The scheme in small resolution is shown on the Fig. 12.
It contains only devices (circuits) necessary and sufficient for the specified task:
20MHz crystal resonator
Reset circuit for the PIC restarting
LEDs as indicators
Switches to emulate input events
TTL to RS232 converter (standard MAX232 manufactured by MAXIM is used)
for interfacing microcontroller with PC

Fig. 12: Scheme of interface PCB

30

from the heat meter

6. Software
1.13. Description of used software tools
For coding I used MPLAB IDE with C18 compiler. This software is provided
and fully supported by Microchip. Microchip also provides a lot of libraries for PIC18
series. To upload the program to the microcontroller it is necessary to use some standard
or ICSP (In-Circuit Serial Programming) programmer. Another possibility is to use
some Bootloader. Bootloader is a special program, which is able to communicate with
computer via RS232 and to store the received data into its flash program memory. This
was not possible few years ago, because microcontrollers were not able to rewrite their
own program memory. This advantage should be sometimes disadvantage, when human
does not care about the part of the memory, which is prohibited to use. Bootloader
usually needs few instructions on the very beginning of the program memory to make a
jump to the total end of the program memory, where is situated the bigger part of the
bootloader (RS232 configuration and communication protocol). Then the users
program can be situated everywhere except these memory parts. On the internet is
possible to find and download many different bootloaders. Very famous are Tiny
bootloaders, which are the smallest (occupy only 100 words of the program memory).
This is, because they make just necessary communication, and the control management
is done by the computer. In this application I used TruTrack bootloader. Although it is
bigger than Tiny bootloader, the software interface is very simple and reliably.

31

from the heat meter
1.14. Created functions
For communication with heat meter and the VDIP2 module I have made header
files with functions to simplify the communication.
header file ret.value function parameters
heat_met result getData unsigned char hexcode,
unsigned char meter
UdayArchive getDayArchive long2 adr
vdip_fce void wordUART const rom char *p_letter
void wordUART2 char *p_letter
void wordlnUART const rom char *p_letter
void wordlnUART2 char *p_letter
void DelayRXHalfBitUART void
void DelayRXBitUART void
void DelayTXBitUART void
void vdipInit void
void changeDirectory const rom char *path
void createFile const rom char *name
void closeFile const rom char *name
void createFile2 const rom char *name,
char *p_let
void closeFile2 const rom char *name,
char *p_let
void write2fileROM const rom char *word
void write2fileRAM char *word
void writeChar2file char letter
void writeEnter2file void

Table 16: List of created functions
result getData(unsigned char hexcode, unsigned char meter) Function sends
request for the current data from the heat meter, whose type is defined by the
first parameter hexcode. By the second parameter we can determine from which
meter we want to obtain data (because it is double system). Before the end check
sum is computed and is sent as the last byte to check the data transfer. Then
function is simply waiting for the first zero (code 0x00) to determine the start of
receiving message. After this input characters are stored in the array. Transfer
ends with the last zero (0x00), which is in the same time termination character in
the array. Array of chars is returned in the structure.

32

from the heat meter
void wordUART(const rom char *p_letter) function sends string of data
characters situated in a program memory and terminated by 0x00 to the UART
(Universal Asynchronous Receiver/Transmitter).
void wordUART2(char *p_letter) equivalent to the wordUART function, but
string is now situated in the data RAM memory
void wordlnUART(const rom char *p_letter), void wordlnUART2(char
*p_letter) these functions are equivalents to the previous ones, just they send
on the end of the communication carriage return character to finish the line
void DelayRXHalfBitUART(), void DelayRXBitUART(), void
DelayTXBitUART() are delay loops (252, 507 and 521 instruction cycles),
which are used during the serial communication transfer
void vdipInit() function to initialize Vinculum. At first is written command
IPA to switch on the ASCII mode of the monitor, then it is command ECS to
use extended command set
void changeDirectory(const rom char *path) switches actual directory on the
USB key to the one defined by the path from program memory
void createFile(const rom char *name) opens file for writing. If the file does
not exist, it creates this file.
void closeFile(const rom char *name) closes currently opened file
void createFile2(const rom char *name,char *p_let), void closeFile2(const rom
char *name, char *p_let) equivalents to the functions above, but the part of the
filename is stored in the RAM (after it is used to make name of the file with
actual time)
void write2fileROM(const rom char *word) writes string from the program
memory to the currently opened file for write
void write2fileRAM(char *word) writes string from the data RAM to the
currently opened file for write
void writeChar2file(char letter) writes single character to the file
void writeEnter2file() writes feed line and carriage return characters to go to a
new line

33

from the heat meter
1.15. Main program
Program starts with initialization of the input and output ports and serial ports.
For this task was necessary to create one extra software serial port. First (the hardware
one) is situated on the PORTC and is used to communicate with the heat meter. Second
UART (the software one) communicates with the VDIP2 module. Baud rate of the first
port is set to the maximal speed for the heat meter (i.e. 38 400 Bd). After this is VDIP2
initialized for the communication (vdipInit function). Communication, which follows,
has simple structure easy to understand from the source code.
7. Conclusion
On the beginning I studied USB communication, which is more sophisticated
compared to RS232 communication. USB interface provides more comfort for the end
user (a lot of management is done automatically), but this makes USB much more
complicated for developers. To know how does it really work I tried to catch
communication with the USB key by software in the PC. Then I was able to recognize
data packages. As a software I tried Device Monitoring Studio (only trial version for
free). Fortunately in these days is not necessary and it is also ineffective to manage USB
communication on the low layers by hand. After USB communication I tried to
communicate with the VDIP2 module. I tried to connect some HIDs, but I found, that it
does not work with a lot of them, because VNC1L does not support low speed devices.
It is difficult task to get data sheet of the HID before you buy it to know whether it is
supported or not. I had to have a look on the chip inside the device to see which type of
speed supports. I tried to communicate with VNCL1 at first directly with the computer
via Terminal (using RS232 mode). Then after some experiments I switched to direct
communication between VDIP2 and microcontroller. Because VNC1L thanks to
precisely made firmware provides a lot of commands for BOMS management, it was
not so difficult to create a file with .csv extension. I chose this format (.csv), because it
is simple to create (data are substracted by comma) and it is simple to use it can be
opened by Excel to make statistics or graphs.
Next task was to manage communication with the heat meter. At first I tried it
also via Hyperterminal, but it was not so difficult thanks to precise description in the
data sheets. Because PIC18f452 contains only one hardware serial port and I needed
two of them, I decided to use hardware one for the heat meter communication and to

34

from the heat meter
create new software serial port for the VDIP2 module. On the software one is baud rate
set to standard 9600 Bdand on the hardware one to the highest possible (for the heat
meter) 38400 Bd.
After these experiments I made a scheme and PCB in the Eagle layout editor.
I realized it and checked the communication. The interface works like follows: after
USB key is detected on the Port2, LED2 lights. Now when the button on the PORTB7
is pushed, communication starts firstly data are obtained from the heat meter and
stored in an array. Then in the directory DATA on the USB key is created file with
actual time and data from the array.
The communication works fine, but sometimes when some unexpected error
occurs, it can fail. To get rid of this is necessary to detect errors, make some additional
control algorithms (parity, check sum...) make the communication more robust. The
next task for future development should be to realize interface with devices in smaller
(SMD) packages and everything minimize (make a small module connectable to
standard slots on the heat meter).

35

from the heat meter
Literature
[1] USB connector pinout [online]. 20.5.2010.
URL:<http://pinouts.ru/Slots/USB_pinout.shtml>
[2] Komunikan protokol univerzln sriov sbrnice [online]. 20.5.2010.
URL: <http://www.root.cz/clanky/komunikacni-protokol-universalni-seriove-
sbernice/#k02>
[3] USB in Nutshell [online]. 20.5.2010.
URL: <http://www.beyondlogic.org/usbnutshell/>
[4] Topology [online]. 20.5.2010.
URL:<http://i.technet.microsoft.com/Cc768200.wrkff01(en-us,TechNet.10).gif>
[5] VDIP2 Vinculum VNC1L Prototyping Module [online]. 20.5.2010.
URL: <http://www.vinculum.com/documents/datasheets/DS_VDIP2.pdf>
[6] Vinculum VNC1L Embedded USB Host Controller IC Datasheet [online].
20.5.2010.URL: <http://www.vinculum.com/documents/datasheets/DS_VNC1L_V
201(FT_000030).pdf>
[7] Vinculum Firmware User Manual [online]. 20.5.2010.
URL: <http://www.vinculum.com/documents/fwspecs/UM_VinculumFirmware_V
205.pdf>
[8] MT200DS Communicatio Protocols for Data Acquision [online]. 20.5.2010.
URL: < http://www.eesa.cz/documents/en/protocol/MT200DS_kom_e.pdf>
[9] MT200DS Installation and Operation Manual [online]. 20.5.2010.
URL: <http://www.eesa.cz/documents/en/MT200DS_mtpa.pdf>

36

from the heat meter
Appendix A - PCB

Fig. 13: PCB devices on the top side

Fig. 14: PCB device on the bottom side

37

from the heat meter

Fig. 15: PCB - bottom side

38

from the heat meter
Fig. 16: Realized board - top view
Appendix B - file
Heat meter data - 15.05.10 20:13:32
FIRST METER
total volume,771791.300
current flow, 490.576
output temp., 0.000
input temp., 0.000
diff. temp., 0.000
total heat, -0.1612
heat power, 0.0000
pressure, 10.000
SECOND METER
total volume,773243.000
current flow, 491.339
output temp., 0.000
input temp., 0.000
diff. temp., 0.000
total heat, -0.0412
heat power, 0.0000
pressure, 8.000

Table 17: An example of the .csv file created on the USB key

Tomas Marek Semestral Project

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tomas Marek Semestral Project

Transféré par

Droits d'auteur :

Formats disponibles

______________________________________________________________________

Vous aimerez peut-être aussi