Hi Martin,
On 25/09/2019 09:27, Martin Hundebøll wrote:
Hi Jonas,
On 9/25/19 5:44 AM, Jonas Bonn wrote:
On 24/09/2019 21:20, Martin Hundebøll wrote:
On 24/09/2019 20.09, Martin Hundebøll wrote:
On 24/09/2019 19.23, Denis Kenzior wrote:
Furthermore, there's not an AT command sent every 500 ms. The
command gets requeued after 500ms, but it doesn't actually go out
until the modem responds to the first one... not quite sure why
this works, to be honest.
Funny. But not real confidence inspiring :)
Martin, any ideas what could be going wrong here?
The code looks quite familiar :)
For good reason! :)
Jonas, do you have a log with OFONO_AT_DEBUG=1 set?
ofonod[31545]: Aux: > AT\r
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: plugins/ublox.c:init_cmd_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: Aux: < \r\n+AT: READY\r\n
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > ATE0\r
ofonod[31545]: Aux: < ATE0
ofonod[31545]: Aux: < \r\r\nOK\r\n
For the record, here one from my setup:
UART: > AT\r
UART: < \371\013s\001\222\371
../git/plugins/quectel.c:init_timeout_cb() 0x610000000d40
UART: > AT\r
UART: < \r\nOK\r\n
../git/plugins/quectel.c:init_cmd_cb() 0x610000000d40
../git/src/modem.c:get_modem_property() modem 0x610000000d40 property
RtsCts
UART: > ATE0\r
UART: < \r\nOK\r\n
So yours looks a bit different... you really do lose the first AT
command into a black hole. The uBlox modem seems to not lose anything
sent over the USB bus but rather buffers it up and responds later.
That said, according to the documentation it _could_ lose the AT
command so one cannot rely on the response just turning up eventually.
Could it be safe to assume that it will lose only a single AT command?
In that case, it should be enough to send just two AT's. Once the first
OK is received, you could wait 500 ms for the second OK, or retry the
second AT in case of a timeout?
No lost AT:
> AT // Send first
> AT // Send second and wait
< OK // Wait 500 ms
< OK // Start initialization
One lost AT
> AT // Send first
> AT // Send second and wait
< OK // Wait 500 ms
> AT // Retry second
< OK // Start initialization
That's pretty much what we've got, isn't it?
The thing that wasn't clear to me, though, was why every invocation of
init_timeout_cb doesn't result in a new AT command being sent? It's
like the command is set to be retried in the first invocation, but it
never gets sent so the subsequent retries amount to no-ops. This
behaviour is agreeable in this case, but I don't quite understand why
it works this way...
Can the usb-to-serial driver block further writes until the modem is ready?
Not the driver but the modem. If the USB bulk endpoint on the modem
side decides it is busy (for example, because it's buffers are full), it
can NAK subsequent packets until it's ready to receive again. It's not
out of the question that Linux is smart enough to return EAGAIN for a
write in that case... but I would suspect that the OS would normally
buffer the write() for more than one AT command before this happened.
For that reason, I can't see why ofono would be able to detect this...
from ofono's point of view it should just look like there's a series of
AT commands going out and no responses coming back. There must be some
magic in g_io_...???
/Jonas
// Martin
_______________________________________________
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
