[BC660K] network registration takes long time

Technical Subjects
1

I am based in Brazil, and the NB-IoT band I am using here is the 28.

So, I am using this AT command:

AT+QIBAND=1,28

The module sometimes takes a long time to get the network registration done, it varies from just a few seconds after startup to up to 5 minutes as I’ve seen so far.

Because our firmware has a reset() call in some cases (watchdog, for example), then the process of registering into the network starts again, and it can take a long time again.

My question is: is there a way to store the network registration information or something persistent after the module network registration is done? I’ve heard that CFUN=0 does the trick, but I could not find any mention of this in the documentation.

2

yes,The historical frequency will be saved
AT+QCSEARFCN=0 //clean historical frequency(EARFCN)

1 Like
3

Thank you @herbert.pan-Q for the help.

I just got a little confused, please help me out to make sure I understood.

By checking the command you mentioned on the AT commands manual, AT+QCSEARFCN, it tells that:

This command clears the stored EARFCN list for the UE

By “clearing the list”, I got confused, because if it clears the list, wouldn’t the network registration be slower, because the UE would need to re-scan the frequencies again?

Did I get it right? Sorry for the confusion.

4

Yes, your understanding is correct. UE needs to rescan the frequency points and search the network

1 Like
5

I am facing the same problem with BC92.
Sometimes it takes too long to connect to the network.

QCSEARFCN does not solve the problem.

Did you fix the problem?

6

You need to grab the debug Log for analysis. I have sent the tools and documents to your email

1 Like
7

I’m going to post here an answer that I sent to another user privately, but since this is an issue for more people, I’m going to make it posted here to be visible to anyone.

So, basically, the first symptom of taking much time to register to the network was because I was using a broad range of frequencies via AT command AT+QBAND=x,y, for example.

So, I narrowed it down to the bands that my SIM Card uses, which here in Brazil is specifically the Band 28, so, in my case, I use AT+QBAND=1,28.

This simple step of searching only the band that your SIM Card uses speed things up in most cases, but it is not 100% sure, but in our experiments we get in 90% of the cases less than 5 seconds to connect to the network.

One thing we did wrong, as I remember on the post you just mentioned, was a wrong understanding we had from some old BC module we used in the past, which was the command AT+QCSEARFCN=0.
For some reason I do not remember now, we added some code in our firmware that had some logic that caused some problems related to the time the network takes to register, which was something like this:

  1. Set the exact QBAND to be used
  2. Then launch the connection via AT+CGATT=1
  3. Then, we should wait for the URC that indicates the connection was complete +CEREG=1, and calculate how much time it took from step (2) to (3)
  4. If it took more than 60 seconds, we disconnect (AT+CFUN=0) and run again step (3).
  5. If it took less than 60 seconds, then we are done.

So, at step (4), we thought at some point that running AT+CFUN=0 would save the scanned frequencies on the flash, and then the next reconnection would take just a few seconds, but we were wrong about this understanding, and it caused the complete opposite. If you just got a connection, ask to disconnect, and try to connect again, the reconnection would take much time in most of the cases. So, we just got rid of this algorithm, which was bad for the connection attempt.

Another thing I remember from the very beginning of the project was related to how we flash the Firmware, that one also improved a lot.
We do the flashing via the command line, not via the GUI. The GUI is just a nice interface, but at the end, it runs the following command lines:

flashtoolcli1.exe --cfgfile flash_download.ini --port="COM19" probe
flashtoolcli1.exe --skipconnect 1 --cfgfile flash_download.ini --port="COM19" flasherase 0x350000 0x54000
flashtoolcli1.exe --skipconnect 1 --cfgfile flash_download.ini --port="COM19" flasherase 0x3BB000 0x1000
flashtoolcli1.exe --skipconnect 1 --cfgfile flash_download.ini --port="COM19" flasherase burn

But, there is this erase step, which erases that particular memory related to the frequencies, and because we erase this, the connection takes much time in most cases.

So, if you are still developing your firmware, to avoid these long waiting time for network connection caused due to the fact that the GUI is erasing the stored frequencies, you can simply run these two commands instead:

flashtoolcli1.exe --cfgfile flash_download.ini --port="COM19" probe
flashtoolcli1.exe --skipconnect 1 --cfgfile flash_download.ini --port="COM19" flasherase burn

That solved the main issue we had at the beginning of the project, which was that the network always took a long time to connect (100% of the time > 1 minute). With this solution, we got an improvement to just a few seconds when the correct QBAND is set.