HL7800 - Byte losing during data transmission

IoT Modules HL78
1

Hi,

i encountered strange issue during UDP data transmission with HL7800 modem.
We lose some bytes in payload sometimes. My observations:

  • I checked UART bus communication → it is working without any issue.
  • I am using handshaking. Checked with analyzer and scope. It works.
  • I observed an interesting behavior of HL7800 module: I lose a few bytes only after i sent character ‘+’. In the payload i use base64 encoded data, I performed a lot of tests comparing data between nbiot device and server. When there are lost bytes sometins, it always only after this character ‘+’. Here are 2 examples:

We send this UDP payload:

AT+KUDPSND=1,“xxx.xxx.xxx.xxx”,“xxx”,870
CONNECT
9gb0AgEBAQCQAzkAIAYEAFghAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD0APQA9ADxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
nyn1AgEBAQCQAzkAIAYEAFkhAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbrAOsA6wDpAOkA6QDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
YoX2AgEBAQCQAzkAIAYEAAAiAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDpAOkA6QDsAOwA7AD0APQA9ADxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
z0T3AgEBAQCQAzkAIAYEAAEiAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
pnb4AgEBAQCQAzkAIAYEAAIiAAAAAAcAAeAXHgACAAAQABD2APYA9gARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
–EOF–Pattern–
OK
+KUDP_NOTIF: 1,8
+KUDP_DATA: 1,40

We received 868 Bytes instead of 870 Bytes on the server:

9gb0AgEBAQCQAzkAIAYEAFghAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD0APQA9ADxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
nyn1AgEBAQCQAzkAIAYEAFkhAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbrAOsA6wDpAOkA6QDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
YoX2AgEBAQCQAzkAIAYEAAAiAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDpAOkA6QDsAOwA7AD0APQA9ADxAPEA8QD5APkA+oAOgA6ADnAOcA5wDrAOsA6wA=
z0T3AgEBAQCQAzkAIAYEAAEiAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=
pnb4AgEBAQCQAzkAIAYEAAIiAAAAAAcAAeAXHgACAAAQABD2APYA9gARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=

There are missing “QD”, after character ‘+’.

AT+KUDPSND=1,“xxx.xxx.xxx.xxx”,“xxx”,870
CONNECT
ZWWPAgEBAQCQAzkAIAYEACggAAAAAAcAAeIXHgACAAAQABD0APQA9AARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD2APYA9gDxAPEA8QD7APsA+wDnAOcA5wDoAOgA6ADrAOsA6wA=
wWeQAgEBAQCQAzkAIAYEACkgAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD6APoA+gDnAOcA5wDoAOgA6ADsAOwA7AA=
9AmRAgEBAQCQAzkAIAYEADAgAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD7APsA+wDoAOgA6ADoAOgA6ADrAOsA6wA=
TzOSAgEBAQCQAzkAIAYEADEgAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD0APQA9ADyAPIA8gD7APsA+wDoAOgA6ADoAOgA6ADrAOsA6wA=
jamTAgEBAQCQAzkAIAYEADIgAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD6APoA+gDnAOcA5wDoAOgA6ADsAOwA7AA=
–EOF–Pattern–
OK
+KUDP_NOTIF: 1,8
+KUDP_DATA: 1,40

And we received 866 Bytes instead of 870 Bytes on the server:

ZWWPAgEBAQCQAzkAIAYEACggAAAAAAcAAeIXHgACAAAQABD0APQA9AARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD2APYA9gDxAPEA8QD7APsA+wDnAOcA5wDoAOgA6ADrAOsA6wA=
wWeQAgEBAQCQAzkAIAYEACkgAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD6APoA+gDnAOcA5wDoAOgA6ADsAOwA7AA=
9AmRAgEBAQCQAzkAIAYEADAgAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD7APsA+wDoAOgA6ADoAOgA6ADrAOsA6wA=
TzOSAgEBAQCQAzkAIAYEADEgAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD0APQA9ADyAPIA8gD7APsA+OgA6ADoAOgA6ADrAOsA6wA=
jamTAgEBAQCQAzkAIAYEADIgAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbsAOwA7ADrAOsA6wDtAO0A7QD1APUA9QDxAPEA8QD6APoA+gDnAOcA5wDoAOgA6ADsAOwA7AA=

There are missing “wDoA”, after character ‘+’.

Does anybody has any idea what there happens ? I was thinking about the sequence “+++”, which means end of data mode. But this +++ must be sent in sequence, in my payload there ‘+’ characters are being sent random and not in sequence.
It is clear that modem hangs at some point during data receiving over UART, because at the end we get this notification +KUDP_NOTIF: 1,8, which means modem expected 870 Bytes but it received more or less bytes. I check the data sequence/transmission through analyzer and scope on UART bus, between CPU and HL module, all have been sent correct direct to modem, even the handshaking (CTS/RTS) worked well.

thank you

2

Hi @jan.krchnak,
Which firmware are you using? I tried to reproduce the issue on the latest (4.4.6). The module is transmitted completely, the byte after the character “+” is not lost. Let see the output as below
I saw that your data including 868 as the screenshot

image
image1497×1045 45.3 KB

at+kudpsnd=1,“10.1.0.98”,5043,868

CONNECT

OK

+KUDP_NOTIF: 1,8

+KUDP_DATA: 1,864
at+kudprcv=1,868

CONNECT
9gb0AgEBAQCQAzkAIAYEAFghAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD0APQA9ADxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=nyn1AgEBAQCQAzkAIAYEAFkhAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbrAOsA6wDpAOkA6QDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=YoX2AgEBAQCQAzkAIAYEAAAiAAAAAAcAAeAXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDpAOkA6QDsAOwA7AD0APQA9ADxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=z0T3AgEBAQCQAzkAIAYEAAEiAAAAAAcAAeIXHgACAAAQABD1APUA9QARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=pnb4AgEBAQCQAzkAIAYEAAIiAAAAAAcAAeAXHgACAAAQABD2APYA9gARhIAPGwAAAU6BEgAAAAAAAAAAAAAAAAIAAAAAAAFDnzbqAOoA6gDqAOoA6gDsAOwA7AD1APUA9QDxAPEA8QD5APkA+QDoAOgA6ADnAOcA5wDrAOsA6wA=–EOF–Pattern–
OK
Please share any concerns you have and help tick Solution if your problem is gone
Thanks

1 Like
3

Hi Vianney,

thank you for your efforts.
I have older FW of HL7800: 3.4.1
Do you know where i can find release notes ? I would like to check them.

Byt losing happens rarely, not alll the time. I don’t how many times did you send the payload. By me it happens maybe once per 5 - 10 transmissions, if payload includes a lot of ‘+’ characters. If i have paylaod with almost none ‘+’, it works fine.

Note: My payload has size of 870 Byte, after your last line there are missing CR and LF, therefore you have 868 Bytes.

Thank you.

4

@jan.krchnak

You really need to use the newer firmware as given here, as 3.4.1 is very old and the newer firmware has a lot of bug fixes in, the release notes are contained in the sub page of a firmware that you choose.

Regards

Matt

5

Thank you.
I was considering to upgrade the module as well.
I will try, and let you know.

Jan

6

Hi all,

i am sorry for delay.
I am going to update FW of HL7800, which port is being used for FW upgrade ?
There are UART0, UART1 (i am using for communication) or USB ? I was trying to make pure UART bridge mode in my device with UART1, and the update SW from Sierra didn’t sync HL7800.

Thank you

Jan

7

@jan.krchnak

You can update over either of the UART’s, generally people use the AT command one (the debug/UART 0 as per the dev kit labeling) can be used depending on its mode.

Regards

Matt

8

Is it ok if i will make USB/UART cable for UART0 of HL7800 ?
I downloaded that exe file (Window one click) from here https://source.sierrawireless.com/resources/airprime/software/hl7800-firmware/hl7800-firmware-3,-d-,5,-d-,0/#sthash.AdTJWY1W.dpbs

This SW requires only to select COM port number and baud rate.

9

@jan.krchnak

I would definitely recommend using firmware newer than 3.5.0, go for 4.3.9 as a minimum.

Obviously the one click updater is referring to the COM port on the PC, not the COM port on the module. With regards the port to use on the module as I say you can use either, not sure of the mode (AT+SWITRACEMODE) the unit needs to be in for UART0/debug, you will have to mess with it.

Regards

Matt

10

Hi all,

i was only trying to use that FW update exe file (windows one click) throgh UART1 of HL7800, without success. I checked data flow on UART, modem was responding only echo with ERROR on everything sent to modem.

AT+SWITRACEMODE doesn’t work as well.
Is there any manual / guide from Sierra Wireless with instructions how to update FW manually?
Sorry my first experiences with Sierra Wireless modems.

Thank you

11

@jan.krchnak

So some questions.

  • Are you doing this on a dev board or your application?
  • You are referring to UART’s but can you please be explicit as to which UART? UART1 is the AT command UART and is referred to in the PTS and on the dev board with UART0 being the debug port.
  • What do you mean AT+SWITRACEMODE doesn’t work well? Need a bit more detail.

If you have a dev kit you literally insert the modem, power the board up, run the one click updater, specify the UART (of the PC) and speed to be used and it should update the unit.

I need a lot more detail i.e. screen shot, command responses, etc to be able to help you.

Regards

Matt

12

Hi, thank you all so far for your help.

We upgraded NBIoT module through debug port to latest available FW 4.4.6.

I encountered another issue with latest modem FW:

  • There is still something strange issue with “+”.
  • But instead of missing Bytes, there are screwed Bytes, probably at the place where should be “+” characters in payload (This time the length of payload is always ok).

E.g.: Here is payload received in server: At the beginning there appeared “++” (it was not sent out). In the last line there is appeared one space " " and few Bytes before there is missing “+”.

image
image1349×150 8.91 KB

I will proceed more tests, and will compare the data sent out and received on the server.

Jan

13

Hi,

I executed next test. I sent 6 UDP packets (with base64 strings) during one connection.
Apparently there is issue with characters ‘+’. There are being appeared some ‘+’ at the begin of first line (at the begin of payloads). And inside payload there are missing or screwed Bytes. Mostly at the places where was ‘+’ character.
I am using the latest modem FW 4.4.6.

  1. UDP packet

Sent from device:

CONNECT
4JsBAgABAgCQAzkAAW4AAmUABDIFIAYXAEkV
J2gCAgEBAgCQAzkAAAEBAAAAAQgAAAcAATcYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD1APUA9QD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
0aEDAgEBAgCQAzkAIAcUADEJAQAAAAcAASMYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD0APQA9AD9AP0A/QD5APkA+QD+AP4A/gDtAO0A7QDtAO0A7QDyAPIA8gA=
EMoEAgEBAgCQAzkAIAcUADIJAAAAAAcAARwYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD0APQA9AD9AP0A/QD5APkA+QD/AP8A/wDsAOwA7ADuAO4A7gDyAPIA8gA=
5DUFAgEBAgCQAzkAIAcUADMJAAAAAAcAARgYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb+AP4A/gD1APUA9QD1APUA9QD9AP0A/QD5APkA+QD+AP4A/gDuAO4A7gDuAO4A7gDyAPIA8gA=
+vgGAgEBAgCQAzkAIAcUADQJAAAAAAcAARUYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb+AP4A/gD1APUA9QD1APUA9QD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
–EOF–Pattern–

Received on server:

++4JsAgABgCQAzkAAW4AAmUABDIFIAYXAEkV
J2gCAgEBAgCQAzkAAAEBAAAAAQgAAAcAATcYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD1APUA9QD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
0aEDAgEBAgCQAzkAIAcUADEJAQAAAAcAASMYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD0APQA9AD9AP0A/QD5APkA+QD+AP4A/gDtAO0A7QDtAO0A7QDyAPIA8gA=
EMoEAgEBAgCQAzkAIAcUADIJAAAAAAcAARwYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb8APwA/AD1APUA9QD0APQA9AD9AP0A/QD5APkA+QD/AP8A/wDsAOwA7ADuAO4A7gDyAPIA8gA=
5DUFAgEBAgCQAzkAIAcUADMJAAAAAAcAARgYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb+AP4A/gD1APUA9QD1APUA9QD9AP0A/QD5APkA+QDAP4A/gDu AO4A7gDuAO4A7gDyAPIA8gA=
vgGA gEBAgCQAzkAIAcUADQJAAAAAAcAARUYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgAKAAkADAAaAAFDnzb+AP4A/gD1APUA9QD1APUA9QD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=

  1. UDP packet

Sent from device:

CONNECT
khoHAgEBAgCQAzkAIAcUADUJAAAAAAcAARMYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzb/AP8A/wD1APUA9QD1APUA9QD9AP0A/QD5APkA+QD+AP4A/gDtAO0A7QDuAO4A7gDyAPIA8gA=
4kgIAgEBAgCQAzkAIAcUADYJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzb/AP8A/wD2APYA9gD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
edUJAgEBAgCQAzkAIAcUADcJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYAAQABAAH2APYA9gD1APUA9QD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
4psKAgEBAgCQAzkAIAcUADgJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYAAQABAAH3APcA9wD1APUA9QD9AP0A/QD5APkA+QD+AP4A/gDsAOwA7ADuAO4A7gDzAPMA8wA=
9yQLAgEBAgCQAzkAIAcUADkJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYBAQEBAQH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD+AP4A/gDtAO0A7QDvAO8A7wDyAPIA8gA=
xJEMAgEBAgCQAzkAIAcUAEAJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD/AP8A/wDuAO4A7gDuAO4A7gDzAPMA8wA=
–EOF–Pattern–

Received on server:

khoHAgEBAgCQAzkAIAcUADUJAAAAAAcAARMYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzb/AP8A/wD1APUA9QD1APUA9QD9AP0A/QD5APkA+QD+AP4A/gDtAO0A7QDuAO4A7gDyAPIA8gA=
4kgIAgEBAgCQAzkAIAcUADYJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzb/AP8A/wD2APYA9gD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
edUJAgEBAgCQAzkAIAcUADcJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYAAQABAAH2APYA9gD1APUA9QD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
4psKAgEBAgCQAzkAIAcUADgJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYAAQABAAH3APcA9wD1APUA9QD9AP0A/QD5APkA+QD+AP4A/gDsAOwA7ADuAO4A7gDzAPMA8wA=
9yQLAgEBAgCQAzkAIAcUADkJAAAAAAcAAREYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYBAQEBAQH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD+AP4A/gDtAO0A7QDvAO8A7wDyAPIA8gA=
xJEMAgEBAgCQAzkAIAcUAEAJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD/AP8A/wDuAO4A7gDuAO4A7gDzAPMA8wA=

  1. UDP packet

Sent from device:

CONNECT
IRYNAgEBAgCQAzkAIAcUAEEJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD0APQA9AD+AP4A/gD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
jd4OAgEBAgCQAzkAIAcUAEIJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD+AP4A/gDsAOwA7ADuAO4A7gDzAPMA8wA=
PVEPAgEBAgCQAzkAIAcUAEMJAAAAAAcAAQgYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD2APYA9gD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
UjoQAgEBAgCQAzkAIAcUAEQJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYDAQMBAwH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDtAO0A7QDzAPMA8wA=
KFMRAgEBAgCQAzkAIAcUAEUJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD1APUA9QD+AP4A/gD4APgA+AD+AP4A/gDuAO4A7gDuAO4A7gDzAPMA8wA=
CdsSAgEBAgCQAzkAIAcUAEYJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH4APgA+AD1APUA9QD8APwA/AD5APkA+QD/AP8A/wDtAO0A7QDtAO0A7QDyAPIA8gA=
–EOF–Pattern–

Received on server:

+++IRNAgBAgCQzkAIAcUAEEJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD0APQA9AD+AP4A/gD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
jd4OAgEBAgCQAzkAIAcUAEIJAAAAAAcAAQoYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYCAQIBAgH3APcA9wD1APUA9QD+AP4A/gD5APkA+QD+AP4A/gDsAOwA7ADuAO4A7gDzAPMA8wA=
PVEPAgEBAgCQAzkAIAcUAEMJAAAAAAcAAQgYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD2APYA9gD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
UjoQAgEBAgCQAzkAIAcUAEQJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYDAQMBAwH3APcA9wD1APUA9QD+AP4A/gD5APkAQD/AP84A/wDtAO0A7QDtAO0A7QDzAPMA8wA=
KFMRAgEBAgCQAzkAIAcUAEUJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD1APUA9QD+AP4A/gD4APgAAD++AP4A/gDuAO4A7gDuAO4A7gDzAPMA8wA=
CdsSAgEBAgCQAzkAIAcUAEYJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH4APgAAD1APUA9QD8AAPwA/AD5APkA+QD/AP8A/wDtAO0A7QDtAO0A7QDyAPIA8gA=

  1. UDP packet

Sent from device:

CONNECT
7LYTAgEBAgCQAzkAIAcUAEcJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH4APgA+AD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
LGEUAgEBAgCQAzkAIAcUAEgJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD2APYA9gD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
CM4VAgEBAgCQAzkAIAcUAEkJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYFAQUBBQH5APkA+QD2APYA9gD+AP4A/gD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
q2AWAgEBAgCQAzkAIAcUAFAJAAAAAAcAAQQYHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYFAQUBBQH4APgA+AD2APYA9gD+AP4A/gD5APkA+QD/AP8A/wDsAOwA7ADuAO4A7gDzAPMA8wA=
TYQXAgEBAgCQAzkAIAcUAFEJAAAAAAcAAQQYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYGAQYBBgH5APkA+QD1APUA9QD8APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
RJcYAgEBAgCQAzkAIAcUAFIJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYGAQYBBgH4APgA+AD2APYA9gD8APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
–EOF–Pattern–

Received on server:

+++7LYTAgEgQAzkAIAcUAEcJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYEAQQBBAH4APgA+AD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
LGEUAgEBAgCQAzkAIAcUAEgJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYEAQQBBAH3APcA9wD2APYA9gD9AP0A/QD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
CM4VAgEBAgCQAzkAIAcUAEkJAAAAAAcAAQYYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYFAQUBBQH5APkA+QD2APYA9gD+AP4A/gD5APkAQD/AP8A//wDtAO0A7QDuAO4A7gDzAPMA8wA=
q2AWAgEBAgCQAzkAIAcUAFAJAAAAAAcAAQQYHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYFAQUBBQH4APgA+AD2APYA9gD+AP4A/gD5APkAQD/AP8A//wDsAOwA7ADuAO4A7gDzAPMA8wA=
TYQXAgEBAgCQAzkAIAcUAFEJAAAAAAcAAQQYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYGAQYBBgH5APkA+QD1APUA9QD8APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
RJcYAgEBAgCQAzkAIAcUAFIJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYGAQYBBgH4APgAAD2APYA9gD88APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=

  1. UDP packet

Sent from device:

CONNECT
6nQZAgEBAgCQAzkAIAcUAFMJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYHAQcBBwH5APkA+QD2APYA9gD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
o4YaAgEBAgCQAzkAIAcUAFQJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYHAQcBBwH5APkA+QD2APYA9gD+AP4A/gD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
8mkbAgEBAgCQAzkAIAcUAFUJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDtAO0A7QDzAPMA8wA=
LdccAgEBAgCQAzkAIAcUAFYJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD2APYA9gD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDvAO8A7wDzAPMA8wA=
y3sdAgEBAgCQAzkAIAcUAFcJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABMACgALAAkADAAaAAFDnzYHAQcBBwH5APkA+QD2APYA9gD8APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
apoeAgEBAgCQAzkAIAcUAFgJAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDsAOwA7ADuAO4A7gDzAPMA8wA=
–EOF–Pattern–

Received on server:

+++6nQZAEBAgCzkAIAcUAFMJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYHAQcBBwH5APkA+QD2APYA9gD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
o4YaAgEBAgCQAzkAIAcUAFQJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYHAQcBBwH5APkAQD2APYA9gD+9AP4A/gD4APgAAD/AP88A/wDtAO0A7QDuAO4A7gDyAPIA8gA=
8mkbAgEBAgCQAzkAIAcUAFUJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDtAO0A7QDtAO0A7QDzAPMA8wA=
LdccAgEBAgCQAzkAIAcUAFYJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhsADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkAQD2APYA9gD9AAP0A/QD5APkA+QD/AP8A/wDtAO0A7QDvAO8A7wDzAPMA8wA=
y3sdAgEBAgCQAzkAIAcUAFcJAAAAAAcAAQEYHgACAAARhIAPGwAAAU6BEhoADgAKABMACgALAAkADAAaAAFDnzYHAQcBBwH5APkA+QD2APYA9gD8APwA/AD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
apoeAgEBAgCQAzkAIAcUAFgJAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhoADgAKABIACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD1APUA9QD9AP0A/QD5APkA+QD/AP8A/wDsAOwA7ADuAO4A7gDzAPMA8wA=

  1. UDP packet

Sent from device:

CONNECT
w8AfAgEBAgCQAzkAIAcUAFkJAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD2APYA9gD+AP4A/gD4APgA+AD/AP8A/wDtAO0A7QDuAO4A7gDzAPMA8wA=
0dsgAgEBAgCQAzkAIAcUAAAQAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD2APYA9gD8APwA/AD5APkA+QD+AP4A/gDtAO0A7QDtAO0A7QDzAPMA8wA=
–EOF–Pattern–

Received on server

++w8AfAgEBAgQzkAIAcUAFkJAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYIAQgBCAH5APkA+QD2APYA9gD+AP4A/gD4APgAAD/AP8A/wDDtAO0A7QDuAO4A7gDzAPMA8wA=
0dsgAgEBAgCQAzkAIAcUAAAQAAAAAAcAAf8XHgACAAARhIAPGwAAAU6BEhsADgAKABMACgALAAkADAAaAAFDnzYIAQgBCAH5APkAQD2APYA9gD8AAPwA/AD5APkA+QD+AP4A/gDtAO0A7QDtAO0A7QDzAPMA8wA=

14

Hi,

One note more to my last contribution. Apparantelly there is a strange issue related to ‘x’ characters.

E.g. 1. UDP packet:

image
image1307×146 7.22 KB

Received

image
image1307×137 7.85 KB

Red arrow = 2 “xx” appeared at the begin of payload
Red circles = 2 ‘x’ missing in the content of payload

E.g. 3. UDP packet:

image
image1292×150 8.05 KB

Received

image
image1292×142 9.35 KB

Red arrow = 3 “xx” appeared at the begin of payload
Red circles = 3 ‘x’ missing in the content of payload