Forums

2.5 digit bcd to 8 bit encoding?

Started by N_Cook November 18, 2014
On 11/18/2014 11: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.
If the data is moving slowly you may consider sending just the difference with the previous value. In this way 8 bits are more than enough (assuming this is what you wanted). Of course this has problems if you don't know an initial value or if you lose a packet... Ad-hoc tricks may help for your particular problem, which you haven't described accurately enough. Pere
> 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?
On 19/11/2014 17:44, Spehro Pefhany wrote:
> On Wed, 19 Nov 2014 16:11:03 +0000, Martin Brown > <|||newspam|||@nezumi.demon.co.uk> wrote: > >> >> 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)
I remember the face on ones. They must have been fairly easily (cheaply) available surplus as we made a digital clock using them and built from parts salvaged from old ICL1900 boards. The lit digit would jump forwards and backwards when it counted up in sequence. I think they were exactly round. I wonder what happened to that clock? -- Regards, Martin Brown
On Thu, 20 Nov 2014 08:59:51 +0000, N_Cook <diverse@tcp.co.uk> wrote:

>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
And if you are not getting them? What then? ?-/
On Thu, 20 Nov 2014 09:24:44 +0000, N_Cook <diverse@tcp.co.uk> wrote:

>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 =3D 1, stored D4 =3D 1, the present D7 =3D=
0 and
>> present D4 =3D 0. The down transition is the stored D7 =3D 0, stored =
D4 =3D
>> 0, present D7 =3D 1 and present D4 =3D 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=20 >each for the tenths and hundredths. >Hold lines D5 and D6 low until the 2 analogue switch gates pass the=20 >units data into the "9" encoding when both D4 and D7 are high.
That assumes that you regularly get 9s and not 7s or 5s. ?-/