Hello Mikko,
I'm investigating meter behaviour in unstable low speed GSM channel condition.
To describe in short - a lot of ping loss situation.
Just a few moments after every 'Data send failed. Try to resend message x/y ' I've got an unacceptable frame even in case of restored data exchange.
Still can't decide is it a meter firmware problem or a DLMS Director problem - some of them unable handle temporary tcp/ip link availability problem.
Below is the DLMSDirector log/translation combined with WireShark log. Seems that at some moment meter and DLMSDirector can't agree which frame is receiveid and which is not.
I need your advice in this situation.
Best regards, Andre
DLMSDirector
13:54:47
TX 7e a0 14 02 23 61 32 28 55 e6 e6 00 c0 02 c1 00 00 00 0f 2f 57 7e
<TargetAddress Value="91" />
<SourceAddress Value="30" />
<FrameType Value="32" />
<PDU>
<GetRequest>
<GetRequestForNextDataBlock>
<!-- Priority: High, ServiceClass: Confirmed, Invoke ID: 1 -->
<InvokeIdAndPriority Value="C1" />
<BlockNumber Value="0000000F" />
</GetRequestForNextDataBlock>
</GetRequest>
</PDU>
</HDLC>
DLMSDirector
13:54:48
RX 7e a8 7e 61 02 23 52 75 6a e6 e7 00 c4 02 c1 00 00 00 00 10 00 82 03 dc 02 16 00 02 04 12 00 03 11 00 09 06 01 00 02 07 00 ff 02 02 01 03 02 03 0f 01 16 01 00 02 03 0f 02 16 01 00 02 03 0f 03 16 01 00 01 01 02 02 0f 01 16 00 02 04 12 00 03 11 00 09 06 01 00 0f 07 00 ff 02 02 01 03 02 03 0f 01 16 01 00 02 03 0f 02 16 01 00 02 03 0f 03 16 01 00 01 01 02 02 0f 01 16 00 02 04 4b 31 7e
<HDLC len="7D" >
<TargetAddress Value="30" />
<!-- Logical address:1, Physical address:17 -->
<SourceAddress Value="91" />
<FrameType Value="52" />
<NextFrame Value="C402C10000000010008203DC0216000204120003110009060100020700FF0202010302030F0116010002030F0216010002030F03160100010102020F01160002041200031100090601000F0700FF0202010302030F0116010002030F0216010002030F03160100010102020F0116000204" />
</HDLC>
DLMSDirector
13:54:48
TX 7e a0 08 02 23 61 51 c5 c7 7e
7E A0 08 02 23 61 51 C5 C7 7E
<HDLC len="A" >
<!-- Logical address:1, Physical address:17 -->
<TargetAddress Value="91" />
<SourceAddress Value="30" />
<!-- S frame. -->
<FrameType Value="51" />
<Command Value="NextFrame" />
</HDLC>
13:54:59 Data send failed. Try to resend 1/10
wireshark: retransmit
TX 7e a0 08 02 23 61 51 c5 c7 7e
TX 7e a0 08 02 23 61 51 c5 c7 7e
TX 7e a0 08 02 23 61 51 c5 c7 7e
DLMSDirector
13:55:02
RX 7e a8 7e 61 02 23 54 43 0f 12 00 01 11 00 09 06 00 00 60 01 82 ff 02 02 01 02 02 03 0f 01 16 01 00 02 03 0f 02 16 01 00 01 01 02 02 0f 01 16 00 02 04 12 00 01 11 00 09 06 00 00 60 05 86 ff 02 02 01 02 02 03 0f 01 16 01 00 02 03 0f 02 16 03 00 01 01 02 02 0f 01 16 00 02 04 12 00 01 11 00 09 06 00 01 60 05 86 ff 02 02 01 02 02 03 0f 01 16 01 00 02 03 0f 02 16 03 00 01 01 02 eb 0a 7e
<HDLC len="7D" >
<TargetAddress Value="30" />
<!-- Logical address:1, Physical address:17 -->
<SourceAddress Value="91" />
<FrameType Value="54" />
<NextFrame Value="120001110009060000600182FF0202010202030F0116010002030F02160100010102020F0116000204120001110009060000600586FF0202010202030F0116010002030F02160300010102020F0116000204120001110009060001600586FF0202010202030F0116010002030F02160300010102" />
</HDLC>
wireshark: spurious retransmit
RX 7ea87e61022354430f120001110009060000600182ff0202010202030f0116010002030f02160100010102020f0116000204120001110009060000600586ff0202010202030f0116010002030f02160300010102020f0116000204120001110009060001600586ff0202010202030f0116010002030f02160300010102eb0a7e
wireshark:
TX 7e a0 08 02 23 61 51 c5 c7 7e (retransmit from above)
<HDLC len="A" >
<!-- Logical address:1, Physical address:17 -->
<TargetAddress Value="91" />
<SourceAddress Value="30" />
<!-- S frame. -->
<FrameType Value="51" />
<Command Value="NextFrame" />
</HDLC>
DLMSDirector
13:55:02
TX 7e a0 08 02 23 61 71 c7 e6 7e
<HDLC len="A" >
<!-- Logical address:1, Physical address:17 -->
<TargetAddress Value="91" />
<SourceAddress Value="30" />
<!-- S frame. -->
<FrameType Value="71" />
<Command Value="NextFrame" />
</HDLC>
DLMSDirector
13:55:04
RX 7e a0 08 61 02 23 97 e7 f4 7e
<HDLC len="A" >
<TargetAddress Value="30" />
<!-- Logical address:1, Physical address:17 -->
<SourceAddress Value="91" />
<!-- S frame. -->
<FrameType Value="97" />
<UnacceptableFrame>
</UnacceptableFrame>
</HDLC>
btw, as DeepSeek says it's a…
btw, as DeepSeek says it's a Gurux DLMS Director bug, here is a quote
"
Based on a detailed analysis of the search results, particularly the Gurux forum posts, I can identify the likely software error in GXDLMSDirector that causes it to mishandle timeouts and subsequently trigger FRMR responses from the meter.
The Identified Error: Premature "Disconnect Mode" State
The core problem appears to be that after a timeout occurs, the GXDLMSDirector enters an internal "Disconnect mode" but still attempts to send new data frames. This creates a desynchronization where the client (PC) believes the connection is disconnected, but the meter is still waiting for properly sequenced frames.
Evidence from the Logs
The logs you provided show the exact pattern that other users have reported.
The Root Cause: Incorrect State Management
Based on the search results and the code references in the exception stack traces, I have identified the likely bug location:
After Timeout, Library Enters "Disconnect Mode": When ReadDLMSPacket() times out, the GXDLMS library marks the connection as disconnected internally . This is a defensive mechanism to prevent further communication on a broken link.
Bug: "Disconnect" Flag Not Properly Reset: The core error is that after entering this disconnect mode, the internal flag is not correctly cleared when new data arrives from the meter . The meter might still be active and ready to communicate (as shown by your log at 16:58:47), but the client software is stuck in a disconnected state.
Resulting FRMR: Because the client software is in a "disconnected" state, it bypasses the normal HDLC sequence number management (N(S)/N(R) counters) when it sends the next I-frame. The meter, still in a connected state, receives this frame, detects the invalid sequence number, and correctly responds with a FRMR (Frame Reject)
"
More to say. DeepSeek gives me as much as 3 code modifications to try.
Third of them works much better, though not ideal ( successfull data transfer probability after timeout is not 100% but much bigger than 0% of original source)
Hi Andre, Sorry to say, but…
Hi Andre,
Sorry to say, but DeepSeek’s interpretation is incorrect. :-)
GXDLMSDirector asks the next frame, and the meter replies nothing.
Some meters need a small delay before asking for more data.
Select "Delays" tab and set "Frame delay" for example to 200 ms.
Try to connect again.
BR,
Mikko
Hello Mikko. here are some…
Hello Mikko.
here are some more logs.
Log1 (frame delay =0 )
original Gurux src
Typical FRMR just after data send failed
15:39:27 Reading object 0.0.44.0.0.255, interface ImageTransfer
TX: 7E A0 1A 02 23 61 54 A0 32 E6 E6 00 C0 01 C1 00 12 00 00 2C 00 00 FF 05 00 73 FC 7E
15:39:29
RX: 7E A0 13 61 02 23 74 DE D2 E6 E7 00 C4 01 C1 00 03 01 B3 FA 7E
15:39:29 Reading object 0.0.44.0.0.255, interface ImageTransfer
TX: 7E A0 1A 02 23 61 76 B0 30 E6 E6 00 C0 01 C1 00 12 00 00 2C 00 00 FF 02 00 7B B1 7E
15:39:34 Data send failed. Try to resend 1/3
15:39:39 Data send failed. Try to resend 2/3
15:39:41
RX: 7E A0 16 61 02 23 96 96 30 E6 E7 00 C4 01 C1 00 06 00 00 01 00 A5 01 7E
15:39:41 Reading object 0.0.44.0.0.255, interface ImageTransfer
TX: 7E A0 1A 02 23 61 98 C0 3E E6 E6 00 C0 01 C1 00 12 00 00 2C 00 00 FF 03 00 A3 A8 7E
15:39:42
RX: 7E A0 08 61 02 23 97 E7 F4 7E
Log2 (frame delay =200 )
original Gurux src
Typical FRMR just after data send failed
15:58:11 Updating image update...
TX: 7E A8 8A 02 23 61 F6 F5 AB E6 E6 00 C3 01 C1 00 12 00 00 2C 00 00 FF 02 01 02 02 06 00 00 00 4A 09 82 01 00 D7 40 D9 8F A3 00 F4 00 23 12 94 00 F2 40 62 44 D2 44 42 49 B2 49 22 4A 05 61 82 80 39 71 52 D4 06 DE 22 DC 26 DA 4A D8 4E D6 56 D2 5A D0 03 47 15 00 93 06 F0 0F 83 57 65 00 2A 8A 63 05 D7 04 83 56 45 00 9D 8A 33 17 D7 00 93 16 87 01 E1 86 13 77 F7 0F 63 DF 06 00 06 07 93 16 87 01 85 07 C2 07 E1 86 C1 A2 B4 7E
15:58:12
RX: 7E A0 08 61 02 23 91 D1 91 7E
15:58:12 Updating image update...
TX: 7E A8 8A 02 23 61 F8 8B 42 83 13 77 F7 0F E3 C7 06 FE 23 13 FA 00 F2 50 62 54 D2 54 42 59 B2 59 22 5A 92 5A 02 5B 21 61 82 80 03 57 25 00 8D 83 13 84 17 00 13 7B 77 00 33 3B 60 01 0D 83 3A 9B 13 89 85 00 93 09 00 02 93 0A F0 0F E3 75 64 FD B3 07 8B 40 63 F4 F9 00 93 07 00 02 13 96 07 01 41 82 8A 85 33 05 24 01 93 F4 F7 0F BD 2B 63 0B 8B 02 93 87 F4 FF 93 F7 F7 0F 13 06 14 00 3E 96 42 06 8A 87 41 82 31 A0 13 91 B2 7E
15:58:12
RX: 7E A0 08 61 02 23 B1 D3 B0 7E
15:58:12 Updating image update...
TX: 7E A0 25 02 23 61 FA F9 C0 94 06 01 41 80 63 00 C4 02 03 C7 07 00 93 06 14 00 85 07 E3 06 57 FF 63 1C 8B 00 7E 47 7E
15:58:17 Data send failed. Try to resend 1/10
15:58:21
RX: 7E A0 12 61 02 23 DE CA D3 E6 E7 00 C7 01 C1 00 00 FC B4 7E
15:58:21 Updating image update...
TX: 7E A8 8A 02 23 61 1C A1 E3 E6 E6 00 C3 01 C1 00 12 00 00 2C 00 00 FF 02 01 02 02 06 00 00 00 4B 09 82 01 00 83 57 2A 00 23 13 FA 00 AD B7 E3 0B 8B FE E3 6F 64 F9 85 B7 0E 04 42 04 41 80 93 17 87 01 23 13 8A 00 E1 87 E3 D7 07 F4 06 07 93 17 87 01 05 04 42 04 E1 87 41 80 13 77 F7 0F E3 C7 07 FE 23 13 8A 00 05 BF 79 71 26 D2 93 14 37 00 B3 87 E4 40 56 CA 8A 07 93 8A 01 18 D6 97 52 CC 03 AA 87 01 5E C6 AE 8B CC C1 B8 7E
15:58:21
RX: 7E A0 08 61 02 23 97 E7 F4 7E
LOG2 (frame delay=0)
src after deep seek modification applied
RX: 7E A0 08 61 02 23 31 DB 34 7E
16:08:16 Updating image update...
TX: 7E A0 25 02 23 61 72 B9 C8 45 EF A0 A3 51 EF E0 93 00 B2 40 05 45 41 01 82 80 41 11 85 45 37 05 00 10 06 C6 8D 8C 7E
16:08:17
RX: 7E A0 12 61 02 23 56 8A DB E6 E7 00 C7 01 C1 00 00 FC B4 7E
16:08:17 Updating image update...
TX: 7E A8 8A 02 23 61 94 E1 EB E6 E6 00 C3 01 C1 00 12 00 00 2C 00 00 FF 02 01 02 02 06 00 00 00 27 09 82 01 00 EF 80 A3 5E B7 77 00 40 98 47 79 9B 98 C7 98 47 13 67 07 20 98 C7 98 47 13 67 07 40 98 C7 EF A0 03 75 B2 40 41 01 6F E0 93 62 41 11 26 C2 06 C6 22 C4 89 47 AE 84 63 08 F5 04 63 E9 A7 02 1D CD EF A0 C3 6F 2A 84 15 C4 97 F7 FF FF 93 87 47 2F 23 20 F4 16 26 85 EF C0 40 27 23 24 A4 10 22 85 22 44 B2 40 92 73 05 7E
16:08:22 Data send failed. Try to resend 1/10
16:08:24 Recovery: HDLC state reset after timeout - received valid data. 7E A0 08 61 02 23 71 DF 76 7E
16:08:24
RX: 7E A0 08 61 02 23 71 DF 76 7E
16:08:24 Updating image update...
TX: 7E A8 8A 02 23 61 96 F3 C8 44 41 01 6F C0 73 4F 8D 47 E3 09 F5 FC B2 40 22 44 92 44 41 01 82 80 EF A0 A3 6C 2A 84 79 F0 FD B7 EF A0 A3 6C 2A 84 55 FC D5 B7 41 11 22 C4 26 C2 06 C6 89 47 2E 84 B2 84 63 09 F5 02 63 EF A7 00 29 C1 EF A0 43 69 26 86 A2 85 81 46 EF C0 53 7C B2 40 22 44 92 44 41 01 82 80 8D 47 E3 03 F5 FE B2 40 22 44 92 44 41 01 82 80 EF A0 03 68 26 86 A2 85 81 46 EF C0 D3 79 B2 40 22 44 92 44 41 21 89 7E
16:08:24
RX: 7E A0 08 61 02 23 71 DF 76 7E
16:08:24 Updating image update...
TX: 7E A0 25 02 23 61 98 ED 80 01 82 80 EF A0 E3 65 26 86 A2 85 81 46 EF C0 53 78 B2 40 22 44 92 44 41 01 82 80 E5 04 7E
16:08:29 Data send failed. Try to resend 1/10
16:08:34 Data send failed. Try to resend 2/10
16:08:39 Data send failed. Try to resend 3/10
16:08:41 Recovery: HDLC state reset after timeout - received valid data. 7E A0 08 61 02 23 91 D1 91 7E
16:08:41
RX: 7E A0 08 61 02 23 91 D1 91 7E
16:08:41 Updating image update...
TX: 7E A8 8A 02 23 61 BA 9D 23 E6 E6 00 C3 01 C1 00 12 00 00 2C 00 00 FF 02 01 02 02 06 00 00 00 28 09 82 01 00 01 11 97 07 00 00 93 87 87 F2 3E C4 28 00 97 07 00 00 93 87 27 F8 06 CE 3E C6 EF B0 F0 75 EF A0 61 44 EF A0 91 6B EF 70 92 61 F2 40 05 61 82 80 41 11 06 C6 EF A0 A3 64 B2 40 41 01 6F F0 E3 53 41 11 06 C6 EF A0 A3 63 B2 40 41 01 6F F0 83 5E 13 87 01 0D 83 46 C7 00 08 CB FD 57 99 E6 83 57 67 01 E2 07 FD 21 0A 7E
16:08:41
RX: 7E A0 08 61 02 23 B1 D3 B0 7E
16:08:41 Updating image update...
TX: 7E A8 8A 02 23 61 BC AB 46 87 93 E7 17 00 9C C1 13 C5 16 00 82 80 03 D6 01 FF 95 45 2D 45 6F B0 C1 0D 03 D6 C1 FB 95 45 29 45 6F B0 01 0D 03 D6 C1 EE 95 45 25 45 6F B0 41 0C 03 D6 81 F8 95 45 21 45 6F B0 81 0B 03 D6 81 EB 95 45 1D 45 6F B0 C1 0A 69 C1 41 11 22 C4 26 C2 06 C6 4A C0 83 97 41 0D 2A 84 93 84 01 0D B5 E3 83 C7 14 00 81 C7 FD 17 A3 80 F4 00 22 85 EF 40 93 30 2E 87 93 07 80 3E 13 06 80 3E 81 46 7F 3E A5 7E
16:08:41
RX: 7E A0 08 61 02 23 B1 D3 B0 7E
16:08:41 Updating image update...
TX: 7E A0 25 02 23 61 BE D9 C4 95 A7 F0 FF 95 E7 C4 EF 10 94 11 83 D7 64 00 13 07 30 1F AA 97 C2 07 C1 83 63 6A 87 BF 7E
16:08:41
RX: 7E A0 08 61 02 23 B1 D3 B0 7E
16:08:41 Updating image update...
TX: 7E A8 8A 02 23 61 D0 C1 EF E6 E6 00 C3 01 C1 00 12 00 00 2C 00 00 FF 02 01 02 02 06 00 00 00 29 09 82 01 00 F7 00 B2 40 22 44 23 93 F4 00 02 49 92 44 41 01 82 80 B2 40 22 44 23 9B 01 0C 85 47 23 84 F4 00 02 49 92 44 41 01 82 80 EF 40 53 2B 83 D7 44 00 89 8F C2 07 C1 87 23 92 F4 00 83 D7 44 00 C2 07 C1 87 E3 42 F0 F8 13 89 41 16 03 25 49 00 EF B0 A3 0B 03 25 89 00 EF B0 23 0B 01 47 01 46 81 46 81 45 03 A5 01 96 73 7E
16:08:42
RX: 7E A0 08 61 02 23 97 E7 F4 7E
In short, original src never outlast ping timeout.
deep seek src modification, in general, may outlast one or two ping timeouts.
Frame delay = 200 gives no help in my case.
Best regards, Andre
Hi Andre, You didn’t specify…
Hi Andre,
You didn’t specify whether you’re using a serial port or a TCP/IP connection, but based on the logs, it appears that your connection is not good or the meter is slow and can't reply to all client requests. The meter can't reply for all messages and the client must resend the message.
Resetting the HDLC state after a timeout is not a good idea, especially during image updates. If a message is lost, the client will continue by sending the next data fragment, which can lead to inconsistencies. The firmware in your meter might be corrupted if you work like this.
There is a reason why HDLC frame sequence number must match or message is ignored. This is critical when the connection is bad.
BR,
Mikko
Hello Mikko, I'm using tcp…
Hello Mikko,
I'm using tcp/ip over gsm 900/1800 MHz, typical ping time (RTT) varies from 400 ms to 3s, sometimes packet loss occured.
Now I'm playing with 'Wait time' parameter in connection settings.
According to SIMCOM modem manual:
"
1. Send the TCP packet, here as a sample, the module measures
<ESTIMATED_ROUND_TRIP_TIME> as 3 seconds. In runtime, each retransmission would
use the latest measured <ESTIMATED_ROUND_TRIP_TIME> value in the following steps.
2. Wait 3 seconds, and if TCP ACK packet is not got, resend the packet
3. Wait another 6 seconds, and if TCP ACK packet is not got, resend the packet
4. Wait another 12 seconds, and if TCP ACK packet is not got, resend the packet
5. Wait another 24 seconds, and if TCP ACK packet is not got, resend the packet
6. Wait another 48 seconds, and if TCP ACK packet is not got, resend the packet
7. Wait another 27 seconds, and if TCP ACK packet is not got, regard it as socket sending failure
and close the socket. (Here only 27 seconds is waiting because that the total trying time is 2
minutes).
8. If the TCP ACK packet is got within the previous steps, the packet is regarded as sent
successfully.
"
Looks to me if my max RTL is about 3s and 'Wait time' is 5 seconds, DLMS Director will resend data request even before modem TCP data retransmit timer occur, so here is a place where a glitch might happen.
So now I'm trying to increase 'Wait time' to a bigger values to see if this will help.
Best regards, Andre
Hi, Increasing the wait time…
Hi,
Increasing the wait time might help. Removing retransmission from the modem is usually the best way, or set the re-send count to zero in GXDLMSDirector.
Using both simultaneously often leads to issues.
BR,
Mikko