Need display design help

[Dave]

Hi all,

I haven't designed a circuit in the past 15 years and need some help.

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
There is a kit out there that only brings it out to binary and that's
located at http://www.rst-engr.com/rst/catalog/altitude_encoder_and_elt.html

I'd like to buy the kit and add additional circuitry to allow for the
real time digital display of altitude.

The altitude needs to display in thousands of feet with increments of
100 feet. Each bit change is in 100 foot increments.
The range would be -2000 to 40,000 feet.
10100 feet would be displayed as 10.1 so I would guess a four segment
display would be in order.

I suspect that I would need to burn some type of a prom to take the gray
code output and then feed it into the display.

Is there something out there that will do this in a single IC?

What would I need to burn the prom?

Thanks

Dave
[email protected]

 

[Roger Hamlett]

Hi all,

I haven't designed a circuit in the past 15 years and need some help.

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
There is a kit out there that only brings it out to binary and that's
located at
http://www.rst-engr.com/rst/catalog/altitude_encoder_and_elt.html

I'd like to buy the kit and add additional circuitry to allow for the
real time digital display of altitude.

The altitude needs to display in thousands of feet with increments of
100 feet. Each bit change is in 100 foot increments.
The range would be -2000 to 40,000 feet.
10100 feet would be displayed as 10.1 so I would guess a four segment
display would be in order.

I suspect that I would need to burn some type of a prom to take the gray
code output and then feed it into the display.

Is there something out there that will do this in a single IC?

What would I need to burn the prom?

Thanks

Easiest solution, is a micro.
Single chip versions, have their own internal oscillator, which while not
accurate enough for anything requiring really good timing, will be fine
for a job like this. If you want to use 'segmented' displays, these can
also be driven from the micor, but probably even easier, to use an LCD,
with one of the emulations of the Hitachi interface. These are common,
cheap, and code to drive them is standard.
The code used on the aviation altitude encoders, is a 'modified' grey
code, which has zero omitted, and is offset (to allow the -ve altitude
outputs). Code to decode this, has been posted on a number of forums (I
posted a version using a PIC, a little while ago, in a software forum).
There are circuits to program PICs and similar micros, directly from the
PC parallel port, requiring only a handful of components. The hardest
part, will be writing the code, since this is not 'your field'. However
any student, ought to be able to do this in a couple of hours.

Best Wishes

 

[D from BC]

Hi all,

I haven't designed a circuit in the past 15 years and need some help.

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
There is a kit out there that only brings it out to binary and that's
located at http://www.rst-engr.com/rst/catalog/altitude_encoder_and_elt.html

I'd like to buy the kit and add additional circuitry to allow for the
real time digital display of altitude.

The altitude needs to display in thousands of feet with increments of
100 feet. Each bit change is in 100 foot increments.
The range would be -2000 to 40,000 feet.
10100 feet would be displayed as 10.1 so I would guess a four segment
display would be in order.

I suspect that I would need to burn some type of a prom to take the gray
code output and then feed it into the display.

Is there something out there that will do this in a single IC?

What would I need to burn the prom?

Thanks

Dave
[email protected]

This looks like a nice uC project..

For uC's you need to know a high level language... I think C is most
popular for uC's. You'll need the C compiler program too.
Basic and Pascal compilers are in the wild too.
Use assembly language if you like pain.

The you need some cheapo programmer to plug to your PC + associated
software. Ebay might come to the rescue.

Display code can probably be found in a uC library or app examples on
the manu. site.

Once all set up.. You can make all sorts of complicated digital
projects! You could work from home and do code for companies around
the world just by setting up shop in the internet.

See
http://en.wikipedia.org/wiki/PIC_microcontroller
as an example.
There are other competing uC's... so check them out to and chose.


D from BC

 

[Jonathan Kirwan]

I haven't designed a circuit in the past 15 years and need some help.

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
There is a kit out there that only brings it out to binary and that's
located at http://www.rst-engr.com/rst/catalog/altitude_encoder_and_elt.html

I'd like to buy the kit and add additional circuitry to allow for the
real time digital display of altitude.

The altitude needs to display in thousands of feet with increments of
100 feet. Each bit change is in 100 foot increments.
The range would be -2000 to 40,000 feet.
10100 feet would be displayed as 10.1 so I would guess a four segment
display would be in order.

I suspect that I would need to burn some type of a prom to take the gray
code output and then feed it into the display.

Is there something out there that will do this in a single IC?

What would I need to burn the prom?

Hi, Dave. It's not clear to me what you are talking about, just yet.
You have an existing system on the plane which provides a Gray encoded
parallel form of signalling. In other words, you've got a bunch of
wires coming out. How many of these wires, exactly? 16? Also, what
is the analog signalling like? Is this 5V CMOS or 3.3V CMOS or 5V TTL
or something else entirely? (By the way, is it the "blind encoder"
shown on that site you mentioned?)

