1. I tried just looping data back to the adapter using a standard COM Port null modem, why didn't it work?

2. My SyncDrive(Plus) application is not working. How can I establish that my hardware is configured properly?

3. Once I have determined using example programs that my hardware is good, but my application program still doesn't work, what should I do next?

4. Under which OS is my RS-232 Synchronous Serial PCI Board supported?

5. What are SyncDrive and SyncDrive Plus?

6. What are the major differences between SyncDrive and SyncDrive Plus?

7. What is required to use SyncDrive and/or SyncDrive Plus?

8. Which memory models does SyncDrive (Plus) support?

9. What is the SyncDrive (Plus) Digital Phase-Locked Loop (DPLL) used for?

10. What are the data encoding requirements for using the DPLL?

11. What are the clock speed requirements for the DPLL?

12. How does using the SyncDrive (Plus) DPLL affect the data rates that can be achieved?

13. Does SyncDrive (Plus) use the FIFOs in the optional Z85230 upgraded SCC?

14. What does the SyncDrive "error" indicator mean in a receive com_block's buffer_status variable?

15. Why aren't there any SyncDrive example programs for buffer queues using byte-synchronous communications?

16. Does the OS/2 version of SyncDrive work with version 4.00 OS/2 Warp?

17. Do I need local administrator rights to install a Quatech serial device?

18. If I have problems not addressed in this FAQ, what information do I need to submit on the technical support request form in order to get help?

Q1. I tried just looping data back to the adapter using a standard COM Port null modem, why didn't it work?

A. Null modems are intended for asynchronous adapters or standard COM ports. They are not meant for synchronous communication as with synchronous communication, the pinouts and signals are different from asynchronous.

Q2. My SyncDrive(Plus) application is not working. How can I establish that my hardware is configured properly?

A. A good step in determining whether a problem is related to the software program or the hardware is to try known good compiled SyncDrive(Plus) example applications on the hardware. Quatech provides a set of example applications for both SyncDrive and SyncDrive Plus.

Q3. Once I have determined using example programs that my hardware is good, but my application program still doesn't work, what should I do next?

A. The answer to this question could be one of a great many things depending on what the application is. The following are descriptions of two of the most common problems our customers have experienced over the last few years when writing application programs using SyncDrive and SyncDrive Plus

Check the SyncDrive Configuration
This is usually a good place to start if the application program is causing a crash or lockup. In particular, the customer should double-check base_address, tx_interrupt, rx_interrupt, tx_dma_channel, and rx_dma_channel.

Clock Sourcing
If the problem seems to be that transmit and receive functions aren't functioning correctly, the programmer should double-check the clock_source variable in the channel configuration structure. Also, be certain that the modes in clock_source are set properly and check the hardware manual to be certain that the clock signals are being routed to the proper SCC outputs and inputs.

Q4. Under which OS is my RS-232 Synchronous Serial PCI Board is supported?

A. View the latest OS support matrix for RS-232 Synchronous Serial PCI Board.

Q5. What are SyncDrive and SyncDrive Plus?

A. SyncDrive and the new SyncDrive Plus are frame-level synchronous communication driver packages written specifically for use with C and are designed to aid users of Quatech MPA/MPAP/MPAC hardware in the development of their application software.

Q6. What are the major differences between SyncDrive and SyncDrive Plus?

A. There are three major differences between SyncDrive and SyncDrive Plus.

1. SyncDrive Plus is for Windows 2000/XP while SyncDrive is for Windows 95/98/Me and OS/2
2. SyncDrive Plus supports only bit-synchronous SDLC/HDLC protocols, while SyncDrive supports both Bit-synchronous (SDLC/HDLC) and byte-synchronous (monosync/bisync) protocols.
3. SyncDrive Plus supports and is included free with MPAP series PCMCIA cards and MPAC series PCI boards. SyncDrive supports and is included free with the MPAP and MPAC series cards, as well as Quatech's MPA series ISA boards.

Q7. What is required to use SyncDrive and/or SyncDrive Plus?

A. SyncDrive requires a system with an Intel-compatible 80386 processor or later running Windows 95/98/Me or OS/2, SyncDrive Plus requires a Pentium compatible processor, running Windows 2000 or Windows XP. Both require a C compiler. An import library that resolves your applications' external references to SyncDrive(Plus) functions is supplied in the DLL.

Q8. Which memory models does SyncDrive (Plus) support?

A. DOS programs must be compiled in Large model. For Windows 95/98/Me/2000/XP and OS/2, programs are compiled in Flat model.

