AGPS issues with nRF9160 Dev Kit

Hello, 

I am using nRF9160 dev kit in Chicago (USA) and in Aldingen (Germany) where I am using same firmware for both DK to get GPS Fixes for location. But surprisingly in Aldingen without any single failure my Firmware works fine. But in Chicago the DK always gets stuck at  GPS_EVT_OPERATION_BLOCKED which will never get the GPS fix sometimes in 24 hours. Then next day if it gets the fix there are errors while downloading and feeding AGPS data to Modem. So can you please answer below question. 

Questions: 

1. If device is in Roaming status then is it will create an issues for GPS fixes? 

2. How to check the which operator we are connecting to?  

3. Does network operator can create issues for Dev Kits to be in PSM mode? Example: network operator can reject PSM mode settings even if Dev kit asks for 10 mins (TAU) of PSM mode and 1 minute of Active mode (RAT).

Console Logs:

GPS_EVT_SEARCH_STARTED 
GPS_EVT_AGPS_DATA_NEEDED 
[00:00:07.833,068] <dbg> nrf9160_gps.configure_antenna: MAGPIO set: AT%XMAGPIO=1,0,0,1,1,1565,1586
[00:00:07.833,740] <dbg> nrf9160_gps.configure_antenna: COEX0 set: AT%XCOEX0=1,1,1565,1586
[00:00:07.836,395] <dbg> nrf9160_gps.enable_gps: GPS mode is enabled
[00:00:07.845,153] <dbg> nrf9160_gps.start: GPS operational
[00:00:07.847,412] <dbg> nrf9160_gps.gps_thread: A-GPS data update needed
[00:00:07.849,792] <dbg> agps.init_supl: Using GPS driver to input assistance data
[00:00:07.849,822] <inf> agps: SUPL is initialized
[00:00:08.082,794] <dbg> agps.open_supl_socket: Connecting to 142.250.138.192 port 7276
[00:00:08.177,886] <inf> agps: Starting SUPL session
[00:00:08.180,053] <dbg> agps.supl_logger: ULP encoding length: 35
[00:00:08.180,664] <dbg> agps.supl_logger: Bytes sent: 35
[mqtt_evt_handler:391] MQTT PUBLISH result=0 len=7

Received Data from Server: No Data
[00:00:08.280,212] <dbg> agps.supl_logger: Bytes received: 30, total 30
[00:00:08.280,761] <dbg> agps.supl_logger: ULP ossDecode success, choice 3
[00:00:08.280,883] <dbg> agps.supl_logger: SUPL server responded using version 2.0.4
[00:00:08.280,975] <dbg> agps.supl_logger: SUPL response received
[00:00:08.281,158] <dbg> agps.supl_logger: ULP encoding length: 54
[00:00:08.281,799] <dbg> agps.supl_logger: Bytes sent: 54
[00:00:08.642,700] <dbg> agps.supl_logger: Bytes received: 708, total 708
[00:00:08.643,249] <dbg> agps.supl_logger: ULP ossDecode more input 4
[00:00:08.757,629] <dbg> agps.supl_logger: Bytes received: 708, total 1416
[00:00:08.758,148] <dbg> agps.supl_logger: ULP ossDecode more input 4
[00:00:08.981,079] <dbg> agps.supl_logger: Bytes received: 708, total 2124
[00:00:08.981,597] <dbg> agps.supl_logger: ULP ossDecode more input 4
[00:00:09.135,406] <dbg> agps.supl_logger: Bytes received: 708, total 2832
[00:00:09.135,925] <dbg> agps.supl_logger: ULP ossDecode more input 4
[00:00:09.191,772] <dbg> agps.supl_logger: Bytes received: 242, total 3074
[00:00:09.192,657] <dbg> agps.supl_logger: ULP ossDecode success, choice 5
--- 3 messages dropped ---
[00:00:09.203,155] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 2
--- 7 messages dropped ---
[00:00:09.216,003] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 2
--- 7 messages dropped ---
[00:00:09.231,140] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 2
--- 7 messages dropped ---
[00:00:09.240,478] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 2
--- 15 messages dropped ---
[00:00:09.286,163] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 2
--- 47 messages dropped ---
[00:00:09.313,873] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
--- 13 messages dropped ---
[00:00:09.313,873] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.314,666] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.314,697] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.315,246] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.315,246] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.315,826] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.315,856] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.316,436] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.316,436] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.317,138] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.317,138] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.317,901] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.317,901] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.318,634] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.318,634] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.319,213] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.319,213] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.319,976] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.319,976] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.320,709] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.320,709] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.321,289] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 3
[00:00:09.321,289] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 3, size: 32
[00:00:09.321,350] <dbg> agps.supl_logger: No integrity data available
[00:00:09.322,296] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 4
[00:00:09.322,326] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 4, size: 8
[00:00:09.323,059] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 7
[00:00:09.323,059] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 6, size: 144
[00:00:09.323,669] <dbg> nrf9160_gps.agps_write: Sent A-GPS data to modem, type: 8
[00:00:09.323,669] <dbg> agps.inject_agps_type: Injected A-GPS data, type: 7, size: 16
[00:00:09.323,730] <dbg> agps.supl_logger: SUPL POS received
[00GPS_EVT_OPERATION_BLOCKED 
:00:10.323,181] <dbg> agps.supl_logger: read again
[00:00:10.430,084] <dbg> agps.supl_logger: Bytes received: 30, total 30
[00:00:10.430,603] <dbg> agps.supl_logger: ULP ossDecode success, choice 6
[00:00:10.430,664] <dbg> agps.supl_logger: SUPLEND:
[00:00:10.430,725] <dbg> agps.supl_logger: 	Mask: 0
[00:00:10.430,786] <dbg> agps.supl_logger: 	Status: 0
[00:00:10.430,847] <dbg> agps.supl_logger: SUPL END received
[00:00:10.430,938] <dbg> agps.supl_logger: SUPL session internal resources released
[00:00:10.430,969] <dbg> agps.supl_logger: SUPL session finished
[00:00:10.430,969] <inf> agps: SUPL session finished successfully
[00:00:10.431,488] <dbg> nrf9160_gps.gps_thread: Waiting for time window to operate

TracMile GPS Search Crossed 6 Seconds. 

[00:00:14.364,410] <dbg> nrf9160_gps.gps_thread: GPS has time window to operate
[00:00:14.368,499] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:14.368,499] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 14
[00:00:15.256,622] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:15.256,652] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 15
[00:00:16.256,774] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:16.256,774] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 16
[00:00:17.259,002] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:17.259,002] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 17
[00:00:18.256,500] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:18.256,530] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 18
[00:00:19.256,652] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:19.256,683] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 19
[00:00:20.257,293] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:20.257,324] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 20
[00:00:21.257,568] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:21.257,568] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 21
[00:00:22.257,232] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:22.257,232] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 22
[00:00:23.256,469] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:23.256,469] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 23
[00:00:24.256,988] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:24.257,019] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 24
[00:00:25.256,958] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:25.256,958] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 25
[00:00:26.423,004] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:26.423,034] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 26
[00:00:27.425,262] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:00:27.425,262] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 27
GPS_EVT_OPERATION_BLOCKED 
[00:00:28.483,489] <dbg> nrf9160_gps.gps_thread: Waiting for time window to operate
[mqtt_evt_handler:512] default: 9
[mqtt_evt_handler:512] default: 9

TracMile GPS Search Crossed 139 Seconds. 

[00:02:27.456,115] <dbg> nrf9160_gps.gps_thread: GPS has time window to operate
[00:02:27.460,296] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:02:27.460,296] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 147
[00:02:28.456,146] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:02:28.456,146] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 148
[00:02:29.454,742] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:02:29.454,742] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 149
[00:02:30.455,780] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:02:30.455,810] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 150
GPS_EVT_OPERATION_BLOCKED 
[00:02:31.690,460] <dbg> nrf9160_gps.gps_thread: Waiting for time window to operate
[mqtt_evt_handler:512] default: 9

TracMile GPS Search Crossed 195 Seconds. 

[00:03:23.456,848] <dbg> nrf9160_gps.gps_thread: GPS has time window to operate
[00:03:23.461,029] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:03:23.461,059] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 203
[00:03:24.457,427] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:03:24.457,427] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 204
[00:03:25.456,970] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:03:25.456,970] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 205
[00:03:26.457,855] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 0 Using: 0 Unhealthy: 0
[00:03:26.457,855] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 206
GPS_EVT_OPERATION_BLOCKED 
[00:03:27.671,905] <dbg> nrf9160_gps.gps_thread: Waiting for time window to operate

NCS version : 1.7.0

Modem Firmware version: 1.3.1

Device Revision : NRF9160_xxAA_REV2

Board Version : PCA10090

SIM used: iBasis

Thank you !

Regards,

Chetan

Parents
  • Chetan Kale said:
    Thank you!

    My pleasure, Chetan :-) 

    Chetan Kale said:
    Thanks for the response. Please correct me if I am wrong. So you mean the Network connection is weak at the location where I am testing the device ? Or is that is related to MQTT/TCP ? 

    That is a little bit hard for me to say, as it is the network that releases the UE. But the retransmission attempts from the server side might indicate weak signal quality, yes.  

    180	13.792083	10.165.147.123	142.250.138.192	ILP	87	[Malformed Packet]
    181	13.883026	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=1 Ack=36 Win=65535 Len=0
    182	13.901184	142.250.138.192	10.165.147.123	ILP	82	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    183	13.911132	10.165.147.123	142.250.138.192	ILP	106	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    184	14.014099	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=0
    185	14.157135	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    186	14.381530	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [PSH, ACK] Seq=739 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    187	14.381988	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=1447 Win=5664 Len=0
    188	14.541534	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [ACK] Seq=1447 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    189	14.686645	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    190	14.687133	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=2863 Win=5664 Len=0
    191	14.766113	142.250.138.192	10.165.147.123	ILP	294	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    192	14.909668	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=708
    193	14.910125	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    194	15.069702	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [ACK] Seq=1447 Ack=90 Win=65535 Len=708
    195	15.070129	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#1] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    196	15.267150	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708
    197	15.267425	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#2] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    198	15.343231	142.250.138.192	10.165.147.123	TCP	294	[TCP Spurious Retransmission] 7276 → 64290 [PSH, ACK] Seq=2863 Ack=90 Win=65535 Len=242
    199	15.343414	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#3] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    200	16.030242	142.250.138.192	10.165.147.123	ILP	82	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    201	16.042724	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [FIN, ACK] Seq=90 Ack=3135 Win=6342 Len=0
    202	16.099273	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=3135 Ack=91 Win=65535 Len=0
    203	16.112152	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [FIN, ACK] Seq=3135 Ack=91 Win=65535 Len=0
    204	16.112304	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=91 Ack=3136 Win=6341 Len=0
    205	18.192321			LTE RRC DL_DCCH	26	RRCConnectionRelease [cause=other]
    206	19.597137			AT	23	Rcvd AT Command: +CSCON: 0  

    Chetan Kale said:
    Also, What shall I do to make it more robust that I can assure that there is a weak network or network failure occurred? 

    I honestly cannot tell you that, as it depends on a lot of environmental factors and how the antenna of the UE is designed. One of those factors is in which surrounding the device is located and how fast it moves. It is to be expected that the signal quality varies, a stable network connection is probably only possible to achieve in test chambers or close to a cell tower.  

    Cheers, 

    Markus 

