Inter-Tel AXXESS & Comtrol RocketModem II throughput
Chris Largent
purchased a new Comtrol "RocketModem II" 6-port modem for use in one of our
remote access servers. Unfortunately, the RocketModem is exhibiting
extremely low and unusable throughput on all of its ports. It typically will
only establish a carrier (i.e., DCE speed) of 19,200 bps or lower, and
regardless of what carrier speed the modem reports, the ACTUAL throughput
seems to be around 1,200 to 2,400 bps.
Some key diagnostics to consider:
-- We have several other modems that work just fine through our Inter-Tel
AXXESS switch, including external USRobotics "V.Everything" modems and an
internal ZOOM "56K Faxmodem ". These particular modems consistently and
reliably establish carriers in the 21,600 to 33,600 bps range and perform to
expectation.
-- The RocketModem works like a charm when connected directly to POTS lines
(i.e., bypassing the AXXESS switch.)
With the above in mind, Comtrol and I feel that the throughput problem may
be due to some incompatibility between the AXXESS switch and the Rockwell
chipset that the RocketModem is designed around.
Has anyone else out there experienced behavior like this related to their
Inter-Tel AXXESS phone system or Comtrol RocketModem?
Rich Piehl
What kind of connection do you have between the AXXESS and the Telco?
POTS , or something digital?
If digital do you have the clocking card installed i nthe AXXESS? I've
seem similar problems with fax machines and the clocking card fixed the
problem.
Take care,
Rich
God bless the USA
--
"Life is a crapshoot, Rocky. And if I'm going to roll snake eyes I'd rather do it on a jammed up garbage disposal that the fast lane of the Hollywood Freeway!"
-Jim Rockford
Rich Campbell
where some modems will NOT try and go to v.34 like the USR modems can..BTW
USR is far better modem. Unless you are going straight digital into the
modem you will only achieve 33.6 top...which is v.34 bis.
"Chris Largent" <chris....@spamisnotprofessionalpro-group.com> wrote in
message news:b9jabc$4...@dispatch.concentric.net...
Chris Largent
what we've been using up to this point. However, I'm now trying to clean up
the external clutter in our server room. It's a conscious choice for us to
migrate to an internal, multi-port modem for our RAS needs.
Yours is a good test (to force the v.34 or earlier protocol), and I did try
that in my early diagnostics. Unfortuantely, this doesn't resolve the
problem. Related note: we aren't originating any calls on the RocketModem,
only answering inbound calls. So my environment only represents analog
modem-to-analog modem calls, which as you point out, limits connections
(carriers) to the v.34 protocol (33,600 bps) at best.
Chris
"Rich Campbell" <rcam...@pantelonline.com> wrote in message
news:G3jva.805175$L1.229784@sccrnsc02...
Chris Largent
the 2 analog circuits are "loop start" circuits.
All of these circuits are connected to our AXXESS as CO trunks. When routing
inbound "modem pool" calls through the AXXESS, the RocketModem's throughput
problem occurs. When bypassing the AXXESS (by removing one of the analog
trunks and punching it down directly to the RocketModem), the RocketModem
has no throughput problem and performs beautifully (i.e., on all of its 6
ports.) For 100% clarity, it doesn't matter if the inbound call comes in on
an analog circuit or via the PRI-ISDN circuit...as long as the call is
routed through the AXXESS whatsoever, the RocketModem throughput problem
occurs.
Yes, we do have a clock card installed in the AXXESS. With this in mind,
please note that none of our other analog devices have any problems, which
includes various fax machines and the other modems mentioned in my original
post. I also tested some of the spare Single-Line Card (SLC) ports on the
AXXESS to see if the RocketModem just happened to be connected to a
malfunctioning SLC port. All of the spare SLC ports that I connected to the
RocketModem produced the same behavior, so I don't think a "bad SLC port" is
the problem either.
We think the problem MAY have something to do with analog-to-digital and/or
digital-to-analog conversion being peformed internally by the AXXESS. Why
this only causes problems for the Comtrol "RocketModem II" is what really
confuses us. This is why we currently think there may be an incompatibility
with the Rockwell modem chipset, or how Comtrol implemented the Rockwell
chipset in its "RocketModem II".
Chris
"Rich Piehl" <rpiehl5REMOVE...@charter.net> wrote in message
news:vbratjd...@corp.supernews.com...
Rich Campbell
USR had a multi-modem device that used BRI's and that would allow you to go
straight digital and allow 56k capability. Of course you would need to get
BRI on your AXXES. Another thing, you may want to strip out a POTS line to
see if your new modem works right to begin with. Another thought...mabe
check gain levels on the analog lines on the AXXES...just a few thoughts.
"Chris Largent" <chris....@spamisnotprofessionalpro-group.com> wrote in
message news:b9mk9k$s...@dispatch.concentric.net...
Rich Piehl
I have run into similar type of problems trying to get analog modems on
analog ports of a digital system to go out on POTS lines. Same situation
as you - I could get other modems to work. Just not the one the customer
had and insisted on using. I even had one that would connect and
handshake with the other end and then put jibberish on the screen.
I think your assessment is correct. There's just something in the way
certain modems modulate and demodulate that does like having the
analog/digital/analog conversion done to them. Like maybe missing a key
bit or something. Or having the analog modem version of something
similar to B8ZS goofed up. (and before everyone writes YES I KNOW that
B8ZS is something completely different!)
I've never come up with a 100% effective fix for it. Sorry.
Chris Largent
participant who e-mailed me directly...
=== cut here ===
Pardon the email reply, but I can't post via my ISP.
Since I deal with Axxess daily, I'll toss in a couple of ideas.
1. First of all, and for what ever reason, you may need ARS to make the
modem work. Had a site that was using a modem pool and a fax pool and
Inter-tel suggested I go the ARS route, and it worked. (Wish I could
remember the brand of modem pool they were using, but it was also 6 port.)
2. Do you have access to tech support, or does your inter-connect?
Inter-tels support guys are usually very good, and are often up to the
challenge. 3. It does sound to me like a chipset incompatibility. Had a fax
machine that wouldn't work on the Axxess, but would directly on a POTS 4.
I'll take a copy of your posting and check Inter-tels support site for
suggestions and if I come up positive, I'll let you know. Good luck,
Chris Largent
exactly follow how ARS applies to incoming modem calls. Maybe the following
will eliminate ARS as suspect... I have the appropriate SLC ports--those
that are connected to our modems--grouped into a hunt group. I have a
Direct Inward Dial (DID) phone number that points to the hunt group. The
RocketModem's bad behavior occurs whether the calling modem is located
internal or external to our AXXESS.
2) I only have access to Inter-Tel's technical support via my local phone
vendor (i.e., since Inter-Tel doesn't provide an online knowledgebase or any
other support accessible to end-users.) ...Yes, my vendor has contacted
Inter-Tel, and Inter-Tel suggests that maybe the RocketModem II has a design
problem related to higher-than-normal loop current. Inter-Tel suggests that
we experiment by installing 100 ohm resistors on both the tip & ring
circuits of each port (i.e., solder them into a line cord). However, even
if this resolved the problem, it wouldn't be a solution that I'd like or
accept. (Although I have to admit, it sure would be intellectually
satisfying to know.)
As anyone can guess, Comtrol does not agree with Inter-Tel's suggestion that
the RocketModem II might be out of specification. Likewise, Inter-Tel does
not agree with Comtrol's suggestion that the AXXESS might be out of
specification. (What fun it is when engineers butt heads!) We'll probably
never know the real cause since it's not worth it, but I must convey that
Comtrol IS REALLY working earnestly with me to either solve this problem, or
provide an alternative solution. Comtrol has been showing me that they take
their quality and reputation seriously.
Chris
Chris Largent
e-mailed me directly...
=== cut here ===
ARS is not your issue (brain fart on it being incoming), and since you have
the same behavior internal or external, that helps to narrow the problem.
Setting up huntgroup and DID is the way I'd do it also. We had a site where
we punched down the resisters on the blocks as a possible solution for
similar modem issues. It sounded like a good theory, but didn't help at
all.
I searched for other ideas on their site, and came up blank. Sorry, I'm out
of ideas. If you resolve this, please let me know what you did. Thanks and
good luck.
Chris Largent
some 100 ohm metal-oxide resistors (1 watt rating; 5% tolerance). I spliced
a standard line cord and connected one resistor into the "tip" side (red) of
the loop circuit, and connected another resistor into the "ring" side
(green) of the loop circuit.
Drum roll...
This actually resolves the problem! I tested every port on the RocketModem
II using my customized line cord, and every port worked perfectly. With
every test call, I got a solid 33,600 bps carrier with corresponding
throughput.
All diagnostics/conditions up to this point conclusively prove that there is
an analog design incompatibility (i.e., loop current) between Comtrol's
"RocketModem II" and our Inter-Tel AXXESS phone system. However, this does
NOT conclusively show an incompatibility with ALL Inter-Tel AXXESS phone
systems. It is also important to note that, according to Comtrol, it has
not seen this incompatibility with any other non-Inter-Tel phone system.
Also, so that Comtrol isn't completely singled out, Inter-Tel mentioned that
this behavior has been seen with a few other modems from other
manufacturers.
Macy Hallock
+---------------
Aha. Then it's either line current or line audio levels.
Measure the line current before and after the resistor addition.
That will give a clue. I've seen this arise on some modems.
V.32 does require optimal line levels in order to work well.
It is accutally possible to have a "too loud" connection fail.
On some PBX's you can modify the line levels (pads?) from the T1 span
to the stations. Try dropping levels by 3db or so...
(Congratulations on your persistence and efforts to solve this.)
--
Macy M. Hallock, Jr. N8OBG 216.241.7166 fax:216.241.7522
APK Net, Inc. 1621 Euclid Ave. Suite 1230 Cleveland, OH 44115 USA
Justin Time
> As quoted from "Chris Largent" <chris....@spamisnotprofessionalpro-group.com>:
>
> +---------------
> > I just HAD to satisfy my curiosity... As suggested by Inter-Tel, I bought
> > some 100 ohm metal-oxide resistors (1 watt rating; 5% tolerance). I spliced
> > a standard line cord and connected one resistor into the "tip" side (red) of
> > the loop circuit, and connected another resistor into the "ring" side
> > (green) of the loop circuit.
> >
> > Drum roll...
> >
> > This actually resolves the problem!
<<SNIP>>
>
> Aha. Then it's either line current or line audio levels.
>
> Measure the line current before and after the resistor addition.
> That will give a clue. I've seen this arise on some modems.
>
> V.32 does require optimal line levels in order to work well.
> It is accutally possible to have a "too loud" connection fail.
>
> On some PBX's you can modify the line levels (pads?) from the T1 span
> to the stations. Try dropping levels by 3db or so...
>
> (Congratulations on your persistence and efforts to solve this.)
Several years ago we attempted to connect a T1 device to a Northern
SL-1. The upshot was we had to reduce the signal level from 3.2 v p-p
to roughly half that level. The SL-1 refused to sync to a signal that
was delivered at the spec voltages even though their documentation
stated it would accept it.
Rodgers Platt
Floyd Davidson
>
>Several years ago we attempted to connect a T1 device to a Northern
>SL-1. The upshot was we had to reduce the signal level from 3.2 v p-p
>to roughly half that level. The SL-1 refused to sync to a signal that
>was delivered at the spec voltages even though their documentation
>stated it would accept it.
>
>Rodgers Platt
Something else was wrong. Everyone else gets them to work as
specified.
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Macy Hallock
+---------------
> >Several years ago we attempted to connect a T1 device to a Northern
> >SL-1. The upshot was we had to reduce the signal level from 3.2 v p-p
> >to roughly half that level. The SL-1 refused to sync to a signal that
> >was delivered at the spec voltages even though their documentation
>
> Something else was wrong. Everyone else gets them to work as
> specified.
It's entirely possible that there was an unrelated external event.
For example, many years ago, when serial port programmed Adtran HDSL based T1
smartjacks were first coming into common use, we had a number of incidents
where the telco T1 signal peak to peak voltage was set too high as default.
This drove our CSU/DSU's in intermittent errors and flaps and drove us crazy
for a few weeks 'til we found it. (We didn't have a nice TTC or Sunset T1 test
set at the time, only an old Phoenix.) The orgination point of the fault
was traced to an error in the default values in the configuration software
in use by this particular telco. We had to instruct all telco tech's to adjust
this, on each installation, they always missed it. A few months later, updated
configuration software was distributed by the telco and the problems stopped.