TROUBLESHOOTING


Problem:
Telix and the modem do not seem to be able to detect busy signals.

Solution:
Some modems (especially older 1200 bps units) do not have the capabil- ity to detect busy signals. Assuming yours does, you'll still probably have to edit the default modem Init String. The X1 that Telix uses in the string to be compatible with all modems does not enable busy de- tection in most modems. Try a value like X3, X4, or higher.


Problem:
When the QDHost Mode script is run Telix always thinks that a caller is online and immediately asks for the caller's name or Telix always says that a Hang-up operation failed even when it did in fact success- fully hang-up the modem.

Solution:
Your modem is almost certainly overriding the true state of the Car- rier Detect signal. This is the factory default on most modems, but should be disabled. For proper operation, Telix needs to see this sig- nal on when connected to another computer, and off when not. If your modem has dip switches, as do most 1200 bps units and all US Robotics external Couriers, switch number 6 usually controls this and must be in the up position. If your modem does not seem to have any dip switches (look carefully, sometimes the front needs to be popped off), it is probably controlled solely by software commands, as are most 2400 bps units. Just a few examples of these are the Hayes 2400, ATI 2400etc., GVC 2400, and many others. For these modems, adding &C1 in the modem Init String (before the final ^M (Carriage Return is a good spot)) will configure the modem properly.


Problem:
When trying to use a multi-tasking system like MS Windows, Topview, or DoubleDOS, with Telix in the background, window displays bleed through to the active partition.

Solution:
In the Telix Configuration Menu, select the 'Screen and colors set- tings' option, then select as the Screen Write Mode, 'BIOS calls used for writes'. Screen updating will be slower but will not bleed through.


Problem:
When redialing Telix does not seem to know when a connection has been reached.

Solution:
Telix knows when a connection has been reached in one of two ways: when it receives a Connect string from your modem, or when the Carrier Detect signal turns on (if it was off). Make sure that the Connect string is properly defined in the Configuration Menu, or that your mo- dem does turn on the Carrier Detect signal regardless of whether or not there is a connection.


Problem:
Telix doesn't work with a certain modem.

Solution:
Telix is set by default to use the Hayes 'AT' modem command standard. There are modems that are not Hayes compatible however, and use other commands to dial, hang up, and perform other tasks. Make sure that if your modem is not Hayes compatible Telix has been properly configured to its commands.


Problem:
When trying to use the DOS Shell, or another function that uses DOS, Telix warns that it can not find a file called COMMAND.COM, and aborts the function.

Solution:
The file COMMAND.COM is the DOS command interpreter. Telix must be able to find it to use many DOS functions. The location of COMMAND.COM is stored in an environment variable (explained in your DOS manual) called COMSPEC. COMSPEC is set at boot-up, but if you boot of a floppy and then change to another floppy or a hard disk, it will not point to the right place anymore. In short, make sure that COMSPEC always points to the location of COMMAND.COM, or that COMMAND.COM is in the current directory.


Problem:
When calling some systems, especially large ones such as Compuserve or the Source, all incoming characters look like garbage.

Solution:
The communications parameters are probably wrong. Most of these sys- tems need a setting of Even parity, 7 data bits, and 1 stop bit. This is different from the normal standard of N81 used for most bulletin boards.


Problem:
When running Telix, it reaches the "initializing modem" screen but won't go any further.

Solution:
Unfortunately, the solution here is not simple, and requires some knowledge of hardware. If you are not comfortable with configuring or jumpering your hardware, please contact a qualified computer consul- tant or service shop. The problem is likely that two devices in the computer wish to use the same part of the computer at the same time (called using the same interrupt). This will be the case with internal modems on COM3 or COM4, when you have other serial devices (mice, Sound Blaster cards, network interface cards, or other interrupt driven devices). By default, COM1 shares an interrupt with COM3, and COM2 shares with COM4. Only one device may use an interrupt at a time. You should try to place your internal modem on an unused interrupt (IRQ 5 is free in most AT or 386 class systems), and then tell Telix under the Configuration menu that COM3 or COM4 now uses IRQ5.


Problem:
During transfers with a high speed modem, many CRC and/or timeout er- rors occur.

Solution:
First ensure that CTS/RTS hardware flow control is enabled and that DSR/DTR hardware flow control is disabled both in Telix under the Con- figuration menus in the Terminal Options section and in your modem (refer to your modem manual for instructions on setting up your modem properly, or use the MODEMCFG.EXE program). If this fails, it may sim- ply be hardware limitations. Sometimes such hardware limitations can be circumvented by running Telix with the /D parameter.

Many high-speed modems, especially in a multitasking (Windows, DESQview, TopView, etc.) environment or on XT or slower AT-class ma- chines are simply too fast for the hardware, and may need some help to prevent lost characters. A UART (Universal Asynchronous Receiver- Transmitter) is a chip found on every serial card or internal modems. Most serial cards or internal modems come stock with 8250 or 16450 chips that are not rated for high speed modems. A replacement chip called the NS16550AN will likely eliminate such problems.


Problem:
When I run Telix from my menu program it tells me "Unable to find/open ANSI.KEY" and goes back to the menu program.

Solution:
ANSI.KEY is a file required for Telix operation, but due to the menu not changing to the Telix directory, Telix cannot find this file. Telix expects to find all of it's system files in the current directory or in the directory pointed to by the TELIX environment variable.

An environment variable is a setting that DOS can look at (or other programs, like Telix) to find out certain information it needs.

By placing the command:

SET TELIX=C:\TELIX

in your AUTOEXEC.BAT (modified for your own Telix path, of course) Telix will then know to look there for all of it's files if they are not in the current directory. There should be no spaces in the command as above, other than between SET and TELIX.


Problem:
I have call waiting on my phone line and whenever someone calls me while I'm online, I get disconnected.

Solution:
Call waiting is usually disableable on outgoing calls only. Contact your operator or phone company to determine if it can be disabled, and if so, what the codes are in your area. In many areas, it is *70, so we will use that as an example.

First, check your modem manual to insure that the modem is capable of dialing all the necessary characters like * or #. If not, you will have to do this by hand on your phone before each call, or ask the operator if there are alternatives (often 1170 will work, but it takes longer).

If your modem CAN dial the needed characters, or you are told of a suitable substitute, edit the dialing prefixes under Telix's Config:

ALT-O - Modem and Dialing - Options B,C,D

Insert after each "DT" (or DP if on pulse dialing) the appropriate call waiting cancel string. Note that often a comma is necessary as a pause to get a second dial tone. Once this is saved permanently to your Telix config ("W"rite setup to disk), you're set. Most often these will be:

ATDT*70,


Problem:
I have a new 14,400 bps modem, but Telix doesn't support 14,400 as a speed option.

Solution:
This is one of the great misconceptions about high speed modems, so you're not along in wondering this. Let me try to detail why it doesn't matter, and at the same time give you a bit of an idea what's going on behind the scenes when you call another modem...

The link to get from your computer to the other computer looks much like this:

     Telix <--> Your modem <--> Their modem <--> Their computer

         DTE rate        DCE rate         DTE rate
          38,400          14,400           57,600
As you can see, it is really a series of three links; one between your computer and your modem, one between the two modems, and one between their modem and their computer. What might surprise you is that each of these three rates can be, and often are, completely different, as above. So you know, DCE stands for Data Communications Equipment (i.e. a modem to modem link) and DTE is Data Terminal Equipment (i.e. terminal to modem link). You are not concerned with the final link, the remote DTE rate. That is up to the remote site, and does not matter at all to you. Once the data leaves your modem, and is received by theirs, it is out of your hands.

Your modem likely has either MNP-5 or v.42bis data compression built in. For transferring non-.ZIP files, these modems can be extremely efficient in compressing the data before sending it -- sometimes as much as 4 times compression (25% of the original size).

If the modems can take 1000 characters from Telix, and then turn it into perhaps as little as 250 characters with compression, your modem still transmits at 14,400 and would need 1000 characters from the comm program to transmit a mere 250 characters. In order to keep the DCE link flowing with data non-stop, Telix has to send data to your modem at 4 times the speed the modem is talking to the other modem (in the best case, which almost never happens). Thus, the DTE (Telix to modem rate) must be higher than the DCE (modem to modem rate) by a good margin, or the modems will sit idle frequently, waiting for the comm program to supply it with enough data. Since you have no way of knowing how much the data will be compressed, or at what speeds the two modems will actually connect up at, you should ALWAYS leave the DTE rate on your end (the link between Telix and your modem as specified in the Telix configuration) locked in, or fixed, at that high rate that can accommodate the most efficient case, since that most efficient case can occur at any time.

That's why you're always advised by MODEMCFG.EXE to set the comm program's speed, as well as all dialing directory entries (no matter how fast the board actually is), to a speed higher than the 9,600 or 14,400 you really have. Typically, you'll be told to use 19,200 or 38,400 (nowadays, typically 38,400, and even some will say 57,600). But the important thing is, that speed is constant. Your DTE (program to modem rate) always stays the same, so that when that most efficient case comes along, you're ready.


