MASTER'S THESIS1025363/FULLTEXT02.pdf · 2016-10-04 · Chapter 3 { Hardware 19 ... 1.3 Limitations...

MASTER'S THESIS

Modbus Interface Extension of D-flowsEngineering Kit

Angelica Brusell2015

Master of Science in Engineering TechnologyEngineering Physics and Electrical Engineering

Luleå University of TechnologyDepartment of Computer Science, Electrical and Space Engineering

Master Thesis

Modbus interface extension ofD-Flow’s Engineering kit

S. Angelica Brusell

Lulea University of TechnologyDepartment of Computer Science, Electrical and Space Engineering

9th September 2015

ABSTRACT

In today’s connected world easy and reliable communication between sensors and sys-

tems is key. Being able to collect all sensor data from a single main communication unit

increases the usability of the system.

Modbus is a popular industrial communication protocol. It is simple to implement,

extensively used and supported by a large number of devices used in industrial settings.

Due to the popularity of the Modbus protocol, supporting it is key to ensure a competi-

tive product.

D-Flow desired to provide a Modbus interface extension for their Engineering kit. A

new subsystem was designed to provide the required hardware and software requirements

to support the Modbus protocol.

One of the key features of D-Flow’s flow meters is its low power consumption. This

demands equal low power restrictions of the Modbus interface, as D-Flow’s flow sensors

are commonly battery operated.

In the end a fully functional prototype was completed. The power consumption did

not meet specified ranges that allow for long term battery operation, but was judged to

be as low as possible with the transceivers available on the market.

iii

PREFACE

I would like to thank D-Flow Technology that made this thesis possible. Through their

warm welcome, stimulating work environment and support, the work was able to keep

flowing in the right direction. Especially I would like to thank my industrial supervisor

Jorgen Marklund for the great comments and ideas throughout the work.

Also, I would like to thank all my amazing friends and family for supporting and en-

couraging me through thick and thin. Without you nothing of this would have been

possible.

Lastly I would like to thank my academic supervisor at Lulea University of Technology,

Per Lindgren, and Andreas Lindner for the help with feedback, discussion and the final

report.

Angelica Brusell

v

CONTENTS

Chapter 1 – Introduction 1

1.1 D-Flow Technology AB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Market research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Method and approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 – System overview and theory 5

2.1 Embedded systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Protocol description . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Data and addressing model . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 Function codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.4 Exception codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 TIA/EIA-485 (RS-485) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Cabling and connectors . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Biasing and line termination . . . . . . . . . . . . . . . . . . . . . 15

2.3.3 Grounding and protection circuitry . . . . . . . . . . . . . . . . . 15

2.3.4 Noise immunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 D-Flow’s Engineering Kit . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1 UFO2 ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.2 Engineering Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 3 – Hardware 19

3.1 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2 Engineering kit communication . . . . . . . . . . . . . . . . . . . 19

3.1.3 Modbus communication . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.4 RS485 termination . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.5 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Component choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 RS485 transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.3 Crystals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.4 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.5 Passive components . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 PCB design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Modbus Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.2 Programming adapter . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 4 – Software 27

4.1 Programming environment . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 EFM32 Zero Gecko development board . . . . . . . . . . . . . . . . . . . 28

4.3 Sleep mode scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Peripheral configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4.1 Clock configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.2 USART/LEUART . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.3 Direct Memory Access, DMA . . . . . . . . . . . . . . . . . . . . 29

4.4.4 GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.5 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5 Serial communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5.1 Development board communication . . . . . . . . . . . . . . . . . 30


4.6 Modbus implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.6.1 Function and exception codes . . . . . . . . . . . . . . . . . . . . 34

4.7 Modbus master simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.7.1 Modbus registers configuration . . . . . . . . . . . . . . . . . . . 35

Chapter 5 – Measurements and testing 37

5.1 Robustness and reliability . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Start up delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2 Awake time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.3 Long term functionality . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.4 Stress test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1.5 Multiple slave network . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Power consumption measurements . . . . . . . . . . . . . . . . . . . . . . 41

viii


5.2.2 Engineering kit communication . . . . . . . . . . . . . . . . . . . 42

5.2.3 Full operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.4 Power vs. baud rate . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.5 Power vs. high frequency clock speed . . . . . . . . . . . . . . . . 45

5.2.6 Power vs. data package size . . . . . . . . . . . . . . . . . . . . . 46

5.2.7 Battery life calculations . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 6 – Results 49

6.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.3 Power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.4 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 7 – Discussion and conclusions 53

7.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2.1 Engineering kit setup . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.4 Testing and measurements . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.5 Alternative approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Appendix A – Component list 57

Appendix B – Modbus Interface PCB 59

B.1 Modbus Interface schematic . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.2 Modbus Interface PCB layout . . . . . . . . . . . . . . . . . . . . . . . . 60

Appendix C – Adapter PCB 61

C.1 Adapter schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

C.2 Adapter PCB layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

ix

CHAPTER 1

Introduction

In today’s connected world communication between sensors and systems is key. A simple

and robust way to collect measured data in an automated way is mandatory for many

processes to run smoothly. Enabling easy data collection saves time and money as the

maintenance of the system is simplified with a centralized main unit controlling each

sensor. If applied correctly the system can save company resources and increase efficiency.

Due to extensive support of the Modbus protocol [1] for communication between in-

dustrial devices and sensors the possibility to support it is a huge advantage in offering

a competitive industrial application.

1.1 D-Flow Technology AB

D-Flow Technology AB is a knowledge based company specializing in ultrasound technol-

ogy, mainly for flow measurement. D-Flow’s knowledge is based on 25 years of research

in ultrasonics and flow measurement technology. The company provides the key compo-

nents and know-how for application specific flow meters.

The D-Flow Ultrasonic Technology Concept is based on three cornerstones: D-Flow

UFO ASIC, Ultra Sonic Transducers and know-how & experience from many years of

research and development.

The UFO2 ASIC is a single chip solution for ultrasonic time of flight and temperature

measurements. The UFO2 ASIC provides a high level of integration. That keeps the

total cost for the electronics to a minimum.

D-Flow ultrasonic transducers for liquids are specially designed for ultrasonic flow mea-

surement. The cost-effective solution makes the transducers suitable for high-volume ap-

plications. The PEEK material is approved for both medical and industrial applications

and is therefore suitable for a wide range of flow measurement applications.

D-Flow offer all the necessary development services needed to develop an ultrasonic

flow meter.

1

2 Introduction

1.2 PurposeThe purpose of this thesis was to produce a system specification, design a subsystem ca-

pable of Modbus communication, test its functionality and keep the power consumption

as low as possible. The Modbus interface itself was designed as a stand-alone PCB with

the required hardware and software to collect serial data from D-Flow’s Engineering kit

and convert it to the Modbus protocol. The interface had to be completely detached from

the Engineering kit in the sense that no alterations of its original hardware or software

could be made. This puts a number of restrictions on the Modbus interface in the sense

of the serial data structure, physical placement of components, connectors, power supply

and not to interact with the Engineering kit except for reading it’s output data.

Due to the power consumption restrictions implementing the Modbus interface directly

on the on-board microprocessor of the Engineering kit was not a viable option. The power

consumption of the on-board processor would use too much power after the required

software modifications to meet the target range of ∼ 60µA. For more information on the

Engineering kit, see Section 2.4.

1.3 LimitationsThe thesis was limited to the development of the hardware and software of a stand-alone

prototype Modbus slave interface. The Modbus master, while examined and taken into

consideration throughout the design, was not developed within the framework of this

thesis.

1.4 Market researchSince the interface developed was aimed specifically at D-Flow’s already existing Engi-

neering kit the design of both hardware and software was custom made to fit its specific

needs. Due to these restrictions it was determined that the interface were to be con-

structed from scratch instead of building on a third party solution.

The majority of the Modbus slave interfaces available come as bulky generalized im-

plementations of the Modbus protocol to fit any possible sensor, such as HMS’s Modbus

RTU Slave Inteface [2]. Similarly to the prototype developed in this thesis these interfaces

take serial data input and convert it to Modbus. The downside to these kinds of imple-

mentations is that they leave little control to optimize the power consumption. Another

common type of Modbus interface available is the PLC type of implementation with a

programmable box that can act as either a Modbus master or slave, e.g Advantech’s

ADAM-4572 1-port Modbus Gateway [3].

1.5. Method and approach 3

Neither of these solutions were of interest while designing the system as they give little

control and are physically bulky. A small stack-on board that will fit in the current

casing was considered a cleaner solution.

Complete sensor packages with Modbus implemented exist om market. The E + E

Elektronik [4] humidity and temperature sensor EE071 [5] is one example. Here the

measured values are stored in the Modbus registers until requested by the Modbus master.

This is the same type of functionality that will be added to D-Flow’s Engineering kit

with the interface developed in this thesis.

1.5 Method and approachThe project started with an extensive study of the Modbus protocol specification to

determine the requirements in terms of hardware and software. After mapping out the

scope of the project in more detail the initial time plan was revised to better reflect the

development process.

Due to the strict low power demands of the system a great deal of effort was put into

researching the different microprocessors currently available on market. The choice was

made with respect to power consumption, architecture, documentation, size, computa-

