Dialing with a modem

[kerry Farmer]

What is the easiest place to find some code for dialing and hanging up through a modem?

Does it work on a USB modem?

Thanks

[Dale Yarker]

to dial:
COMM SEND #nComm, "ATDT" + number$ + $CRLF
wait for MODEM to reply with "CONNECT", "BUSY", etc.

to hang-up:
SLEEP 3000
COMM SEND #nComm, "+++"
wait for MODEM to reply with "OK"
COMM SEND #nComm, "ATH0" + $CRLF
wait for MODEM to reply with "OK"

You didn't say if it was the MODEM AT commands you needed help with, or you needed complete PB code for COMM operations.

Have you looked in samples that came with PB install?

It will work with USB MODEMs if Windows makes a "COMx" to use in COMM OPEN when MODEM is connected to PC.

Cheers,

[Mel Bishop]

...COMM SEND #nComm, "+++"...

Very important. NO terminating $crlf or anything else after "+++". Just send that string and nothing else to kick the modem off-line and back to command mode.

This caused me some head-scratching when I was programming modems.

If you want a command list, try Googling "hayes at command set". Several pages will be displayed.

[kerry Farmer]

Thanks guys

This forum is truly magnificent

[kerry Farmer]

Originally Posted by Dale Yarker

It will work with USB MODEMs if Windows makes a "COMx" to use in COMM OPEN when MODEM is connected to PC.

How could I check this? Would this usually happen?

Thanks

Kerry

[Erich Schulman]

Very important. NO terminating $crlf or anything else after "+++". Just send that string and nothing else to kick the modem off-line and back to command mode.

One more thing. Most (all?) modems have a programmable guard time. You must allow at least that much time before and after the +++ for it to be effective. Otherwise threads like this would be unreadable for dialup users. You may be able to query the time from a S register. Otherwise, try some trial and error (maybe start at 2 seconds then go in .1-second steps up and down). You could also make this a user setting in your application, especially if a S register query fails.

I hope you realize you've opened a Pandora's box here There's a whole API for working with COM-less modems. Have a peek at http://en.wikipedia.org/wiki/TAPI and go from there. The program ZOC requires you to specify a COM port or TAPI, so a query might not be possible or surely its author would have supported it by now.

[Dale Yarker]

The guard time is in S12. The default is 1 sec. The SLEEP 3000 should be more than enough, even if somebody changed S12.

The guard time after sending +++ is simply a matter of not sending anything till the MODEM replies with OK.

The +++ does NOT cause the MODEM to disconnect from the distant MODEM or to hangup the phone line. It just tells it to listen to TX data for commands, and not pass it along to distant MODEM. ATH0 (ATention Hook zero) tells it hang-up the phone line.

Cheers,

[kerry Farmer]

[quote=Dale Yarker;290584]to dial:
COMM SEND #nComm, "ATDT" + number$ + $CRLF
wait for MODEM to reply with "CONNECT", "BUSY", etc.

QUOTE]

It works! It works!

I am using a serial port modem - that USB stuff sounded a bit heavy for me

One more silly and pathetic question please. How do I check the modem reply?

Thanks

[Dave Biggs]

./Samples/Comms/Comm.bas

has what you need!

[Michael Mattias]

>One more silly and pathetic question please. How do I check the modem reply

Well, if 'COMM SEND' sends, I would think there might be a 'COMM "receive"' or something like that....

But what I would probably do in Real Life is read the help file under Contents/Programming Reference/Serial Communications/Reading and Writing Data... if only because it sounds so promising.

[Cliff Nichols]

As Dave said

./Samples/Comms/Comm.bas

has all that you need, and from what I know is a heck of a good example to start with (Heck, I built my original PB software on it, when I 1st took the dive from VB to PB)

Over the years, things have gotten added, modified, rebuilt, but I like to think the core concepts are all what I found in the example (COMM SEND/COMM RECV)

Forget the device attached, whether it is USB or a true Serial device....once you have control of the port, all that matters is sending commands that the device understands (Modem/Motor Controller/Data Acquisition System...etc) and from my investigations they normally all USB that were at one time serial port devices, have a "Virtual COMM" so that your apps still work with their products.....After all it is called the "Universal SERIAL Bus" )

(and TRUST ME!!!!! when I say I would rather work with Serial protocols over a true USB protocol....you would spend many a night ...trying to figure that one out

In short I think Kerry had the most likely answer to your question

COMM SEND #nComm, "ATDT" + number$ + $CRLF
wait for MODEM to reply with "CONNECT", "BUSY", etc.

where the reply would be found with COMM RECV

[Erich Schulman]

We don't know who Kerry Farmer's target audience is: self, a single client/employer, general public, etc. That would make a difference.

I once had an icky USB modem that supported only Win9x. Even its virtual COM port driver was limited to DOS compatibility (COM1-4 with the common IRQ and port addresses for each). The PC I used it with had real COM1/2 on the motherboard, so that made using the virtual COM3/4 problematic. (I was using Win95C on that PC.)

Not all the drivers are bad. I have a scanner (the radio kind) and USB cable. I had no trouble using it on COM7 in Win2000.

If the target audience is the general public, you don't know what you're up against. Some users will have icky drivers. Some didn't install the driver because they never thought they needed to. And once they know, they may have lost the CD or floppy that came with the modem. Using TAPI at least gives you some assurance things will work and you may avoid a lot of tech support queries you can do nothing about.

OTOH, if you have a limited target audience (just your employer, etc.), you can survey what equipment is in use, test on it, and replace any recalcitrant devices or drivers with something easier to deal with.

[kerry Farmer]

[quote=Erich Schulman;290872]We don't know who Kerry Farmer's target audience is: self, a single client/employer, general public, etc. That would make a difference.
QUOTE]


This is an excellent point Erich

The answer is firstly for myself - but I always think about how my programs could be marketed to a wider user base.

As for progress - now I know it can be done, I have spent the last two days working on other programs in the suite - but I will be back onto the dialling program (which is the main operational program) tomorrow

Thanks to all for the advice.

[Michael Mattias]

As for progress - now I know it can be done, I have spent the last two days working on other programs in the suite - but I will be back onto the dialling program (which is the main operational program) tomorrow

Well, I would have made sure it could be done BEFORE I committed to the suite... but your experience is the same one I have all the time... you have to have all those 'support' pieces working first, or you can't test the 'main mama.'

When I was GM of a software VAR, I had one programmer who disliked the waiting so much she routinely asked to be on 'bug fix' duty... because on 'bug detail' she got little 'highs' every day, instead of going thru a couple weeks of creating support software before she could even see if the main program was going to work.

Worked out pretty well, since the other programmers generally hid in a supply closet if you asked for a 'bug detail' volunteer.


MCM

[Erich Schulman]

Then I'd say just COM port support for now. TAPI support can always be phased in later as time permits or when potential buyers request it.