Hi
I am using the EM7565 that supports 2 SIM cards.
I planned to develop management code in QMICLI as it is more simple and more easily readable than AT commands.
But looking at the QMICLI ref guide, I only found 2 commands directly providing access to SIM slot1 or slot2 (–uim-sim-power-on and uim-sim-power-off).
Other uim related QMICLI commands do not allow to set a slot id as parameter (I have even look in the qmicli code from linux and in fact, in the command tehmselves, they force the slot number to slot 1 so thta it seems those commands only access slot 1 SIM card).
And QMICLI commands from other group than uim are not dependent on the slot id at all.
Is there any way to address both SIM cards in QMICLI command ? Selecting any of them and connecting on it ?
Otherwise, I think about a mix of AT and QMICLI commands.
Concerning AT commands, I think about using “at!uimsX” AT command where X = 0 for first slot and X = 1 for second slot (next command whether QMICLI or AT commands will be directed to the slot id I ahve juts idenfied as the rpimary SIM with the previous AT command). And most probably also managing the SIM card activation via PIN by AT command also as the QMICLI uim related command hardcode a slot 1 target (so I could not activate a slot 2 SIM card using its PIN code with a QMICLI command).
Is it correct ?
As far as I understand, the QMICLI seems developped to manage only slot 1 SIM card for most of the commands ? At leats fro the QMICLI version I look at the code).
Thanks
I have been able to go further.
Two points :
(1) The SLOT1 thta is hardcoded in SQMICLI commands do not correspond to the physical SLOT1 where the SIM card is inserted. It corresponds to the primary SIM. The SIM that is used to connect.
(2) AT commad “AT!UIMS=X” where X=0 or 1 allow to set physical SIM slot 1 or physical SIM slot 2 as primary SIM.
So before executing any connection, I first execute an AT command “AT!UIMS=X” to set physical SLOT 1 or physical SLOT2 as primary SIM slot. And then all the QMICLI commands work correctly with this SIM card.
But I still have one question. I did not find QMICLI command to set the primary SIM slot. If possible I would prefer to do evrything in QMICLI commnd instead of miwing QMICLI and AT commands.
Any idea on a QMICLI command that would allow to configure the primary SIM SLOT ?
Thanks
If I’m not mistaken, the effect of running AT!UIMS=0|1 command to switch between slot 0 or 1 is equivalent to running qmicli --uim-switch-slot=1|2; i.e. changing which is the current active slot.
Slot status operations will be available since libqmi 1.26. There’s already a 1.26-rc1 available here: https://lists.freedesktop.org/archives/libqmi-devel/2020-May/003322.html
E.g. see how the “slot status” field changes in the QMI slot status query after running the AT command.
$ sudo minicom -D /dev/ttyUSB2
AT!UIMS=1
OK
$ qmicli -d /dev/cdc-wdm2 -p --uim-get-slot-status
[/dev/cdc-wdm2] Successfully got slots status
[/dev/cdc-wdm2] 2 physical slots found:
Physical slot 1:
Card status: present
Slot status: inactive
ICCID: 8988211000000268949
Protocol: uicc
Num apps: 0
Is eUICC: no
Physical slot 2:
Card status: present
Slot status: active
Logical slot: 1
ICCID: unknown
Protocol: unknown
Num apps: 0
Is eUICC: no
$ sudo minicom -D /dev/ttyUSB2
AT!UIMS?
!UIMS: 1
OK
AT!UIMS=0
OK
$ qmicli -d /dev/cdc-wdm2 -p --uim-get-slot-status
[/dev/cdc-wdm2] Successfully got slots status
[/dev/cdc-wdm2] 2 physical slots found:
Physical slot 1:
Card status: present
Slot status: active
Logical slot: 1
ICCID: 8988211000000268949
Protocol: uicc
Num apps: 0
Is eUICC: no
Physical slot 2:
Card status: present
Slot status: inactive
ICCID: unknown
Protocol: unknown
Num apps: 0
Is eUICC: no
Or, testing the other way:
$ sudo minicom -D /dev/ttyUSB2
AT!UIMS?
!UIMS: 0
OK
$ qmicli -d /dev/cdc-wdm2 -p --uim-switch-slot=2
[/dev/cdc-wdm2] Successfully switched slots
$ sudo minicom -D /dev/ttyUSB2
AT!UIMS?
!UIMS: 1
OK
Thanks a lot for the information.
Unfortunately the project has been delivered in its final version to the customer with a qmicli version that do not support this qmicli SIM card selection command. It has been implemented in AT commands.
However, I will have an evolution request to be logged for the future when new version of the product will be implemented to move from AT command to qmicli.
Thanks again.
@pmonnie If you don’t mind me asking, how did you solve the problem of reliably communicating with the running modem via AT commands? On my system sometimes that port can be blocked because another service is sending a command. Did your system simply not have that problem, or was there some cleverness required?
Three mechanisms =>
(1) Shell lock files use to avoid concurrent access to the resource. But in my dev, I master all the accesses to the device (they are in different shell tasks so I syncronized them by shell lock files)
(2) Before each AT command I flush the content of the serial comm link, then I send my AT command and then I read serial link (loop of reading with 10 ms between each read) under shell during several seconds. If I have something else than expected answer on it (you can very easily have that case … ), I discard it and continue to read until either I get the expected response, either my timeout expires … If at end of timeout I do not have the expected answer, then I go to point (3)
(3) I globally retry the full process (i.e. cleanning serial output queue, sending AT command, waiting for answer) 3 times as long as I do not get correct answer. Only at the end of the 3 times I raise an error if failed.
Initially I was having failures quite often (particularly at the begining of my dev when I hadn’t deactivated yet the serial link echo process that can generate loop of sending between the two sides of the serial link) but with the above mechanism, I have no more now. It happens I still have to wait for second AT command sending for correct execution. But I never reach the 3rd AT command execution to have it successful.
the price is that AT commands are quite slow, but I have very few of them and they are only used at initialisation … not once communication is established with ground … so not really a problem.
But I have very few AT commands. Most of what I had to do was implemented in qmicli. which is far easier to manage than AT commands executed directly under the linux shell.
1 Like