Searching \ for 'Encode 4 keypad digits into 12 Bits?' in subject line. ()
Help us get a faster server
Search entire site for: 'Encode 4 keypad digits into 12 Bits?'.

Truncated match.
'Encode 4 keypad digits into 12 Bits?'
1999\02\18@175406 by

Hi All,

I need to encode 4 keypad digits into 12 Bits.  I have all the digits from 0
to 9.  My
project reads in four keypad numbers from 0 to 9 as they are pressed and I
only have 12 bits
to work with. Given that if I only had digits from 0 to 7 => 000 to 111 I
could encode all four
into 12 Bits.  Given that I also have to include 8 => 1000 and 9 => 1001 it
makes an
interesting problem.

I could also go down to three digits and have 12 bits but I could not get the
requirements
changed.

All suggestions?

Thanks!!

Paul

Hi,

If you really need all possible four digit decimal numbers to fit into ONE
12-bit number,you have a real problem. 12-bits only has 2^12=4096
combinations and there are 10000 combinations in an unresitricted 4-digit
decimal number. There are many solutions to the problem if you can accept
the input as several 12-digit numbers, OR, if you don't need to allow all
possible 4-digit numbers.

Sean

At 05:47 PM 2/18/99 EST, you wrote:
{Quote hidden}

| Sean Breheny
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
shb7cornell.edu  Phone(USA): (607) 253-0315 ICQ #: 3329174

Who wrote the requirements?

If you have four digits, there are 10,000
possible values to encode (0-9999).

With 12 bits, you can represent only
4,096 distinct values.

10,000 into 4096 does not compute.

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
On Thu, 18 Feb 1999 17:47:26 EST PDRUNENAOL.COM writes:
>Hi All,
>
>I need to encode 4 keypad digits into 12 Bits.  I have all the digits
>from 0
>to 9.  My
>project reads in four keypad numbers from 0 to 9 as they are pressed
>and I
>only have 12 bits
>to work with. Given that if I only had digits from 0 to 7 => 000 to
>111 I
>could encode all four
>into 12 Bits.  Given that I also have to include 8 => 1000 and 9 =>
>1001 it
>makes an
>interesting problem.

There are 10000 4-digit numbers and 4096 12-bit numbers.  So it isn't
possible to encode every 4-digit number into a unique 12-bit number.  You
could take the 4-digit number mod 4096, reusing all the 12-bit numbers
twice and some of them 3 times (i.e. 0001, 4097, and 8193 are all
represented as 0000 0000 0001 in 12 bits).  Or you could not allow the
user to enter a number larger than 4095.

>
>I could also go down to three digits and have 12 bits but I could not
>get the
>requirements
>changed.

There are only 1000 3-digit numbers so not all the 12-bit combinations
will be used.  Three digit decimal numbers can be converted to 10 bits
since 2^^10 = 1024.

___________________________________________________________________
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

Glenville T. Sawyer   ( the 48 year old )
Outback Communications.   South Australia
Theatre, Concert Lighting, Special Effects, Props. & more !
Embedded Control systems for Theatrical Applications

>I need to encode 4 keypad digits into 12 Bits.  I have all the digits from
0
>to 9.  My project reads in four keypad numbers from 0 to 9 as they are
pressed and I
>only have 12 bits to work with. Given that if I only had digits from 0 to 7
=> 000 to 111 I
>could encode all four into 12 Bits.  Given that I also have to include 8 =>
1000 and 9 => 1001 it
>makes an interesting problem.

An conceptual idea I once applied to using EPROMS to handle
and the "rub" was that we only had 8 bits of width to work with) -
You have an extra 4 - but ...  WARNING - not easy , but possible ...........

