Hi,
I have an issue with CEREG command when parsing the response while device is not registered.
Response contains extra comma when using n >= 3.
AT+CEREG=3 // also happens with n = 4 / n = 5
OK
AT+CEREG?
+CEREG: 3,0, , , , ,0,0
OK
When receiving response and device is registered on network, this does not happen
+CEREG: 5,1,“283C”,“000172B7”,9,0,0
This is not a problem. When n>=3, BC66 will report some information, but BC66 is not registered to the network, so it can only report some empty.
I understand that, but when I set n to 3 I am expecting 7 fields from the response delimited with 6 commas.
I get response with 7 commas which is inconsistent with result code explained in AT Commands Manual.
When sending AT+CEREG? read command, I received the response +CEREG: 3,0, , , , ,0,0
First value is n, in this case 3
Comma
Second value is stat, in this case 0
Comma
Third value is empty (this would be tac)
Comma
Fourth value is empty (this would be ci)
Comma
Fifth value is empty (this would be AcT)
Comma
Sixth value is empty (???) // This is where I expect cause_type
Comma
Seventh value is 0
Comma
Eight value is 0
So I am having an extra comma there, or am I missing something?
You are mixing response to AT+CEREG? and +CEREG unsolicited message. The former has one more field - current CEREG settings, while the latter does not have it. In the AT commands manual this value is referred as <n>.
So you first example is:
AT+CEREG?
+CEREG: ,,,…
and the second is:
+CEREG: ,,…
It is a bit confusing, but to properly parse +CEREG message you have to count number of fields and then you know which one to use. Otherwise you may get (in very rare case) two +CEREG messages as a reply to AT+CEREG? - one being the reply and the other being unsolicited message. This could happen if just in that moment network registration status changes.
Or, you could simplify it by looking for quotes in TAC and cellid fields.
Here is the excerpt from the document that is preceeding the one you’ve posted:
Both examples are responses, not URC. In the second example, n was 5.
Okay, so here is a table how I understand the CEREG command. R in column header is standard response, and URC is unsolicited result.
Coming back to my original question, even if that was URC, it would make less sense: 3 would be stat value (REGISTRATION_DENIED) which I’ve never received. and tac would be 0 which is not a string.
Using this table, can you parse this in any reasonable way? Using your logic, number of commas would lead me to parse this as n=4 or n=5 URC, but even then parameters don’t fit.
I’m pretty sure this is a normal response when n=3, but this comma should not be there.
@dev1 You’re right, I haven’t noticed it so far. When TAC/cellid are not filled, there is one more comma than expected. What FW version are you using? This issue seems to be fixed in BC66NBR01A11, even though it is not mentioned in release notes.
I don’t know which exact version is on the module, but AT+CGSN=3 returns value 10. If that’s not the latest, version where can I obtain FW you’ve mentioned?
AT+CGMR
To get new FW (if older than BC66NBR01A11) contact your FAE.
