BGFAX's READ.ME file... Yes, there might actually be interesting stuff here! ----------------------------------------------------------------------------- This READ.ME text file has special notes for the following configurations: a. Auto answering b. Rockwell V.FC and V.34 modems c. FD 2.02 (free version) d. Adept-XBBS/2 e. Binkley f. USR owners g. Hayes owners h. ZyXEL owners i. Supra owners j. Multitech owners k. Zoom owners l. PPI owners m. PC Logic owners n. Hornet 28.8 VFC owners o. DesqView p. OS/2 q. PC Board for OS/2 r. RPI (Rockwell Protocol Interface) modems s. Remote Access Shell-to-Mailer mode t. EXAR-based modems u. Voicemail interface v. WinFOSSIL =========================================================================== Auto Answer (not Adaptive Answer) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One quick note relating to all setups: Do NOT use your modem in 'auto answer' mode. You must make your software physically send an answer string to the modem. Therefore, register S0 _must_ be set to 0. (S0=0). Any BBS or Fido mailer software that requires the modem answer in AUTO ANSWER mode is crap. Most software will send an answer string to the modem when the modem sends a "RING" response. AUTO ANSWER mode forces the mode to answer the call whether your software is ready to answer it or not. Sysops should never use auto answer. I am making this statement because many of the setup help files (*.TXT) for BGFAX require that the BBS/mailer software send answer strings to the modem. AUTO ANSWER is not ADAPTIVE ANSWER. They are two different things. Adaptive answering is required for BGFAX to receive both data and fax calls. Rockwell V.FC and V.34 modems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It should be noted that many of the Rockwell V.FC modems have flawed adaptive answering. (i.e., Many true data calls will be misinterpreted as fax calls.) You might want to keep an eye out for this. Many Rockwell V.34 modems suffer from the same flaw. Supra released firmware in December 1994 that fixed Rockwell's V.34 adaptive answering problem. (This was done just before the modems started to ship, so don't worry if you have a Supra.) Zoom released the 1.309 firmware in October 1995 that fixed Rockwell's V.34 adpative answering problem. This was done after tens of thousands of modems have been sent out. See the "Zoom owners" section of this file. I am not aware of any other Rockwell based modem companies that have bothered to fix (or obtain a fix from Rockwell) on this problem. How do you know if you have a Rockwell chipset modem? In terminal mode, type "AT+FMFR?" to report the datapump/chipset manufactuer. If you have bought a Rockwell based modem just recently, most likely, you are using current firmware and the adaptive answering bug is not present. FD 2.02 (free version) ~~~~~~~~~~~~~~~~~~~~~~ I strongly recommend using FD 2.12 rather than FD 2.02. FD 2.12 is much easier to set up with BGFAX and works much better. FD 2.02 can be forced to work with some modems (such as the Supra), but not all of them the way FD 2.12 can be used. Just say "no" to FD 2.02 and get FD 2.12. I provide excellent help files for FD 2.12 that describe, in detail, what you have to do to make it work with BGFAX. Adept-XBBS/2 ~~~~~~~~~~~~ Adept-XBBS has a box on its config screen relating to whether or not an "ATO" string must be sent to the modem if it encounters a "DATA" string. This is a powerful option that has not yet made it to other mailers, but if you use this option on a modem that does not require an "ATO", you will force your modem to hangup on all data calls. Most modems do NOT require the ATO. Some modems in Class 1 mode require the ATO. The Hayes Optima does NOT. Binkley ~~~~~~~ Make sure that you are using Binkley 2.60 or better. This 2.60 version of Binkley fixed bugs in the previous (2.59 beta and below) versions that prevented Binkley and BGFAX to interact with some modems. Again, MAKE SURE YOU HAVE BINKLEY 2.60 OR BETTER !!! Some people prefer to let Binkley internally receive the faxes, rather than using BGFAX to do it. You can do this, and use BGFAX's VIEW.EXE to view the received faxes. It might be necessary to add a /BO switch on the VIEW command line if you get nothing but bad scan lines when attempting to view a Bink raw fax file. USR owners ~~~~~~~~~~ Make sure DIP switch #5 is in the "SUPRESS AUTO ANSWER" position and make sure the S0 register is equal to 0. If you plan to use BGFAX to receive both faxes and data calls, be advised that this will NOT work with the following US Robotics modems... a. Sportster 14.4K modems (original series) because they does not have adaptive answering. Note that the newer Sportster VI and DSVD 14.4K Sportsters should work, because they have both Class 2.0 and adaptive answering. Also, some European versions of the original series Sportster 14.4K modems do appear to have adaptive answering, but it is unknown as to whether it actually works or not. b. All Courier modems slower than the 21600 v.32terbo model lack adaptive answering. (This means both Courier 14.4K and Courier 16.8K modems will not be able to take both data and fax calls.) c. The Courier 21600 v.32terbo modem does have adaptive answering and Class 2.0 fax, but it works so badly that I do not recommend people to use this particular modem with BGFAX. You can call USR to buy a new daughtercard to this modem that will upgrade it to 33600 v.34+. BGFAX _will_ work with the 28.8K modems (V.34 Sportster/V.34 Everything). Make sure you are using firmware version 09/20/96 (supervisor date). Ignore anything the USR manual says about fax commands. Also, it is normal for the FAX/ARQ light to "blink" when the modem is waiting for a fax call. The blinking means the modem is in "adaptive answering" mode. (NOTE: It is NOT normal to blink when a user is online. If that is happening, it means you have a noisy connection.) If you are using one of the DUAL STANDARD Courier modems, you may need to put a "B0" in your answer string to make sure the modem is prepared to answer all types of calls. See your Courier manual for more info on the ATB0 and ATB1 commands. The Sportster DSVD modem has a bug in adaptive answering mode that makes Class 2.0 adaptive answering behave like Class 1 adaptive answering. This means an "ATO" command will have to be sent to the modem when a "DATA" response is issued. This makes the DSVD incompatible with any kind of Fido Mailer (except Adept-XBBS for OS/2). The DSVD should be capable of taking data and BBS calls with BGFAX answering "/HOST /ATO" mode, but not with a Fido mailer. I've heard reports that the Sporster 28800 (non-DSVD) with firmware having a Supervisor date of 08/29/95 has a problem receiving faxes when in adaptive answering mode. It will behave like the Courier firmware dated 07/05/95 which causes 9600 faxes to be received at 7200, but they aren't recevied, just null bytes are recevied, so you end up getting empty pages, which makes these firmware releases useless. Sportster 288's with firmware 01/11/96 and other dates have a bad habit of spitting out garbage during Class 2.0 mode. The garbage will cause the fax session to fail. The Courier I-Modem has many fax bugs in all modes. It will often drop characters that BGFAX needs to be able to see when in Class 2.0 mode. i.e., instead of returning "+FCO", it might return "FCO" or "+FC", but it is not-predictable what result will occur. In Class 1 mode, you must use the modem in numeric-resule code only, because in verbose-result mode the modem will "go crazy" at the point fax data is starting to be received. Most USR modems in Class 2.0 have a bug that prevents them from receiving of all of fax from certain faxback servers. If you notice the phrase "eom/multidocument" frame in the BGFAX.LOG, it will be most likely that the fax will die at that point with a +FHS:70 error. The USR Sportster 336 modems with firmware dated 05/13/96 have a bug in Class 1 bug that prevents them from sending more than 12 pages. If you have a "Sportster SI" modem, this is not a real modem, but an RPI type clone. See the "RPI modem" section of this READ.ME. Hayes owners ~~~~~~~~~~~~ BGFAX has been tested with the Hayes Optima 288 V.FC modem and the V.34 upgrade. Make sure you are using the 3.10 ROMs in the V.FC model. Use the ATI3 command. It will produce a multi-line response. Look for... 04-00621-310 27232 PASS <-- Notice the "310", that means 3.10 ^^^ ATI7 will produce a more human readable response, but it is not reliable. ATI7 will report the ROM version that ORIGINALLY was in the modem when it was manufactuered. If you are using a 14400 version of the Optima or Accura, you will need to put a minus sign after the com port number so that BGFAX will use an alternate method of 19200-shifting. (i.e., po=1- inside the BGFAX.CNF for COM1, Accura-style 19200 DTE shifting.) Also, the 14400 Accura does not like the answer string of "AT+FAE=1;A" like its 28800 counterpart. You will need to use another initialize string of "AT+FAE=1" and use the regular answer string of "ATA". ZyXEL owners ~~~~~~~~~~~~ See the included FD-ZYXEL.TXT file for an example of how to use the ZyXEL with FD 2.12/SW. Basically, the init strings are: ATZ AT#P713 555 1212 AT#B1+FCLASS=6 And the answer string is "ATA". The above strings basically use the ZyXEL's special fax mode. People report greater success with that method, as compared to using ZyXEL's Class 2 implementation. If you have trouble with BGFAX and the ZYXEL, you can always use REFAX, or the ZFAX software that comes with your modem. If you want to send faxes with the ZyXEL 2864-ISDN modem with BGFAX, add a line in the BGFAX.CNF that says "ss=AT&O0". That will make BGFAX send the command to the modem that activates the fax/modem/voice DTE channel rather than the ISDN DTE channel. Supra owners ~~~~~~~~~~~~ I own a Supra 14400 with 1.8 ROMs myself. I have not tested BGFAX with the Supra 14400 with the 'newer' 1.4 ROMs (the newer board layout) or with the Supra LC (14400, low cost alternative). The Caller ID features in BGFAX's /HOST mode where developed using the Supra v.32bis (the older 1.8 series) as a reference. If you are using a Supra 288 V.FC (-16 firmware), the adaptive answering is broken. Call the Supra BBS and download the latest FLASH firmware for the V.FC modem to fix it. The Supra 288 V.34 modem has very good adaptive answering. It can even be tuned, which is unique only to Supra and Multitech. The tuning is made by tweaking the S192 register. S192=2 (default) 'Bad' calls logged as "NO CARRIER" S192=0 (better) 'Bad' calls logged as "FAX" The default value will make the Supra V.34 do adaptive answering like the Supra V.32bis did. In this case, the modem will wait for about 1 or 2 seconds before starting a data mode handshake. If a fax CNG tone is heard during the initial 1 to 2 second wait, the modem will respond "FAX" and shift into fax mode. On bad data calls, the modem will properly log the failed call as "NO CARRIER". So, what's bad about the default? It sounds good, BUT... Many fax machines out there don't send CNG tones during the first 1-2 seconds. For example, if a user tries to send a fax to you from a real-live fax machine, he or she must hit the 'START' button on some models to make a fax CNG tone. Many times the person sending the fax will not hit 'START' until after they hear noises coming from the modem. If you use S192=2 (the default), YOU WILL MISS THIS PARTICULIAR FAX CALL! If you use the recommended S192=0 setting, the modem will report "FAX", and you WILL get this fax call. If getting all fax calls are important, you should definately use S192=0. So, there has to be a downside to this, right? Yes, there is... If a bad modem handshake occurs, rather than getting a "NO CARRIER" result, you will get a "FAX" result. This is the way that S192=0 is _supposed_ to work. IT IS *NOT* A BUG IN THE MODEM. Many people don't like 'false' FAX connects and that is why Supra choose to use S192=2 as the default. So, in summary, if you want reliable fax operation, use S192=0, just remember you will get the 'FAX' return result when it is actually a failed handshake of a data call. Multitech owners ~~~~~~~~~~~~~~~~ The Multitech offers adaptive answering tuning, just as the Supra V.34. AT+FAAMOD=0 see your manual for description AT+FAAMOD=1 see your manual for description The Multitech Class 2 mode will NOT shift to 19200 when receiving in fax mode. Because of this, make sure you put a '!' after the com port to tell BGFAX that this modem will not need a 19200 DTE shift. Example command line: bgfax /fax c:\bgfax 1! z <-- keep locked at current rate If you are able to receive a fax, but are unable to read the fax received from the Multitech, you might want to add the AT+FBOR=1 string to your initialization. Zoom owners ~~~~~~~~~~~ Some Zoom owners have experienced more reliable BGFAX operation when using the exclaimation point (!, bang) after the port. This instructs BGFAX to NOT drop the port speed down to 19200 bps when in fax mode. Almost all Class 2 fax modems require this shift. SOME Zoom modems will not operate with BGFAX unless you use the "!" after the port. SOME Zoom modems will NOT operate if you PUT the "!" after the port. Just a little warning. bgfax /fax c:\bgfax 1 z <-- change speed to 19200 when receivin bgfax /fax c:\bgfax 1! z <-- keep locked at current rate If you are using a 28800 Zoom modem, make sure you are using at least firmware version 1.100. (ATI3 will show you the version number.) Zoom released the series 1.309 firmware for it's V.34 products in October of 1995. This new firmware release corrects the adaptive answering problems that surfaced in Rockwell's V.FC and V.34 chipsets. (As far as I know, the adaptive answering bug fix is only available for Zoom's V.34 modems.) PPI owners ~~~~~~~~~~ Some of the earlier PPI modems do not include Class 2 fax. You can buy an upgrade ROM for approximately $30 that will let you use BGFAX, however, it will only allow fax speeds up to 9600 rather than 14400. If you want to use 14400 fax, you will have to get a new motherboard and datapump that will cost you about $100. Most fax machines only support 9600 fax anyway so this is not that much of a problem. Please note that most PPI owners are using the newer models that include both Class 1 and Class 2 fax at speeds up to 14400. If you think you might have an older model, issue a "AT+FCLASS=?" command from your terminal program. It it responds "0,1" you have an older model that needs the upgrade in order to use Class 2. If it responds "0,1,2" you have a newer model and BGFAX should work fine. It has been suggested to me by a member of PPI's tech support team, to tell all users to use the &D3 setting instead of the, more usually used &D2 setting. This &D3 setting seems to eliminate some 'odd' problems. If you have the 2.17 version ROMs in your modem, you need to get it upgraded to 2.30. Many people reported problems with the 2.17 firmware. Call PPI Tech Support for info on upgrading. It should be free, but this policy may have changed with the recent Hayes fiasco. Note that if you have an older FXSA [xA3] modem, you cannot upgrade the 2.17 to 2.30. If you have this [xA3] model, you're out of luck. (The number in brackets is given by the ATI3 command, and the "x" can be any number.) If ATI3 reports [9R4] in brackets, you will have either 2.42 or 2.43 firmware. Be sure to add an S7=125 in your init string. I've had a few ports that the PM144MT/HCII [xxRx] version 1.03 mistakes 2400 data callers as faxes. I am not sure if the 2.02 version does this or not. PM144FXH, [41R4] 1.03, report same 2400 problem PM144FXHC, [43R4] 1.54 seemed to work fine at 2400 One person claims the PPI's 288LCD fax mode is flawed with firmware 2.62 PC Logic owners ~~~~~~~~~~~~~~~ The PC Logic adaptive answering seems to not work at all, in the 14400 model. I haven't tried it with their new v.32terbo modem. My advice is to not try running BGFAX on the PC Logic. Hornet 28.8 VFC owners ~~~~~~~~~~~~~~~~~~~~~~ I've seen two people with Hornet 28.8 VFC modems report they were getting +FHNG:25 error messages when trying to receive faxes. The solution was to put an &K3 at the end of the last init strings. Very strange. DesqView ~~~~~~~~ If you have trouble SENDING faxes under DV, make sure... "Optimize Communications=YES" ...in your DV configuration screen. Note that some people have told me this does not help at all, but others report it does make a difference. OS/2 ~~~~ BGFAX/2 was designed to use Ray Gwinn's SIO communications drivers. BGFAX/2 was also recently tested with IBM's standard COM.SYS drivers and found to work. If you have trouble SENDING faxes under OS/2, make sure you use the native OS/2 version of BGFAX to do the sending. The DOS version of BGFAX, if running in an OS/2 DOS-box, will have trouble using software based flow control on some modems because of the way SIO handles XON/XOFF characters when it is set for RTS/CTS flow control mode. Using BGFAX2.EXE will solve that problem. If you really want to use the DOS version of BGFAX to send faxes when using OS/2, change the "SIO_Mode_XON/XOFF" setting (see SIO's docs for more details) to "Received XON is flow control". If you "lock" your com ports DTE rate with SIO, be sure to read the section in the BGFAX.DOC file which describes operation of the SU.EXE program. This means, before running BGFAX2, add a line in your command file (*.CMD) that says: SU 1 LOCK 0 Where "1" will be the com port number, and "0" indicates to "UNLOCK" port. If you get an error that says "{Set N81}: 22", then instead of passing the port handle, or com port number, use "v2", for example, to represent open com port #2 in VBBS-compatibility mode. If you can get an error says that says "Openport error 32", then instead of passing the com port number, pass the com port handle (an H in front of it). The handle will com from the application answering the phone. PC Board for OS/2 ~~~~~~~~~~~~~~~~~ PC Board for OS/2 is very new, but I am sure many of you are going to be using it before the next BGFAX release comes out. BGFAX 1.50 is coming out before the full public release of PCB/2, and I know little about it, but there are a few things different about the OS/2 PCB setup from the DOS setup in relation to BGFAX. In all of BGFAX's PC Board help files (PCB*.TXT), they always give examples like: BGFAX /xxxx C:\BGFAX 1 Z Where xxxx is some parameter, depending upon type of modem. The "1" in the above would represent COM1. In OS/2, com ports are handled via a "handle". So, instead of "1", you might say "h%pcbhandle%". Example: BGFAX2 /xxxx C:\BGFAX H%pcbhandle% Z Where "H" tells BGFAX the number following is an OS/2 com handle, and where "%pcbhandle%" returns the value of the environment variable set by PC Board. NOTE: I am not certain if that is the correct environment variable name. See the PCB/2 documentation regarding doors, com handles, fax exit errorlevel. RPI (Rockwell Protocol Interface) modems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Many manufactuers have begun to sell 14400 modems for dirt-cheap prices. You get what you pay for. These RPI modems usually lack Class 2 and only offer Class 1 fax mode. You can still use BGFAX with these modems, but if you are running in BGFAX /HODE mode, you might need to add a /ATO switch to the command line. See BGFAX.DOC for more info on the /ATO switch. If you are running a Fido mailer, you may have to use the ATOTSR.COM file. Again, see BGFAX.DOC for more information. Most people don't know they have bought an RPI modem, so in all likelyhood you will probably never read this. :-( RPI modems are not suitable for BBS use, because they lack error correction and data compression capabilities in the modem hardware, instead, requiring you to use some "COMIT" telecom program, or the use of a WinRPI driver. Remote Access Shell-to-Mailer mode ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've received numerous reports indicating the BGFAX does not function correctly if you are using OS/2 and Remote Access (2.02 and 2.50) in shell-to-mailer mode. Apparently, RA is doing something to the port which causes BGFAX to misbehave and receive many bad scan lines and other severe problems. To fix this, run RA in standard mode rather than shell-to-mailer mode and you should be okay. EXAR-based modems ~~~~~~~~~~~~~~~~~ If you use an EXAR based modem (type "AT+FMFR?" to your modem to find out), when sending faxes, some EXAR modems default to using hardware (CTS) flow control instead of XON/XOFF flow control. So, you will need to use the /HW switch on the BGFAX /SEND command line. i.e., bgfax /send output.fax 5551212 /hw Also, EXAR modems receive the faxes in a slightly different format. When receiving with an EXAR-based modems, you will need to add the /EX switch to the end of the command line. i.e., bgfax /host /ex Voicemail interface ~~~~~~~~~~~~~~~~~~~ BGFAX 1.70 includes many "hooks" that allow an external voice mail program to be used if your modem supports voicemail and distingtive ringing. These hooks were originally designed to be used with my BGVOI.EXE voicemail program, but work on this project was discontinued due to lack of interest. In the chance that another voicemail software becomes available, I will list below the interface that was added to BGFAX /HOST mode that was added: New BGFAX.CNF options, MR= and VR= for BGFAX /HOST mode. These new options are mainly designed for use with BGVOI, but they can be useful for any users that have a distingtive ring compatible modem. The default is "MR=RING" and "VR=RABC". MR= represents the string from the modem BGFAX will assume to be for the Modem/Fax. VR= represents the string from the modem for Voice. The default is non-sense since VR= and MR= _cannot_ be set to the same. If a RING pattern is detected, but it does not match MR= or VR=, BGFAX will *IGNORE* the RING and just wait for the line to stop ringing before waiting for a new call. What about the old VM= voicemail exit string? That function still works as before, but it is slightly different in function from VR=. The best way to explain it is by example. Let's assume your BGFAX.CNF file has the following directives: RI=2 MR=RING A VR=RING B VM=RING C Remember that "RI=2" tells BGFAX to not answer until the 2nd ring. When any "RING" response is sensed from the modem, BGFAX increments the ring counter. If the VM= string is detected (RING C), BGFAX will exit with an errorlevel 8 _immmediately_ ignoring the RI= ring counter requirement. If "RING A", "RING B", or any other "RING" is encountered, BGFAX will just sit there waiting for the 2nd RING to roll around before deciding what to do. (Due to yet another bug in the US Robotics modems, the distingtive ring detection will sometimes spit out an invalid RING detection on the first ring because it does not properly decode the pattern from the telephone company. But, it always seems to work properly on the 2nd ring, that's why we want to use RI=2.) As the 2nd RING pattern comes in, BGFAX will check and see if it matches the MR= (modem ring) or the VR= (voicemail ring). If the MR= is encountered, BGFAX sends the adaptive answering (fax/data) sequence to the modem. If the VR= is encountered, BGFAX will exit with an errorlevel of 8. If neither the MR=, VR=, or VM= strings are detected, (say RING X or RING D, or just a plain old RING in our example), BGFAX will *IGNORE* the incoming RING. (This way, you can use one distingtive ringing telephone number for a voice-only which lets your telephone ring rather than a voicemail system, which is useful even for people without voicemail modems, but modems that still have multi-pattern ring detection.) WinFOSSIL ~~~~~~~~~ I have received numerous reports of troubles with WinFOSSIL and BGFAX. I am not really certain which program is at fault. I sent a message to Bryan Woodruff, but never heard back, so I'll post it here in case a user of WinFOSSIL might see something wrong with the method of DTE changing. (48) Tue 31 Dec 96 11:54p Sent: Tue 31 Dec 11:55p By: B.J. Guillot To: Bryan Woodruff, Woodruff Software Systems (343/294) Re: Bug in WNFOSCTL or BGFAX? St: Pvt Crash Sent ------------------------------------------------------------------------ Hello, Bryan. I've been getting numerous reports back from users having trouble with BGFAX and WinFOSSIL. I finally had some time to try and track down at least one of the problems. Since your the FOSSIL expert, I'll give you some details of the problem, and ask if you think the fault is in WNFOSCTL utility program or in BGFAX's call of the Int14 $1E function. Problem: WNFOSCTL is run with "WNFOSCTL 1 unlock" command to force unlock of FOSSIL port 1 (aka COM2). BGFAX runs (using the FOSSIL), but when attempting to shift to 19200, it does not shift. Only all kind of high-bit ASCII garbage is received. Environment: Windows 95. WinFOSSIL 1.12.004. WNFOSCTL.EXE is dated 7/22/96 1:12am, size 8329 bytes. What BGFAX does: BGFAX opens the port initially at 115200 with 1Eh function. Once BGFAX receives the "+FCON" result from the modem, BGFAX attempts to shift down down to 19200, again with 1Eh function. The following registers are set during the 115200 initial open: ah=30 (1Eh) al=0 (no break) bh=0 (no parity) bl=0 (1-stop-bit) cl=132 (84h, 115200) ch=3 (8-data-bits) dx=1 (FOSSIL port 1, aka COM2) Then, of course, Int 14h is called. The following registers are set during the 19200 shift attempt: same as above, except for... cl=8 (19200) Then, of course, Int 14h is called. ###########################################################################