Need display design help

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

formatting link

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 snipped-for-privacy@craigmileaviation.com

Reply to
Dave
Loading thread data ...

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

Reply to
Roger Hamlett

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

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

D from BC

Reply to
D from BC

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

Reply to
Jonathan Kirwan

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.

Reply to
MooseFET

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.

Reply to
CWatters

< 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

Reply to
Donald

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

Reply to
D from BC

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.

Reply to
whit3rd

formatting link
google xor graycode brings up a few reasonable hits

Martin

Reply to
Martin Griffith

Jon,

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

formatting link

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

Reply to
Dave

On a sunny day (Sun, 16 Sep 2007 19:32:01 GMT) it happened D from BC wrote in :

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 display converter seems to be to be a bit of overkill.....

Reply to
Jan Panteltje

look at the registers,

(for speed for example,

enough, and that would

C compiler.

and a real OS,

to be to

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.
Reply to
linnix

On a sunny day (Sun, 16 Sep 2007 15:26:58 -0700) it happened linnix wrote in :

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

formatting link

Reply to
Jan Panteltje

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.

Reply to
linnix

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.

Okay.

Jon

Reply to
Jonathan Kirwan

Probably a 12V car battery supply?

Jon

Reply to
Jonathan Kirwan

Jon, The "C" group of bits repeat every 1000 feet as indicated in

formatting link
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

Dave

Reply to
Dave

in

formatting link

You have approx. 300 values encoded in 12 bits. This can be done in

0.5K look up table in the smallest micro.
Reply to
linnix

Okay. I think I'm with you. The D field of three looks like an addition to a prior standard to extend the altitude. There are provisions for three bits there, but just rolling over from 0 to 1 is enough to add another 32000' to the prior standard and that is why there are only 10 leads. No need to pass along the other two, which will always be zero, anyway.

The C field works a little differently than the A and B fields. The valid symbol sequence for the C field appears to be:

1 3 2 6 4 4 6 2 3 1 ^ ^

A "carry" (advance to the next code in the B field) occurs where the "^" is at, above. In other words, when it switches direction. It counts up, then it counts back down. Then back up, then back down.

The B field uses this sequence:

0 1 3 2 6 7 5 4 4 5 7 6 2 3 1 0 ^ ^

And again, at the 'arrows' (^) above, there is an advance in the A field indicated at that B field transition. Note that the B field adds the additional symbols of 7 and 5 and 0 to the C field sequence.

Finally, the A field looks like the B field:

0 1 3 2 6 7 5 4 4 5 7 6 2 3 1 0 ^ ^

However, without a D field added, the A field cannot advance past the first "^" above.

In terms of basic symbols, there are 5 symbols in the C field before having to change the B field. There are 8 symbols in the B field before having to change the A field. And without the D field, there are 8 symbols in the A field. So before considering the D field, you have 5*8*8 or 320 possible symbols. With 100' increments, that provides a span from -1200' to (-1200' + 320*100' - 100') or 30700. Just as the table shows, in fact. At 30800, the D field inserts itself into the problem and changes from a 0 to a 1.

You are really going to find that a micro would be the easier approach to all this, assuming you can get it programmed of course. It can not only do the conversions required, quite easily, but it can also drive a multipled 7-seg LED display with the results. Open collector should be no problem, at all.

You are talking about 10 input lines, 10 output lines I think for the

7-seg high efficiency LED displays, three BJTs for the common side drivers probably, some resistors and a micro. A 28-32 pin device should manage fine. I don't know if there is an existing demo board with the necessary stuff already done for you, but probably there is.

Jon

Reply to
Jonathan Kirwan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.