[PATCH] ublox: use ID_MM_UBLOX_PORT_READY_DELAY udev flag as init

[Aleksander Morgado]

On Mon, May 7, 2018 at 4:32 PM, Matthew Starr <mstarr at hedonline.com> wrote:
>> -----Original Message-----
>> From: Aleksander Morgado [mailto:aleksander at aleksander.es]
>> Sent: Saturday, May 05, 2018 7:31 AM
>>
>> >> > > How about having a single call reading the udev tag value in
>> >> > > ublox_custom_init() and passing the value to wait_for_ready()?
>> >> > >
>> >> > > E.g.
>> >> > > static void
>> >> > > wait_for_ready (GTask *task,
>> >> > >                 guint wait_timeout_secs)
>> >> > > {
>> >> > > ...
>> >> > > }
>> >> > >
>> >> >
>> >> > The only issue with that is wait_for_ready() is also called by the
>> >> quick_at_ready() function which is a callback function, so I can't pass in
>> the
>> >> wait_timeout_secs to that instance.  I was thinking instead of adding
>> >> wait_timeout_secs to the CustomInitContext struct since that is already
>> >> available to the wait_for_ready() function no matter how it is called. Then
>> >> ctx->wait_timeout_secs can be set in the ublox_custom_init() function,
>> >> unless you have another recommendation.
>> >>
>> >> Oh, that's totally fine. Just read it once and store it in the
>> >> CustomInitContext.
>> >>
>> >
>> > One additional item is I found to reliably get the TOBY-R200 to initialize with
>> ModemManager I needed to have it use a 2 second delay using the
>> ID_MM_UBLOX_PORT_READY_DELAY udev flag in the 77-mm-ublox-port-
>> types.rules file.  Without this the modem is sometimes never initialized by
>> MM.  I am planning on adding that to the new patch I will be sending too.
>> >
>>
>> Humm.... but does the TOBY-R200 send the +READY URC before those 2s?
>> I don't understand why that would be needed really. Could you send
>> some logs with/without the 2s timeout to see the differences?
>>
>
> The TOBY-R200 does not send a +READY URC message.  The root issue is that when the USB serial devices (ttyACM) appear they are not really ready for communication yet.  This delay interface just happened to be an easy way to apply a delay at startup, but I can see how this is outside the code's intended use.
>
> Apparently several of the modems that u-blox has can send greeting text which by default is turned off, and when turned on the default greeting is a blank string.  Since the defaults have to be assumed, the use of the greeting on other u-blox modems will not be useful to determine when the modem is ready to communicate.
>
> If you want I can take out the 2 second delay from the patch and resubmit without that.
>

I believe the patch should go without 2 second delay, yes.

> I attached the logs with and without the delay for you to review.  You can see in the one without the delay MM never is able to get the modem to respond to the AT command even after 10 minutes of trying.
>

I'm extremely confused by this log (the one "without delay"). Is this
log obtained running from git master without any other patch on top?
Did you manually modify anything in the code to get this log? I would
expect to see "AT" commands *sent* to the device via the ttyACMx
interfaces and I'm not seeing those in the logs.


-- 
Aleksander
https://aleksander.es