<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><a href="http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_Platforms_seminar_2007.pdf">http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_Platforms_seminar_2007.pdf</a></div></blockquote><div><br></div><div>This is GSM 7.10 TE-MS multiplexor protocol.</div><div><br></div><div>The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.</div><div><br></div><div>The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).</div><div><br></div><div>It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.</div><div><br></div><div>SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><a href="http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_application_note_v1.3.pdf">http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_application_note_v1.3.pdf</a></div><div><br></div><div><img id="f9ffe935-11e5-4e60-b823-d992f8920e08" height="592" width="480" apple-width="yes" apple-height="yes" src="cid:03F69F01-962C-4C79-838E-33911DFFAC48"></div></blockquote><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Am 28.04.2013 17:06, schrieb Michael Balzer:<br>
<blockquote cite="mid:517D3AED.40206@expeedo.de" type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
I just checked in my fix for the USSD reply handler. My tests with
streaming enabled did not produce any more crashes, so I think
that was the problem.<br>
</blockquote>
<br>
I was wrong, it's still crashing. I have to dig deeper it seems.<br>
<br>
Has anyone observed crashes with streaming mode on other vehicles,
or is this a Twizy specific bug now?<br>
<br>
Thanks,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>