🚀 go-pugleaf

"Phil" <phil@camusinc.com> wrote in message 
news:460132f4@newsgroups.borland.com...
> Stephan,
>> assuming you can bash bits on your embedded controller,
>> one way to insure that your problem only exists with latency
>> is to have the controller simply immediately return whatever
>> it receives, essentially turning it into a loopback connection.
>> send out a character, measure the round trip time, done.
>>
> I can connect directly from my PC to the controller using a serial cable, 
> and a command/response takes about 10ms at 19200.  Using a modem it takes 
> about 125ms.  The code is the same in both cases, which points to an issue 
> with my modem connection.  I just don't know if the issue is in the phone 
> system or in my  modem setup.

this is all stream of consciousness.... not to be read like a essay.


ok phil, you have the latency.
what I was suggesting before is useful for the next step.
with the embedded controller just back looping the data,
do a burst transmission, such as transmit OX or something 512 times,
and time how long it takes to accomplish this.

there are other factors that can slow down transmission, such as line noise
and line bandwidth. check the AT set, maybe the modems have a
signal quality report?

you could try kicking the baud down to 2400, check the round trip
command/response there

one thing that might be an issue is the embedded controller. you know
the controller uart talks to the pc uart well,
but how is it doing with the modem?

with all the components bolted together, you really need to isolate exactly
where in the chain things are breaking down.

consider, you had it ok when you went puter to embedded controller.
now, you have puter to modem. modem to modem.
modem to embedded controller.

maybe your modem on the embedded controller side can be configure to
loopback mode? that way, you can see the latency in the line itself.