Forums

2.5 digit bcd to 8 bit encoding?

Started by N_Cook November 18, 2014
On 2014-11-18, N_Cook <diverse@tcp.co.uk> wrote:

> Any other harware conversion/encoding idea I might consider?
Fx yz first byte ix 1111xxxx where xxxx encodes the first digit in BCD second byte is yyyyzzzz where yyyy is the second digit and zzzz is the third, If the reading is negative send 1110xxxx for the first byte instead. its reasonably compact and includes synchronisation information to recover from communicatons errors. Alternatively maybe go full ascii as has been suggested. -- umop apisdn
On 2014-11-18, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Tue, 18 Nov 2014 10:32:49 -0800, artie wrote: >
>> 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.
DAA, not really the same thing - it keeps BCD consistent under addition, it doesn't convert. -- umop apisdn
On 11/19/2014 3:30 AM, N_Cook wrote:
>> >> Actually I think I cracked the code. He is thinking that he can utilize >> some of the "don't care" bits that occur in the two digits, '8' and '9'. >> Not fully realizing that these can indeed be used... if these digits >> are transmitted. But when the two lsds are characters other than an 8 >> or 9 there are no don't care bits so you lose that capacity. >> > > yes, perhaps I should have termed them don't-care rather than illegal. > In hardware terms , for the send end, AND D4,D7 (active H for tenths > digit 9) and output goes to feed the control of 2 analogue gates that > pass the 2 bits of the 0,1,2,or3 units data onto lines D5,D6. Convert to > serial, and pass to pc where look-up or whatever will decript back to 9 > and the units figure
You are ignoring the issue of not always sending an 8 or 9 digit. How would you encode this value, 1.35? How about 0.35, 2.35 and 3.35? -- Rick
On 19/11/2014 08:47, rickman wrote:
> On 11/19/2014 3:30 AM, N_Cook wrote: >>> >>> Actually I think I cracked the code. He is thinking that he can utilize >>> some of the "don't care" bits that occur in the two digits, '8' and '9'. >>> Not fully realizing that these can indeed be used... if these digits >>> are transmitted. But when the two lsds are characters other than an 8 >>> or 9 there are no don't care bits so you lose that capacity. >>> >> >> yes, perhaps I should have termed them don't-care rather than illegal. >> In hardware terms , for the send end, AND D4,D7 (active H for tenths >> digit 9) and output goes to feed the control of 2 analogue gates that >> pass the 2 bits of the 0,1,2,or3 units data onto lines D5,D6. Convert to >> serial, and pass to pc where look-up or whatever will decript back to 9 >> and the units figure > > You are ignoring the issue of not always sending an 8 or 9 digit. How > would you encode this value, 1.35? How about 0.35, 2.35 and 3.35? >
It is well behaved data. I'd only be passing the units,u value, data superimposed on (.)9x when it is sent , so the receiver has the previous units value u' for logging and only has to monitor whether the next ,non-9 , data is 8x or 0x to know whether to log u' as u or u +1 eg for amended BCD of 1001xxxx and units value of 2 , transmit 1101xxxx then if the next non-9 data is 1000xxxx then units value is still the 2 if the next data is 0000xxxx then units value is 3 The transmitted data is full 8 bit data, not packed double BCD subset.
On 11/19/2014 4:15 AM, N_Cook wrote:
> On 19/11/2014 08:47, rickman wrote: >> On 11/19/2014 3:30 AM, N_Cook wrote: >>>> >>>> Actually I think I cracked the code. He is thinking that he can >>>> utilize >>>> some of the "don't care" bits that occur in the two digits, '8' and >>>> '9'. >>>> Not fully realizing that these can indeed be used... if these digits >>>> are transmitted. But when the two lsds are characters other than an 8 >>>> or 9 there are no don't care bits so you lose that capacity. >>>> >>> >>> yes, perhaps I should have termed them don't-care rather than illegal. >>> In hardware terms , for the send end, AND D4,D7 (active H for tenths >>> digit 9) and output goes to feed the control of 2 analogue gates that >>> pass the 2 bits of the 0,1,2,or3 units data onto lines D5,D6. Convert to >>> serial, and pass to pc where look-up or whatever will decript back to 9 >>> and the units figure >> >> You are ignoring the issue of not always sending an 8 or 9 digit. How >> would you encode this value, 1.35? How about 0.35, 2.35 and 3.35? >> > > It is well behaved data. I'd only be passing the units,u value, data > superimposed on (.)9x when it is sent , so the receiver has the previous > units value u' for logging and only has to monitor whether the next > ,non-9 , data is 8x or 0x to know whether to log u' as u or u +1 > eg for amended BCD of 1001xxxx and units value of 2 , > transmit 1101xxxx > then if the next non-9 data is 1000xxxx then units value is still the 2 > if the next data is 0000xxxx then units value is 3 > The transmitted data is full 8 bit data, not packed double BCD subset.
If the data changes that slowly there are a bazillion ways to compress and send the data. Are you sure the data will always have an x.9y to send in between x.8y and x+1.0y? BTW, your earlier post seemed to be describing hardware to do the encode and decode. Is that really necessary? Can't software do this? -- Rick
On 19/11/2014 09:49, rickman wrote:
> On 11/19/2014 4:15 AM, N_Cook wrote: >> On 19/11/2014 08:47, rickman wrote: >>> On 11/19/2014 3:30 AM, N_Cook wrote: >>>>> >>>>> Actually I think I cracked the code. He is thinking that he can >>>>> utilize >>>>> some of the "don't care" bits that occur in the two digits, '8' and >>>>> '9'. >>>>> Not fully realizing that these can indeed be used... if these digits >>>>> are transmitted. But when the two lsds are characters other than an 8 >>>>> or 9 there are no don't care bits so you lose that capacity. >>>>> >>>> >>>> yes, perhaps I should have termed them don't-care rather than illegal. >>>> In hardware terms , for the send end, AND D4,D7 (active H for tenths >>>> digit 9) and output goes to feed the control of 2 analogue gates that >>>> pass the 2 bits of the 0,1,2,or3 units data onto lines D5,D6. >>>> Convert to >>>> serial, and pass to pc where look-up or whatever will decript back to 9 >>>> and the units figure >>> >>> You are ignoring the issue of not always sending an 8 or 9 digit. How >>> would you encode this value, 1.35? How about 0.35, 2.35 and 3.35? >>> >> >> It is well behaved data. I'd only be passing the units,u value, data >> superimposed on (.)9x when it is sent , so the receiver has the previous >> units value u' for logging and only has to monitor whether the next >> ,non-9 , data is 8x or 0x to know whether to log u' as u or u +1 >> eg for amended BCD of 1001xxxx and units value of 2 , >> transmit 1101xxxx >> then if the next non-9 data is 1000xxxx then units value is still the 2 >> if the next data is 0000xxxx then units value is 3 >> The transmitted data is full 8 bit data, not packed double BCD subset. > > If the data changes that slowly there are a bazillion ways to compress > and send the data. Are you sure the data will always have an x.9y to > send in between x.8y and x+1.0y? > > BTW, your earlier post seemed to be describing hardware to do the encode > and decode. Is that really necessary? Can't software do this? >
The only way the decoded data could jump 1 unit between samplings , is if there is an error in the sensing,coding or decoding, not the original input, so it can be ignored in software if a random glitch and flag as -9999 ,or whatever, or the whole system is broken anyway. Decoding would by VB on a pc, so no limitations there. I've no means of programming pics or controllers ,without kitting-up for all that plus learning to use it all, too long in the tooth for that now, and this is just a one off. Bits of paper and soldering iron only for me
On 11/19/2014 03:18 AM, Martin Brown wrote:
> On 18/11/2014 19:16, Phil Hobbs wrote: >> 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. > > It is curious marketeering calling it 2-1/2 or 2-3/4 digits when they > are in reality a shade under 2-1/3 and 2-2/3 respectively. > Lg10(2) ~= 0.301 < 1/3 << 1/2
It's an old, old idiom, used since the first LED multimeters. There may even have been +-1 Nixies, I don't know. There's a strong tendency for useful numbers to be logarithmically distributed, so it makes a big difference.
> > If the OP sends his 0 to 199 data then he can reserve the other 56 codes > for sending up to 5 independent bits of status information back as well > at the expense of sending a byte with no actual reading in it. > > Limiting readings to 0 to 191 range would allow 6 bits of status codes. >
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
On 19/11/2014 15:57, Phil Hobbs wrote:
> On 11/19/2014 03:18 AM, Martin Brown wrote: >> On 18/11/2014 19:16, Phil Hobbs wrote: >>> On 11/18/2014 01:25 PM, Tim Wescott wrote:
[snip]
>>>> 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. >> >> It is curious marketeering calling it 2-1/2 or 2-3/4 digits when they >> are in reality a shade under 2-1/3 and 2-2/3 respectively. >> Lg10(2) ~= 0.301 < 1/3 << 1/2 > > It's an old, old idiom, used since the first LED multimeters. There may > even have been +-1 Nixies, I don't know. There's a strong tendency for > useful numbers to be logarithmically distributed, so it makes a big > difference.
Yes! I am sure you know this but for the benefit of others here it goes by the name of Benford's law and can be used in forensic analysis. I don't recall ever seeing a +/-1 Nixie but I can't rule it out! -- Regards, Martin Brown
On 11/19/2014 11:11 AM, Martin Brown wrote:
> On 19/11/2014 15:57, Phil Hobbs wrote: >> On 11/19/2014 03:18 AM, Martin Brown wrote: >>> On 18/11/2014 19:16, Phil Hobbs wrote: >>>> On 11/18/2014 01:25 PM, Tim Wescott wrote: > [snip] >>>>> 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. >>> >>> It is curious marketeering calling it 2-1/2 or 2-3/4 digits when they >>> are in reality a shade under 2-1/3 and 2-2/3 respectively. >>> Lg10(2) ~= 0.301 < 1/3 << 1/2 >> >> It's an old, old idiom, used since the first LED multimeters. There may >> even have been +-1 Nixies, I don't know. There's a strong tendency for >> useful numbers to be logarithmically distributed, so it makes a big >> difference. > > Yes! I am sure you know this but for the benefit of others here it goes > by the name of Benford's law and can be used in forensic analysis. > > I don't recall ever seeing a +/-1 Nixie but I can't rule it out! >
ISTR a Nixie voltmeter that used an NE-2 positioned with the electrodes edgewise to make a '1'. 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
On Wed, 19 Nov 2014 16:11:03 +0000, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

>On 19/11/2014 15:57, Phil Hobbs wrote: >> On 11/19/2014 03:18 AM, Martin Brown wrote: >>> On 18/11/2014 19:16, Phil Hobbs wrote: >>>> On 11/18/2014 01:25 PM, Tim Wescott wrote: >[snip] >>>>> 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. >>> >>> It is curious marketeering calling it 2-1/2 or 2-3/4 digits when they >>> are in reality a shade under 2-1/3 and 2-2/3 respectively. >>> Lg10(2) ~= 0.301 < 1/3 << 1/2 >> >> It's an old, old idiom, used since the first LED multimeters. There may >> even have been +-1 Nixies, I don't know. There's a strong tendency for >> useful numbers to be logarithmically distributed, so it makes a big >> difference. > >Yes! I am sure you know this but for the benefit of others here it goes >by the name of Benford's law and can be used in forensic analysis. > >I don't recall ever seeing a +/-1 Nixie but I can't rule it out!
I don't think it was that big a deal to get custom displays even http://www.stevenjohnson.com/nls/pics/x-2.jpg http://pixgood.com/nixie-tubes-steampunk.html (2nd down on left)