The concept relied upon applying "Karnaugh" mapping to the data,
with just 0-9 at any one time there will only ever be a maximum of
3 "ones" (1's) in any of the 4 digit positions, by example, "7" (0111)
is the "largest" pure binary value that can appear in any of the 4 digit
locations.

I will admit, some of the finer details are now a little hazy - 'twas a
long
time ago (well for me it was), but by mapping which digits are
High/Low you can look at doing a compare and reduce bit overhead
requirements ..

If digit 'n'  = GT 8 then obviously it is only going to be 1000 or 1001 (8
or 9)
If digit 'n'  = LT 8 and GT 1 then 3 bit positions only are needed to
"describe"
the data.

We have an added advantage with this application, in that you have
a micro to do the comparisons, I at that time did not, it had to be a
hardware function.

Have a play with the idea above and see what YOU come up with.

Sorry I about not being too specific on this - that is ... "here's the code
you need",
but at present I do not have the time resources to get stuck into it too
deeply,
but hopefully this will promote some "throwing around" of ideas, that have a
more
than better chance of success.

Regards for now,
Glenville.

It is possible if you can afford to use the first digit
just from 0 to 4, the others from 0 to 9.
See, 12 bits makes 4096 combinations...

Other possibility is that old "Exclusive OR" multiple
combinations that "squeeze" bytes one over another, but
I can't find the algoritm.

have fun,

Wagner Lipnharski
http://www.ustr.net

Glenville T. Sawyer wrote:
> >I need to encode 4 keypad digits into 12 Bits.  I have all the digits from
> 0
> >to 9.  My project reads in four keypad numbers from 0 to 9 as they are
> pressed and I
> >only have 12 bits to work with. Given that if I only had digits from 0 to 7
> => 000 to 111 I
> >could encode all four into 12 Bits.  Given that I also have to include 8 =>
> 1000 and 9 => 1001 it
> >makes an interesting problem.

"One more time ..."

You can certainly squeeze the bits to get
an entity with fewer bits, but you can't
represent more than 4096 distinct values
in a 12-bit number. That is, you can't
recover the original information without
some metaphysical phenomenon, so it is
futile to seek some algorithm that does.

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
Glenville T. Sawyer   ( the 48 year old )
Outback Communications.   South Australia
Theatre, Concert Lighting, Special Effects, Props. & more !
Embedded Control systems for Theatrical Applications
Subject: Re: Encode 4 keypad digits into 12 Bits?

I agree, you cannot pack a WHOLE NUMBER greater than 4096 into just 12
bits,
however if "user input" from the keypad was in the range of "0000" to "7777"
then you can fit that into just 12 bits, with only a simple encoding and
extraction
scheme.

Digit 1          Digit 2      Digit 3
"0" 0000           0000        0000
"1" 0001           0001        0001
"2" 0010           0010        0010
"3" 0011           0011        0011
"4" 0100           0100        0100
"5" 0101           0101        0101
"6" 0110           0110        0110
"7" 0111           0111        0111

Digit 4 uses the MSB (Left side) of each of the other 3 digits

"0" 0nnn          0nnn        0nnn
"1" 0nnn          0nnn        1nnn
"2" 0nnn          1nnn        0nnn
"3" 0nnn          1nnn        1nnn
"4" 1nnn          0nnn        0nnn
"5" 1nnn          0nnn        1nnn
"6" 1nnn          1nnn        0nnn
"7" 1nnn          1nnn        1nnn

>From this we see that we have utilised the MSB -, without disrupting the
original 0-7 data from digits 1,2 & 3.

NO it does NOT meet the target specification, we are in fact 2,222 short
of the highest required number, but it does (hopefully) provide an
indication
that we can pack numbers that are a little higher than 4096 into the 12 bits
that we have available.

Well it was a good exercise anyway !, I needed the mental-stim'
had just finished a straight 36 hours session (not PIC related -but
it will be when I finish the design work)   :-)

Regards,        Glenville.

>>> I need to encode 4 keypad digits into 12 Bits.  I have all the
>>> digits from 0 to 9.  My project reads in four keypad numbers from
>>> 0 to 9 as they are pressed and I only have 12 bits to work with.

> I agree, you cannot pack a WHOLE NUMBER greater than 4096 into
> just 12 bits, however if "user input" from the keypad was in the
> range of "0000" to "7777"

Limiting each digit to 0..7 violates a given requirement.

> then you can fit that into just 12 bits,

Obviously.  It's 4 octal digits.

