ENERGY METER READING PROTOCOL THROUGH OPTICAL PORT CALIBRATION PROTOCOL EMOP-VT11-VT11

Author: Narender Rao Saineni , Narender.saineni@gmail.com Revision: 1.0, Dated 15 July 2012

1 Introduction
These days in India several electric utility companies are procuring the single and 3 phase energy meters with meter reading facility from the optical port or a variation of the optical port like IRDA, CIR etc. However to read the measured parameters and the logged data like tamper log, load survey log from the meter no standard protocol has been specified by the Indians standardization body, hence every utility is specifying their own protocol. If utility does not specify the mfr implements his own protocol. in the case of meters shipped using vijethat technology and the customer does not specify the product , vijethat intends to implement the protocol as specified in this document. enough effort has been put to make this protocol server all the benefits normally expected from the protocol as listed in the above requirements of the protocol. Even when customer specifies his own protocol, we will implement the customer protocol for reading the meters, but in addition to the customer protocol we will implement the features of this protocol for identification purpose and the calibration purpose. going forward when we implement the RF communication in the meters, we need as protocol between the RF module and the energy chip, then also we will use this protocol.

2 Requirements of the Protocol

To design this protocol we have taken the following list of requirements. It should have protocol version identifier and allow future enhancements easily It should give full product identification wake up from sleep condition should be defined even if it can not be implemented now collision avoidance for global enquires should be there should detect errors in the packets and repeat attempt procedure should be defined It should be easy to implement Reader should be able to read the normally used basic data very fast It should be compatible to add the next communication module i.e LPRF ZIGBEE It should give self documentation to the extent feasible It should allow setting of some parameters as future enhancement It should allow authentication to field set TOD times etc as future enhancement Facility to Calibrate/Set with computer and test bench on the prodn floor. Voltages, Currents, KWhs, Lead/Lag factor, Time, Srno, Lock

3 Vijetha 1 Phase Energy Meter Protocol

In normal situation The reader first issues the whoareyou command to the meter. meter gives its full identity i.e the make,model,srno,protocol,s/w version,basicdata-size etc. The reader reads one block of basic data which is typically about 30 bytes with single read n registers query, the response takes about 30 msecs, reader issues session close command which takes about 10msec @ 9600 baudrate. the meter displays done on LCD and does not respond to the global queries for about 15 mins.

that is the end of the meter reading session

To read archive data like accumulated tampers & load survey if implemented The reader does not close the session after first read but issues more read commands that it is interested in and collects the data The data available with the meter is published by the meter in its directory register block, by reading this block the reader can collect all the data the meter has , even though the reader is not aware of the mapping of the extra data collected it can still collect it and upload it to BCS.

3.1 Reading Session Overview

A typical Meter Reading session in the field The meter reader ( MRI/CMRI/ISBM) can read the meter if the protocol is followed.The automatic product and protocol recognition helps in a common meter reader to used the appropriate protocol to read the meter and store its data This also helps the mfr in calibrating the device automatically as per the mfrg protocol mfr may be manufacturing the single phase /3 phase energy meters for different customers as per customer protocol, and also may be manufacturing the DIN industrial meters or any other data acquisition system. -------------------------Reading Session Overview -----------------------------------------Reader: Meter: Reader: Meter: Reader: Meter: Identify yourself global enquiry Identification Give Data, meter specific enquiry Data Close Session , meter specific OK

3.2 Protocol Details

3.2.1 Wakeup command

This is not really command because the meter is not expected to receive the full byte sequence sent, however meter is expected to get some interrupt and wake up from the sequence sent. This is not possible on all h/w versions, this is mainly to be used for future planning. Query: Resp: 0x00000000 wakes up but does not give any response

//implementation Normally the serial line is in mark condition (no optical signal through optical port), when we send 0 the signal switches from mark to space sufficient amount of time. We can make RXD going to zero for long using rc filter to generate an interrupt to the cpu to wake up instead of every RXD waking it up.

3.2.2 Help command

