How to synchronise HL8518 module with a NTP server?

IoT Modules Legacy HL Series
1

Hi,

I’m trying to simply recover time & date with my HL8518 module. Note that in my finale application, the module will provide time & date to the system, not the opposite.

AT+KNTP is not available on HL8518 but it would have been perfect.

AT+CTZU/+CTZR are not really reliable as they depend on NITZ ( <NTP, depends on the network) and that their usage rely on Unsollicited Result Codes which can be difficult to catch and read by a firmware routine.

So is my only option left is to open a TCP/IP or an UDP socket with a NTP server ? It seems very tidious to me.

I’m really surprised about NITZ still being the norm, even though NTP is a much more reliable mechanism for retrieving hour. Unhappily, we don’t want to rely on NITZ as it “depends on the antenna” (ie the network/operator you are connected to) and just give local time.

Thanks in advance for your help & answers :slight_smile:

2

Hi Jalleth,

Yes you can open a TCP/IP socket with a NTP server. But I don’t have the demo for you now.

3

Ok thanks ! I was going to do so.

However, when people open a socket with NTP servers, they seem to choose UDP over TCP/IP.

Do you know why ?

4

Hi Jalleth,
Yes you are right. Need to use UDP on port 123 in order to communicate with the NTP pool.

5

Thank you Sierra_klin2 ! :slight_smile:

I’m going to test that with UDP socket.

6

Ok I just managed to synchronize my HL8518 module. I will describe the big steps here if someone wants to do it in the future :

  • Configure a PDP context and bring it up ( AT+KCNXCFG, AT+KCNXUP). Let’s say that his ID is cnx_id

  • First, configure an UDP session in client mode : AT+UDPCFG = cnx_id, 0, , 0 . Id is udp_id
    The last option is data_mode. I set it to 0 but it’s the default configuration. I recommend to use it that way as AT+KUDPRCV will work correctly like that

  • Send a 48 bytes message to the NTP server “pool.ntp.org” at port 123 (which is the reserved port for NTP). Value of the first byte of the message must be 27 (decimal) / 0x1B (hex), the other bytes remains at 0.
    –> AT + KUDPSND = udp_id, “pool.ntp.org”, 123, 48 and wait for CONNECT
    Why sending that ??? Go to Let’s make NTP client in C to have more precisions :slightly_smiling_face:

  • Check if you have received 48 bytes with +KUDP_DATA // +KUDP_RCV notifications.

  • Retrieve the message with AT+KUDPRCV = udp_id, 48

  • Retrieve the POSIX time and make it human readable : check this again Let’s make NTP client in C
    :blush:

7

Hi Jalleth,

Wow, Great job! Thanks for sharing. :slight_smile:

8

I’ve gone down this same path but I can’t explain the delay I need to insert before the EOF to make it work. Here is with no delay (Unprintable ASCII is in <hex>):

tx: AT&K3<d><a>
rx: <d><a>OK<d><a>
tx: AT+KCNXCFG=1,"GPRS",m2m-east.telus.iot<d><a>
rx: <d><a>OK<d><a>
tx: AT+KCNXTIMER=1,60,1,60<d><a>
rx: <d><a>OK<d><a>
tx: AT+KUDPCFG=1,0,,0<d><a>
rx: <d><a>+KUDPCFG: 1<d><a>
rx: <d><a>+KCNX_IND: 1,4,1<d><a>
rx: <d><a>+KCNX_IND: 1,1,0<d><a>
rx: <d><a>+KUDP_IND: 1,1<d><a>
tx: AT+KUDPSND=1,pool.ntp.org,123,48<d><a>
rx: <d><a>CONNECT<d><a>
tx: <1b><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>--EOF--Pattern--
rx: <d><a>OK<d><a>
rx: <d><a>+KUDP_NOTIF: 1,8<d><a>
rx: <d><a>+KUDP_DATA: 1,48<d><a>
rx: <d><a>+KUDP_RCV: 1,"192.99.2.8",123,48<d><a>
tx: AT+KUDPRCV=1,48<d><a>
rx: <d><a>+CME ERROR: 923<d><a>
tx: AT+KUDPCLOSE=1<d><a>
rx: <d><a>OK<d><a>

Note the “+KUDP_NOTIF: 1,8” which says not enough characters were sent. If I add a delay of 250ms or more before sending the EOF sequence, then I don’t get this and everything runs fine. I am monitoring the pins from the cell modem independently from the driver so I can tell any differences. The link is running at 115200.
Here is the same conversation with only a delay of 500ms added before sending EOF:

tx: AT&K3<d><a>
rx: <d><a>OK<d><a>
tx: AT+KCNXCFG=1,"GPRS",m2m-east.telus.iot<d><a>
rx: <d><a>OK<d><a>
tx: AT+KCNXTIMER=1,60,1,60<d><a>
rx: <d><a>OK<d><a>
tx: AT+KUDPCFG=1,0<d><a>
rx: <d><a>+KUDPCFG: 1<d><a>
rx: <d><a>OK<d><a>
rx: <d><a>+KCNX_IND: 1,4,1<d><a>
rx: <d><a>+KCNX_IND: 1,1,0<d><a>
rx: <d><a>+KUDP_IND: 1,1<d><a>
rx: <d><a>CONNECT<d><a>
tx: AT+KUDPSND=1,pool.ntp.org,123,48<d><a><1b><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
// don't send anything for at least 250ms
tx: --EOF--Pattern--
rx: <d><a>OK<d><a>
rx: <d><a>+KUDP_DATA: 1,48<d><a>
rx: <d><a>+KUDP_RCV: 1,"209.115.181.107",123,48<d><a>
tx: AT+KUDPRCV=1,48<d><a>
rx: <d><a>CONNECT<d><a>
rx: <1c><2><3><e8><0><0><9>#<0><0><5>t<ce>l<0><83><e0><d9><d9><a5><cb><ad><d3><<0><0><0><0><0><0><0><0><e0><d9><db>+<fb>u<e8><15><e0><d9><db>+<fb>x<90><1>--EOF--Pattern--
tx: AT+KUDPCLOSE=1<d><a>
rx: <d><a>OK<d><a>

Having to insert an empirically derived delay doesn’t sit well with me. In my released code I’ve doubled the delay just to add a safety margin. The cell modem is HL8548 with firmware 5.5.18.

The above modem conversation shows all characters exchanged in either printable ASCII or hex code, but some outputs have been split onto separate lines for ease of human parsing. So the letter a would be ‘a’ but a line feed which is ascii code 10 in hex is printed as . All printable ASCII characters are printed including space (32-127).

Can anybody offer guidance to the nature of the delay? Thanks.

9

Hi,

I test without any delay before EOF and it works fine.
Note that no extra <CR/LF> be added at the end of data and EOF.
e.g.
AT+KUDPSND=1,10.10.10.10,5555,10
CONNECT
1234512345–EOF–Pattern–//Should no extra <CR/LF> at the end of EOF.
OK

ATI3
RHL85xx.5.5.18.0.201506301553.x6250_1
OK
AT+KCNXCFG=1,"GPRS",3gnet
OK
AT+KUDPCFG=1,0
+KUDPCFG: 1
OK
+KCNX_IND: 1,4,1
+KCNX_IND: 1,1,0
+KUDP_IND: 1,1
AT+KUDPSND=1,pool.ntp.org,123,48
CONNECT
//NTP_to_send[NTP_to_send.txt|attachment](upload://d3Pqu0eXdTbhcK9tOIMzz1UztwV.txt) (64 Bytes)  with EOF.
OK
+KUDP_DATA: 1,48
+KUDP_RCV: 1,"45.43.30.59",123,48
AT+KUDPRCV=1,48
CONNECT
冂刎特刎i刳嘹x?滾Z刎刎刎刎嘹{陿騭嘹{隁?--EOF--Pattern--
OK
10

Thanks for the reply. I have edited my post to make it clearer that the exchanges have been edited for clarity. I have attempted to display all characters of the exchange so that I know exactly what transpired. Each character is timestamped so that I can also see what inter-character and response times are but that information is only summarized in the text.
It also works if I put the delay between after the CONNECT from the modem and before the data+EOF from the micro. This is what I originally did was delay after getting the CONNECT but I decided to see if I could figure out the critical piece. The data portion can slide around but there needs to be at least 250 ms between CONNECT and EOF. At 115200, each byte takes 86 uS. 250 ms / .086 = 2906 chars. So for larger UDP transfers my bet is this problem won’t show up.

What version of firmware does your modem use?
What baud rate are you using?

11

I used UART@115200 baud rate with RHL85xx.5.5.18.0.201506301553.x6250_1.