> with only a simple encoding and extraction scheme.  [store 1 bit
> from 4th digit as MSB of each of the other 3 hexadecimal digits]

An even easier encoding is to store each octal digit as a 3-bit
wide field in the 12-bit word.

> NO it does NOT meet the target specification, we are in fact
> 2,222 short of the highest required number,

Uhhhh, d'10000' - o'10000' != d'2222'

Actually, you are 5,904 states short of the requirement (for
a 4 digit decimal number ranging from 0000 to 9999 given the
4,096 possible combinations in a 12-bit word).

> but it does (hopefully) provide an indication that we can pack
> numbers that are a little higher than 4096 into the 12 bits

No it doesn't.  12 binary digits gives 4,096 discrete states.
Nothing more can be packed in without information loss.

> had just finished a straight 36 hours session

Maybe sleep is more in order than algorithm design. :-)

Lee Jones

Glenville T. Sawyer   ( the 48 year old )
Outback Communications.   South Australia
Theatre, Concert Lighting, Special Effects, Props. & more !
Embedded Control systems for Theatrical Applications

I concur, we all (I hope) agree that it is simply NOT POSSIBLE
to meet the target requirement * Anyway *, given the number of
bits that are available, I was attempting to "salvage" whatever
I could from the situation (that is 12 bits only).

With this we can - as Lee Jones observed correctly, use an Octal
scheme for the entire 4 digits - but ONLY from 0-7 for each of the
digit positions - using what we have been given.

I do indeed realise that the customers application will require
(to meet "target" specifications) a FULL16 Bits.

Hope you didn't think that I totally "lost the plot" on that one,
but as I have indicated above, used it as a "salvage" method
to see just what we COULD do,  given the premise that we are
not going to be able to meet the "spec" anyway.

Cheers all, Glenville.

Am not quite sure, look:

separate the 12 bits in 3 bytes, and give names A B and C

bits ->   0000 (a)    0000 (b)    0000 (c)

now, the 4 numbers can be any hexadecimal representation,
we will call them  N1, N2, N3 and N4.

use the formula:

Step 1) Apply N1 exclusive OR over A and B
Step 2) Apply N2 exclusive OR over       B and C
Step 3) Apply N3 exclusive or over A and       C
Step 4) Apply N4 exclusive or over A and B and C

I did random combinations for N1,2,3,4
as   7, C, 5, D   or   1, 2, 4, 8   or   B, 2, D, 6

Step 5) To retrieve back N4, just make exclusive OR
of A over B over C

Step 6) Now, apply N4 exclusive or over A and B and C

You will get on A, B and C, the same result you
got previously on the Step(3) above.

Now, this is just third grade group combination.

What bit combination of two given numbers N1 and N2
can make the result in B, while the same  N1 and N3
can make the result in A, while the same  N2 and N3
can make the result in C?

here goes the example of N1,2,3,4 =  B, 2, D, 6:

A        B        C

Step 1   1011     1011     0000    XOR N1 over A B -
Result   1011     1011     0000

Step 2   ----     0010     0010    XOR N2 over - B C
Result   1011     1001     0010

Step 3   1101     ----     1101    XOR N3 over A - C
Result   0110     1001     1111

Step 4   0110     0110     0110    XOR N4 over A B C
Result   0000     1111     1001

Step 5   0000
1111   Xor A B C
1001
Result   0110   Get Back the N4 = 6

Step 6   0000     1111     1001   Step 4 results
0110     0110     0110   XOR retrieved N4 over ABC
Result   0110     1001     1111   The same as result on Step 3

What is   N1       N1       --    ??
--       N2       N2    ??
N3       --       N3    ??

In exclusive or format that can generate
ABC as   0110     1001     1111   ??

It looks like that silly math question:
Joe, Mary and Peter has certain quantity of oranges,

Joe  + Mary  = 5
Joe  + Peter = 6
Mary + Peter = 7

How many oranges everyone has?
Then you divide by 2 (n-1): 9 oranges
Now, 9 - 7 (Mary + Peter) = 2 Joe
Mary = 5 - Joe = 3
Peter = 7 - Mary = 4
So, Joe 2, Mary 3, Peter 4.

