EHS6T CSD Data connection problem - corrupted mesages received in Java | Telit Cinterion IoT Developer Community
November 26, 2016 - 6:08pm, 2587 views
Hello.
We have production system that uses CSD dial-up connection to send commands from desktop PC program to java terminals. Originally, we used TC65i termanals and all worked fine, and i've never seen that data received was corrupted, but recently we switched to the EH6T and problems revealed. EH6T Terminal receives commands with missed and replaced symbols and communication fails.
Out software is rather complex, so i created very simple program that receives data and prints it to the serial out, byte by byte. You can see full source code here: https://gitlab.com/Grigoriy/ehs6t_test/tree/master
Main part that receives data is simle as:
while (true) {
int bytesAvailable = dataIn.available();
while (bytesAvailable > 0) {
char ch = (char) dataIn.read();
System.out.print(ch);
bytesAvailable--;
}
} Then I tested this example sending packets of some strings like '1111122222333335555566666777778888899999' repeated several *****. I've done 10 cycles of connect - send 1000 bytes - restart terminal and in ALL attempts data was corrupted. I've noticed that corrupted symbols are located in the same place every time - near 140 - 160 symbols after connection start. You can see this on attached screenshots.
correct data:
error example:
another example:
My question is what can be the reason of such data **********? It seems like bug in java implementation - in my code (please any suggestions about what i should correct) or in internal EHS6T firmware. My EHS6T version is
ATI1
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.42
On the other side (to send data from PC) I use old but trustworthy Siemens TC35i.
Also i should notice that it is not looks like data ********** somethere in CSD protocol itself, because when i repeat same tests without java program, controlling EHS6T by external AT commands, data get never corrupted
Hello,
Thank you for the detailed information.
This is a strange behaviour - I need to test your scenario to be able to say more. I will get back to you soon.
Regards,
Bartłomiej
Hello,
I have tested your scenario with the same firmware and unfortunately I was able to reproduce this behaviour.
I've done some more tests and I was able to receive the correct data when I exchanged reading byte by byte with reading to a buffer.
Here's an example:
byte[] buf = new byte[128]; int read = 0; while (true) { //sleep(10); while (dataIn.available() > 0) { read = dataIn.read(buf); System.out.print(new String(buf,0,read)); buf = new byte[128]; } }Another change that seems to help is to add the delay on the sender side.
Please test if this workaround is working for you and if it is acceptable.
Best regards,
Bartłomiej
Thank you a lot for your answer.
Indeed, reading to a buffer like in your example, worked like a charm. Originally, I used reading byte by byte, because i need to examine every byte for special symbols, now i read bytes to the buffer and examine this buffer in another loop. Also I should mention that there is no need to recreate buffer after reading every pack (line buf = new byte[128]; in your example).
Another fix was to remove sleep(x) commands in wait loop, because this also can cause missing symbols.