tional power, product support and available development boards. A microprocessor was

chosen that had an existing development board so that the software development could

begin as soon as possible.

The specified hardware protocol, RS485, of the Modbus protocol requires a transceiver

chip to convert the single ended serial data stream from the microprocessor to differen-

tial signals that run over RS485, and the other way around. This turned out to be a big

problem due to the power consumption and supply voltage limitations of the project. It

was decided that nothing could be done about this fact. To complete the prototype the

most suitable RS485 transceiver with the lowest possible power consumption was chosen

as a proof-of-concept for future work.

A prototype of the interface was built on a prototype board and connected to the de-

velopment board. The majority of the software development was done on this platform

as a design verification stage before the actual PCB version was designed. When the

majority of the software had been written and the prototype hardware proven to work,

a PCB was designed and assembled.

The testing was done in several stages. Firstly a series of long running tests were

made over nights and weekends to verify robustness and reliability of the system. When

the system was deemed stable enough the power consumption was measured to find the

optimal settings for baud rate, clock speed, polling frequencies and so on.

CHAPTER 2

System overview and theory

This chapter presents the theory and specifications. Embedded systems are presented

along with the specifications of Modbus and its physical layer, RS485. The chapter ends

with a general description of a Modbus network.

2.1 Embedded systemsAn embedded system is a computer system that is designed to preform a specific task.

Embedded systems are small in size, low power and cheap systems. Designing a system

to handle just a small set of tasks ensures that no resources are wasted or redundant.

Designing low power embedded systems is hard. The term ’low power’ implies different

system properties depending on the application at hand. Systems that are required to

run constantly have to focus on reducing their dynamic power to be efficient. Battery

powered devices though have to focus a lot more on optimizing the use of sleep modes

[6].

2.1.1 Microprocessor

Microprocessors are commonly used to add intelligence to an embedded system. It’s a

cheap and simple way to add logic and functionality to a system that might otherwise

be hard to achieve.

Architecture

Microprocessors come in a wide range of shapes and sizes. Their basic underlying struc-

ture can differ widely between manufacturer, architecture and instruction set used.

The Cortex family of microprocessors span a wide range of use cases. From the more

powerful Cortex based processors, M3-M4 and M7, to the smaller and more energy effi-

5

6 System overview and theory

cient M0 and M0+ cores. The main difference between the M0 and M0+ is the smaller

two-stage pipeline of the M0+. They are both based on the same ARMv6-M architecture

and support the same instruction set.

As an example Silicon Lab’s [7] M0+ microprocessor EFM32ZG108 [8] will be used to

describe the functionality and features of a microprocessor.

Figure 2.1: Block diagram of the EFM32ZG108F32 [8].

Figure 2.1 shows a block diagram representation of the internal structure of the EFM32ZG108F32.

The upper half of the diagram shows the main parts of the microprocessor, namely the

core, memory, clocks and power supply.

Memory

As can be seen in the top left corner of Figure 2.1 the processor has two types of internal

memory. The EFM32ZG108F32 comes with 32KB flash memory and 4KB of Random

Access Memory, RAM.

The processor also support something called Direct Memory Access, DMA. DMA is

a feature that allows certain peripherals to read/write from memory without occupying

the core. This allows the core to perform other tasks or go into sleep mode while data is

being transferred.

2.1. Embedded systems 7

Peripherals

A microprocessor typically has some built in features that are commonly used, such as

GPIO, timers, UART, I2C, SPI, DMA, to name a few. These peripherals are supported

in hardware on the same chip as the logic unit itself, and can be used if required by the

application without any additional hardware being added.

Clock configuration

The clock management unit, CMU, consist of a configurable clock tree. The EFM32ZG108F32

has two internal crystals, one low frequency clock running at 32kHz and one high fre-

quency clock running at 21Mhz [8]. It is also possible to connect two external clocks, one

low, and one high frequency for better precision and different base clock speeds.

The high or low frequency clock can be used to clock each peripheral depending on

how it is supposed to be used in the application.

2.1.2 I/O

The main purpose of an embedded system is to process data. For this to be possible

there has to be data to process. An embedded system will most likely be connected to

some kind of sensor or actuator to serve a purpose.

2.1.3 External interfaces

If the microprocessor does not have support for a required interface or functionality an

external chip can be added to the system. Small screens are commonly added to enable

visual feedback when the system is running.

2.1.4 Power consumption

Embedded systems are commonly designed to be as low power as possible. To achieve

this microprocessors typically have some sort of sleep mode feature. In sleep mode the

microprocessor shuts down certain functionalities, like processor core power, clocks and

peripherals, to preserve power.


2.2 ModbusModbus is a widely used serial communications protocol [9]. It is a commonly imple-

mented protocol used to connect industrial electronic devices. Modbus was developed in

1979 with industrial applications in mind, making it easy to deploy and maintain. The

protocol is a strict master/slave set-up, meaning that slaves can only send data over the

network if so asked to by the master. No communication is done between the individual

slaves.

2.2.1 Protocol description

Modbus is a flexible protocol in the sense of its most basic implementation. Table 2.1

shows a summary of the required properties for Basic and Regular implementation, along

with the default settings.

Worth noting is the fact that Modbus does not force you to implement all specified

function codes, but lets you chose what is required for the application at hand.

2.2.2 Data and addressing model

The Modbus data stack is based on four different types of data. Discrete inputs and coils

are single bit data values, while the input- and holding-registers are 16 bits. Discrete

inputs and input registers are read-only from the master’s point of view and acts as

data buffers for sensory input to the slave unit. The coils and holding registers can be

written to by the master and can be set-up to change variables and settings of the slave

if so desired. Table 2.2 shows a summary of the different register types declared by the

Modbus specification.

Modbus has a specified register memory stack for each of the four data types listed

above. They each have 10000 designated addresses. Table 2.3 shows the register memory

map for each of the four data types.

Depending on implementation the function code sometimes acts as an address pointer

to the type the function is acting upon. For example, when requesting to read one input

register the address field is just 0, not 30000.

2.2. Modbus 9

BASIC REGULAR Default value

Addressing Slave: Master: Same as Basic -

config-

urable

address

from 1 to

247

to be able

to address

a slave

from

address 1

to 247

Broadcast Yes Yes -

Baud Rate9600 (19200 is also

recommended)

9600, 19200 +

additional

configurable baud

rates

19200 ( if

implemented,

else 9600)

Parity EVEN

EVEN + possibility

to configure NO and

ODD parity

EVEN

Mode RTU RTU + ASCII RTU

Electrical Interface RS485 2W-cabling

RS485 2W-cabling

(and 4W-cabling as

an additional option)

RS485

2W-cabling

or RS232 or RS232

Connector Type RJ 45 (recommended)

Table 2.1: Table of must have properties of the Modbus protocol [1].

Primary tables Object type Type of Comment

Discrete Input Single bit Read-OnlyThis type of data can be

provided by an I/O system.

Coils Single bit Read-Write

This type of data can be

alterable by an application

program.

Input Registers 16-bit word Read-OnlyThis type of data can be

provided by an I/O system.

Holding Registers 16-bit word Read-Write

This type of data can be al-

tered by an application pro-

gram.

Table 2.2: The four primary tables Modbus bases its data model on [1].


Register type Address range

Discrete Output Coils 1-9999

Discrete Inputs 10000-19999

Input Registers 30000-39999

Holding Registers 40000-49999

Table 2.3: Register memory map for Modbus register types [1].

2.2. Modbus 11

2.2.3 Function codes

The Modbus protocol is based on function codes sent between master and slave. The

function codes determine what action is supposed to be executed. Table 2.4 shows the

complete set of function codes specified by the Modbus protocol.

Function Codes

codesub

codehex

Data

Access

Bit

Access

Physical Discrete

InputsRead Discrete Inputs 02 02

Internal bits

Or

Physical coils

Read coils 01 01

Write Single Coil 05 05

Write Multiple Coils 15 0F

16 bits

access

Physical Input

RegistersRead Input Register 04 04

Internal Registers

Or

Physical Output

Registers

Read Holding Registers 03 03

Write Single Registers 06 06

Write Multiple Registers 16 10

Read/Write Multiple Registers 23 17

Mask Write Register 22 16

Read FIFO queue 24 18

File record accessRead File record 20 14

Write File record 21 15

Diagnostics

Read Exception status 07 07

Diagnostic 08 00-18,20 08

Get Com event counter 11 0B

Get Com event Log 12 0C

Report Server ID 17 11

Read device identification 43 14 2B

OtherEncapsulated Interface

Transport43 13,14 2B

CANopen General Reference 43 13 2B

Table 2.4: Modubs public function code definition [1].

As previously mentioned it is not mandatory to implement all function codes. For

smaller applications it is common to only implement a few read/write functions.

Table 2.5 shows an example request from a Modbus Master. The master is requesting

to read two input registers, 0 and 1, from slave 1. As the slave receives the request it


Slave address Function code Starting address Nr of registers CRC

01 04 00 00 00 02 6B C8

Table 2.5: Modbus Master request to read two input registers from slave one.

first verifies that the slave ID field matches the slaves ID; thereafter it verifies the CRC,

that the function code is valid and lastly that the starting address and address span is

within limits. If the request is deemed complete the slave fetches the requested registers

and replies to the master.

