WP7607 - Differences between SKU 1103511 and 1104192

Hi,

we use WP7607 samples with different SKU numbers.
All samples have been reprogrammed with our own software, based upon R13.2 (legato 19.02).
They all use the same yocto build, based upon 2.5.

Apparently, there are some small differences in the bevahiour of SKU 1103511 vs 1104192.
For example:
when I execute the AT command AT+CGDCONT? on the target console, I get a different response.
SKU 1103511 : (returns always 1 item)
+CGDCONT: 1,“IP”, …

SKU 1104192 : (returns always a list of 3 items)
+CGDCONT: 1,“IP”, …
+CGDCONT: 2,“IPV4V6”, …
+CGDCONT: 3,“IPV4V6”, …

We also experience an issue with dropping LTE data sessions:

How can I compare the firmware versions and settings of both SKU samples?
What could cause the difference?

Our custom .spk image contains the following:

Type Size(Exclude Header) Product Compress Version

*SPKG 66760060 Y921 0 9999999_9907152_SWI9X07Y_02. 28.03 .01_00_GENERIC_002.064_000
*BOOT 408528 Y921 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
HASH 6480 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
SBL1 401248 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
*MODM 28242132 Y921 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
HASH 6560 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
TZON 550652 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
QRPM 158200 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
DSP2 27525120 9X28 0 SWI9X07Y_02. 28.03 . 01 000000 CARMD-EV-SIGN01 2019 / 04 / 16 23 : 57 : 08
*FILE 28392 Y921 0 9999999_9907152_SWI9X07Y_02. 28.03 .01_00_GENERIC_002.064_000
*APPL 33360016 Y921 0 Wed Sep 11 14 : 14 : 34 UTC 2019
SYST 23592960 9X28 0 Wed Sep 11 14 : 14 : 34 UTC 2019
APPS 9766256 9X28 0 3.18 . 131 20190911125640
3.18 . 131 20190911131455
3.18 . 131 20190911141422
*APPL 4718992 Y921 0 19.02 . 0 HostLegato 2019 / 10 / 23 10 : 26 : 29
USER 4718592 9X28 0 19.02 . 0 HostLegato 2019 / 10 / 23 10 : 26 : 29

greetings,
annaertd

Hi,

For SKU 1104192 : (returns always a list of 3 items)
+CGDCONT: 1,“IP”, …
+CGDCONT: 2,“IPV4V6”, …
+CGDCONT: 3,“IPV4V6”, …

Because this device has defined 3 PDP contexts before. You can delete PDP context 2,3 by AT command: AT+CGDCONT=2 and AT+CGDCONT=3.
How can I compare the firmware versions and settings of both SKU samples?
–> You can check package firmware version and SKU by these commands:
AT!UNLOCK=“A710”
AT!PACKAGE? (Displays the firmware package name)
AT!SKU? (Check the SKU store in NV Item is matched with package)
AT!PRIID? (Report module PRI part number and revision)
Please find the log file for more details. SKU_Log_WP76xx.txt (5.5 KB)

Hi,

I compared our WP7607 samples 1103511 vs 1104192.

Although all samples have been reprogrammed with the same custom .spk image (with firmware, linux and legato), there is still some difference in their behaviour.

How can I make sure they have the same settings/configurations/parameters?
How can I compare their factory defaults?

SKU: 1103511
PACKAGE:1103511_9907327_WP7607_02.16.02.00_00_Qualified_001.004_000
PRI Part Number: 9907327
Revision: 001.004
Customer: Qualified
Carrier PRI: 9999999_9907152_SWI9X07Y_02.28.03.01_00_GENERIC_002.064_000

SKU: 1104192
PACKAGE: 1104192_9908663_WP7607_02.18.05.00_00_Qualified_001.002_000
PRI Part Number: 9908663
Revision: 001.002
Customer: Qualified
Carrier PRI: 9999999_9907152_SWI9X07Y_02.28.03.01_00_GENERIC_002.064_000

greetings,
annaertd

@annaertd,

The main difference is the firmware, 1103511 had R8 where 1104192 had R10.1. The other big difference is that VoLTE has bee added to 4192. After that it is not easy to compare all of the exact setting, generically speaking it will be the same as they are generic units. Ther cannot be an exhaustive list given that a lot of the settings (like enabling VoLTE) is an individual NV item that is not accessible outside of Sierra.

Regards

Matt

Hi,

Nice to know that VoLTE has been added in 4192.

I know that 1103511 came with R8, and 1104192 came with R10.1.
I would like to understand why both samples behave differently even if I provide them with the same custom image based upon R13.1.
For instance:

  • my UMTS data session drops every 60 minutes on 4192, but, never drops on 3511.
  • my LTE data session drops every 60 seconds on 4192, but, never drops on 3511.

Do you have any idea which settings I need to check?

greetings,
annaertd

@annaertd,

Short answer is that there is nothing built into the units that will cause a connection to drop like you are describing. You are going to need to come up with some log files to pin down where the issue may or may not be.

Regards

Matt

Hi,

our server communicates with our modems at fixed intervals (eg every 30 or 50 minutes).
The communication uses UDP packets and TCP sessions.
The data session of the modem is created at startup of the application, and is connected to our APN until power down.

If the communication interval is less than 60 minutes, everything works fine.
When the interval goes above 60 minutes, the modem data session gets dropped when the server tries to communicate with the modem.

When I check my syslogs, I can see that every data session drop is preceded by a ‘remove WdsClient’ log. (see below)
Check for instance wdsclient 0x16f.

It’s hard to investigate what’s really going on, because I don’t have access to the source files swiQmi.c and pa_mdc_qmi.c.
Where can I find the definition of the serviceType values (eg 0x3) and msg_id values (eg 0x22)?
What is a WDS?

Nov 19 14:07:04 swi-mdm9x28-wp user.debug Legato: DBUG | modemDaemon[875]/swiQmi T=unknown | swiQmi.c WdsIndicationsHandler() 219 | serviceType=0x3
Nov 19 14:07:04 swi-mdm9x28-wp user.debug Legato: DBUG | modemDaemon[875]/swiQmi T=unknown | swiQmi.c WdsIndicationsHandler() 220 | msg_id=0x22
Nov 19 14:07:04 swi-mdm9x28-wp user.debug Legato: DBUG | modemDaemon[875]/swiQmi T=unknown | swiQmi.c WdsIndicationsHandler() 222 | clientHandle 0x16f
Nov 19 14:07:04 swi-mdm9x28-wp user.debug Legato: DBUG | modemDaemon[875]/le_pa T=unknown | pa_mdc_qmi.c QMINewSessionStateHandler() 1065 | wdsClient: 0x16f, profile index: 1
Nov 19 14:07:04 swi-mdm9x28-wp user.debug Legato: DBUG | modemDaemon[875]/le_pa T=main | pa_mdc_qmi.c mdc_qmi_ReleaseWdsClient() 2781 | Remove WdsClient [0][0] 0x16f

greetings,
annaertd
WP7607 R13.1 - UMTS data session drops and reconnects immediately.txt (52.0 KB)

@annaertd,

Again there just isn’t enough information, you need to describe the system i.e. are you using a Legato application a host processor, etc? Also a detailed description of the entire scenario, not just the slight excerpt from where you see the failure.

From your description it sounds to me like you stat a connection and don’t use it for 30 or 50 minutes and then expect it to still be there, there can be multiple failure points between the WP and the server if you do that.

FYI WDS is the wireless data service which is a set of QMI API’s Legato uses to interface to the signalling firmware.

Regards

Matt

Hi,

our provider gave us some extra info related to the LTE data session drop (after 60 seconds) of our SKU 1104192 modems.

1/ An LTE data session is built up normally
2/ After 60 seconds, a VOIP session is requested, although our application doesn’t need/implement VOIP
3/ Our APN does not support VOIP, so, this request is rejected by the network
4/ Because of this rejection, the network breaks down the active LTE data session
5/ Our application immediately tries to set up a new LTE data session, which goes fine
6/ 60 seconds later, a VOIP session is requested again, …

How can we avoid that our WP7607 modems request automatically for VOIP sessions?
Do we need to change a config file, or, can we use a Legato API call?

greetings,
annaertd

Hi,

I was able to fix the issue.

At startup of my application, I use Legato API calls le_mdc_GetProfileList(), le_mdc_GetProfile() and le_mdc_GetAPN() to check the APN name of all profile index numbers (except default index 1).
In case an APN name is different from the empty string, I use le_mdc_SetAPN() to give the APN an empty string name.

With this solution I can avoid to clear the modem profile 2 and 3, using AT commands:
AT+CGDCONT=2
AT+CGDCONT=3

As an exercise, I read the result after startup, using the AT command:

AT+CGDCONT?
+CGDCONT: 1,“IP”,“myAPNname”,“0.0.0.0”,0,0,0,0
+CGDCONT: 2,“IPV4V6”,"",“0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0”,0,0,0,0
+CGDCONT: 3,“IPV4V6”,"",“0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0”,0,0,0,1

Now, the modem doesn’t try to setup data sessions for profile 2 and 3, and the default data session doesn’t get interrupted anymore.

Greetings,
annaertd