On a sunny day (Sun, 16 Sep 2007 16:12:48 -0700) it happened linnix wrote in :
I did a display system using the PCF8577 (or an earlier one, not sure, but same idea)
formatting link
32 segments, or 64 segments muliplexed (I did not multiplex). Driving huge 7 segment LCDs to show time and number for people (in a building). With backlight.. In the eighties. But that was a small series (about 50).
That chip is likely more expensive, but you can hang it on the 70 cent PIC, and have IO pins left ;-)
Hi Dave . I did a general aviation mode c altitude encoder in c in '99.. seems that the challenge in building a tester is the pneumatic part to pump down the encoder static port to check that its reading accurately. Pitot-Static test sets aint cheap for a reason I think.
Accurate pressure sensors are not cheap-- you probably need an accuracy of something like +/-0.025% or 0.05% to do a decent job in this case.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
You buy a microprocessor development board which has a suitable display and enough I/O lines to read the altitude encoder outputs. You then have to figure out how to write the software to do the job. A fairly big lump of learning to do.
You build some circuitry. The simplest solution would be an 8 bit EPROM and 7 segment LED display for each display digit. The encoder output addresses the EPROMS the EPROM outputs drive the display segments directly (via current limiting resistors). You have to work out a big lookup table to translate the gray code into LED segments and need some means to program the EPROMS.
Think it boils down to if you are happier building hardware and have some means to program an EPROM or you are happier taking on learning how to program a microprocessor.
If you were going to make 'some' of these units the microprocessor option (basically the development board with the bits you don't use left off) would likely be the cheapest smallest solution.
Yes, we are looking into COG PCF8533 (80x4) and using only 80x1. We want to get away from multiplexed signals (hard to read) and dedicated uC (hard to buy). But that's a few months away.
As many others have mentioned in this thread, I think a micro is the way to go.
16x2 LCDs are cheap and very easy to handle. With a micro, you can do just about anything you want. The problem is that you have either a learning curve and/or considerable expense getting in the door with these things.
There are two I know of, however, that don't require programming hardware, that have a lot of I/O lines, and have free development systems available. The two that pop right to mind are the Arduino ATmega168 and the Picaxe 28X1.
Arduino:
formatting link
Picaxe:
formatting link
The Picaxe is programmed in a subset of BASIC. It's very easy to program that chip to perform simple tasks, but as your application gains in complexity, that language soon becomes unwieldy.
The Arduino is programmed in C. It might have a steeper learning curve getting in the door, but it makes larger programs much simpler to write, modify, and maintain.
I recently tried an Arduino for the first time, and was able to implement a fairly complex application with very little pain. I was amazed how easy it was to develop a large (as microcontrollers go) program. If your app is simple, I'd take a look at the 28X1. If it looks like there's going to be any complexity in either the short or long term, try an Arduino.
If you'd like to take a look at my project (which, by the way, incorporates a 16x2 LCD), you can find it at
formatting link
Don't let the idea of programming a micro scare you away. As you can see from the large number of responses to your question, lots of folks (myself included) would be only too happy to help you along.
Thanks for adding that Spehro. The question I have about your figures comes from a recollection about air pressure changes. I thought I'd recalled something like 0.1 hPa/m at sea level. If that were the case, then I'd expect to see 100' (about 30m) work out to about 3 hPa. Since sea level is roughly 1000 hPa, that's about 0.3% resolution.
So I looked it up.
I think pressure declines at the rate of about 0.1 hPa/m. 100' would be about 30 m, so about 3 hPa resolution. Since sea level pressure is around 1000 hPa, that is about 0.3%, isn't it?
So I googled and got something from section 3.2.2 of:
Well, they might be in the sense that the technician has an accurate instrument pressure reading they get and that they can then verify that the instrument exposed to open air reads that value, or closely enough. An easy one point cal, at a guess.
I get 0.1% between 15,000 and 20,000 feet to meet the TSO minimum accuracy requrement. You'd want your standard to be a lot closer than that, no?
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
So this is where your 0.05% comes from. Thanks. The resolution at elevation like that would certainly need to be better than at sea level -- I forgot to plot (dP/P) vs A. You continue to use the term 'accuracy' though in your writing. Since my vague recollection from decades ago is that I just set the sea level pressure into the altimeter and that aircraft fly separate themselves by the thousands, (odd thousands for half the circle of directions, even thousands for the other half) that seems a poor term to use. I'd guess that 200 to
300 hundred feet of accuracy is all that is actually needed to keep VFR traffic (which has lower instrumentation requirements and doesn't include some of the fancier things IFR requires) generally apart.
Anyway, thanks for clarifying what you were thinking about.
So this is where your 0.05% comes from. Thanks. The resolution at elevation like that would certainly need to be better than at sea level -- I forgot to plot (dP/P) vs A. You continue to use the term 'accuracy' though in your writing. Since my vague recollection from decades ago is that I just set the sea level pressure into the altimeter and that aircraft fly separate themselves by the thousands, (odd thousands for half the circle of directions, even thousands for the other half) that seems a poor term to use. I'd guess that 200 to
300 hundred feet of accuracy is all that is actually needed to keep VFR traffic (which has lower instrumentation requirements and doesn't include some of the fancier things IFR requires) generally apart.
Anyway, thanks for clarifying what you were thinking about.
I'm using a basic pitot/static test set that once had a mechanical altimeter as a reference. It has an internal combination pressure and vacuum pump with reservoirs for each. It also has manual pumps so i can get along without electricity. The big thing with it is controlling the vacuum and pressure levels. You really need quality needle valves with good stable characteristics. The mechanical altimeter had a requirement to get calibrated every 30 days and that was an expensive pain in the arse. It still wasn't cheap with the basic instruments ie, airspeed, vertical speed and altimeter. I've since upgraded to a handheld digital altimeter made by Meriam with the following specifications:
"The 353 is microprocessor based and has +/- 0.02% of full scale accuracy including all effects of linearity, repeatability, hysteresis and temperature over the range of 23 º F to 122 º F. This equates to +/-
7 feet at sea level and +/- 77 feet at 60,000 feet."
It was quite a bit more expensive than the mechanical altimeter, but has a one year calibration requirement. I understand that there are internal temperature sensors which compensate for temperature variances in the sensor.
The topmost bit is passed through untouched. Each of the lower bits is obtained by XOR with either the input (binary->Gray) or output (Gray->binary) from the stage above. IOW;
Note that the encoding (binary->Gray) case has unit propagation delay, while the decoding case has ripple delay (i.e. proportional to the number of bits).
But the project in question seems to be sufficiently involved that a microcontroller would be more appropriate.
I've taken a moment to provide sketch out one possible way to go, with a microcontroller. The PIC16F57 is very cheap, mostly because it doesn't have a serial port or other useful extras. It's just a bunch of simple I/O pins. Which is all you really need. They are less than a dollar each, in 1's, at Allied:
formatting link
You might also try these 7-segment displays (I've not used them, but the current and brightness may work):
formatting link
I consider these expensive (I get them at about 1 cent each, if I keep my eyes peeled for a good deal), but if you are going to put an Allied order together, Q1-Q4 can be had here:
formatting link
Anyway, I'm open to criticism about the schematic. I didn't add the
5V regulator to it, figuring you can find a schematic for that on the web. They are simple enough, driven off of 12V. Consider Vcc=5V, below.
The minus sign can be one of the segments on the high order digit
7-segment display, since that will normally be 0, then. (You only go down to -1200', so that would display as a -12.)
What is missing beyond all that is the code. And you'll need a PIC programmer device to load the code into the cpu. Perhaps you can corner someone into doing the code for you. It shouldn't be too difficult. A timer setup to establish the multiplexing time period is needed, some code to read and interpret the input lines and generate the selected segments to drive. It's pretty basic stuff, for someone who is used to coding micros.
Jon
read the following without word-wrap and in a fixed point font:
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.