The function code acts as the address pointer to the correct memory span, therefore

the starting address field is numbered from 0-9999 instead of the actual 30000-39999.

Slave address Function code Byte count Register one Register two CRC

01 04 04 00 02 00 03 1A 45

Table 2.6: Modbus slave response with the contents of two input registers.

2.2.4 Exception codes

For the master to be able to supervise the network exception codes are used. If the slave

receives an invalid request it replies with an exception response. This way the master

(and user) can be aware of the status of the slaves. Typical exceptions are; illegal function

code and illegal data address. If the master tries to read from a register not mapped in

the slaves Modbus memory map it will cast an exception. Table 2.7 shows a complete

list of the specified exception codes.

Table 2.8 shows an example Modbus master request to read 16 holding registers from

slave 1. Slave 1 does not have 16 holding registers mapped in its Modbus memory map,

so an exception is thrown. Table 2.9 shows the proper exception response from the slave.

The slave responds with its address per usual but the function code has the most

significant bit set to high to indicate that an exception has been cast. The exception

code 02 indicates that the one or more of the requested registers does not lie within the

slave’s defined address space.

2.2. Modbus 13

Code Name

01 Illegal function

02 Illegal data address

03 Illegal data value

04 Server device failure

05 Acknowledgement

06 Server device busy

08 Memory parity error

0A Gateway path unavailable

0B Gateway target device failed to respond

Table 2.7: Table of Modbus exception codes [1].

Slave address Function code Starting address Nr of registers CRC

01 04 00 00 00 10 F1 C6

Table 2.8: Modbus Master request to read 16 input registers from slave one.

Slave address Function code Exception code CRC

01 84 02 C2 C1

Table 2.9: Modbus slave excpetion response for Illegal address range.


2.3 TIA/EIA-485 (RS-485)

The TIA/EIA-485 (hereafter refereed to as RS485) is a balanced transmission line stan-

dard used in industry applications. RS485 is most commonly used in noisy environments

for applications requiring long cables. In these settings single-ended drivers proves ex-

tremely hard to implement, if possible at all [10]. The RS485 standard strictly concerns

the physical wiring of the network and the functionality of the receiver/transmitter.

The digital differential transmission line interface can handle signal rates up to 50M

bits/s, cable lengths up to 1200 meters and has a much lower noise sensitivity than its

single-ended predecessor, RS232. RS485’s popularity has given rise to a wide selection

of drivers, receivers and transceivers available on market [11].

Due to the versatility of RS485 an increasing number of communication protocol stan-

dards have adopted RS485 as the physical layer standard. Modbus [9], M-Bus [12] and

Profibus [13] to name a few.

A properly set-up RS485 network can handle up to 32 devices, but can be extended

by the use of so called repeaters. Repeaters amplifies the signals on the lines to enable

longer networks with more nodes.

Key parameters Specification limits

Maximum common-mode voltage -7V to 12V

Receiver input resistance 12kΩ minimum

Receiver sensitivity ± 200mV

Driver load 60Ω

Driver output short-circuit limit 250mA for VSHORT -7V to 12V

Table 2.10: Table of RS485 specification highlights [10].

2.3.1 Cabling and connectors

The RS485 standard does not specify cable or connector type, this is done by the man-

ufacturer of the driver/receiver chip, if at all. Common connector types are RJ-11 (e.g

[14]), RJ-45 (e.g [15]) and DB9 [1]. These connectors can though be considered too big

in some applications. In such a case open style screw terminals can be used [11].

The choice of cable is determined by the desired data rate and length of the network.

Cable type should be chosen with care depending on the network requirements. Shielding

and conductor size can be experimented with to minimize jitter and noise[11]. CAT5/6

cables are commonly used when conditions are not extreme.

The network should be set up in a daisy chain configuration, keeping the stubs to a

2.3. TIA/EIA-485 (RS-485) 15

minimum.

2.3.2 Biasing and line termination

Line termination is required at both ends of the RS485 network if the data rates are high.

Exactly when termination is required depends on the cable used, but the termination

resistor should match the characteristic impedance of the cable. Typical values are 120

to 130Ω. DC termination minimizes reflections in the network, decreasing errors.

When the network is idle the cables will ’float’. This can cause the bus to falsely

trigger the receivers. To ’lock’ the data lines down a pull-up resistor to supply voltage

is attached to the positive line, and a pull-down to ground connected to the negative.

With the proper resistor values, depending on the supply voltage, it can be ensured that

the differential voltage will not dip bellow 200mV while idle. [11]

2.3.3 Grounding and protection circuitry

Even though the RS485 data lines are specified as a differential pair three wires might

be required. A return path between circuit grounds and the drivers/receivers is required.

Either each node can be tied down to ground against a frame or chassi, or a third wire

can be added along with the twisted pair to ensure common ground. To avoid creating a

ground loop either a third wire or chassi ground should be used. Using a common ground

ensures that no individual node collects an excessive potential difference that propagates

through the network.

To protect the transceivers from excessive common mode voltages additional protection

can be used. A diode network can be added, but this adds capacitance to the system

resulting in lower data rates. Another approach to circuit protection is optical isolation.

Optical isolation will not add excessive capacitance to the system, but it can take up a

lot of physical space and is a power consuming solution. To ensure a current return path

the third common wire is then mandatory [11].

2.3.4 Noise immunity

Running a differential signal bus greatly reduces the problems with EMC and noise

disturbances. The receiving end of the signal only reads the difference between the lines,

which means that if a surge causes the lines to raise 2V in potential the difference will

still remain the same.

The bus is run through twisted pair cables with also cancels out the noise as both lines

are equally effected. To add additional noise immunity the bus could be run through a

shielded twisted pair cable.

This is one of the main reasons for the popularity of differential signal buses (mainly

RS485) in industrial settings as noise could potentially be a big problem.


2.4 D-Flow’s Engineering Kit

D-Flow offers a ready-to-use Engineering kit solution implementing their flow measure-

ment ASIC UFO 2. To simplify system development the Engineering kit can be used to

build proof of concept solutions quickly. Figure 2.2a shows a picture of the Engineering

kit encapsulated in a standard flow meter casing. Figure 2.2b shows a close up picture

of the UFO 2 ASIC.

(a) D-Flow’s Engineering Kit [16] [17]. (b) D-Flow’s UFO2 ASIC [18].

Figure 2.2: D-Flow’s Engineering Kit and flow measurement ASIC, UFO2.

2.4.1 UFO2 ASIC

D-Flow’s UFO2 ASIC is a single chip solution with an analogue measurement part and a

digital microprocessor part. The ASIC is capable of measuring flow, temperature, energy

flow, level, speed of sound and distance [18] [16]. With its low power features it is capable

of basic flow measurements consuming only 20µA.

2.4.2 Engineering Kit

The Engineering kit connects to the ultrasonic flow meters trough a series of screw

terminals on its side. Thereafter the microprocessor embedded in the ASIC is set-up

through a series of serial commands to perform the desired measurements. The UFO 2

supports eight different measurement types of varying information and data length.

The measured data is then sent out over a serial line to be collected at some kind of

main unit.

2.5. System overview 17

2.5 System overviewA Modbus network consists of one Modbus Master and an arbitrary number of slaves,

connected through RS485. 32 slaves are supported without the use of repeaters. The

Modbus protocol theoretically supports up to 256 slave devices, due to it’s 8 bit address

field, if it can be supported by hardware.

Figure 2.3 shows an overview picture of the complete Modbus network. The Modbus

master is connected with the slaves in a daisy-chain configuration.

ModbusMASTER

ModbusInterface

D-FlowEngi. kit Modbus

Interface

D-FlowEngi. kit

ModbusInterface

D-FlowEngi. kit

RS485

Figure 2.3: Overview of the complete Modbus network.

The scope of this thesis covers the development and design of the Modbus Slave Inter-

face between the Modbus master and D-Flow’s Engineering kit.

The slave interface needs to be able to;

• Properly support the Modbus protocol

• Read the measurement data from the Engineering kit

• Be as low power as possible to enable battery operation

• Be small in size

CHAPTER 3

Hardware

This chapter covers the requirements, design choices and development process of the

hardware. The hardware requirements are stated to specify what functionality the system

demands. The components are chosen with regard to the specifications and finally a PCB

is designed.

3.1 Hardware requirements

To achieve a working Modbus Interface two key parts have to be addressed by the hard-

ware. Firstly the interface requires hardware support for communicating with the phys-

ical layer of Modbus, RS485. Secondly the interface has to be able to handle the serial

communication with D-Flow’s Engineering kit [16]. The system will also have to be able

to process the incoming and outgoing data.


A common way to add intelligence to a system is to add a microprocessor. Microproces-

sors are a cheap, energy efficient way to add logic and computational power to a system

that might otherwise be hard to achieve. The microprocessor is programmed to perform

certain desirable tasks and have a very flexible functionality.

3.1.2 Engineering kit communication

The Engineering kit communication is done serially, so the system will require support

for serial communication. The majority of microprocessors available on market supports

this feature. Throughout the work the communication from the Engineering kit was kept

static at a baud rate of 57 600, 8 data bits and one stop bit.

19

20 Hardware

3.1.3 Modbus communication

The communication with Modbus’s physical layer is done by adding an external transceiver

that converts serial data into a differential signal with the RS485 specifications supported.

This will put an additional requirement on the microprocessor, namely support for run-

ning two separate serial communication lines in parallel.

3.1.4 RS485 termination

For the RS485 network to work properly the lines needs to be terminated. This can

either be done external to the interface or be integrated on each interface.

3.1.5 Connectors

A proper set of connectors is required to connect the interface to D-Flow’s Engineering

kit and to connect the device to the RS485 network.

3.1.6 Summary

In summation, the Modbus interface requires;

• One microprocessor with support for two serial communication interfaces

• One RS485 compliant transceiver

• Modifiable line termination resistors

• Connectors to the development board and RS485 network

3.2. Component choices 21

3.2 Component choices

This section covers the key points of the component choice process.

3.2.1 RS485 transceiver

Due to the popularity of the RS485 network there is a plentitude of drivers, receivers and

transceivers available on market. Sadly most of them have a high power consumption

and run on 5V+ voltage supply. This limits the search a lot. Luckily the pinout of the

transceivers are standardized, which means that they are easily replaced with a different

component.

The prototype board was based on Maxim Integrated’s [19] MAX3485 [20]. Due to it’s

high, ∼ 1mA, power consumption it was replaced by Intersil’s [21] ISL32603E [22]. The

ISL32603E has a much lower power consumption, ∼ 100µA, and was much more suitable

for the application.


Architecture

Due to previous experience, availability on market, and good support, the ARM archi-

tecture was chosen to be the base of the system. The aim of this thesis was to keep the

power consumption low, and since the system was not computationally heavy the choice

was between the more established M0 and the newer but more power efficient M0+ cores.

Peripheral requirements

The next step was to specify the peripheral requirements of the system in order to meet

the specified functionality.

To communicate with the RS485 transceiver and the Engineering kit two separate serial

interfaces, UART/USART, were required.

In addition to the UART/USART’s the RX pin was used to generate an interrupt

to wake the core when a new message arrives. This requires at least two GPIO’s with

interrupt capabilities.

The transceiver also requires two GPIO’s to control the drive/receive functionality.

In order to free the core while data is being read from either the Engineering kit or the

transceiver, Direct Memory Access (DMA) was used. This enables the microprocessor

to perform other tasks while loading the data read into memory. Due to the non-static

length of messages from the surrounding systems two timers were required to generate

a ’time out’ interrupt when nothing had been read for a specified amount of time. This

interrupt was used instead of the internal DMA complete interrupt.

22 Hardware

Peripheral Number of Number of pins

UART/USART 2 RX/TX 4

GPIO 4 4

TIMER 2 0

DMA 4 channels 0

Table 3.1: Summary of required peripherals.

Table 3.1 shows a summary of the required pins and their functionality. The micropro-

cessor chosen had to support all of the functionality listed above. At least 8 I/O’s had

to be available for use.

Manufacturer

Using the functionality criteria discussed above as a basis for the search the power con-

sumption was the final parameter of concern. A number of microprocessor datasheets

were examined and finally Silicon Lab’s [7] EFM32ZG108 [8] was chosen, due to it’s low

power consumption, good product support and available development board [23].

3.2.3 Crystals

The crystals were both chosen to match the existing high/low frequency clocks of D-

Flow’s Engineering Kits, mainly due to component uniformity across D-Flow’s product

selection. Using the same components across different applications simplifies production.

High frequency clock

The chosen high frequency clock runs at 16Mhz [24]. Even though the microprocessor

supports up to 24Mhz as that was judged unnecessary. The small 7.5×5.1×1.4mm SMD

packaging makes it suitable for small size embedded systems.

Low frequency clock

The low frequency clock runs at 32.768kHz [25]. The high accuracy, ±20ppm, and small

size, 3.2×1.5×0.65mm, makes it suitable for low power embedded systems.

3.2.4 Connectors

Engineering kit connector

The output connector of D-Flow’s development board is a 1×4 2.54mm male pin header.

Therefore a suitable solution is to mount a female header on the bottom side of the board

3.2. Component choices 23

for stackabillity and mechanical stability.

The Engineering kit connector also provided a power supply pin carrying the regulated

3V powering the on-board ASIC. This power supply pin was used to power the Modbus

interface as well.

RS485 connector

The Modbus standard does not specify a connector to the RS485 network. This means

that any option suitable for the application at hand is applicable. Due to the small

size requirements of the interface, connectors such as RJ45 simply can not be used.

Instead two three pin screw terminals were chosen. Due to their simple mounting, robust

structure and easy use they made suitable candidates.

programming connector

A 2×3 male 2.54mm pin header was chosen for the SWD programming header. The wide

availability and common use makes it a suitable choice. Due to size concerns a through

hole model was used, as the surface mounted version requires slightly more space.

3.2.5 Passive components

Resistors

To properly terminate the RS485 network two resistor networks are required. Figure

3.1a shows the end-of-the-line termination located at the very end of the network. This

resistor should be impedance matched with the characteristic impedance of the cable

used. [11]

Figure 3.1b shows the bias network used to ensure that the voltage difference between

the positive and negative differential lines is bigger than 200mV. The values chosen to

achieve this depends on the characteristic impedance of the cable and supply voltage of

the system. [11]

Capacitors

To minimize disturbance in the system decoupling capacitors were added to every power

pin in the system. Decoupling capacitors filters out some of the noise on the power line

and stabilizes the power supply to the microprocessor and transceiver.

24 Hardware

(a) Differential line termination resistor circuit.

(b) Differential line voltage bias circuit.

Figure 3.1: The two required resistor networks to properly terminate and bias a RS485

network.

3.3. PCB design 25

3.3 PCB design

To simplify the measurements a printed circuit board version of the prototype board

circuit was designed. The PCB layouts and schematics were designed using Altium

Designer 15 [26].

3.3.1 Modbus Interface

To improve the mechanical stability of the stack-on design a mounting hole was aligned

with the existing one of the Engineering kit. Mounting the two boards together with a

distance increases mechanical stability and ensures that the majority of the stress is not

put on the fragile 2.54mm header that could possibly break.

A number of holes were cut out from the board to enable access to the sensor input

screw terminals that are placed directly under the Modbus Interface. The holes can be

seen running down along the right side of the board, see Figure 3.2a.

(a) Top side of Modbus Interface PCB. (b) Bottom side of Modbus Interface PCB.

Figure 3.2: Modbus Interface PCB top and bottom side.

3.3.2 Programming adapter

To simplify the connection between the programmers 40 pin SWD output header and the

6 pin SWD on the Modbus interface board a small adapter was designed. The required

6 pins were mapped from the 40 pin debugging header of the programmer.

26 Hardware

(a) Top side of programming adapter. (b) Bottom side of programming adapter.

Figure 3.3: Programming adapter PCB top and bottom side.

Due to the minimalistic design of the PCB regular 2.54mm jumpers were not a suitable

choice. Instead a so called solder jumper was used. A solder jumper is two unpopulated

pads close together that can easily be joined with solder. This closes the connection and

act like a jumper. Though removable they are not as easily configurable as the regular

pin jumpers. In this case it was determined that a smaller board was more important

than being able to quickly hook up the line termination, and solder jumpers were used.

For future reference the bottom side of the adapter board was used to try out a few

different footprint designs of the solder jumpers. The designs can be seen in Figure 3.3b.

CHAPTER 4

Software

This chapter describes the development and functionality of the software involved in

this project. The general structure and design choices are discussed based on flowchart

representations of the code.

4.1 Programming environment

All the code for this project was written in the programming language C. To program

the development board and completed interface PCB, Silicon Lab’s [7], Simplicity Stu-

dio 3.0 [27] was used. To ensure compatibility and support for programming both the

development board and external processors this was the most convenient choice.

Simplicity Studio comes with some convenient features. First and foremost the Sim-

plicity Integrated Development Environment, IDE, that was used to write all the code

and debug the processors.

Another excellent feature is the Energy Profiler that takes measurements from the

on-board current measurement circuitry and displays the power consumption of the pro-

cessor on the development board as a graph in real time. This simplified the development

and debugging of the system as the measured values could be used as a guide to see if the

processor entered sleep modes correctly. Initially it was used as a guideline to benchmark

the prototype before moving on to producing a PCB version of the system. Unfortunately

the Energy profiler only measures the power consumption of the processor itself and the

existing peripherals on the development board. It does not measure the power consump-

tion of any external devices connected to the 3.3/5V pins.

Simplicity Studio also features a Flash Programmer-tool which enables the develop-

ment board to act as a SWD-programmer. The interface PCB’s programming pins were

connected to the development board’s debug-out header and programmed that way.

27

28 Software

4.2 EFM32 Zero Gecko development board

The development board used to prototype the system was Silicon Labs EFM32 Zero

Gecko Starter Kit STK3200 [23]. The development kit was used due to the fact that it has

the same processor as was to be used on the Modbus Interface. The direct compatibility

ensured that the prototype would be a good bench mark of the actual product.

Figure 4.1: EFM32 Zero Gecko development board [23] and prototype Modbus interface.

Figure 4.1 shows a picture of the prototype Modbus interface used in the initial design

phase of the software and the EFM32 Zero Gecko development board.

4.3 Sleep mode scheduling

To keep the power consumption as low as possible the processor needs to be kept in sleep

