Hi Everyone,
I’m having trouble sending larger Python scripts to my Telit 862 GPS, I’ve tried quite a few things and I’m pretty stuck now. Smaller files work fine but one over about 8k or so fail consistently, the AT#WSCRIPT times out so somehow characeters are getting lost. (I’ve tried splitting the script up into smaller files and they all transfer OK.)
Any suggestions or ideas?
I’ve read the AT command reference and taken note of this warning:
During command mode, due to hardware limitations, under severe CPU load the serial port can loose some characters if placed in autobauding at high speeds. Therefore if you encounter this problem fix the baud rate with +IPR command.
I’ve seen this person describing the problem:
Q - I have noticed a limit to the script file that can be sent using “AT#WSCRIPT”. I have found it to be approx 7,000 bytes. To upload scripts larger than this I have to do it through Python, using file commands. This isn’t a problem, more a point of interest. Also there appears to be a limit to the script size that Python can compile. I think it is approx 13,000 bytes. I am still trying to get around this one. My question is, is there a way I can pre-compile a script on a PC? I could then upload the file using Python’s file commands.
A - Actually the script upload is not limited. The the max size of a single script on the latest software is 2^32 = 4GB. The previous limit was 64KB.
The script upload must be performed at 115200, 8N1, with hardware flow control active.
I’ve got screen set correctly:
screen -S rs -T vt100 /dev/ttyUSB0 115200,crtscts,-parity,-cstopb
Relevant bits from stty man page:
- [-]crtscts
enable RTS/CTS handshaking
csN set character size to N bits, N in [5…8]
[-]parenb
generate parity bit in output and expect parity bit in input
-evenp same as -parenb cs8
[-]parity
same as [-]evenp
[-]cstopb
use two stop bits per character (one with `-')
I’ve got autobauding disabled and hardware flow control is enabled:
AT+IPR?
+IPR: 115200
OK
AT+FLO?
2
OK
AT&V
DTE SPEED : 115200
DTE FORMAT : AUTO
GSM DATA MODE : Not Transparent
AUTOBAUD : +IPRxxx00=NO
COMMAND ECHO : E1=YES
RESULT MESSAGES : Q0=YES
VERBOSE MESSAGES : V1=YES
EXTENDED MESSAGES : X1=YES
LINE SPEED : F0=autodetect
CONSTANT DTE SPEED : YES
FLOW CONTROL OPTIONS : &K3=HW bidirect.
ERROR CORRECTION MODE : RLP
CTS (C106) OPTIONS : &B2=OFF while disc.
DSR (C107) OPTIONS : &S3=PHONE ready->ON
DTR (C108) OPTIONS : &D0=ignored
DCD (C109) OPTIONS : &C0=always ON
RI (C125) OPTIONS : \R1=OFF dur. off-hk
C108/1 OPERATION : &D4=NO
POWER SAVING ON DTR : +CFUN:1=NO
DEFAULT PROFILE : &Y0=user profile 1
OK
This is the status line Screen gives me:
(1,3)/(80,24)+1024 +flow G0[BBBB] {RTS (CTS) DTR DSR (!CD)} 0(ttyUSB0)
And here is the part of the Screen man page which (apparently!) explains it:
For tty windows, the info command shows some of the modem control lines in the status line. These may include ‘RTS’, ‘CTS’, ‘DTR’, ‘CD’ and more. This depends rather on on the available ioctl()'s and system header files than on the physical capabilities of the serial board. The name of a logical low (inactive) signal is preceded by an exclamation mark (‘!’), otherwise the signal is logical high (active). Unsupported but shown signals are usually shown low. When the CLOCAL status bit is true, the whole set of modem signals is placed inside curly braces (‘{’ and ‘}’). When the CRTSCTS or TIOCSOFTCAR bit is true, the signals ‘CTS’ or ‘CD’ are shown in parenthesis, respectively.
For tty windows, the command break causes the Data transmission line (TxD) to go low for a specified period of time. This is expected to be interpreted as break signal on the other side. No data is sent and no modem control line is changed when a break is issued.
Cheers, Dave.
Edit:
So I’d mistyped crtsrts (I put crtrts and screen doesn’t check the arguments, pro-tip: check your options using stty before you use them for screen!).
Problem is now it’s just hanging on me when I send the file, GNU Screen becomes totally unresponsive and I end up having to reboot the box to get the serial device unlocked again.
The “Slurped 14807 characters into buffer” message that usually disappears after a couple of seconds stays on the screen indefinitely. No idea what’s going wrong here, I’m sending the file with https://gist.github.com/968694.
Edit2:
Found someone in a similar situation, no solution given though 
http://www.roundsolutions.com/forum/thr … AT+WSCRIPT
Edit3:
I’ve tried another USB to serial adapter, same problem. Just ordered a PCI serial card and wire, I’ll update this if it helps.