<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 12:33 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Mar 21, 2014 at 12:11 PM, Lars Knudsen <<a href="mailto:larsgk@gmail.com">larsgk@gmail.com</a>> wrote:<br>
> First, can someone with a deeper knowledge of how the modemmanager probes<br>
> tell me (for a near term solution) if it's possible to report back some<br>
> magic keyword to the initial "AT" that will let the modemmanager release a<br>
> device instantly?<br>
><br>
> Our problem is that we need to release very soon - and we want to support<br>
> Chromebook and Linux (in general) with our education platform (<br>
> <a href="http://www.empirikit.com" target="_blank">www.empirikit.com</a> ) - preferably without hacking our device to report as<br>
> something else - but we might be forced to to give an acceptable user<br>
> experience.<br>
<br>
<br>
</div>Hum... hard to tell how you can do that without needing to change MM.<br>
<br>
The probing logic is more or less explained here:<br>
<a href="http://www.freedesktop.org/software/ModemManager/api/1.2.0/ch02s02.html" target="_blank">http://www.freedesktop.org/software/ModemManager/api/1.2.0/ch02s02.html</a><br>
<br>
Basically, if MM decides that needs to probe the device, it will start<br>
with AT probing (sends "AT" several times) to see if the port is an<br>
AT-capable port. If you don't want to get the port detected as AT, you<br>
can just ignore the "AT" command and not reply anything. Note that if<br>
you e.g. reply "ERROR" to that, the port will anyway get flagged as<br>
AT-capable. After the AT probing fails, it will try QCDM probing,<br></blockquote><div>Bummer ;) - maybe this could be introduced as a possible bailout mechanism?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
sending a QCDM probe to see if the port replies correctly to it. If<br>
nothing is replied to the probe, the port will finally be discarded.<br>
This whole sequence may take up several seconds, as for each AT and<br>
QCDM probe we retry a couple of times. BTW, all this is for MM 1.x,<br>
the logic in MM 0.6.x is a bit different.<br></blockquote><div>How many seconds for the version in the current Chromebooks (approx?).</div><div>As the Chromebooks are not easily possible to hack a blacklist in - AND they</div>
<div>are considered a std consumer device, they will be most exposed to this problem. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Which kind of TTY are you exposing? Is it a read-only tty (e.g. a<br>
usual GPS NMEA port) or a read-write one?<br></blockquote><div> </div><div>We are making a science lab sensor/controller to be used in (primarily) </div><div>developing countries' science education (K7-K12). It's a two way communication</div>
<div>and we are basing it on Freescale's Freedom evaluation boards (e.g. FRDM-KL25Z + mbed firmware)</div><div><br></div><div>br</div><div>Lars</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div></div>