mode for the majority of the time. This is made possible by either using an interrupt

driven style of programming or a kernel. It was decided that the application did not

motivate the use of a kernel due to its simplicity and the linearity of the system.

Figure 4.2 shows the general structure of the system.

4.4 Peripheral configuration

As previously discussed in Section 3.1.6 and 3.2.2 a number of peripherals are required.

4.4. Peripheral configuration 29

EM0

Sleep until interrupt

Process ASIC data

Process Modbus request

EM2

Figure 4.2: General system structure flowchart.

4.4.1 Clock configuration

The Clock Management Unit (CMU) was configured to activate all the required clocks

to run the desired peripherals. The high frequency clock was divided to run at 1.2Mhz.

4.4.2 USART/LEUART

Both the USART and LEUART was configured to run at 8 bits of data, no parity and

one stop bit at a baud rate of 57 600 bits/s.

4.4.3 Direct Memory Access, DMA

A total of four DMA channels were set-up to move data from the RX/TX buffers of the

two serial communication interfaces. The data was stored in a buffer and later handled

in the proper way depending on source or target.

The DMA resets right before the processor re-enters sleep mode after performing the

desired task.

4.4.4 GPIO

To generate the desired interrupts to wake the microprocessor from sleep two GPIO

interrupt handlers were configured. Both pins were connected to the RX pins of the

USART/LEUART respectively to trigger an interrupt on falling edge. As the start bit

arrives the system is woken up by the generated interrupt and then processes the incoming

data.

30 Software

4.4.5 Timers

To handle the varying sizes of incoming data from both the Modbus Master and En-

gineering Kit two timers were configured. The timers were set to count the time from

the last received byte from both the USART and LEUART. If the time since the last

byte was longer than 2ms an interrupt was generated to signal end of message and the

interface moves on to process the new data.

4.5 Serial communicationThe serial communication is based on interrupts. The first start bit of each message

generates a GPIO interrupt that wakes the microprocessor. The interrupt handler for

each communication line sets a flag to true to indicate that the event has occurred, and

disable itself. Simply setting a flag in the interrupt handler enables the two routines to

overlap without disrupting the processes so much that the system breaks.

The stability of this approach was tested experimentally.

4.5.1 Development board communication

Due to confidentiality agreements a made up data structure will be used from here on

out to represent the flow sensor data.

Start of message Header Payload CRC End of message

Table 4.1: ASIC data representation.

Table 4.1 shows the general structure of the development board data format. As the

data is sent from the development board to the interface the start bit generates an in-

terrupt that wakes the microprocessor. As soon as the interrupt has been generated it is

turned off to prevent false readings. As the message is being read by the DMA a timer

keeps track of how long ago the last byte was received. When the DMA has not read any

new data in 2ms the message is considered complete. Upon the interrupt of the timer the

message starts to get processed and checked. A start and end of message check is per-

formed, as well as a length control and CRC check. If the message is considered complete

the payload will be divided into the Modbus registers according the structure described

in Section 4.7.1. When the data has been properly sorted into its respective Modbus

register the interrupt is reactivated along with its corresponding DMA channel, and then

put back into sleep mode. Figure 4.3 shows a flowchart of the serial communication.

4.5. Serial communication 31

GPIO_IRQLEUART

GPIO LEUART

GPIO LEUART

Wait for interrupt

GPIO_IRQUSART

GPIO USART

GPIO USART

IFUSART_GPIO

IFLEUART_GPIO

Wait for USART time out

Check start/end of message

Check message length

Check message CRC

Load data into Modbus registers

GPIO USART

Wait for LEUART time out

Exception check request

IFException

Send Modbus reply

Send exception reply

GPIO LEUART

EM2

True

False

False

True

False

True

EM0

Figure 4.3: Serial communication code flowchart.

32 Software


Slave address Function code Payload CRC

Table 4.2: Generalized Modbus master request [1].

The procedure of handling a Modbus request is done similarly as with the ASIC data.

As the first start bit is sent from the transceiver an interrupt in generated to wake the

microprocessor, then turned off. The DMA transfers all the data into a data buffer and

the timer keeps track of when the message ends. The data is then checked for exceptions

and completeness. If the message is considered valid the function code determines the

proper action of the interface. The data is then either collected from or written to the

register addresses corresponding to the values of the address field in the request’s payload.

When the slave has responded to it’s request the Modbus interrupt it reactivated along

with it’s corresponding DMA channel, and then put back into sleep mode.

Figure 4.4 shows a complete flowchart of the Modbus communication.

4.5. Serial communication 33

GPIO_IRQLEUART

GPIO LEUART

GPIO LEUART

Wait for Modbus master request

Wait for LEUART time out

Get Modbus message

Validate slave address

Validate function code

Validate data address

Validate data value

Send Modbus reply

Exception code = 1

Exception code = 2

Exception code = 3

Excecute Modbus function

Send Modbus exceptionresponse

False

False

True

True

True

False

False

EM2

EM0

Figure 4.4: Modbus execution code flowchart.

34 Software

4.6 Modbus implementation

The Engineering kit has multiple measurement types, differing in content and size. Bellow

the mock-up data structure is used to explain the general implementation details.

4.6.1 Function and exception codes

As previously discussed in Section 2.2.3 it is not mandatory to implement all the function

codes specified in the Modbus protocol. For this specific application only four function

codes are supported. Table 4.3 shows a complete list of the supported function codes

along with a short description.

Supported function Function

code

3 Read Holding register

4 Read Input register

6 Write single register

16 Write multiple registers

Table 4.3: Table of supported Modbus function codes.

Due to the limitations in the implemented functions codes all exception codes were not

needed. Only two function codes were relevant in regard of the function codes. Table 4.4

shows a complete list of implemented exception codes and a short description.

Supported Exception Exception

code

1 Read Holding register

2 Read Input register

Table 4.4: Table of supported Modbus exception codes.

The above function and exception codes was enough to cover the specified functionality

of the Modbus slave inteface.

4.7. Modbus master simulator 35

4.7 Modbus master simulator

Development of the Modbus master was not included within the frames of this thesis.

To be able to test the Modbus slave interface a freely available open source Modbus

master simulator was used. Radzio! Modbus Master Simulator [28] provides all the

basic functionality of a Modbus master. It supports all the read/write function codes

implemented in the Modbus slave interface.

Figure 4.5: Print screen of Radzio! Modbus Master Simulation GUI.

Figure 4.5 shows a print screen of the Modbus Master Simulator’s graphical interface.

4.7.1 Modbus registers configuration

The output data from the Engineering kit is sorted into the Modbus Input registers of

the slave. All measurement data is not of the same length, so the length will have to

be modified to fit the specified 16-bit register size of Modbus. The Engineering kit ID,

REV, NR and SEQ are all 8-bits of data, but take up an entire 16-bit Modbus register

each. The majority of the measurement data is in 32-bit format, which requires the slave

to split the data between two Input registers. This splitting is done in big endian. A

total of 35 Input registers are implemented in the Modbus Interface. Table 4.5 shows a

complete list of one of the measurement types of the Engineering kit.

Since the holding registers are read/write form the master’s point of view these regis-

ters can be used to change the settings of the salve. Due to size and pinout limitations a

36 Software

Input register Value

30000 ID

30001 REV

30002 NR

30003 SEQ

30004 Measurement 1

30005 Measurement 2

30006 Measurement 3 High

30007 Measurement 3 Low...

30033 Measurement 16 Low

30034 Measurement 17 High

30035 Measurement 18 Low

Table 4.5: Input register memory structure.

physical slave ID interface was not included on the PCB. This meant that another way of

setting the address was required. The approach used was to dedicate a holding register

to be the address of the slave. Whenever the master writes to Holding register 40000

the salve will automatically change its address to the value at hand. This means that all

slaves can be set-up with a default slave address, 1, and then connected one at the time,

being appointed a new address by the master. Unfortunately this also means that the

slave addresses have to be reconfigured every time the system is reset, since it will then

return to its default settings.

In the same manner the baud rate of the Modbus communication can be changed by

writing the desired value to Holding register 40001.

Table 4.6 shows a complete list of the implemented Holding registers.

Holding register Value

40000 Slave ID

40001 Baud rate

Table 4.6: Holding register memory structure.

CHAPTER 5

Measurements and testing

This chapter presents the measurement data and test cases run on the system. Robustness

and stress testing data is presented. Power consumptions measurements are performed

with different variables changed to ensure the lowest possible power consumption.

5.1 Robustness and reliability

5.1.1 Start up delay

To ensure that the system wakes up on time to read all the bits in the incoming message

the clock has to stabilize as soon as possible after arrival. How small this time frame is is

hard to say and has to be proven by long term testing. Figure 5.1 shows a measurement

of the time delay between the start bit (bottom wave, yellow) and the start-up of the

high frequency clock (top wave, blue). The time delay turns out to be 2.74µs, which with

a baud rate of 57 600 bits per second is 15.8% of a bit, see Equation 5.1.

2.74

(1/57600)µ = 15.8% (5.1)

The measured start-up time compares well with the 2µs specified in the datasheet [8].

5.1.2 Awake time

To measure how long the processor spends in fully operational mode, EM0, the clock

signal was through put to a GPIO pin and measured. The test was run using a Modbus

