Re: [hylafax-users] Error Receiving 2D-MMR from a HP G95 Fax

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.12.13 12:51 Impact wrote:
> Using hylafax 4.1.8-1rh8.
> Digi Datafire modems in class 2.0
> Receiving a fax from an HP officejet G95.  one page.
> All that gets transmitted is a thin horizontal line.  Less than 1k pdf
> file is generated.
> The fax is received just fine if the modems are forced to answer in
> 2D-MR.
> Session Trace below.
> Any ideas?

> Dec 13 15:30:29.28: [13782]: --> [20:+FCS:0,5,0,2,3,1,0,0]
> Dec 13 15:30:29.29: [13782]: REMOTE wants 14400 bit/s
> Dec 13 15:30:29.29: [13782]: REMOTE wants page width 1728 pixels in
> 215
> mm
> Dec 13 15:30:29.29: [13782]: REMOTE wants unlimited page length
> Dec 13 15:30:29.29: [13782]: REMOTE wants 3.85 line/mm
> Dec 13 15:30:29.29: [13782]: REMOTE wants 2-D MMR
> Dec 13 15:30:29.29: [13782]: REMOTE wants T.30 Annex A, ECM
> Dec 13 15:30:29.29: [13782]: --> [7:CONNECT]
> Dec 13 15:30:29.29: [13782]: RECV: begin page
> Dec 13 15:30:29.29: [13782]: RECV: send trigger 022
> Dec 13 15:30:29.29: [13782]: <-- data [1]
> Dec 13 15:30:56.81: [13782]: RECV/CQ: Invalid EOL code word, row 0, x
> 0
> Dec 13 15:30:56.81: [13782]: RECV/CQ: Bad 2D pixel count, row 0, got
> 0,
> expected 1728
> Dec 13 15:30:56.81: [13782]: RECV/CQ: Invalid EOL code word, row 1, x
> 0
> Dec 13 15:30:56.81: [13782]: RECV/CQ: Bad 2D pixel count, row 1, got
> 0,
> expected 1728
> Dec 13 15:30:58.27: [13782]: RECV: 217 bytes of data, 2 total lines

By the way (it's not relevant to your problem), these 5 lines above are 
fixed in HylaFAX CVS because in CVS the decoder now supports MMR.

> Dec 13 15:30:58.27: [13782]: --> [26:+FHR: FF 13 BF 2F 00 00 63]
> Dec 13 15:30:58.27: [13782]: --> [14:+FPS:1,1,1,0,0]

Short answer:

Set Class2CQCmd to "AT+FCQ=0,0" which disables copy quality checking by 
the modem's firmware.

Long answer:

That +FPS line above is the problem.  The +FPS provides the line count 
in the second parameter, and it claims that the image is only one line 
long.  So this problem is a firmware bug on the part of the Digi 
modem.  I just tried it with my Digi AccelePort RAS, and it does 
exactly the same thing.  Now that the decoder in HylaFAX CVS supports 
MMR we can stop relying on the modem to report the line count for MMR 
faxes, and the patch I've hung on

http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=482

does exactly that for HylaFAX CVS, but even if you were to use that 
you'd find that you would just get a big blank page instead of the 
image that was transmitted by the sender.  The problem is that the 
modem firmware copy quality mechanism is broken for MMR and is thus 
breaking the firmeware line-counting.  So even if we avoid the firmware 
line-count, we still run into the real problem that the CQ mechanism is 
broken.  You'll notice that the line count will be fine if you simply 
disable the firmware CQ with Class2CQCmd as I mentioned above.

I'm CC'ing the folks at Digi in hopes that they can fix their 
firmware.  In the meantime, just disable the modem's CQ.

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@xxxxxxxxxxxx*