Hi Giancinto

Den ons 19 feb. 2020 kl 11:05 skrev Giacinto Cifelli <gciofono@gmail.com>:

> Hi Richard,
>
> On Wed, Feb 19, 2020 at 10:06 AM Richard Röjfors
> <richard.rojfors@gmail.com> wrote:
> >
> > Hi Giancinto,
> >
> > Den tis 18 feb. 2020 kl 20:27 skrev Giacinto Cifelli <gciofono@gmail.com
> >:
> >>
> >> Hi Richard,
> >>
> >> On Tue, Feb 18, 2020 at 10:19 AM Richard Röjfors
> >> <richard.rojfors@gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Ofono (at least for ublox) is always powering off the radio during
> start.
> >> > This can of course be handy of programmatic reasons to bring the
> modem to a known state.
> >> > Some configuration requires the radio to be turned off;  for instance
> the LTE auto connect APN. But on the other hand these are stored in
> non-volatile memory and could be configured before hand.
> >> >
> >> > The big drawback with turning it off is that it might take time to
> register again when the radio is on. I have seen it taking more than 10
> minutes in extreme cases.
> >> >
> >> > In embedded systems this can be a big issue.
> >> >
> >> > I'm thinking of adding a configuration option to keep the radio on
> during start.
> >> >
> >> > Whats the general thought about this?
> >>
> >> my opinion would be to keep it like that.
> >> it can generate several headaches for several use cases, and break
> >> existing code.
> >
> >
> > Yes I agree that the startup sequence will change, which is risky, but
> > it would be an option for people knowing what they are doing.
> >
> >>
> >> for example when the SIM could change as compared with the previous
> >> boot.
> >
> >
> > When using this option you should know what you are doing. As I said you
> > might need to write settings to non-volatile memory since runtime changes
> > might not apply. And a SIM wont just change in environments where this
> > option should be used.
> >
> >>
> >> Then it becomes much harder to recover from this situation.
> >> it would be better to be able to boot the modem in airplane mode,
> >> directly, so that there is no flip-flop effect.
> >
> >
> > That could be an option, but that will cost up to several seconds of
> time.
> > In the systems I'm talking about the boot loader might kick the modem
> > running to get it registered as quickly as possible.
> >
> >>
> >>
> >> In any case I have never observed 10 minutes.
> >
> >
> > This is not the regular case. But I have observed this.
> >
> >>
> >> If this really happens, either the signal is so low that in any case
> >> the link will be pretty unstable, or the stack needs debugging.
> >
> >
> > I contacted the FAE's from the vendor regarding this. I guess they
> > want to keep the work load down, but their major complaint was
> > the way ofono turns off the radio. And even if they would fix their
> > bugs there will be modems in the field that behaves like this.
> > But regardless; 10min is a super long time, even if its just
> > seconds to save, that could be of importance...
> >
> >
> > I'm not sure its a good idea to introduce this. I need to,
> > but I wanted to check if there was an interest in the general public.
>
> trying is quite easy. In plugins/ublox.c, there are 2 occurrencies of
> "AT+CFUN=4":
>  -> change both of them to "AT+CFUN=1".
>   (I am not sure whether this will produce an error in case the modem
> is already in CFUN:1, but it is worth trying).
>

Yeah I have done this for a while. The question was not how to do it,
just if there was an interest to get this kind of code upstreamed.

FYI;
It did not work out of the box at that point, since it triggered some
race conditions. These could happen anyway so they are fixed in
upstream ofono.


>
> If you are satisfied, then you can make it conditional with an
>      if (getenv("OFONO_UBLOX_NO_CFUN_FLIP"))
>

That could be a "simple" way of adding the switch.

--Richard