Hylafax Mailing List Archives

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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*



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services