Serial Communication Extender problems with pWaitfor

Keywords:     pComOpen	pComControl  pWaitfor

Question:

I'm having problems with the Serial Extender software. I'm capturing the serial communications in a capture log, and I am getting LOTS of data transmission problems.
I support all the "road warriors" at my company and have done so for years. I live and breathe modems, serial communications and telephone lines. If I was my own customer, I'd suspect a dirty telephone circuit or a bad modem, but when I run any other modem application such as, HyperTerminal, Dialup Networking, Procomm, etc. everything works fine. I've got an analog line pulled into my office here - one of the most modern facilities in the area - and I've used it perfectly for years. My modem is new as of about 3 months (Megahertz XJ-CC4288 flash upgraded to a 33.6), and I also use a USR 56K modem I'm evaluating. All new, super clean, modern stuff.
However I don't doubt noise on the line. That just comes with the territory of modem communications. It happens every time we dial up, but the other applications seem to be able to deal with the problems better... somehow...
It seems I have one of two problems...

Something is wrong in my coding, maybe in the modem setup commands in pComOpen or pComControl. Even with all my years of experience, I don't claim to have my PhD in modems. I notice that some applications use 8N1 to dial CompuServe and seem to work fine. I don't understand...
Here's a snippet of my code:
pcomopen("COM3","0","57600","7E1","RTSRTS") pmodemcommand("5999986","ATZ") pmodeminit("5999986") pmodemdial("5999986","1","9w214-720-9183") pmodemconnect("5999986") ;Here I get:[ ***** RECEIVE PARITY ERROR ***** ] pputline("5999986","") pputline("5999986","") pwaitfor("5999986","Host Name:","+","0","10000")
Puzzled, and waiting for your reply.

Answer:

8N1 means there is 8 data bits and no additional parity bit.
Compuserve around here leastways uses 7E1 which is 7 data bits and 1 parity bit (set to Even). I would use the same settings that your other programs that reference CIS use.
I don't see any "overrun" errors which indicates your machine is fast enough to handle both the communications and to write to the log file at the same time.
New modems don't mean much. Different brands and individual modems sometimes have problems talking with each other.
PPP Dialup networking etc, send checksummed packets of data so they can recover from errors.
The closest is Hyperterminal. See what works in hyperterminal and use those settings. In the log I looked at, there looks like spurts of noise. In using hyperterminal on the same machine, is it clear or do you also see noise?
I'm not real sure why the noise is there. it seems to be so close to almost working. I notice that the FRAMING ERRORS message has gone away (from a previous message) -- seeming replaced by the parity error message.
What if you ditch the log and suck the data into a binary buffer. Then BinaryWrite the buffer to see what you have.

Question (continued):

I'm still having problems with my timeout values in the pWaitFor command. Attached is my source code and the code in question is the last pWaitFor command...
pCaptureLog("Begin timeout of 2 minutes") TOStart=Timedate() pCaptureLog(TOStart) timeouttest=120000 RetCode = pWaitFor(port,"Texas","+",0,timeouttest) ;timeout is 2 minutes! TOEnd=Timedate() pCaptureLog(TOEnd) If RetCode == 0 Then goto Abort
I've tried specifying a timeout value of 120000, "120000", and then using a variable like above (as in your examples). It APPEARS that the max timeout value is 2 seconds. If I set it to be 500 (half a second) the list gets very short, so I know WinBatch is reading the value. But no matter what I do, the list never gets beyond San Mateo, CA - which is about 10% of the way down the states list.

BTW, I'm getting clean data now, at least temporarily. I changed modems to a USR 56K PC card, and that's working very well. I'm using 7E1 while Hyperterminal is using 8N1. When I use 8N1 in WinBatch, I get garbage. I also uses RTSRTS in WinBatch and Hyperterminal uses RTS/CTS, but that isn't an option in WinBatch.

Answer:

The problem is that maybe you are trying to use the capture file to get your data for you (it's designed for debugging) rather than grab the data yourself and do what you need with it.

The capture buffers overflow and it quits.

Answer:

1. Try doing the pWaitFor for:
```
    Ho�t N��e:
```
Try 7E1. What happens?
Try adding pGetLastError(1) after pModemDial and after pModemConnect.

Question:

Here's my capture log after changing to 7E1, and adding the GetLastError.
As you can tell from the attached capture log, the first pWaitFor function call generates no parity error, but the second and third pWaitFor function calls gererate the "***** RECEIVE PARITY ERROR ***** " message, apparently without adverse affect. I also added the pModemInit function.
pcomopen("COM1","0","57600","7E1","RTSRTS") OK = 5999986 pmodeminit("5999986") OK = 1 pmodemdial("5999986","1","9-1-626-303-3869") OK = 1 pmodemconnect("5999986") OK = 1 pputchar("5999986","") OK = 1 \r pwaitfor("5999986","Host Name:","","0","30000") 0010RYU Host Name: [ #1 WaitFor string found ] pputline("5999986","WFMAIL") OK = 1 WFMAIL\r pwaitfor("5999986","Enter logon id","","0","30000") WFMAIL Connected to 0001 WELLS_FARGO Enter logon id: [ #1 WaitFor string found ][ ***** RECEIVE PARITY ERROR ***** ] pputline("5999986","WR3341IA") OK = 1 WR3341IA\r pwaitfor("5999986","Enter password","","0","30000") 33A Enter password: [ #1 WaitFor string found ][ ***** RECEIVE PARITY ERROR ***** ] pmodemhangup("5999986") OK = 1 pcomclose("5999986","0") OK = 1

Answer:

The receive parity error means the data we're receiving isn't what we were expecting.

Here are a few possibilities:

Your modem could be sick?
Noise on the line could cause the parity error.
Try other kinds of parity which might suppress checking:

Question:

Your modem could be sick?
I'll try it with another modem of the same model.

>Noise on the line could cause the parity error.
I suppose it's possible, but it seems too consistent to be the case.

>Try other kinds of parity which might suppress checking: e.g. 7O1, 7M1, 7S1.
I'll test them out.

Article ID:   W12577

Filename:   Serial Communications Problems with pWaitfor.txt

File Created: 1999:04:15:16:48:10

Last Updated: 1999:04:15:16:48:10

Database Search

TechHome

Serial Communication Extender problems with pWaitfor

Question:

Answer:

Question (continued):

Answer:

Related Question:

Answer:

Question:

Answer:

Question: