at+c5greg=2;+c5greg? reports the following data:
+C5GREG: 2,1,"7D0C","4F29B2204",11,4,"01.000001"
The Cell-ID is obvisously wrong, according to TS 127.007:
+C5GREG: <n>,<stat>[,[<tac>],[<ci>],[<AcT>]
,[<Allowed_NSSAI_length>],[<Allowed_NSSAI>]
[,<cause_type>,<reject_cause>]]
...
<tac>: string type; three byte tracking area code in hexadecimal format (e.g. "0000C3" equals 195 in decimal).
<ci>: string type; five byte NR cell ID in hexadecimal format
It is also inconsistent with !NRINFO and !GSTATUS? output:
!GSTATUS:
Current Time: 100327 Temperature: 34
Thermal Mitigation Level: 0
Reset Counter: 1 Mode: ONLINE
System mode: NR5G PS state: Attached
IMS reg state: NOT REGISTERED IMS mode: Normal
IMS Srv State: NO SMS,NO VoIP
NR5G TAC: 007d0c NR5G Cell ID: 880
...
Hi stefanbruens ,
What module type and firmware version are you using? Can you try it with the latest firmware?
This is with the latest FW, 03.09.06.
Reading the report again, it might not be obvious what is expected:
- Missing leading zeros in
+C5GREG output. TS 127.007 specifically mentions “string type; 3 byte … in hexadecimal format (e.g. “0000C3” equals 195 in decimal)”. In contrast, the “Allowed_NSSAI” has just “string type in hexadecimal format”, i.e. no length specified.
- Apparently completely wrong value for “Cell ID”. For ENDC and older standards, the value was e.g. “Cell ID: 01e57310 (31814416)” and matched the
+C*REG output.
(1.) is just an inconvenience. (2.) is a significant problem.
1 Like
@Donald - do you need any further information?
We need consistent results from the various commands, otherwise we have to find some workaround for theses issues.
We would appreciate an answer in a timely manner. Can you please provide a confirmation for the issue, or even better a timeline for a fix?
Hi stefanbruens,
Sierra has been aware of this issue. The dev team is analyzing it.