I gather you are looking for something that doesn't sit on the plane,
but instead is used in the shop to calibrate/test altitude encoders?

I guess I'm also flipping between thinking this is a one-off for your
own plane versus something that an A&P might use in the shop for a
wide variety of units they might see over time. Which is it?

Jon

 

[MooseFET]

This looks like a nice uC project..

For uC's you need to know a high level language.

No, you can do it in assembly on an 8051. Whatever you do don't try
to do something like this in C. That is certainly the hard way. If
you don't know assembly go get one of those micros that speaks basic.
It is much easier to develop code in a interpretive environments. You
don't need the speed that assembly will give you.

 

[CWatters]

What would I need to burn the prom?

Many single chip micros have Flash memory or similar. Some have a serial
interface to get the code into the device and you just need a simple cable
you can make yourself to program them from a PC.

 

[Rich Grise]

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
There is a kit out there that only brings it out to binary and that's
located at http://www.rst-engr.com/rst/catalog/altitude_encoder_and_elt.html

I'd like to buy the kit and add additional circuitry to allow for the
real time digital display of altitude.
....

Is there something out there that will do this in a single IC?

What would I need to burn the prom?

I once saw a binary-to-gray/gray-to-binary encoder/decoder made of a bank
of exclusive or gates. I have no idea how to implement it, but it
shouldn't be that hard to come up with a circuit, since you already
know the truth table.

What you would need to burn the PROM would be some software that can
make the proper binary file, and a PROM programmer of some kind to do
the actual programming.

If your data needs to be scaled (I snipped your numbers), then a
micro is probably in order, or you could put your scale factor in
the PROM.

Good Luck!
Rich

 

[Donald]

No, you can do it in assembly on an 8051. Whatever you do don't try
to do something like this in C. That is certainly the hard way. I

< CAUTION: Flame War emanate >

WHAT !!??

What's wrong with C.

I am sure like yourself, I have functional C code ready to drop into a
new project. C is the assembly code of the new millennium.

Code re-use is far easier in C then 8051 assembly.


don

 

[D from BC]

No, you can do it in assembly on an 8051. Whatever you do don't try
to do something like this in C. That is certainly the hard way. If
you don't know assembly go get one of those micros that speaks basic.
It is much easier to develop code in a interpretive environments. You
don't need the speed that assembly will give you.

I thought the goal of using C and a C compiler is supposed to make uC
code developement easier and faster?

Note: I only code in PIC assembly so I haven't checked out how good
those uC C developement environments are these days...


D from BC

 

[whit3rd]

I'm into aircraft avionics and want to build a test box to decode the
altitude encoders output. It's a gray scale binary output.
.... Each bit change is in 100 foot increments.
The range would be -2000 to 40,000 feet.

So you want output to have sign bit, and two full digits (4 bits
each)
and one digit that ranges 0...4 (3 bits). Easy to do with two
8-bit ROMs. Input range is implied to be about nine bits.
So, two 512-byte ROMs would do it in lookup-table style.
That's pretty small for an EPROM/EEPROM, but obviously
do-able.

If you multiplex the display, your digit counter (0 for least-
significant
digit, ...5 for the sign) that adds 3 bits to the address and pulls
the
output width of the ROM down to 4 bits, so you can do it with
half a 4096-byte ROM. Heck, go ahead and decode the digit (four bits)
to the seven segments inside the ROM and use seven bits of
the ROM output. Still a nice small ROM, and that even includes
the two always-zero digits.

The smallest EPROM in the catalog is about 256k, so it leaves room
for tables for active-HIGH and active-LOW inputs in combination
with active-HIGH or active-LOW outputs, using only 16k of the
available space. I'd say, go for it!

You have to construct the table, of course.

 

[Martin Griffith]

I once saw a binary-to-gray/gray-to-binary encoder/decoder made of a bank
of exclusive or gates. I have no idea how to implement it, but it
shouldn't be that hard to come up with a circuit, since you already
know the truth table.

What you would need to burn the PROM would be some software that can
make the proper binary file, and a PROM programmer of some kind to do
the actual programming.

If your data needs to be scaled (I snipped your numbers), then a
micro is probably in order, or you could put your scale factor in
the PROM.

Good Luck!
Rich

http://en.wikipedia.org/wiki/Gray_code
google xor graycode brings up a few reasonable hits



Martin

 

[Dave]

Hi, Dave. It's not clear to me what you are talking about, just yet.
You have an existing system on the plane which provides a Gray encoded
parallel form of signalling. In other words, you've got a bunch of
wires coming out. How many of these wires, exactly? 16? Also, what
is the analog signalling like? Is this 5V CMOS or 3.3V CMOS or 5V TTL
or something else entirely? (By the way, is it the "blind encoder"
shown on that site you mentioned?)

I gather you are looking for something that doesn't sit on the plane,
but instead is used in the shop to calibrate/test altitude encoders?

I guess I'm also flipping between thinking this is a one-off for your
own plane versus something that an A&P might use in the shop for a
wide variety of units they might see over time. Which is it?

Jon

Jon,

I believe the encoder has an open collector arrangement for the 10 data
lines. Typically not all data lines are being used.

http://www.mail2600.com/EncoderConverter/EncoderTester.jpg

The preceding web page shows what the interface looks like for a basic
LED display of the data lines. The tester will need to supply voltage to
the data lines and the encoder will pull the lines down to change the
state of the line. That voltage could be just about anything positive.
I'll try to find the actual voltage specification for the interface.

There is no analog signaling used at all.

Your correct that it is used to calibrate the encoder on the bench/off
plane. The blind encoder is shown along with the test box. The test box
is nothing more than resistors and leds.

I plan on using this for my testing since my current transponder test
box went up in smoke and the new one i expect to buy does not have this
feature.

Other A&Ps may use this, but RST engineering has the basic led version
if they need one.

Cheers

Dave

 

[Jan Panteltje]

I thought the goal of using C and a C compiler is supposed to make uC
code developement easier and faster?

I think to program a micro in C, then it must have a suitable address space,
and memory organisation.

As _hardware_ designer it makes a lot of sense to just take the data sheet and look at the registers,
and go asm, because it is 100% clear what you are doing.
For example output port associated registers, and timers, similar stuff.
In C always the question lingers: 'What code did the compiler generate?'
Or: 'Did the compiler understand my hardware intentions?'
This is especially true when you program on the edge of what the uc can do (for speed for example,
where you need to count clock cycles to get it just right).
For a simple display interface like the OP needs, a very small micro is enough, and that would
be a simple type that probably does not have the resources to be suited for a C compiler.

OTOH if the project is more complex, and you have a board with ethernet, USB, and a real OS,
like for example Linux, and sufficient memory, alien drivers, then C is a must.
Even then knowing asm maybe helpful.

Using C, or even BASIC, to make a grey to <whatever> display converter seems to be to
be a bit of overkill.....

 

[linnix]

I think to program a micro in C, then it must have a suitable address space,
and memory organisation.

As _hardware_ designer it makes a lot of sense to just take the data sheet and look at the registers,
and go asm, because it is 100% clear what you are doing.
For example output port associated registers, and timers, similar stuff.
In C always the question lingers: 'What code did the compiler generate?'
Or: 'Did the compiler understand my hardware intentions?'
This is especially true when you program on the edge of what the uc can do (for speed for example,
where you need to count clock cycles to get it just right).
For a simple display interface like the OP needs, a very small micro is enough, and that would
be a simple type that probably does not have the resources to be suited for a C compiler.

OTOH if the project is more complex, and you have a board with ethernet, USB, and a real OS,
like for example Linux, and sufficient memory, alien drivers, then C is a must.
Even then knowing asm maybe helpful.

Using C, or even BASIC, to make a grey to <whatever> display converter seems to be to
be a bit of overkill.....

Overkill is in the eye of the beholder. I recently did a simple demo
project to compare two analog signals and show the results on an LCD.
The C program takes half a day and the binary takes approx. 2K. The
16K micro is definitely an overkill, but we got thousands of them for
$3 each.

 

[Jan Panteltje]

Overkill is in the eye of the beholder. I recently did a simple demo
project to compare two analog signals and show the results on an LCD.
The C program takes half a day and the binary takes approx. 2K. The
16K micro is definitely an overkill, but we got thousands of them for
$3 each.

I can do that in a < 1$ PIC is ASM in half a day or less, if it is one
of those 2 line text LCD'.
And I'd throw in a temp display for free
In less then 2 k.
For example PIC12F615
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1001&mid=10&lang=en&pageId=74

 

[linnix]

OK, I lied. We don't have thousands yet, will have thousands soon.

I can do that in a < 1$ PIC

Not for segmented LCDs.

is ASM in half a day or less, if it is one
of those 2 line text LCD'.

Text LCDs are too expensive. Segmented LCDs are 50 cents each.
The demo uses a 40 segments LCD glass, using a 64 pins LCD AVR.
The demo convinced the customer to start with 5000 units.

 

[Jonathan Kirwan]

Jon,

I believe the encoder has an open collector arrangement for the 10 data
lines. Typically not all data lines are being used.

