Re: [hylafax-users] Failed to properly detect high-speed data carrier

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2005.02.03 12:58 John Kosta wrote:
> All,
>
> I am sorry to post this problem to the list.  I am getting the error 
> "Failed to properly detect high-speed data carrier" with a just 
> purchased Multitech MT5600ZDXV after also receiving the error with a 
> Multitech MT2834ZDXb (Class 2 only).  I have read through the 
> archives and tried several of the suggestions therein, but continue 
> to experience this problem.

John,

I've received your logs in full and have looked at them.

I'm sorry, but I can't do anything about your Class 2-only modem.  I'd 
recommend replacing it if it's giving you fits.

As for the logs with the Class 1 modem...

There seems to be a fair amount of interference between you and this 
sender.  I say that because in all of the logs there are lots of 
instances of retraining and PPR signals, both of which generally 
indicate audio quality problems between the sender and the receiver.  
You may run into the same kinds of errors if you just replace the 
sender's fax machine (unless the fax machine itself is causing the 
noise).  I think that the *right* way to fix this problem is to figure 
out where the line noise/interference is coming from.  Have the lines 
tested.  Avoid PBXes.  Try different equipment (a different fax 
machine, just to test with).

As for the fax protocol failure here (forgive me if this gets 
technical)...

90% of my "failure to properly detect high-speed data carrier" errors 
look like yours: they happen with +FCERROR messages immediately 
following our transmission of a PPR signal.  Sometimes it will happen 
after TCF (CFR), sometimes it will happen after MCF, but these are much 
more rare.  I blame T.30 for this problem (bad protocol design mixed 
with bad programmers makes for trouble).

You'll notice that your logs will have this kind of flow:

  get PPS, send PPR
  get PPS, send PPR
  get PPS, send MCF
  get PPS, send PPR
  get PPS, send PPR
  +FCERROR and failure

Sometimes it will involve fewer PPRs:

  get PPS, send PPR
  get PPS, send PPR
  get PPS, send MCF
  get PPS, send PPR
  +FCERROR and failure

I've even seen it happen after just one or two PPRs.  The underlying 
problem is that ECM protocol allows the sender to signal a "speed 
change" with CTC or a "give up" with EOR following the 4th PPR signal 
on the same block.  The real problem, though, is that ITU T.30-A.4.1 
isn't clear about the "per block" part... the "per block" part is only 
made clear in T.30-A.1.3.  Some senders will sometimes count PPRs 
spanning multiple blocks.  Some senders will sometimes count PPRs 
spanning (get this) different fax sessions.  It's like they have some 
"counter" and they don't always reset it when they're supposed to (at 
the beginning of every new block).  Every time the counter reaches a 
multiple of 4 then it will think that it can send CTC/EOR.  So 
unfortunately, this essentially leads us to a behavior on some fax 
senders to pretty much assume that they can return a signal (and they 
don't limit themselves to CTC and EOR, sometimes they do DCN - which is 
okay, I guess) after any PPR response by us as a receiver.  And that 
assumption is completely inaccurate.

If the sender is signalling with V.21 and the receiver is listening for 
V.17 (for example), then it will generate an +FCERROR message on the 
receiving side.  This isn't the only reason behind +FCERROR, though.  
Generally the best way to handle +FCERROR is to just "try again" a 
number of times because sometimes the switching of carriers can make 
noises that cause +FCERROR to happen.  But if the sender really was 
signalling with V.21, then this approach will make us miss that signal 
(which they really should not be sending at that moment, per the spec).

There's another problem, too...

You see, most of the time the sender is in a precarious situation.  The 
sender, most of the time, must understand the reciever's MCF 
(confirmation signal) or PPR (signal to retransmit frames) signals the 
first time the receiver sends them - because the receiver will usually 
only send them once and then move on expecting the sender to react 
accordingly.  But if the sender didn't get the signal properly it will 
likely retransmit its earlier V.21 signal or will transmit CRP (command 
to repeat), and this pretty much will be a disasterous attempt because 
the receiver will not be expecting that (it will be expecting a 
high-speed data carrier instead).  That will generate fatal +FCERRORs 
also.

HylaFAX does have some "workarounds" for these problems built-in.  
However, their successfullness is quite limited depending on various 
behaviors that the modem may exhibit.  My guess is that the workarounds 
tend to function better on older Rockwell chipsets than on new Lucents 
because the Lucents tend to follow Class 1 spec more rigidly - which 
kind of kills the attempt to "work around" shortcomings in the specs.  
I *think* that the new Conexants should work like the old Rockwells, 
which is what your Class 1 modem is using.  Even if the workarounds do 
work sometimes, they probably won't work all the time.  They're in 
there as a last-ditch "hail mary" kind of attempt.

T.31 (sometimes called "Class 1.0") eventually did produce its own 
"fix" which includes a few new AT commands, the most significant of 
which is AT+FAR=1 (adaptive receive).  What this command will do is it 
will make the modem "adaptively receive" *any* fax carrier signal, even 
if it was expecting a different one.  So, you would see a troubled fax 
session go something like this:

  <-- AT+FAR=1
  --> OK
  .....
  <-- AT+FRM=145
  --> +FRH:3
  --> CONNECT

This would be in lieu of this happening:

  <-- AT+FRM=145
  --> +FCERROR
  <-- AT+FRM=145
  --> +FCERROR
  .....

It would mean the exact same end-result as:

  <-- AT+FRH=3
  --> CONNECT

Unfortunately, to my knowledge only new Conexant chipsets support +FAR, 
and HylaFAX doesn't support it either yet.  I *think* that your modem 
may support +FAR.

Also, because there is no "carrier changes" at all in V.34-Fax 
(SuperG3) use of it eliminates a lot of this problem.  However, 
V.34-Fax has its own set of problems... namely the fact that it's so 
new that a lot of hardware implementations are still buggy and it will 
take some time for those buggy systems to get replaced, upgraded, and 
updated.

So, anyway, if your line tests and fixes that way don't result in any 
improvements, let me know, and we'll try to see how we can better work 
the matter.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*