Query= help,sno cr lf // this is a very generic ascii query which should be supported by all devices, if help is followed by a number, only the addressed device should respond otherwise all who receive it should respond, lower 2 digit partial sno match supported Response= binary 000000 wakes up device, whoareyou gives MAKE,PRODUCTID,CUSTREF,SERIALNO,FWVERSION, RDGPROTOCOL,CONFIG-PROTOCOL for protocoldetails check http://sites.google.com/site/energymetersindia.com/protocol-vjt-sem01,lrs

3.2.3 Whoareyou command

Issuing this command is optional, this is not required to be issued in normal case where the meter type and protocol is known.

only in case the reader is handling many types of meters with different protocols issue of this command helps it determine how to read the meter based on response to this command Query= whoareyou crlf or whoareyou n,a,b,c,CS crlf n= whoareyou command version n for version 1 the parameters a,b,c mean a=respond in one of a time slots b=time slot period in milliseconds CS= checksum for the basic whoareyou command CS is not required for extended whoareyou with parameters CS is required ( we need to detect errors in the parameters, if whoareyou word itself is errored it will not get response) Respone= RFmt, MAKE, PRODCODE, CUSTREF, SNO, FWVER, RDGPROTO, CALPROTO, CS16 CRLF example response VT1, NPPL, EM1U-APCM-1, DGSD1207, 1..8, 10, EMOP-APCM11, EMOPITSN11 , CS crlf RFmt: Response Format 1, in future we may implement additional formats MAKE: Make is a four letter word which identifies the manufacturer PRODCODE: Product Code tells us what type of product is it, single phase/ 3phase meter , utility meter or DIN meter and the hardware features in it , wether it has super cap, optical port/irda port/CIR etc for example 1= 1 Phase meter U=Utility version M= Msp controller inside 2= 6+2 digit LCD, Optical Port peripherals, eeprom, RTC peripheral combination 0= PCB Logical Connections to the controller ( if this varies the s/w varies)

CUSTREF: Customer Reference is a string which tells if it is a specific customer tender model or our generic model etc, if it is customer model 4 letter customer name and YYMM will be part of this string, if the product is our generic product which is common to several customers then our generic string will be there like GNRL1207, which means our general model introduce in year 2012 month 7.

SNO: Serial Number is usually a numeric string giving the product serial number in this model FWVER: Firmware Version is the two letter word which tells us the feature set of the firmware in this model , first letter identifies the software feature set in this model second letter identifies the improved version/bug fixed version with the same customer feature set 10 1= Feature set defined in the PO 0= The First Release Version

RDGPROTO: Reading Protocol is a string which identifies the protocol used to read the device for example EMOP-APCM11 means this protocol is used in the context of Energy Meter Reading through Optical Port , Protocol is Andhra Pradesh Common Protocol 1 , Version 1 PROTOCOLCALIB: The protocol string which identifies the protocol used to calibrate the device for example EMOP-ITSN11 means Energy Meter Optical Port Protocol IT Age Solutions Calibration Procedure 1 , Version 1

whoareyou can be issued with multiple options R = whoareyou,2,4,100,cs crlf 2=respond in time slotted manner 4=4 slots 100= each slot 100 msecs each

3.2.4 Reading Data

Reading the meter is as per the modbus binary reading mode known as rtu mode, however there is a small change made to it , normally modbus-rtu uses crc16 as the checksum. but we are using 16 bit checksum ( ~cs16) , the computation of cs16 is very simple compare to the crc16, crc16 needs 512 byte page table to compute it in byte mode or bit mode convolution which takes time. however in meters having the capability to implement crc16 we provide the option of using such protocol when meter uses reading protocol vtmb1x i.e Vijetha Technologies modbus protocol version11 then it is ~cs16 when meter uses reading protocol vtmb2x , then we use crc16 as per modbus standard

as per modbus standard the device publishes some 16 bit registers having the readable data. we have to use modbus read registers command to read those registers. the registers can be read in any number and in any sequence. the read registers command format is

Query: devid 03 aaaa nnnn cs16 where devid is the one byte slave device id, here in the case of meter reader can use 0xff which means global address any meter , or if it wishes it can use lower 2 digits from the meter serial number as the bcd devid 03 = function code to read registers aaaa = 16 bit starting address of the register block nnnn = number of registers to read ,two bytes cs16 = our variant of ( in standard it is crc16) checksum example: ff0310000002xxxx // Hello anyone read 0x0002 regs from 0x1000

