HL8548 5.5.22 not honouring +COPS format selection

IoT Modules Legacy HL Series
1

Hi,
I issue a +COPS=3,2 to set the format value to numeric but a subsequent +COPS? still returns the operator in alpha format.
This issue started in fw 5.5.22; previously in 5.5.18 it worked fine.

A full network scan with +COPS=? shows all operators alpha and numeric info, so I know the module has what I need!

Does another command have to be issued? Can anyone reproduce the fault I’m seeing?

I query the operator code to know what APN info to submit, which annoys me. Is there a better way of determining APN info than keeping a table and setting for the specific operator?

2

Does anybody else have this issue, or can someone with a HL8548 confirm this behaviour? Is it only 5.5.22 that does this?

3

Hi,

This should work as per the below.

at+cops?
+COPS: 0,0,"vodafone UK",2

OK
at+cops=3,2
OK
at+cops?
+COPS: 0,2,"23415",2

OK
at+cgmr
RHL85xx.5.5.22.0.201603171544.x6250_3

OK

Re the APN point, for 2G and 3G you have to keep a table, there is no way for the unit to determine what it should use, this is down to the application to know what APN it is subscribed to. On LTE this is different and the network will tell it on attach the APN to use.

Regards

Matt

4

Hi Matt,

It should work like that but doesn’t. I got hold of a dev board and tried upgrading previous 5.5.18 modules that worked, and downgraded new 5.5.22 ones that didn’t, and found it is module specific, not firmware. Can you think of any other setting that might be causing these modules to ignore +COPS=3,2 (or hear it, as confirmed by the ‘2’ in +COPS? reply, but not return the numeric operator? Another clue is that the alpha operator returned is NOT that from the network (as seen by +COPS=?), rather the one stored in the +COPN table, whereas a good module returns the alpha operator it receives from the network.

+nvrst=2 OK
                                                                            
+PBREADY
+NVBU_IND: 0,1,"2004/01/01 00:02:53","RHL85xx.5.5.22.0.201603171544.x6250_3"
+NVBU_IND: 0,2,"2004/01/01 00:02:54","RHL85xx.5.5.22.0.201603171544.x6250_3"
  
+cops? +COPS: 0,0,"YES OPTUS",2                                                                               
OK

+cops=3,2 OK
+cops? +COPS: 0,2,"YES OPTUS",2 
OK

+cops=?
+COPS: (2,"Optus AU","Optus","50502",2),(3,"Telstra Mobile","Telstra","50501",2)
,(3,"vodafone AU","voda AU","50503",2),(3,"vodafone AU","voda AU","50503",0)
5

I seem to have a single unit (out of lots) that seems to exhibit this behaviour, there seem to be a couple of tickets internally that can affect this but we are talking about lots of internal parameters set on the unit which should not be affected by normal operation/upgrading.

Where did you get the nvrst command from as its not publicly available and should not be used unless directed by someone from Sierra, its functionality can vary from build to build in terms of the parameters it can reset, this might have caused your issue in the first place (it may well have caused my issue as I put my units through the ringer).

Regards

Matt

6

Hi Matt,

We’ve got 13 units from the same SKU that all seem to have this behaviour. A Sierra engineer is working with me on it, he’s the one who gave me the undocumented +NVRST as part of diagnostics.
Since then he’s given another undocumented AT command, +XCOPS=0, which directly gives the numeric operator even on these modules. Waiting to hear back if this is good for a permanent workaround!

So is your module the only one from a bunch of the same SKU, and did it always exhibit the behaviour or do you suspect it was a setting that got changed as part of your wringing?

7

Hi,

No I collect my units ver a period of time and so they are all almost certainly not the same SKU (some are even pre production. if you get a funny behaviour in one of my units it is almost impossible to trace it back to something specific.

Suggest you work with the FAE in question.

FYI any at+x commands are Intel specific ones in that they are contained in the firmware Intel give us as part of the stack, some we expose (which means we have to validate them, others we do not (which means we do not).

Regards

Matt

8

Hi Matt,

The fix is in - +XATTMODE=0 then a +CPOF reset.
Any idea what was actually going on? What does +XATTMODE do exactly?

Good to know re +X commands - I was considering just using +XCOPS but this could cause issues down the track if discontinued or changed.

We’ll probably issue this command manually to the modules from this SKU during testing, luckily it’s only a small number.

Also, is +CPOF the best way to reset the module? We’ve been using +CFUN=1.

Alex

9

Alex,

I think this command is to do with AT&T specific settings (as we have to produce a specific build for them), stands to reason as they ask for things which do differ from the rest of the world. How it got into this state

Re the reset it does not really make a difference, the CFUN command tells the unit to specifically reset, the CPOF command tells the software to power off then once it has completed the procedure if you have the on line held low then the hardware tells it to power up again. Both have the same effect, both are controlled in terms of saving data to flash ,etc.

Regards

Matt