u-blox TOBY-R200 Intermittent Long Registration on Simple Connect

Thu Apr 5 23:21:04 UTC 2018

> -----Original Message-----
> From: Dan Williams [mailto:dcbw at redhat.com]
> Sent: Thursday, April 05, 2018 3:50 PM
> To: Matthew Starr; modemmanager-devel at lists.freedesktop.org
> Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on Simple
> Connect
> 
> On Thu, 2018-04-05 at 18:32 +0000, Matthew Starr wrote:
> > > -----Original Message-----
> > > From: Dan Williams [mailto:dcbw at redhat.com]
> > > Sent: Thursday, April 05, 2018 1:22 PM
> > > To: Matthew Starr; modemmanager-devel at lists.freedesktop.org
> > > Subject: Re: u-blox TOBY-R200 Intermittent Long Registration on
> > > Simple Connect
> > >
> > > On Tue, 2018-04-03 at 21:19 +0000, Matthew Starr wrote:
> > > > I have a u-blox TOBY-R200 running on an embedded Linux device with
> > > > the ModemManager 1.8-rc2 build, plus the patch for "ublox: fix
> > > > 'any'
> > > > mode building".  On this device there seems to be an issue between
> > > > the automatic registration of the TOBY-R200 modem and
> ModemManager
> > > > reaching the Simple Connect State (5/8) Register.
> > > >
> > > > Between reboots I can get ModemManager to have a quick
> > > > registration and then have a slow (40 or more seconds)
> > > > registration, where ModemManager seems to have caught the modem
> > > > right before it finished auto registration or for some reason a
> > > > denied state occurs and restarts the entire registration over.
> > > > The issue seems to happen right before simple connect state (5/8)
> > > > Register is run.
> > > >
> > > > Here is what is reported during a quick registration step:
> > > > Simple connect state (5/8): Register Already registered in network
> > > > 'XXXXXX', automatic registration not launched...
> > > >
> > > > Here is what is reported during a slow registration step:
> > > > Simple connect state (5/8): Register Launching automatic network
> > > > registration...
> > > >
> > > > See attached files for logs of the fast and slow registration from
> > > > the start of a simple connect to step (6/8) Bearer
> > >
> > > In the quick case, the modem is already registered long before
> > > SimpleConnect gets to it's registration check.
> > >
> > > In the slow case, the modem isn't yet registered.  It first reports
> > > GPRS=denied, UMTS=denied, LTE=idle.  MM then starts automatic
> > > registration on ACM0 and two seconds later gets GPRS=registered on
> > > ACM1.
> > > But ACM0 is still blocked running the AT+COPS=0 registration command
> > > which doesn't complete until 30 seconds later.  Only then can MM
> > > continue with the connection attempt, even though the modem was
> > > registered
> > > 28
> > > seconds before.
> > >
> > > So yeah, it's (1) a race with modem firmware between the two cases,
> > > and
> > >  (2) the modem not returning from the AT+COPS=0 automatic
> > > registration request even when it has already registered.  (though
> > > there is perhaps another small race where if the modem has just
> > > registered the instant before MM sends AT+COPS=0 and hasn't yet
> > > notified MM, it will then do a full network scan and registration
> > > cycle when the +COPS=0 comes in)
> > >
> > > How long has the modem been +CFUN=1 before you send the
> > > SimpleConnect() request?  Can you test whether waiting a couple
> > > seconds after the modem is fully enabled, before sending
> > > SimpleConnect(), makes a difference?
> > > We could also test-patch MM do that.  This isn't a real fix
> > > though...
> > >
> > > Dan
> > >
> >
> > Dan,
> >
> > I am using SystemV init scripts  for my init this device and I already
> > tested putting in various sleeps right after starting ModemManager
> > before I start NetworkManager which is setup to autoconnect to the
> > cellular connection.  I put in a sleep as long as
> > 30 seconds before NetworkManager is started and the rest of the boot
> > continues and it made no difference.  I was still getting random
> > results with sometimes MM seeing auto registration had already
> > completed and other times it forcing a full registration.
> 
> Are you enabling the modem from the scripts, or leaving that to
> NetworkManager?  If you're leaving it to NM, you might try "mmcli -m 0 -e"
> before doing the sleep.
> 
> Dan
> 

I added the "mmcli -m 0 -e" right after starting ModemManager, but in this case I got the message:
error: couldn't find the ModemManager process in the bus

Then I added a "sleep 1" before the "mmcli -m 0 -e", but still got an error message:
error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0'

I looked a little more into what was going on and found that this TOBY-R200 modem takes much longer than other u-blox modems I have used to initialize the virtual USB serial ports on startup.  It appears with the USB serial ports appear after ModemManager has already started, the longer registration occurs.  When I put a delay before ModemManager is started until after the USB serial ports appear, then I always get the fast registration.  This is without the "mmcli -m 0 -e" command being run at all.

I am not sure what in ModemManager is causing the registration issue based on this ordering of which appears/starts first.

Additionally it seems to take a really long time during a fast registration for ModemManager to actually startup, probe the modem, and attempt to connect.  It looks like the time between when ModemManager starts and when a simple connect can start because enough probing of the modem was finished is 34 seconds.  Much of this is waiting for 20 seconds for the /dev/ttyACM3, /dev/ttyACM4, and /dev/ttyACM5 interfaces to timeout to probing and then another 5 seconds as the same interfaces have AT commands sent to it and timed out again.  These are not AT command interfaces so it would be nice if this could be optimized for this modem.  I am not sure if this can be done or how to do it with ModemManager.

Matt

> > Matt
> >
> > > > Any idea on what the difference is between the fast and slow
> > > > registration and what might be causing it?  Any ideas how to fix
> > > > it?
> > > >
> > > > Best regards,
> > > > Matthew Starr
> > > >
> > > >
> > > > _______________________________________________
> > > > ModemManager-devel mailing list
> > > > ModemManager-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel