Phonebook dialer issue
#1
I'm using an updated Wimodem232 with my DOS PC running Terminate 5.0. The modem works great and is super easy to use.

I'm running into an issue that I can't seem to resolve, but I thought might be solvable using AT commands or a firmware update.

Terminate, being from the dial-up modem era, seems to expect some slight delay after the modem says "CONNECT" or "CONNECT 57600" before it exits to the terminal mode when using the build in dialer/phone book. But the Wimodem232 prints CONNECT and then immediately starts showing the text that the remote BBS is sending. As a result, Terminate is still in the dialer window when the BBS starts probing the terminal capabilities, and when Terminate finally does drop into the terminal it's too late and the ANSI autodetection is over and I'm left with an ASCII BBS session. I'm thinking that either the Wimodem232 is too fast overall for Terminate, or Terminate has some kind of hard-coded time it waits for modem negotiation to happen and the Wimodem232 doesn't use up all that dialing time. 

So my question: Is there a command that can introduce a pause/wait time between when the modem "CONNECT" message appears and when it starts delivering data to the computer? In other words, a pause that gives the terminal program time to parse the CONNECT message and drop to terminal before the first data starts arriving.

Thanks in advance.
Reply
#2
As soon as the WiModem232 has data it relays it, just like a real modem does. Ironically, there is actually a substantial delay period due to the TCP/IP packets having to traverse the internet, through your router, and to the WiModem232. If anything I would have expected a question why the WiModem232 is too slow after negotiating a connection.

Just like a real modem, I can't hold off data that is being received (the buffer is very small).

Have you verified that it is really a problem with the phone book delay? Have you manually entered the phone number (URL) and checked to see if the ANSI mode is picked up automatically?
Reply
#3
(09-02-2020, 07:16 PM)admin Wrote: Have you verified that it is really a problem with the phone book delay?  Have you manually entered the phone number (URL) and checked to see if the ANSI mode is picked up automatically?

Yes, it's definitely the phone book because if I dial the BBS's manually from the terminal it negotiates the terminal type just fine, ANSI and all. I found an option to lower the dialing wait time to 1 second, but it's still not short enough as it seems that most Synchronet bbs's detect the terminal type immediately after CONNECT. And it won't allow me to enter 0 seconds of wait time, otherwise that would be perfect. I know the issue isn't with your hardware, but I was hoping that there was some feature or AT command that could help me. I even tried using commas as pauses in the URL like what used to work with phone numbers, but no success.

Maybe I'll just try a different terminal program, although Terminate 5 is incredible compared to the old ones I used to use.
Reply
#4
Even though you said it can't really be resolved with the modem, I'm sharing a video of the problem for posterity sake in case anyone has this issue in the future:

https://photos.app.goo.gl/WNKzZNn2P1AKedcU6
Reply
#5
Being that it seems that BBS is connecting through a Telnet portal, are you using AT*T1 prior to dialing this? You might try that before attempting the phonebook dialing to see if that makes a difference.
Reply
#6
(09-03-2020, 01:01 PM)admin Wrote: Being that it seems that BBS is connecting through a Telnet portal, are you using AT*T1 prior to dialing this?  You might try that before attempting the phonebook dialing to see if that makes a difference.

I tried it both ways (AT*T0 and AT*T1) but it didn't have any effect.

Thank you for your ideas though. Seems that I'll just need a different comm program that reacts faster after CONNECT.
Reply
#7
I am looking into this a bit. Don't give up yet. Smile
Reply
#8
Yeah i was thinking that maybe there could be an option to have the modem create the connection, assert the CD signal, slightly pause, send a CONNECT message, then pause again slightly, then change to data mode. But all those pauses require buffering, as you said.
Reply
#9
Ok, so it seems that there is an S register (S9) that controls this exact function.  I have it supported in the sense that you can set/read the value, but it doesn't do anything.  So, I am implementing it.  When did you get your WiModem232? I made an early version of the hardware and the v2.0/v2.1 versions.  I can put up a test version for you to download and try.

What I don't know right now is if the CONNECT message itself is what is triggering your program's 1 second delay, or if it is the DCD line (or both).  It may take a couple of versions of BETA software to make this work, but I am pretty sure I can do this - providing my theory is correct on how to hold off the incoming connection without actually losing any data.  The default timeout period for a modem is 0.6 seconds.  So, you might have to increase the time to be >1 second.  That would be done with: ATS9=xxx where xxx is the value in 1/10ths of a second.  The stock value is 6 (for 6/10ths, or 0.6 seconds).  So a value of 10 would be 1 second.

Let me know what version of the WiModem232 you have - I have a version ready to test!
Reply
#10
I have the latest version of the hardware (just bought it a few weeks ago) and I'm running firmware 3.04 currently.
Reply




Users browsing this thread: 1 Guest(s)