TIP: Click on subject to list as thread! ANSI
echo: aust_modem
to: Ian Smith
from: Lewin Edwards
date: 1996-03-14 20:33:28
subject: netcomm m34f problems

IS> Lewin would know a lot more about this, from the perspective of the maker
 IS> tuning those characteristics via the DSP, and about what's available to
 IS> the manufacturer who uses the DSP pretty well raw, like Netcomm, Dataplex
 IS> and a few others, and those who just bolt in the pre-coded 'solution'
 IS> best-guess stuff.  Then, how much access the USER has to play with it, by
 IS> published or possibly unpublished commands.

I found Rod's reply to this and searched back for your message. First, no
Rockwell-based manufacturer (including NetComm et al) has access to the
DSP. In the DPi-series datapumps, the high-level controller has access only
to DSP RAM. Basically, you're given a memory map with a lot of holes in it;
you're told the functions of certain locations in DSP RAM. Under no
circumstances can you actually update DSP code. You cannot tweak low-level
protocol parameters, it's simply not possible. I don't know exactly how
much ROM the datapump contains, but there's not a lot of RAM, and even if
there was a way to halt and restart the DSP at a specific location, there
isn't enough space to upload code patches. So NO tweaking.

A _lot_ of stuff is implemented DIRECTLY in the DSP in that unmodifiable
code. For example, CLI-CND. The datapump can detect an incoming CLI packet
and will tell the host uC so.

The controller is there to handle interface with the host, and to implement
high-level protocols. A surprising amount is implemented in the datapump,
retraining for example, cf. p6-2 of the RC288DPi Modem Designer's Guide
(remember, this guide talks ONLY about the 288DPi and NOT the AC firmware
which Rockwell supply, for "modem" read "datapump" and
for "user" read "modem controller") :

=== edited quote begins [I can't be bothered typing it all out] ===

6.2 RETRAIN AND AUTOMATIC RATE CHANGE
=====================================
6.2.1 Retrain Without a Rate Change
V.17 Configurations
-------------------
When the RTRN bit is set to a 1, the modem will send the training sequence.
The modem for which the retrain is intended will detect the training
sequence and will retrain. This can be monitored at the transmitter by
examining the state of CTS (CTS off means going through training sequence)
and at the receiver by examining the RLSD, P2DET and PNDET bits. Once the
retrain is completed, the process is complete.

V.34/V.FC/V.32/V.32bis and V.22bis Configurations
-------------------------------------------------
[basically the same as above]

6.2.2 Retrain With a Rate Change
V.34/V.FC/V.32/V.32bis and V.22bis Configurations
-------------------------------------------------
1. Store the desired configuration in the CONF register. Use configuration
code 82h (V.22bis/1200) for fall forward or fallback between 2400bps and
1200bps. NOTE : Do NOT set the NEWC bit.

2. Set the RTRN bit to a 1.

The modem will then send the retrain sequence at the correct operating
speed as selected in the configuration registers. The rate sequence is
automatically changed in the training sequence to tell the other modem at
what speed to operate. The status bits will change as mentioned above and
the CTS bit will be set to a 1 when the retrain sequence is completed. (See
the RREN bit description in Table 3-1 for rate change procedures in the
V.34/V.FC/V.32bis modes using a rate renegotiation rather than a retrain.
Also, see the SRCEN bit description in Table 3-1 for rate change procedures
in V.FC modes using the secondary channel).

6.3 HANDSHAKE TIMEOUT TIMERS
============================
If any part of the handshake is not detected, the modem will time out and
abort the handshake. In this case, the transmitter will immediately stop
sending the training sequence. Also, the modem, upon timing out, will load
an error code into register 14 (ABCODE) of interface memory that indicates
that point in the handshake the time-out occurred. The error code is not
cleared even if the modem immediately goes into a new handshake after
aborting. The user can observe this register during the handshake to
determine if an abort occured.

The user can progressively observe the handshake detector bits (AADET,
ACDET, CCDET, etc) to determine how the handshake is proceeding. The user
can thus be interrupted at each step of the handshake progression.

=== quote ends ===

And that's just the tip of the iceberg.

 IS> I'd be surprised if both the Netcomm and the Sportster didn't have a way
 IS> to select the bit error rate (BER) at which fallforward and fallback

This is a controller-pushed feature and is controller-implemented; the
controller follows the procedures above to initiate retrains. I don't know
if customization of this feature is in current NetComm ROMs, but afaics it
wasn't in the one I hacked (an oldish version of the M11F firmware).

-- Lewin A.R.W. Edwards [Team OS/2]  Tel 0419320415 * 0412809805 * 0414927056

--- GoldED 2.41+
* Origin: ZWSBBS +61-3-9827-6881 28800bps Multiline (3:634/396)
SEEN-BY: 50/99 78/0 620/243 621/525 623/630 624/300 632/329 348 998 633/371
SEEN-BY: 634/376 381 384 387 388 396 635/301 402 502 503 506 541 544 639/252
SEEN-BY: 711/401 409 410 413 430 510 808 809 899 932 934 712/515 713/888
SEEN-BY: 714/906 800/1 7877/2809
@PATH: 634/396 384 635/503 50/99 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.