and Engineering kit communication baud rate of 57 600, sending and collecting data at

1 Hz, requesting 35 registers of data while running the high frequency clock at 1.2Mhz.

Figure 5.2a shows the time spent awake to read and properly sort the incoming data

from the Engineering kit. Figure 5.2b shows the time spent awake to read, interpret and

37

38 Measurements and testing

reply to a Modbus command.

Figure 5.1: Delay between wake-up interrupt and clock stabilization.

(a) High frequency clock signal when collecting

one cycle of ASIC measurement data.(b) High frequency clock signal when processing

and replying the to Modbus master request.

Figure 5.2: Measurements of the active time of the high frequency clock for both tasks.

As summarized in Table 5.1 the total time spent awake to read one measurement and

reply to the Modbus masters request of 35 data registers is 57.6ms.

5.1. Robustness and reliability 39

Time awake

[ms ]

Development board 26

Modbus 31.6

Total 57.6

Table 5.1: Table of time spent awake by each process and the total time spent awake by

one cycle of sensor data collection and Modbus request.

5.1.3 Long term functionality

Long term testing is hard within a limited time frame of the project. A number of tests

were performed by running the system over nights and weekends to see if the Modbus

Master Simulator detected any errors in the incoming Modbus messages. Figure 5.3

shows a print screen of the Radzio! Modbus Master Simulator with the frame counter

high lighted in red. The frame counter feature counts the number of received Modbus

messages and how many of them were successful or failed.

Figure 5.3: Print screen of Radzio! Modbus Master Simulatior [28].


The longest running test lasted for five days without a fail.

This method of testing only ensures that the Modbus message has arrived correctly,

not the ASIC data itself. To test this another program has to be developed that knows

the expected structure of the data in such a way that it can validate the ASIC behaviour.

Such a procedure is possible, but confidential.

5.1.4 Stress test

The Modbus polling frequency and ASIC data retrieval rate can both be changed. In-

creasing the frequency at which data is requested by the master will increase the stress

on the system. A series of tests were made where the ASIC measurement frequency and

Modbus polling frequency was increased in 1Hz intervals. The system was run for one

hour to ensure stability.

Running the system at 16Hz ASIC measurement and Modbus polling frequency turned

out stable over the one hour test, but higher frequencies failed.

5.1.5 Multiple slave network

Two slaves were connected to the same master and could be properly addressed and

send/receive data without collisions. This would have to be tested further to ensure

proper functionality. Due to time restrictions a multi-slave network with more than two

slaves was never tested.

5.2. Power consumption measurements 41

5.2 Power consumption measurementsA series of tests were run to measure the power consumption aspect of each part of the

system. The tests were done using a FLUKE 289 [29] multimeter and the plots were

drawn in Octave [30]. All graphs represent the corresponding data table interpolated

over the measurement interval.


To measure the power consumption of each of the two major parts, the Modbus and

Engineering kit communication, each part was turned off in turns. The Engineering kit

communication was turned off, meaning that the Modbus registers were all zero. The

Modbus polling frequency was set to three different frequencies; 1, 2 and 4Hz. The

average power consumption for each of the frequencies was measured over a time interval

of five minutes to get a stable value. Table 5.4a shows a summary of the measured power

consumption of the interface when the development board communication is turned off.

Polling Power consumption

frequency [µA]

1Hz 80

2Hz 93

4Hz 119

(a) Table of power consumption of the Modbus

communication for three different polling/ASIC

frequencies.

(b) Plot of power consumption of the Modbus

communication for three different polling/ASIC

frequencies.

Figure 5.4: Power consumption measurement data for the Modbus communication.

From the values in Table 5.4a an average cost per Hz can be calculated to 13µA/Hz.


5.2.2 Engineering kit communication

In the same manner as previously the interface was tested with the Modbus communica-

tion and transceiver turned off, only collecting Engineering Kit data. To ensure minimal

impact from the transceiver it was put into sleep mode.

Polling/ASIC Power consumption

frequency

1Hz 25

2Hz 32

4Hz 46

(a) Table of power consumption of the develop-

ment board communication for three different

polling/sensor reading frequencies.

(b) Table of power consumption of the develop-

ment board communication for three different

polling/ASIC frequencies.

Figure 5.5: Power consumption measurement data for the development board communi-

cation.

From the values in Table 5.5a an average cost per Hz can be calculated to 7µA/Hz.


5.2.3 Full operations

When the power consumption of the two major communication lines had been deter-

mined the system was put into fully operational mode. Theoretically the total power

consumption should be the addition of the power consumption of the two individual

parts.

Polling/ASIC Power consumption

frequency

1Hz 119

2Hz 154

4Hz 191

(a) Table of power consumption of the

fully operational system for three different

polling/ASIC frequencies.

(b) Plot of power consumption of the fully oper-

ational system for three different polling/ASIC

frequencies.

Figure 5.6: Power consumption measurement data running at full operations.

From the values in Table 5.6a an average cost per Hz can be calculated to 26.75µA/Hz.


5.2.4 Power vs. baud rate

To determine the power consumption dependencies of the baud rate used for serial com-

munication a series of tests were done using different baud rates for the serial communi-

cation. The same baud rates were used for both Modbus and Engineering kit communi-

cation. The tests were run at a polling and ASIC measurement frequency of 1Hz.

Baud rate Power consumption [µA]

9600 131

19200 127

38400 125

57600 121

(a) Table of power consumption for four differ-

ent serial communication baud rates.

(b) Plot of power consumption for four different

serial communication baud rates.

Figure 5.7: Power consumption measurement data running at full operations with differ-

ent serial communication baud rates.


5.2.5 Power vs. high frequency clock speed

Another important aspect of optimizing embedded systems is clock speed. Depending on

the system at hand and its purpose, different clock speeds are considered ideal. In the

case of the Modbus Interface the main concern is the power consumption, so a series of

tests were performed varying the high frequency clock speed to determine a relationship

between power consumption, computational speed and clock frequency. The tests were

run a a polling and sensor reading frequency on 1Hz.

High frequency Power consumption [µA]

clock speed

1.2Mhz 120

6.5Mhz 149

10.9Mhz 184

14Mhz 200


ent high frequency clock speeds.


high frequency clock speeds.


ent high frequency clock speeds.

From the values in Table 5.6a an average cost per Mhz can be calculated to 6.3µA/MHz.


5.2.6 Power vs. data package size

Longer packages require longer times in full speed operation mode, EM0. To determine

a relationship between the requested package length and power consumption a series of

tests were performed where the Modbus master was set-up to request different amount of

registers. The rest of the system was set up with a 1Hz polling/sensor reading frequency,

a baud rate of 57 600 bits/s and a 1.2Mhz clock speed.

Data register Power consumption [µA]

amount

5 113

10 115

20 118

35 121


ent requested amounts of registers.


requested amounts of data registers.


ent number of data registers requested.

From the values in Table 5.6a an average cost per MHz can be calculated to 0.35µA/data

register.


5.2.7 Battery life calculations

Given some of the most likely configurations the battery life was calculated using the

following formulas,

Battery capacity ∗ 1%years = Available charge (5.2)

Available charge

years ∗ days ∗ hours= Available current. (5.3)

The batteries used for the calculations are manufactured by SAFT [31]. Three different

sizes of batteries will be compared, all with a voltage of 3.6V, with a desired system life

length of 10 and 15 years. A 1% self-dischange per year is assumed for all batteries as

the datasheets do not specify this.

Using Equations 5.2 and 5.3 the current available for each battery and life span can be

calculated.

LS 14500 [32] LS 17500 [33] LS 26500 [34]

Nominal capacity [Ah] 2.6 3.6 7.7

10 yearsAvailable charge [Ah] 2.3514 3.2558 6.9637

Available current [µA] 26.842 37.166 79.495

15 yearsAvailable charge [Ah] 2.2362 3.0962 6.6224

Available current [µA] 17.018 23.563 50.399

Table 5.2: Table of calculated available current for a 10 and 15 year life span of the

system for three different battery sizes.

Table 5.2 shows a summary of the calculated available current for the three different

batteries and life spans.

LS 14500 [32] LS 17500 [33] LS 26500 [34]

Nominal capacity [Ah] 2.6 3.6 7.7

Expected life time [years ] 2.41 3.31 6.84

Table 5.3: Table of calculated expected life span of the system for three different battery

sizes and a system power consumption of 120µA.

CHAPTER 6

Results

In this chapter the results are summarized and presented. The still present problems and

required testing is brought to light along with the parts of the thesis that was completed

and verified.

6.1 HardwareSince the hardware was thoroughly tested before the PCB was designed no functional

problems arose with the PCB. With the exception of the access holes to the sensor input

screw terminals might be increased in size to make for easier access no major fault was

found with the hardware.

Figure 6.1 shows a photograph of the Modbus slave interface mounted on the Engi-

neering kit.

6.2 SoftwareThe core functionality of the software was completed as planned. The software properly

implements the basic functionality of the Modbus protocol and during testing appeared

stable.

Based on the measurements presented in Chapter 5 the current basic configuration of

the system is as follows,

• Baud rate: 57 600

• Clock speed: 1.2Mhz.

49

50 Results

Figure 6.1: Modbus Interface mounted on D-Flow’s development board.

