| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.