<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
You can now see these error in the "*-OVM-ServerLogs" CSV as well,
I've just extended the logging a bit to also capture logins and
terminations.<br>
<br>
For sending data, it's mostly a question of the available modem send
buffer and actual network MTU. You can query the available max send
size by...<br>
<br>
<tt>AT+CIPSEND=?</tt><br>
<br>
...which will normally be around 1460. You need to add base64
encoding and line termination overhead, but that still allows for
multiple data rows to be added to one send.<br>
<br>
That's done simply by doing multiple
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
net_msg_encode_puts() between net_msg_start() and net_msg_send().<br>
<br>
Doing multiple net_msg_start() in series without adding proper
delays will not work reliably, because the modem needs time to
transmit an IPSEND and flush the buffer. The new net_wait4modem()
function will assume the modem is ready after 50 ms of RX silence,
but that may not be enough to really get the modem ready for the
next IPSEND.<br>
<br>
That's the reason the framework uses the net_msg_sendpending
semaphore to know when the modem is definitely available again.<br>
<br>
So:<br>
<br>
- If your messages fit (encoded!) into the 1460 byte MTU (better
leave some headroom), you can just do this:<br>
<br>
<tt>net_msg_start();</tt><tt><br>
</tt><tt>for (index = 0; index < MAX_CAN_DUMP; index++) </tt><tt>{
prep net_scratchpad, call net_msg_encode_puts() }</tt><tt><br>
</tt><tt>net_msg_send();</tt><br>
<br>
This is the most efficient way.<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<br>
- If they don't fit, you need to split your send. Good practice is
to use some notification flags and hook into the idle() or ticker()
calls, checking the net_msg_sendpending semaphore.<br>
<br>
- If you really need to do multiple sends in series, add at least a
3 seconds delay after the net_msg_send() to give the modem enough
time to finish the transmission.<br>
<br>
Regard,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 07.01.2017 um 09:30 schrieb Tom
Parker:<br>
</div>
<blockquote
cite="mid:4cc2d90c-b014-8b86-2eda-a597b48585b5@carrott.org"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Interesting. I haven't changed anything in that code for a long
time, but I also hadn't noticed it was causing problems so might
have been broken for a long time? How do I see these errors?
Running my own server? Watching the comms with the modem?<br>
</p>
<p> It's supposed to send me up to the most recent of 3 different
CAN frames (chosen at compile time), once per minute. Looking
through the server logs (nice email feature on your server) I
see it fairly reliably sends the first frame each minute, but
usually not the others. The car is moving, so it's on, so all
three frames are present on the bus, so I'm reasonably sure it
is trying to send the other 2. I'm sending 3 messages one after
the other in this code triggered from ticker60
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://carrott.org/git/Open-Vehicle-Monitoring-System.git/blob/refs/heads/report-more-data:/vehicle/OVMS.X/vehicle_nissanleaf.c#l241">https://carrott.org/git/Open-Vehicle-Monitoring-System.git/blob/refs/heads/report-more-data:/vehicle/OVMS.X/vehicle_nissanleaf.c#l241</a><br>
</p>
Can I just send messages one after the other? The message
framework was... complicated. I see in the twizzy telemetry it may
only send one message each time it's called?<br>
<br>
<div class="moz-cite-prefix">On 07/01/17 08:52, Michael Balzer
wrote:<br>
</div>
<blockquote
cite="mid:9b439454-4703-7325-e8f7-3cad83b6ce27@expeedo.de"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Tom,<br>
<br>
I did some more log digging:<br>
<br>
a) Since yesterday, your log entries haven't contained any
garbage characters.<br>
<br>
b) "Unable to decode" messages now/still occur on a regular and
quite predictable base.<br>
<br>
The rule seems to be: the next message sent by the car after a
"H NL-COM-CAN" message will be broken.<br>
<br>
This happens independant of the time span between the "H"
message and the next, and as the following messages are of
varying sizes also independant of the message type.<br>
<br>
So this looks like a memory corruption coupled to the "H
NL-COM-CAN" message generation process, that kills your
encryption (or more...).<br>
<br>
Examples:<br>
<br>
<tt>2017-01-06 07:40:32.557128 +0100 info main: #26 C NZLLEAF
rx msg H NL-COM-CAN,3,86400,054A120070020000003B</tt><tt><br>
</tt><tt>2017-01-06 07:41:13.198896 +0100 info main: #26 C
NZLLEAF rx
6Rm2CahmvSvTu/P7nJMLkUiRqFS1rww6BrxQY7zBF0sQwamaOHBMRbuWby0Gs8P9nrMcW45Ft73uZT93u6sHGTOkUgcdh/fzeGF4gcPSpql4/cC+bksNFJKEjykWVMLJ+cNrvlh5E7DCmA==</tt><tt><br>
</tt><tt>2017-01-06 07:41:13.199028 +0100 error main: #26
NZLLEAF error - Unable to decode message - aborting connection</tt><tt><br>
</tt><tt><br>
</tt><tt>2017-01-06 13:10:03.385363 +0100 info main: #41 C
NZLLEAF rx msg H NL-COM-CAN,3,86400,054AA00070020000003A</tt><tt><br>
</tt><tt>2017-01-06 13:10:12.587657 +0100 info main: #41 C
NZLLEAF rx
zZ186U6RmvLkP272bNAP5xk3bRXt5P6Z/X+F86EaNtymnduvZT1o2UKu6+r4LUDGRCXe4vd/jQ==</tt><tt><br>
</tt><tt>2017-01-06 13:10:12.587918 +0100 error main: #41
NZLLEAF error - Unable to decode message - aborting connection</tt><tt><br>
</tt><tt><br>
</tt><tt>2017-01-06 20:35:34.710329 +0100 info main: #68 C
NZLLEAF rx msg H NL-COM-CAN,3,86400,054A1200700200000039</tt><tt><br>
</tt><tt>2017-01-06 20:35:39.556488 +0100 info main: #68 C
NZLLEAF rx
Tl4PXkvivM+Iq+eeIgNCHKcwqUhY4i/+0igGrXgx/kR89xTBlY3uYQVwRXZfZQnvwDAi+IsojhjncnNVDDhEZ9B6YTv/RGjtx0qdtAEOwBEQPRIwejEtBnNaHpNu8Cu2dwHDUQ8c</tt><tt><br>
</tt><tt>2017-01-06 20:35:39.556746 +0100 error main: #68
NZLLEAF error - Unable to decode message - aborting connection</tt><tt><br>
</tt><br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 05.01.2017 um 13:20 schrieb
Michael Balzer:<br>
</div>
<blockquote
cite="mid:4f88caed-ca8f-a160-658c-7a26e511b5a6@expeedo.de"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Also, the "S" corruption
originates from just a single wrong character inserted in
the encoded protocol message, i.e.<br>
<br>
+cGF352j<u><F3></u>FeLiJ59cMLlOXpRJhGa7sMGM9Rg/WeXeJuwKGCiuqv8p4FVNCKiHEsEnf9WeNbnm6JGPz7yxD7KjlQtOSVFtHXH2DGUa+C0x5ZaZRiSv6HpLxBkvIEBEu0f4EBPjF+X<br>
or<br>
+dUShf7R71hcb7msV8SCXu55xEwG9Z3Dx9G4UNuO9V7t7JFnGYwSmrf5aWouO+rm1PdZfQgLENbGLMVbv/tRfkEA+vZRPapkU<u><DB></u>KSO92hqvnrVcgJOVYNiglaXPqMt92lKXatEVO1<br>
<br>
-- IMO that cannot originate from the base64 encoding, so
can only come from some UART TX related problem (?)<br>
<br>
May be a serial log can show what's happening here.<br>
<br>
<br>
<br>
Am 05.01.2017 um 13:06 schrieb Michael Balzer:<br>
</div>
<blockquote
cite="mid:0cd58e1a-e7a8-3060-7282-82e8013f9e59@expeedo.de"
type="cite">Tom, <br>
<br>
from my logs archive: <br>
<br>
a) I found "duplicate car login" and "unable to decode"
errors from your car beginning on 2016-12-14 15:50 (UTC) <br>
...that was with firmware 2.8.7/NL1.0/V2/V2E9 <br>
<br>
b) garbage characters first occurred in the "S" messages
beginning with 2017-01-01 12:16 <br>
...that was right after changing your firmware to
2.9.2/NL1.0/V2/V2E9 <br>
<br>
The "L" message corruptions due to the stp_l2f bug started
on 2017-01-04 03:05 with 3.1.1/NL1.0/V2/V2E9. <br>
<br>
The "S" corruptions only occur with your car (on my server).
<br>
<br>
My earliest log kept is from 2016-12-10, and your car
messages were clean and error free until 2016-12-14 15:50. <br>
Can you tell what has changed on 2016-12-14 15:50? <br>
<br>
Regards, <br>
Michael <br>
<br>
<br>
Am 05.01.2017 um 04:08 schrieb Tom Parker: <br>
<blockquote type="cite">On 05/01/17 02:00, Michael Balzer
wrote: <br>
<br>
<blockquote type="cite">Checking the server log I found
another bug I introduced some time ago in the server
push notification code. <br>
I just restarted the fixed server, tell me if the
authentication notifications still occur. <br>
</blockquote>
<br>
The authentication success/failed messages are still
occurring. <br>
<br>
At 10:39 today I got a trunk open while in valet mode
alert via SMS but not via email and communication stopped.
I'm not setting the trunk or valet bits in the leaf
firmware. <br>
<br>
I'm logging the server traffic with client.pl and I see
this, where <FA> represents the raw hex 0xfa and ^E
is probably whatever ctrl-e is. <br>
<br>
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0
T0 <br>
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0
S77,K,0,0,stopped,standard,105,0,0,0,0,0,0,0,0,0,0,-1,0.00,-1,-1,0,0,-1,0,0,-1,-1<FA>_<8D>D<80>~^^D<A0>^Ev<D7>O<FA><br>
~^N <br>
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0
T0 <br>
Thu Jan 5 10:29:24 2017 Server message decodes to: MP-0
Z0 <br>
Thu Jan 5 10:29:35 2017 Server message decodes to: MP-0
Z1 <br>
Thu Jan 5 10:39:25 2017 Server message decodes to: MP-0
Z0 <br>
<br>
I think there must still be a corruption bug somewhere. It
might be time to bisect. <br>
_______________________________________________ <br>
OvmsDev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="50">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</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>