6.3. Power consumption 51

6.3 Power consumption

Due to the problematically high power consumption of the RS485 transceiver the power

consumption goals were not met. As can be seen in Table 5.3 the life span of the entire

system running on battery power is not the desired 10-15 years. This means that in its

current state the system requires external power from a power line. Disregarding the

static power consumption of the transceiver though, the dynamic overlay of the system

stays within the specified 60µA.

Modbus communication

As seen in Figure 5.4b the polling frequency dependency of the power consumption is

very linear. This is not very surprising since the polling frequency just determines how

many times the microprocessor wakes up each second; one, two or four times. The calcu-

lations are still the same every wake-up, which means that the power consumption will

just be a multiple of the amount of wake-ups.

Engineering kit communication

Figure 5.5b shows the same highly linear behaviour as for the Modbus communication.

Full operations

Figure 5.6b shows that the dependency is not as linear as the two separate parts in them-

selves. This means that the average power consumption per Hz will not be a very good

approximation. The average value is slightly higher than the sum of the two communi-

cation links separately.

Baud rate

As seen in Figure 5.7b the power consumption goes down as the baud rate increases.

The increased time to read/write messages to the Modbus master when running slower

baud rates, increases the time the microprocessor has to be awake, increasing the power

consumption.

High frequency clock speed

Figure 5.8b shows that a lower clock speed is preferred in terms of low power consumption.

52 Results

Data package size

As seen in Figure 5.9b the power consumption increases as the number of requested

registers increase.

6.4 ReliabilityDuring the limited testing that was performed the system appeared stable.

CHAPTER 7

Discussion and conclusions

7.1 Hardware

The hardware worked as expected overall. Besides changing the footprint of the solder

jumpers nothing problematic layout wise was discovered during testing.

The current version of the system uses software determined slave addressing. A com-

mon way to handle this in PLC-type modules is to implement a hardware switch that

determines the address in binary depending on which pins are set high/low. This was

decided against in the current version due to the required upgrade in processor size (from

24 pin to 32) and the physical size of the switch itself. A more extensive survey could

be done to determine the exact cost/size versus usability/implementation advantages

between the two approaches. An external EEPROM could be implemented to store the

slave ID between resets. To minimize its power consumption cost it could be powered on

only when required, but otherwise sleep.

Before the interface is ready for market extensive EMC testing is required to determine

the disturbance propagation between the interface and the Engineering kit. It was never

tested within the scope of this project to measure the possible impact on measurement

values from the flow meters. The interface is placed directly above the input terminals

for the flow meters, so it is possible that some disturbances from, foremost, the crystal

propagates down through the board. Redesigning the board shape to overlap more to-

wards the other side of the board, away from the flow meter input terminals, could be

a good option to be on the safe side. This could impact the mechanical stability of the

board stack though, if not taken into account.

Due to the high power consumption of the RS485 transceivers currently available one

option could be to deliver power through the differential signal lines. By biasing the

lines to 3V the data signal could be filtered out and the potential difference used to

53

54 Discussion and conclusions

power the interface. Since the data is read as the difference between the two lines the

communication would not be affected by doing this. This would mean that no battery

would be required to run the system. The down side would be the required extension in

hardware. To filter the data signal some kind of rectifier would have to be constructed

which will take up a lot of room on the Interface PCB.

To simplify assembly of the product in mass production the amount of through-hole

connectors could be lowered. The programming connector could be changed to a surface

mounted version, or even just pads for a pogo-pin frame to connect to. Programming the

interface with pogo-pins would remove some of the physical bulkiness of the permanently

mounter connector.

Towards the middle of the project news from Atmel was published concerning their

new M0+ processor, SAM L21. According to the released information this processor will

require as little as a third of the power consumption of the Zero Gecko. No release date

has yet been announced, but once released an investigation would have to be conducted

whether of not the project should be ported to the SAM L21 processor before bringing

the product to market.

7.2 Software

The software implementation of the Modbus protocol works as intended. The code itself

could use some tidying up though. The current version of the software is dependant on

functions from the emlib. The system could be rewritten to be completely independent

from the native libraries of EFM32 to make it more generic if so desired.

The use of holding registers to change the settings of the slave and the Engineering kit

could be extended. Interesting setting would be to change the measurement frequency

and measurement type of the Engineering kit. The Modbus communication it self could

be configurable as well. Things such as parity, number of data bits, stop bits and baud

rate could be implemented as configurable settings.

By implementing these functionalities the set-up process and maintenance could be

simplified. Instead of disassembling the network to program each individual slave it

could be done by the Modbus master.

One could try to implement a number of light weight kernels to see how the power

consumption changes. Though this was not in the scope of this project the results could

be interesting if run in strictly specified testing environments.

7.3. Power consumption 55

7.2.1 Engineering kit setup

The Engineering kit is set-up through commands sent over its serial interface. Sending

commands to the salve over Modbus could act as a link to each of the individual on-

board ASIC’s on the Engineering kits. The current solution is to physically connect to

each of the Engineering kits and setting it up for the desired measurements, this could be

greatly simplified by just sending a set of commands from the Modbus master. Dedicating

a number of holding registers to act as the ’programmer’ of the Engineering kit. This

functionality would greatly improve the usability of the system.

7.3 Power consumption

Over all the power consumption of the processor itself falls within specification.

The biggest problem with the system as a whole is the power consumption of the RS485

transceiver. In the current version the transceiver alone draws 90% of the total power.

No decent substitute was found during the project. A possible way around the problem

could be to design a custom transceiver out of comparators. This was not investigated

in the scope of this work and is purely speculation. Another way around the transceiver

problem could be to integrate a separate driver and receiver chip. In that case the driver

can be shut down while not sending data, which might lower the total power consump-

tion. Writing a on/off-scheduled for the transceiver is possible, but this would require

knowledge of an approximate arrival time of the Modbus master requests as well as the

ASIC data. This would strictly limit the flexibility of the system, which works against

the fundamental ideas that makes Modbus such a good protocol.

7.4 Testing and measurements

Even though a series of measurements were performed a more extensive study should be

done. By setting up a proper test bench for the system the results would be more reliable

and might reveal previously missed flaws of the system.

A number of longer long term functionality test would have to be conducted before the

system can be considered complete. Stress testing over longer periods of time and testing

in noisy environment would also be required. Controlled surge testing, discharge testing

and voltage overload testing is also good, to see how the system effects the network if a

unit would break in an unexpected way.

The serial communication and wake up times of the microprocessor should be examined

and measured in depth to ensure stability. A series of response time measurements and

long term tests should be performed with varied settings of crystal clock speed and baud

rates.

56 Discussion and conclusions

7.5 Alternative approachesDue to the specifications from D-flow and time restrictions of the project a microproces-

sor was used as the main logic of the Modbus slave interface. Another possible solution

could be to develop an application specific ASIC. This could possibly solve the power

consumption problems of the RS485 transceiver.

Another possible approach could be to investigate the possibility of power harvesting of

the differential lines of the RS485 network. This option was discussed during the project,

but there was not enough time to thoroughly investigate the advantages/disadvantages

of such an implementation.

APPENDIX A

Component list

Component Description Amount Distributor Distributor ID

EFM32ZG108F32 Micro processor 1 Digikey 336-2579-ND

MAX3485CSA+-ND RS485 transceiver 1 Digikey MAX3485CSA+-ND

CAP 12pF 10V Capacitor 2 Digikey 311-1100-1-ND

CAP 22pF 10V Capacitor 2 Digikey 311-1103-1-ND

CAP 10nF 10V Capacitor 2 Digikey 399-7989-1-ND

CAP 100nF 10V Capacitor 3 Digikey 399-1171-1-ND

CAP 1uF 10V Capacitor 1 Digikey 399-8002-1-ND

CAP 10uF 10V Capacitor 1 Digikey 399-3525-1-ND

RES 0Ω Resistor 1 Digikey 311-0.0ARCT-ND

RES 100Ω Resistor 2 Digikey 311-100ARCT-ND

RES 470Ω Resistor 2 Digikey 311-470ARCT-ND

Header 3x2 Male header 1 Elfa 43-717-12

Header 4x1 Female header 1 Elfa 43-782-79

Phoenix 1x3 Screw terminal 1 Elfa 48-354-19

16Mhz XTAL Oscillator 1 Elfa 74-585-65

32kHz XTAL Oscillator 1 RScomponents 814-9358

Table A.1: List of components and the distributor used.

57

APPENDIX B

Modbus Interface PCB

B.1 Modbus Interface schematic

1

1

2

2

3

3

4

4

D D

C C

B B

A A

Title

Number RevisionSize

A4

Date: 2015-04-27 Sheet ofFile: C:\Users\..\ModBus_Interface.SchDoc Drawn By:

RO 1

RE 2DE3

DI4

GND 5

A 6

B 7

VCC8

U2

MAX3082CSA+

GND

VCC

GNDC2100nF

C3100nF

C12

100nFC110uF

X1 1

2

3

4

X2

HFXTALPHFXTALN

LFXTALPLFXTALN

C722pF

C822pF

C912pF

C1012pF

VCC

C510nF

C610nF

GND

VCC VCC

GND

GND

GND

LFXTALPLFXTALN

GND

HFXTALPHFXTALN

