Linmodems Mailing list Archives

Mailing-List: contact discuss-help@linmodems.org; run by ezmlm
Message-ID: <19990727115126.B147@bug.ucw.cz>
Date: Tue, 27 Jul 1999 11:51:26 +0200
From: Pavel Machek <pavel@bug.ucw.cz>
To: Fabrice Bellard <bellard@email.enst.fr>, discuss@linmodems.org
Subject: Re: Let's begin to code!
References: <19990719230105.12689.qmail@hotmail.com> <379CEB65.F708F490@email.enst.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <379CEB65.F708F490@email.enst.fr>; from Fabrice Bellard on Tue, Jul 27, 1999 at 01:12:37AM +0200

Hi!

> I think we have enough spoken - it is time to code. In particular, I
> think it is irrelevant to try to understand how a given chipset is
> working. We can begin now to write a generic linmodem, and then try to
> adapt it for each chipset. 

I do not think it is irrelevant to write specific code: generic code
without any drivers is pretty hard to debug. BTW I've already started
doing some lucent work.

> So a possible architecture is :
> 
> 1) an AT command emulator & serial port emulator. No need to redevelop
> it, it is already included in the kernel tree, see
> linux/drivers/isdn/isdn_tty.c.

You don't need to emulate serial ports. AT command emulator.. Well, I
guess I don't like AT commands and would prefer something more
inteligent.

> 2) a connection - hangup - dialing layer. No special skills are needed
> to develop it. It is basically a state machine, with a few tones
> generator for DTMF. Many DTMF generators are already available.

That's what I'm working on now.

> 3) a V34 protocol layer. It must handle the V34 connection negociation
> by generating some V34 tones and decoding the V34 negociation packets.
> Then, if we exclude V42 & V42bis which could be implemented later, we
> only convert bytes into a stream of bits with start & stop bits. No
> special skills needed... you need to read the V34 spec.
> 
> 4) a V34 data pump(*). The emission part is long to write, but not too
> difficult since all is explained in the specs (provided that the V34
> spec is accurate !). The reception part requires some telecom skills...
> this is the tickiest one. In particular, the modem must synchronize to
> the incoming signal, and then it must do echo cancelation and
> equalization. It might be simpler to begin with low V34 speeds which may
> require less accurate filters & algorithms.

Ok, go ahead, I'm looking forward to your results ;-).

> A shorter path may be to begin to implement 5) instead of 3) and 4):
> 
> 5) a low speed data pump such a V22 ou V23. The code has already been
> developped (see linux/drivers/net/hamradio/soundmodem) so it is mainly a
> problem of API definition (we may need to factorize the code for
> hamradio, linmodem & isdn).

Q: Do you want our winmodem drivers in kernel on not? ltmodem is
currently developed in userspace, which have some problems with
interrupts, but those can be eliminated by busy-waiting (it is not
that bad). I guess it is going to be neccessary for it to go into
kernel, but it does not seem neccessary now.

> 6) write drivers for each chipsets. The primitives are in fact very
> simple : send & receive PCM samples, control the on/off hook relay. Some
> commands may be added later to be compliant with all the countries (in
> particular the selection of the line impedance, control the pulse dial
> relay).

That's what I'm currently doing for lucent winmodem. I can currently
checksum winmodem's rom and that's about all :-).

								Pavel
-- 
I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel.  Pavel
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Webmaster: Russell Nelson
Last modified: Wed Jul 30 11:02:43 EDT 2003