Forums

2.5 digit bcd to 8 bit encoding?

Started by N_Cook November 18, 2014
On Wed, 19 Nov 2014 09:15:18 +0000, 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.
Your life will be complicated by the fact that you need to do something that's easy to implement in logic. So your parent data ranges from 0x000 to 0x18f. If you use a the MSB as a flag, then you can let x = 0x00 to 0x7f correspond to y = range + x, where range is retained from sample to sample. Then you can let x = 0x80 to 0xff to correspond to y = (x - 0x80) * 8. All in all, if you don't use a PAL you'll need about half a dozen chips on each side of the link instead of one microprocessor, the "kit" that you'll be avoiding buying costs $29.95, and the code that you don't want to learn how to write will run to about 20 lines of C (maybe 100 of assembly). But it's your decision. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Wed, 19 Nov 2014 11:44:28 +0000, N_Cook wrote:

> 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
I don't have enough time left in my life to NOT use microprocessors for this kind of stuff! You can get a 20-pin ARM Cortex part for less than $2 in onsies (less than $1 in quantity). An ST-Link programmer costs $29.95 from DigiKey. And if ALL you're doing is looking at segments and spitting out RS-232, the code should be fairly straightforward. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Tue, 18 Nov 2014 10:30:55 +0000, 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=
=20
>behaved , just going up or down slowly. >As limited to hardware conversion/encoding at the sensor end (pc at the=20 >other so no decoding limitation there), thinking >Send as packed BCD of the tenths and hundredths and then hardware encode=
=20
>onto MSB only when it is 1001 "9", the units 0to 3 reading as 2bit=20 >binary on the D6 and D7 bits. Then on the pc "stick or twist" the units=20 >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=20 >9.99 using D1 and D2 on the LSB but would not be reliable for general=20 >data or jittering around the .9. >Any other harware conversion/encoding idea I might consider?
Unless you are going to send multiple characters there is a big problem. You have 400 input states possible and only 256 transmission states possible. Not possible without some other kind of limitations. ?-/ =20
On Tue, 18 Nov 2014 16:16:12 +0000, N_Cook <diverse@tcp.co.uk> 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=20 >hundredths , leaving 156 unused places to hide 4 datapoints for the=20 >units. Using the most appropriate place to hide them , which for=20 >hardware manipulation would seem to be D5 and D6 , unused in 8 and 9=20 >representations of BCD,1000 and 1001, of which 9 is the easiest to gate=20 >from.
How are you going to deal with 2.77? ?-/ =20
Den torsdag den 20. november 2014 02.10.54 UTC+1 skrev Tim Wescott:
> On Wed, 19 Nov 2014 11:44:28 +0000, N_Cook wrote: > > > 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 > > I don't have enough time left in my life to NOT use microprocessors for > this kind of stuff! > > You can get a 20-pin ARM Cortex part for less than $2 in onsies (less than > $1 in quantity). An ST-Link programmer costs $29.95 from DigiKey. And if > ALL you're doing is looking at segments and spitting out RS-232, the code > should be fairly straightforward. >
and $29.95 is the expensive one, you can just get one of the eval kits like: http://www.digikey.com/product-detail/en/STM32L100C-DISCO/497-13930-ND/4357642 $7.88 and it includes an ST-link -Lasse
On 20/11/2014 05:53, josephkk wrote:
> On Tue, 18 Nov 2014 10:30:55 +0000, 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? > > > Unless you are going to send multiple characters there is a big problem. > You have 400 input states possible and only 256 transmission states > possible. Not possible without some other kind of limitations. > > ?-/
One option is to map the range in such a way as to preserve fractional dynamic range or simpler to compress the higher range readings. eg. Simplest case is to keep 0..a and then step in twos. Solve a+1 + (400-a)/2 = 256 a/2 + 201 = 256 hence a = 110 (ignoring fencepost errors or algebra slips) -- Regards, Martin Brown
On 20/11/2014 06:05, josephkk wrote:
> On Tue, 18 Nov 2014 16:16:12 +0000, N_Cook <diverse@tcp.co.uk> 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. > > How are you going to deal with 2.77? > > ?-/ > >
well behaved input packed double binary of 01110111 with unit 2 or 3 logged from the previous pass in the x.9x data and wait for the next x.9x transmitted data to update the units info
On 11/20/2014 1:05 AM, josephkk wrote:
> On Tue, 18 Nov 2014 16:16:12 +0000, N_Cook <diverse@tcp.co.uk> 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. > > How are you going to deal with 2.77?
He is taking advantage of the fact that the value changes very slowly. If decreasing it will hit x.9y before it reaches x.8y. The 9 in the tens place will contain the new value for x and will be latched. On increasing when x.0y is reached the previous value stored will be incremented. I think this will take a bit more logic than he realizes. Detecting the crossing from x.9 to x+1.0 will require a FF and logic. Then he will need a loadable counter to remember the units and increment. I understand the idea, but I think he would be just as well off simply detecting the .9 to .0 and .0 to .9 transitions and counting up or down as needed. The thing has to start with a value near zero or it won't work at the start anyway. His approach does at least have the advantage of setting the correct value on the tenths reaching .9 in case they get corrupted. The up and down transitions can be detected when the D7 bit transitions and the D6 bit matches. That makes it two FFs. An up transition is stored D7 = 1, stored D4 = 1, the present D7 = 0 and present D4 = 0. The down transition is the stored D7 = 0, stored D4 = 0, present D7 = 1 and present D4 = 1. I assume he has a strobe to say when the data is valid which is used to clock everything. Not sure how he plans to interface with the UART, etc. -- Rick
On 20/11/2014 09:01, rickman wrote:
> On 11/20/2014 1:05 AM, josephkk wrote: >> On Tue, 18 Nov 2014 16:16:12 +0000, N_Cook <diverse@tcp.co.uk> 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. >> >> How are you going to deal with 2.77? > > He is taking advantage of the fact that the value changes very slowly. > If decreasing it will hit x.9y before it reaches x.8y. The 9 in the > tens place will contain the new value for x and will be latched. On > increasing when x.0y is reached the previous value stored will be > incremented. > > I think this will take a bit more logic than he realizes. Detecting the > crossing from x.9 to x+1.0 will require a FF and logic. Then he will > need a loadable counter to remember the units and increment. I > understand the idea, but I think he would be just as well off simply > detecting the .9 to .0 and .0 to .9 transitions and counting up or down > as needed. The thing has to start with a value near zero or it won't > work at the start anyway. His approach does at least have the advantage > of setting the correct value on the tenths reaching .9 in case they get > corrupted. The up and down transitions can be detected when the D7 bit > transitions and the D6 bit matches. That makes it two FFs. > > An up transition is stored D7 = 1, stored D4 = 1, the present D7 = 0 and > present D4 = 0. The down transition is the stored D7 = 0, stored D4 = > 0, present D7 = 1 and present D4 = 1. I assume he has a strobe to say > when the data is valid which is used to clock everything. Not sure how > he plans to interface with the UART, etc. >
As it stands I have 3 banks of latched BCD, 2 bits for units and 4 bits each for the tenths and hundredths. Hold lines D5 and D6 low until the 2 analogue switch gates pass the units data into the "9" encoding when both D4 and D7 are high.
On 20/11/2014 09:24, N_Cook wrote:
> Hold lines D5 and D6 low
i meant droppered instead of held , so can be H or L for 0 to 7 use but data passed by the analogue switch takes priority in the "9" tenths situation