Hi Martin,
On 24/09/2019 21:20, Martin Hundebøll wrote:
Hi,
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.
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...
/Jonas
_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono