Uploading data from a Psion via a Nokia 6310i - problems.

Hi All,

This problem seems to be widely acknowledged, but I was wondering if
anyone who knows a bit more about AT commands and the like than I do
can suggest a solution.

There is a known problem with sending large (>10k) files via a Nokia
6310i over IrDA from a Psion 5mx PDA. Basically, the phone connection
to the ISP is dropped randomly when sending large amounts of data.
(Receiving data is fine.)

I have recently been forced into using a 6310i (my Ericsson R520 died)
and this problem is really bugging me. There are numerous solutions
suggested online, mostly involving switching to XON/XOFF flow control,
but these don't seem to work. Similarly, using the Mobile Connectivity
Updates from Psion are supposed to help, but they don't.

I have seen this problem with 2 different Psions and 3 different
6310i's. It does not happen when using the Nokia PC Suite to connect
to the phone via IR from a laptop, and it does not happen when using
the Psion to connect to an Ericsson phone. Hence there is some
incompatibility between the Psion and the Nokia.

Looking at the Psion's comms log file, I have noticed something. The
last commands before the call ends (which are logged) are usually
something along the lines of :

Tx:AT
Rx:
OK

Tx:ATO
Rx:
NO CARRIER

Tx:ATH
Rx:
OK

Now, from reading some of the documentation on the web, it looks as if
the Psion has got into a mode where it has issued (or thinks it has
issued) an escape sequence ('+++') to the Nokia - ATO is the command
to return to online mode after an escape.

What I suspect is happening is that the Psion issues an escape command
to the Nokia, and somehow by the time it is ready to return to online
mode, the Nokia has disconnected. The question is why the Psion is
issuing excapes while in the middle of sending data - under what
circumstances will this happen? AT commands are used to configure the
modem, and I would have assumed that once connected, this shouldn't be
necessary. Are XON/XOFFs sent via escape sequences? Is there some way
of stopping the Psion from sending escapes? What does the Psion think
it is doing while in command mode? Is it sending some AT command which
hangs-up, or which is interpreted by the Nokia as a hang-up request?

I don't know if this is fixable - I'm sure Psion aren't interested in
fixing it, and I doubt that Nokia care that much. I'm wondering if
some judicious hacking of the GSMBSC.TSY telephony stack on the Psion
with a hex editor could change a command sequence to stop this, but I
don't know enough about modem command sets to know where to look.

Any advice gratefully received - please post to the group if you have
any ideas.

Simon

(Apologies for not following the thread correctly - Google Groups
seems a bit slow this morning....)


"Chris Malcolm" <cam@holyrood.ed.ac.uk> wrote in message
news:bhg98d$slj$1@scotsman.ed.ac.uk...

> I tried sending some large files from my Psion 5mx via infrared and
> the Comms App to my office computer via a 6310i. YMODEM, which works
> fine the other way, dropped out at first 10K for some reason. But it
> also does this when connected via data cable. So I tried plain ASCII,
> and transferred several 1/3 Megabyte files by infrared successfully
> with no problem. Incidentally, I noticed that speed of transfer varied
> noticeably with mobile signal strength.

That's interesting. I hadn't tried any plain ASCII, but if that gets
through ok, then it is probably a problem with data bytes in the
transmitted file being interpreted as control codes which cause the
connection to drop. I've read recently in some modem documentation
that XON/XOFF flow control is not recommended when sending binary
data. I would have thought that the protocol was designed to cope with
this, but maybe it isn't...

> Can you be more specific about the circumstances of your problem? I
> seem to recall there was some strange interaction with another
> apparently completely unrelated Psion 5mx parameter which when set
> appropriately made this infrared dropout problem go away.

OK. I am using RMRFTP to upload files to my website. I am using HSCSD
on Orange (although turning that off doesn't seem to make any
difference). I have tried lots of different setups on the Psion, but
the one I have settled on as being least bad (!) is :

Speed : 115200
Connect : Infrared
Fax Class : Auto
Init string : AT&F&K4 (factory defaults, XON/XOFF flow control)
Data string : AT+CBST=14
Flow control : Software
DSR : Not checked
DCD : Not checked
Modem : Mobile

This works fine for downloads, but uploads tend to fall over after 25k
or so. On occasion something gets through - I am testing with a 75k
SIS file - but it probably works no more often than 1 time in 20.

I have tried nFTP - same problem.

If I enable connection logging (C:\Logs\Etel), the file shows all the
initial handshaking as fine, up to a good CONNECT string. The last few
lines in the file tend to show something like :

Tx: AT
Rx:
OK

Tx: ATO
Rx:
NO CARRIER

Tx: ATH
Rx:
OK

This looks to me as if the Psion has sent an escape sequence to the
phone at some point, and the line gets dropped while the Psion is
offline.

On occasion, you actually see the Psion send the escape in the log
file - something like :

Tx: AT
Tx: +++
Tx: AT
Tx: AT
ERROR

I have tried dropping the connection speed between the Psion and the
phone, and changing the flow control, but nothing seems to affect what
happens.

I have read that there are problems with IrDA if the Psion's
auto-power down timeout is set to > 30 minutes, but it is set to 3
minutes on mine.

Any bright ideas - I'm stumped! (As are Psion Teklogix - I'm tempted
to try and extract the GSM files from the latest ROM for the Netbook,
as the readme admits to a bug in Etel being fixed. It'd be interesting
to know if any Netbook users can get this to work...)

Cheers,

Simon

I

Simon Long wrote:
> Hi All,
>
> This problem seems to be widely acknowledged, but I was wondering if
> anyone who knows a bit more about AT commands and the like than I do
> can suggest a solution.
>
> There is a known problem with sending large (>10k) files via a Nokia
> 6310i over IrDA from a Psion 5mx PDA. Basically, the phone connection
> to the ISP is dropped randomly when sending large amounts of data.
> (Receiving data is fine.)
>
<snip>

> Are XON/XOFFs sent via escape sequences? Is there some way
> of stopping the Psion from sending escapes? What does the Psion think
> it is doing while in command mode? Is it sending some AT command which
> hangs-up, or which is interpreted by the Nokia as a hang-up request?
>
> Simon

Have you tried to change the flow control to RTS/CTS, AT command &K3
- this is usually works best in "normal" PC communications.

--

Mark²
Linux Registered User #324341

"Simon Long" wrote:

> I've read recently in some modem documentation that XON/XOFF
> flow control is not recommended when sending binary data. I
> would have thought that the protocol was designed to cope with
> this, but maybe it isn't...

Software flow control (using the XON/XOFF characters) cannot be
used reliably for binary data, as these two characters are very
likely to occur within the data itself. They will be
interpreted, and lost from the data stream, instead of being
passed transparently. Other things being equal, a single XOFF
will terminate data transfer.

Hardware flow control (using the CTS/RTS RS232 pins) is the
sensible strategy where binary data might be involved.

The real advantage of XON/XOFF flow control is that it can be
used over a simple 3-wire circuit (on long runs between buildings
for example).

John

simon@longnews.freeserve.co.uk (Simon Long) writes:

>Hi All,

>This problem seems to be widely acknowledged, but I was wondering if
>anyone who knows a bit more about AT commands and the like than I do
>can suggest a solution.

>There is a known problem with sending large (>10k) files via a Nokia
>6310i over IrDA from a Psion 5mx PDA. Basically, the phone connection
>to the ISP is dropped randomly when sending large amounts of data.
>(Receiving data is fine.)

I tried sending some large files from my Psion 5mx via infrared and
the Comms App to my office computer via a 6310i. YMODEM, which works
fine the other way, dropped out at first 10K for some reason. But it
also does this when connected via data cable. So I tried plain ASCII,
and transferred several 1/3 Megabyte files by infrared successfully
with no problem. Incidentally, I noticed that speed of transfer varied
noticeably with mobile signal strength.

Can you be more specific about the circumstances of your problem? I
seem to recall there was some strange interaction with another
apparently completely unrelated Psion 5mx parameter which when set
appropriately made this infrared dropout problem go away.


--
Chris Malcolm cam@inf.ed.ac.uk +44 (0)131 650 3085 DoD #205
School of Informatics, Edinburgh University, 5 Forrest Hill,
Edinburgh, EH1 2QL, UK. [http://www.dai.ed.ac.uk/homes/cam/ ]