HDLC protocol

Forum Rules

Before commenting read Forum rules

Don't comment the topic if you have a new question.

You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.

By iMeter, 2 March, 2020
Forums
General discussion

Hi.
Some questions on HDLC:
1. Has anyone encountered such an algorithm?
The flag sequence must never occur within the content of a frame otherwise it could be confused with an intentionally sent flag. A technique known as 0-bit insertion is used to prevent random data synthesizing a flag. The technique is said to make HDLC transparent, since any stream of bits may be present between the open and closing flag of a frame. The transparency is achieved by encoding the data by inserting a 0-bit after any sequence of 5 consecutive 1's within the payload.
2. Is this algorithm used in DLMS?
3. Does ESC (value ^ 0x20) apply inside the frame?
ESC, FLAG and ABORT (0x7d, 0x7e and 0x7f)
Thanks.

Kurumi

4 years 7 months ago

Hi,

I know this technique. It's not mentioned in Green Book and we haven't read any DLMS meter that is supporting it. We have read non-DLMS meters that are supporting it.

BR,
Mikko

iMeter

4 years 7 months ago

Based on 8.4.1.1 HDLC frame format type 3 (GB), it can be stated unequivocally that a byte with a value of 0x7E should not appear between flags.
I see two methods:
a) use algorithm zeroing the 6th bit of the frame between flags;
b) use PPP protocol algorithm ESC (value ^ 0x20).
Which option can support GXDLMSDirector application and is it worth it to go this way?
Kind Regards,
Albert

Kurumi

4 years 7 months ago

Hi Albert,

I'm using GB 9. Can you point me where you find that 0x7E should not appear between flags?
I can't find it.

At the moment we are reading meters where 0x7E is coming as part of CRC and sometimes as part of data. Those meters don't change it. 0x7E is coming as normal data.

BR,
Mikko

iMeter

4 years 7 months ago

Hi Mikko.
On the history of this issue.
The requirement for bits stuffing appeared in the Russian Standard CTO_34.01-5.1-006-2019 and did not receive an answer to the question -which source document? I started to search.
Sorry to disturb you, Mikko, you're right.
Here is the answer to my question.

62056-46 IEC:2002+A1:2006(E).
6.4.4.2.1 Transparency
Subclause 4.3 of ISO/IEC 13239 specifies multiple transparency mechanisms.
For the purpose of this protocol, the non-basic frame format transparency mechanism has been selected, as it is specified in 4.3.4 of that standard.
When using the non-basic frame format with the frame format field, the length sub-field obviates the need for the bit or octet insertion methods to achieve transparency. Consequently, no control octet transparency (octet insertion) is used in this MAC sub-layer operation.

ISO/IEC 13239:2002(E)
4.3.4 Non-basic frame format transparency
When using the non-basic frame format with the frame format field, the length subfield obviates the need for the bit or octet insertion methods to achieve transparency. This capability is selected by the use of Option 24 described in 6.15.24. The use of the frame format field may be established by a priori agreement or may be selected with the XID or set mode using a negotiation procedure specified in 7.

6.15.24 Option 24  no bit or octet insertion
This optional function indicates that the normal transparency mechanisms are inhibited. This option can only be used with Option 22, since the length subfield defined by Option 22 makes it possible to inhibit bit or octet insertion as a transparency mechanism.
Regards, Albert.

Kurumi

4 years 7 months ago

Hi Albert,

Thanks for this info. I was also checking this. There are so many standard documents and one sentence can change everything.

BR,
Mikko

ramusw427

9 months 2 weeks ago

Hi mikko,
I see that end of packet is searched in sample client application.(I saw in java example).
If end of packet is in the data itself,receive function is gxsynchronousmediabase class will return true at wrong index in data.

Am i correct?
Since length of frame is indicated in frame format field,can't it be used instead to determine the complete frame received or not? (assuming minimum 3 bytes are to be received for this checking)