Reply by josephkk November 22, 20142014-11-22
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? ?-/
Reply by josephkk November 22, 20142014-11-22
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. ?-/
Reply by Martin Brown November 20, 20142014-11-20
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
Reply by o pere o November 20, 20142014-11-20
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?
Reply by N_Cook November 20, 20142014-11-20
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
Reply by N_Cook November 20, 20142014-11-20
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.
Reply by rickman November 20, 20142014-11-20
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
Reply by N_Cook November 20, 20142014-11-20
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
Reply by Martin Brown November 20, 20142014-11-20
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
Reply by Lasse Langwadt Christensen November 20, 20142014-11-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