Post by thread:encode 4 keypad digits into 12 Bits?

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}>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) 253-0315 ICQ #: 3329174

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 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. ___________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. 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 displaying multiple digit readouts (was for a two-way 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 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.

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 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? 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 (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}> > 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.

> > >>> 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 3-bit > wide field in the 12-bit 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 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. 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. >

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 EraseMEdave.evansspam_OUTTakeThisOuTdlcc.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.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 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 >>

Spot-on about the one-to-one mapping. (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 @spam@dave.evansKILLspamdlcc.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

> > 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 RemoveMEdave.evansTakeThisOuTdlcc.com {Quote hidden}> -----Original Message----- > From: dave vanhorn [spamBeGonedvanhornspamBeGoneCEDAR.NET] > Sent: Saturday, February 20, 1999 11:43 AM > To: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU > Subject: Re: Encode 4 keypad digits into 12 Bits? > > > >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. 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.