HL7812 Automatic Fallback

IoT Modules HL78
1

After realising fallback is not automatically enabled, we have implemented it (using AT+KSELACQ).

We have a current issue with getting DENIED network registration on CAT-M (which is a different topic).

However this issue has allowed us to test the fallback behaviour.

It can take up to 30-minutes before it successfully falls back and registers on either NB-IoT or GSM.

We have two test units running in different geographics areas, ~50 miles apart, with varying network coverage.

What governs the “timeout” to switch RAT?
Whether being DENIED is causing any different behaviour?

2

I have has some clarification on the CAT-M DENIED network registration - the client is using a roaming SIM provider, but O2 have blocked access to their LTEM to negotiate new commercials.

3

Hi @mark.bewley,

  1. What firmware is the HL7812 running?
  2. How are you testing the HL7812’s automatic fallback? Have you tried retesting it on the latest firmware of the HL7812 to see if it still takes 30 minutes?
  3. Please provide some output from the HL7812 along with a list of AT commands with timestamps that you have tested.
ATI9
AT+KCARRIERCFG?
AT+CEREG=2
AT+CREG=2
AT+KSELACQ?

'''
List AT command
'''

Thanks,

4

Quick responses on the settings.

ATI9
HL7812.5.4.10
HL78xx.5.4.10.0.RK_03_02_00_00_22111_001.20220530
2022/05/30 02:04:45
IMEI-SV: 3511444403415711
Legato RTOS: 22.04.0.FreeRTOS.w19 2022/05/04 17:23:01
atSwi: 22.04.0.FreeRTOS.w19
UBOOT: 01.03
Apps: RKAPP_03_02_00_00_22061_001__d21d59a7ccfd13226f6533f3bf8647cb216120a8
MAC: ALT1250_03_02_00_00_22111_NB
PHY: 0.0.306151
PMP: 306188
AISE: ISE2APP_00_00_00_09

SBUB: 1
SBFW: 1
FPuK1: CBF402DD
FPuK2: 4BE7EB7F
RBUB: 0
RBFW: 0
MCU-Disable: 1

OK

AT+KCARRIERCFG?
+KCARRIERCFG: 0

OK
AT+KSELACQ?
+KSELACQ: 1,2,3

OK

I will collect some timestamped logs.

5

I have ran this a few times today, and seems to be a lot quicker.
But still takes several minutes.

[31/05/24 - 15:15:34:949] Terminal ready
[31/05/24 - 15:15:34:949] 
[31/05/24 - 15:15:34:949] +CEREG: 2
[31/05/24 - 15:15:44:075] 
[31/05/24 - 15:15:44:075] +CREG: 0
[31/05/24 - 15:15:46:074] 
[31/05/24 - 15:15:46:074] +CREG: 0
[31/05/24 - 15:17:05:870] 
[31/05/24 - 15:17:05:870] +CREG: 0
[31/05/24 - 15:17:05:886] 
[31/05/24 - 15:17:05:886] +CREG: 2
[31/05/24 - 15:17:09:048] 
[31/05/24 - 15:17:09:048] +CREG: 5,"40B0","01B80E78",7
[31/05/24 - 15:17:09:048] 
[31/05/24 - 15:17:09:048] +CREG: 0
[31/05/24 - 15:17:09:064] 
[31/05/24 - 15:17:09:064] +CREG: 0
[31/05/24 - 15:17:14:163] 
[31/05/24 - 15:17:14:163] +CREG: 2
[31/05/24 - 15:18:34:834] 
[31/05/24 - 15:18:34:834] +CREG: 0
[31/05/24 - 15:18:34:834] 
[31/05/24 - 15:18:34:834] +CREG: 2
[31/05/24 - 15:18:35:567] 
[31/05/24 - 15:18:35:567] +CREG: 3
[31/05/24 - 15:18:35:567] 
[31/05/24 - 15:18:35:567] +CREG: 3
[31/05/24 - 15:18:39:948] 
[31/05/24 - 15:18:39:948] +CREG: 2
[31/05/24 - 15:18:39:948] 
[31/05/24 - 15:18:39:948] +CREG: 0
[31/05/24 - 15:18:39:948] 
[31/05/24 - 15:18:39:948] +CREG: 2
[31/05/24 - 15:18:40:434] 
[31/05/24 - 15:18:40:434] +CREG: 3
[31/05/24 - 15:18:44:963] 
[31/05/24 - 15:18:44:963] +CREG: 3
[31/05/24 - 15:22:47:557] 
[31/05/24 - 15:22:47:557] +CREG: 2
[31/05/24 - 15:22:47:557] 
[31/05/24 - 15:22:47:557] +CREG: 0
[31/05/24 - 15:22:47:557] 
[31/05/24 - 15:22:47:557] +CREG: 2
[31/05/24 - 15:22:56:830] 
[31/05/24 - 15:22:56:830] +CREG: 3
[31/05/24 - 15:22:56:852] 
[31/05/24 - 15:22:56:852] +CREG: 0
[31/05/24 - 15:23:00:509] 
[31/05/24 - 15:23:00:509] +CREG: 2
[31/05/24 - 15:23:08:902] 
[31/05/24 - 15:23:08:902] +CREG: 5,"53F5","00005F92",0
[31/05/24 - 15:23:12:374] 
[31/05/24 - 15:23:12:374] +CREG: 5,"53F5","00005F92",0```
1 Like
6
  1. Investigate Timeout:
  • Consult device documentation for RAT switch timeout settings.
  • If configurable, adjust timeout to a shorter duration (consider network conditions).
  1. Review DENIED Impact:
  • Check if DENIED registration delays fallback initiation by AT+KSELACQ.
  • If so, explore alternative fallback mechanisms that might trigger faster (consult device documentation).
  1. Test Network Coverage:
  • Verify adequate NB-IoT/GSM coverage in both test locations.
  • Insufficient coverage could further delay fallback success.

Consider contacting the device manufacturer for specific guidance on RAT switch behavior and troubleshooting DENIED registration.

7

Thanks @cellphoneareas for the comments, I am working though the problem in a similar methodology.

Currently have a bit of a knowledge gap… haven’t found any timeout info on the recommended hands-off RAT management feature; or whether I should consider doing it ourselves (but would take a lot more coding to achieve a suitable level of intelligence).

Developers forum was my first port of call, and believe it is [based on other threads] monitored by manufacturer technical people.

Then, if required, contacting support - although I would have to look into how.

Regards,
Mark

8

Hi @mark.bewley,

Do you know which band HL7812 is using? If so, can you try setting it to that one band only to see if it reduces the searching time?
Please refer to the AT command AT+KBNDCFG in the HL78xx AT Commands Interface Guide at the following link: HL78xx AT Commands Interface Guide

Thanks,