2.5 digit bcd to 8 bit encoding?

For D6 and D7 bits read D5 and D6 bits

I can't follow what you are doing. Are you trying to send all 400 possible combinations of 0.00 to 3.99 in just 8 bits?

I have absolutely no idea what you mean by "stick or twist".

Are you just trying to compress your data?

--

Rick

Don't know if it is compressing or encoding but using some of the easily resolvable "illegal" ABCDEF codes of the otherwise unused bits in BCD to encode the units data and then use the pc to extract and manipulate back to 0 to 3.99.

By stick or twist I mean If tenths 8 follows the tenths 9 sent data, stick with the last unit integre transferred If tenths 0 follows the tenths 9, then unit twisted to last transferred unit +1

You are not making any sense 8 bits can encode a maximum of 256 states.

0.00 to 3.99 contains 400 states. You have to accept either losing the least significant bit or using an extra bit for every 8 values sent.

--
Regards, 
Martin Brown

Once you have figured out what you are /actually/ trying to do, and then learned to write proper sentences in English, it is quite possible that someone here can help you. But at the moment it looks like you have taken half a problem, added half a solution, and liquidised the mixture.

The way I see it , there is 100 datapoints , in 2 ranks tenths and hundredths , leaving 156 unused places to hide 4 datapoints for the units. Using the most appropriate place to hide them , which for hardware manipulation would seem to be D5 and D6 , unused in 8 and 9 representations of BCD,1000 and 1001, of which 9 is the easiest to gate from.

I think you need to get your brain rewired. This is total nonsense.

--
Regards, 
Martin Brown

I still have no idea what you are saying.

As has been pointed out you can't represent 400 states in 8 bits. But you can compress the information if you *know* the states will not vary by more than some amount between samples. Instead of sending the value, send the delta from the previous value. As long as you have a way to set a starting point you can then track a somewhat slowly varying signal.

--

Rick

You're thinking of sending the lower 100 values together with the

4 values of the top digit, but you cannot use the combinations already in use for the low digits, if you're attempting to squeeze everything in one 8 bit byte.

There are 256 possible values in 8 bits and 400 values you want to put in - 5 elephants do not fit a VW Beetle.

--

-TV

Your title says "2.5 digit BCD to 8-bit encoding".

You can only encode 256 different values in 8 bits.

There are 400 values in 0.00 to 3.99.

Do you see a conflict there?

I _think_ you're talking about encoding 2.5 digit BCD into at least two, or maybe three bytes -- but you don't SAY this.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

Even if they're in clown makeup?

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

No, there are 400 data points. Sorry, reality sucks sometimes.

You mean, leaving one bit to "hide" four bits worth of information.

If you truly want to hide them, since you certainly can't actually transmit them, why don't you just transmit the bottom digits and let the user guess the rest? Then they'll be "hidden".

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

Ok, now I understand. The problem is that if your lower digits aren't 8 or 9 you don't have those two bits available.

You are trying to fit 400 combinations into 8 bits which only has 256 combinations.

--

Rick

(1) consider your BCD data as three 4-bit fields; use a simple state machine to send those three 4-bit fields encoded as three 8-bit characters (0x30 as the top 4 bits, 4 bits of data as the lower four bits, so sending ascii '0' - '9').

(2) similar to (1), do a state machine sending 4 fields, with the first one being a synch character.

(3) combining (1) and (2), state machine sends three 8-bit characters with one of those characters tagged in the upper 4 bits for synch.

(4) use a pre-programmed EPROM as a lookup table, feeding the BCD data into the address pins. Building the table makes you decide what you're going to do with illegal states, and also lets you cook your data at the sensor. Clocking to account for read times left as an exercise for the reader, as is insuring address bit stability for that read.

(5) do the whole thing with a single chip -- a microprocessor. Back in the olden days when computers used little donuts made of rust for memory (magnetic cores), some of those dinosaurs had instructions for converting bcd to binary -- in the 360 (and others such as the SDS Sigma 5/6/7/9), it was the CVA - convert via addition -- instruction. This instruction uses a table containing the binary value for each bit in the BCD field; if a bit in the BCD field is set, the corresponding table entry is added to the sum. Have the micro do the bcd/binary conversion and serial output generation.

First, trivially, you couild send serially the ASCII characters "3", "." "9", "9". That has the obvious benefit of giving a clear indication of digit placement (with the "." always in second position). Second, you could send all but the last significant bit as a single eight-bit entity (0.10 becomes 0x05, 2.00 becomes 0x A4). That loses the LSB, but you might be able to get it back by averaging values at the receive end. Conversion can be more complex (add a dither to successive transmissions) and you can ensure the full complement of significant figures in the average-of-several-values; this is a slowly changing value, maybe that's good enough?

The conversion to nine bits can be done by calculation, or you can just build a four hundred-entry table of the eight MSBs, and the least significant bit is just the low bit (the even/odd bit) of the least significant digit.

Of course 2-1/2 digits is only 0 to 199, which will fit fine. 2-3/4 digits (0-399) not so much.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

If you're truly trying to send 400 different codes, using a single

8-bit byte (which has only 255 possible values) for each reading, and you need to be able to handle each and every set of readings which could ever occur in sequence... I believe it cannot be done. The "pigeonhole principle" forbids it.

In practice, if the readings aren't changing too quickly or too arbitrarily, you may be able to use compression of some sort to get the data rate down to an average of one (or less) 8-bit byte transferred, per reading taken. This will be an average... there will be times when you need to transmit two bytes to handle a reading... and there will be some amount of additional latency added by the compression scheme.

The gotcha is that no matter what lossless-compression scheme you choose, there will *always* be *some* patterns of inputs which don't compress, or which expand slightly. You're trying to pack about 8.5 bits worth of information into each 8-bit byte, and that cannot always be done.

The Z-80 has such an instruction. I think the 68HC11 had one too, but I'm not sure.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com