top menu
Site Menu Site Search
 
Products
 

Low Power V.32 bis Modem

CMX869B


Features:

  • V.32 bis/ V.32/ V.22 bis/ V.22 Automodem
    • (14400, 12000, 9600, 7200, 4800, 2400, 1200 bps Duplex)
  • V.22 bis/V.22 Manual Modem
    • (2400, 1200 bps)
  • V.23 (1200/75, 1200/1200, 75, 1200 bps FSK)
  • Bell 202 (1200/150, 1200/1200, 150, 1200 bps FSK)
  • V.21 or Bell 103 (300/300 bps FSK)
  • High Performance DTMF Modem
  • Single/Dual Tones Transmit and Receive
  • 'Powersave' Standby Mode
  • Asynchronous, Synchronous and HDLC Modes

Applications:

  • EPOS Terminals
  • Telephone Telemetry Systems
  • Remote Utility Meter Reading
  • Security Systems
  • Industrial Control Systems
  • Electronic Cash Terminals
  • Pay-Phones
  • Cable TV Set-Top Boxes

Supply Requirement:

  • 3.0 to 3.6 V power supply

The CMX869B is a multi-standard modem for use in EPOS terminals and telephone based information and telemetry systems. This highly integrated single-chip modem IC provides the functions needed to construct a ITU V.32 bis automode modem or a V.22 bis, V.22, V.21 and Bell 202, Bell 103 compatible modem operating under the control of external host timing for EPOS and other proprietary protocols.

The V.32 bis automode-modem provides operation from 14400 bps with automatic fallback through to 4800 bps, retrain, rate re-negotiation and automatic detection of V.22 and V.22 bis modems.

A high-quality DTMF decoder with excellent immunity to falsing on voice and a standard DTMF encoder are included. Alternatively, the device can transmit and detect user-programmed single and dual-tone signals, call progress signals or modem calling and answering tones.

The CMX869B features a software controlled output to drive a hook switch relay and a ring detector block that continues to function when the device is in Powersave mode.

When a line voltage reversal or ringing signal is detected, the ring detector circuit provides an interrupt that can wake up the host µController.

Line input and line outputs can be single-ended or differential and the line-output amplifier is capable of directly driving into a low-impedance transformer or opto-isolated DAA. The hybrid and gain control circuits are integrated on chip, requiring only passive external components to build a 2- or 4-wire line interface.

Host control and data transfer is via a simple, high-speed serial bus that operates in normal and Powersave modes and which is compatible with popular µC serial interfaces.

An embedded USART accepts multi-format asynchronous data with V.14 support, or allows unformatted synchronous data or HDLC framed data to be received or transmitted. Data transfer can be in either an 8- or 16-bit format.

Block Diagram

CMX869B: a multi-standard modem for use in EPOS terminals and telephone based information and telemetry systems

Design Support Information

 

CMX869B FAQ
 

Q. Can you help me understand the differences and migrate between the CMX869x families of devices?.

A. There are a number of minor differences between devices, to help explain these differences and make the most of the CMX869x please refer to the following application note: AN_Telecom_869B_Upgrade_1_August_06.pdf.


Q. How do I perform a V.32bit handshake with the CMX869B?

A. To originate a V32bis connection with CMX869A please follow the sequence illustrated below:
Reset and Power-up Sequence
Write GeneralReset
$01, no data
Write GeneralControlRegister(Reset=1,PwrUp=1)
$E0=0x0180
Wait 20ms
Write GeneralControlRegister(Reset=0,PwrUp=1)
$E0=0x0100
Set transmit and receive levels, b11:9 of $E1 and $E2 respectively.
The setting of these will depend on the line interface. For transmit, set such that signal level on line is –10dBm, the rest of this document will assume –4.5dB for Tx output (0b100).
For receive, a good starting recommendation is the maximum value, i.e. 0b111.
Go off hook
If using CMX869B relay drive.
$E0=0x0300
Wait 3 seconds
Dial number
Start handshake process
Set time limit for completion of connect sequence to 30 seconds
Select transmit QAM automodem mode, asynchronous 8 bit data no parity 1 stop bit
$E1=0xF816
Select receive QAM automodem mode, asynchronous 8 bit data no parity no overspeed.
$E2=0xFE36
Start QAM modem, originate at 14k4 b/s
$EA=0x0017
Monitor connect progress.
Check status register ($E6) bit 9 for QAM mode status change.
Check QAM status register for new status.
Leave when QAM status $EB= 0xXXX8 to 0xXXXF (value of bits 2:0 indicate connect bit rate), OR leave when 30 second timer expires.


Q. Why does the "carrier lost" status not appear when I remove the cable from the modem?

A. The Algorithm used within the CMX869B requires a minimum amount of received energy to be present with a long enough period of decodable data.
If the far end modem stops transmitting data (and therefore there is no carrier), the CMX869B can detect the lack of signal compared to the ambient noise level and so very quickly detect the loss of carrier and so issue the "carrier lost" status. This will also occur if the far end modem hangs up (as long as the two modems are connected through a switch / exchange).

