Announcement

Collapse
No announcement yet.

Dialing with a modem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dialing with a modem

    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
    [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
    Kerry Farmer

  • #2
    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,
    Last edited by Dale Yarker; 13 Jul 2008, 01:09 AM. Reason: add USB part, add CRLF after ATH0 (thnks Mel)
    Dale

    Comment


    • #3
      ...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.
      There are no atheists in a fox hole or the morning of a math test.
      If my flag offends you, I'll help you pack.

      Comment


      • #4
        Thanks guys

        This forum is truly magnificent
        [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
        Kerry Farmer

        Comment


        • #5
          Originally posted by Dale Yarker View Post
          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
          [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
          Kerry Farmer

          Comment


          • #6
            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.
            Erich Schulman (KT4VOL/KTN4CA)
            Go Big Orange

            Comment


            • #7
              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,
              Dale

              Comment


              • #8
                [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
                [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                Kerry Farmer

                Comment


                • #9
                  ./Samples/Comms/Comm.bas

                  has what you need!
                  Rgds, Dave

                  Comment


                  • #10
                    >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.
                    Last edited by Michael Mattias; 16 Jul 2008, 07:43 AM.
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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

                      Engineer's Motto: If it aint broke take it apart and fix it

                      "If at 1st you don't succeed... call it version 1.0"

                      "Half of Programming is coding"....."The other 90% is DEBUGGING"

                      "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                      Comment


                      • #12
                        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.
                        Erich Schulman (KT4VOL/KTN4CA)
                        Go Big Orange

                        Comment


                        • #13
                          [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.
                          [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                          Kerry Farmer

                          Comment


                          • #14
                            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
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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.
                              Erich Schulman (KT4VOL/KTN4CA)
                              Go Big Orange

                              Comment


                              • #16
                                Originally posted by Michael Mattias View Post
                                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.'

                                You are absolutely correct Michael

                                This is what I meant to say.

                                I have a small piece of crude code which tests that I can dial and hangup. This is sufficient for me to empower myself and go on and do the system. All other benefits will be icing on the cake. Actually the control program will be quite difficualt - needs easy to use, fool proof systems - for people who may not be computer savvy. I know that I can do this.

                                So now I have got the technical stuff sorted - more or less - I will get onto the rest.
                                [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                                Kerry Farmer

                                Comment


                                • #17
                                  Just a few things I have learnt so far

                                  you have to go:

                                  DO UNTIL modem_input_data_length&>0
                                  modem_input_data_length& = COMM(#hComm, RXQUE)
                                  COMM RECV #hComm, modem_input_data_length&, modem_input_data$
                                  LOOP
                                  modem_input_data_length& = 0
                                  DO UNTIL modem_input_data_length&>0
                                  modem_input_data_length& = COMM(#hComm, RXQUE)
                                  COMM RECV #hComm, modem_input_data_length&, modem_input_data$
                                  LOOP

                                  The first one picks up the dialing information and the second one picks up the response

                                  On my setup the response to "engaged" or "no such number" both show as "busy".

                                  And you get no response at all if the call is answered. So I need to chamge the second do loop to time out when the call is answered - or have manual intervention I suppose

                                  Any thoughts anyone?

                                  Thanks
                                  [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                                  Kerry Farmer

                                  Comment


                                  • #18
                                    "On my setup the response to "engaged" or "no such number" both show as "busy"."

                                    Busy is American English for engaged, Hayes was a U.S. company so "busy" is the response built into the MODEM when it hears busy/engaged tone on the phone line. If I remember correctly "no such number" tone uses same frequencies as "busy" in different pattern, so MODEM responds with "busy" to that too.

                                    "And you get no response at all if the call is answered. So I need to chamge the second do loop to time out when the call is answered - or have manual intervention I suppose"

                                    If a human answers instead of another MODEM, your MODEM should say "NO CARRIER" The default time for this in the MODEM is 50 seconds. Are you waiting long enough?

                                    If after dialing, the call is never answered, the MODEM sends you "NO ANSWER".

                                    ----------------
                                    The manufacturer of the MODEM you have should have a download-able pdf on their web site for AT Commands and S registers. If you're going to do programming involving MODEMs, you're going to need it!

                                    [added] The owners manual, CD or floppy that came with the MODEM should also have this info!!!!

                                    Cheers,
                                    Last edited by Dale Yarker; 18 Jul 2008, 11:19 PM. Reason: add
                                    Dale

                                    Comment


                                    • #19
                                      Originally posted by kerry Farmer View Post
                                      Just a few things I have learnt so far

                                      you have to go:

                                      DO UNTIL modem_input_data_length&>0
                                      modem_input_data_length& = COMM(#hComm, RXQUE)
                                      COMM RECV #hComm, modem_input_data_length&, modem_input_data$
                                      LOOP
                                      modem_input_data_length& = 0
                                      DO UNTIL modem_input_data_length&>0
                                      modem_input_data_length& = COMM(#hComm, RXQUE)
                                      COMM RECV #hComm, modem_input_data_length&, modem_input_data$
                                      LOOP

                                      The first one picks up the dialing information and the second one picks up the response
                                      I haven't looked at the excellent example that came with the PB compiler for a while, but I'm 100% sure it uses a separate thread for the RECV loop. Your code above will result in an infinite loop if the modem doesn't respond, which is more than likely in certain situations.

                                      I used to deal with modems extensively back in the '80's and '90's, but this is 2008 - every one and every business I know has broadband. Good luck with this, but I doubt that there's much of a demand...
                                      --pdf

                                      Comment


                                      • #20
                                        Originally posted by Paul Franks View Post
                                        I haven't looked at the excellent example that came with the PB compiler for a while, but I'm 100% sure it uses a separate thread for the RECV loop. Your code above will result in an infinite loop if the modem doesn't respond, which is more than likely in certain situations.

                                        I used to deal with modems extensively back in the '80's and '90's, but this is 2008 - every one and every business I know has broadband. Good luck with this, but I doubt that there's much of a demand...
                                        you are absolutely right - I had thought I could always expect some reponse - but now I know that this is not true

                                        I am using the modem as a dialler - not for data as such. It is for a telemarketing exercise. Doies this affetc your remark about Broadband?

                                        Thanks
                                        [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                                        Kerry Farmer

                                        Comment

                                        Working...
                                        X