Response Packet Format is devid cmd n Data cs16 devid cmd n Data cs16 = = = = = slave device id same as in query no of data bytes ( n = 2 * n of query) data bytes HHLL HHLL 16 bit checksum // devid=0x01, cmd=0x03,n=0x04,data=01020304

example: 01030401020304xxxx

When you want to read the basic block of registers to be read and do not know exactly how many registers are there in the block ( this can be found in the register map) the nof regs to be read can be given as 0xff, then only the available no regs in the basic block are returned with appropriate parameter n ( the no of data bytes)

How to read data from different meters having different amount of data ? One feature of this protocol is that the reader can read the basic block of data having the important parameters like cuKWH,MD , cumultative TamperStatus, time stamp quickly in about less than 0.1 sec.

However if the customer wants to read more data , the extra data is avalibale in the additional parameters blocks they can be read by issuing another read command The reader can also read the archived data like load profile, last 6 months KWH,MD records by issuing read archive block command. However all of them can be read by using the same read registers command only. The registers block starting address will change as shown in the register map for the model of the meter. the maximum block size that can be read in one command is 252 bytes. modbus cmds supported 0x03 0x04 Read Registers Write Registers ( for TOD related parameters )

// manufacturer specific commands 0x60 0x61 0x62 0x70 0x71 0x72 0x7f Display a parameter on LCD Read a parameter using parameter ID Set the parameter/Calibrate ( discussed in calibration section) Flash area dump // for debug purpose RAM area dump // for debug purpose All records dump // for debug purpose Session Close

3.2.5 Register Map

The map of registers is defined in the excel file embedded here

3.2.6 Session close command

Query: devid closecmd nofmins cs16 Response: ACK // meter after sending ACK char displays done on lcd

after this does not respond to global address requests for nofmins however device specific query resets the timer.

3.3 Calibration Session

This session also has to be planned in such a way that we should be able to calibrate diffent types of meters , single phase, 3 phase, DIN meters, different customer specs, different communication ports including RF port. Calibration sequence should be planned to support both shared RS485, dedicated link RS232 , and RF media links. from whoareyou enquiry we get the protocol string as epdcl20-vt10 Ascii Query / commands Response Supported help Q R whoareyou Q R mset Q Query Response help Some text and a url Whoareyou,l,m,n,CS Make,product,model,. mset,mode,devid,CS mode=0x02=addressed mode devid=modbus devid OK Parameter Details

current practice of calibration on 3 posn bench with spdcl protocol for reference only $select bench-slot-all :calibrate time save :calibrate voltage save :calibrate current save // // // // cmd issued to the multiplexure all meters to take this time all meters to take this voltage all meters to take this ph-current

:calibrate power 0% correction wait for 5..10 pulses $select bench-slot-1 :calibrate power bencherror% $select bench-slot-2 :calibrate power bencherror% $select bench-slot-3 :calibrate power bencherror%

// all meters move to power calibration mode

$select bench slot 1 if bench error low , :calibrate power error0 save else :calibrate power bencherror% .. $select bench slot 3 if bench error low , :calibrate power error0 save else :calibrate power bencherror%

Calibration of meters with any read protocol and vt11 calibration protocol

$select bench slot 1 mset,01,01,cs16 crlf $select bench slot 2 mset,01,02,cs16 crlf $select bench slot 3 mset,01,03,cs16 crlf

//modeset to modbus-rtu-cs16 with devid=01 //modeset to modbus-rtu-cs16 with devid=02 //modeset to modbus-rtu-cs16 with devid=03

0xff calib RTC values save cs16 // all meters calibrate voltage& save 0xff calib voltage values save cs16 // all meters calibrate voltage& save 0xff calib current values save cs16 // all meters calibrate voltage& save

dev01 calib PhKwhError values nosave cs16 dev02 calib PhKwhError values nosave cs16 dev03 calib PhKwhError values nosave cs16 // we can also send multiple errors in single global pkt

wait for 10 pulses if bench error low for dev01 : dev01 calib PhKwhErroor 0 save cs16 else : dev01 calib PhKwhError bencherror% nosave cs16 .. for other slots timeout check read meter parameters and pass or fail

Calibration of the device starts with identification of the device , calibration protocol version, the appropriate calibration command sequences is followed as per the protocol. The calibration set up should be similar for utility meters, industrial DIN meters and other products calibrated using computer. at present when the computer issues a calibrate a parameter command using cmdcode 62, the meter displays the parameter and uses the calibration constant given by the computer, computer can ask it to save after reading the parameter so computer irrespective of the protocol needs to address the parameters specifically which parameter id is to be calibrated and read. If this addressing the parameter with parameter id is retained , then even if change the register map , the calibration procedure holds good. In future it is also possible to calibrate the meters using shared bus without multiplexure , by first issuing whoareyou command using timeslot respond method and assigning in the devid to the slotted meter. this will be developed if required in future.

3.4 Future Enhancements

How to use this protocol if meter uses RF Module.

RF module should have an application which reads the meter using this protocol and export the data to the head end / meter reader using the RF domain standards for example smart energy. The meter chip will have the firmware of this protocol. and the meter chip need not be aware whether communication module is Optical port , or RF communication port. All the code related to RF communication will be handled by the RF module app. However support of additional registers will be added based on the requirement. Only the register map need be known to the end user. (BCS)

4 References
4.1 Modbus and International Standard
What is Modbus protocol? Modbus Protocol is a messaging structure developed by Modicon in 1979. It is used to establish master-slave/client-server communication between intelligent devices. It is a de facto standard, truly open and the most widely used network protocol in the industrial manufacturing environment. It has been implemented by hundreds of vendors on thousands of different devices to transfer discrete/analog I/O and register data between control devices. It's a lingua franca or common denominator between different manufacturers. One report called it the "de facto standard in multi-vendor integration". Industry analysts have reported over 7 million Modbus nodes in North America and Europe alone. The RTU mode(binary mode frame) will be as follows

The ASCII mode ( 7 bit ascii +1 bit parity chars) frame will be as follows

4.2 DLMS and International Standard

Q: R: Q: R: /? DeviceAdress ! CR LF /XXXZ\;W;Identification CRLF ACK V Z Y CR LF STX DATABLOCK ! CR LF ETX BCC

4.3 Comparsion of Protocols

MODBUSASCII APCOMMON Modbus-rtu Vt11 Vt21

StartChar : : 3.5chargap 3.5chargap 3.5chargap

devid n devid devid devid

cmd cmd cmd cmd cmd

data data data data data

cs cs Crc16 Crc16 CS16

EndChars CRLF CRLF

How are we calibrating now ? at present the meters are at 2400 baud before locking, after locking they are at the customer specified baud rate at present the multiplexure selects the device based on the select command $0264 + deviceno + 00 + checksum + <CR><LF> multiplexure uses the deviceno from dip switch settings multiplexure connects only the selected device, other posns the meter is disconnected from the shared bus.

60 parid 61 parid 62 parid value_16 save

//display the parameter //read the parameter //set the parameter

Now Communication Protocol between the Bench Calibrator computer and multiplexer PCB Revision-1

Command to the multiplexer PCB to select the meter $ DataLen WriteCmd DevID 00 CS CRLF Example : $0264 0100xx <CR><LF> In the above line 02=datalen, 64=writecmd,01=mtrposn,00,xx=checksum

Subsequent to the meter selection The communication with the meter is transparent , i.e multiplexer does not interpret it

The job of the multiplexer: Keep looking for a line starting with $, if such a line is found Take the meter id field from it and select if it matches, deselect if it does not match the posn of the multiplexer ( set with dip switch)

Activity of the meter is selected The computer directly communicates with the selected meter using meter protocol. For example to set RTC time it issues the following command :0651 + date + month + year + hr + min + secs + checksum + <CR><LF>

The lines starting with : are as per the meter protocol, the meter response directly reaches the computer.

Revision 2

Additional feature added to select all meters at the same time for same time calibration of voltage,current, power etc to the extend possible.

Commands to the multiplexer

$, LEN, CMD, PAR1, PAR2, CHECKSUM, CRLF

CMDLIST 64= SELECT A METER PARAMETER1=>FF=ALL, FE=NONE, 00-7F= DEVID,80-FD=UNUSED So there is only one command defined so far in for this multiplexer.