RS485 INRS485 OUTHFXTAL 16MHzLFXTAL 32KHz

Analog decoupling

Digital decoupling

modbus_Pmodbus_N

R4470

R2470

GND

VCC

R1100

R3100

SWD ASIC connector

DE REREDE LEU_TX LEU_RX

LEU_TX

LEU_RX

SWDCLKSWDIO

US_RXUS_TX

LEU_RX

RST

SWDIOSWDCLKLEU_TX RSTR5

0

GND

VCC

US_RXUS_TX

GND

VCC GND

1234

JP2

Header 4X1

C11

1uFVSS 0

PA01

IOVDD_02

PC03

PC14

PB7 5

PB8 6

RESETn7

PB11 8

AVDD_29

PB13 10

PB14 11

AVDD_012

PD6 13

PD7 14

VDD_DREG15

DECOUPLE 16

PC1417

PC1518

PF0 19

PF1 20

PF2 21

IOVDD_522

PE1223

PE1324

U1

EFM32ZG108F32-QFN24

1 23 45 6

JP1

Header 3X2modbus_N

modbus_N

modbus_Pmodbus_P2

3

1

J1

2

3

1

J2

GND

GND

1 2

1 2 1 2

1 2PI01 PI02

COPI01 PI02PI01 PI02

PI01 PI02

PIC101

PIC102COC1

PIC201

PIC202COC2

PIC301

PIC302COC3

PIC501

PIC502COC5

PIC601

PIC602COC6

PIC701

PIC702COC7

PIC801

PIC802COC8

PIC901

PIC902COC9

PIC1001

PIC1002COC10

PIC1101 PIC1102

COC11

PIC1201 PIC1202

COC12

PIJ101

PIJ102

PIJ103

COJ1

PIJ201

PIJ202

PIJ203

COJ2

PIJP101 PIJP102

PIJP103 PIJP104

PIJP105 PIJP106

COJP1

PIJP201

PIJP202

PIJP203

PIJP204

COJP2

PIR101

PIR102COR1

PIR201

PIR202COR2

PIR301

PIR302COR3

PIR401

PIR402COR4

PIR501 PIR502COR5

PIU100

PIU101

PIU102

PIU103

PIU104

PIU105

PIU106

PIU107

PIU108

PIU109

PIU1010

PIU1011

PIU1012

PIU1013

PIU1014

PIU1015

PIU1016

PIU1017

PIU1018

PIU1019

PIU1020

PIU1021

PIU1022

PIU1023

PIU1024

COU1

PIU201

PIU202PIU203

PIU204

PIU205

PIU206

PIU207

PIU208

COU2

PIX101 PIX102

COX1 PIX201

PIX202PIX203

PIX204

COX2

PIU1017

PIU203NLDE

PIC101 PIC201 PIC301

PIC501 PIC601

PIC701 PIC801

PIC901 PIC1001

PIC1102

PIC1202

PIJ101

PIJ203

PIJP104

PIJP204

PIR401

PIU100

PIU205

PIX202

PIX204PIC1002

PIU1011

PIX203

NLHFXTALN

PIC902

PIU1010

PIX201

NLHFXTALP

PIU101

PIU104

PIU201NLLEU0RX

PIR501

PIU1021

PIU204

NLLEU0TX

PIC802

PIU106

PIX102

NLLFXTALN

PIC702

PIU105

PIX101

NLLFXTALP

PIU207

NLmodbus0N

PIU206

NLmodbus0PPI01

PIR201

PIR302

PIR301

PIR402

PIR101

PIR102

PI02 PIJ201

PIJ202PIJ102

PIJ103

PIC1101PIU1016

PIJP105PIR502

PIU103 PIU108

PIU1023

PIU1024

PIU1018

PIU202NLRE

PIJP106

PIU107

NLRSTPIJP103

PIU1019

NLSWDCLKPIJP101

PIU1020

NLSWDIO

PIJP202

PIU1013

NLUS0RX

PIJP203

PIU1014

NLUS0TX

PIC102 PIC202 PIC302

PIC502 PIC602

PIC1201

PIJP102

PIJP201

PIR202

PIU102

PIU109

PIU1012

PIU1015

PIU1022

PIU208

Figure B.1: MODBus Interface schematic.

59

60 Appendix B

B.2 Modbus Interface PCB layout

Figure B.2: Top layer Modbus Interface PCB layout.

Figure B.3: Bottom layer Modbus Interface PCB layout.

APPENDIX C

Adapter PCB

C.1 Adapter schematic

Figure C.1: Adapter schematic.

61

62

C.2 Adapter PCB layout

Figure C.2: Top layer adapter PCB layout.

Figure C.3: Bottom layer adapter PCB layout.

REFERENCES

[1] M. Organization, “Modbus application protocol specification v1.1b3.” http://www.

modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf, 2012.

[2] H. I. Networks, “Modbus rtu slave interface.” http://www.anybus.com/products/

products.asp?PID=78&ProductType=Anybus-S.

[3] Advantech, “Adam-4572.” http://www2.advantech.eu/products/GF-5TZ5/

ADAM-4572/mod_1E01192D-95A1-42A4-B199-79343134F4CA.aspx.

[4] E. . E. E. GES.M.B.H. http://www.epluse.com/.

[5] E. . E. E. GES.M.B.H, “Low power oem humidity and temperature probe with

modbus interface.” http://www.epluse.com/fileadmin/data/product/ee071/

Datasheet_EE071.pdf.

[6] M. T. Inc., “Low-power design guide.” http://ww1.microchip.com/downloads/

en/AppNotes/01416a.pdf, 2011.

[7] S. L. Inc. http://www.silabs.com/pages/default.aspx.

[8] S. L. Inc, “Efm32zg108 datasheet, rev 1.10.” http://www.silabs.com/Support%

20Documents/TechnicalDocs/EFM32ZG108.pdf, 2015.

[9] M. Organization. http://www.modbus.org/.

[10] T. Instruments, “Interface circuits for tia/eia-rs485 (rs-485).” http://www.ti.com/

lit/an/slla036d/slla036d.pdf, 2008.

[11] C. Controls, “Understanding eia-485 networks.” http://www.ccontrols.com/pdf/

ExtV1N1.pdf, 1999.

[12] h. . M-Bus.

[13] P. . P. International. http://www.profibus.com/.

63

64

[14] T. Electronics, “Inductive filtering modular rj jacks.” http://datasheet.

octopart.com/6-6609208-0-Corcom-datasheet-501201.pdf.

[15] HRS, “Rj45 modular jack connectors with pulse transformers.” https://www.

hirose.co.jp/cataloge_hp/e22229322.pdf.

[16] D.-F. T. AB, “Engineering kit data sheet.” http://www.d-flow.se/sites/

default/files/media/engineering_kit_data_sheet.pdf, 2015.

[17] D.-F. T. AB, “Dn20 evaluation meter data sheet.” http://www.d-flow.se/sites/

default/files/media/dn20_evaluation_meter_data_sheet.pdf, 2015.

[18] D.-F. T. AB, “D-flow ufo2 asic brief data sheet.” http://www.d-flow.se/sites/

default/files/media/UFO2_ASIC_brief_data_sheet.pdf, 2015.

[19] M. Integrated. http://www.maximintegrated.com/en.html.

[20] M. Integrated, “Datasheet max3485.” http://www.intersil.com/content/dam/

Intersil/documents/isl3/isl32600e-01e-02e-03e.pdf.

[21] I. A. LLC. http://www.intersil.com/en.html.

[22] I. A. LLC, “Datasheet isl32603e.” http://www.intersil.com/content/dam/

Intersil/documents/isl3/isl32600e-01e-02e-03e.pdf, 2012.

[23] S. L. Inc, “User manual starter kit efm32zg-stk3200.” https://www.silabs.com/

Support%20Documents/TechnicalDocs/efm32zg-stk3200-ug.pdf, 2013.

[24] I. F. Products, “Datasheet 12smx 16mhz crystal.” https://www1.elfa.se/data1/

wwwroot/assets/datasheets/12smx_eng_tds.pdf, 2012.

[25] I. F. Products, “Datasheet qtc3 series tuning fork.” http://docs-europe.

electrocomponents.com/webdocs/12f2/0900766b812f2ae8.pdf.

[26] A. Limited. http://www.altium.com/altium-designer/overview.

[27] S. L. Inc. http://www.silabs.com/products/mcu/Pages/simplicity-studio.

aspx.

[28] R. Kwiecien, “Radzio! modbus master simulator,” http://en.radzio.dxp.pl.

[29] F. Corporation. http://www.fluke.com/fluke/sesv/digitala-multimetrar/

advanced-multimeters/fluke-289.htm?pid=56061.

[30] J. W. Eaton. http://www.gnu.org/software/octave/index.html.

[31] SAFT. http://www.saftbatteries.com/.

65

[32] SAFT, “Ls14500.” http://www.saftbatteries.com/force_download/LS14500.

pdf.

[33] SAFT, “Ls17500.” http://www.saftbatteries.com/force_download/LS17500_

EN_31029_2_0615.pdf.

[34] SAFT, “Ls26500.” www.saftbatteries.com/force_download/LS26500.pdf.

Date post:	20-Apr-2020
Category:	Documents
Upload:	others
View:	8 times
Download:	0 times