How do I code, only using a protocol?

Question

1.00/5 (2 votes)

See more:

, +

I'm trying to write some minor code for requesting a response for a electric meter using an optical probe. The cable is still arriving, so while I'm waiting, I have to write the code for it, and I have no clue.

The protocol is ABNT NBR-14522 which is based on IEC-62056 and ANSI-C12.2.
I have the protocol here.

In the protocol there is a lot of Octets(octetos) which consists of 8 bits that the protocol asks for (a lot of them).
I'm currently accepting any ideas of how am I going to request a command so that the equipment can answer me with the string I need.

Thank you in advance, John.

What I have tried:

I have no clue. I've tried researching on the internet, and on this website.

Posted 13-Nov-17 2:31am

Tecnico guardiancar

Updated 13-Nov-17 8:51am

v4

Add a Solution

3 solutions

Solution 3

An octet is a byte:
Octet (computing) - Wikipedia[^]

Quote:
<enq> ::= 05 Hexadecimal
<ack> ::= 06 Hexadecimal
<nak> ::= 15 Hexadecimal
<wait> ::= 10 Hexadecimal

Those are standard ASCII codes, this notation is used because those are non printable.
Ascii Table - ASCII character codes and html, octal, hex and decimal chart conversion[^]

Posted 13-Nov-17 8:51am

Patrice T

Solution 1

You should work with buffers of 8 byte size. You can call it "octet".

C++

byte octet[8];// or char
strncpy( octet, "it works", 8);

Pay attentation that in a normal string the last element is the terminating zero, so you have 7 chars "payload". It also possible to use the 8th byte, when the code works without the terminator.

Posted 13-Nov-17 2:50am

KarstenK

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jochen Arndt · Accepted Answer · 2017-11-13T03:06:00

Solution 2

You should have a device driver for the communication. This should provide functions to setup the interface and read and write data (usually with a pointer for the data and a size parameter).

Quote:
In the protocol there is a lot of Octets(octetos) which consists of 8 bytes that the protocol asks for.

I guess that you misunderstand that and you have just bytes (8 bits).

If so, just declare a buffer of sufficient size (max. number of bytes per message) and fill that with the data according to the protocol (I don't know if the below applies to your protocol but a quick web research assumes it):

C++

unsigned char buf[MAX_MSG_SIZE];
buf[0] = 0x2f; // start
// set n data bytes here
// this might be for example a command send to the device
//memcpy(buf+1, data, n);
buf[n+1] = 0x21; // end
buf[n+2] = 0x0d; // CR
buf[n+3] = 0x0a; // LF
buf[n+4] = 0; // Optional when using string functions
// Driver specific send function
send_meter(buf, n+4);
//send_meter(buf, strlen(buf));

The above assumes that also binary data may be part of the message. If not, you might also use a char buffer and use strlen() to get the message length (when creating a NULL terminated buffer).

Similar for the receive function. With string data, that usually returns when a CR-LF terminated line has been received. Than just access the portion that contains the data payload.

BTW:
Are you allowed to make the document available on the net?
If not, please remove the link from your question.

Posted 13-Nov-17 3:06am

Jochen Arndt

Comments

Tecnico guardiancar 13-Nov-17 10:50am

I actually don't know, because I just googled NBR15422 and found it. But just to be safe I'll remove it.

You have to understand that I don't have that much knowledge on coding, I know Assembly, and a little bit of C (for mikroC).
One of the codes I have to send to the meter is detailed like this:

Octet 001: two digit number that specify what I am asking for the meter to send me(20/21/22/51)

Octet 002: Reader Serial Number MSB
Octet 003: Reader Serial Number
Octet 004: Reader Serial Number LSB
Octet 005: 00 for all Mass Memory
Octet 006: which Channels to pick (00=channels 1,2,3;01=channels 4,5,6...up to 32)
Octet 007: If 00, octet 005 is true.
Octet 008 to 010: NULL,
if 01 read amount of hours in the Memory Mass
Octet 005 must be read as a number of hours of registry to be provided
Octet 008 and 009 must be NULL
Octet 010 defines the mask of quantities to be read,
if 02 read amount of days of registry in the Memory Mass
Octets 008 and 009 must be read as a number of days of registry to be provided
Octet 010 defines the mask of quantities to be read,
if 03 read of the registry since last read of the Memory Mass.
Octet 010 defines the mask of quantities to be read
Octet 008: NN¹ number of civil days to the Memory Mass MSB.
Octet 009: nn¹ number of civil days to the Memory Mass LSB.
Octet 010: Mask of the Solicited Channels.
Bit 0: Solicited Quantities of the first channel of this group.
Bit 1: Solicited Quantities of the second channel of this group.
Bit 2: Solicited Quantities of the third channel of this group.
Octet 011 to 064: NULL
Octet 065: CRC LSB
Octet 066: CRC MSB
(Quantities are in W, kW, kVAr,...)
------------------

And I don't know how to code following these standards. (note that the code is going through
a Serial port RS-232, and to a optical infrared meter.)

And I have this too:

<enq> ::= 05 Hexadecimal
<ack> ::= 06 Hexadecimal
<nak> ::= 15 Hexadecimal
<wait> ::= 10 Hexadecimal
<byte> ::= 00 to FF Hexadecimal
<code.> ::= 01 to 99 BCD, except 05, 06, 10 and 15.
<crc> ::= CRC16 (X16 + X15 + X2 + 1)
<com> ::= 63 <byte>
<res> ::= 255 <byte>
<flag> ::= <enq> or <ack> or <nak> or <wait>
<command> ::= <code><com><crc>
<answer> ::= <code><res><crc>

Jochen Arndt 13-Nov-17 11:11am

An octet is a byte.
Because the above contains "00" you have binary data.
Then set the bytes as already explained.

Octet 002: Reader Serial Number MSB
Octet 003: Reader Serial Number
Octet 004: Reader Serial Number LSB

That implies that you have a 3 byte (24 bit) serial number. If that is stored in an 32-bit unsigned sn (or sn is just a constant value):
// Offset must be one less because C indexes start at 0
buf[0] = 0x20; // command byte
buf[1] = (unsigned char)((sn >> 16) & 0xff); // MSB
buf[2] = (unsigned char)((sn >> 8) & 0xff); // mid byte
buf[3] = (unsigned char)(sn && 0xff); // LSB

buf[offset] = 0x06; // ACK

It does not care which type of hardware interface is used. You just have to prepare / read the data and use the functions provided by the driver / SDK.

fernando barbosa 22-Jan-20 23:46pm

COULD HELP ME I HAVE A SIMILAR PROJECT