<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">> Aren't the sim hot swap unsolicited messages received always, regardless of whether the modem is enabled or disabled? disabling_stopped function releases both ports contexts, so we don't receive unsolicited on SIM swap ports. > The only issue is when getting #QSS=0 after a +CFUN=4, right? Because we would be getting a SIM removal event that isn't really such thing, it was just the SIM card being powered off as well. Is there maybe a command to get into low-power mode that shuts down RF but leaves SIM card powered? This is correct, but we don't have commands that disable RF and leaves SIM card powered. > A wild idea, but would it be possible to wrap around the +CFUN calls between #QSS indication disabled and enabled? > E.g. > Disable #QSS indications (not just ignore them in MM, but explicitly tell the modem to not send them) > +CFUN=4 > Enable #QSS indications right away > (maybe the #QSS won't arrive here as it was disabled during CFUN?) > > Would that make sense? Or will the #QSS be sent anyway, even if it was disabled during the +CFUN being run? That's actually a good idea to test. I've thought about disabling on CFUN=4 and re-enabling on CFUN=1, but not around the same command. </div></div><div class="gmail_extra"> <div class="gmail_quote">On 1 August 2017 at 10:32, Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 01/08/17 10:04, Carlo Lobrano wrote: > last week I was working to handle a behavior that most of the Telit modem > have, that is, they emit *#QSS* unsolicited in consequence of *+CFUN* > commands. Most of the times, the modems are already in *+CFUN=1* at the > start so we did not notice it in a normal power up, but if we put the modem > in power low state, the *+CFUN=4* triggers a *#QSS=0* that the ModemManager > considers as a SIM swap. Note that this is receved as soon as the modem is > enabled again, because currently we release SIM swap ports while disabling > the modem, and, if we set power state on, ***together with the #QSS=1 due > to +CFUN=1*** causing a crash. > Aren't the sim hot swap unsolicited messages received always, regardless of whether the modem is enabled or disabled? > Generally speaking this behavior isn't wrong per se (a part from the crash, > that can be fixed), because the SIM is actually turned off, but in this > configuration we cannot re-enable the modem, while sending a *+CFUN=1* the > modem would be usable again. > > So, I made a couple of patches, (1) avoid releasing SIM swap ports on modem > disable, so we can still receive SIM notifications at the right moment, and > (2) ignore QSS unsolicited when changing *+CFUN* state and only for a short > amount of time. The problem is that there isn't a specific timeout within > which this unsolicited must arrive and according to my tests it is quite > variable (about between 3 and 10 seconds). > The only issue is when getting #QSS=0 after a +CFUN=4, right? Because we would be getting a SIM removal event that isn't really such thing, it was just the SIM card being powered off as well. Is there maybe a command to get into low-power mode that shuts down RF but leaves SIM card powered? > One solution is then to ignore *#QSS* for like 10 seconds, while the other > one is to keep ignoring them in the whole time between *+CFUN=4* and* > +CFUN=1*. This last solution is more consistent, but it won't let us get > SIM removal/insertion when the modem is in power-state-low. A wild idea, but would it be possible to wrap around the +CFUN calls between #QSS indication disabled and enabled? E.g. Disable #QSS indications (not just ignore them in MM, but explicitly tell the modem to not send them) +CFUN=4 Enable #QSS indications right away (maybe the #QSS won't arrive here as it was disabled during CFUN?) Would that make sense? Or will the #QSS be sent anyway, even if it was disabled during the +CFUN being run? -- Aleksander <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div> </div>