Reply
  • Chetan Kale said:
    Thank you!

    My pleasure, Chetan :-) 

    Chetan Kale said:
    Thanks for the response. Please correct me if I am wrong. So you mean the Network connection is weak at the location where I am testing the device ? Or is that is related to MQTT/TCP ? 

    That is a little bit hard for me to say, as it is the network that releases the UE. But the retransmission attempts from the server side might indicate weak signal quality, yes.  

    180	13.792083	10.165.147.123	142.250.138.192	ILP	87	[Malformed Packet]
    181	13.883026	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=1 Ack=36 Win=65535 Len=0
    182	13.901184	142.250.138.192	10.165.147.123	ILP	82	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    183	13.911132	10.165.147.123	142.250.138.192	ILP	106	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    184	14.014099	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=0
    185	14.157135	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    186	14.381530	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [PSH, ACK] Seq=739 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    187	14.381988	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=1447 Win=5664 Len=0
    188	14.541534	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [ACK] Seq=1447 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    189	14.686645	142.250.138.192	10.165.147.123	TCP	760	7276 → 64290 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708 [TCP segment of a reassembled PDU]
    190	14.687133	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=2863 Win=5664 Len=0
    191	14.766113	142.250.138.192	10.165.147.123	ILP	294	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    192	14.909668	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [ACK] Seq=31 Ack=90 Win=65535 Len=708
    193	14.910125	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    194	15.069702	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [ACK] Seq=1447 Ack=90 Win=65535 Len=708
    195	15.070129	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#1] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    196	15.267150	142.250.138.192	10.165.147.123	TCP	760	[TCP Spurious Retransmission] 7276 → 64290 [PSH, ACK] Seq=2155 Ack=90 Win=65535 Len=708
    197	15.267425	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#2] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    198	15.343231	142.250.138.192	10.165.147.123	TCP	294	[TCP Spurious Retransmission] 7276 → 64290 [PSH, ACK] Seq=2863 Ack=90 Win=65535 Len=242
    199	15.343414	10.165.147.123	142.250.138.192	TCP	52	[TCP Dup ACK 193#3] 64290 → 7276 [ACK] Seq=90 Ack=3105 Win=6372 Len=0
    200	16.030242	142.250.138.192	10.165.147.123	ILP	82	[UNKNOWN PER: too long integer(per_normally_small_nonnegative_whole_number)][Malformed Packet]
    201	16.042724	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [FIN, ACK] Seq=90 Ack=3135 Win=6342 Len=0
    202	16.099273	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [ACK] Seq=3135 Ack=91 Win=65535 Len=0
    203	16.112152	142.250.138.192	10.165.147.123	TCP	52	7276 → 64290 [FIN, ACK] Seq=3135 Ack=91 Win=65535 Len=0
    204	16.112304	10.165.147.123	142.250.138.192	TCP	52	64290 → 7276 [ACK] Seq=91 Ack=3136 Win=6341 Len=0
    205	18.192321			LTE RRC DL_DCCH	26	RRCConnectionRelease [cause=other]
    206	19.597137			AT	23	Rcvd AT Command: +CSCON: 0  

    Chetan Kale said:
    Also, What shall I do to make it more robust that I can assure that there is a weak network or network failure occurred? 

    I honestly cannot tell you that, as it depends on a lot of environmental factors and how the antenna of the UE is designed. One of those factors is in which surrounding the device is located and how fast it moves. It is to be expected that the signal quality varies, a stable network connection is probably only possible to achieve in test chambers or close to a cell tower.  

    Cheers, 

    Markus 

Children
  • But the retransmission attempts from the server side might indicate weak signal quality, yes.

    Okay, then here I will assume its a problem with MQTT/TCP. Also let me share some more traces with you as we faced some issues while generating Modem traces and will come to know if the similar issues repeats when we found "111" at AT+CEREG. 

    I honestly cannot tell you that, as it depends on a lot of environmental factors and how the antenna of the UE is designed. One of those factors is in which surrounding the device is located and how fast it moves. It is to be expected that the signal quality varies, a stable network connection is probably only possible to achieve in test chambers or close to a cell tower.

    Actually the modem traces which I shared with you is from the nRF9160 Dev Kit which is placed near the window at same location for continuous testing. But if it is related to signal quality then is there any AT command which tells the Signal Quality status so that if device found less signal quality the I can take precautionary measures ?

    Regards,

    Chetan 

Related