<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Why does sending SNRM frame 7E A0 0A... result in timeout with no response over optical probe?]]></title><description><![CDATA[<blockquote>
<p dir="auto"><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f6e1.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--shield" style="height:23px;width:auto;vertical-align:middle" title="🛡" alt="🛡" />️ <strong>Technical Redaction &amp; Safe Harbor Warning</strong>:<br />
Proprietary utility keys, serial numbers, and meter addresses have been neutralized. Frame traces use standard DLMS User Association public examples.</p>
</blockquote>
<p dir="auto">Hi everyone, testing a new optical probe with an electricity meter (IEC 62056-46 Clause 6.4) to read logical device name <code>0.0.42.0.0.255</code>.<br />
I connected the serial debugging tool and directly transmitted the following SNRM (Set Normal Response Mode) frame:</p>
<pre><code class="language-hex">7E A0 0A 00 02 00 23 21 93 18 71 7E
</code></pre>
<p dir="auto">The optical probe LED blinked once, but the meter returned absolutely nothing, causing a 5000ms timeout.<br />
Is there an error in this HDLC frame structure or did I miss something fundamental in physical layer setup?</p>
]]></description><link>https://dlms.sharur.org/topic/62/why-does-sending-snrm-frame-7e-a0-0a...-result-in-timeout-with-no-response-over-optical-probe</link><generator>RSS for Node</generator><lastBuildDate>Fri, 16 Oct 2026 19:14:34 GMT</lastBuildDate><atom:link href="https://dlms.sharur.org/topic/62.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 23 Aug 2026 03:50:56 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Why does sending SNRM frame 7E A0 0A... result in timeout with no response over optical probe? on Sun, 23 Aug 2026 03:51:09 GMT]]></title><description><![CDATA[<p dir="auto">Actually, changing the parity bit solved the entire problem!<br />
My serial port was set to <code>None</code> parity (8N1). Once I switched to <code>Even</code> parity (8E1), the meter immediately answered with the expected UA response:</p>
<pre><code class="language-hex">7E A0 1F 21 00 02 00 23 73 D5 F2 81 80 14 05 02 00 80 06 02 00 80 07 04 00 00 00 01 08 04 00 00 00 01 54 A7 7E
</code></pre>
<p dir="auto">Per IEC 62056-46 Clause 6.4, the UA frame contains the negotiated HDLC parameters. Thank you for the quick guidance! Marking this issue as resolved.</p>
]]></description><link>https://dlms.sharur.org/post/232</link><guid isPermaLink="true">https://dlms.sharur.org/post/232</guid><dc:creator><![CDATA[carlos_mendez]]></dc:creator><pubDate>Sun, 23 Aug 2026 03:51:09 GMT</pubDate></item><item><title><![CDATA[Reply to Why does sending SNRM frame 7E A0 0A... result in timeout with no response over optical probe? on Sun, 23 Aug 2026 03:50:59 GMT]]></title><description><![CDATA[<p dir="auto">Looking closely at this issue, this is a classic beginner trap where physical UART framing and server addressing are missing.</p>
<p dir="auto">Here is the step-by-step diagnostic tree per IEC 62056-46 Table 2:</p>
<ol>
<li>
<p dir="auto"><strong>Parity and Baudrate mismatch</strong>:<br />
Per IEC 62056-21 and IEC 62056-46, standard optical probe ports default to <strong><code>9600 bps, 8 Data Bits, Even Parity (8E1), 1 Stop Bit</code></strong> (or <code>300 7E1</code> initial optical wakeup). If your serial tool is configured with <code>8N1</code> (No Parity), the meter's hardware UART parity check will silently drop the incoming frame.</p>
</li>
<li>
<p dir="auto"><strong>Server Addressing (Logical &amp; Physical Device SAP)</strong>:<br />
In your frame <code>00 02 00 23</code>, the Server Address is <code>0x0023 = 35</code>. If the meter's physical address is different, the MAC layer filter will discard the packet.</p>
</li>
<li>
<p dir="auto"><strong>Check CRC FCS</strong>:<br />
The FCS bytes <code>18 71</code> correspond to CRC-CCITT (polynomial 0x8408). If baudrate is unstable, CRC calculation fails on meter MCU.</p>
</li>
</ol>
]]></description><link>https://dlms.sharur.org/post/231</link><guid isPermaLink="true">https://dlms.sharur.org/post/231</guid><dc:creator><![CDATA[elena_rostova]]></dc:creator><pubDate>Sun, 23 Aug 2026 03:50:59 GMT</pubDate></item></channel></rss>