What about apply the same idea on A B and C above?
I did not tested it consistently, but...
something to the friends with time to think about.
Probably it won't work at all, but somebody can check it?

:)

Wagner.

Glenville T. Sawyer wrote:
{Quote hidden}

>
> >>> I need to encode 4 keypad digits into 12 Bits.  I have all the
> >>> digits from 0 to 9.  My project reads in four keypad numbers from
> >>> 0 to 9 as they are pressed and I only have 12 bits to work with.
>
> > I agree, you cannot pack a WHOLE NUMBER greater than 4096 into
> > just 12 bits, however if "user input" from the keypad was in the
> > range of "0000" to "7777"
>
> Limiting each digit to 0..7 violates a given requirement.

It does. The point was moot from the start.

{Quote hidden}

Not octal. That's Binary Coded Decimal (BCD).

>
> > NO it does NOT meet the target specification, we are in fact
> > 2,222 short of the highest required number,
>
> Uhhhh, d'10000' - o'10000' != d'2222'

True. But BCD 7777 which is the highest BCD number represented is 2222 less
than the highest number needed to be represented, which was his point.
{Quote hidden}

Again not the point. Which 4096 numbers which can be represented is...

BAJ
>
> > had just finished a straight 36 hours session
>
> Maybe sleep is more in order than algorithm design. :-)
>
>                                                 Lee Jones
>

>
> Glenville T. Sawyer   ( the 48 year old )
> Outback Communications.   South Australia
> Theatre, Concert Lighting, Special Effects, Props. & more !
> Embedded Control systems for Theatrical Applications
>
> I concur, we all (I hope) agree that it is simply NOT POSSIBLE
> to meet the target requirement * Anyway *, given the number of
> bits that are available, I was attempting to "salvage" whatever
> I could from the situation (that is 12 bits only).
>
> With this we can - as Lee Jones observed correctly, use an Octal
> scheme for the entire 4 digits - but ONLY from 0-7 for each of the
> digit positions - using what we have been given.
>
> I do indeed realise that the customers application will require
> (to meet "target" specifications) a FULL16 Bits.

Actually it requires between 13 and 14 bits. So 14 bits will always meet the
spec...

>
> Hope you didn't think that I totally "lost the plot" on that one,
> but as I have indicated above, used it as a "salvage" method
> to see just what we COULD do,  given the premise that we are
> not going to be able to meet the "spec" anyway.
>
>
> Cheers all, Glenville.
>

>  I agree, you cannot pack a WHOLE NUMBER greater than 4096 into just 12
> bits,
> however if "user input" from the keypad was in the range of "0000" to
"7777"
> then you can fit that into just 12 bits, with only a simple encoding and
> extraction
> scheme.

If you limit the input to 4 times 0..7 then your total input
is limited to 8^4 WHOLE NUMBERS = 4096. Ok, that fits,
but that is an entirely different problem.

Wouter.

Wagner: I have been lurking on this list for a couple
of weeks, and I have appreciated the excellent
information from you and several others on this list.

However ...

The original keypad problem was that of attempting to
map a set of 10,000 different elements (the decimal
numbers 0000-9999) into a set of 4,096 different
elements (12-bit binary numbers). That's pretty easy,
unless you have to be able to retrieve the original
value.

The person who originally posted this question said
he thought it is a pretty interesting problem. I
disagree: it's very uninteresting (once you realize
that ***it can't be done***).

You have actually enhanced the problem by giving
a way to compress a set having 65,536 elements
(the hex numbers 0000-FFFF) into the set
of 12-bit binary numbers. See above paragraph
for the answer (still can't be done in a way
that allows us always to retrieve the original
value).

The interesting part is seeing how many ways people
can deny the impossibility.

As to your specific example, you have certainly
demonstrated a procedure that can retrieve the
original value of N4. You'll get the right value
for N4 every time. However ...

Consider the following:
N1 = A (1010) -- different from yours
N2 = 3 (0011) -- different from yours
N3 = C (1100) -- different from yours
N4 = 6 (0110)

If you apply steps 1-4 of your procedure, you
get

A = 0000 (same as yours)
B = 1111 (same as yours)
C = 1001 (same as yours)

So, a different set of values for
N1,N2,N3,N4 give the same set of
values for A,B,C.

Or, looking at it from the bottom up, if we
are given values A, B, and C obtained by
your procedure, we want to find unique values
of N1, N2, N3, and N4. Your procedure can
be expressed as a set of three equations
that connect all of the variables:

A = N1 (exor) N3 (exor) N4
B = N1 (exor) N2 (exor) N4
C = N2 (exor) N3 (exor) N4

If we consider this to be three equations in
the four unknowns (N1,...,N4), we see that
this particular system of equations has more
than one solution. (You gave one set of values
N1,...,N4 that give these values of A, B, C;
I gave another.) In math class they usually
give you systems of linear equations to solve with
real numbers and real-number arithmetic, but
the math is "more-or-less the same" with binary
numbers and the linear binary operator "exor".

The "silly math question" with the oranges happens
to describe a system of three independent equations
with three variables. In general, for N equations
with N unknowns (using real number arithmetic),
there are exactly three possibilities (depending
on the characteristics of the particular
set of equations):

No solutions (inconsistent equations).
Exactly one solution (consistent, independent equations).
Infinite number of solutions (consistent, non-independent equations).

The "orange" equations that you presented are consistent
and independent, and you have correctly determined
the unique solution.

It is left as an exercise for the interested reader
(and I would be surprised at this point to learn
that there are many left) to give the possibilities
for N equations and N+1 unknowns.

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
Some years ago we were told that the max baud rate that could be transmitted
over
the phone line was at 2400 baud.  I guess that some metaphysical phenomenon
occurred.

I guess what you are saying that I can encode the 4 digits, say 3691 to be
some 12- bit number but it may also share the same number with say 7409 or
6751?  There is not a one-to-one relationship because I really need to keep
all 16 bits.

In a message dated 2/19/99 9:14:31 AM Central Standard Time,
dave.evansDLCC.COM writes:

<< "One more time ..."

You can certainly squeeze the bits to get
an entity with fewer bits, but you can't
represent more than 4096 distinct values
in a 12-bit number. That is, you can't
recover the original information without
some metaphysical phenomenon, so it is
futile to seek some algorithm that does.

Dave Evans >>