However, if the local line to the CMX869B is physically broken, it will attempt to decode data from the noise energy at the input and indicate a "bad" or "very bad" SNR. At this stage the CMX869B cannot determine if the line has actually been broken, or is simply too noisy to support the current baud rate, and so will try to re-train to re-establish the connection.

The host should monitor the SNR readings from the CMX869B to determine if a baud rate increase or decrease is feasible, and implement a timeout for the condition where the SNR remains bad even after a re-train has been executed at the lowest baud rate selected. If the time-out expires, then the host should terminate the connection.


Q. I notice that during retrain/renegotiation attempts, the QAM Modem Status Register always indicates “rate negotiation” first, followed by “retrain request detected”. Why do these readings always follow one another?

A. The preamble for the rate re-negotiation request is 64 symbol periods of a particular data stream, the contents of which depend on whether the calling or answering modem is initiating the request. The preamble for the retrain request is at least 128 symbol periods of the same data stream as is used for the rate re-negotiation request.
The CMX869B sees the 64 symbol periods for "rate negotiation" first, as 64 symbol times completes before 128 symbol times does, so the device indicates, “rate negotiation request detected”. If the request is actually a “retrain request”, the preamble won’t stop there and will continue for at least another 64 symbol times…at the end of that period, the CMX869B will recognize the “retrain” request and update the QAM Modem Status Register accordingly.


Q. The "QAM Modem Status Register" (Section 6.9 of the data sheet) refers to "R1" through "R5", yet I find no mention of these parameters in the data sheet. What are R1 through R5?

A. R1 through R5 are rate sequence specifiers that are used in the call establishment, re-train, and rate re-negotiation phases of a V.32bis data transaction. R1 through R3 are used for initial call establishment and re-training, while R4 and R5 are used for rate re-negotiation. These specifiers are fully described in the V.32bis specification that can be obtained from the ITU website.


Q. Are the QAM Modem Status Register contents valid when the 869B is NOT in QAM modem mode?

A. The contents of the QAM Modem Status Register are only valid when in QAM modem mode.


Q. If I enable the 869B for ‘automodem’ mode, will the device automatically and autonomously negotiate a connection with a remote modem, including a reduction in connection speed if required?

Yes, the '869B will auto-negotiate with the other end to the fastest bit rate that both can handle. The caveat here is that there is a limit as to how far down it will try to connect; the minimum connection speed depends on the selected standard , ie: if you start it off at 14.4kbps, it will only auto-negotiate down to 4.8kbps (ie: V32).
If you want the '869B to attempt a slower connection, you will need to manually configure the ' 869B for this.

Rate negotiation requests will be reported during the initial handshake procedure, and also if the far end issues a re-train or re-negotiate at any time, in which case the handshake will be automatically re-started in an attempt to get the highest speed possible on a given link. There should be no need for the host to take any action when it receives these messages, unless it causes a break in the data transfer while its going on.


Q. Concerning the notion that the chip will throttle back its speed to a minimum level determined by the standard, how will the host know that the handshake has effectively failed and that the device needs to be "manually" configured for lower speed connections?

A. If the CMX869B is set to 14k4 as its max connect rate, and it backs off to 4k8 and still cannot get a good connection, it will report a no-connect.
If the host wishes to try at 2k4 and 1k2, then it will have to issue a connection request with 2k4 as the max connect rate.


Q. If the far-end modem issues a re-train or re-negotiate request during the data session, will the 869B automatically and autonomously start the required handshake?

A. This will automatically be detected by the 869 and the 'automodem' process will be started automatically.
The 869B's host will then see a data famine as this process runs, which could (wrongly) be interpreted as a loss of connection by the host. The host does not need to do anything to respond to a re-train or re-negotiate request except wait for it to complete and data transfer resume. Hence reading the QAM status register should be done regularly and the re-train request will be seen.


Q. I notice that the 869B connects but has “garbage characters” immediately after the connection completes, and I never receive “good data. What could be the problem?

A. It is imperative that the crystal frequency deviates from the nominal 6.144MHz by no more than the 100ppm laid down in the data sheet.
It must be stressed that the QAM algorithms are very sensitive to clock inaccuracy. Furthermore, if the crystal tolerance is outside of the required specifications, 1.2kbaud will sometimes work where all higher speeds produce high errors.

Internal tests indicate that a device with an inaccurate clock would connect OK with a reasonable SNR result in the QAM Modem Status register, but the receive SNR would quickly start to drop until the received data had a high error rate.
In some cases the errors would start almost immediately after connection was established.

Measuring the crystal frequency directly is somewhat difficult in that any probe adds some capacitance to the pin and shifts the frequency of oscillation.
There is an indirect test that can confirm if crystal tolerance is a problem.
Once a connection has been established, periodically read the SNR result from the QAM Modem Status register; if the SNR degrades, the crystal tolerance is likely a problem.

 
 
View our news as RSS Visit our twitter feed Visit our Youtube channel Visit our LinkinIn page Visit our facebook page
Web design by S-Digital
Copyright © 2014 CML Microsystems Plc