Problem:
When trying to transfer a file, telix just sits there saying "Waiting to send." or "Waiting to receive" but nothing ever happens.

Solution:
When a user is downloading, the other system is by definition uploading to him. BOTH systems must know exactly what is happening at every given moment, and this is especially true at the beginning of the transfer.

First the downloader must tell the remote system (the one to be downloaded FROM) that s/he requests a download. On most systems, this is accomplished with the "D"ownload command.

The sending system will then ask the downloader to choose a protocol. You may choose any one that Telix supports, but we recommend Zmodem if it is available, and 1K-Xmodem (sometimes labeled Ymodem) if Zmodem is not available. In any case, the important thing to remember is that BOTH the sender and the receiver must be using the same protocol, and it must be agreed upon in advance.

Perhaps before choosing a protocol, you will be asked what files you wish to download. Then the system may tell you that it is ready to send the files. If you have selected Zmodem, and have Zmodem auto- downloads on in Telix (the default) you should not have to do anything more. Telix will sense the Zmodem transfer coming and go into ZModem receive mode. Sometimes this will appear as "garbage" like an up arrow, a bunch of asterisks, and numbers like 0's and 8's. This is a signal to start!

The most important thing to remember when downloading is that first you have to tell the other system what to send and how to send it, and let it get started. As soon as the other system starts, you generally have about 30 to 60 seconds to start your receive with the SAME protocol. It is crucial that both sides know that a transfer is taking place. You cannot start yours early, or the other side will never send the file.

Thus, don't hit Alt-R (or PgDn) until you are *sure* the other side is ready to send, and ready for you to tell it that you are ready to receive (ALT-R does this automatically).


Problem:
When trying to compile a script I get the message "Unable to open file" even though I know the script is present.

Solution:
Some OEM versions of DOS 2.11 (notably, the Tandy DOS burned into the 1000 HX) are incompatible with the compiler used in these cases. This does not apply to Telix itself.

It is highly recommended that you upgrade your DOS if possible. For users with the DOS burned into the ROM of the machine, you may boot from a system floppy of a higher DOS system to compile scripts.


Problem:
When I start a download, the transfer window disappears very fast, with a message that looks like "Unable to open file", and no transfer takes place.

Solution:
Telix expects to be able to open a new file in the subdirectory you have defined for the Download Directory under ALT-O/Filenames and Paths. If this subdirectory does not exist, that will cause this message to appear:

"Unable to open file!"

This is a sure sign that you need to check your configuration in this area, and either create the defined subdirectory from the DOS prompt with the MKDIR command, or to change the configuration under ALT-O/F to reflect the location of an existing path.


Problem:
When I transfer a file, sometimes letters flash in the lower right corner of the transfer window.

Solution:
This is completely normal, and signifies a "flow" control, or a signal to Telix or the modem to slow down or stop momentarily. It signifies that things are in good working order.


Problem:
How do I telix to operate reliably under Microsoft Windows?

Solution:
TELIX.PIF included with Telix is a Program Information File for Windows that should allow best operation of Telix under Microsoft Windows. Windows doesn't offer the best of communications handlers, though, and for best communications results under Windows, we recommend a Windows-based program. deltaComm is currently programming a Windows comm program expected to be released in the first half of 1994.


Problem:
My modem requires compatible software to use the MNP features of my modem, or it says it needs RPI compatible software. Is Telix compatible in this way?

Solution:
No, it is not, and there is little likelihood that we will support RPI or software MNP in the near or distant future. RPI is an attempt by Rockwell and the modem manufacturers to create a cheaper modem (by about $5) by pushing off some of the hardware implementation into software. We disagree with this for the sole reason that software cannot be as efficient as hardware (esp. when coprocessed), and that these functions truly belong on the hardware for efficiency and speed. Most comm developers we know feel the same way and without our support the manufacturers will have to go back to putting these functions on the hardware -- where they belong.

Our recommendation is to take the modem back to the place of purchase, and don't leave until you get a REAL MNP/v.42bis modem at exactly the same price, because what you bought was not what you thought you did, and the only way the industry will stop these shenanigans is for the ones being taken advantage of to stand up for themselves and do something about it.


Problem:
We have our modems on a network and we need a network version of Telix in order to access them. Does Telix have network support built in?

Solution:
Networking a comm program, or using a modem across the network as a resource requires two things.

1) The network must be NETBIOS compliant.

2) The comm program must use the BIOS (Int-14) for comm routines. Telix normally bypasses the slower BIOS and writes directly to the comm port for speed considerations, making it incompatible with networks.

However, we have developed a version of Telix which uses the Int-14 calls, and it is now available as a separate product. please call our sales staff for more information about Telix for Networks.


Problem:
When I run QDHost it says "Either the upload or download directory as defined in the Host config does not exist" and then aborts. What now?

Solution:
If you receive this message when running the QDHost mode then you need to do the following:

From Telix Terminal mode (the blank screen that you are at after the opening screen goes away), press ALT-G, and type "QDCONFIG". The QDCONFIG.SLC script must exist in the same directory as QDHOST (i.e. in the script directory as defined under ALT-O/Filenames).

You will then see a menu that pops up something like this:

     A: Level 1 password       : pass1
     B: Level 2 password       : pass2
     C: Remote Shell password  : shell
     D: Shut down host pass    : shut
     E: Host download directory: C:\TELIX\HSTFILES\     <------
     F: Host upload directory  : C:\TELIX\HSTFILES\     <------
     G: Connection type        : Modem
     H: Modem locked at >= 9600: No
     I: Exit without saving changes.
     J: Exit and save changes to disk.
The indicated lines are the ones that need to be changed. You can either Exit without saving and then do MKDIR with the above paths:

MKDIR C:\TELIX\HSTFILES

or, better, is to change options E and F above to paths that you know already exist (NEVER set these equal to your Telix subdirectory!), and then "Exit and Save Changes to Disk". For more information concerning DOS paths, please consult your DOS manual.


Problem:
When calling from our office we have to use a credit card number, but the whole number won't fit in the dialing directory. How can telephone credit cards be used with Telix?

Solution:
The MODEM is going to be your bottleneck here. Most modems cannot take as many characters at once as a comm program can send out. The vast majority of modems have a 40 character command string limit, which must include the at the end, and the ATDT (or ATDP) at the beginning. Spaces, dashes, and any directives for MNP and such in the dialing prefixes also count.

Telix can, with the use of long distance codes, send much more than this, but the modem will not likely respond to this, since anything past 40 characters is simply ignored (and this includes your at the end).

Many long distance companies have gone to 13 character card codes to protect you against fraud, and this is a good idea. However, it does limit you via your modem (again, Telix is not the limitation here).

In the number you wish to dial, rather than making the number in the directory read: "1-919-481-9399"

Save space (it's STILL tight) and make it read: "1-919-481-9399!"

The exclamation point tells Telix to append the contents of that code, and the code can be edited to include any sequence you wish, under Alt-D/Other/Edit LD codes.


Problem:
Telix seems to be grossly optimistic when estimating the length of time it will take to transfer a file. Its usually about four times slower than Telix thinks it will be. Why is this?

Solution:
Previous versions of Telix merely estimated transfers based on the speed that Telix dialed at (the DTE), even though this could be up to four times greater than the actual connect speed.

Telix 3.22 now makes its best attempt to read the actual connect speed (DCE), but needs a little cooperation from the modem. Telix cannot determine the DCE on its own -- it must rely on the modem to report it.

Telix must accept the rate that the modem offers -- it has no way to "validate" it. The best way to demonstrate this is to dial a number without using the dialing directory. Type ATDT and the number, and press Enter. Watch for the first string that displays. It will be something like:

CONNECT 14400/ARQ/V42BIS/LAP-M

If you have a vanilla 2400:

CONNECT 2400

If the dialing directory had been used, Telix would have read the connect rate as 14400 in the first case and 2400 in the second. (Telix reads the connect rate as the first number to follow the connect string on the same line as the connect string). Some modems, however, (notably newer v.32bis modems) can be configured to return very detailed information like this:

CARRIER 14400

PROTOCOL: LAP-M

CONNECT 57600/V32BIS/V42BIS

Now, if your connect string was "CONNECT", the value is not the 14400 you wanted, but the 57600 you didn't want. In this case, you need to find the command in the modem manual that disables extended result codes (often the S95 or S44 registers) and reverts to the simple CONNECT 14400/ARQ/V42BIS string as above -- then Telix will get the connect string you wanted.

Another option above (but not for all such modems) is to change the connect string to match the word right before the number. Above, you'd change the connect string to CARRIER. This one won't always work, and it is best to disable extended result codes if you want correct estimates.

Some modems do not return a correct response string at all, such as the older US Robotics HST Dual Standard 1441 (v.32/ 9600) modems. They return 9600 even if the connect was at 14400, and your estimates in such cases will err by the difference.


[Table of Contents]
Page layout and HTML programming by Spyros Spyrou