[poll: vote now!1!!] 3G paranoia: Discussing solutions

[zmatt]

Sigh, so now we have

• a power switch on the battery supply line to the module, even though its documentation repeatedly warns not to disconnect this supply until the module has been powered down;
• the EMERG_OFF input it provides to forcibly power if off (if shutting it down cleanly is not an option) has been left unconnected;
• the VEXT supply output you can monitor to confirm it is powered down has been left unconnected;
• a current measurement resistor ("to detect if the Modem is doing unwanted Things") in series with its supply despite the importance of avoiding dips on this supply during transmit bursts;

And this was a good idea.. why?

Oh well, on the bright side it looks like both the power switch and the resistor can be easily bridged. The inaccessibility of EMERG_OFF is a bummer though, it seems there's not even a test pad for it.

BTW, as for the "proprietary" firmware on the modem, this talk is enlightening. Although I can't be sure yet, it seems to me there's a pretty good chance something similar is on the modem we use.

 

[Linux-SWAT]

I don't get it, we now can't be sure that the modem is off ???

 

[zmatt]

I don't get it

That's pretty clear yeah

we now can't be sure that the modem is off ???

This is indeed a rare case where ??? is the appropriate punctuation since the first thing I said in my post was:

Sigh, so now we have

• a power switch on the battery supply line to the module, ...

 

[Linux-SWAT]

Probably read too fast.
There's no mention of the led on the supply line, a software solution to monitor that is a bad idea.

 

[zmatt]

Probably read too fast.
There's no mention of the led on the supply line, a software solution to monitor that is a bad idea.

...

Ehm, no? If you want to waste a led on that feel free to configure that, I'll pass on an always-on led.

 

[dTal]

Sigh, so now we have

• a power switch on the battery supply line to the module, even though its documentation repeatedly warns not to disconnect this supply until the module has been powered down;
• the EMERG_OFF input it provides to forcibly power if off (if shutting it down cleanly is not an option) has been left unconnected;
• the VEXT supply output you can monitor to confirm it is powered down has been left unconnected;
• a current measurement resistor ("to detect if the Modem is doing unwanted Things") in series with its supply despite the importance of avoiding dips on this supply during transmit bursts;

And this was a good idea.. why?

Oh well, on the bright side it looks like both the power switch and the resistor can be easily bridged. The inaccessibility of EMERG_OFF is a bummer though, it seems there's not even a test pad for it.

BTW, as for the "proprietary" firmware on the modem, this talk is enlightening. Although I can't be sure yet, it seems to me there's a pretty good chance something similar is on the modem we use.

What's the practical upshot of this? What happens if, in direct opposition to the documentation, you actually use the power cutoff? Will the module be damaged? Seems like it must be pretty important given that EMERG_OFF even exists.

Doesn't really seem like it would take too many extra components to get the best of both worlds - a hard power cutoff switch like we have now, plus a small circuit downstream that would 1) buffer enough power in a capacitor to keep the modem alive long enough to 2) send high to EMERG_OFF. Basically a tiny UPS. Assuming this is feasible with modem power consumption and shutdown time, this would be conformant to the docs even in the face of a system power failure and also reliably shut the modem down even if it were misbehaving.

(I tried to find the documentation for myself but as far as I can tell all the Gemalto links previously posted on this forum are now dead.)

 

[hns]

Don't worry about this.

Nobody can prevent that main power is interrupted unexpectedly by removing the battery...
And there are ca. 250µF outside of the module and an unknown amount of buffer capacity inside.

The only harm that can/will happen is that if you are in the middle of changing the PIN or a phone book entry you won't know if it has been changed or not.

EMERG_OFF does not help either in case of power interruption. Usually the official command is to use a software command (AT^SMSO) to shut down the module, which does the same as EMERG_OFF.

To assure you that there is no problem, I have looked up and found no mention of a damage situation in the manuals. They rather say: "Caution: Use the EMERG_OFF line only when, due to serious problems, the software [means modem firmware] is not responding for more than 5 seconds. Pulling the EMERG_OFF line causes the loss of all information stored in the volatile memory. Therefore, this procedure is intended only for use in case of emergency, e.g. if PLS8-E does not respond, if reset or shutdown via AT command fails. "

So it is an emergency measure if the module firmware fails. Not if power fails.

Since we have additional control over power we can always cut power and this resets the module. Of course there is also loss of volatile memory.

I assume the reason for the EMERG_OFF feature is that if the module is used in some remote location (e.g. webcam on top of a mountain in winter) where it costs a lot of money to send somebody to remove the battery and do a real power cycle if the module firmware gets stuck (which anyways should not happen). And maybe some lead customer of Gemalto just required such a feature to exist after doing the FMEA analysis of their system. So it exists but nobody else has to use it if there are good enough alternatives.

There might also be a watchdog timer connected to some microcontroller and if that one times out, it could activate EMERG_OFF just to be safe.
So basically EMERG_OFF seems to be an alternate control of the power switch inside the module. Like pressing the power button of the Pyra (or your notebook) for ca. 10 seconds.

But since we have our own power switch and can always remove the battery I do not see why we should use EMERG_OFF.

And because VEXT was mentioned. There is a PWR_IND output which has exactly the same meaning (but in 1.8V logic levels). And that one is connected to a GPIO of the OMAP. Our rfkill driver uses it to detect if modem was turned on/off.

Power supply dips by a 20mOhm shunt resistor (2 A => 40 mV) are not really significant. At 3.7V battery voltage they are approx. 1%. Note that resistance inside battery, battery connectors, charger switch, copper traces are in the same range.
And all this is buffered by the above mentioned >250 µF. Yes, it would be better to avoid these resistances, but the modem also works with.

 

[zmatt]

The only harm that can/will happen is that if you are in the middle of changing the PIN or a phone book entry you won't know if it has been changed or not.

The manual states that after triggering emergency shutdown using EMERG_OFF,

Please note that the power supply voltage (BATT+) may be disconnected resp. switched off only after having reached Shut Down as indicated by the PWR_IND signal going high.​

Since, as you mentioned, EMERG_OFF already incurs data loss, this warning must be included for other reasons.

My understanding of EMERG_OFF exists to allow the module to be forcibly shut down if asking it politely doesn't work, because cutting its power to do so isn't allowed. Maybe I'm wrong, but this is the impression I get from the manual, and is also what I'd expect since abrupt power cuts can easily cause all sorts of trouble on a complex module like this.

Perhaps you could ask Gemalto for clarification?

 

[hns]

Hi,
it also says

The best and safest approach to powering down PLS8-E is to issue the AT^SMSO command. This procedure lets PLS8-E log off from the network and allows the software to enter into a secure state and safe data before disconnecting the power supply.

So this is only the "safest approach". Which does not imply that it is "unsafe" if this procedure is not exactly followed .
Especially I don't see a warning that the module can be damaged. It is only about unspecified "safe data" (where I still wonder what that should be - maybe the list of currently visible base stations).

Basically it is all about that the module gets enough time after a normal AT^SMSO to actively deregister from the network.
Then, the network knows immediately that the user is no longer reachable and can redirect a call to the voice mailbox.

If it is not properly deregistered, the network will do a paging call in the last neighboring cell and try to "wake up" the module.
This will timeout after a while if there is no response. This adds a delay for the caller until he/she is switched to the voice mailbox.
And of course network operators prefer if it is not necessary.

Therefore they also recommend this for the EMERG_OFF. Just wait until module is powered down. Anyways this is a little over-engineered.
If the modem firmware is stuck, there is no guarantee that the module reacts to EMERG_OFF at all, isn't it? Then your only chance to
reset/reboot the modem firmware is to cut power.

I think it is the same with every mobile phone (same complexity like a module) when removing the battery. Or putting it into a shielded
box (or cellar or tunnel or otherwise uncovered radio area).

Anyways, we can (and will) easily follow the recommended sequence. We just send AT^SMSO, wait for PWR_IND to change and
then turn off the modem power switch transistor. So where is the problem?

What can be debated IMHO is the rare case of removing the battery while in full operation. But how often have you done that on
your devices (smart phones, tablets, notebooks) and how often was it damaged afterwards? A module is not inherently more
risky for power cuts than any other embedded system.

 

[zmatt]

What can be debated IMHO is the rare case of removing the battery while in full operation. But how often have you done that on your devices

Extremely rarely I think, only as last resort.

A module is not inherently more risky for power cuts than any other embedded system.

I can reflash the pyra if it gets hosed. This seems far more problematic for the modem.

We both seem to be speculating however about the exact nature and purpose of EMERG_OFF and the risks of a power cut, and I agree the manual isn't really sending a very coherent message on this topic. Could ask Gemalto about this to settle any doubt?

 

[hns]

Extremely rarely I think, only as last resort.
I can reflash the pyra if it gets hosed. This seems far more problematic for the modem.

We both seem to be speculating however about the exact nature and purpose of EMERG_OFF and the risks of a power cut, and I agree the manual isn't really sending a very coherent message on this topic. Could ask Gemalto about this to settle any doubt?

Why should you ever have to reflash the modem? During operation the flash is read-only so it can not be corrupted during operation or power is cut. Only RAM looses information.
Anyways, if there were such a high risk they would explicitly have to write a big warning. And they would not be able to sell these modules to anyone else. But they do in higher quantities that Pyras are planned. Hence I assume that bigger companies than OpenPandora have already checked everything...
Since I have no doubts about this topic, I see no no reason that I go and ask Gemalto (which is already quite indirect since we are a small customer for them)...

 

[lukey]

Maybe the different Voltages need to be disconnected in a strict order or something in the TX Amplifier needs to be discharged like on Old CRTs.