<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I've modified one of the IDF examples to talk to our modem and do
regular restarts and found this:<br>
<br>
The test application shows no frame errors, regardless of the number
of resets if performs.<br>
<br>
But: if I first flash the OVMS, do a "module reset", then flash
& run the test application, all without power interruption, the
test application suddenly also shows the frame errors &
corrupted characters:<br>
<br>
<font face="monospace">I (13868) TX_TASK: Wrote 39 bytes<br>
W (13868) uart_events: uart frame error<br>
W (13868) uart_events: uart frame error<br>
W (13868) uart_events: uart frame error<br>
I (13868) uart_events: [UART DATA]: 3: «í<br>
</font><br>
I also found out it doesn't matter if I do the reset in software or
by pushing S1. The effect remains until the next cold boot.<br>
<br>
So it seems something we do (some hardware configuration) has a side
effect that persists over resets and begins interfering with the
UART after the first reset. I thought maybe we have some bug in our
UART driver setup, and fixed some issues I found, but that didn't
help. My next suspect was the SD card, but excluding that didn't
change anything.<br>
<br>
Espressif are aware of the UART not resetting properly, there are
multiple open issue tickets, but there has been no progress for
about two years on this.<br>
<br>
But the effect only showing after a full OVMS boot means there might
be a workaround. Attached is the test application, in case anyone
wants to experiment with this.<br>
<br>
Regards,<br>
Michael<br>
<br>
PS: as a side benefit from my investigation, I also found out how to
get the SIMCOM 7600 to only send NMEA sentences on one MUX channel
(→ commit 8f49ecab01617414c89b1e3ffa70c79e0115fe95).<br>
<br>
<br>
<div class="moz-cite-prefix">Am 09.09.22 um 21:00 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:df7a80b0-e1a6-d1ad-be02-0e0a0cda9992@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Regarding the UART frame errors:<br>
<ol>
<li>disabling GPS doesn't change anything</li>
<li>splitting the status poll into two queries doesn't change
anything</li>
<li>issuing a UART HW FIFO reset
(<a class="moz-txt-link-freetext"
href="https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580f2881a2a"
moz-do-not-send="true">https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580f2881a2a</a>)
doesn't change anything</li>
<li>explicitly setting the mode to standard UART doesn't change
anything<br>
</li>
<li>performing a deep sleep instead of a standard reboot doesn't
change anything</li>
<li>brute force writing a cycle of all 1's and all 0's twice to
the full UART1 register range before driver init doesn't
change anything<br>
</li>
</ol>
<br>
Apparently, the ESP32 UART has some kind of hardware flaw leading
to an ESP32 reset actually not doing a full UART reset.<br>
<br>
<ul>
<li><a class="moz-txt-link-freetext"
href="https://www.esp32.com/viewtopic.php?t=4701"
moz-do-not-send="true">https://www.esp32.com/viewtopic.php?t=4701</a></li>
<li><a class="moz-txt-link-freetext"
href="https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580f2881a2a"
moz-do-not-send="true">https://github.com/espressif/esp-idf/commit/5404252e803f5489a72119a3ad41b580f2881a2a</a></li>
<li><a class="moz-txt-link-freetext"
href="https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb61431339"
moz-do-not-send="true">https://github.com/espressif/esp-idf/commit/f482e9e54ce83e249e46f5ee082f6ffb61431339</a></li>
<li>…some were lucky with this patch: <a
class="moz-txt-link-freetext"
href="https://esp32.com/viewtopic.php?f=2&t=4725"
moz-do-not-send="true">https://esp32.com/viewtopic.php?f=2&t=4725</a>
…we are not.</li>
</ul>
<p><br>
</p>
<blockquote type="cite"> //Due to hardware issue, we can not
use fifo_rst to reset uart fifo.<br>
//See description about UART_TXFIFO_RST and UART_RXFIFO_RST
in <<esp32_technical_reference_manual>> v2.6 or
later.</blockquote>
<br>
There is apparently no method to perform a full UART HW reset, at
least I haven't found one. It seems this is an issue we cannot fix
(in software).<br>
<br>
But I now don't think this is a new issue, and this also affects
modules quite differently, no idea depending on what
circumstances: on the current run, my car module has lots of FIFO
overflows & quite some MUX framing errors, but not a single
UART frame error.<br>
<br>
IOW, I don't think we should let that block the release.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 09.09.22 um 14:23 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:a9d16ded-2b62-a56a-8f15-d1f5dbf133fe@expeedo.de">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
A related issue -- I remember wanting to ask this before: why do
we receive all NMEA sentences three times / on three MUX
channels?<br>
<br>
Apparently they come in on channels 1, 3 and 4 -- stumbled
across this again because this now leads to these also being
added to a cellular command response:<br>
<br>
<font face="monospace">OVMS# cell cmd AT+CMUX?<br>
+CMUX: 0,0,5,118,0,0,600<br>
OK<br>
$GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07<br>
$GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68</font><br>
<br>
<br>
<font face="monospace">V (3388221) gsm-mux: ProcessFrame(CHAN=1,
ADDR=05, CTRL=ff, FCS=bf, LEN=78)<br>
D (3388231) gsm-nmea: Incoming RMC:
$GPRMC,114516.00,A,xxx.139223,N,xxx.391678,E,0.0,,090922,0.9,W,A*07<br>
V (3388231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (3388231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
<br>
V (3388241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
D (3388241) gsm-nmea: Incoming GNS:
$GNGNS,114516.00,xxx.139223,N,xxx.391678,E,AAN,11,1.0,324.4,47.0,,,V*68<br>
V (3388251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (3388261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
<br>
V (3393221) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
D (3393231) gsm-nmea: Incoming RMC:
$GPRMC,114521.00,A,xxx.139223,N,xxx.391676,E,0.0,,090922,0.9,W,A*0D<br>
V (3393231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (3393231) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
<br>
V (3393241) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
D (3393241) gsm-nmea: Incoming GNS:
$GNGNS,114521.00,xxx.139223,N,xxx.391676,E,AAN,11,1.0,324.4,47.0,,,V*62<br>
V (3393251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (3393261) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
<br>
</font><br>
This also produces a lot of unnecessary stress on the ESP's RX
buffer, doesn't it?<br>
<br>
Channel 1 is the dedicated NMEA channel, 3 is POLL and 4 is CMD.
I don't see why channels 3 & 4 are used for these by the
modem, but I also cannot find any command meant to configure
this.<br>
<br>
Any idea on this?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 09.09.22 um 13:14 schrieb
Michael Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:8939480a-6502-acb5-a758-d6ae90c66712@expeedo.de">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Mark,<br>
<br>
(am I the only one experiencing this?)<br>
<br>
I've had multiple times of temporarily frozen modem
communication over the last days on my car module. That's new,
so I think we should try to fix that before releasing.<br>
<br>
On my bench module there's a clear correlation between the
extended status query and the frame errors. It's also not
related to the NMEA messages, I've checked that, they come at
another second.<br>
<br>
Log excerpts below.<br>
<br>
With frame errors responses also occasionally get corrupted,
e.g.<br>
<font face="monospace">D (204251) cellular: mux-rx-line #3:
Hologram",7</font><br>
<br>
I think the extended status responses now very often cause an
overflow on the RX buffer when coming in together. Solution
could be to split the queries and distribute over 2-3 seconds.<br>
<br>
I don't know if that will also fix the strange cold/warm boot
difference with this, but maybe that's simply because the
modem is faster with getting back to the network after a
reboot, so the status responses become large quickly.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<font face="monospace">D (204211) cellular: mux-tx #3:
AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS?<br>
W (204251) gsm-mux: Frame error: EOF mismatch (CHAN=55,
ADDR=df, CTRL=ff, FCS=35, LEN=133)<br>
V (204251) gsm-mux: Frame dump: f9 df ff ff bf bf dd ff f9
0d ff af 0d 0a 2b 43 | ..............+C<br>
V (204251) gsm-mux: Frame dump: 50 53 49 3a 20 4c 54 45 2c
4f 6e 6c 69 6e 65 2c | PSI: LTE,Online,<br>
V (204251) gsm-mux: Frame dump: 32 36 32 2d 30 32 2c 30 78
42 30 46 35 2c 31 33 | 262-02,0xB0F5,13<br>
V (204251) gsm-mux: Frame dump: 31 37 39 34 31 32 2c 34 34
38 2c 45 55 54 52 41 | 179412,448,EUTRA<br>
V (204251) gsm-mux: Frame dump: 4e 2d 42 41 4e 44 31 2c 31
30 30 2c 34 2c 34 2c | N-BAND1,100,4,4,<br>
V (204251) gsm-mux: Frame dump: 2d 39 32 2c 2d 31 31 35 32
2c 2d 38 37 35 2c 31 | -92,-1152,-875,1<br>
V (204251) gsm-mux: Frame dump: 34 0d 0a 34 f9 f9 0d ff ed
0d 0a 2b 43 52 45 47 | 4..4.......+CREG<br>
V (204251) gsm-mux: Frame dump: 3a 20 31 2c 35 0d 0a 0d 0a
2b 43 47 52 45 47 3a | : 1,5....+CGREG:<br>
V (204251) gsm-mux: Frame dump: 20 31 2c 35
0d | 1,5. <br>
V (204251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=da, LEN=25)<br>
D (204251) cellular: mux-rx-line #3: Hologram",7<br>
V (208231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
V (208241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (208251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
V (208251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
V (208271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
<br>
…<br>
<br>
V (233271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (233271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
D (234211) cellular: mux-tx #3:
AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS?<br>
W (234211) cellular: UART frame error<br>
W (234211) cellular: UART frame error<br>
W (234211) cellular: UART frame error<br>
W (234211) cellular: UART frame error<br>
W (234231) gsm-mux: Frame error: EOF mismatch (CHAN=63,
ADDR=ff, CTRL=ea, FCS=2c, LEN=53)<br>
V (234231) gsm-mux: Frame dump: f9 ff ea 5f ff b7 ff fd ff
b9 df fd bf f9 ff fd | ..._............<br>
V (234231) gsm-mux: Frame dump: fb ff f9 f9 a9 f9 0d ff af
0d 0a 2b 43 50 53 49 | ...........+CPSI<br>
V (234231) gsm-mux: Frame dump: 3a 20 4c 54 45 2c 4f 6e 6c
69 6e 65 2c 32 36 32 | : LTE,Online,262<br>
V (234231) gsm-mux: Frame dump: 2d 30 32 2c
30 | -02,0 <br>
V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=a7, LEN=124)<br>
D (234241) cellular: mux-rx-line #3: +CREG: 1,5<br>
D (234241) cellular: mux-rx-line #3: +CGREG: 1,5<br>
D (234241) cellular: mux-rx-line #3: +CEREG: 1,5<br>
D (234241) cellular: mux-rx-line #3: +CCLK:
"22/09/09,12:52:41+08"<br>
D (234241) cellular: mux-rx-line #3: +CSQ: 13,99<br>
V (234241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=da, LEN=25)<br>
D (234251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de
Hologram",7<br>
V (238231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
V (238241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
<br>
…<br>
<br>
V (293251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
V (293251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
V (293271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (293271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
D (294211) cellular: mux-tx #3:
AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS?<br>
W (294211) cellular: UART frame error<br>
W (294211) cellular: UART frame error<br>
W (294211) cellular: UART frame error<br>
W (294241) gsm-mux: Frame error: EOF mismatch (CHAN=59,
ADDR=ef, CTRL=db, FCS=2b, LEN=117)<br>
V (294241) gsm-mux: Frame dump: f9 ef db df ef df f7 cb f9
ff ff db 7f fd ff ff | ................<br>
V (294241) gsm-mux: Frame dump: f9 0d ff af 0d 0a 2b 43 50
53 49 3a 20 4c 54 45 | ......+CPSI: LTE<br>
V (294241) gsm-mux: Frame dump: 2c 4f 6e 6c 69 6e 65 2c 32
36 32 2d 30 32 2c 30 | ,Online,262-02,0<br>
V (294241) gsm-mux: Frame dump: 78 42 30 46 35 2c 31 33 31
37 39 34 31 32 2c 34 | xB0F5,13179412,4<br>
V (294241) gsm-mux: Frame dump: 34 38 2c 45 55 54 52 41 4e
2d 42 41 4e 44 31 2c | 48,EUTRAN-BAND1,<br>
V (294241) gsm-mux: Frame dump: 31 30 30 2c 34 2c 34 2c 2d
39 36 2c 2d 31 31 35 | 100,4,4,-96,-115<br>
V (294241) gsm-mux: Frame dump: 35 2c 2d 38 37 33 2c 31 34
0d 0a 34 f9 f9 0d ff | 5,-873,14..4....<br>
V (294241) gsm-mux: Frame dump: ed 0d 0a 2b
43 | ...+C <br>
V (294251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=da, LEN=25)<br>
D (294251) cellular: mux-rx-line #3: Hologram",7<br>
V (298231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
V (298241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (298241) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
V (298251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
V (298261) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (298271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
<br>
…<br>
<br>
V (323251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
V (323261) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
V (323271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (323271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
D (324211) cellular: mux-tx #3:
AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS?<br>
W (324231) gsm-mux: Frame error: EOF mismatch (CHAN=29,
ADDR=77, CTRL=fb, FCS=45, LEN=125)<br>
V (324231) gsm-mux: Frame dump: f9 77 fb ef 5f ff bb ed fb
bb db ff b7 fb cf ff | .w.._...........<br>
V (324231) gsm-mux: Frame dump: bf d9 ff bb f9 0d ff b1 0d
0a 2b 43 50 53 49 3a | ..........+CPSI:<br>
V (324231) gsm-mux: Frame dump: 20 4c 54 45 2c 4f 6e 6c 69
6e 65 2c 32 36 32 2d | LTE,Online,262-<br>
V (324231) gsm-mux: Frame dump: 30 32 2c 30 78 42 30 46 35
2c 31 33 31 37 39 34 | 02,0xB0F5,131794<br>
V (324231) gsm-mux: Frame dump: 31 32 2c 34 34 38 2c 45 55
54 52 41 4e 2d 42 41 | 12,448,EUTRAN-BA<br>
V (324241) gsm-mux: Frame dump: 4e 44 31 2c 31 30 30 2c 34
2c 34 2c 2d 31 30 39 | ND1,100,4,4,-109<br>
V (324241) gsm-mux: Frame dump: 2c 2d 31 31 36 36 2c 2d 38
37 34 2c 31 31 0d 0a | ,-1166,-874,11..<br>
V (324241) gsm-mux: Frame dump: c2 f9 f9 0d ff ed 0d 0a 2b
43 52 45 47 | ........+CREG <br>
V (324241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=da, LEN=25)<br>
D (324241) cellular: mux-rx-line #3: Hologram",7<br>
V (328231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
V (328241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (328251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
<br>
…<br>
<br>
V (353251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
V (353251) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=b1, LEN=82)<br>
V (353271) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=f4, LEN=82)<br>
V (353271) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f9, LEN=82)<br>
D (354211) cellular: mux-tx #3:
AT+CREG?;+CGREG?;+CEREG?;+CCLK?;+CSQ;+CPSI?;+COPS?<br>
W (354211) cellular: UART frame error<br>
W (354211) cellular: UART frame error<br>
W (354211) cellular: UART frame error<br>
W (354211) cellular: UART frame error<br>
V (354231) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=34, LEN=93)<br>
D (354231) cellular: mux-rx-line #3: +CPSI:
LTE,Online,262-02,0xB0F5,13179412,448,EUTRAN-BAND1,100,4,4,-122,-1184,-874,9<br>
V (354241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=a7, LEN=124)<br>
D (354241) cellular: mux-rx-line #3: +CREG: 1,5<br>
D (354241) cellular: mux-rx-line #3: +CGREG: 1,5<br>
D (354241) cellular: mux-rx-line #3: +CEREG: 1,5<br>
D (354241) cellular: mux-rx-line #3: +CCLK:
"22/09/09,12:54:41+08"<br>
D (354251) cellular: mux-rx-line #3: +CSQ: 13,99<br>
V (354251) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=da, LEN=25)<br>
D (354251) cellular: mux-rx-line #3: +COPS: 0,0,"vodafone.de
Hologram",7<br>
V (358231) gsm-mux: ProcessFrame(CHAN=1, ADDR=05, CTRL=ff,
FCS=bf, LEN=78)<br>
V (358241) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff,
FCS=fa, LEN=78)<br>
V (358251) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff,
FCS=f7, LEN=78)<br>
</font><br>
</blockquote>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>