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

[Aleksander Morgado]

Hey!

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

Like directly after starting MM? MM needs time to boot and expose
interfaces in DBus, you shouldn't be trying to enable a modem
immediately after MM is started.

Actually, there should not be any issue with starting MM right when
the system starts, and you can start both NM and MM in parallel if
needed. Then, only once the modem is probed and exposed in DBus, NM
would start the autoconnection process. There shouldn't be any need
for any other logic to be added, it's a bit surprising that you get
these errors I think.

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

Well, MM needs time to probe the modem. You can monitor the
availability of the modem with "mmcli -L" or "mmcli -M", or using your
own custom program to do so via libmm-glib (e.g. even in Python). See
the modem watcher example:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem-watcher-python

ModemManager will only expose the modem in DBus (i.e. expose it to NM
and other clients) once the modem is ready and fully probed, and that
may take a while.

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

So you mean that if MM tries to poke the ports *while* the TOBY is
still booting, it makes it timeout in the registration?
I have seen myself that in a different u-blox device the TTYs are
*not* ready as soon as they're exposed by the kernel, it may take up
to 10s-15s since they are exposed to be ready for AT commands
(although it usually is something like 5s-8s). But I haven't seen a
case where poking the TTYs early would end up triggering registration
failures or delays.

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

I've asked u-blox about this and hopefully they'll have an idea of
what's happening here.

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

That is easily solvable if the modem has predefined interfaces for
different purposes, which is very probable in this case. See e.g. the
TOBY-L4 port type rules defined here:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/ublox/77-mm-ublox-port-types.rules

-- 
Aleksander
https://aleksander.es