+KTCP_NOTIF: 1,8 with correct data length sent

[rlemburg]

Hi all,

I am receiving a +KTCP_NOTIF: 1,8 after transmitting TCP data. (Data sending is OK but +KTCPSND was waiting for more or less characters). Because of this, I do not know how many bytes the server is sending back to me, because I don’t get a +KTCP_DATA response.

Using BHL7800-M.2.5.6.1.20190412.
BHL78xx.2.5.6.1.RK_02_01_01_00_41.20190412
Legato RTOS: 18.09.2.ALT1250.rc5 2019/04/04 14:02:47

Sending 13866 bytes of data to a server using TCP. I have 3 data components concatenated together:

TCP Header, some pre-data, and data:

POST <IP-ADDRESS-ENDPOINT> HTTP/1.1<CR><LF>
Host: <IP-ADDRESS><CR><LF>
Content-Length: 13750<CR><LF>  (NOTE: Total Size - TCP header size)
Content-Type: application/octet-stream<CR><LF>
<CR><LF>
[object][data]--EOF--Pattern--

The total size of this data (up to but not including --EOF--Pattern--) in this example is 13866 bytes.

My general connection flow is as follows:

AT+K3
AT+CGDCONT=1,"IPV4V6","internet.sierrawireless.com"   --> Receive OK
AT+KCNXCFG=1,"GPRS","internet.sierrawireless.com"     --> Receive OK
AT+KTCPCFG=1,0,"<IP_ADDRESS>",80                      --> Receive +KTCPCFG: 1
AT+KTCPCNX=1  
--> Receive    +KCNX_IND: 1,1,0   (Connecting...)
--> Receive    +KTCP_IND: 1,1     (Connected)

Each command has 200 msec of delay after receiving a response, and before transmitting the next command. After receiving connect KTCP_IND: 1,1, I issue AT+KTCPSND=1,13866 200 msec later. I then wait for “CONNECT”. After receiving “CONNECT”, I start sending data to the UART.

AT+KTCPSND=1,13866
[200 msec delay]
--> Receive CONNECT
[Immediately transmit 13866 bytes of data] (Have also tried with additional delays after CONNECT).

1. I verify with a logic analyzer that after “CONNECT”, the EXACT number of bytes (13866) are sent to the radio after CONNECT and up to but not including --EOF--Pattern--.
2. I verify the baud rate is correct (115200 +/- 1%)
3. Hardware flow control is enabled, and TX data (into the module) is being properly delayed when CTS is asserted.
4. I continue to run this example, and on occasion, the radio will respond with “+KTCP_DATA: 1,<bytes_to_receive>”

Any ideas how I should approach this? Is there a way to query the module for how many bytes it received?

Appreciate any feedback anyone may have.
Thank you

Other threads I have read:

HL8548 How to create a TCP connection

Team, [image] I am following the exact same steps given in the AirPrime_HL6_and_HL8_Series_AT_Commands_Interface_Guide_Rev19_0 page number 780 How to Use TCP Commands but i am not able to create the successful TCP connection. As soon as I Get CONNECT response from Modem, i send “GET / HTTP/1.0 but i do not get any response after that. it stays here for 1 min, after that timeout happens. It looks like i am not getting any response from HTTP/1.0 page? any help will be greatly appreciated! A…

HL6528 - Kpattern problem

Hi, i’m using an HL6528 2.8V When connecting as a tcp client to a server, it happens that sometimes the kpattern is not recognized by the HL6528. the escape char is sent to the server as a data…i can see it in the log of the server I try to send it three times with a pause of 1 second between each try… but i never get the OK from the HL6528. it is sent three time as a data to the server It happens approximatively 1 times every 15 frames successfully sent to the server. it seems that the mod…

[Sierra_JordanZhao]

@rlemburg

+KTCP_NOTIF: 1,8

Would you please give a try on the latest version 3.7.2.3 or 3.5.0?
https://source.sierrawireless.com/resources/airprime/software/hl7800-firmware/hl78xx-firmware/#sthash.5xCRrlra.dpbs

[rlemburg]

Jordan,

Thank you for your response. I noticed also in document “AirPrime - HL7800 - Customer Release Note - 3.5.0 - R00.15b” that there is a known issue with this ([PROTOCOM][KTCPSND] +KTCP_NOTIF: 1,8 is returned although module have sent fully data to server) on p. 70, (ID DIZZY1-1017). I have upgraded to firmware version BHL7800-M.3.7.0.0.20190918.

Could you please verify that when CTS is low, the radio module is in fact ready to receive more characters right away? My concern is that during a long data transmission, it appears the HL7800 is asserting CTS for about 5us or so after every byte sent. If the interrupt service routine in the HL7800 module is missing data if it is sent immediately, that could explain the KTCP_IND: 1,8 situation. Are there any known issues with this, or can I continue to transmit data immediately whenever CTS is low?

The new firmware has improved this, but it still happens occasionally.

[rlemburg]

Update:

Still happening on BHL7800-M.3.7.0.0.20190918. Sending exactly the right number of bytes, but still receiving +KTCP_NOTIF: 1,8. I will upgrade again to 3.7.2.3, and see if the same issue occurs there.

[rlemburg]

Update 2:

Upgraded to BHL7800-M.3.7.2.3.20191030. Transmitting correct number of bytes each time, but get back +KTCP_DATA sometimes.

Transmitting the same packet seems to yield different results each time. I must be missing something obvious!

[cherokee]

Hi @rlemburg,

+KTCP_DATA is sent for each TCP packet received sequentially; notification of the following received packet is sent only when the current +KTCP_DATA has been read with a +KTCPRCV command.

Please use command AT+KTCPRCV=<session_ID>,<n_data> to read the first packet. After that the next “+KTCP_DATA” will be displayed.

Thanks,

[Sierra_JordanZhao]

What do you mean getting back +KTCP_DATA sometimes? Do you mind to attach the OK and NG AT log for checking?

[rlemburg]

Thanks for your help, Jordan.

Here are two back-to-back examples of the same transmissions, but with and without the expected +KTCP_DATA=1, from the module. Each transmission has the following sequence:

1. Full radio module power-off (including power supplies).
2. Power on module
3. Wait 30 seconds
4. Boot module, send 16 AT and receive 16 OK
5. Inquire network status with AT+CGATT? and verify attached.
6. Send connect and TCP transmit sequence

Sequence 1
Packet transmission sequence without KTCP_DATA:1,ndata

ATE0
OK

AT&K3
OK

AT+CCID
+CCID: <ccid>

OK

ATI3
BHL7800-M.3.7.2.3.20191030

OK
 
+CESQ: 99,99,255,255,11,34

OK

AT+CGDCONT=1,"IPV4V6","internet.sierrawireless.com"
 ERR>>ERROR
 [2,0] 80

AT+KCNXCFG=1,"GPRS","internet.sierrawireless.com"

OK
 EXP>>OK
 [2,0] 00


OK
APN connected [1236 ms]
AT&K3
 EXP>>OK
 [2,0] 00

AT+CCLK?

+CCLK: "20/02/06,10:16:00-24"

 EXP>>+CCLK: "20/02/06,10:16:00-24"
 [6,0] 00

OK
AT+KTCPCFG=1,0,"<ipaddress>,80

+KTCPCFG: 1


AT+KTCPCNX=1

OK

+KCNX_IND: 1,1,0

+KTCP_IND: 1,1
 EXP>>+KTCP_IND: 1,1
 [15,0] 00
 

AT+KTCPSND=1,13314

CONNECT
 

Connected. Sending data...
 
[DATA]--EOF--Pattern--
OK
 EXP>>OK
 [2,0] 00

At this point, I should get back +KTCP_DATA,1,<ndata> and then issue +KTCPRCV=1,. In this example, the radio never sent this notification, so I do not know how many bytes to read from the server.

Sequence 2
Same packet transmission sequence as above with same data length, but successful:

… (same as above until this point) …

AT+KTCPSND=1,13314

CONNECT
 

Connected. Sending data...
 
[DATA]--EOF--Pattern--
OK
 EXP>>OK
 [2,0] 00
 
+KTCP_DATA: 1,467
 EXP>>+KTCP_DATA: 1,467
 [10,0] 00

RX 467
AT+KTCPRCV=1,467

CONNECT
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Server: <??>
X-AspNet-Version: <??>
X-Powered-By: <??>
Access-Control-Allow-Headers: Content-Type, Origin, X-Requested-With, Accept, Key
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST,PUT
Date: Thu, 06 Feb 2020 16:23:51 GMT
Content-Length: 80

{"status":"Success","description":"Received 13197 bytes from you","response":""}--EOF--Pattern--
OK
AT+KTCPCLOSE=1,1

OK

 EXP>>OK
 [2,0] 00

+KCNX_IND: 1,5,30
AT+KTCPDEL=1

OK
 EXP>>OK
 [2,0] 00


+KCNX_IND: 1,3

Let’s say I transmit this packet 100 times in a row, spaced out by 60 seconds. I will receive a +KTCP_DATA notification approximately 80% of the time. With the old firmware, I was receiving this notification approximately 10% of the time, in addition to +KTCP_NOTIF: 1,8 . With the new firmware, I am no longer receiving +KTCP_NOTIF: 1,8 notification, but I am not receiving a +KTCP_DATA notification after each transmission.

Every time I do receive a +KTCP_DATA notification, I am reading all <ndata> bytes up to and including --EOF--Pattern-- sent by radio.

• Confirmed with a logic analyzer that all bytes in AT+KTCPSND=1,ndata are being sent to radio.
• Confirmed bytes are being transmitted only when CTS is low.
• Confirmed power supply voltages are solid during TX period.
• Confirmed data without +KTCP_DATA response is received on server.

A few other notes:

• 200 msec of delay between commands
• Baud rate is 115200 +/- 1%
• VBATT + VBATT_PA are 3.3V
• Peak current during transmit 1 = 650mA & transmit 2 = 643mA
• Software version is BHL7800-M.3.7.2.3.20191030
• RSRQ=11 (-14dB), RSRP=34 (-106dBm)
• Using LTE Band 12 (700 MHz)

[rlemburg]

Hi Cherokee,

notification of the following received packet is sent only when the current +KTCP_DATA has been read with a +KTCPRCV command.

My understanding is that after transmission, received data unsolicited indication should appear after dropping back to command mode. Once this message is received, you then issue AT+KTCPRSV=,. If is less than the first , then you will continue to receive +KTCP_DATA notifications until all data is read.

However, this indication needs to be received after the transmission first, in order to know how many bytes to receive in the first place. I suppose one way to deal with this is to send a At+KTCPRCV=1,1000 and just try to receive bytes. However, if the +KTCP_DATA notification does not show up after the packet transmission is completed, then no data is available anyway.

[Sierra_JordanZhao]

Hi @rlemburg, If the module didn’t receive the data, it won’t output the +KTCP_DATA indication. To confirm whether the module received the data or not, please trigger below command in CLI port and capture the package received by the module.
How to get the IP traffic log from HL7800?

1. Install wireshark application on Linux or Windows
2. Use CLI command “tcpdump [-i interface] [-t timeout] [-lte print direction [-p packet capture]]”
   ​e.g. “tcpdump -lte 3 -p” ( at this point any packet between MAC and RTOS print out)
3. Network side send the data package to the module and you will see the output in CLI port.
4. Copy the output to text file
5. open Linux/Windodws os machine and run the command line "text2pcap -t %H:%M:%S <wireshark.pcap>.
6. open the .pcap file​ to check IP traffic.

As long as we confirm that the module indeed receives the data package without outputting +KTCP_DATA indication, we can say it’s a firmware issue.

[rlemburg]

Just wanted to update all that this has been fixed by upgrading to software version BHL7800-M.3.7.2.3.20191030. Thanks for your help.