Connect with us

Need display design help

Discussion in 'Electronic Basics' started by Dave, Sep 16, 2007.

Scroll to continue with content
  1. Dave

    Dave Guest

    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

    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?


  2. 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
  3. D from BC

    D from BC Guest

    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.

    as an example.
    There are other competing uC's... so check them out to and chose.

    D from BC
  4. 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?

  5. MooseFET

    MooseFET Guest

    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.
  6. CWatters

    CWatters Guest

    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.
  7. Rich Grise

    Rich Grise Guest

    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!
  8. Donald

    Donald Guest

    < 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.

  9. D from BC

    D from BC Guest

    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
  10. whit3rd

    whit3rd Guest

    So you want output to have sign bit, and two full digits (4 bits
    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

    If you multiplex the display, your digit counter (0 for least-
    digit, ...5 for the sign) that adds 3 bits to the address and pulls
    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.
    google xor graycode brings up a few reasonable hits

  12. Dave

    Dave Guest


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

    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

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


  13. 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.....
  14. linnix

    linnix Guest

    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.
  15. 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
  16. linnix

    linnix Guest

    OK, I lied. We don't have thousands yet, will have thousands soon.
    Not for segmented LCDs.
    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.
  17. That goes a long way. Thanks. It doesn't go all the way, as I still
    have more questions.
    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.)
    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.
    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.
    okay. Understood.

  18. Probably a 12V car battery supply?

  19. Dave

    Dave Guest

    The "C" group of bits repeat every 1000 feet as indicated in
    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 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.
    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

  20. linnix

    linnix Guest

    You have approx. 300 values encoded in 12 bits. This can be done in
    0.5K look up table in the smallest micro.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
There are no similar threads yet.
Electronics Point Logo
Continue to site
Quote of the day