Modbus Interface Extension of D-flows Engineering Kit
Angelica Brusell 2015
Master of Science in Engineering Technology Engineering Physics and Electrical Engineering
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
Modbus interface extension of D-Flow’s Engineering kit
S. Angelica Brusell
Lule˚ a University of Technology
Department of Computer Science, Electrical and Space Engineering
9th September 2015
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
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 J¨orgen 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 Lule˚a University of Technology, Per Lindgren, and Andreas Lindner for the help with feedback, discussion and the final report.
Angelica Brusell
v
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.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.5.2 Modbus communication . . . 32
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.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
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
1.2 Purpose
The 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 Limitations
The 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 research
Since 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].
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 approach
The 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.
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 systems
An 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
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.
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 Modbus
Modbus 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.
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 Rate 9600 (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-Only This 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-Only This 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.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 code sub
code hex
Data Access
Bit Access
Physical Discrete
Inputs Read 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
Registers Read 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 access Read 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
Other Encapsulated Interface
Transport 43 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.
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
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
A 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.
Modbus MASTER
Modbus Interface
D-Flow
Engi. kit Modbus Interface
D-Flow Engi. kit
Modbus Interface
D-Flow Engi. 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
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.
3.1.1 Microprocessor
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
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
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.
3.2.2 Microprocessor
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.
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
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.
(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
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.
(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.
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
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.
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.
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 communication
The 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.
GPIO_IRQ LEUART
GPIO LEUART
GPIO LEUART
Wait for interrupt
GPIO_IRQ USART
GPIO USART GPIO USART
IF USART_GPIO
IF LEUART_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
IF Exception
Send Modbus reply Send exception
reply
GPIO LEUART
EM2
True
False
Fals e
True
Fals e True
EM0
Figure 4.3: Serial communication code flowchart.
4.5.2 Modbus communication
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.
GPIO_IRQ LEUART
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 exception response
False
False True
True
True False
False
EM2
EM0
Figure 4.4: Modbus execution code flowchart.
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
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
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.
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
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.
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
A 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.
5.2.1 Modbus communication
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
(a) Table of power consumption for four differ- ent high frequency clock speeds.
(b) Plot of power consumption for four different high frequency clock speeds.
Figure 5.8: Power consumption measurement data running at full operations with differ- 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
(a) Table of power consumption for four differ- ent requested amounts of registers.
(b) Plot of power consumption for four different requested amounts of data registers.
Figure 5.9: Power consumption measurement data running at full operations with differ- 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 years Available charge [Ah] 2.3514 3.2558 6.9637 Available current [µA] 26.842 37.166 79.495 15 years Available 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.
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 Hardware
Since 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 Software
The 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
Figure 6.1: Modbus Interface mounted on D-Flow’s development board.