(If it isn't one-to-one, it the inverse
map doesn't exist.)

A simple BCD-to-binary conversion will always
give a result that fits into a 14-bit number,
since
9999 < 2^14

Furthermore, since
2^13 < 9999,
13 bits are not sufficient.

The guys who said the max rate was 2400 baud
were making certain assumptions about bandwidth,
noise models, physical characteristics and assumed
properties of twisted-pair copper conductors, etc...

The guy who said that "you can't put ten pounds
of sugar into a five-pound bag" was me, but my
boss disagrees about twice a month (except in
years divisible by 1000).

Best regards,

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
If the keyboard has digits 0-9, how do we encode,
for example, user input "0009". If you can't handle
that value, then you cant claim to have successfully
handled numbers in the range 0000-7777.

If the keyboard has digits 0-7, your method gives
one possible encoding. Me? I would just pack the
four octal digits, as entered, into a 12-bit word.

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
I am not saying that any mathematical formula or metaphysical
phenomenon will compress 16 into 12 bits, but also, I always
remember that the word that less crossed the mind of people like
Einstein, Edison, V.Braun, Copernicus, Dumont, Bell, Schotkky,
Da Vinci, and so many others not less important, was "impossible".

Quadrature and amplitude modulation was the key to speed up our
modems. When before we used several cycles in a particular
frequency to transmit just one bit, now we transmit several bits
in a single 2400Hz cycle time.

IBM mainframes used ECC (error correction) hardware to compress in
some way 32, 64 or 128 memory bus data into extra 8 or more bits, so
it was able to identify and correct any failing 1, 2 or more bits.

The important here is not to find out a way to compress 16 into 12
bits, but to think about it, and enter into the oldest human fight,
against the "impossible" word.

We are able to find out solutions for *all* our emerging problems,
when we really need it.  When PC hard disks were expensive and
programs
needed more and more space, we invented the doublespace, doubledisk
or other software solution to compress data.  It was a fantastic
technique, it was "standard" in some Microsoft DOS versions, and all
over the world people used it.  It was fast, easy, problems yes, but
"even impossible", it increased the HD space, and gave us free space.
But then, everyone forgot it when HD manufacturers found an almost
"impossible" way to reduce HD prices.

It's the "human mind free" that makes you decide to see something as
"impossible" or not. There is nothing wrong to think in either way,
I deeply respect that, but you can't deny that we are surrounded by
all kinds of impossible things. Ice in your refrigerator is just one.

"Long live to Mr. Dick Tracy and his
marvelous futuristic wireless phone"

Yes, Exclusive OR solutions can work pretty well, except if the
results goes to all zeroes or all ones. That's a dead end.

-------------------------------
Wagner Lipnharski - Director RD
UST Research Inc. - Orlando, Fl
http://www.ustr.net
-------------------------------

> The important here is not to find out a way to compress 16 into 12
> bits, but to think about it, and enter into the oldest human fight,
> against the "impossible" word.

An admirable sentiment, to be sure, and I fully agree, but certain things
*are*, can can be proven to be, impossible.

Let's suppose, for a second, that such a guaranteed method of compressing
4 decimal digits into 12 bits, *with no loss of data* existed. Well, we'd
have ourselves an infinite compression scheme - simply convert your data
to base 10000, and compress. Rinse, and repeat, until your entire hard
drive is stored in a single bit! Whoo hoo!

I seem to recall there's some similar thing involving trisecting angles
using only a bisector. Despite the fact that this has been proven
mathematically impossible, people still insist on trying... I'm also
aware that many years ago, people believed that irrational numbers were
an impossibility, (in fact, legend has it that one of Pythagorus's
followers was stoned to death for showing that sqrt(2) was
irrational!)... but then, our concepts of mathematical proof are possibly
a little more rigorous today than they used to be :)

Cheers,

Ben

>Quadrature and amplitude modulation was the key to speed up our
>modems. When before we used several cycles in a particular
>frequency to transmit just one bit, now we transmit several bits
>in a single 2400Hz cycle time.

So it would work in 12 bits of trinary.

>
> Some years ago we were told that the max baud rate that could be transmitted
> over
> the phone line was at 2400 baud.  I guess that some metaphysical phenomenon
> occurred.

Actually I beleve that's still true. For modems the baud rate (number of
transistions per second) on the phone line hasn't moved much. What has
changed significantly is the number of bits that are encoded in each transition
thereby changing the bit rate. I believe for 33.6 modems (which are the last
to work on both ends of a regular phone line. V90 and X2 56K modems require
special equipment on the ISP end IIRC) that the baud rate is 2400 with each
symbol change carrying 14 bits of information. So in short for the modem there
are 16384 symbols to choose from and 2400 of those symbols are transmitted
per second.

Nothing special occured.

>
> I guess what you are saying that I can encode the 4 digits, say 3691 to be
> some 12- bit number but it may also share the same number with say 7409 or
> 6751?  There is not a one-to-one relationship because I really need to keep
> all 16 bits.

It isn't 16 bits like I said in my last post but between 13 and 14. It takes
16 bits if you're encoded in Binary Coded Decimal.

The only way to get out of this is with compression. But compression can only
occur if there an unequal probability of symbols occuring in the set. if any
of the 10000 combinations can occur with equal probability, there's no way to
do it. However if symbols occur with different frequency, then you can encode
frequently occuring symbols with small than 12 bits and others which are
larger than 12 bits.

BAJ

bit  == binary digit
trit == trinary digit (ternary digit?)

Dave Evans
dave.evansdlcc.com

{Quote hidden}

At 11:33 02/20/99 -0500, PDRUNENAOL.COM wrote:
>Some years ago we were told that the max baud rate that could be transmitted
>over
>the phone line was at 2400 baud.  I guess that some metaphysical phenomenon
>occurred.

