Forums

2.5 digit bcd to 8 bit encoding?

Started by N_Cook November 18, 2014
On 18.11.14 18:16, N_Cook wrote:
> On 18/11/2014 12:34, David Brown wrote: >> On 18/11/14 11:30, N_Cook wrote: >>> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is well >>> behaved , just going up or down slowly. >>> As limited to hardware conversion/encoding at the sensor end (pc at the >>> other so no decoding limitation there), thinking >>> Send as packed BCD of the tenths and hundredths and then hardware encode >>> onto MSB only when it is 1001 "9", the units 0to 3 reading as 2bit >>> binary on the D6 and D7 bits. Then on the pc "stick or twist" the units >>> logged according to whether the next tenth sent reading is 8 or 0. >>> I suppose in the general case 9.99 could be encoded like this for 0 to >>> 9.99 using D1 and D2 on the LSB but would not be reliable for general >>> data or jittering around the .9. >>> Any other harware conversion/encoding idea I might consider? >> >> 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.
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
On Tue, 18 Nov 2014 11:33:53 +0000, N_Cook wrote:

> On 18/11/2014 10:51, rickman wrote: >> On 11/18/2014 5:30 AM, N_Cook wrote: >>> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is >>> well behaved , just going up or down slowly. >>> As limited to hardware conversion/encoding at the sensor end (pc at >>> the other so no decoding limitation there), thinking Send as packed >>> BCD of the tenths and hundredths and then hardware encode onto MSB >>> only when it is 1001 "9", the units 0to 3 reading as 2bit binary on >>> the D6 and D7 bits. Then on the pc "stick or twist" the units logged >>> according to whether the next tenth sent reading is 8 or 0. >>> I suppose in the general case 9.99 could be encoded like this for 0 to >>> 9.99 using D1 and D2 on the LSB but would not be reliable for general >>> data or jittering around the .9. >>> Any other harware conversion/encoding idea I might consider? >> >> 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? >> >> > 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.
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
On Tue, 18 Nov 2014 20:11:18 +0200, Tauno Voipio wrote:

> 5 elephants do not fit a VW Beetle.
Even if they're in clown makeup? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Tue, 18 Nov 2014 16:16:12 +0000, N_Cook wrote:

> On 18/11/2014 12:34, David Brown wrote: >> On 18/11/14 11:30, N_Cook wrote: >>> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is >>> well behaved , just going up or down slowly. >>> As limited to hardware conversion/encoding at the sensor end (pc at >>> the other so no decoding limitation there), thinking Send as packed >>> BCD of the tenths and hundredths and then hardware encode onto MSB >>> only when it is 1001 "9", the units 0to 3 reading as 2bit binary on >>> the D6 and D7 bits. Then on the pc "stick or twist" the units logged >>> according to whether the next tenth sent reading is 8 or 0. >>> I suppose in the general case 9.99 could be encoded like this for 0 to >>> 9.99 using D1 and D2 on the LSB but would not be reliable for general >>> data or jittering around the .9. >>> Any other harware conversion/encoding idea I might consider? >> >> 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 ,
No, there are 400 data points. Sorry, reality sucks sometimes.
> leaving 156 unused places to hide 4 datapoints for the > units.
You mean, leaving one bit to "hide" four bits worth of information.
> 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.
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
In article <m4f74h$4gg$1@dont-email.me>, N_Cook <diverse@tcp.co.uk>
wrote:

> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is well > behaved , just going up or down slowly. > As limited to hardware conversion/encoding at the sensor end (pc at the > other so no decoding limitation there), thinking > Send as packed BCD of the tenths and hundredths and then hardware encode > onto MSB only when it is 1001 "9", the units 0to 3 reading as 2bit > binary on the D6 and D7 bits. Then on the pc "stick or twist" the units > logged according to whether the next tenth sent reading is 8 or 0. > I suppose in the general case 9.99 could be encoded like this for 0 to > 9.99 using D1 and D2 on the LSB but would not be reliable for general > data or jittering around the .9. > Any other harware conversion/encoding idea I might consider?
(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.
On 11/18/2014 11:16 AM, N_Cook wrote:
> On 18/11/2014 12:34, David Brown wrote: >> On 18/11/14 11:30, N_Cook wrote: >>> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is well >>> behaved , just going up or down slowly. >>> As limited to hardware conversion/encoding at the sensor end (pc at the >>> other so no decoding limitation there), thinking >>> Send as packed BCD of the tenths and hundredths and then hardware encode >>> onto MSB only when it is 1001 "9", the units 0to 3 reading as 2bit >>> binary on the D6 and D7 bits. Then on the pc "stick or twist" the units >>> logged according to whether the next tenth sent reading is 8 or 0. >>> I suppose in the general case 9.99 could be encoded like this for 0 to >>> 9.99 using D1 and D2 on the LSB but would not be reliable for general >>> data or jittering around the .9. >>> Any other harware conversion/encoding idea I might consider? >> >> 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.
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
On Tuesday, November 18, 2014 2:31:00 AM UTC-8, N_Cook wrote:
> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232.
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.
On 11/18/2014 01:25 PM, Tim Wescott wrote:
> On Tue, 18 Nov 2014 11:33:53 +0000, N_Cook wrote: > >> On 18/11/2014 10:51, rickman wrote: >>> On 11/18/2014 5:30 AM, N_Cook wrote: >>>> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is >>>> well behaved , just going up or down slowly. >>>> As limited to hardware conversion/encoding at the sensor end (pc at >>>> the other so no decoding limitation there), thinking Send as packed >>>> BCD of the tenths and hundredths and then hardware encode onto MSB >>>> only when it is 1001 "9", the units 0to 3 reading as 2bit binary on >>>> the D6 and D7 bits. Then on the pc "stick or twist" the units logged >>>> according to whether the next tenth sent reading is 8 or 0. >>>> I suppose in the general case 9.99 could be encoded like this for 0 to >>>> 9.99 using D1 and D2 on the LSB but would not be reliable for general >>>> data or jittering around the .9. >>>> Any other harware conversion/encoding idea I might consider? >>> >>> 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? >>> >>> >> 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. > > 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. >
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
In article <m4faqm$i3e$1@dont-email.me>, N_Cook  <diverse@tcp.co.uk> wrote:

>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.
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.
On Tue, 18 Nov 2014 10:32:49 -0800, artie wrote:

> In article <m4f74h$4gg$1@dont-email.me>, N_Cook <diverse@tcp.co.uk> > wrote: > >> So 0.00 to 3.99 to 8bit and then via simple 8bit RS232. The data is >> well behaved , just going up or down slowly. >> As limited to hardware conversion/encoding at the sensor end (pc at the >> other so no decoding limitation there), thinking Send as packed BCD of >> the tenths and hundredths and then hardware encode onto MSB only when >> it is 1001 "9", the units 0to 3 reading as 2bit binary on the D6 and D7 >> bits. Then on the pc "stick or twist" the units logged according to >> whether the next tenth sent reading is 8 or 0. >> I suppose in the general case 9.99 could be encoded like this for 0 to >> 9.99 using D1 and D2 on the LSB but would not be reliable for general >> data or jittering around the .9. >> Any other harware conversion/encoding idea I might consider? > > (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.
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