l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2002 Sep 21 14:06

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
RE: [vox-tech] Modem question . . . I think it is possible
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [vox-tech] Modem question . . . I think it is possible



I'm a student and am still learning so please, if these are incorrect
statements I would appreciate a clarification (as opposed to a flame)

On Fri, 20 Sep 2002, Shawn Neugebauer wrote:

>
> Your idea is reliant on each device producing a signal that is
> synchronous (received at the same time) with the signals produced
> by the other two devices.

I had thought there was an agreed upon clock hertz level and that the
whole point of trellis as opoposed to the hexagonal mesh encoding ws that
if off sync, it could get back on sync.  I thought that the idea of the
nonlinear encoding in the V34.bis was also designed to automatically sync

> It is one thing to do this with many
> transmitters and a single receiver; it is quite another matter to
> do this with multiple transmitters and two receivers.

I thought that as long as we keep the devices isolated as to when and
where (with respect to the real imaginary on the plane) they are expecting
a signal, then this avoids any complex models

>
> Without synchronous signaling, each device, while able to cancel
> its own transmission through the use of echo cancellation,
> effectively receives two signals---co-channel interference.

I thought that having a 32-state trellis and two 16 state trellis's would
actually not interfere as long as one is phase shifted.

> Although it is technically feasible to separate two signals of the
> type transmitted by a V.34 modem, it is very, very difficult in
> practice.

By this do you mean it would be an unacceptable degradation (like +30%)?

>
> I think there would be significant problems with other aspects
> of V.34 communication (many of which are not linear and are not
> separable in the manner you describe), as well.

like what?  I have limited documentation on it dating back at least 4-5
years.

>
> The idea was worth considering, but I don't think there's much
> merit in tweaking the V.34 spec to accommodate multi-user
> communication---there are other physical-layer communication
> schemes better suited for this.  If one wanted to do this, one
> would be better served directly designing a system for it.
>
> shawn.

Thanks

Quoth Myself On a Previous Day:
> > I know the post is a few days old but I was intrigued with the idea.
> > modems capable of the v.34 standard have something called an auxiliary
> > channel by which it can exchange information on such things as line
> > quality.  It can code using nonlinear, precoding, and 16-trellis along
> > with most modern being able to do 32 and 64 state trellis depending of
> > course on what type of bit (dibit etc) you want to transmit at.  Here is
> > the trick: Because of the ability to use such things as assymetrical
> > transmission and the use of trellis coding, and echo cancellation, each
> > modem will have an idea of sender and reciever.  For the first modem, the
> > other modem will be a sender and the other end of the ppp will be a
> > sender.  This essentially sets what could be a master slave model in order
> > to do correct splitting, with hopefully little interference (via the
> > trellis encoding).  Here is how it would work:
> >
> > Computer 1 is master
> > Computer 2 is slave
> >
> > ppp ISP is ISP
> >
> > Initiate the connection with the master to ISP and send a request for
> > 16-state trellis encoding at 14400 bps.  Ask for 16-state send and
> > 16-state receive.  Put the master on 32-state trellis recieve
> > without confirmation via the auxiliary making each other
> > baud recieved as null or noise.
> >
> > Place slave in 16-state trellis before connecting.  Because of the
> > trellis, it will interpret the data being sent as noise and adjust phase
> > correctly to the nulls.
> >
> > When it sends out a request, the ISP with 16 state trellis which is synced
> > with the master will interpret it as noise and ignore it.  However, the
> > master will take the signals in as extra data.  As long as the master can
> > split every other bit and maintain parity and whatever, it has now set up
> > two channels, one 16 bit with the other laptop and one 16 bit with the
> > ISP.  Each other end will take the 'excess' data as noise and ignore it
> > because it is not in sync.  You now have two linked connections over one
> > line.
> >
> > Truly, the slave still goes to the master which in turns goes to the ISP,
> > however, this would be a sane operation of 14400 bps and a technical modem
> > split.  Implementing it however, is another thing . . . shouldn't be that
> > difficult but also shouldn't be that worthwhile.  Anyway, that is all for
> > now.
> >
> >
> > Sincerely,
> > 	Christopher J. McKenzie
> >
> > 	cjm@ucdavis.edu
> > 	mckenzie@cs.ucdavis.edu
> > 	H: +1 818.9917724
> > 	C: +1 818.4293772
> > 	1815 Mesa Ridge Ave
> > 	Westlake Village, CA 91362
> >
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech@lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox-tech
> >
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

Sincerely,
	Christopher J. McKenzie

	cjm@ucdavis.edu
	mckenzie@cs.ucdavis.edu
	H: +1 818.9917724
	C: +1 818.4293772
	1815 Mesa Ridge Ave
	Westlake Village, CA 91362

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.