Q9. What is the SyncDrive (Plus) Digital Phase-Locked Loop (DPLL) used for?

A. In configurations that do not include separate signals for clocking information, it is sometimes possible to use the DPLL to extract clocking information from the encoded data itself. There are special requirements for the data encoding techniques and clock speeds to be used with the DPLL. The DPLL can be used as the source for the received data clock by making the appropriate bit selections in the clock_source variable in the channel configuration structure.

Q10. What are the data encoding requirements for using the DPLL?

A. SyncDrive (Plus) requires that the received data be either NRZI (most common), FM0 or FM1 encoded. This choice should be made in the operating_mode variable in the channel configuration structure. The operating_mode selection affects both transmit and receive operations.

Q11. What are the clock speed requirements for the DPLL?

A. The SCC always uses its internal baud rate generator (BRG) as an input clock to "seed" the DPLL. The DPLL needs to oversample the received data bit stream in order to extract clocking information. This means that the DPLL's input clock needs to be running at a multiple of the actual rate of the received data bit stream.

If the received data is NRZI-encoded, the DPLL input clock must run at 32 times the received data rate. The clock_source variable in the channel configuration structure must be set for X32 clock mode. If the received data is FM-encoded, the DPLL input clock must run at 16 times the received data rate. The clock_source variable must be set for X16 clock mode.

Q12. How does using the SyncDrive (Plus) DPLL affect the data rates that can be achieved?

A. The clock mode factors into the denominator of the equation for calculating baud rate constants. As the clock mode increases, the highest possible baud rate decreases. Running a X32 clock, for example, will permit a substantially lower maximum baud rate than would running a X1 clock. This is a tradeoff for using the DPLL.

Q13. Does SyncDrive (Plus) use the FIFOs in the optional Z85230 upgraded SCC?

A. Yes, the FIFOs in the Z85230 are always used by SyncDrive (Plus). The application does not need to enable them, and cannot disable them.

Q14. What does the SyncDrive "error" indicator mean in a receive com_block's buffer_status variable?

A. This bit will be set when a receive CRC error occurs or when the receive buffer of the SCC itself suffers an overrun. An overrun will occur when the SCC is not being serviced rapidly enough. It is essentially a "horsepower" issue. Possible solutions include lowering the data rate, using DMA if possible (SyncDrive supports DMA only in the bit-synchronous mode), increasing the speed of the host computer, etc.

Q15. Why aren't there any SyncDrive example programs for buffer queues using byte-synchronous communications?

A. Actually, they do exist, and are available on request. Please submit our Technical Support Request form to obtain them. We don't distribute them because they don't run well under DOS. The example programs do a lot of printing to the screen with the "printf()" C runtime function call, and the BIOS functions which handle this apparently disable interrupts for long periods of time. This causes problems for buffer queues, which are constantly generating interrupts as their operation runs in the background. Using DMA reduces the number of interrupts substantially and lets the bit-synchronous queue examples run better under DOS. Unfortunately, this isn't an option for byte-sync modes. OS/2 and Windows do not seem to suffer from the problem of printf() disabling interrupts, and the buffer queue examples work even better under those operating systems.

This is not to say that byte-sync applications cannot use buffer queues. On the contrary, buffer queues should work fine in any application so long as interrupts are not disabled for long periods of time. Note that as SyncDrive Plus does not support byte-synchronous communication protocols, there are no such examples available for it.

Q16. Does the OS/2 version of SyncDrive work with version 4.00 OS/2 Warp?

A. Yes. The OS/2 version of SyncDrive works under OS/2 versions 2.1 up through 4.00. Users of this OS/2 version, however, should have at least 16 M of memory before beginning to develop their SyncDrive application.

Q17. Do I need local administrator rights to install a Quatech serial device?

A. Yes. When installing most kinds of hardware, you must have local admin rights or equivalent on the PC. If your computer is part of a Domain or participates in a networked environment, please contact your local LAN Administrator for assistance.

Q18. If I have problems not addressed in this FAQ, what information do I need to submit on the technical support request form in order to get help?

A. Please include the following information in the "description" field of the technical support request form:

• Product Model Number (ie: MPAC-100)
• Version of SyncDrive or SyncDrive Plus being used. (This can be found on the Quatech COM CD)
• Type of C Compiler being used.
• Brief description of your application.(I.E. Bit-Sync, Byte-sync, etc.)
• Specific explanation of the problem being experienced.
• Any error messages or error codes being generated