Trouble with duplicate messages in UDP with HL7588

Hello everyone!

I’m having trouble with a HL7588, I have configured a UDP server to receive and send data to multiple remote stations, when receiving the data everything works fine but everything stops working as I expect when data is sent to a connection, when this happens if the remote connection sends any data this It is reported twice by the UART port of the device. For better context, below I will leave the lists of commands that I currently use and give an example of what is happening to me.

Rx: +CREG: 2
Rx: +CGREG: 2
Rx: +SIM: 1
Rx: +KSUP: 0
Tx: ATE0
Rx: OK
Tx: AT+KSLEEP=2
Rx: OK
Tx: AT+KGSN=0
Rx: +KGSN: 014284008472445
Rx: OK
Tx: ATI0
Rx: HL7588
Rx: OK
Tx: ATI3
Rx: RHL75xx.A.2.15.151600.201809201422.x7160_3
Rx: OK
Rx: +PBREADY
Tx: AT+KSRAT?
Rx: +KSRAT: 7
Rx: OK
Tx: AT+KSRAT=2
Rx: OK
Tx: AT+KSIMDET=1
Rx: OK
Tx: AT+CREG=1
Rx: OK
Tx: AT+CGREG=1
Rx: OK
Tx: AT+KSREP=1
Rx: OK
Tx: AT+CTZU=1
Rx: OK
Tx: AT+CTZR=1
Rx: OK
Tx: AT+KUSBCOMP=0
Rx: OK
Tx: AT+WMUSBVCC=1
Rx: OK
Tx: AT+CGEREP?
Rx: +CGEREP: 0,0
Rx: OK
Rx: +CREG: 1
Rx: +CGREG: 4
Rx: +CTZV: -20,“24/03/11,08:38:43”
Rx: +XNITZINFO: “GMT-05:00”,“24/03/11,08:38:43”
Rx: +CTZDST: 0
Rx: +CGREG: 1
Tx: AT+KBND?
Rx: +KBND: 00000020
Rx: OK
Tx: AT+KPATTERN=3nd0fm3ss4g3
Rx: OK
Tx: AT+KCNXCFG=1,“GPRS”,“apn”,“user”,“password”
Rx: OK
Tx: AT+KUDPCFG=1,1,SERVER_PORT,1
Rx: +KUDPCFG: 1
Rx: OK
Rx: +KCNX_IND: 1,4,1
Tx: AT+KCNXTIMER=1,10,3,0,0
Rx: OK
Rx: +KCNX_IND: 1,1,0
Rx: +KUDP_IND: 1,1
Tx: AT+CSQ
Rx: +CSQ: 7,4
Rx: OK
Tx: AT+COPS?
Rx: +COPS: 0,0,“Movistar”,2
Rx: OK
Tx: AT+KCGPADDR
Rx: +KCGPADDR: 1,“SERVER_IP”
Rx: OK
Tx: AT+KBND?
Rx: +KBND: 00000020
Rx: OK
Tx: AT+CSQ
Rx: +CSQ: 7,4
Rx: OK
Rx: +KUDP_DATA: 1,10,“REMOTE_IP”,REMOTE_PORT,HI Server
Tx: AT+KUDPSND=1,REMOTE_IP,REMOTE_PORT,10
Rx: CONNECT
Tx: Tx:Hi client–EOF–Pattern–
Rx: OK
Rx: +KUDP_DATA: 1,27,“REMOTE_IP”,REMOTE_PORT,second message from client
Rx: +KUDP_DATA: 1,27,“REMOTE_IP”,REMOTE_PORT,second message from client

If anyone has had the same thing happen to them, knows how to fix it or tell me what I’m doing wrong, I would appreciate it!

Tx: AT+KPATTERN=3nd0fm3ss4g3
Tx:Hi client–EOF–Pattern–

Is there any contradiction on these two lines?
Do you see problem with UDP client?

Hello!

client–EOF–Pattern– I use it to refer to 3nd0fm3ss4g3 which was configured in AT+KPATTERN, so what is actually sent in the previous example is “Tx: Hi client\r3nd0fm3ss4g3” to which I receive an OK and that’s it until there It’s going wonderfully, the problem is when more information arrives, since the data is arriving twice and there is nothing in the AT command manual that refers to this case. :pensive:

As for the second question, I have also used the client, but I did not see the error that I mentioned, it only happens when it is configured in server mode.

how about setting data_mode to zero in +KUDPCFG?

I still see you are setting “1” for this data_mode parameter:

AT+KUDPCFG=1,0,SERVER_PORT,1

I apologize, I configured the test incorrectly, this is the configuration you told me and the result I obtained, just like the previous case I have the same result. :pensive:

Rx: +CREG: 2
Rx: +CGREG: 2
Rx: +SIM: 1
Rx: +KSUP: 0
Tx: ATE0
Rx: OK
Tx: AT+KSLEEP=2
Rx: OK
Tx: AT+KGSN=0
Rx: +KGSN: 014284008472445
Rx: OK
Tx: ATI0
Rx: +PBREADY
Rx: HL7588
Rx: OK
Tx: ATI3
Rx: RHL75xx.A.2.15.151600.201809201422.x7160_3
Rx: OK
Tx: AT+KSRAT?
Rx: +KSRAT: 7
Rx: OK
Tx: AT+KSRAT=2
Rx: OK
Tx: AT+KSIMDET=1
Rx: OK
Tx: AT+CREG=1
Rx: OK
Tx: AT+CGREG=1
Rx: OK
Tx: AT+KSREP=1
Rx: OK
Tx: AT+CTZU=1
Rx: OK
Tx: AT+CTZR=1
Rx: OK
Tx: AT+KUSBCOMP=0
Rx: OK
Tx: AT+WMUSBVCC=1
Rx: OK
Tx: AT+CGEREP?
Rx: +CGEREP: 0,0
Rx: OK
Rx: +CREG: 1
Rx: +CGREG: 4
Rx: +CTZV: -20,“24/03/11,12:02:36”
Rx: +XNITZINFO: “GMT-05:00”,“24/03/11,12:02:36”
Rx: +CTZDST: 0
Rx: +CGREG: 1
Tx: AT+KBND?
Rx: +KBND: 00000020
Rx: OK
Tx: AT+KPATTERN=3nd0fm3ss4g3
Rx: OK
Tx: AT+KCNXCFG=1,“GPRS”,“apn”,“user”,“password”
Rx: OK
Tx: AT+KUDPCFG=1,1,SERVER_PORT,0
Rx: +KUDPCFG: 1
Rx: OK
Rx: +KCNX_IND: 1,4,1
Tx: AT+KCNXTIMER=1,10,3,0,0
Rx: OK
Rx: +KCNX_IND: 1,1,0
Rx: +KUDP_IND: 1,1
Tx: AT+CSQ
Rx: +CSQ: 13,2
Rx: OK
Tx: AT+COPS?
Rx: +COPS: 0,0,“Movistar”,2
Rx: OK
Tx: AT+KCGPADDR
Rx: +KCGPADDR: 1,“SERVER_IP”
Rx: OK
Tx: AT+KBND?
Rx: +KBND: 00000020
Rx: OK
Tx: AT+CSQ
Rx: +CSQ: 13,2
Rx: OK
Rx: +KUDP_DATA: 1,22
Rx: +KUDP_RCV: 1,“REMOTE_IP”,REMOTE_PORT,22
Tx: AT+KUDPRCV=1,22
Rx: CONNECT
Rx: HI Server from Client\r3nd0fm3ss4g3
Rx: OK
Tx: AT+KUDPSND=1,REMOTE_IP,REMOTE_PORT,22
Rx: CONNECT
Rx: HI Client from Server\r3nd0fm3ss4g3
Rx: OK
Rx: +KUDP_DATA: 1,27
Rx: +KUDP_RCV: 1,“REMOTE_IP”,REMOTE_PORT,27
Tx: AT+KUDPRCV=1,27
Rx: CONNECT
Rx: second message from client\r3nd0fm3ss4g3
Rx: OK
Rx: +KUDP_DATA: 1,27
Rx: +KUDP_RCV: 1,“REMOTE_IP”,REMOTE_PORT,27
Tx: AT+KUDPRCV=1,27
Rx: CONNECT
Rx: second message from client\r3nd0fm3ss4g3
Rx: OK

does it relate to the size of the data?
for example, what if client sends only 22 bytes (1st message) instead 27 bytes (2nd message)?

Or the issue only happens after server sends out data to client by +KUDPSND?

Does this issue related to the “send size v4” in +KIPOPT command?

I don’t think it is related to the size of the data sent from the client.

I carried out several tests with different sizes of the data sent from the client (REMOTE IP) and they only arrived once.

Rx: +KUDP_DATA: 1,36,“REMOTE_IP”,REMOTE_PORT,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
Rx: +KUDP_DATA: 1,1,“REMOTE_IP”,REMOTE_PORT,0
Rx: +KUDP_DATA: 1,2,“REMOTE_IP”,REMOTE_PORT,01
Rx: +KUDP_DATA: 1,3,“REMOTE_IP”,REMOTE_PORT,012
Rx: +KUDP_DATA: 1,4,“REMOTE_IP”,REMOTE_PORT,0123
Rx: +KUDP_DATA: 1,5,“REMOTE_IP”,REMOTE_PORT,01234
Rx: +KUDP_DATA: 1,6,“REMOTE_IP”,REMOTE_PORT,012345
Rx: +KUDP_DATA: 1,7,“REMOTE_IP”,REMOTE_PORT,0123456
Rx: +KUDP_DATA: 1,8,“REMOTE_IP”,REMOTE_PORT,01234567
Rx: +KUDP_DATA: 1,9,“REMOTE_IP”,REMOTE_PORT,012345678
Rx: +KUDP_DATA: 1,10,“REMOTE_IP”,REMOTE_PORT,0123456789
Rx: +KUDP_DATA: 1,11,“REMOTE_IP”,REMOTE_PORT,0123456789A
Rx: +KUDP_DATA: 1,12,“REMOTE_IP”,REMOTE_PORT,0123456789AB
Rx: +KUDP_DATA: 1,13,“REMOTE_IP”,REMOTE_PORT,0123456789ABC
Rx: +KUDP_DATA: 1,14,“REMOTE_IP”,REMOTE_PORT,0123456789ABCD
Rx: +KUDP_DATA: 1,15,“REMOTE_IP”,REMOTE_PORT,0123456789ABCDE
Rx: +KUDP_DATA: 1,16,“REMOTE_IP”,REMOTE_PORT,0123456789ABCDEF
Rx: +KUDP_DATA: 1,17,“REMOTE_IP”,REMOTE_PORT,0123456789ABCDEFG
Rx: +KUDP_DATA: 1,18,“REMOTE_IP”,REMOTE_PORT,0123456789ABCDEFGH

After that, I sent a single byte from the server to the client and repeated the sending from the client to the server in the same way with a single byte (‘A’) and the error occurred again

Tx: AT+KUDPSND=1,REMOTE_IP,REMOTE_PORT,1
Rx: CONNECT
Tx: A3nd0fm3ss4g3
Rx: OK
Rx: +KUDP_DATA: 1,2,“REMOTE_IP”,REMOTE_PORT,B
Rx: +KUDP_DATA: 1,2,“REMOTE_IP”,REMOTE_PORT,B

so it is clear that the error only occurs when data is sent to the client with the +KUDPSND command.

The validation of the data size for UDP with the +KIPOPT command was done after sending data using +KUDPSND thinking that its default value was being changed, but it is maintained as can be seen.

Tx: AT+KIPOPT?
Rx: +KIPOPT: 0,“TCPC”,1,0,0
Rx: +KIPOPT: 0,“TCPS”,1,0,0
Rx: +KIPOPT: 0,“UDPC”,2,1020,1020
Rx: +KIPOPT: 0,“UDPS”,2,1020,1020
Rx: +KIPOPT: 0,“FTP”,1,0,0
Rx: +KIPOPT: 0,“HTTP”,1,0,0
Rx: +KIPOPT: 0,“HTTPS”,1,0,0
Rx: +KIPOPT: 1,0
Rx: +KIPOPT: 2,0
Rx: +KIPOPT: 3,0,0
Rx: +KIPOPT: 4,2
Rx: OK

you might need to think of some workaround.
For example, immediately close the UDP socket and start it again after sending data to client
Since this is for UDP which is connectionless socket, so this should not bring any bad effect to the client

BTW, have you tried to send the UDP packet from server by another session created by another +KUDPCFG ?

I also thought about looking for a solution to mitigate the problem. What seems curious to me is that it only happens with the IP that is saved when data is sent with the KUDPSND command, since when validating with KUDPCFG it appears as follows:

+KUDPCFG: 1,1,1,SERVER_PORT,1,“REMOTE_IP”,REMOTE_PORT,0

Furthermore, once data is sent to a different IP, no more repeated data arrives from the IP that was sending it.

I would like to know if there is a way to eliminate the REMOTE_IP and the REMOTE_PORT without having to reconfigure the server?

On the other hand, I loaded a version of FW that I found while I was trying to find a solution, I don’t know if it is official but in this version that error does not appear, the version is SWIMCB71XX-VC4.29.00.174400.201711061628.01

Then you can have a dummy +KUDPSND to an invalid IP address (e.g. 192.168.0.1) after sending the required data to client

BTW, have you tried to send the UDP packet from server by another session created by another +KUDPCFG ?

I have not tried to send the server data from another session, I could see which of the proposed solutions would be most useful for my application. If so, could it be said that this version has a bug? Although the same thing happens to me in all the AT&T versions for the HL7588 and it also happens to me with the HL8548-G module

no idea if this is a bug, but i don’t see there is any firmware fix release for a long time, so better get a workaround to overcome this

Or you can also contact distributor to start the investigation

As a solution to the problem of duplicate data arriving, what you mentioned of sending a message to a dummy IP was implemented, this guarantees that the IP and port are not stored in the KUDPCFG command.

I thank you for all the help you gave me!

I just wanted to ask you one more question, since the HL7588 is discontinued, would you know what the replacement for the HL7588 would be?

for the replacement, you can take a look on the RC series module here: