RX / TX Data - ARDUINO + PROTOCOL

I need to receive data through the arduino rx / tx serial port with the 9600 bus, which receives this information and stores it in an array or vector so that I can treat the data according to the protocol below, forgetting that it has special characters in it. start and end to inform you that you have started and completed the package:

FOR SERIAL TRANSMISSION CHARACTERS 01H, 04H, 10H, 11H AND 13H CONTAINED IN THE DATA ARE CONVERTED TO CHARACTER 10H FOLLOWING THE FORBIDDEN CHARACTER AT 8 PM, BEEN CALCULATED CHECKSUM; SO, THE CHECKSUM MUST BE CHECKED IN THE DESTINATION BEFORE THEY CONVERT THEM AGAIN IN THE REAL VALUES;

EXAMPLE (HEXADECIMAL LITERALS):
01 08 1F 0D 0B 08 02 10 21 06 30 00 00 86 20 FF 24 BE 2A 3D 10 24 00 00 00 00 00 20 FF FF 10 21 00 34 37 34 4F 10 21 40 04

0x01H - START FRAME
0x08H - MESSAGE INDICATOR ORIGINATED IN MTC-400
0x1FH - PARAMETER ADJUSTMENT TYPE ALERT
0x0DH - GMT TIME
....
.....
......
0x40H - CHECKSUM UNDERSTANDING SUM IN A VARIABLE BYTE TYPE OF ALL VALUES FROM 0x08H TO THE CHARACTER BEFORE CHECKSUM
0x04H - END OF FRAME

The serial input basics tutorial has information on reading serial data, that has start and end markers, into a null terminated character array.

So what is the problem?

Where IS your code that receives that stuff?

ChelltonAlmeida:
I need to receive data through the arduino rx / tx serial port with the 9600 bus, which receives this information and stores it in an array or vector so that I can treat the data according to the protocol below, forgetting that it has special characters in it. start and end to inform you that you have started and completed the package:

EXAMPLE (HEXADECIMAL LITERALS):
01 08 1F 0D 0B 08 02 10 21 06 30 00 00 86 20 FF 24 BE 2A 3D 10 24 00 00 00 00 00 20 FF FF 10 21 00 34 37 34 4F 10 21 40 04

0x01H - START FRAME
0x08H - MESSAGE INDICATOR ORIGINATED IN MTC-400
0x1FH - PARAMETER ADJUSTMENT TYPE ALERT
0x0DH - GMT TIME
....
.....
......
0x40H - CHECKSUM UNDERSTANDING SUM IN A VARIABLE BYTE TYPE OF ALL VALUES FROM 0x08H TO THE CHARACTER BEFORE CHECKSUM
0x04H - END OF FRAME

couple of of questions:

  1. frame length: it is fixed? if no, is there a byte within the frame that indicates the frame size?

  2. Start and End of Frame (0x01, 0x04): are they SOLELY used for just that ie these values are never present within the frame?

sherzaad:
2. Start and End of Frame (0x01, 0x04): are they SOLELY used for just that ie these values are never present within the frame?

looks like byte stuffing is being used, i.e.
FOR SERIAL TRANSMISSION CHARACTERS 01H, 04H, 10H, 11H AND 13H CONTAINED IN THE DATA ARE CONVERTED TO CHARACTER 10H FOLLOWING THE FORBIDDEN CHARACTER

Introduction

For serial or GPRS transmission, the characters 01h, 04h, 10h, 11h and 13h contained in the data are converted to the 10h character followed by the forbidden character added to 20h, after which the checksum is calculated;

Conversion of special characters also applies to checksum; the command structure for serial or GPRS sending via tcp / ip protocol always follows the following format:

image;

0x01h - Frame start
0x00h - Reserved
0xyyyyh - Word (16 bits) with key for ack of the command in case of
transmission by GPRS. Each new command sent to the equipment or retenta-
must have a different key than the previous command or attempt. Otherwise, the
The machine will not execute the command and disconnect itself, then initiate a
new GPRS connection. For serially sent commands there is no need to
key variation for confirmation, which should be 0x0000h.
0xyyh - byte (8 bits) identifier of the command type.
0xyyyyyyyyyyh - Equipment ID (ASCII) - unique id of the ascii equipment (5
bytes). For the command to be sent, it needs to be in hexadecimal,
this conversion only the last 5 numbers of the equipment ID are used.
Example:
Equipment ID: 530954
Five last numbers: 30954 the numbers are converted according to the table
ASCII.
30954 in hexadecimal: 3330393534
Command: 0x3330393534h
0xYYH - command parameter, if any, of variable size.
0xyyh - byte-type checksum, comprising the least significant byte of the sum of
all characters from the character after the beginning of the frame, to the character
previous to the checksum.
0x04h - End of frame.

as @PaulS asked in post #2 what is the problem?