Q. What is the correct procedure to follow after power is applied to the CMX869/A/B?
Q. What is the procedure for returning the CMX869/A/B to normal operation following Powersave mode?
A. The algorithm, "Recommended Start-up and Powersave procedure for the CMX869/A/B" shows how to manage the CMX869/A/B after powering it on or bringing it out of Powersave mode.
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: www.cmlmicro.com/products/applications/AN_Telecom_869B_Upgrade_1_August_06.pdf.
Q. How do I perform a V.32bit handshake with the CMX869A?
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 CMX869 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. The CMX869A connects but I get data errors. If the modem re-trains the same thing happens. Why is this?
Q. I use the CMX869A on a poor line where modems normally connect at low rates such as 9600 bps. Why does the CMX869A normally connect at 14400 bps and then get a high bit error rate?
Q. Sometimes, when answering a call, the CMX869A produces data errors but when it originates a call on the same line, it connects without any problem. Is there a problem with the answer mode?
A. During the start-up and retrain procedures, the CMX869A determines a likely bit-rate at which satisfactory performance can be attained with the particular GSTN connection. Under exceptional conditions, it is possible that the CMX869A will determine an incorrect bit-rate resulting in reduced BER performance. A CML Application Note - CMX869A Automode Modem describes a method to both detect and work-around this anomaly. This anomaly has also been observed on the CMX869 and the same work-around can be used.
Q. Why does the "carrier lost" status not appear when I remove the cable from the modem?
A. The Algorithm used within the CMX869 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 CMX869 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 CMX869 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 CMX869 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 CMX869 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. What should my transmit levels be in the modem mode?
A. Determine the required transmit levels on tip and ring first; this value is
commonly -10.5dBm (0dBm=775mVrms). Since the line interface “terminating
resistor” and the tip/ring “line” typically act as a balanced voltage divider,
the transmit signal will be reduced by half when presented to the line. This is
a loss of 6dB and must be accounted for in your design. If transformer coupling
is also being used, this typically results in an additional loss of 1dB, so the
total attenuation applied to the transmit signal before it reaches tip/ring is
7dB.
The nominal TXA/TXAN output level (Vdd=3.3V) is -0.5dBm when the Tx Gain Block
is set to 0.0dB. Since the desired TXA/TXAN output level is -3.5dBm (-10.5dBm
desired level + 7dB attenuation), adjusting the Tx Gain Block to -3.0dBm will
cause the transmit line levels to be -10.5dBm. These values can be adjusted
depending on the specific parameters in your application.
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 CMX869 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 CMX869 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): www.itu.int/ITU-T/sitemap/index.asp.
Q. How do I use the ‘automodem’ capability of the 869?
A: Here is a recommended connection sequence:
Originate V32bis connection with CMX869.
Reset and power up sequence
WriteGeneralReset
$01, no data
WriteGeneralControlRegister(Reset=1,PwrUp=1)
$E0=0x0180
Wait20ms
WriteGeneralControlRegister(Reset=0,PwrUp=1)
$E0=0x0100
Set transmit and receive levels, b9:11 of $E1 and $E2 respectively. The setting of these will depend on 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 I would start with maximum, i.e. 0b111.
Go off hook
If using CMX869 relay drive:
$E0=0300
Wait 3 seconds
Dial number
Start handshake process
Set time limit for completion of connect sequence to 30 seconds.
Select transmit QAM mode, asynchronous 8 bit data no parity 1 stop bit.
$E1=0xC816
Select receive QAM mode, asynchronous 8 bit data no parity no overspeed.
$E2=0xCE36
Start QAM modem, originate at 14k4b/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. Are the QAM Modem Status Register contents valid when the 869 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 869 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 869 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 869 to attempt a slower connection, you will need to
manually configure the 869 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 869 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 869 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 869'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 when the data stops is a good
idea.
Q. I notice that the 869 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.
Please note the CML disclaimer notice for applications and FAQ information.