Faxpoll server with USR Courier V34+

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

Sam Leffler wrote:
>     To:  gerhard@ats.xs4all.nl (Gerhard Ahuis)
>     Subject:  Re: Faxpoll server with USR Courier V34+
>     Cc:  mgetty@muc.de
>     Date: Thu, 18 Jan 1996 19:08:22 +0100
>     From:  gert@greenie.muc.de (Gert Doering)
> 
> 	<...stuff deleted...>
> 
>     > 01/17 16:51:25 yS1  fax_wait_for(OK)
>     > 01/17 16:51:25 yS1  fax_wait_for: string '+FPS:1,2288,0,0,0'
>     > 01/17 16:51:25 yS1  page status: +FPS:1,2288,0,0,0
>     > 01/17 16:51:25 yS1  8840 lines received, 0 lines bad, 0 bytes lost
>     
>     This is the next ugly thing: the standard demands hexadecimal responses,
>     the courier sends decimal numbers. *sigh*.
>     
> Eh?  Can you please identify which standard you are referring to (and a
> section or page number would be good)?  

TIA/EIA-592, section 6.1.5.2 "Numeric Constants"

"Numeric constants shall be expressed in hexadecimal, ..."

> I did a quick check on T.class2
> (the forthcoming ITU T.32 standard), "Class 2" (SP-2388-A) and Class 2.0
> (EIA/TIA-592) and can't see anything that says the receive line count value
> should be hexadecimal.

While I can't find any proof that this sentence applies to the line count
as well, it is about the only numerical value (except +FHS and +FNF) that
is larger than 9, so I conclude that the authors must have targeted this
sentence at the line counts and the +FHS value...

> In practice the receive line count returned by a modem is decimal (base 10),

Hmm, I don't know *that* many modems, but I know for sure that ZyXELs in
class 2.0 return the value in hex (while they use decimal in class 2).
When I asked, Brent told me, that class 2.0 demands hexadecimal, too.

I have to try and find out what my ELSA does in 2.0 mode.

> but cannot be trusted (many vendors emulate the old Rockwell firmware bug
> that causes the same value to be returned no matter what data is received).
> The only reliable way to decide how many lines have been received is to 
> count EOL markers in the page data.

Since I don't really care (yet) - I use this line count only for
informational purpose, and reject the page if its shorter than 50 lines -
this doesn't harm me too much. But thanks for the information, I'll work
it in into some future release.

gert

-- 
                                                            //www.muc.de/~gert
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3545980 <---new!!!              gert.doering@physik.tu-muenchen.de