Forums

2.5 digit bcd to 8 bit encoding?

Started by N_Cook November 18, 2014
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?
For D6 and D7 bits
read
D5 and D6 bits

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? -- Rick
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.
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? >
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
On 18/11/2014 11:33, 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.
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
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.
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.
On 18/11/2014 16: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.
I think you need to get your brain rewired. This is total nonsense. -- Regards, Martin Brown
On 11/18/2014 6:38 AM, 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? >> > > 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
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