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

[Matthew Starr]

> -----Original Message-----
> From: Aleksander Morgado [mailto:aleksander at aleksander.es]
> Sent: Monday, April 30, 2018 6:50 PM
> 
> On Mon, Apr 30, 2018 at 10:45 PM, Dan Williams <dcbw at redhat.com> wrote:
> > On Mon, 2018-04-30 at 20:09 +0000, Matthew Starr wrote:
> >> > -----Original Message-----
> >> > From: Aleksander Morgado [mailto:aleksander at aleksander.es]
> >> >
> >> > >
> >> > > I don't understand why there is a 20 second timeout.  Couldn't
> >> > > you just test
> >> >
> >> > the AT interface right away with 'AT' instead of waiting a timeout
> >> > and then
> >> > trying it.  Also 20 seconds is a long time.  Couldn't a much
> >> > shorter timeout be
> >> > put in with some message sent to the modem to get it to respond
> >> > (like 'AT')
> >> > and do that several times to add up to 20 seconds.  This seems like
> >> > it would
> >> > be much quicker in cases where the modem did not respond
> >> > immediately
> >> > and might resolve this issue.
> >> > >
> >> >
> >> > That 20s timeout is really an artifact added for the TOBY-L4, to
> >> > wait
> >> > for the +READY URC it sends if the port is detected via hotplug
> >> > events. It's actually just to make it quicker the probing in the
> >> > TOBY-L4. This should be therefore something specific for the TOBY-
> >> > L4
> >> > and not something generic for all u-blox modems... sorry for that
> >> > :/
> >> >
> >> > I'll gladly accept a patch that makes this 20s timeout something
> >> > specific for the TOBY-L4 ;)
> >>
> >> I changed that timeout to 2 seconds and it resolved the 20 second
> >> timeout I was seeing.  Now as you said it needs to be something
> >> specific for the TOBY-L4.  At this early of a point in registration
> >> you haven't read the model number yet since communication hasn't been
> >> established.  The only way I can think of detecting the TOBY-L4 is
> >> using the USB product ID.
> >>
> >> Is there a function that allows obtaining the USB product ID that can
> >> be used in the context of the wait_for_ready() function in the
> >> plugins/ublox/mm-plugin-ublox.c file?  I tried the
> >> mm_port_probe_get_product() function called within the
> >> wait_for_ready() function, but just got (null) returned.
> >>
> >> Do you know if the TOBY-L4 has a unique USB product ID?  If so, do
> >> you know what it is?
> >
> > Could do it through udev tags too; eg tag TOBY-L4 in the udev rules as
> > needing a larger timeout, but all the rest get a shorter one.
> >
> 
> Yes, I was thinking in udev tags as well. For the TOBY-L4:
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="1010"

I took a slightly different approach in a patch set I just submitted.  I made a global way to set a ready delay through a new udev tag.  I figured that there are other modems that don't respond correctly during a certain amount of time after they are reset and this configurable delay through udev flags could be added to other plugins.

I then re-implemented the 20 second delay for the TOBY-L4 using this new udev method.

I didn't submit a patch for the TOBY-R2, but at boot I can get the modem to come up faster if I use a ready delay of 35 seconds on my device.  The reason this helps is the device has time to auto register with the cell network before MM probes the modem resulting in about one second between probing finish and a full simple connect.  This is faster than the 60-70 seconds it takes to do a simple connect when MM probes the modem before the modem has registered with the network.  This is really more of a workaround for the issue of MM not letting the TOBY-R2 modem auto register on its own instead of forcing a full re-register.  This is also why I did not include the TOBY-R2 timeout in the patch set.

Regards,
Matthew Starr