using a GE864-Quad and a Quad V2 to transfer data over GPRS. Normally it works
sometimes it’s getting a clutter in the payload data. The strange thing is that
the GPRS checksum always is correct, which concludes me that the problem probably
appears before the module sends the data over GPRS.
transmit the data to the Telit module I use a RS-232 Serial connection. I
already have checked this connection; the data payload is transmitted correctly
to the Telit module also in the error case.
should have been transmitted:
43 32 30 30 39 34 35 2E 30 32 33 30 30 2C 23 23 56 30 31 30 30 33 34 2C 39 31
3D 34 30 2C 38 36 3D 53 63 68 75 6C 65 72 20 30 32 33 30 30 2C 38 37 3D 43 32
30 30 39 34 35 2E 30 32 33 30 30 2C 41 34
effectively has been transmitted:
œ €¯Æ , à›
B0 20 20 20 20 20 20 20 20 20 33 30 30 2C 23 23 56 30 10 1D 74 03 D0 17 74 03
01 34 B6 3C 13 03 3D 53 10 1D 74 03 D0 17 74 03 01 20 B6 3C 13 03 03 20 08 20
9C 02 20 80 AF C6 13 20 2C 20 E0 9B 10 20
Module is running in the selint=2 mode and the sockets are running in the
a code fragment I use to transmit the payload. REQ means request sending to the
Telit module RES is the response from the module.
anybody have observed similar things? Or any ideas why this happens? Or how I
can solve this problem?
the module adds strange messages to the payload. And some parts of the payload
are equal (red letters)
e l f S e r v i c e =40,87=Cð?(ð5(7 :2=22803,A115=310511_135550_00_5D49,86=WIB
o m b o x ##V0P’tð&t 4¶<=S €h¿( – (Ÿ+41794997979 86,90ð?t ‘t2¶<,D
the meaning of "Self Service" or "Combox" in this context?
Are you 100% sure isn’t your that sends wrong data? Can you observe/sniff RS232 link in some way? What is/where is your application running? In case is an Windows application you can use for example HHD free serial port monitor.
Hello Mr. Buhu
Thanks for responding
I already have checked the
RS232 link with a sniffer. The data’s transmitting correctly to the Quad
module. The baud ratio is 9600 baud.
Please explain exactly what hardware and software you are using, to have the big picture maybe some ideas will come.
Well, I use
the GE864-Quad in a embedded system. The communication between main processor
and telit module is a RS 232. I do not use any additional software. The
communication is with AT commands.
this module since long time in the same architecture without any problems. At
this time the module was used in the online mode. Since April the sockets now
are opened in the command mode. Since the module is open the sockets in the
command mode the module is sending these strange things.
information helpful? Or did I misunderstand your question?
That is is what I asked for, however cannot say much more … One idea is to check the numbers of bytes sent/received and compare with the ones at the other party, and try to conduct the traffic manually from a PC.
Please check and report firmware version too, thanks.
noticed that only the quad V1 module has these problems. The quad V2 always
sends the correct data.
The quad V1
has the FW Version 07.02.005 and the V2 has the Version 10.00.23.
I’ve tried to
send the commands manually by hand from PC to the Telit module and the data
still was sent wrong.
safety reasons I power down the module if I don’t need it. If the module has to
transmit something, the module goes power up and sends the data before it goes
power down again. The duration between power up and send the data is around
Could it be
that the module still isn’t ready to send data? also when I get a ‘>’ as
response of AT#SSEND?
this is a good point. What do you mean for "power down". It is a complete shut down (ON/OFF or AT#SHDN) or a power saving (AT+CFUN=0 or 5) ?
First test: try to increase the delay between OK received after AT#SD= and next AT#SSEND=1 ? Which is the current delay?
Second test: try increasing the delay between the ‘>’ prompt and the string of data? Let’s say 100ms, 500ms and 1s ?
down’ in mi case means complete shut down (cut power source)
Delay between OK and SSEND
At moment the
delay between the "OK" and the "SSEND" is about 530ms. I
increased it up to 1s and still the same thing.
Delay after ‘>’
after receiving the ‘>’ is around 30ms. After increasing the delay up to 1s,
the problem still appears.
So, I tried
to increase both delays up to 2 seconds (at the same time) and the problem
still appears. Although not as often as without delay.
I’ve made some comparison test even if it is not so easy to reproduce this behavior with the 7.02.605 firmware.
It seems that the 7.02.607 improves the "SSEND" behavior…so I kindly ask you to test this version.
You can request it to your distributor or writing an email to firstname.lastname@example.org.
Thanks a lot for your
I tried to reproduce the
error with the 7.02.607 FW and in fact it seems that with this FW the error
does not appear anymore. That’s good news, but for me it’s not possible to
upgrade all modules. So I’d like to find a workaround for the old FW
(07.02.005). Are there any parameters or settings to change to avoid this
I think the only possible workaround is to add more delay between the > and the string to send.
The alternative it is to switch between online and command mode:
=> send the data
=> send AT commands.
The second work around
doesn’t work in mi case because sometimes there will be "+++" in the
So I’ll try to find a short
delay to work with.
Encountered similar problem. GL868-DUAL, 10.00.186. Modem is controlled by Python script. Data are periodically read from serial interface and sent to FTP. Additionally there are two listening sockets: TCP-Serial bridge and console. Settings:
SER.set_speed(“2400”, “8E1”), no flow control is required for connected deviceAT&K0 (on both MDM and MDM2)AT#SCFG=1,2,300, 0,600,20AT#SCFG=1,3,300,90,600, 1AT#CPUMODE=3
Most of such systems works fine. But on some after heavy data exchange over TCP-Serial bridge data from ASC0 come distorted when connection is active. E.g.: when there is no active connection then data are read succesfully and then sent to FTP. If connection is active (bridge is used or debug reading is made from console) data contains garbage and amount of data differs from expected. Checksum is verified after reading from SER and before data is sent to socket. Example of good and bad data are given in attachment.
In the same time, short packets (below 10 bytes) are sent and received succesfully. Maximum packet length is 256 bytes. Reboot, AT&K3, +IPR, +ICF, AT&F1 on MDM and MDM2, SER.set_speed() right after connection was accepted didn’t help.
What can affect “SER/ASC0 – device” communication when connection is activated?
Hit enter to search or ESC to close
Knowledge Base & Download Zone