I had some trouble getting network strengh and access technology the
standard way on Quectel EC21. It does work - but only kind of. I did not
get URCs when I am sure I should. This way through CIEV, CIND and CMER
is also not documented in Quectel documentation, so I suspect this to be
unsupported.
This is now changed to the "quectelish" way of gettings those values and
this does work more fine-grained and reliable on the Quectel EC21.
The distinction between OFONO_VENDOR_QUECTEL and
OFONO_VENDOR_QUECTEL_SERIAL does not suffice for EC21/EC25 in some
places, so introduce and use a new vendor:
OFONO_VENDOR_QUECTEL_EC2X
As there are some more sources of +QIND: activated, do now only update
voltage when we get the
+QIND: "vbatt",-1
but not on things like
+QIND: "act","LTE"
or
+QIND: "csq",20,99
Set the URC port of the Quectel EC21 to uart1 when it is used through
it's serial port. This setting is saved to non-volatile storage by the
modem automatically.
This reverts commit 1868dbf2b3.
Development for this was done on EC21 firmware version
EC21EFAR06A01M4G_BETA0318. It now turns out, that actual release
firmware versions for this modem again need the original mux order with
aux channel as the second mux channel. (We know for sure for firmware
version EC21EFAR06A03M4G.)
We do not know for sure when and for what firmware versions quectel did
the switch back on the mux order, but we suspect that the "BETA"
firmware is the only one with the reversed mux order. This "BETA"
firmware was only given out for development purposes and will not appear
"in the wild", so we revert the patch here and hope for the best.
The Quectel EC21 does only work correctly, if the mux channel used for
aux is the first mux channel. It does only put it's URC messages in the
first mux channel, so this has to be the aux channel in our case.
To be flexible on the mux order we introduce two arrays here, that then
contain the initialization data in their needed order.
Initialization data is then applied by for-looping over this array.
This is a change for the EC21. It will require specific handling before
and right after setting up the mux. So this change prepares this. It
queries the modem model before the mux (CMUX) is activated.
Use at_util_sim_state_query_new() to query the sim inserted state. Once
that returns, the locked state is queried by issuing a AT+CPIN? command.
If not locked, a timer is started to query the quectel init status of
the sim. Once the init status is ready, the sim atom is created, and the
modem is set to powered, and the sim is signaled both inserted, and
initialized.
If locked, the modem is set to powered, and the sim atom is created.
This allows users to enter the pin to unlock the sim. Once the sim is
unlocked, a +CPIN: READY indication is caught to query the quectel
init status. Once the init status is ready, the sim is signaled
initialized.
All the above is needed, because the modem indicated +CPIN: READY before
the sim is really ready. The only way to be certain, is to wait for the
quectel init status to be ready. Even signaling the sim inserted
prematurely can cause to modem to hang during the initial AT+CRSM
commands.
The quectel M95 and MC60 modems are picky about when the sim is properly
initialized, so the logic to detect this needs to be in the quectel
plugin.
After doing basic initialization, a CPIN query is issued to detect sim
state.
If the sim is unlocked and ready, a timer is created to wait for the
modem state (AT+QINISTAT) to complete. At this point ofono is notified
about the initialized sim.
If the sim is locked, a listener for "+CPIN: READY" is set up to
know when a pin is entered. Once the indication is received, the timer
is set up as if the sim was unlocked from the beginning.
If the sim is busy/resetting, the CPIN query is issued again.
According to the manual, when using CMUX on the UC15, it outputs
unsolicited indications on port 2 (i.e. /dev/gsmtty2), so the quectel
plugin must use this when registering for such.
If the modem isn't powered on, the use of g_at_chat_set_wakeup_command()
makes ofono send out AT strings in an endless loop. Avoid this by using
g_at_chat_retry() in a timer instead.
The Quectel modems issues unsolicited strings in case of power related
events. The UC15 uses +QIND: for the events, while M95 and MC60 uses
descriptive strings. (UC15 also uses a string for normal power down).
Register listeners for these strings/codes. The handler emits an
appropriate dbus signal, and closes down the modem if needed.
The gprs-context does special casing on the quectel serial modem when
probing the supported layer 2 protocols, so pass the vendor id when
setting up the atoms.
Some Quectel models supports different features such as GNSS or
different URC strings. Add a field in the quectel data structure to be
used when adding support for said features.
The Quectel M95 modem issues a "Call ready" notification when call and
phonebook are ready, so set up a listener for that.
The only way to know when sms is ready is to issue QINITSTAT queries.
Since sms is always ready after call and phonebook, the queries are
initiated after creating call/phonebook.
This adds support for configuring a gpio in udev to control the modem
power.
To enable gpio control, specify OFONO_QUECTEL_GPIO_CHIP and
OFONO_QUECTEL_GPIO_OFFSET in the udev environment, for example:
KERNEL=="ttymxc0", ENV{OFONO_DRIVER}="quectel", \
ENV{OFONO_QUECTEL_GPIO_CHIP}="gpiochip2", \
ENV{OFONO_QUECTEL_GPIO_OFFSET}="26"
Setup GSM 07.10 multiplexing using the kernel n_gsm line discpline
driver, and use the virtual tty devices as Aux and Modem channels.
The driver supports rts/cts on the underlying serial device. This is
enabled with OFONO_QUECTED_RTSCTS udev environment, e.g.:
KERNEL=="ttymxc0", ENV{OFONO_DRIVER}="quectel", \
ENV{OFONO_QUECTEL_RTSCTS}="on"