Option to not power off radio during start ofono

Option to not power off radio during start ofono

[Richard =?unknown-8bit?q?R=C3=B6jfors?=]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

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?

BR
--Richard

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 912 bytes --]

Re: Option to not power off radio during start ofono

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

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.
for example when the SIM could change as compared with the previous
boot. 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.

In any case I have never observed 10 minutes.
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.

>
> BR
> --Richard
> _______________________________________________
> ofono mailing list -- ofono(a)ofono.org
> To unsubscribe send an email to ofono-leave(a)ofono.org

BR,
Giacinto

Re: Option to not power off radio during start ofono

[Richard =?unknown-8bit?q?R=C3=B6jfors?=]

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

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.

--Richard

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4031 bytes --]

Re: Option to not power off radio during start ofono

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

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).

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

But again, you know what you are doing in the lab, not later in the field.
If there is a SIM detection switch, for example, it is in general
detected by the modem only (and not by the application) and  therefore
only when it is running.
It can work well if the SIM is soldered.

>
> --Richard

Giacinto

Re: Option to not power off radio during start ofono

[Richard =?unknown-8bit?q?R=C3=B6jfors?=]

[-- Attachment #1: Type: text/plain, Size: 3974 bytes --]

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

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 5223 bytes --]

Re: Option to not power off radio during start ofono

[Giacinto Cifelli]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Hi Richard,

>>
>> 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.
>

I don't have a uBlox modem at hand to test, but I expect there can be
problems similar to race conditions if the AT+CFUN=4 is commented out
instead of being changed to something more innocent.
Actually also an empty "AT" would do in your case.

Giacinto

Re: Option to not power off radio during start ofono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Hi Richard,

On 2/18/20 3:19 AM, Richard Röjfors 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.

So by default we bring the device into airplane mode until the SIM card 
has been initialized.  Also, the policy decision of bringing the radio 
up / down was left to external services such as ConnMan.

> 
> 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.
> 

That's nuts.  Shouldn't take more than a few seconds?

> In embedded systems this can be a big issue.
> 

Indeed.

> I'm thinking of adding a configuration option to keep the radio on 
> during start.
> 
> Whats the general thought about this?
> 

Not sure.  Are you certain that adding such low-level config options is 
the right approach?  Even documenting / explaining what and why this 
configuration option is there would be challenging I imagine.

Regards,
-Denis

Re: Option to not power off radio during start ofono

[Richard =?unknown-8bit?q?R=C3=B6jfors?=]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi Denis,

Den ons 19 feb. 2020 kl 19:52 skrev Denis Kenzior <denkenz@gmail.com>:

> Hi Richard,
>
> On 2/18/20 3:19 AM, Richard Röjfors 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.
>
> So by default we bring the device into airplane mode until the SIM card
> has been initialized.  Also, the policy decision of bringing the radio
> up / down was left to external services such as ConnMan.
>
> >
> > 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.
> >
>
> That's nuts.  Shouldn't take more than a few seconds?
>

I would assume so too, but that's what we have experienced.


>
> > In embedded systems this can be a big issue.
> >
>
> Indeed.
>
> > I'm thinking of adding a configuration option to keep the radio on
> > during start.
> >
> > Whats the general thought about this?
> >
>
> Not sure.  Are you certain that adding such low-level config options is
> the right approach?


I'm not sure thats why I started the discussion. The other suggestion
in this thread was to use some environment variable to pass the
information, maybe thats a better way?


>   Even documenting / explaining what and why this
> configuration option is there would be challenging I imagine.
>

Yes it will be. I think I'm convinced we should not have this
feature upstreams.

--Richard

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 2678 bytes --]