http://www.mail2600.com/EncoderConverter/EncoderTester.jpg

That goes a long way. Thanks. It doesn't go all the way, as I still
have more questions.

The preceding web page shows what the interface looks like for a basic
LED display of the data lines. The tester will need to supply voltage to
the data lines and the encoder will pull the lines down to change the
state of the line. That voltage could be just about anything positive.
I'll try to find the actual voltage specification for the interface.

Okay. So the bench tester needs to source +14V to the encoder under
test, right? In other words, this isn't just a display but also a
power supply. Or is that another box you already have laying about
and plan to attach to the display to make up a whole test unit?

(I would guess that you'd have mentioned it earlier, if you didn't
already have the supply voltage handy. The reason I'm asking this
narrow point is to just nail down the assumptions going on. In other
words, you probably do have the supply and probably would plan to
attach it somehow. From my perspective, though, what this means is
that the display unit should rely upon the same supply, in order to be
more convenient to use. And it should have a (+) and (-) input
connector for the +14V [or whatever it should be] that can be passed
along to the encoder under test.)

There is no analog signaling used at all.

What I meant was to ask what the analog characteristics of the
signaling are -- all digital signals are really just analog signals
with definitions applied to them. So I was interested in the analog
details of the digital signals, if that makes more sense.

Your correct that it is used to calibrate the encoder on the bench/off
plane. The blind encoder is shown along with the test box. The test box
is nothing more than resistors and leds.

Okay. So now we get to my remaining question. On the JPG you show in
the above link, I see the description indicate LEDs grouped in threes.
One is labeled red, one yellow, and one green. And there is one more
"group" of one LED which is labeled as a rectangular red.

The RST-7301 box shown on the original web site you mentioned (not the
one mentioned in the post I'm now responding to, but the earlier
starting post by you), there are these same groups of three LEDs and
they are colored, accordingly. However, that box appears to lack the
rectangular RED LED. What is that one for?

Also earlier, you said the encoding is Gray. However. Is this
encoding on 3-bit groupings only? Or across all the LED groups? Can
you be detailed here?

Purely guessing about this, I'm suspecting that the three groups
correspond to three digits and that each group is Gray encoded, but
not the entire altitude as a whole. And that the rectangular LED is
the minus sign. All just a guess, though.

I plan on using this for my testing since my current transponder test
box went up in smoke and the new one i expect to buy does not have this
feature.

okay. Understood.

Other A&Ps may use this, but RST engineering has the basic led version
if they need one.

Okay.

Jon

 

[Jonathan Kirwan]

So the bench tester needs to source +14V ...

Probably a 12V car battery supply?

Jon

 

[Dave]

Okay. So now we get to my remaining question. On the JPG you show in
the above link, I see the description indicate LEDs grouped in threes.
One is labeled red, one yellow, and one green. And there is one more
"group" of one LED which is labeled as a rectangular red.

Jon,
The "C" group of bits repeat every 1000 feet as indicated in
http://www.mail2600.com/EncoderConverter/ModeCData.txt.
The red, yellow and green groups correspond to the groups of data lines
from the encoder.
Not sure about the rectangular red group you mentioned. It may be the
"D" group of bits which only show their heads when the altitude is above
30800 feet.

The RST-7301 box shown on the original web site you mentioned (not the
one mentioned in the post I'm now responding to, but the earlier
starting post by you), there are these same groups of three LEDs and
they are colored, accordingly. However, that box appears to lack the
rectangular RED LED. What is that one for?

Also earlier, you said the encoding is Gray. However. Is this
encoding on 3-bit groupings only? Or across all the LED groups? Can
you be detailed here?

Purely guessing about this, I'm suspecting that the three groups
correspond to three digits and that each group is Gray encoded, but
not the entire altitude as a whole. And that the rectangular LED is
the minus sign. All just a guess, though.

The link that I added above shows the binary output for each altitude.
I guess what I need is a device/prom/display which will take that input
and display the indicated altitude.

i plan on operating this box from a 12v source which will supply voltage
to the test box and also the 1 amp or so current required by the
encoder. This will either be a portable battery or a plug in the wall
type of supply.

okay. Understood.

Again I appreciate all the input that I've received from everyone here.
I'm not sure if i really need a micro-controller to display the
information required, but it certainly sounds fun.
I'm trying to find more bells and whistles that can be added to this to
make it more versatile and maybe more marketable, but haven't thought of
any yet.

I'll take any and all input for the design of this.


Thanks again

Dave

 

[linnix]

Jon,
The "C" group of bits repeat every 1000 feet as indicated inhttp://www.mail2600.com/EncoderConverter/ModeCData.txt.

You have approx. 300 values encoded in 12 bits. This can be done in
0.5K look up table in the smallest micro.