actually, the baud rate isn't much higher today (around 3.2kbaud, IIRC).
what has gone up primarily is the bit rate. (baud rate is symbols/second,
bit rate is bits/second, and the factor between them is bits/symbol.)

the high speed modems don't use simple 2 frequency fsk anymore... no
metaphysical phenomenon here :)

ge

I think that lossless compression capitalizes on redundancy;
probability has nothing to do with it. If all possible
4-digit decimal numbers must be stored and recovered
in a fixed length binary word, you can't do it with fewer than
14 bits. (Whoa --- flat statement alert.)

Now, if you want to transmit 4-digit decimal numbers
from one place to another, a variable-length encoding
scheme can give better performance than a fixed-length
encoding. Thanks Samuel F. B. Morse.

Dave Evans, KW7X
dave.evansdlcc.com

> {Original Message removed}
The bandwidth used is proportional to the symbol rate
(baud rate?). The information transfer rate in bits
per second is the product of

Symbol Rate (times) the number of information bits per symbol

Dave Evans
dave.evansdlcc.com

> {Original Message removed}
>
> >Quadrature and amplitude modulation was the key to speed up our
> >modems. When before we used several cycles in a particular
> >frequency to transmit just one bit, now we transmit several bits
> >in a single 2400Hz cycle time.
>
> So it would work in 12 bits of trinary.
>

Wouldn't that be 'trits'?

And you'd only need 9 trits which can encapsulate 19000 and change values.

BAJ

Hm....

put a delay on some of the lines, and multiplex them into the same line

when you sample, read twice, one to get the base number, and one to get
the "extra lines".

A simple delay line, consists of an RC component.

similar to a debounce circuit, just use bigger values, to delay more?

GREY

GRAEME SMITH                         email: grysmithfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.

> Some years ago we were told that the max baud rate that could be transmitted
> over
> the phone line was at 2400 baud.  I guess that some metaphysical phenomenon
> occurred.

|Actually I beleve that's still true. For modems the baud rate (number of
|transistions per second) on the phone line hasn't moved much. What has
|changed significantly is the number of bits that are encoded in each transition
|thereby changing the bit rate. I believe for 33.6 modems (which are the last
|to work on both ends of a regular phone line. V90 and X2 56K modems require
|special equipment on the ISP end IIRC) that the baud rate is 2400 with each
|symbol change carrying 14 bits of information. So in short for the modem there
|are 16384 symbols to choose from and 2400 of those symbols are transmitted
|per second.

|Nothing special occured.

Actually, a number of specifically-identifiable special-something's
occurred:

[1] The quality of internal echo cancellation improved to the point
that the same frequencies may be used for both directions of
data transfer.

[2] Rather than trying to output a single waveform which encodes all
the data, modems switched to using several waveforms at different
frequencies [2400-baud QAM can make sense when viewed on a scope,
though it'd be a bit hard to interpret; at 9600-baud and above,
the superimposed signals make visual identification of the data
impossible).

[3] The current 56K modems work on an entirely different principle
from all previous types: rather than generating an analog signal
(which will go through an 8-bit A/D sampled at 8KHz and then get
carried digitally to a phone company office near the destination,
where it will be re-converted to analog) the originating modem
feeds a digital signal directly to the telco.  The receiving modem
"simply"* has to identify what the different possible signal levels
from the telco DAC "look like" under different conditions and can
then look for them. (*)of course, it's not really all that simple...

Note that unlike earlier modem standards which will work with any type
of phone connection that passes audio reasonably faithfully, the 56K
modems have explicit requirements about how the phone company equipment
should work.  Note as well that to transmit 56K, it's necessary to have
the equivalent of an ISDN line to the telco; there's no way two people
with ordinary phone lines can achieve that sort of rate between each
other.

Final note and advice: some digital phone switches will "munge" the
data going through them slightly in ways which would not be audible
but which can cause problems with 56K communications.  My 56K modem
would often not work well at all until I upgraded it to V.90 which is
designed to identify and avoid these errors; since then it has worked
much better (throughput of ~6Kbytes/second on compressed files is now
pretty common).  If you have a 56K modem and haven't liked it, I'd
suggest seeing if a V.90 upgrade might help.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...