Hl7800 - at+knwscancfg

IoT Modules HL78
1

Hi,
I’m trying to configure the network scan policy on HL7800 with exponential back-off:
AT+KNWSCANCFG=1,1,300,3600
The result is depicted below - it seems to never increase the back-off intervall:

image
image1225×457 5.78 KB

Am I doing something wrong?
I have purposely configured the bands to something our operator don’t use for this test.
Regards
Martin

EDIT:
The FW is 4.4.6

2

Another thing I can’t wrap my head around is the +CEREG URCs.
In the following picture I believe the modem wakes up to to a network scan:

image
image1599×711 25.9 KB

It seems to be searching 2 bands for a total of ~30s, but all of the URCs occur in the last 11ms.
Shouldn’t it report “+KSUP” when the modem first wakes up, then “+CEREG: 2” before/while searching and then report “+CEREG: 0” right before going back to hibernate?
Regards
Martin

3

Hi Martin,

With that configuration, the device will search with +CEREG: 2 and then +CEREG: 0, after 300s device starts the second search with + CEREG: 2 and +CEREG: 0, after 300 + 2^1 s device starts the third search, after 300+2^2 s device starts the fourth search… So the first capture is correct .
The time between CEREG: 2 to CEREG: 0 is a few seconds.

What is the configuration with PSM? If the device is still searching network, it’s only enter to Lite hibernate mode, not Hibernate. Device will wake up to search network when the interval is reached (300+2^x), if the timer reaches 3600, the interval for searching will repeat every 3600s.

Thanks,

4

Thanks for your reply,
First issue:
Okay, I would assume that the back-off period would increase with a factor of 2 with exponential back-off:

1: 300 * 2^0
2: 300 * 2^1
…

Wouldn’t this be more useful?

If it works the way that you described it then it’s not really exponential since the factor between 2 different attempts is not the same.

Second issue:
As I tried to depict in the image is that the time between “+CEREG: 0” and “+CEREG: 2” is only 11ms.
The PSM settings shouldn’t matter since the modem is never connected, right?
It is set up like this however:

AT+CPSMS=1,00111000,00000100
AT+KSLEEP=1,2,0

Regards
Martin

5

Hi Martin,
Exponential scheme works by adding Tmin+2exponent where exponent is equal to scan times.
So the period should be:

  • 1: 300s+ 2^0
  • 2: 300 +2s
  • 3: 300 + 4s
    …
  • n: 3600
  • n+1: 3600
    …
    From the second issue, I saw that the time between CEREG: 2 to CEREG: 0 is about 5s ( this is the time for searching, after CEREG: 0 -> searching is completed). Device needs sometime to boot up from Lite hibernate, it is the reason why the time in the picture is about 30s ( it is not 30s for searching, 30s is for booting up and searching and preparing for lite hibernate again ). I didn’t see any other CEREG: 2 . So why you count the time between +CEREG: 0 and CEREG: 2 is 11s?

Thanks,

6

Hi again,

First issue:
I understand how it works per your explanation, all I’m saying is that the way it works it is not really useful nor an exponential back-off.

Second issue:
The unit from the image is in milliseconds. So there is 5 milliseconds between the output of “+CEREG: 2” and “+CEREG: 0”. The selection of the image shows the span from the first output of “+CEREG: 2” and the last output of "+KSUP:0 ". So the questions remain:

  1. Why isn’t the URC “+CEREG: 2” outputted in the start of the network scan, but in the end?
  2. Why is the URC “+KSUP: 0” after both “+CEREG: 2” and “+CEREG: 0”

Regards
Martin

7

Hi Martin,
Yes, my mistake, the time between CEREG: 2 and CEREG: 0 is 5 ms

  1. Why isn’t the URC “+CEREG: 2” outputted in the start of the network scan, but in the end?

–> from your capture:
754960 +CEREG: 2 —> start searching
754965 +CEREG: 0 ----> complete searching
754971 +KSUP: 0
Device wakes up and search network in a few ms, and wait for the next searching (300+2^x)

  1. Why is the URC “+KSUP: 0” after both “+CEREG: 2” and “+CEREG: 0”
    –> KSUP is belonged to KSREP command. By default, the timeout is 4000 (ms), in this time , the subsystem events for network searching (CEREG) could be displayed first.
    If you want KSUP is displayed first, you can set up the timeout in KSREP to 0.
    image
    image1236×398 39.1 KB

Thanks,

8

Hi,

  1. But if searching is scanning for network is done in 5 ms, what has it been doing for ~30 seconds before that?
    As you can see in the current-consumption graph, all of the output is done in the last 11 ms before entering (lite) hibernate.
  2. That timeout parameter seems to be new in the at-command interface guide release yesterday - I will look into that.

Thanks
Martin

9

Hi Martin,
Sorry for late response. I have just checked our modules and don’t capture your issue.
Could you help to reboot device and check again? Beside that, could you help to use other terminal to capture the AT log?
I used teraterm and the time between CEREG: 2 to CEREG: 0 is 4s at least, and if I configure many bands, the searching time could be over 10s.

[2020-08-11 16:04:26.549] at+i9
[2020-08-11 16:04:31.834] HL7800.4.4.6
[2020-08-11 16:04:31.834] HL78xx.4.4.6.0.RK_02_01_02_00_88.20200410
[2020-08-11 16:04:31.834] 2020/04/10 18:01:58
[2020-08-11 16:04:31.834] IMEI-SV: 0044024600289409
[2020-08-11 16:04:31.834] Legato RTOS: 18.09.4.ALT1250.rc3 2020/03/02 10:50:25
[2020-08-11 16:04:31.834] atSwi: 30.00
[2020-08-11 16:04:31.834] UBOOT: 01.03
[2020-08-11 16:04:31.834] Apps: RKAPP_02_01_02_00_80__b8247bc6f15eaf43cfdf7605486de028995374aa
[2020-08-11 16:04:31.834] MAC: ALT1250_02_01_02_00_81_FW
[2020-08-11 16:04:31.834] PHY: 12.50.228224
[2020-08-11 16:04:31.834] PMP: 228753
[2020-08-11 16:04:31.834] SBUB: 0
[2020-08-11 16:04:31.834] SBFW: 0
[2020-08-11 16:04:31.834] RPuK:
[2020-08-11 16:04:31.834] FPuK:
[2020-08-11 16:04:31.834] RBUB: 0
[2020-08-11 16:04:31.834] RBFW: 0
[2020-08-11 16:04:31.834]
[2020-08-11 16:04:31.834] OK
[2020-08-11 16:04:35.399]
[2020-08-11 16:05:07.320] +CEREG: 2
[2020-08-11 16:05:14.616]
[2020-08-11 16:05:14.616] +CEREG: 0
[2020-08-11 16:09:07.548] at+cfun=1,1
[2020-08-11 16:09:11.164] OK
[2020-08-11 16:09:15.118]
[2020-08-11 16:09:15.118] +WDSI: 0
[2020-08-11 16:09:15.118]
[2020-08-11 16:09:15.118] +KSUP: 0
[2020-08-11 16:09:17.919]
[2020-08-11 16:09:17.919] +CEREG: 2
[2020-08-11 16:09:18.878]
[2020-08-11 16:09:18.878] +SIM: 1
[2020-08-11 16:09:19.310] at+ksleep=1,2,0
[2020-08-11 16:09:23.694] OK
[2020-08-11 16:09:25.423]
[2020-08-11 16:09:25.423] +CEREG: 0
[2020-08-11 16:11:07.817]
[2020-08-11 16:11:07.817] +CEREG: 2
[2020-08-11 16:11:07.817]
[2020-08-11 16:11:07.817] +WDSI: 0
[2020-08-11 16:11:07.817]
[2020-08-11 16:11:07.817] +KSUP: 0
[2020-08-11 16:11:07.833]
[2020-08-11 16:11:07.833] +SIM: 1
[2020-08-11 16:11:11.881]
[2020-08-11 16:11:11.881] +CEREG: 0
[2020-08-11 16:12:54.033]
[2020-08-11 16:12:54.033] +CEREG: 2
[2020-08-11 16:12:54.033]
[2020-08-11 16:12:54.033] +WDSI: 0
[2020-08-11 16:12:54.033]
[2020-08-11 16:12:54.033] +SIM: 1
[2020-08-11 16:12:59.307]
[2020-08-11 16:12:59.307] +CEREG: 0
[2020-08-11 16:12:59.322]
[2020-08-11 16:12:59.322] +KSUP: 0
[2020-08-11 16:14:42.470]
[2020-08-11 16:14:42.470] +CEREG: 2
[2020-08-11 16:14:42.470]
[2020-08-11 16:14:42.470] +WDSI: 0
[2020-08-11 16:14:42.470]
[2020-08-11 16:14:42.470] +SIM: 1
[2020-08-11 16:14:47.744]
[2020-08-11 16:14:47.744] +CEREG: 0
[2020-08-11 16:14:47.758]
[2020-08-11 16:14:47.758] +KSUP: 0
[2020-08-11 16:16:32.908]
[2020-08-11 16:16:32.908] +CEREG: 2
[2020-08-11 16:16:32.908]
[2020-08-11 16:16:32.908] +WDSI: 0
[2020-08-11 16:16:32.908]
[2020-08-11 16:16:32.908] +SIM: 1
[2020-08-11 16:16:38.181]
[2020-08-11 16:16:38.181] +CEREG: 0
[2020-08-11 16:16:38.195]
[2020-08-11 16:16:38.195] +KSUP: 0
[2020-08-11 16:18:27.329]
[2020-08-11 16:18:27.329] +CEREG: 2
[2020-08-11 16:18:27.345]
[2020-08-11 16:18:27.345] +WDSI: 0
[2020-08-11 16:18:27.345]
[2020-08-11 16:18:27.345] +SIM: 1
[2020-08-11 16:18:33.304]
[2020-08-11 16:18:33.304] +CEREG: 0
[2020-08-11 16:18:33.320]
[2020-08-11 16:18:33.320] +KSUP: 0
[2020-08-11 16:20:30.470]
[2020-08-11 16:20:30.470] +CEREG: 2
[2020-08-11 16:20:30.470]
[2020-08-11 16:20:30.470] +WDSI: 0
[2020-08-11 16:20:30.470]
[2020-08-11 16:20:30.470] +SIM: 1
[2020-08-11 16:20:35.741]
[2020-08-11 16:20:35.741] +CEREG: 0
[2020-08-11 16:20:35.757]
[2020-08-11 16:20:35.757] +KSUP: 0
Note: I configured the KNWSCANCFG=1,1,100,600
If the issue is still re-producible, please re-flash the firmware and check.

Thanks,

10

Hi and thank you for your answer,

I did some more testing regarding this issue, and it seems to depend on if the wakeup-signal is asserted or not.
If the wakeup-signal is asserted it works as per your output, but if it’s not then both +cereg:2 and +cereg:0 after the scanning is completed.

An other thing I cant wrap my head around is why any “AT+CREG?” polling during the scanning will result in “0”, shouldn’t it respond with “2” as well?
This scenarios is depicted in the following image (this is from when the wake-up signal is asserted):

image
image945×980 32.5 KB

Transcript from the same image where polling “AT+CREG?” results in “0”:

34361 - 2020-08-11T13:27:24 - +CEREG: 2
35112 - 2020-08-11T13:27:24 - AT+CREG?
35114 - 2020-08-11T13:27:24 -
35115 - 2020-08-11T13:27:24 - +CREG: 0,0
35115 - 2020-08-11T13:27:24 -
35116 - 2020-08-11T13:27:24 - OK
36124 - 2020-08-11T13:27:25 - AT+CREG?
36126 - 2020-08-11T13:27:25 -
36127 - 2020-08-11T13:27:25 - +CREG: 0,0
36127 - 2020-08-11T13:27:25 -
36127 - 2020-08-11T13:27:25 - OK
37136 - 2020-08-11T13:27:26 - AT+CREG?
37136 - 2020-08-11T13:27:26 -
37138 - 2020-08-11T13:27:26 - +CREG: 0,0
37138 - 2020-08-11T13:27:26 -
37138 - 2020-08-11T13:27:26 - OK
38148 - 2020-08-11T13:27:28 - AT+CREG?
38148 - 2020-08-11T13:27:28 -
38150 - 2020-08-11T13:27:28 - +CREG: 0,0
38151 - 2020-08-11T13:27:28 -
38151 - 2020-08-11T13:27:28 - OK
39160 - 2020-08-11T13:27:29 - AT+CREG?
39160 - 2020-08-11T13:27:29 -
39162 - 2020-08-11T13:27:29 - +CREG: 0,0
39163 - 2020-08-11T13:27:29 -
39163 - 2020-08-11T13:27:29 - OK
40172 - 2020-08-11T13:27:30 - AT+CREG?
40173 - 2020-08-11T13:27:30 -
40174 - 2020-08-11T13:27:30 - +CREG: 0,0
40174 - 2020-08-11T13:27:30 -
40175 - 2020-08-11T13:27:30 - OK
41183 - 2020-08-11T13:27:31 - AT+CREG?
41185 - 2020-08-11T13:27:31 -
41186 - 2020-08-11T13:27:31 - +CREG: 0,0
41186 - 2020-08-11T13:27:31 -
41186 - 2020-08-11T13:27:31 - OK
42195 - 2020-08-11T13:27:32 - AT+CREG?
42197 - 2020-08-11T13:27:32 -
42198 - 2020-08-11T13:27:32 - +CREG: 0,0
42198 - 2020-08-11T13:27:32 -
42198 - 2020-08-11T13:27:32 - OK
43207 - 2020-08-11T13:27:33 - AT+CREG?
43209 - 2020-08-11T13:27:33 -
43210 - 2020-08-11T13:27:33 - +CREG: 0,0
43210 - 2020-08-11T13:27:33 -
43210 - 2020-08-11T13:27:33 - OK
44219 - 2020-08-11T13:27:34 - AT+CREG?
44219 - 2020-08-11T13:27:34 -
44221 - 2020-08-11T13:27:34 - +CREG: 0,0
44222 - 2020-08-11T13:27:34 -
44222 - 2020-08-11T13:27:34 - OK
45231 - 2020-08-11T13:27:35 - AT+CREG?
45231 - 2020-08-11T13:27:35 -
45233 - 2020-08-11T13:27:35 - +CREG: 0,0
45233 - 2020-08-11T13:27:35 -
45234 - 2020-08-11T13:27:35 - OK
46243 - 2020-08-11T13:27:36 - AT+CREG?
46244 - 2020-08-11T13:27:36 -
46245 - 2020-08-11T13:27:36 - +CREG: 0,0
46245 - 2020-08-11T13:27:36 -
46246 - 2020-08-11T13:27:36 - OK
47254 - 2020-08-11T13:27:37 - AT+CREG?
47256 - 2020-08-11T13:27:37 -
47257 - 2020-08-11T13:27:37 - +CREG: 0,0
47257 - 2020-08-11T13:27:37 -
47258 - 2020-08-11T13:27:37 - OK
48266 - 2020-08-11T13:27:38 - AT+CREG?
48268 - 2020-08-11T13:27:38 -
48269 - 2020-08-11T13:27:38 - +CREG: 0,0
48269 - 2020-08-11T13:27:38 -
48269 - 2020-08-11T13:27:38 - OK
48297 - 2020-08-11T13:27:38 -
48298 - 2020-08-11T13:27:38 - +CEREG: 0

Another question:
It seems from you output that your module only scans for network for about ~5 seconds whereas my module scans for network for ~14 seconds. Is there any command to control that behaviour?

EDIT: The module is configured to use only one band in this test
Regards
Martin

11

Hi Martin,
For HL7800, the module first tries to connect to EPS bearer (4G). So, it sends +CEREG: 2 indication to the user. The value of +CREG: remains 0 as it is searching first for 4G. If there is EPS bearer, the CREG will be started.
For your case, if you set the band that no operator is using, CREG will not be started (because no EPS bearer is available).
For the searching time, it is depend on the configured band. Example: if the frequency of band is 700-800MHz, the searching time is about 4-8s. If the frequency is about 1800MHz, the searching time is about 10-20s. The higher frequency the higher time for searching.

Thanks.

12

Hi,
Thanks for the clarification regarding creg and cereg, and the searching time.
Regarding the output of the URC +CEREG:2/0 after the scanning completed - what was the state of the wake-up pin during your test?

Thanks
Martin

13

Hi Martin,
The timestamp of the outputs are correct for both status of wake-up pin. But remember that if the wake-up pin is not asserted, your device does not go to low power mode.
Did you try with other tool to get the output of UART?

Thanks,

1 Like
14

Hi,
The wake-up pin should be deasserted for the device to be able to enter low power mode, right?
Since I got the “correct” output when having the wake-up pin asserted, I doubt it’s my tool that causes the issue - I will try with a different tool nonetheless. Ill get back to you with the result.

Regards