BG600 frustration

AMDFX · June 30, 2021, 7:37pm

Hey,

I have worked a lot with Quectel in the past and currently with the BG600 - unfortunately the BG600 works very poorly (with the newest firmware A04).

Problems:

A lot of DNS Errors (565) when request a ntp time or open a TCP socket
Receiving command errors which can only be fixed via module reboot
Implausible behavior when establishing a connection that does not match the documentation

And of course I have samples:

Here a short trace of the DNS error - right from the startup:

RDY

APP RDY

AT

OK

AT+IPR=115200

OK

AT+GMR

BG600LM3LAR02A04

OK

AT+QINISTAT

+QINISTAT: 3

OK

AT+CREG=2

OK

AT+COPS=3,2

OK

AT+QGPSXTRA?

+QGPSXTRA: 1

OK

AT+QCFG=“nwscanmode”,0,1

OK

AT+QCFG=“nwscanseq”,0201,1

OK

AT+QCFG=“iotopmode”,0,1

OK

AT+QCFG=“band”,F,80084,80084

OK

AT+QNWCFG=“hplmnsearch_ctrl”,0

OK

AT+CTZU=0

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+QICSGP=1,1,“wm”

OK

AT+QIACT=1

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+QNTP=1,“time.google.com”,123

OK

+QNTP: 565

What’s wrong here? Why does the module response with 565 (DNS parse fail?)

Also here you can see that the module outputs a pdpdeact. According to the documentation, the PDP context must be closed (QIDEACT).
CREG confirms that there is a connection, I set the APN Config, activate the PDP Context with AT+QIACT=1 and then want to make another NTP request, but it is no longer possible.
Why receive I an error after execute AT+QNTP?
AT+QIGETERROR just response: +QIGETERROR: 572,operation not allowed

Here a short uart trace:
+QIURC: “pdpdeact”,1

AT+QIDEACT=1

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+QICSGP=1,1,“wm”

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+QIACT=1

OK

AT+CREG?

+CREG: 2,5,“C0F8”,“344C01”,8

OK

AT+QNTP=1,“time.google.com”,123

ERROR

And then other problems like stucking a long time at CREG state 2 (searching for operator and try to register… sometimes over 5 minutes. If I reboot the module: It’s fixed instantly and the connection is back very quickly but it can’t be the solution to always reboot the module.

Is there an explanation for these problems? Is the setup wrong? Any ideas?

herbert.pan-Q · July 3, 2021, 3:05am

hi,AMDFX:

AT+CREG?
+CREG: 2,5,“C0F8”,“344C01”,8

Through the results of your query can be seen that your device in the network registration way belongs to roaming,so, it is normal for your device to first register the network for a long time.

AT+QNTP=1,“time.google.com”,123
ERROR

The above error is due to the fact that you are using a domain name. Our reference manual requires you to use an IP address. This may be due to the fact that the module does not support domain name resolution capability.

As for the problem that your registration network takes too long, the main reason is that your SIM card provider now provides roaming service, which affects your registration time. I suggest you change to another local SIM card.

AMDFX · July 4, 2021, 11:08am

Well that doesn’t make sense to me.

Sometimes time.google.com dns is working but not always - so dns is basically supported.
So slow roaming is a BG600 problem? The MC60 is pretty fast, also with Roaming (okay it’s only 2G) but also the BG600 ist fast but just after a fresh startup. It’s only slow after losing the current connection and start’s to re-search and like I said sometimes over 5 minutes. If I do a hard-reset of the bg600 and start fresh again, the roaming is complete after ~30 seconds.

herbert.pan-Q · July 5, 2021, 1:34am

Hi,AMDFX:
I’m sorry I didn’t give a rigorous answer;Our module itself has built-in DNS parsing capabilities,so it can resolve common domain addresses.Is your question caused by the content marked below?

According to your description, your device is slow to register the network for the first time, and faster to register the network later, is that right?If it is the first time to register the network time is longer, it is normal.

AMDFX · July 5, 2021, 2:59pm

If you check out the log above, AT+QIACT=1 is set and I also received the “OK”. So for me it doesn’t make sense why I receive sometimes the DNS parse error.

About the registration speed: It’s the other way around. First time is fast but later it’s getting slow.

AMDFX · July 7, 2021, 7:10am

I found out something else.
If I start the GPS XTRA Feature + GPS, as soon as a connection is signaled by CREG, but the PDP context is not open, the connection breaks down again and again - the module ALWAYS loses the connection (CREG state changes to searching for operator). If I first open the PDP context and then start XTRA + GPS, this doesn’t happen.

Is that a bug? Nowhere in the documentation is it written that a PDP context must be activated before I can start XTRA + GPS, only a connection check with CREG must be carried out: