CINTERION PCS3 -> Downloading problem in TCP transparent mode | Telit Cinterion IoT Developer Community
October 5, 2016 - 3:17pm, 6124 views
Hallo all,
I have one interesting problem with which I need help.
One year ago I ended development work on our project in USA. Station which contain ****m CINTERION PCS3 have availability for upgrade of FW of our station, but we can speak about this problem as generall problem.
Around one year everithing worked fine, without problems, and few month ago began coming claiming that stations are not able upgrde their self.
I found out that problem is in additonal data which coming as redundant data somewhere inside of our FW (see picture - yellow part)
Fact about this problem:
- blocks of 12 ***** 0x20 (ASCII space character) are added inside our FW
- it is repaeting pseudo-periodicaly, that mean in most case after 671 Bytes +/- few Bytes, or mutiplied of that number like after 1340 or after 2016 Bytes!
I check in documentation if I will find anything, I found something related with unsolicited messages, that this messages are additional signaling on RING0 pin, but also there was short information that if this is not possible you can setup also BREAK transition, but nowhere was descripted what or which shape is BREAK.
In documenation is write that not solved unsolicited answers can disturb activ transmition in any case, so in that case I should stop data flow on mdm (****m) port and switch to command **** via "+++" and I would be able to read "problem"....I did this but no problem was there!
Do somebody help me with this, what can mean this sequence of 12 ***** 0x20, from where it could come, or what can be 671 Bytes ( if any size of something or treshold or whatever )
Thanx a lot!
Matus
It seems that you have the latest firmware release.
It's good that there is at least everything OK in non-transparent ****.
I don't know and can't explain to you the implementation details about what's inside while doing a transparent or non-transparent ****.
So you have tried on PC - what's after connect - do you just read the data or is there any exchange of messages. Is it possible to use any link to some other downloadable file to reproduce it? If we were able to reproduce it easily we would be able to further analyse this to find the root cause and know if it is on our side or not.
On which interface are transmitting the data? I assume that you are not using multiplexer.
Thanks,
Bartłomiej
Hi Bartłomiej,
I have news, but not possitive :(..
I reprogram algorithm, and now I am working not in transparent **** but through ^SISR and ^SISW instructions.
I prepared test file of size 528kB, content of file is nothing else only ASCII 0 ( 0x30 ).
After download of that file, as you can see on picture, there are still spaces ( 12 ***** 0x20 ).
So this **** also is not worked, unfortunately ****m have not other **** for cummunication!!!
Regarding your questions:
We are using (emulating) HTTP via this TCP, so we are sending request to server after establishing connection with server, server should answer to us according URL which we are defined...that is all
I am not using multiplexer in my case, only ASC0 switched to "Modem"...
Would be good if you will be able test that somehow, because I am realy lost any ideas! When this dump going out from ****m, I can't do practicaly nothing!
As I seid before few *****, in past was not problem, suddenly there is! It looks like any non-combality of ****m after any changes in CDMA network or what...
If you want we can prepare somenthing for you for test, any link, from where you can download any prepared file, and tell you what we are sending to server and what we are waiting to come!!!
Hello,
Please provide all the information as you offer. I need to test this problem but I can't do it myself in Europe. I need to ask some college from US to test it for me.
Regards,
Bartłomiej
Hallo,
tell me pls what exactelly you need, and I will prepare that for you!
I also have to do this, and disscuss with my cleague on server side...
Thanx a lot!
Hello,
You have mentioned that you can prepare a link to download a prepared file, and tell what you are sending to server and what you are waiting for in a reply.
Thanks,
Bartłomiej
Hello,
In a meantime my colleagues from USA tried to reproduce this problem but they wasn't able to.
Here are their conclusions:
However, got the test result from my side, and I did not find any problem on the behavior PCS3.
My test setup is like these:
1. Build up a TCP server which is able to push data. Configured with static ip address(***.***.***.***).
2. PCS3 open tcp client socket and enter transparent ****. which is exactly following customer’s steps.
3. Push over 10kbytes hex data “ffffffffffffffff” from tcp server to PCS3, and monitor the receiving from tracing tool.
Here is the result:
[Thu Oct 27 09:12:42.950 2016] ^SYSSTART
[Thu Oct 27 09:12:43.022 2016]
[Thu Oct 27 09:12:43.022 2016] ^SREG: 2
[Thu Oct 27 09:12:43.022 2016]
[Thu Oct 27 09:12:43.022 2016] +CTZU: 16/10/27,16:12:58,+00,0
[Thu Oct 27 09:12:43.998 2016]
[Thu Oct 27 09:12:43.998 2016] ^SREG: 5
[Thu Oct 27 09:12:43.998 2016]
[Thu Oct 27 09:12:43.998 2016] +CTZU: 16/10/27,16:13:00,-28,1
[Thu Oct 27 09:12:52.498 2016] at
[Thu Oct 27 09:12:53.747 2016] OK
[Thu Oct 27 09:13:00.122 2016] AT^SCFG="MEopMode/PwrSave","disabled"
[Thu Oct 27 09:13:01.066 2016] ^SCFG: "MEopMode/PwrSave","disabled","0","50"
[Thu Oct 27 09:13:01.066 2016]
[Thu Oct 27 09:13:01.066 2016] OK
[Thu Oct 27 09:13:05.267 2016] AT\Q3
[Thu Oct 27 09:13:05.892 2016] OK
[Thu Oct 27 09:13:09.535 2016] AT+CTZU=0
[Thu Oct 27 09:13:10.192 2016] OK
[Thu Oct 27 09:13:13.466 2016] AT+CMEE=1
[Thu Oct 27 09:13:14.027 2016] OK
[Thu Oct 27 09:13:16.726 2016] AT^SLED=2
[Thu Oct 27 09:13:17.287 2016] OK
[Thu Oct 27 09:13:20.466 2016] AT+CMGF=1
[Thu Oct 27 09:13:21.043 2016] OK
[Thu Oct 27 09:13:24.094 2016] AT&W
[Thu Oct 27 09:13:24.671 2016] OK
[Thu Oct 27 09:13:28.106 2016] AT+CFUN?
[Thu Oct 27 09:13:28.635 2016] +CFUN: 1
[Thu Oct 27 09:13:28.635 2016]
[Thu Oct 27 09:13:28.635 2016] OK
[Thu Oct 27 09:13:34.291 2016] AT$MDN?
[Thu Oct 27 09:13:34.868 2016] $MDN: *********X
[Thu Oct 27 09:13:34.868 2016]
[Thu Oct 27 09:13:34.868 2016] OK
[Thu Oct 27 09:13:38.014 2016] AT+CIMI
[Thu Oct 27 09:13:38.559 2016] ***************
[Thu Oct 27 09:13:38.575 2016]
[Thu Oct 27 09:13:38.575 2016] OK
[Thu Oct 27 09:13:41.530 2016] AT^SREG?
[Thu Oct 27 09:13:42.075 2016] ^SREG: 1,5
[Thu Oct 27 09:13:42.075 2016]
[Thu Oct 27 09:13:42.075 2016] OK
[Thu Oct 27 09:13:53.133 2016] AT^SCFG="MEopMode/RingOnData","on"
[Thu Oct 27 09:13:53.949 2016] ^SCFG: "MEopMode/RingOnData","on"
[Thu Oct 27 09:13:53.965 2016]
[Thu Oct 27 09:13:53.965 2016] OK
[Thu Oct 27 09:13:58.885 2016] AT^SCFG="MEopMode/RingUrcOnCall","on"
[Thu Oct 27 09:13:59.445 2016] ^SCFG: "MEopMode/RingUrcOnCall","on"
[Thu Oct 27 09:13:59.445 2016]
[Thu Oct 27 09:13:59.445 2016] OK
[Thu Oct 27 09:14:02.833 2016] AT^SCFG="URC/Data****/Ringline","on"
[Thu Oct 27 09:14:03.427 2016] ^SCFG: "URC/Data****/Ringline","on"
[Thu Oct 27 09:14:03.427 2016]
[Thu Oct 27 09:14:03.427 2016] OK
[Thu Oct 27 09:14:11.703 2016] AT^SCFG="cdma/sip/ppp"
[Thu Oct 27 09:14:12.456 2016] ^SCFG: "cdma/sip/ppp","*********X@vzw3g.com"
[Thu Oct 27 09:14:12.456 2016]
[Thu Oct 27 09:14:12.456 2016] OK
[Thu Oct 27 09:14:19.710 2016] AT^SICO=201
[Thu Oct 27 09:14:23.741 2016] OK
[Thu Oct 27 09:14:24.792 2016] AT^SISS=0,"srvType","TCPclient"
[Thu Oct 27 09:14:25.401 2016] OK
[Thu Oct 27 09:14:38.905 2016] AT^SISS=0,"address","***.***.***.***:1000"
[Thu Oct 27 09:14:39.577 2016] OK
[Thu Oct 27 09:15:08.698 2016] AT^SISO=0
[Thu Oct 27 09:15:10.043 2016] OK
[Thu Oct 27 09:15:10.043 2016]
[Thu Oct 27 09:15:10.043 2016] ^SISW: 0,1
[Thu Oct 27 09:15:15.172 2016] AT^SIST=0
[Thu Oct 27 09:15:15.914 2016] CONNECT
[Thu Oct 27 09:15:45.942 2016]
[Thu Oct 27 09:21:24.437 2016] OK
[Thu Oct 27 09:21:26.521 2016] at
[Thu Oct 27 09:21:26.756 2016] OK
[Thu Oct 27 09:21:27.872 2016] at
[Thu Oct 27 09:21:28.066 2016] OK
[Thu Oct 27 09:22:49.587 2016] ati1
[Thu Oct 27 09:22:50.216 2016] Cinterion
[Thu Oct 27 09:22:50.216 2016] PCS3
[Thu Oct 27 09:22:50.216 2016] REVISION 02.100
[Thu Oct 27 09:22:50.216 2016] A-REVISION 01.000.07
[Thu Oct 27 09:22:50.216 2016]
[Thu Oct 27 09:22:50.216 2016] OK
There's also a data trace which does not show any extra characters.
Best regards,
Bartłomiej
Hi Bartłomiej,
thank you for test!
There are any deviations btw our settups, but OK...
The best would be to test it with conditions settup by us...sorry but we have not time yet to discuss about test with my coleague...I will let you know, when I appoint with him this!