Truncated match.
PICList
Thread
'Encode 4 keypad digits into 12 Bits?'
1999\02\18@175406
by
PDRUNEN
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
1999\02\18@180234
by
Sean Breheny
Hi,
If you really need all possible four digit decimal numbers to fit into ONE
12bit number,you have a real problem. 12bits only has 2^12=4096
combinations and there are 10000 combinations in an unresitricted 4digit
decimal number. There are many solutions to the problem if you can accept
the input as several 12digit numbers, OR, if you don't need to allow all
possible 4digit numbers.
Sean
At 05:47 PM 2/18/99 EST, you wrote:
{Quote hidden}>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
>

 Sean Breheny
 Amateur Radio Callsign: KA3YXM
 Electrical Engineering Student
\=
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
spam_OUTshb7TakeThisOuTcornell.edu Phone(USA): (607) 2530315 ICQ #: 3329174
1999\02\18@180648
by
Dave Evans
Who wrote the requirements?
If you have four digits, there are 10,000
possible values to encode (09999).
With 12 bits, you can represent only
4,096 distinct values.
10,000 into 4096 does not compute.
Dave Evans
.....dave.evansKILLspam@spam@dlcc.com
> {Original Message removed}
1999\02\18@183602
by
Mike Keitz

On Thu, 18 Feb 1999 17:47:26 EST PDRUNENKILLspamAOL.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 4digit numbers and 4096 12bit numbers. So it isn't
possible to encode every 4digit number into a unique 12bit number. You
could take the 4digit number mod 4096, reusing all the 12bit 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 3digit numbers so not all the 12bit combinations
will be used. Three digit decimal numbers can be converted to 10 bits
since 2^^10 = 1024.
___________________________________________________________________
You don't need to buy Internet access to use free Internet email.
Get completely free email from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654JUNO [6545866]
1999\02\18@201143
by
Glenville T. Sawyer

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
displaying multiple digit readouts (was for a twoway radio system,
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 09 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.
1999\02\19@021610
by
Wagner Lipnharski
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.
1999\02\19@101408
by
Dave Evans
"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 12bit 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.evansKILLspam.....dlcc.com
> {Original Message removed}
1999\02\20@022504
by
Glenville T. Sawyer

Glenville T. Sawyer ( the 48 year old )
Outback Communications. South Australia
Theatre, Concert Lighting, Special Effects, Props. & more !
Embedded Control systems for Theatrical Applications
http://www.gsawyer.mtx.net/emailpad.html
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 07 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 mentalstim'
had just finished a straight 36 hours session (not PIC related but
it will be when I finish the design work) :)
Regards, Glenville.
1999\02\20@024811
by
Lee Jones

>>> 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 3bit
wide field in the 12bit 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 12bit 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
1999\02\20@033431
by
Glenville T. Sawyer

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 07 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.
1999\02\20@042138
by
Wagner Lipnharski

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?
just think about it.
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?
First you add everything: 18
Then you divide by 2 (n1): 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}>
> 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 07 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.
1999\02\20@080047
by
Byron A Jeff
>
> >>> 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}>
> > 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 3bit
> wide field in the 12bit word.
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}>
> 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 12bit 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.
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
>
1999\02\20@080300
by
Byron A Jeff
>
> 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 07 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.
>
1999\02\20@105737
by
w. v. ooijen / f. hanneman
> 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.
1999\02\20@113131
by
Dave Evans

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 00009999) into a set of 4,096 different
elements (12bit 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 0000FFFF) into the set
of 12bit 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 14 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 realnumber arithmetic, but
the math is "moreorless 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, nonindependent 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
EraseMEdave.evansspam_OUTTakeThisOuTdlcc.com
> {Original Message removed}
1999\02\20@113556
by
PDRUNEN
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 onetoone 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.evansspam_OUTDLCC.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 12bit 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 >>
1999\02\20@114600
by
Dave Evans
Spoton about the onetoone mapping.
(If it isn't onetoone, it the inverse
map doesn't exist.)
A simple BCDtobinary conversion will always
give a result that fits into a 14bit 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 twistedpair copper conductors, etc...
The guy who said that "you can't put ten pounds
of sugar into a fivepound bag" was me, but my
boss disagrees about twice a month (except in
years divisible by 1000).
Best regards,
Dave Evans
@spam@dave.evansKILLspamdlcc.com
> {Original Message removed}
1999\02\20@115816
by
Dave Evans
If the keyboard has digits 09, 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 00007777.
If the keyboard has digits 07, your method gives
one possible encoding. Me? I would just pack the
four octal digits, as entered, into a 12bit word.
Dave Evans
KILLspamdave.evansKILLspamdlcc.com
> {Original Message removed}
1999\02\20@132700
by
Wagner Lipnharski

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

1999\02\20@143624
by
Ben Stragnell

> 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
1999\02\20@144511
by
dave vanhorn
>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.
1999\02\20@144912
by
Byron A Jeff
>
> 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 onetoone 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
1999\02\20@145538
by
Dave Evans
1999\02\20@145541
by
Gerhard Fiedler
At 11:33 02/20/99 0500, RemoveMEPDRUNENTakeThisOuTAOL.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
1999\02\20@151711
by
Dave Evans
I think that lossless compression capitalizes on redundancy;
probability has nothing to do with it. If all possible
4digit 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 4digit decimal numbers
from one place to another, a variablelength encoding
scheme can give better performance than a fixedlength
encoding. Thanks Samuel F. B. Morse.
Dave Evans, KW7X
dave.evansEraseME.....dlcc.com
> {Original Message removed}
1999\02\20@152123
by
Dave Evans
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
EraseMEdave.evansdlcc.com
> {Original Message removed}
1999\02\20@173200
by
Byron A Jeff
>
> >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
1999\02\21@172029
by
Graeme Smith
Hm....
How about TIME MULTIPLEXING....
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: RemoveMEgrysmithEraseMEEraseMEfreenet.edmonton.ab.ca
YMCA Edmonton
Address has changed with little warning!
(I moved across the hall! :) )
Email will remain constant... at least for now.
1999\02\24@185701
by
John Payson

> 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 specificallyidentifiable specialsomething'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 [2400baud QAM can make sense when viewed on a scope,
though it'd be a bit hard to interpret; at 9600baud 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 8bit A/D sampled at 8KHz and then get
carried digitally to a phone company office near the destination,
where it will be reconverted 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...