Avionics-Archive.digest.vol-ac

December 28, 1999 - May 14, 2000



      Jeff
      
      -----Original Message-----
      
      
      How many people here are hams?  I am (WB6RQN), Steve Devine is (N1YZJ),
      and Dave Bridgham is (I forgot his callsign).  Anyone else?
      
      
      
________________________________________________________________________________
From: HornetBall(at)aol.com
Date: Dec 28, 1999
Subject: Re: DMU-AHRS
I've had good success with the Watson Industries AHRS. ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Ham licenses
Date: Dec 28, 1999
I'm KB5FWG... -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Brian Lloyd Sent: Tuesday, December 28, 1999 10:16 AM Subject: Avionics-List: Ham licenses How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), and Dave Bridgham is (I forgot his callsign). Anyone else? Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Ham licenses
On Tue, 28 Dec 1999, Jeff Barlow wrote: > > Brian, > > Well... Many, many years ago I was (WB6CSV). > > >I'm KB5FWG... A pretty high ratio of hams here. Do I detect a correlation between wanting to play with radios and wanting to play with radios in airplanes? ; ) Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Ham licenses and airplane radios
Date: Dec 28, 1999
>A pretty high ratio of hams here. Do I detect a correlation between >wanting to play with radios and wanting to play with radios in >airplanes? ; ) > >Brian Lloyd Well, I originally got my tech license to put an avionics and video package into a radio-controlled plane... I was considering building a Senior Telemaster (8' wingspan, was hoping to find a souce for the giant 12' model), but got distracted with other things... The idea never flew (I screwed up somewhere in the ATV transmitter kit assembly/tuning, and later found a better used for the microvideo camera), and I subsequently decided that it would make more sense to start flying the real thing instead of simulating it with an R/C bird... So this sort of idea has been banging around my cranium for quite some time (it just got bigger more recently) (the idea, not the cranium). Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: PBGCP: amusing side topics
Date: Dec 28, 1999
(PBGCP = Pink Bunny Glass Cockpit Project) If one were to draw up a pink bunny logo, what exactly would he be smashing with that hammer? (Some of us need amusing and completely irrelevant side projects to help pass the time) I'm picturing a very frustrated looking bunny whacking away at the cowling or panel or an instrument or something... it has to be something obvious... whacking at a black box or AHRS gyro just won't look the same... Bored at work... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 28, 1999
From: Richard Dudley <rhdudley(at)att.net>
Subject: Re: Ham licenses
AC4PF Richard Dudley RV-6A wings Florida Brian Lloyd wrote: > > > How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), > and Dave Bridgham is (I forgot his callsign). Anyone else? > > Brian Lloyd > brian(at)lloyd.com > +1.530.676.6513 > ________________________________________________________________________________
From: "Gordon or Marge Comfort" <gcomfo(at)tc3net.com>
Subject: Re: Audio question
Date: Dec 28, 1999
-----Original Message----- From: Matthew Mucker <mmucker(at)airmail.net> >I'd like to take the headphone audio output from an aircraft's >intercom/radio system and use that to feed the microphone input to a >camcorder. Since the microphone, I'm sure, uses much lower voltage and >current than the headphone output, I'm wondering if anyone knows of or could >whip up a circuit to do the proper level matching. Matt: Upon the advice (several years ago) of a Sigtronics engineer, I bought a cable from Radio Shack that fit the videocamera external mic jack, a quarter watt 1000ohm resistor and from an aircraft supply house a headphone plug. The resistor was soldered in series with the phone lead (inside the aircraft plug) with suitable insulation and strain relief. Since most cameras apparently have some sort of signal levelling built in the above impedance matching is all that is needed. Works just fine. I also installed a third phone jack in my RV-4 to enable its use. You can narrate, record intercom traffic and any radio traffic. Engine noise is still slightly audible but does not intrude. Gordon Comfort N363GC ________________________________________________________________________________
From: "IEN YOE" <PAUL.AND.IEN(at)worldnet.att.net>
Subject: Re: Ham licenses
Date: Dec 28, 1999
Paul Bilodeau WA1VGC New Jersey RV-6A > > > > > > How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), > > and Dave Bridgham is (I forgot his callsign). Anyone else? > > > > Brian Lloyd > > brian(at)lloyd.com > > +1.530.676.6513 > > > > > > ________________________________________________________________________________
Date: Dec 28, 1999
From: Collins <collins(at)pali.com>
Subject: Re: Ham licenses
N8IZN Sunnyvale CA Brian Lloyd wrote: > > > How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), > and Dave Bridgham is (I forgot his callsign). Anyone else? > > Brian Lloyd > brian(at)lloyd.com > +1.530.676.6513 > -- Bob Collins ________________________________________________________________________________
From: "Mel Jordan" <tmjordan(at)flash.net>
Subject: Re: Ham licenses
Date: Dec 28, 1999
N7UBK Mel Jordan Tucson, AZ Burr-Brown Corporation RV6A Firewall forward ----- Original Message ----- > Brian Lloyd wrote: > > > > > > How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), > > and Dave Bridgham is (I forgot his callsign). Anyone else? > > > > Brian Lloyd > > brian(at)lloyd.com > > +1.530.676.6513 > > > > -- > Bob Collins > > > > > > ________________________________________________________________________________
Date: Dec 29, 1999
From: Ray Menke <rndmenke(at)lockhart.net>
Subject: Re: Ham licenses
> How many people here are hams? WX5D TriPacer N9017D (1957) Skybolt (under construction ....years) Lytton Springs, Texas -- Ray Menke RnDMenke(at)lockhart.net ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: FW: Psychic Dog
Date: Dec 29, 1999
Not strictly avionics but more canine-onics - but I thought you guys need a little lighten-up over the holidays. I'm sure you will appreciate the sensations involved.... Joe Hovel It's common practice in England to ring a telephone by sending extra voltage across one side of the two wire circuit and ground (earth in England). When the subscriber answers the phone, it switches to the two wire circuit for the conversation. This method allows two parties on the same line to be signalled without disturbing each other. Anyway, an elderly lady with several pets called to say that her telephone failed to ring when her friends called and that on the few occasions when it did ring her dog always barked first. The telephone repairman proceeded to the scene, curious to see this psychic dog. He climbed a nearby telephone pole, hooked in his test set, and dialled the subscriber's house. The phone didn't ring. He tried again. The dog barked loudly, followed by a ringing telephone. Climbing down from the pole, the telephone repairman found: The dog was tied to the telephone system's ground post via an iron chain and collar. The dog was receiving 90 volts of signalling voltage. After several such jolts, the dog would start barking and urinating on the ground. The wet ground now completed the circuit and the phone would ring... Which shows you that some problems can be fixed by just pissing on them. (But only temporarily.) ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Psychic Dog
Date: Dec 29, 1999
> >Not strictly avionics but more canine-onics - but I thought you guys >need a little lighten-up over the holidays. I'm sure you will appreciate >the sensations involved.... > >...The dog was tied to the telephone system's ground post via an iron >chain and collar. The dog was receiving 90 volts of signalling voltage. >After several such jolts, the dog would start barking and urinating on >the ground. The wet ground now completed the circuit and the phone >would ring... > >Which shows you that some problems can be fixed by just pissing on >them. (But only temporarily.) I suggest that we not adopt this technology for our pink bunny project (ie not have an actual pink bunny completing the circuit... : ) Steve steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 29, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: Ham licenses
> >> How many people here are hams? K0DYH since 1956 Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Dec 29, 1999
Subject: Please help, I want parts! Atmel work continuing, ham
Hi all, >How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), and Dave Bridgham is (I forgot his callsign). Anyone else? I am KG0T, and my first project on the way to an electronic cockpit is to get familiar with some micro by building a Morse code keyer. I chose the Atmel AVR series, got the $50 development board and the free software, and in a very short time got it all working. My assembly language code for the keyer is well under way, and I am very pleased with how easy it has all been. The total parts cost for the keyer will be about $2!. The sore spot is that I have not been able to find a source of supply for some other parts I'll need for my first CAN project. For example, I thought I'd use the Microchip MCP2510 CAN controller, but it appears that it does not really exist. Someone suggested a MB90F497 Fujitsu part with a built-in CAN controller, but I can't find that one either. The TI TMS320F241 would also work, but searches of the TI web site and phone calls to TI indicate that it is vaporware. The TI MPS430F series is another nice part (without CAN) that seems to be imaginary. The Motorola XC68HC912BC32 looks good, but it also is apparently not ready yet. Can anyone tell me where I can actually order (and get delivery of) something? The wonderful thing about Atmel (and, I think, the PIC micros) is that they are available quickly in small quantities with minimum effort - and they are powerful enough for most of what I want to do. Surely some of you have been through all this, and maybe can tell me where I can get parts. OTOH, maybe all the CAN stuff is either vaporware or only available in huge (automotive) quantities. If the price is about the same, my order of preference would be Fujitsu, TI, Motorola, and Atmel plus stand-alone CAN controller. It does appear that the software for the TI will be expensive, while all the others have free assemblers. The TI and Fujitsu are 16 bit processors with hardware multiply and other neat stuff for those heavy duty compute-bound projects - don't need it for most things, but would like to use a single family for everything. OTOH, if the Atmel solution costs $10 and the others are $25, I'll probably use Atmel (the other parts will all need an expensive socket, too). If the majority of the group settles on some particular part then that would have a strong influence. Please give me a new year's present (information)... cheers, g. ________________________________________________________________________________
Date: Dec 29, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Ham licenses
Wow! Sure seem to be a lot of radio hackers out there! Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 29, 1999
From: "Stefan B." <stefan.balatchev(at)wanadoo.fr>
Subject: Airbus A3XX bus
It is just for information. I have read the designers of the very big Airbus A3XX will use the FastEthernet (100 Mb/s) as a communication bus. Stefan Balatchev, France ________________________________________________________________________________
From: "Jeff Frontz" <jhf@ryan-tcad.com>
Subject: Airbus A3XX bus
Date: Dec 29, 1999
> It is just for information. I have read the designers of the very > big Airbus A3XX > will use the FastEthernet (100 Mb/s) as a communication bus. > Is that just for non-critical things (like in-flight entertainment)? I'll be even more leary of flying on a Airbus product if they're using a non-deterministic communication medium like Ethernet. Jeff ________________________________________________________________________________
From: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: I know this is late but I just had to post it.
Date: Dec 29, 1999
A visit From St. Nicholas to an FBO near you... 'Twas the night before Christmas, and out on the ramp, not an airplane was stirring, not even a Champ. The aircraft were fastened to tiedowns with care, in hopes that come morning, they all would be there. The fuel trucks were nestled, all snug in their spots, while peak gusts from two-zero reached 39 knots. And I at the fuel desk, now finally caught up, had just settled comfortably down on my butt. When over the radio, there arose such a clatter, I turned up the scanner to see what was the matter. A voice clearly heard over static and snow, asked for clearance to land at the airport below. He barked out his transmission so lively and quick, I could have sworn that the call sign he used was "St.Nick". Away to the window I flew like a flash, sure that it was only Horizon's late Dash. Then he called his position, and there could be no denial, "This is St Nicholas One and I'm turning on final." When what to my wondering eyes should appear, a Rutan sleigh, and eight Rotax reindeer. He flew the approach on glideslopes he came, as he passed all fixes, he called them by name: "Now Ringo! Now Tolga! Now Triniand Bacun! On Comet! On cupid! 'What pills was he ta kin? Those last couple of fixes left controller's confused, they called down to the office to give me the news, The message they left was both urgent and dour: "When Santa lands, could he please call the tower?" He landed like silk, with the sled runner's sparking, then I heard "Exit at Charlie," and "Taxi to parking." So up to the offices the coursers they flew, with loud airplane noise, and St. Nicholas, too. He stepped out of the sleigh, but before he could talk, I had run out to him with my best set of chocks. He was dressed all in fur, which was covered with frost and his beard was all blackened from reindeer exhaust. His breath smelled like peppermint, gone slightly stale and he smoked on a pipe, but he didn't inhale. He had a broad face and his armpits were smelly, and his boots were as black as a cropdusters belly. He was chubby and plump, a right jolly old fool, and he kindly informed me that he needed some fuel. A wink of his eye and a twist of his toes, led me to know he was desperate to powder his nose. I spoke not a word, but went straight to my work, and I filled up the sleigh, but I spilled like a jerk. He came out of the restroom with a sigh of relief, and then picked up a phone for a flight service brief. And I thought, as he silently scribed in his log, That with Rudolph, he could land in eighth-mile fog. Next, he completed his preflight, from front to rear, then he put on his headset, and I heard him yell "Clear!" And laying a finger on his push-talk, He called up the tower for his clearance and squawk. "Straight out on two-zero," the tower called forth, "and watch for a Cessna straight in from the North." But I heard him exclaim, 'ere he climbed in the night, "Happy Christmas to all, I have traffic insight." ________________________________________________________________________________
From: GRENIER(at)aol.com
Date: Dec 29, 1999
Subject: Re: Ham licenses
K1CAW Ray Grenier RV-4 finishing fuse ________________________________________________________________________________
Date: Dec 29, 1999
From: Steven Eberhart <newtech(at)newtech.com>
Subject: Re: Ham licenses
> >> How many people here are hams? > WB9KJW but I let it expire :-( Will hae to re-test :-( Steve Eberhart THE WING FLIES! - http://www.newtech.com/nlf for info on the new, flight tested, KRnet/UIUC airfoils. Good job KRnet, you can be proud of your contribution to Sport Aviation. Special thanks to Dr. Ashok Gopalarathnam and Dr. Michael Selig for some great Sport Aviation airfoils. One test is worth a thousand expert opinions but a thousand opinions are easier to get. --plagiarized from an unknown author All information, in any of my aircraft related correspondence, is strictly food for thought requiring additional, qualified, engineering analysis. ________________________________________________________________________________
Date: Dec 29, 1999
From: dab(at)froghouse.org
Subject: Airbus A3XX bus
On 29 Dec, Jeff Frontz wrote: > I'll be even more leary of flying on a Airbus product if they're > using a non-deterministic communication medium like Ethernet. Since you can't build a perfect arbitrator (I hear this is provable but I just accept it, I think it involves a diagonalization proof and I just never grokked those), I claim you can't build a network that's non-deterinistic. Or even a computer. So you just build protocols on top of the network that reduce the non-determinism to an acceptable level. -Dave ________________________________________________________________________________
Date: Dec 30, 1999
From: "Stefan B." <stefan.balatchev(at)wanadoo.fr>
Subject: Re: Airbus A3XX bus
Jeff Frontz wrote: > > > It is just for information. I have read the designers of the very > > big Airbus A3XX > > will use the FastEthernet (100 Mb/s) as a communication bus. > > > > Is that just for non-critical things (like in-flight entertainment)? I'll > be even more leary of flying on a Airbus product if they're using a > non-deterministic communication medium like Ethernet. > > Jeff > In this article (from a general industrial information magazine) they say this bus is used between the different modules of the "integrated modular avionics". No other precisions. Stefan. ________________________________________________________________________________
Date: Dec 30, 1999
From: dab(at)froghouse.org
Subject: Airbus A3XX bus
On 29 Dec, To: avionics-list(at)matronics.com wrote: > I claim you can't build a network that's non-deterministic. Arrggh! I meant you can't build a bus that's deterministic because that reduces to the arbitrator problem. -Dave ________________________________________________________________________________
Date: Dec 30, 1999
From: Warren Gretz <gretz_aero(at)h2net.net>
Subject: Re: Ham licenses
Warren Gretz N0FVG Littleton, CO Brian Lloyd wrote: > > How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), > and Dave Bridgham is (I forgot his callsign). Anyone else? > > Brian Lloyd > brian(at)lloyd.com > +1.530.676.6513 > ________________________________________________________________________________
Date: Dec 30, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Airbus A3XX bus
On Wed, 29 Dec 1999, Jeff Frontz wrote: > > > > It is just for information. I have read the designers of the very > > big Airbus A3XX > > will use the FastEthernet (100 Mb/s) as a communication bus. > > > > Is that just for non-critical things (like in-flight entertainment)? I'll > be even more leary of flying on a Airbus product if they're using a > non-deterministic communication medium like Ethernet. Years and years of experience have shown that ethernet works just fine in time-critical applications. You just have to bound the latency by keeping the network unloaded and by quantifying the traffic and traffic sources. From that you can determine what your worst-case latency will be. Sure it is nondeterministic but it works. I get a chuckle when people start worrying about latency and determinism in flight control systems on airplanes where it is perfectly normal for them to be hand-flown by humans. If ever there was a system with built in latency variation it is the human avionics buss. We are talking about an AHRS that doesn't work generating inputs to an organic buss structure and processing system whose speed and latency characteristics vary all over the map from moment to moment. Compared to humans, I think I would be perfectly willing to let a 10Mbps ethernet carry the sensor data and flight control commands. I bet it can do a better job of flying the airplane to an accurate touchdown than I can, let alone a relatively new student pilot. Think about it. How long does it take you to catch an airspeed trend? How long does it take you catch an altitude deviation? How well do you track the localizer and glideslope? How accurate are your corrections? Flying an airplane is an amazingly inexact process that is amazingly forgiving of errors. I see the argument against ethernet or other "nondeterministic" buss structures as being especially specious in light of this. So long as the overall servo loop; i.e. sensor, buss, processing, buss, actutor, aircraft response; is stable and convergent even with latency variability in the buss structure, the *SYSTEM* will be safe and well behaved. Remember you are dealing with a *SYSTEM* and you have to characterize the behavior of the entire system, not just one component. I have seen this behavior in standards groups. Someone sees a potential problem and the group will bend over backwards trying to come up with a solution without ever determining whether the perceived problem is an actual problem in the field. That is one of the reasons that the IETF was so successful with TCP/IP over ISO/OSI. The IETF people would do something simple and then try it out to see how it worked, adjusting the protocols as they gained experience. The ISO/OSI folks did all their work on paper basing their decisions on assumptions. The result was that the OSI protocol stack became more and more topheavy attempting to address all the perceived problems. In the mean time TCP/IP was simple enough that it was actually deployed and found useful. So before you reject a simple approach out of hand because you can perceive a problem with it, it probably would behoove you to do some experimentation to find out if it will work in practice. A monte carlo simulation that injects random latency variation on your buss will give you a pretty good idea how it will behave in the field. This is where a good flight sim would be useful to simulate the actual behavior of the aircraft based on the flight control inputs generated by our experimental flight control system. And if we are only talking about an FMS display system and not a full-authority autopilot, the system becomes even less critical since everything is going to filter through a human anyway, a very inexact and error-prone flight control system as I have already pointed out. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: Airbus A3XX bus
Date: Dec 30, 1999
I would have to back Brian up on this. Why use a back-hoe to move a rock when a lever will do the trick. One example that I can think of that is in accords to Brian's thinking is HTML. It is one of the most simplest software languages out there. Although I am not a Software Engineer and don't profess to be, I follow his analogy and agree fully. Seth -----Original Message----- From: Brian Lloyd [mailto:brian(at)lloyd.com] Sent: Thursday, December 30, 1999 11:47 AM Subject: RE: Avionics-List: Airbus A3XX bus On Wed, 29 Dec 1999, Jeff Frontz wrote: > > > > It is just for information. I have read the designers of the very > > big Airbus A3XX > > will use the FastEthernet (100 Mb/s) as a communication bus. > > > > Is that just for non-critical things (like in-flight entertainment)? I'll > be even more leary of flying on a Airbus product if they're using a > non-deterministic communication medium like Ethernet. Years and years of experience have shown that ethernet works just fine in time-critical applications. You just have to bound the latency by keeping the network unloaded and by quantifying the traffic and traffic sources. From that you can determine what your worst-case latency will be. Sure it is nondeterministic but it works. I get a chuckle when people start worrying about latency and determinism in flight control systems on airplanes where it is perfectly normal for them to be hand-flown by humans. If ever there was a system with built in latency variation it is the human avionics buss. We are talking about an AHRS that doesn't work generating inputs to an organic buss structure and processing system whose speed and latency characteristics vary all over the map from moment to moment. Compared to humans, I think I would be perfectly willing to let a 10Mbps ethernet carry the sensor data and flight control commands. I bet it can do a better job of flying the airplane to an accurate touchdown than I can, let alone a relatively new student pilot. Think about it. How long does it take you to catch an airspeed trend? How long does it take you catch an altitude deviation? How well do you track the localizer and glideslope? How accurate are your corrections? Flying an airplane is an amazingly inexact process that is amazingly forgiving of errors. I see the argument against ethernet or other "nondeterministic" buss structures as being especially specious in light of this. So long as the overall servo loop; i.e. sensor, buss, processing, buss, actutor, aircraft response; is stable and convergent even with latency variability in the buss structure, the *SYSTEM* will be safe and well behaved. Remember you are dealing with a *SYSTEM* and you have to characterize the behavior of the entire system, not just one component. I have seen this behavior in standards groups. Someone sees a potential problem and the group will bend over backwards trying to come up with a solution without ever determining whether the perceived problem is an actual problem in the field. That is one of the reasons that the IETF was so successful with TCP/IP over ISO/OSI. The IETF people would do something simple and then try it out to see how it worked, adjusting the protocols as they gained experience. The ISO/OSI folks did all their work on paper basing their decisions on assumptions. The result was that the OSI protocol stack became more and more topheavy attempting to address all the perceived problems. In the mean time TCP/IP was simple enough that it was actually deployed and found useful. So before you reject a simple approach out of hand because you can perceive a problem with it, it probably would behoove you to do some experimentation to find out if it will work in practice. A monte carlo simulation that injects random latency variation on your buss will give you a pretty good idea how it will behave in the field. This is where a good flight sim would be useful to simulate the actual behavior of the aircraft based on the flight control inputs generated by our experimental flight control system. And if we are only talking about an FMS display system and not a full-authority autopilot, the system becomes even less critical since everything is going to filter through a human anyway, a very inexact and error-prone flight control system as I have already pointed out. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 30, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Avionics trade rag
If you want some visibility into what is happening in the world of commercial and military avionics development you might want to subscribe to Avionics Magazine. They talk about things like busses, mutisensor/multimode nav receivers, avionics upgrades to commercial and military aircraft, etc. The rag is free to people in the trade. As "Director, Flight Operations, Livingston Enterprises," I qualified for a free subscription. Their email address is mailto:avionics(at)phillips.com. The address on the subscription bingo card is: Avionics Magazine Reader Service Management Department PO Box 5360 Pittsfield, MA 01203-9191 Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: Please help, I want parts! Atmel work continuing, ham
Date: Dec 30, 1999
---->Oh, I see Kilo Gulf Zero Tango...Zero not Oscar. When I lived in Anchorage, I used to listen to a radio station called KGOT. >I am KG0T, and my first project... >The sore spot is that I have not been able to find a source of supply >for some other parts I'll need for my first CAN project. For example, >I thought I'd use the Microchip MCP2510 CAN controller, but it appears >that it does not really exist. > >Can anyone tell me where I can actually order (and get delivery of) >something? The wonderful thing about Atmel (and, I think, the PIC >micros) is that they are available quickly in small quantities with >minimum effort - and they are powerful enough for most of what I >want to do. > >Surely some of you have been through all this, and maybe can tell me >where I can get parts. OTOH, maybe all the CAN stuff is either >vaporware or only available in huge (automotive) quantities. ---->No, I don't think any of us have any chips in hand that will run CAN. > I think the chip of choice will be the first capable CAN chip that we can get our hands on. I think getting these chips will probably boil down to a group effort, but I have some ideas I'd like to try first--I'm going to contact a few folks that have CAN web pages and beg... Marlin Mixon ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: CAN--Web page in textbook style and quality
Date: Dec 31, 1999
I found this gem today: http://www.stzp.de/papers/icc97/icc97_e.html on CAN Higher Layer Protocols. It was written by Prof. Dr.-Ing. K. Etschberger and talks about why we need to use CAN Kingdom or CAN Aerospace. It has excellent illustrations. Prof. Etschberger describes the following protocols: * CAL (CAN Application Layer) * OSEK/VDX * CANopen * DeviceNet * SDS (Smart Distribution Systems) At the end of the "chapter" there's a list of references. No Questions though :) This one page answers a lot of my "dumb question" posts I posted in the last thirty days. Also, it talks about how the higher layer protocols can allow you to transmit more than the eight byte limit that CAN imposes on its messages, which is something I suspected was possible, but I wasn't sure if any one actually did it. Also, for more CAN links, check out this CAN Link page: http://www.warwick.ac.uk/~esrpy/links.htm Marlin Mixon ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Protocols
Date: Dec 31, 1999
Folks, We seem to be in a holding pattern regarding a higher-layer protocol for communications in the PBGPC. I *still* haven't digested all of the CAN Kingdom and CDA101 documents. Has anyone? I'm looking at several documents here and still haven't managed to pull together a complete picture of the whole system. Folks, I'm just full-blown confused. I think we all agree that CAN is good for the physical layer, but when we get to data format and messaging, it's a mess. I don't even know what all these acronyms are! The candidates are CAN Aerospace, ARINC 492, and CDA101, right? Each of these has drawbacks, right? I haven't even looked at ARINC, because it costs $$$ just to get the specs. I was the first to say CAN Aerospace doesn't seem up to the task. And I just can't make any sense of CDA101 and CAN Kingdom. Also, since CDA101 is driven by the American Dept. of Defense, it's likely that the specification may diverge from our needs, and of course, we'll have absolutely no input whatsoever into its development. AAArrrggghhh! Well, at least I feel better now that I've vented. I may end up recanting my rejection of CAN Aerospace. I still feel it's incomplete, but it is very simple and the finer points could probably be ironed out with the designer quickly. Does anyone have any idea where we go from here? Throwing my hands up in frustration, -Matt ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Protocols
Date: Dec 31, 1999
Matt, Welcome to the wonderful world of network protocol design. If you're not confused and frustrated that means you don't comprehend the scope of the problem. I'm going to be house (dog, cat) sitting for some friends of mine for about a week and a half in Jan. It's way out in the country on a island, so I'll have lots of time to read specs and ponder this. Maybe when I get back I'll have some "words of wisdom" to impart. Or, maybe I'll still be confused. We'll see. Jeff -----Original Message----- Folks, We seem to be in a holding pattern regarding a higher-layer protocol for communications in the PBGPC. I *still* haven't digested all of the CAN Kingdom and CDA101 documents. Has anyone? I'm looking at several documents here and still haven't managed to pull together a complete picture of the whole system. Folks, I'm just full-blown confused. I think we all agree that CAN is good for the physical layer, but when we get to data format and messaging, it's a mess. I don't even know what all these acronyms are! The candidates are CAN Aerospace, ARINC 492, and CDA101, right? Each of these has drawbacks, right? I haven't even looked at ARINC, because it costs $$$ just to get the specs. I was the first to say CAN Aerospace doesn't seem up to the task. And I just can't make any sense of CDA101 and CAN Kingdom. Also, since CDA101 is driven by the American Dept. of Defense, it's likely that the specification may diverge from our needs, and of course, we'll have absolutely no input whatsoever into its development. AAArrrggghhh! Well, at least I feel better now that I've vented. I may end up recanting my rejection of CAN Aerospace. I still feel it's incomplete, but it is very simple and the finer points could probably be ironed out with the designer quickly. Does anyone have any idea where we go from here? Throwing my hands up in frustration, -Matt ________________________________________________________________________________
Date: Dec 31, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: Protocols
Matthew Mucker wrote: > > Each of these has drawbacks, right? I haven't even looked at ARINC, because > it costs $$$ just to get the specs. I was the first to say CAN Aerospace > doesn't seem up to the task. And I just can't make any sense of CDA101 and > CAN Kingdom. Also, since CDA101 is driven by the American Dept. of Defense, > it's likely that the specification may diverge from our needs, and of > course, we'll have absolutely no input whatsoever into its development. > Matthew, The CAN Kingdom site can be really hard to navigate, so some of the good stuff, I've discovered, is REALLY hard to find. Try the link below. Does this help to paint a better picture? It's more general than the PDF documents, but it shows how it all ties together. http://www.kvaser.se/canking/std/index.htm Marlin ________________________________________________________________________________
Date: Jan 03, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: more buss activity
The January issue of Avionics has an article about databuses titled "Faster Databus, The Holy Grail." For those of you who feel that Ethernet is insufficiently deterministic I quote from the article: ... Rockwell Collins made news, having its Large-Format Display System (LFDS), with Ethernet technology, on Boeing's 767-400ER. The 767-400ER is the "first application of Ethernet to host flight-critical information," says Vern Jackson, Collins' director of new Boeing programs. The 10-Mbit/s network is designated "full duplex," which means that data can flow simultaneously at that speed in each direction. ... On the LFDS, the Ethernet connects the display system's primary line replacable units (LRUs) -- display units, processing computers, and data concentrator units -- in a triple-redundant configuration, [Scott Marston] says. The fact that Etherent technology, though for non-essential functions, has been implemented on the B777 since the airplane's certification in 1995, "is one reason it was seen as a mature standard for the 767-400ER." The new network carries primary flight data, engine instruments and crew alerting data, and systems status information, says Rockwell Collins. This seems to imply that perhaps the FAA would be more accepting of Ethernet that we had originally considered. It might be worthwhile to see if we can get information about high-level protocols out of Boeing. Just between you, me, and the lampost, I really like Ethernet. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Jan 03, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: more buss activity
I should have read further before posting. Here is more from the article in "Avionics": Collins' development of Ethernet reflects the company's desire to take commercial standards and leverage the investment their development represents, rather than defining another avionics industry-specific bus. "We see an avionics system LAN -- based on full-duplex Ethernet -- as part of our core offering, allowing common building blocks across military, commercial, and regional business areas," Jackson says. Using Ethernet in an avionics context is different from using [ARINC-]629, Marston explains. "When tight timing and reliability requirements are placed on an Ethernet system, it is up to the applications connected to the Ethernet bus to implement handshake protocols and timing constraints." The LFDS uses a modified version of UDP/IP, combined with traditional avionics "presence and validity" algorithms, to address these requirments, he says. It goes on to talk about using ARINC-629 for the flight control system where they don't want to implement the data transfer protocols in software. It also says that they are using IEEE 802.1D based switched Ethernet hubs. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CDA101/CAN Kingdom update
Date: Jan 04, 2000
Gentlemen, I had a nice conversation with David Purdy today concerning CAN, CAN Kingdom hardware and software etc. You may want to reread my Dec 10 99 EMail. He also mailed the following (my additional comments start with ///): > -----Original Message----- > From: Livingston John W Civ ASC/ENFD [SMTP:John.Livingston(at)wpafb.af.mil] > Sent: Monday, January 03, 2000 9:51 AM > To: 'Purdy, Dave' > Subject: RE: CDA101 Status > > Dave Purdy, > > Thank you for the EMail. I appreciate the effort. A have a few more > questions if its not to much of a bother. > > 1) Any estimate (ROM) on the web sight launch? [Purdy, Dave] Hopefully, end of the month. > 2) You mentioned a CD. What is on it? How do I get one? Can the contents > be > freely distributed? Does it include software source? [Purdy, Dave] Send me your address and I will send one. You can distribute the contents. It has software /// Needless to say I'm going to get this CD. I don't know if Dave wants to copy these for all who might want them, so let me get a copy from him and I'll ask how we should proceed. The software includes the source code for the ST2000 boat. Dave said it also contained some circuit board layouts. See the report on the ST2000 on the Kvaser site. > That would help alot. > Since we are all new to CAN and CAN Kingdom, example architecture and code > is really important. Reading specs is ok, but most feel better looking at > real hardware and software implementations that have been shown to work > (like your ST2000). > 3) What does the class cover, and where is it held? [Purdy, Dave] Class covers, CDA 101, CAN, and CAN Kingdom. We start at a high level then cover CAN in detail and CAN Kingdom in detail. It lasts three days and half the time is hands on in labs and includes programming your own node. ///I'd love to go to this class but it is not in my neighborhood. > 4) Do you have a POC that could give us some advice on hardware selection? > There seems to be numerous devices being debuted on the net, but many are > not available. Someone with first hand experience with some of these > devices would be very useful. [Purdy, Dave] I suggest Lars-Berno Fredriksson (lbf(at)kvaser.se) or Kent Lennartson (kent(at)kvaser.se). These are the founders of Kvaser and would have some good insight as to what is out there. Kent is the more hands on one but Lars-Berno might /// During our phone conversation Dave suggested the 16 bit C167CR (same one they used in the ST2000) as an available, flexible chip. A newer C167CS version has 2 CAN controllers and flash. Numerous people have dev. boards available. For low cost and availability of free compilers he suggested Microchip's PIC and CAN controller. He also mentioned 7055, MPC555, 8051 processors. > Thanks for the help. CDA101 and your development activities continue to > be a strong candidate for our architecture, but alot depends on > availability > of CAN hardware and CAN Kingdon/CDA101 software. > > John W Livingston ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: No activity?
Date: Jan 05, 2000
Anyone out there? Am I still connected to the avionics list? ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: No activity?
Date: Jan 05, 2000
> > >Anyone out there? Am I still connected to the avionics list? Yep. Yep. Been pretty quiet... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Jan 05, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: No activity?
> >Anyone out there? Am I still connected to the avionics list? Yes. There has been no activity. There was great silence in response to my info WRT ethernet as well. I guess people are still recovering from New Year's eve. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Rob Luce" <robluce1(at)yahoo.com>
Subject: Re: No activity?
Date: Jan 05, 2000
If you don't mind one of the trollers responding. You guys are at a deadlock. The list would pick back up if you just made a decision and went with it. CAN/422/Ethernet, just pick one and start a design. As my hero Linus would say "Show me the code". Frankly, I'd think you'd want to figure out which software tools (CAD/Testing) you are going to use, and start designing as passing them around. Spice anyone? And don't take 2 months (which is how long it's taken to get to this point), pick the tool and go. Start the design and put it out. (Someone who should have stayed in the background with his meager electronics and software skills) Rob ----- Original Message ----- From: Brian Lloyd <brian(at)lloyd.com> Sent: Wednesday, January 05, 2000 4:18 PM Subject: RE: Avionics-List: No activity? > > > > > >Anyone out there? Am I still connected to the avionics list? > > Yes. There has been no activity. There was great silence in response to > my info WRT ethernet as well. I guess people are still recovering from New > Year's eve. > > > Brian Lloyd Lucent Technologies > brian(at)lloyd.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6513 - voice +1.530.676.3442 - fax > > ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: No activity? (CAN/Etherenet, software devel)
Date: Jan 06, 2000
Time to shake things up again... >> Yes. There has been no activity. There was great silence in >> response to my info WRT ethernet as well. I guess people >> are still recovering from New Year's eve. > >(Someone who should have stayed in the background with his meager >electronics and software skills) On the contrary... you have perhaps given us a bit better focus than we've had as of late... sometyhing I probably should be doing... :-) >If you don't mind one of the trollers responding. You guys are >at a deadlock. The list would pick back up if you just made a >decision and went with it. CAN/422/Ethernet, just pick one and >start a design. Rob's right... so let's put this to bed and move on... I am still leaning towards CAN over Ethernet... it is something that we know can be interfaced with, or is even included/intergrated with, various microcontrollers. This is something that can be easily integrated into the little black boxes. Can Ethernet be hooked up to these micros? I would think that the size of the ethernet frames alone (1500 bytes, right?) may force us to have more capable CPU's (maybe) and more RAM in each individual black box than we originally intended. Also, CAN seems to perhaps be more easily implemented, being integrated on some of the the micros, or a single external chip... Ethernet would also require hubs to be installed... a decent full duplex switching hub costs $$$... I have not found a standard hub which I would trust my life to... certainly not those cheap-ass linksys or (God forbid) generic hubs (which some people may be inclined to use, given their price). And what are the environmental requirements for these hubs? I would imagine that they would not be relaible in extremes of heat and cold (not *too* extreme here, but a plane in the sun in the summer gets pretty damn hot, and we all know what winter's like...). Of course, we are not carrying the flight controls on this bus, so some of these points may not be all that important... at least for a VFR only panel... There are already various messaging schemes and HLP's for CAN, some even specific to aviation... I would think that we would be rolling our own if we went with Ethernet. I doubt that we can get Boeing's protocols, and even if we did, they are probably way more involved than we would want or need... K.I.S.S. Please feel free to blow holes in my ideas and/or the assumptions that it's based on. Let's decide and move on. >Frankly, I'd think you'd want to figure out which software tools >(CAD/Testing) you are going to use, and start designing as >passing them around. Spice anyone? And don't take 2 months >(which is how long it's taken to get to this point), pick the tool >and go. Start the design and put it out. OK.... help? Anyone? I would think that this would be entirely dependent upon what hardware/processor is selected, and there may be more than one platform selected for different parts of the project... The development environment for a PIC (simple black box) would be quite different form what we would use for the development of the GUI for a PC display module (probably an x86 or equivalent, PC/104 or other SBC with VGA controller?). Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Jan 06, 2000
From: Quilters Confectionery <qltconf(at)earthlink.net>
Subject: Re: Avionics-List Digest: 01/05/00
Hi, Name here is Larry. I have a Hurricane Ultralight. My Avionics consist of a GPS ICOM Handheld, Beacon and a EIS (LOVE THAT). I have been busy moving but hope to get started on a Zenair 701 by the summer. Fly about 100 hours a year. Been a ham for 50 years. Current call is K4LLQ. Usually build lots of stuff. Have the set up to go from board design to finished product. Do the board layout manually. Most of my ham time is spent on digital HF and MARS I have a Narco 730 Handheld that has an intermittent display. Does any one know where I can get a schematic for that? I agree this list is rather slow. Happy Landings, Larry EAA, USUA ________________________________________________________________________________
From: RobertR237(at)aol.com
Date: Jan 06, 2000
Subject: Re: No activity? (CAN/Etherenet, software devel)
In a message dated 1/6/00 7:14:12 AM Central Standard Time, steve(at)tzogon.com writes: > > There are already various messaging schemes and HLP's for CAN, some even > specific to aviation... I would think that we would be rolling our own if > we went with Ethernet. I doubt that we can get Boeing's protocols, and > even if we did, they are probably way more involved than we would want or > need... K.I.S.S. > > Please feel free to blow holes in my ideas and/or the assumptions that > it's based on. Let's decide and move on. > > I don't know how the rest of the lurkers feel about this but I would like to put a major emphasis on the KISS part of your statements. This whole discussion has been getting far too complex to produce a simple and affordable system that most of us could put together. If this project is to be successful it needs to use readily available off the shelf and proven hardware and software. So PLEASE, Keep It Simple for the Stupid amongst you. PS: I count myself in the stupid group even though I have been producing computer code for over 35 years. I have used everything from machine language, ALC, JOVIAL, Fortran, COBOL, C, C++, Java, and a host of other high and low level languages. I have been an independent systems and computer consultant for the last 20 years and currently on contract to a major oil company. Bob Reed, KIS Cruiser in Progress...http://robertr237.virtualave.net/ ________________________________________________________________________________
Date: Jan 06, 2000
From: dab(at)froghouse.org
Subject: No activity?
On 5 Jan, Livingston John W Civ ASC/ENFD wrote: > > Anyone out there? Am I still connected to the avionics list? I'm still around, just got busy with an assortment of other things like getting the Internet into my new home and then wiring that home with ethernet (still working on that one). I've been meaning to try and catch up with the High Level Protocol docs Marlin has pointed us to and then make comments on those. My inclination is to just use CAN as is and write my own high level stuff but Marlin found that paper which argues why we should use something and I don't feel I should say much until I've at least read it. And I don't understand CAN Kingdom or CAN Aero at all. -Dave ________________________________________________________________________________
Date: Jan 06, 2000
From: dab(at)froghouse.org
Subject: Re: No activity? (CAN/Etherenet, software devel)
On 6 Jan, Steven J. Devine wrote: > I am still leaning towards CAN over Ethernet... That's my opinion as well. I've looked for ethernets attached to small microprocessors and haven't found any. An 80188 seems about the smallest processor I've seen with an ethernet attached. Now some people have reported difficulty finding actual instances of these wonderful CAN capable chips that we find described on the web. If CAN urns out to be illusory, I'd change that opinion. > There are already various messaging schemes and HLP's for CAN, some > even specific to aviation... I would think that we would be rolling > our own if we went with Ethernet. I doubt that we can get Boeing's > protocols, and even if we did, they are probably way more involved > than we would want or need... I'm not in the least bit put off by rolling my own protocol. I may end up arguing that we do that for CAN anyway. And whether we do our own protocol on CAN or use one of the predefined ones, I suspect that it'd be really easy to move that over to ethernet if we so chose. In fact, like Brian has suggested a few times, we can even run it over the Internet for testing. > K.I.S.S. This is why I may argue for doing our own HLP. >>Frankly, I'd think you'd want to figure out which software tools >>(CAD/Testing) you are going to use, and start designing as >>passing them around. Spice anyone? And don't take 2 months >>(which is how long it's taken to get to this point), pick the tool >>and go. Start the design and put it out. > > OK.... help? Anyone? Well, I've laid out my suggestions on hardware. And we've had one response that says PICs are too wimpy. I still think the idea of a microcontroller with some analog inputs, a CAN bus, and a serial port is a good one. That one device, with different software loads, can be a sensor module, an interface to existing serial devices (like a GPS), and a bridge from the CAN bus to a laptop or SBC with a display that we can develop the MFD on. Also a bridge to a desktop machine where we can run simulators of various sorts, test suites, or a tunnel over the Internet to other experimenters. The choice of development software will follow the chocie of processor. -Dave ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: No activity? (CAN/Etherenet, software devel)
Date: Jan 06, 2000
>I'm not in the least bit put off by rolling my own protocol. I may >end up arguing that we do that for CAN anyway. > >> K.I.S.S. > >This is why I may argue for doing our own HLP. Well, we could also use the CAN Kindom architecture, and just add custom messages (instead of rolling the entire project from scratch), for example... I'm not convinced that the existing protocols fit either... that's nect on the agenda once we finailze the CAN decision (which I believe that we're pretty close to doing). >And whether we do our own protocol on CAN or use one of >the predefined ones, I suspect that it'd be really easy to move >that over to ethernet if we so chose. > >In fact, like Brian has suggested a few times, we can even run >it over the Internet for testing. Well, if we are coding our messages under the assumption that CAN only allows us 8 bytes of data, then a 1500 byte frame would be an awful waste if we were to change over to Ethernet and run it as-is... some amount of conversion would be required... For testing, I would lean towards getting a CAN card for a PC, or more likely making/buying a CAN-2-RS232 interface device... that way, I could test the black box either in the home (for development testing) and then install a black box in my truck for longer term testing using a laptop (ie hooked up to the engine for CHT, tach, water temp/pressure, oil temp/pressure, etc., or install a pitot-static system). Ideally, for testing, we would have a PC running as some sort of data repository... one could collect real-world data (like in my truck, or actual aircraft data) and store it with a timestamp... this data can be stored, ftp'd, sent in e-mail, whatever, and replayed to transmit out the CAN bus at the same rate it was collected (using the timestamps)... also, the data can be manipulated or computer generated as needed to test conditions not represented in the actual captured data... Perhaps the PC can also have a CAN 2 IP utility to send test data over the net realtime as well... though this may not be of too much value (unless we got togetehr as a group for these debugging sessions)... perhaps it makes sense if you have more than one PC, but I would think that all the CAN devices would be connected together on the CAN bus, and one PC could be used to monitor the bus messages and such... >The choice of development software will follow the chocie of >processor. Agreed. Perhaps this comes a tiny bit later... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN Kingdom software development
Date: Jan 06, 2000
Steve and Folks, I hope to be recieving a CDA101 CD Rom containing ST2000 software(a CAN Kingdom implementation in C) of a complete system. I am told that this is freely useable by us, and I believe we will be able to redistribute it as well. Why would we want to roll our own HLP? They would have to be pretty good reasons. If we find that the CDA101/CAN Kingdom software is too complex, then we can want to backing away from it and look at something like NMEA 2000/J1939 or CAN Aerospace. There won't be many custom messages to write. If you look at CDA101/12 you will see quite a list, and others are in NMEA2000. What is the preceived problem with the CDA101 CAN/Kingdom HLP anyway? It seems taylor made for our project, at least to me at this stage of the game. CAN is theee game in town right now. Automotive, industrial, marine all are using this. Automotive and industrial grade devise are available. Development boards are available. Free and low cost code and compilers are available.(by the way I think low cost and free compilers will determine our choice of cpu as much as anything). NASA/AGATE databus is the only strange abberation. ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: CAN software development
Date: Jan 06, 2000
>Steve and Folks, <> >Why would we want to roll our own HLP? They would have to be pretty >good reasons... I'm sorry... I do not mean to imply that I saw a reason *NOT* to use them... I agree, there better be just cause in going down this path. I have not looked closely enough at them to see a reason why they would not be applicable... I personally liked the CAN aerospace implementation. But, I am certainly not against rolling our own protocol if needed. (trying to remain impartial as I did nore review the documentation enough to have a STRONG opinion on the matter). >CAN is theee game in town right now. Automotive, industrial, marine all >are using this. Automotive and industrial grade devise are available. That is a *VERY* good reason to use CAN! Let's put this to bed right now... is there ****ANYONE*** out there who has a reason NOT to use CAN? >Development boards are available. Free and low cost code and >compilers are available.(by the way I think low cost and free compilers >will determine our choice of cpu as much as anything). I was not aware of the compilers (or marginally so, I remember sample source code being mentioned). That *DOES* give us a direction to go to for the processors... >NASA/AGATE databus is the only strange abberation. So let's ignore them and stay on track. Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: No activity? (CAN/Etherenet, software devel)
Date: Jan 06, 2000
Hi Guys, Guess I should jump in here. The CAN chips are out there, but they are not going to turn up at your local Radio Shack (or even Digi-Key). As I've mentioned before, I'm currently working on an unrelated project with somewhat similar networking requirements. I've come to the conclusion that CAN is the way to go. I have moved on to chip selection. So far my chip of choice is the Fujitsu MD90F543. (see http://www.fujitsu-fme.com/products/micro/can/09.html ) I have received from Fujitsu a CDROM with all the manuals, data sheets, etc. I also have the Fujitsu IDE with C compiler, debugger, etc. I haven't had time to play with it too much, but other than having a toy editor, it looks to be up to the task. OBTW, it's free. The chips are real. The problem I'm running into with getting samples is, I think, related to the impression many have that these things are vapor ware: CAN has been, so far, mostly a European thing. It was developed by Bosch for automotive applications. The chip vendors are mostly European firms. (Philips and Seimens are the big players). Even the division of Fujitsu I've been dealing with is based in Frankfurt. European distributors seem to carry the parts, but they can't sell to the US. The US distributors have never heard of them. The only significant US demand, so far, seems to be from the automotive industry, and they don't buy from distributors. I'm still working at getting my hands on some real parts. You guys will be among the first to know when I have them. I know the pace at which this is proceeding seems somewhat snail like to many, particularly those who have never done real hardware design before. Working with chip vendors just take a lot of patience, sometimes. Regarding higher level protocol layers: I still haven't absorbed the CAN Kingdom spec well enough to form an opinion. Hopefully next week, when I'm house sitting in the middle of nowhere, I'll correct that. If CAN Kingdom, etc. turns out to not fit well, I am, as Dave said: "not in the least bit put off by rolling my own protocol". On the other hand, I'm not hot to reinvent any wheels that we can just plagiarize. I think it's wise to exercise originality very selectively. That brings up an issue I have been pondering: Do to the nature of this group, there is a wide range of experience levels represented, both quantitatively and qualitatively. In general that's a good thing. It can, however, be an impediment to clear communication. Some of us make some unstated assumptions about what sort of things we can do. It's the "been there, done that" effect. For example, Dave and I (and, I think, Brian) are not intimidated by protocol design. Others of you, I suspect, think we're nuts to suggest it. Similarly, I have been thinking all along in terms of buying chips and doing our own board design. I'm sure those with little hardware design experience find that somewhat daunting. I think this has led to some lack of consensus regarding the scope of this project. IMHO we need to settle some of these scope and goals issues soon if we are to maintain any sort of cohesiveness. To put that another way: We shouldn't expect to get too far on the "how" until we get an answer to the question of "what" that most are comfortable with. If too many folks start to feel we are getting in over our heads they will start to "vote with their feet" and this will collapse. Gee, I've been long winded again, haven't I? Later, Jeff > > >Now some people have reported difficulty finding actual instances of >these wonderful CAN capable chips that we find described on the web. >If CAN urns out to be illusory, I'd change that opinion. > >I'm not in the least bit put off by rolling my own protocol. I may >end up arguing that we do that for CAN anyway. And whether we do our >own protocol on CAN or use one of the predefined ones, I suspect that >it'd be really easy to move that over to ethernet if we so chose. > >In fact, like Brian has suggested a few times, we can even run it over >the Internet for testing. > >Well, I've laid out my suggestions on hardware. And we've had one >response that says PICs are too wimpy. I still think the idea of a >microcontroller with some analog inputs, a CAN bus, and a serial port >is a good one. That one device, with different software loads, can be >a sensor module, an interface to existing serial devices (like a GPS), >and a bridge from the CAN bus to a laptop or SBC with a display that >we can develop the MFD on. Also a bridge to a desktop machine where >we can run simulators of various sorts, test suites, or a tunnel over >the Internet to other experimenters. > >The choice of development software will follow the chocie of >processor. > > -Dave ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: RE Jeff
Date: Jan 06, 2000
Jeff, All, I can't agree more. Good summary of the current situation. I have been reading the CDA101/CAN Kingdom docs and to date see know reason not to go this way. I am only waiting for example software of a complete system before making up my mind. As soon as I get this I will pass it on. I think we shuould all look at this code before making up our minds about a HLP. Specs are OK but looking at code makes it more tangible. The largest advantage of the CDA101/CAN Kingdom approach is that is allows individual modules to be designed without any knowledge as to how they will be used in a system. Other CAN HLPs predefine the CAN IDs and so doing predefine their relative priorites. CDA101/CAN Kingdom allows the system designer to assign IDs and hence priorities and behavior(Kings messages) of the modules(cities). Do you know why the European distributers can sell the USA? I hope that we may eventually offer compilers, software and hardware kits (or at least point them towards sources of these) to get people started. This would include how to manuals and plenty of examples for various types of modules/nodes. OBTW does anyone know what a compiler for the Infineon C167CR/CS processors costs? John ________________________________________________________________________________
Date: Jan 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: No activity? (CAN/Etherenet, software devel)
> >>In fact, like Brian has suggested a few times, we can even run >>it over the Internet for testing. > >Well, if we are coding our messages under the assumption that CAN only >allows us 8 bytes of data, then a 1500 byte frame would be an awful waste >if we were to change over to Ethernet and run it as-is... some amount of >conversion would be required... Ethernet frame payload varies in length between 64 and 1500 bytes. You send only as much as you need so long as the payload is at least 64 bytes long. The DIX ethernet frame format (original, simplest, and most commonly used) has an 8-byte preamble, a 6-byte destination address, a 6-byte source address, two bytes for protocol ID, the payload (64-1500 bytes), and a trailing 4-byte CRC. If you want to set an upper bound on message size that is not a problem. As for whether or not you can interface it, it depends on the processor. If the Ethernet chip is double-buffered internally, you don't need DMA. The chip can buffer the received frame (or the frame to be transmitted for that matter) letting the processor use an I/O polling loop to move the bits across the processor's buss. It really isn't all that difficult or complex. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Jan 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN software development
>That is a *VERY* good reason to use CAN! > >Let's put this to bed right now... is there ****ANYONE*** out there who >has a reason NOT to use CAN? If it works there is no reason to say that it cannot be used. That does not mean that it is optimal either. I have always preferred Ethernet over most LANs since virtually the whole low-level transport is implemented in silicon and doesn't require us to do a whole lot to make it work. Sure you might want to layer something over it but, again, that is also a done deal. I do think that it is telling that Boeing, Airbus, and Rockwell/Collins have adopted Ethernet. It also means that, for development, you probably already have the hardware you need. Hubs are in the $30 range now. Silicon is available now. It is a whole bunch more mature than CAN. Consider that your data source, some sort of engine monitor in this case, just decides to send something without benefit of any higher protocol. It crams the data it wants to send into the Ethernet chip along with the protocol ID and destination address (usually a broadcast or multicast address) and says, "send it." Odds are VERY high that it will get to where it is going if where it is going is still alive. Oh, and it does 10 Mbps or 100 Mbps. This lets me think about things like audio over the network too. This begins to get interesting when doing avionics systems. I am back to thinking about a common set of messages that are relatively independent of the underlying transport, be it CAN or Ethernet. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: RE Jeff
Date: Jan 06, 2000
John, Distributors have contractual agreements with regard to territorial boundaries, etc. I don't know (or care about) the details. It's a pain, but all I can do is try to cope. Fujitsu seems to be more generous with development software than most. That's part of the appeal of using their chips. The other part is a very nice architecture for compiled code and multi tasking. All the C166/7 series compilers that I'm aware of are in the $x000 range. I have not found a GPP port for them, either. That notwithstanding, they are probably my second choice CPU. Later > >Jeff, All, > > Do you know why the European distributers can sell the USA? > > I hope that we may eventually offer compilers, software and hardware kits >(or at least point them towards sources of these) to get people started. >This would include how to manuals and plenty of examples for various types >of modules/nodes. > > OBTW does anyone know what a compiler for the Infineon C167CR/CS >processors costs? > >John ________________________________________________________________________________
Date: Jan 06, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: No activity? (CAN/Etherenet, software devel)
Jeff Barlow wrote: > European distributors seem to carry the parts, but they > can't sell to the US. The US distributors have never heard > of them. The only significant US demand, so far, seems to be > from the automotive industry, and they don't buy from > distributors. That's OK, we're not a US group, we're a global coalition. We've got addresses in Australia even, FCOL! Marlin ________________________________________________________________________________
Date: Jan 06, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Anticipating Technical Issues
I was talking to an automotive engineer friend of mine about CAN and such and he told me that having a single module receiving inputs from several sensors is problematic from the standpoint of RF noise. This is because the sensors lines are low voltage and susceptible to all kinds of RF interference effects. I bring this up now because we are beginning to make decisions on CAN MCUs. Some of these MCUs, I note, have a good number of A/D converters. Can we be sure that we can get good clean signals coming in to those A/D ports? Marlin ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: Anticipating Technical Issues
Date: Jan 06, 2000
Marlin, I basically agree with your automotive engineer friend. This is an issue that I expect to spend a lot of time working on. It's what one would call real world engineering. I would expect an automotive engineer to raise this issue, since the under hood environment is one of the most unfriendly for anything electronic. Just like the firewall forward in an aircraft. I'm not quite sure what point you are trying to make, though. When you say: "having a single module receiving inputs from several sensors is problematic from the standpoint of RF noise", I find myself asking: "as opposed to what"? The available sensors produce the signals they produce. The engine ignition system generates a lot of noise. These are the givens. So, what else is new? Am I missing something here? Is the point that you are expressing some doubt about our ability to solve these kinds of problems? Is this an example of the sort of thing I was addressing at the end of my earlier, long winded post? Jeff > >I was talking to an automotive engineer friend of mine about CAN and >such and he told me that having a single module receiving inputs from >several sensors is problematic from the standpoint of RF noise. This is >because the sensors lines are low voltage and susceptible to all kinds >of RF interference effects. > >I bring this up now because we are beginning to make decisions on CAN >MCUs. Some of these MCUs, I note, have a good number of A/D >converters. Can we be sure that we can get good clean signals coming in >to those A/D ports? > >Marlin > ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: CAN software development
Date: Jan 06, 2000
Brian, Optimal?! When did that become a requirement? Are you placing a vote in favor of using Ethernet rather than CAN? Or are you just playing devil's advocate? I should point out that Ethernet has not been a bus at all since we stopped using the old, Bob Metcalf, coax-the-size-of-garden-hose, flavor. 10baseT is a star, when the hub dies the whole thing goes down. Not good. You say "Silicon is available now". Give me details. I know of three different microcontrollers with two built in CAN controllers. I know of none with even one Ethernet port. Jeff > >>That is a *VERY* good reason to use CAN! >> >>Let's put this to bed right now... is there ****ANYONE*** out there who >>has a reason NOT to use CAN? > >If it works there is no reason to say that it cannot be used. That does >not mean that it is optimal either. > >I have always preferred Ethernet over most LANs since virtually the whole >low-level transport is implemented in silicon and doesn't require us to do >a whole lot to make it work. Sure you might want to layer something over >it but, again, that is also a done deal. I do think that it is telling >that Boeing, Airbus, and Rockwell/Collins have adopted Ethernet. It also >means that, for development, you probably already have the hardware you >need. Hubs are in the $30 range now. Silicon is available now. It is a >whole bunch more mature than CAN. > >Consider that your data source, some sort of engine monitor in this case, >just decides to send something without benefit of any higher protocol. It >crams the data it wants to send into the Ethernet chip along with the >protocol ID and destination address (usually a broadcast or multicast >address) and says, "send it." Odds are VERY high that it will get to where >it is going if where it is going is still alive. > >Oh, and it does 10 Mbps or 100 Mbps. This lets me think about things like >audio over the network too. This begins to get interesting when doing >avionics systems. > >I am back to thinking about a common set of messages that are relatively >independent of the underlying transport, be it CAN or Ethernet. > > >Brian Lloyd ________________________________________________________________________________
Date: Jan 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Anticipating Technical Issues
>I'm not quite sure what point you are trying to make, >though. When you say: "having a single module receiving >inputs from several sensors is problematic from the >standpoint of RF noise", I find myself asking: "as opposed >to what"? > >The available sensors produce the signals they produce. The >engine ignition system generates a lot of noise. These are >the givens. So, what else is new? And given that ignition systems in aircraft are usually fully shielded, I don't see that the environment is all that bad. Frankly, I would be much more concerned about grounding problems especially given the low signal levels of thermocouples. If you use a single-ended input, everything is referenced to ground. But which ground is that: the ground potential at the sensor box or at the engine (many thermocouples are already at ground potential because they have continuity to their casing)? One way around that is to use ungrounded probes but now you have more of a problem with noise pickup. What it boils down to is to know when to use differential inputs (best with low signal levels and unknown ground potential) and when to use single-ended inputs. You also have to give a lot of thought to input protection and input conditioning. You need to make sure that you clamp potentially damaging currents and voltages. If you have signals that change very slowly, you can filter the heck out of them and not worry about noise. There is still a lot of analog stuff we need to deal with but those kinds of problems have been around for a long, long time and are pretty well understood. For instance you want to fuse current inputs (high impedance source with a low impedance sink). Voltage inputs (high impedance) should have series resistors to limit input current and diode clamps to the power rails. You also want ferrite beads and inductors with bypass caps to get rid of the RF hash and trash. Even so, it isn't difficult to do if you are willing to spend the money. : ) Don't be surprised if your analog input conditioning hardware costs more than the digital hardware you are protecting. Think of it in terms of providing improved system reliability. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Jan 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN software development
> >Brian, > >Optimal?! When did that become a requirement? I can always hope to have my cake and eat it too. ; ) >Are you placing a vote in favor of using Ethernet rather >than CAN? Or are you just playing devil's advocate? I have always preferred Ethernet but I can probably live with CAN. >I should point out that Ethernet has not been a bus at all >since we stopped using the old, Bob Metcalf, >coax-the-size-of-garden-hose, flavor. You forget 10base2 using RG-58. That is only the size of a pencil. ; ) >10baseT is a star, Yes and that is not necessarily bad. >when the hub dies the whole thing goes down. Not good. And when a CAN talker wigs out and jams the whole buss that isn't good either. My ethernet hub chip will automatically partition off a source that is jabbering (jamming the buss). If you get a CAN talker doing that you are hosed. Pure are simple but more prone to total failure. So which failure mode is more likely? With 10/100bT Ethernet you are faced with only one point of failure, i.e. the hub chip. With the CAN buss you are faced with multiple points of failure, i.e. every buss driver. Consider tho' that, given that the failure rate for a CAN buss driver is the same as the failure rate for an ethernet hub chip, the system failure rate will be lower with ethernet since I have fewer hub chips that can fail. >You say "Silicon is available now". Give me details. I know >of three different microcontrollers with two built in CAN >controllers. I know of none with even one Ethernet port. I didn't say that you could find a microcontroller with a built in Ethernet (actually the Mot 68360 has built-in Ethernet but the price of the chip way too high), just that silicon is available. There are scads of ethernet interface chips out there with all kinds of processor buss interfaces. Take your pick. Most have been around for awhile so they have reached the bottom of the price curve. So your box has two chips in it, processor and ethernet, so what? You got real estate problems? One nice thing about keeping the processor and buss interface separate is that you get to pick the processor you really like. I used to be partial to building dedicated systems using the Motorola 6800 (yes, I did do that sort of thing 20 years ago) and I kinda took it for granted that I would be gluing multiple chips together. And, no, I am not trying to start a fight or an argument. I just happen to still like Ethernet. Ask Dave. I have been trying to cram Ethernet down his throat as an avionics buss for years. I let it slide because I figured the the FAA would never go for something like Ethernet even tho' there is more experience with that networking technology. Now I learn that the big guys are going for Ethernet. I betcha they have studied all the failure scenarios and now there are commercial aircraft, i.e. the B-777 and AirBus 340, flying with Ethernet carrying mission-critical flight data. This tells us two things about Ethernet: it has been tested within a mm of its life and the FAA believes it is OK to use. That can't hurt acceptance. But all that aside, why would we have to choose one over the other? If you do a CAN/Ethernet gateway you can you either or both. All you need then is a common message format, an "internet protocol" if you will. I used to argue with Dave that we only need one buss and he suggested that we ought to build something that can interface with other things that are already out there. This also implies to me that, at some point in time, we will want gateways to the various ARINC busses as well. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Sten Svensson" <sten(at)stonab.se>
Subject: European components
Date: Jan 07, 2000
Hi, I can! I live in Sweden, that's Europe isn't it :-), and I'll be happy to get you anything you may need! I've been lurking on this list for a while and have no skills, not already demonstrated by others on the list, to contribute but will gladly help with purchasing in Europe. I own a company that is registered with several distributors of components and should be able to get pretty decent prices, at least by European measures. SM7GDM, but QRT for years... Regards Sten Svensson ******************************** > Jeff Barlow wrote: > European distributors seem to carry the parts, but they > can't sell to the US. The US distributors have never heard > of them. The only significant US demand, so far, seems to be > from the automotive industry, and they don't buy from > distributors. ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN vs Ethernet
Date: Jan 07, 2000
Brian, All, Nothing lasts forever (heck, in digital electronics 5 years is a very long time), but I believe we will be more successful pursuing a CAN bus in the near future primarily do to momentum, availability of hardware and software and experience of a large community of users concentrating on CAN and its application to systems with similar requirements to ours. Ethernet solutions may well be technically better, particularly when people get done optimizing there use for dedicated control oriented applications(addition of global clock signals etc). Dave Purdies group (and obviously others) is currently starting work in this area now. The problem is that these efforts are not far enough along or open enough for us to take advantage of them in the very near future. I surely hope we continue to track these efforts (along with AGATES LonTalk), but right now to me they appear too remote and closed with a limited community of users. ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Jan 07, 2000
Subject: Re: Avionics-List Digest: 01/05/00
> The list would pick back up if you just made a decision and went with it. CAN/422/Ethernet, just pick one and start a design. I had earlier reported great difficulty getting any parts to do my CAN project. I am happy to report that persistance paid off, and I have been able to locate the Microchip MCP2510 CAN controller, which I intend to connect to an Atmel AVR microcontroller. TI also came through, and I may switch - though I am concerned about the cost of the software tools with the TI part (TMS320F241, about $16 in small qtys, a bargain considering its features and performance). Motorola and Fujitsu both get an "F", for failure to respond with meaningful info. TI would also have got an "F", except that I know someone and was able to pull some strings. The Atmel web site is so good that I have not had any reason to call them. If there is group consensus before I get too far along on my hobby project, I'll probably switch to whatever everyone else is going to use. I might even be able to contribute something useful... Anyway, I still vote for CAN, if I get to vote. BTW, there is an article in the Jan. issue of Circuit Cellar about a CAN experiment. I've not yet seen it, so don't know how useful it might be. cheers, g. ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: European components
Date: Jan 07, 2000
Hi, Sten, Thanks for the offer. I haven't given up on the local sources yet, but I may get desperate. I have a few Swedish friends who live here in California, so I've heard all the stories about prices and taxes over there. :-) If you get a chance can you check on the price of the Fujitsu MB90F543 chip over there? The distributors in Sweden are: EBV Elektronik GmbH Derbyvgen 20, S-21235 Malm Phone: 0 40 59 21-00 Fax: 0 40 59 21-01 EBV Elektronik GmbH Sjngsvgen 17 S-19272 Sollentuna Phone: 08 59 47 02 30 Fax: 08 59 47 02 31 Thanks a lot Jeff > >Hi, > >I can! I live in Sweden, that's Europe isn't it :-), and I'll be happy to get you anything you may need! > >I've been lurking on this list for a while and have no skills, not already demonstrated by others on the list, to contribute but will gladly help with purchasing in Europe. I own a company that is registered with several distributors of components and should be able to get pretty decent prices, at least by European measures. > >SM7GDM, but QRT for years... > >Regards > >Sten Svensson > ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: CAN vs Ethernet
Date: Jan 07, 2000
All, Ok, it looks to me as if it's been moved and seconded that we standardize on the CAN bus for our low level protocol layers. All in favor say aye, all opposed say nay. Let's put this to rest and move on. Jeff > >Brian, All, > > Nothing lasts forever (heck, in digital electronics 5 years is a very >long time), but I believe we will be more successful pursuing a CAN bus in >the near future primarily do to momentum, availability of hardware and >software and experience of a large community of users concentrating on CAN >and its application to systems with similar requirements to ours. Ethernet >solutions may well be technically better, particularly when people get done >optimizing there use for dedicated control oriented applications(addition of >global clock signals etc). Dave Purdies group (and obviously others) is >currently starting work in this area now. The problem is that these efforts >are not far enough along or open enough for us to take advantage of them in >the very near future. I surely hope we continue to track these efforts >(along with AGATES LonTalk), but right now to me they appear too remote and >closed with a limited community of users. > > ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Aye CAN
Date: Jan 07, 2000
>Ok, it looks to me as if it's been moved and seconded that >we standardize on the CAN bus for our low level protocol >layers. All in favor say aye, all opposed say nay. Let's put >this to rest and move on. Aye. Steve ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: CAN vs Ethernet
Date: Jan 07, 2000
All, I'll be out of town (way out of town) for about a week and a half. I may or may not have email access from there. If I seem to be ignoring you guys it's just that I can't on the net. Jeff ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Jan 07, 2000
Subject: Re: Avionics-List Digest: 01/06/00
>Well, I've laid out my suggestions on hardware. And we've had one response that says PICs are too wimpy. I still think the idea of a microcontroller with some analog inputs, a CAN bus, and a serial port is a good one. That one device, with different software loads, can be a sensor module, an interface to existing serial devices (like a GPS), and a bridge from the CAN bus to a laptop or SBC with a display that we can develop the MFD on. That describes exactly my little hobby project. I surely would like to get some help with PC layout and fabrication... anyone interested? > I have moved on to chip selection. So far my chip of choice is the Fujitsu MD90F543. (see http://www.fujitsu-fme.com/products/micro/can/09.html ) >I have received from Fujitsu a CDROM with all the manuals, data sheets, etc. I also have the Fujitsu IDE with C compiler, debugger, etc. I haven't had time to play with it too much, but other than having a toy editor, it looks to be up to the task. OBTW, it's free. Sounds great, esp. the free compiler. However, after numerous phone calls I got exactly nowhere in trying to get parts. One of the requirements for my project is that I am able to get parts with minimum effort. Mine is not a commercial venture, I am just having fun. > OBTW does anyone know what a compiler for the Infineon C167CR/CS processors costs? I don't know, but I do know that the microcontroller costs far too much for my project. I want a little board with flash, CAN controller, transceiver, ADC, timer, RS-232 interface, at least 8 digital I/O lines, and a breadboard area for special stuff. The cost needs to be low, well under $100. If I do all the work (get parts, assemble, test, etc) I think I can build the nodes for less than $30 each. I plan to hook up a few nodes in my house first, to control lights, monitor my well pump, typical home automation stuff. If it all goes well, I plan to wire my sailboat - fuel and water quantities, engine RPM and temperatures, maybe a connection to the ham radio so I can check on things from home (100 miles from the boat). Some day, if the first experiments turn out well, I might wire my airplane. I am about to proceed with an AVR micro connected to a Microchip CAN controller. My AVR morse code keyer project turned out very well - parts cheap and easy to get, free software, it all went very smoothly. I hesitate to proceed for two reasons: 1) if the group suggests something else, I'd like to use it if it meets my requirements. 2) There is no way to reprogram the AVR over the CAN bus without additional hardware such as a 2nd AVR on the board. This is not really a requirement, but it would be nice. Someone has suggested that there are at least 3 micros with CAN built-in. I know of only two that I can actually order and get delivery on and that also have FLASH or EEPROM: the TI and the Infineon. Software for the TI is too expensive, and hardware for the Infineon is too expensive. Someone please add to the list if you know of anything (be sure you can actually get it before you tell me how great it is). Sorry if this is long-winded, but I really think that the hardware I want might work out well for this group, too. Maybe there are a few like-minded folks out there who would like to form a small group and split up the work. Working by myself it is going to be a long time (I'd rather go fly or sail than design stuff). g. ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Aye CAN
Date: Jan 07, 2000
Same here, CAN! ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Don't forget your CAN reading material
Date: Jan 07, 2000
Jeff, 1 copy of CAN 2.0B 1 copy of CAN Kingdom 3.01 1 copy of CDA101/01,11,12,41 Don't leave home with out them.:-) John ________________________________________________________________________________
From: Jeff Barlow <barlow(at)thegrid.net>
Subject: Re: Don't forget your CAN reading material
Date: Jan 07, 2000
John, I've already got them piled up next to my bags. Jeff > >Jeff, > >1 copy of CAN 2.0B >1 copy of CAN Kingdom 3.01 >1 copy of CDA101/01,11,12,41 > >Don't leave home with out them.:-) > >John > ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Don't forget your CAN reading material
Date: Jan 07, 2000
And CAN Aerospace as well... > -----Original Message----- > From: owner-avionics-list-server(at)matronics.com > [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Livingston > John W Civ ASC/ENFD > Sent: Friday, January 07, 2000 12:48 PM > To: 'avionics-list(at)matronics.com' > Subject: RE: Avionics-List: Don't forget your CAN reading material > > > ASC/ENFD > > Jeff, > > 1 copy of CAN 2.0B > 1 copy of CAN Kingdom 3.01 > 1 copy of CDA101/01,11,12,41 > > Don't leave home with out them.:-) > > John > > > > > > ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: Aye CAN
Date: Jan 07, 2000
Aye Marlin >From: "Steven J. Devine" <steve(at)tzogon.com> > >Aye. > >Steve ________________________________________________________________________________
From: "Rob Luce" <robluce1(at)yahoo.com>
Subject: Re: CAN vs Ethernet
Date: Jan 07, 2000
If a troller can vote: Aye. By the way, while I'm probably not much help in the hardware department, I wouldn't mind getting my hands into the coding of the front end (lots of experience there). Which is why I'm waiting for some schematics of this thing to start putting together. Rob ----- Original Message ----- From: Jeff Barlow <barlow(at)thegrid.net> Sent: Friday, January 07, 2000 11:12 AM Subject: Re: Avionics-List: CAN vs Ethernet > > All, > > Ok, it looks to me as if it's been moved and seconded that > we standardize on the CAN bus for our low level protocol > layers. All in favor say aye, all opposed say nay. Let's put > this to rest and move on. > > Jeff > > > > > >Brian, All, > > > > Nothing lasts forever (heck, in digital electronics 5 years is a very > >long time), but I believe we will be more successful pursuing a CAN bus in > >the near future primarily do to momentum, availability of hardware and > >software and experience of a large community of users concentrating on CAN > >and its application to systems with similar requirements to ours. Ethernet > >solutions may well be technically better, particularly when people get done > >optimizing there use for dedicated control oriented applications(addition of > >global clock signals etc). Dave Purdies group (and obviously others) is > >currently starting work in this area now. The problem is that these efforts > >are not far enough along or open enough for us to take advantage of them in > >the very near future. I surely hope we continue to track these efforts > >(along with AGATES LonTalk), but right now to me they appear too remote and > >closed with a limited community of users. > > > > > > ________________________________________________________________________________
From: "Sten Svensson" <sten(at)stonab.se>
Subject: European components
Date: Jan 08, 2000
No problem! Today is national holiday, so I'll give them a ring on Monday. Prices are usually OK over here, but you are unfortunately quite right about taxes. These are however deductible in commercial usage, so no problem in reasonable quantities. :-) I'll get back to you next week. Sten ************************************ ----- Original Message ----- From: Jeff Barlow <barlow(at)thegrid.net> Sent: Friday, January 07, 2000 6:06 PM Subject: Re: Avionics-List: European components > > Hi, Sten, > > Thanks for the offer. I haven't given up on the local > sources yet, but I may get desperate. > > I have a few Swedish friends who live here in California, so > I've heard all the stories about prices and taxes over > there. :-) > > If you get a chance can you check on the price of the > Fujitsu MB90F543 chip over there? The distributors in Sweden > are: > > EBV Elektronik GmbH > Derbyvgen 20, > S-21235 Malm > > Phone: 0 40 59 21-00 > Fax: 0 40 59 21-01 > > EBV Elektronik GmbH > Sjngsvgen 17 > S-19272 Sollentuna > > Phone: 08 59 47 02 30 > Fax: 08 59 47 02 31 > > Thanks a lot > > Jeff > > > > > >Hi, > > > >I can! I live in Sweden, that's Europe isn't it :-), and I'll be happy to get you anything you may need! > > > >I've been lurking on this list for a while and have no skills, not already demonstrated by others on the list, to contribute but will gladly help with purchasing in Europe. I own a company that is registered with several distributors of components and should be able to get pretty decent prices, at least by European measures. > > > >SM7GDM, but QRT for years... > > > >Regards > > > >Sten Svensson > > > > > > > ________________________________________________________________________________
Date: Jan 07, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN: 82527-Good idea or too retro?
Hi all, Well, I'm off to Bali for two weeks, so these will likely be my parting thoughts 'til I return. When I was a boy, we didn't have these fancy-shmancy CAN-on-a-microcontroller chips, No! We had to spend our lunch money and buy a chip that would talk to our microcontrollers :) Seriosly, what about the Intel 82527 chip? This chip does just the CAN and interfaces with the microcontroller serially. If these chips were easy to get ahold of, it would render much of the microcontroller availability issues moot. It is designed to work with 8 and 16 bit controllers. The advantage here is that we could buy a bulk of these and then everyone can buy their favorite microcontrollers according to their whim. Drawbacks: Adds a complexity to circuit design Adds to total cost per module (maybe not) There may be buffering issues between 82527 and controller. If so, is there a better "just CAN" chip? Marlin ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: RE: Avionics-List Digest: 01/07/00
Date: Jan 09, 2000
Aye - go with CAN Joe Hovel Senior Lecturer Centre for Rural Health & Centre of Medical Informatics Monash University =========================================== www.med.monash.edu.au/crh www.monash.edu.au/informatics > ________________________________________________________________________________
Date: Jan 09, 2000
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: CAN vs Ethernet
Jeff Barlow wrote: > Ok, it looks to me as if it's been moved and seconded that > we standardize on the CAN bus for our low level protocol > layers. All in favor say aye, all opposed say nay. Let's put > this to rest and move on. Aye. Frank van der Hulst. ________________________________________________________________________________
From: RobertR237(at)aol.com
Date: Jan 09, 2000
Subject: Re: CAN vs Ethernet
In a message dated 1/9/00 2:06:57 AM Central Standard Time, frankvdh(at)ihug.co.nz writes: > > Jeff Barlow wrote: > > Ok, it looks to me as if it's been moved and seconded that > > we standardize on the CAN bus for our low level protocol > > layers. All in favor say aye, all opposed say nay. Let's put > > this to rest and move on. > > Aye. > > Frank van der Hulst. > I will abstain from any vote but from all that I have been able to learn the CAN is not readily available and will end up costing far more than the Ethernet. Consider that the Ethernet is already built into many handheld and laptop units. This seems to go against the stated goal of keeping it simple and using off the shelf technology which is readily available. Bob Reed ________________________________________________________________________________
Date: Jan 09, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN vs Ethernet
Everyone seems to think that we must have one and only one transport. I disagree with this thinking. Just as with the Internet, there will probably be a need for more than one data transport. The Big Boys use multiple transports now, with the new ARINC-669 spec (I think, I don't have the spec number in front of me) being used for flight control systems and most everything else migrating to Ethernet (10 Mbps for Boeing and 100 Mbps for Airbus). The increased capacity would allow us to think about putting audio on there for a really slick audio panel. The sense of the group seems to be that CAN and Ethernet are somehow mutually exclusive. They aren't. The internet works by transporting a common set of messages, i.e. the Internet Protocol Suite otherwise known as TCP/IP, over many different transports including but not limited to Ethernet, token ring, FDDI, async PPP, sync PPP, T1, T3, ATM, OC-[3|12|48|192], various flavors of radio, etc. The key is the common message set. My view is that we end up with a common message set that will work over CAN, Ethernet, Lon, whatever. Now you can start with CAN for simple things but not eliminate more advanced applications. We just stick in a router that will speak CAN on one side and Ethernet on the other to allow compatibility between the two. So embracing CAN is not a problem in and of itself but failing to look at a common messaging protocol that will run above CAN/Ethernet/LON/whatever is shortsighted. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Rob Luce" <robluce1(at)yahoo.com>
Subject: Re: CAN vs Ethernet
Date: Jan 09, 2000
I believe that someone should actual design -something-, and the rest would follow along. While we're at it, why don't we start debating binder twine as a possible media for the PB project? Frankly, it doesn't matter, if someone has enough brains to put together a design and put it out there for everyone to look at and suggest improvements/refinements to, then we'll be getting somewhere. What it sounds like is that we have a bunch of people who don't know how to do anything, but like to expel alot of hot air. Frankly, where's the initial design, so that those of us that would be able to work on the software can get started? As far as Ether in a plane, I'd be a bit concerned about the effects of a cascading failure do to a spike somewhere on the bus. I've seen one lighting strike take out an entire buildings worth of computers. This wouldn't be the same, but close enough. Also, you'd have to use either STP or UTP, RG-58 isn't a possibility due to the 10' length limitation between ethernet nodes on 10b2. If someone was going to use ether as the instrument bus, I'd recomend using a inexpensive multiport switch, not a hub. You'd have some hope of electrical isolation that way, otherwise, a overvoltage condition would likely cascade through every piece of equipment in the plane. I've got a question, why can't we terminate each of the instruments directly into the display device (we know it's going to be a PC, but I'll try to be neutral and use the term "display device"). If your encoding altim uses RS-232, plug it in and you're done, why bother taking the step of trying to convert it to CAN and sending it to the PC? You can put a large number of interfaces on a "display device" to allow someone to directly terminate every instrument. As such, this entire bus discussion is moot. Rob ----- Original Message ----- From: Brian Lloyd <brian(at)lloyd.com> Sent: Sunday, January 09, 2000 1:48 PM Subject: Re: Avionics-List: CAN vs Ethernet > > Everyone seems to think that we must have one and only one transport. I > disagree with this thinking. Just as with the Internet, there will > probably be a need for more than one data transport. The Big Boys use > multiple transports now, with the new ARINC-669 spec (I think, I don't have > the spec number in front of me) being used for flight control systems and > most everything else migrating to Ethernet (10 Mbps for Boeing and 100 Mbps > for Airbus). The increased capacity would allow us to think about putting > audio on there for a really slick audio panel. > ________________________________________________________________________________
Date: Jan 09, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN vs Ethernet
>While we're at it, why don't we start debating binder twine as a possible >media for the PB project? It has already been done. It doesn't work very well. (Details if you really want them.) >What it sounds like is that we have a bunch of people who don't know how to >do anything, but like to expel alot of hot air. Well, this isn't exactly my first-line job. My employer sucked up all my free time and my wife seems to think she has claim to anything that is left over. >Frankly, where's the initial design, so that those of us that would be able >to work on the software can get started? Build something first, design it later. That has always been a recipe for success. >As far as Ether in a plane, I'd be a bit concerned about the effects of a >cascading failure do to a spike somewhere on the bus. I've seen one >lighting strike take out an entire buildings worth of computers. This >wouldn't be the same, but close enough. Ethernet uses transformer coupling with highpot insulation in order to prevent HV spikes from taking out the network. I thought that CAN used direct connection to the chips. Seems that CAN would be more susceptible. >Also, you'd have to use either STP >or UTP, RG-58 isn't a possibility due to the 10' length limitation between >ethernet nodes on 10b2. The limitation of minimum distance is very easily ignored without consequence for 10b2. I would go with STP if it were up to me. >If someone was going to use ether as the instrument >bus, I'd recomend using a inexpensive multiport switch, not a hub. You'd >have some hope of electrical isolation that way, otherwise, a overvoltage >condition would likely cascade through every piece of equipment in the >plane. There is no functional difference between a hub and a switch insofar as the physical connection is concerned. All connections are transformer coupled and then feed into the hub chip. A switch just has more silicon, some intelligence, and a one-packet delay because it is a store-and-forward device. All that aside, we could use either without any significant change. It wouldn't affect the data sources or sinks. HV isolation is the same in either case. >I've got a question, why can't we terminate each of the instruments directly >into the display device (we know it's going to be a PC, but I'll try to be >neutral and use the term "display device"). If your encoding altim uses >RS-232, plug it in and you're done, why bother taking the step of trying to >convert it to CAN and sending it to the PC? You can put a large number of >interfaces on a "display device" to allow someone to directly terminate >every instrument. As such, this entire bus discussion is moot. And that takes us right back to the dark ages of RS-232 ports, ARINC-429, etc. The goal was to simplify everything by having one bus to connect everything together. Since I am clearly pissing everyone off, I will shut up now. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Jan 09, 2000
From: dab(at)froghouse.org
Subject: Re: CAN vs Ethernet
On 9 Jan, Brian Lloyd wrote: > Ethernet uses transformer coupling with highpot insulation in order > to prevent HV spikes from taking out the network. I thought that > CAN used direct connection to the chips. Seems that CAN would be > more susceptible. Some CAN stuff I've seen uses opto-isolators. I don't know if that's universal or not. -Dave ________________________________________________________________________________
Date: Jan 09, 2000
Subject: Collins Avionics Wanted
From: "Shelby Smith" <shelbyrv6a(at)mindspring.com>
I am interested in upgrading one of my two VORs to Glideslope capability. Does anyone have any surplus equipment. My understanding is I need the glideslope reciever unit and the indicator. I recieved this e-mail and was wondering what a fair price would be and is this worth doing? COLLINS VOR NAV VIR-351 TSO PN 622-2080-011 SN 21007 INDIC. IND-351 TSO PN 622-2083-003 SN 6570 GLIDESLOPE GLS-350 PN 622-2084-001 SN 6620 No trays. Thanks in advance. -- Shelby Smith 68 B-23 N4004T serial #1110 Based at M88 - Nashville, TN Direct E-mail shelbyrv6a(at)mindspring.com ________________________________________________________________________________
Date: Jan 09, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN vs Ethernet
>Some CAN stuff I've seen uses opto-isolators. I don't know if that's >universal or not. Optoisolators would solve the problem. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Cy Galley" <cgalley(at)accessus.net>
Subject: Re: Collins Avionics Wanted
Date: Jan 09, 2000
No trays could mean it is HOT! Check serial numbers with radio shop to verify. Cy Galley - Editor, B-C Contact! (Click here to visit our Club site at http://www.bellanca-championclub.com) -----Original Message----- From: Shelby Smith <shelbyrv6a(at)mindspring.com> Date: Sunday, January 09, 2000 6:12 PM Subject: Avionics-List: Collins Avionics Wanted > >I am interested in upgrading one of my two VORs to Glideslope capability. >Does anyone have any surplus equipment. My understanding is I need the >glideslope reciever unit and the indicator. > >I recieved this e-mail and was wondering what a fair price would be and is >this worth doing? > >COLLINS VOR >NAV VIR-351 TSO PN 622-2080-011 SN 21007 >INDIC. IND-351 TSO PN 622-2083-003 SN 6570 >GLIDESLOPE GLS-350 PN 622-2084-001 SN 6620 >No trays. > >Thanks in advance. >-- >Shelby Smith >68 B-23 N4004T serial #1110 >Based at M88 - Nashville, TN >Direct E-mail shelbyrv6a(at)mindspring.com > > ________________________________________________________________________________
Date: Jan 09, 2000
Subject: Re: Collins Avionics Wanted
From: "Shelby Smith" <shelbyrv6a(at)mindspring.com>
Good idea. I guess it is good he included the serial numbers. -- Shelby Smith shelbyrv6a(at)mindspring.com ---------- >From: "Cy Galley" <cgalley(at)accessus.net> >To: >Subject: Re: Avionics-List: Collins Avionics Wanted >Date: Sun, Jan 9, 2000, 7:29 PM > > No trays could mean it is HOT! Check serial numbers with radio shop to > verify. > > Cy Galley - Editor, B-C Contact! ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN vs Ethernet Common Message Set
Date: Jan 09, 2000
Brian, I think I agree with you, at least in principle. When you say a Common Message Set I think of a HLP with a defined set of messages which are more or less agreed upon by the community. My current thinking is that our HLP with it's setup, control, timing and messaging approach is our next set of important decisions. CDA101/CAN Kingdom Is the approach I currently champion (subject to change when someone shows me a better one). As I said a short while back, Dave Purdy's CDA101 group is currently working on way of using Ethernet for CDA101. This tells me that what you say is probably right, but we need to go forward and start building a system based on existing hardware, software and available expertise. I would love to have a 10 or 100Mhz capacity databus, but where are we going to get the software? Do you want us to develop it? That seems to be a tall order to me, but I don't know, I don't have experience in that type of coding. John -----Original Message----- From: Brian Lloyd <brian(at)lloyd.com> Date: Sunday, January 09, 2000 2:56 PM Subject: Re: Avionics-List: CAN vs Ethernet > >Everyone seems to think that we must have one and only one transport. I >disagree with this thinking. Just as with the Internet, there will >probably be a need for more than one data transport. The Big Boys use >multiple transports now, with the new ARINC-669 spec (I think, I don't have >the spec number in front of me) being used for flight control systems and >most everything else migrating to Ethernet (10 Mbps for Boeing and 100 Mbps >for Airbus). The increased capacity would allow us to think about putting >audio on there for a really slick audio panel. > >The sense of the group seems to be that CAN and Ethernet are somehow >mutually exclusive. They aren't. The internet works by transporting a >common set of messages, i.e. the Internet Protocol Suite otherwise known as >TCP/IP, over many different transports including but not limited to >Ethernet, token ring, FDDI, async PPP, sync PPP, T1, T3, ATM, >OC-[3|12|48|192], various flavors of radio, etc. The key is the common >message set. > >My view is that we end up with a common message set that will work over >CAN, Ethernet, Lon, whatever. Now you can start with CAN for simple things >but not eliminate more advanced applications. We just stick in a router >that will speak CAN on one side and Ethernet on the other to allow >compatibility between the two. > >So embracing CAN is not a problem in and of itself but failing to look at a >common messaging protocol that will run above CAN/Ethernet/LON/whatever is >shortsighted. > > >Brian Lloyd Lucent Technologies >brian(at)lloyd.com 3461 Robin Lane, Suite 1 >http://www.livingston.com Cameron Park, CA 95682 >+1.530.676.6513 - voice +1.530.676.3442 - fax > > ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN vs Ethernet
Date: Jan 09, 2000
Bob, Cheap CAN controllers are available from many sources. You can buy a contoller and hook it up to any processor you choose. John -----Original Message----- From: RobertR237(at)aol.com <RobertR237(at)aol.com> Date: Sunday, January 09, 2000 10:49 AM Subject: Re: Avionics-List: CAN vs Ethernet >I will abstain from any vote but from all that I have been able to learn the >CAN is not readily available and will end up costing far more than the >Ethernet. Consider that the Ethernet is already built into many handheld and >laptop units. This seems to go against the stated goal of keeping it simple >and using off the shelf technology which is readily available. > >Bob Reed ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Turn & Bank indicator swap sought
Date: Jan 10, 2000
I asked a question a little while ago (last millennium! - that sounds a long time ago....) about an inverter from 12V to 28V for a turn and bank indicator - as some of you might recall. I sort of solved that using a very small but powerful inverter meant for a laptop (car adaptor) which puts out 18VDC and actually drives the gauge quite well as it is. It turn out (on closer examination of the label on the back - dooooh - that it needs 24V not 28) and I guess the converter could be could be tweaked to 24V. However in designing my panel I found that this 3 1/2" instrument is just too big for my layout to look neat and I've decided to go looking for a 2 1/4" turn and bank indicator instead (hopefully 12V). If someone has one at a reasonable price (non TSO'd is OK - mine isn't either) or wants to swap mine for his/hers with cash adjustment if required, I'd be glad to hear from you. Hints on sources will also be appreciated - and others might like to hear of them too. I guess somewhere in the future it will become a secondary or backup instrument - when we get the virtual instruments going! That's why I need the space in the panel.... Thanks Joe Hovel Australia ________________________________________________________________________________
From: "Greg Young" <gyoung@cs-sol.com>
Subject: Sunlight Readable Displays
Date: Jan 10, 2000
For those of you that want to focus on the other end of the glass cockpit, let's talk about sunlight readable displays. I'm going to use 2 displays in my RV-6 and my preliminary sizing indicates I'm limited to 8.4" LCDs including a bezel with some pushbuttons, pointing device and mounting - perhaps 10.1" with a very compact bezel/mounting, depending on the specific panel I choose. I'd like SVGA (or better) but can live with VGA. That said, I've been focusing (perhaps too much, but the concept is too good to ignore) on the Sharp HR-TFT LQ084V2DS01 panel. This is an 8.4" VGA high reflective LCD that does not use a backlight for sunlight readability - supposedly gets better in brighter light instead of washing out. I've not seen one or heard of anyone using one. I believe the Compaq Aero CE device uses the QVGA version (320x240) but I haven't been able to find a live one to view (amazing considering I live 6 miles from Compaq's HQ). Here's some questions specific to the HR-TFT: 1. Anyone seen, used or have experience with it? 2. How does it function in the dark? Does it have enough natural luminescence to be usable or does it need back or front lighting? Does it allow backlighting? 3. I've got the spec sheet but it doesn't answer (in English anyway) the simple question of what kind of controller is required? Will any flat panel LCD controller work or is something special needed? Sources? 4. Sources? Several months ago Marshall's showed it for $500 but it's not listed now that they are Av-Net. Arrow has it for $719. I'm a software guy and component level sourcing is new territory. Do these folks handle onezies & twozies? Any one better than the rest? Any other suggestions? Now here are the more general display questions: 5. Anyone else made a display selection or narrowed your choices? 6. Input devices: I like the idea of function keys (probably 6 on each side of the display) and a mini-joystick. This also seems to be the direction most commercial displays are going and seems logical for operation in turbulence. Touch screens have some problems but sure make the bezel/mounting issue easier. Comments? 7. Source for function keys and joystick? I can find low-profile key switches and even pre-packaged keypads at Digikey, etc., but I haven't located a source for a pointing device - mini-joystick, eraser, coolie hat, etc. I'd also like a professional looking installation so whatever I use will have to be integrated into the... 8. Bezel: I could cobble something together out of aluminum for a proof of concept but it will look pretty amateurish. A machined bezel would be nice but I'm leery of getting it right the first time. I'm not a machinist so it's big$ for each attempt. Molding is a possibility but also complex because of the need for double sided accuracy to mount the keys. Then there's the question of what to mold it from. Any suggestions? 9. Source for custom bezel? Anyone know a reasonable source for custom bezels with integrated, lighted keys, etc.? I haven't a clue as to what's normal in this arena but I'd consider it if I could get both for under $1k. 10. Anyone have any experience with the hi-brite displays or other backlit displays? 11. Any other suggestions for sunlight readable displays? Hopefully this is enough to get another thread going. Presumably everyone considering a glass cockpit has thought about the display at some level. Let's hear your thoughts. Regards, Greg Young - Houston (DWH) RV-6 N6GY (reserved) 90%done, 90% to go "Always do right- this will gratify some and astonish the rest." - Mark Twain (1835-1910) ________________________________________________________________________________
Date: Jan 10, 2000
From: dab(at)froghouse.org
Subject: Re: Sunlight Readable Displays
On 10 Jan, Greg Young wrote: > I'd like SVGA (or better) but can live with VGA. At Osh last summer I saw the Meggit (http://www.meggittavi.com/) displays. They're small compared to what you're talking about but after talking with the guy for a while he told me they were QVGA. I had assumed at least VGA because they looked so good. He said they just put a lot of work into good graphics software and so got good effect out of the smaller displays. I'm not saying I wouldn't like SVGA or better too, but after that example I can see that lower res can be quite effective. > That said, I've been focusing (perhaps too much, but the concept is > too good to ignore) on the Sharp HR-TFT LQ084V2DS01 panel. This is > an 8.4" VGA high reflective LCD that does not use a backlight for > sunlight readability - supposedly gets better in brighter light > instead of washing out. I like the idea of the reflective display. They don't seem to have it in an extended temperature range version though, only down to 0degC. I wish my plane never got colder than that. Still, it could be used for development. Sharp also has a line of extended temperature range panels but none seem to be the reflective type and none have particularly high resolution. They do have some widescreen versions (4.2"x6.8") which might be interesting if mounted portrait orientation. They also take a NTSC/PAL input signal which I don't know if is good or bad. See http://sharp-world.com/e-device/np/lcd1.htm for specs on Sharp LCD and EL panels. > 6. Input devices: I like the idea of function keys (probably 6 on > each side of the display) and a mini-joystick. This also seems to be > the direction most commercial displays are going and seems logical > for operation in turbulence. Touch screens have some problems but > sure make the bezel/mounting issue easier. Comments? I'm dubious about using pointing devices while flying. Especially in turbulence. I was thinking buttons down the sides and one or two shaft encoders, probably on the two lower corners. For the buttons I've wondered if capacitive buttons would make sense. I like the idea of no moving parts but I fear there's some reason I don't know about that makes them a bad idea. > Hopefully this is enough to get another thread going. Presumably everyone > considering a glass cockpit has thought about the display at some level. > Let's hear your thoughts. I don't have thoughts on all the good points you brought up but here's what I do have. -Dave ________________________________________________________________________________
Date: Jan 10, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN vs Ethernet Common Message Set
> I think I agree with you, at least in principle. When you say a Common >Message Set I think of a HLP with a defined set of messages which are more >or less agreed upon by the community. That is how I view it also. >My current thinking is that our HLP >with it's setup, control, timing and messaging approach is our next set of >important decisions. Most of that appears to be dealing with the limitation of CAN itself in order to turn it into a more general message passing transport. Much of that isn't needed when using Ethernet. >CDA101/CAN Kingdom Is the approach I currently >champion (subject to change when someone shows me a better one). As I said >a short while back, Dave Purdy's CDA101 group is currently working on way of >using Ethernet for CDA101. This makes sense to me. I ought to be able to carry the same information over CAN and over Ethernet. >This tells me that what you say is probably >right, but we need to go forward and start building a system based on >existing hardware, software and available expertise. Hardware: many existing SBCs and laptops have Ethernet. Few have CAN. Software: those systems that support Ethernet have the necessary software and high-level interfaces right now. Expertise: there is more existing expertise with Ethernet than with CAN. >I would love to have a >10 or 100Mhz capacity databus, but where are we going to get the software? Your PC already knows how to talk over Ethernet at 100Mbps. Every small OS designed for embedded systems supports IP and Ethernet if you want those. You don't need to create a lot that is new. >Do you want us to develop it? That seems to be a tall order to me, but I >don't know, I don't have experience in that type of coding. But you are already saying that you need to do that for CAN. I don't see the difference other than it is already done for Ethernet and it still needs to be done for CAN. As I said, if we approach this correctly, we can use either CAN or Ethernet as the low-level transport. We will already have commonallity at an internet layer above either CAN or Ethernet. And I guess that I just didn't want to assume that CAN is a slam-dunk. There are some pieces that just aren't filled in yet. Ethernet is not difficult to live with and its ability to transfer larger messages without any additional HLP might actually make it easier to work with. Certainly Ethernet hardware and drivers are easier to come by. But a common messaging system for both CAN and Ethernet would be a big win in the flexibility area. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Jan 11, 2000
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: Sunlight Readable Displays
Greg Young wrote: > Now here are the more general display questions: > 5. Anyone else made a display selection or narrowed your choices? I've only done some preliminary playing around. I took a IBM Thinkpad with a TFT screen for a flight in a C172. It was connected to my GPS and running a simple moving map. Also for a few drives in the car. The screen visibility was disappointing to say the least. Lines and text were marginally readable -- stare at screen for several seconds to figure out what it says. In the end, I changed the map program to display 1/8 resolution (i.e. every 'pixel' was displayed as 8x8 screen pixels). The biggest problem wasn't so much the brightness (or lack thereof) of the screen, but the reflection of the windows off its surface (I had the laptop on the floor of the C172). Based on this experience, I don't think SVGA is important... even 320x200 would be plenty. > 6. Input devices: I like the idea of function keys (probably 6 on each side > of the display) and a mini-joystick. This also seems to be the direction > most commercial displays are going and seems logical for operation in > turbulence. Touch screens have some problems but sure make the > bezel/mounting issue easier. Comments? I like the idea of a touch screen, although these tend to be prohibitively expensive. Another thought is one of those touchpad mouse replacement devices. Alternatively use the hat on top of the stick as a pointing device. Frank. RV-6 50% done ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Sunlight Readable Displays
Date: Jan 10, 2000
> > The screen visibility was disappointing to say the least. Lines and text > were marginally readable -- stare at screen for several seconds to > figure out what it says. In the end, I changed the map program to > display 1/8 resolution (i.e. every 'pixel' was displayed as 8x8 screen > pixels). The biggest problem wasn't so much the brightness (or lack > thereof) of the screen, but the reflection of the windows off its > surface (I had the laptop on the floor of the C172). Based on this > experience, I don't think SVGA is important... even 320x200 would be > plenty. > In my last job I toured the country installing Point of Sale systems in restaurants. Glare was a big issue for many of my customers. My experience is that the material from which the frontmost surface of the screen is made has the biggest effect on glare. That being said, I did not get the impression that this was a big concern to most manufacturers of POS display units. -Matt ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Sunlight Readable Displays
Date: Jan 10, 2000
>I've only done some preliminary playing around. I took a IBM >Thinkpad with a TFT screen for a flight in a C172... but the reflection of the windows off its surface (I had >the laptop on the floor of the C172). Based on this experience, >I don't think SVGA is important... even 320x200 would be >plenty. Also consider the angles involved... if you picture a mirror mounted falt on the panel, you would not see a reflection of the windows. You'd see your lap, the copilot's seat, the floor, etc. Bust a mirror mounted on the floor angled up will have anice view of the windows (or throgh the canopy!). A LCD display mounted in the panel of the aircraft will have less of a glare issue, though obviously we would work to get the best panel for the job. I'm not saying that glare is not a problem, just that it perhaps can be minimized to tolerable levels given appropriate mounting consideration. >I like the idea of a touch screen, although these tend to be >prohibitively expensive. Another thought is one of those touchpad mouse >replacement devices. There has been some discussion of the pro's and con's of these sort of things... particularly controllability in turbulence or while looking out the windows (as one should from time to time :-). Also mentioned was soiling of the face of the display using touch screens. >Alternatively use the hat on top of the stick as a pointing device. This I like! Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Jan 10, 2000
From: Steven Eberhart <newtech(at)newtech.com>
Subject: Re: Sunlight Readable Displays
On Tue, 11 Jan 2000, Frank and Dorothy wrote: > I've only done some preliminary playing around. I took a IBM Thinkpad > with a TFT screen for a flight in a C172. It was connected to my GPS and > running a simple moving map. Also for a few drives in the car. > > The screen visibility was disappointing to say the least. Lines and text > were marginally readable -- stare at screen for several seconds to > figure out what it says. In the end, I changed the map program to > display 1/8 resolution (i.e. every 'pixel' was displayed as 8x8 screen > pixels). The biggest problem wasn't so much the brightness (or lack > thereof) of the screen, but the reflection of the windows off its > surface (I had the laptop on the floor of the C172). Based on this > experience, I don't think SVGA is important... even 320x200 would be > plenty. I may be opening myself up to public ridicule because of my ignorance but... Several years back I was upgraded on a rental car to a Lincoln Town Car. It had an electronic dash that was exceptionally "readable" in all conditions. Naturally I had to see how they did it. The display was located in the horizontal plane with a reflective panel at a 45 degree angle above the panel. Sort of like a heads up display but burried in the dash. No chance for outside light to affect the display. Since that experience I have always wanted to setup a test system with a coated plastic sheet at a 45 degree angle to the laptop display, duly shrouded to keep ambient light out, to play with in direct sun light. Still haven't tried this but have always thought that it would be the configuration i used in an airplane panel. THe only drawback that I can see is that you would have to invert the display as it would be a mirror image. Surely this can be done in software. Steve Eberhart mailto:newtech(at)newtech.com THE WING FLIES! - http://www.newtech.com/nlf for info on the new, flight tested, KRnet/UIUC airfoils. Good job KRnet, you can be proud of your contribution to Sport Aviation. Special thanks to Dr. Ashok Gopalarathnam and Dr. Michael Selig for some great Sport Aviation airfoils. One test is worth a thousand expert opinions but a thousand opinions are easier to get. --plagiarized from an unknown author All information, in any of my aircraft related correspondence, is strictly food for thought requiring additional, qualified, engineering analysis. ________________________________________________________________________________
From: "Chris Atkinson" <chris-atkinson(at)home.com>
Subject: Sunlight Readable Displays
Date: Jan 10, 2000
Here's one worth looking at if you're not an ABMS (anything but microsoft) bigot. http://www.fpsi.fujitsu.com/news/r-demo.htm. BTW, we also ended up choosing Ethernet....it's round and it rolls, so why reinvent it? Chris -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com] On Behalf Of Matthew Mucker Sent: Monday, January 10, 2000 3:20 PM Subject: RE: Avionics-List: Sunlight Readable Displays > > The screen visibility was disappointing to say the least. Lines and text > were marginally readable -- stare at screen for several seconds to > figure out what it says. In the end, I changed the map program to > display 1/8 resolution (i.e. every 'pixel' was displayed as 8x8 screen > pixels). The biggest problem wasn't so much the brightness (or lack > thereof) of the screen, but the reflection of the windows off its > surface (I had the laptop on the floor of the C172). Based on this > experience, I don't think SVGA is important... even 320x200 would be > plenty. > In my last job I toured the country installing Point of Sale systems in restaurants. Glare was a big issue for many of my customers. My experience is that the material from which the frontmost surface of the screen is made has the biggest effect on glare. That being said, I did not get the impression that this was a big concern to most manufacturers of POS display units. -Matt ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN vs Ethernet Common Message Set
Date: Jan 10, 2000
Brian, >>My current thinking is that our HLP >>with it's setup, control, timing and messaging approach is our next set of >>important decisions. >Most of that appears to be dealing with the limitation of CAN itself in >order to turn it into a more general message passing transport. Much of >that isn't needed when using Ethernet. I don't think this is the case. I think that most of the HLP issues deal with determining who is present on the net, what messages will be sent by whom and under what circumstances(send frequency, timeouts, upon request...). This is a control system and we can't have just any module doing what it wants to do on the net or you may loose control over data latency. We need to have a certain control over the setup of each module. How we want it to behave is determined to some extent by what each person's system needs from any given module. This stuff have been worked out to some extent in CDA101. I have'nt even brought up the issues concerning software for fail modes. >...Hardware: many existing SBCs and laptops have Ethernet. Few have CAN. >Software: those systems that support Ethernet have the necessary software >and high-level interfaces right now. >Expertise: there is more existing expertise with Ethernet than with CAN. We're not talking about expertise in sending unsyncronized data over a net. Is there expertise in sending syncronized data ( garenteed maximum delay time) over the Ethernet? I don't know. This is the purpose of realtime control HLPs like CDA101 and others. I would change my mind if we could get an example of a control system's software that addresses these issues using Ethernet. >>I would love to have a >>10 or 100Mhz capacity databus, but where are we going to get the software? >Your PC already knows how to talk over Ethernet at 100Mbps. Every small OS >designed for embedded systems supports IP and Ethernet if you want those. >You don't need to create a lot that is new. Yes. In a loose, unsyncronized, no garentees way. What do we have to do to use this media with more stringent requirements? I'm sure it can be done. We need examples. >>Do you want us to develop it? That seems to be a tall order to me, but I >>don't know, I don't have experience in that type of coding. >But you are already saying that you need to do that for CAN. I don't see >the difference other than it is already done for Ethernet and it still >needs to be done for CAN. No we don't. We can use CDA101 ST2000 CAN Kingdom software as an example starting point. As we and Purdy's CDA101 folks progress we will (I think)find ways of using Ethernet for this sort of work. Maybe it is simpler than I think. Even if it is simple, we still need something like CDA101 & CAN Kingdom. >As I said, if we approach this correctly, we can use either CAN or Ethernet >as the low-level transport. We will already have commonallity at an >internet layer above either CAN or Ethernet. I agree. >And I guess that I just didn't want to assume that CAN is a slam-dunk. >There are some pieces that just aren't filled in yet. Ethernet is not >difficult to live with and its ability to transfer larger messages without >any additional HLP might actually make it easier to work with. Certainly >Ethernet hardware and drivers are easier to come by. But a common >messaging system for both CAN and Ethernet would be a big win in the >flexibility area. I think CAN is nearly a slam-dunk at this point in time. What pieces are not filled in? Ethernets ability to transfer large messages, if not properly controlled can be a (time delay)headache, not a help. Again I agree about a common HLP approach, but I think it would be prudent to take a wait and see approach to the use on Ethernet for all of the reasons mentioned above. Please convince me I'm wrong, because as I said I'd love to use it for audio and video as well. A realtime control oriented HLP is the real important issue. You know I like the idea of 2 buses for redundancy. How about one CAN and one Ethernet. We can use the Ethernet for less critical (non control oriented jobs) until we sort out exactly how to garentee timeing. John ________________________________________________________________________________
Date: Jan 10, 2000
From: dab(at)froghouse.org
Subject: CAN vs Ethernet Common Message Set
On 10 Jan, Livingston John W Civ ASC/ENFD wrote: > Yes. In a loose, unsyncronized, no garentees way. What do we have > to do to use this media with more stringent requirements? I'm sure > it can be done. We need examples. I don't see much reason to extend the discussion about CAN vs Ethernet but I want to make sure we don't fool ourselves into thinking that any network can guarantee timing. You can not build a perfect arbitrator and a multi-access netowrk is an arbitrator. This is been an argument raised against ethernet from the beginning which is not valid in theory and hasn't proven to be valid in practice. > I think CAN is nearly a slam-dunk at this point in time. Agreed. > What pieces are not filled in? Availability. -Dave ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN vs Ethernet Common Message Set
Date: Jan 10, 2000
Dave, The way CDA101 and other real time control HLPs work they can be made to guarantee a maximum time delay (or data latency) , this is because modules are not given unlimited access to the net, but are constrained to work together by the real time HLP. This is what the documents and specs say. I have no idea what is done to handle various failure modes but I'm told there are ways. John -----Original Message----- From: dab(at)froghouse.org <dab(at)froghouse.org> Date: Monday, January 10, 2000 7:14 PM Subject: RE: Avionics-List: CAN vs Ethernet Common Message Set > >On 10 Jan, Livingston John W Civ ASC/ENFD wrote: > >> Yes. In a loose, unsyncronized, no garentees way. What do we have >> to do to use this media with more stringent requirements? I'm sure >> it can be done. We need examples. > >I don't see much reason to extend the discussion about CAN vs Ethernet >but I want to make sure we don't fool ourselves into thinking that any >network can guarantee timing. You can not build a perfect arbitrator >and a multi-access netowrk is an arbitrator. This is been an argument >raised against ethernet from the beginning which is not valid in >theory and hasn't proven to be valid in practice. > >> I think CAN is nearly a slam-dunk at this point in time. > >Agreed. > >> What pieces are not filled in? > >Availability. > > -Dave > > ________________________________________________________________________________
Date: Jan 10, 2000
From: John Lazear <tomlazear(at)netscape.net>
Subject: Microair 760
Does any any one out there have a Microair 760, I have heard nothing but good about this little radio, is there any dislikes about it? I would like to purchase one, to install in CH 701 along with intercom. Does any one have a Phone number where I could get some price & features for the Microair 760. Tom tomlazear(at)netscape.net Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. ________________________________________________________________________________
Date: Jan 10, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN vs Ethernet Common Message Set
On Mon, 10 Jan 2000, Livingston John W Civ ASC/ENFD wrote: > We're not talking about expertise in sending unsyncronized data over a net. > Is there expertise in sending syncronized data ( garenteed maximum delay > time) over the Ethernet? Yes. > I don't know. This is the purpose of realtime > control HLPs like CDA101 and others. I would change my mind if we could get > an example of a control system's software that addresses these issues using > Ethernet. Mostly you don't have to unless the offered traffic is a significant portion of the available bandwidth. The occasional collision is handled in the silicon and we don't need to trouble our little heads with it. There is a short random backoff by the parties to the collision and then they retransmit. This introduces a tiny amount of additional latency but even instruction path variability in the code can introduce that much latency jitter. If you consider point-to-point async serial data paths acceptable insofar as latency is concerned (it can take a looong time to transmit even a short message at 9600 bps compared to 10,000,000 bps) then you can't really complain about Ethernet. And if you are really paranoid you can modify the MAC layer in software. You can adopt token passing or TDM. This guarantees latency values at the expense of those fixed values being greater. This gets into the area of isochronous Ethernet which is still supported by standard Ethernet hardware but this really only buys you something when your Ethernet is heavily loaded. If you looks at the characteristics of CSMA/CD (carrier sense multiple access with collision detection) you find that latency jitter becomes almost a non-issue at offered traffic levels are low, less than about 10% of channel capacity as I recall (I did research in this area about 15 years ago but I forget the exact numbers and my library is still packed up). > > > >>I would love to have a > >>10 or 100Mhz capacity databus, but where are we going to get the software? > > >Your PC already knows how to talk over Ethernet at 100Mbps. Every small OS > >designed for embedded systems supports IP and Ethernet if you want those. > >You don't need to create a lot that is new. > > Yes. In a loose, unsyncronized, no garentees way. What do we have to do to > use this media with more stringent requirements? I'm sure it can be done. > We need examples. You are assuming that a "loose, unsynchronized, no guarantees way" somehow fails to meet the requirements. I hold that a lightly loaded, i.e. less that 10% of channel capacity, standard ethernet without any augmentation is sufficient to meet your requirement for latency jitter. If I know the size of the messages and their arrival rate, I can tell you statistically what your worst-case latency will be. Almost all of the time it will be much less than that value. This is a case where people can envision a problem and then worry about it solving it when it turns out that there is no down-side to just ignoring the problem. You know, if you really want to get paranoid, you will have to examine all the branch paths through your code to ensure that they are all exactly the same length otherwise you will introduce latency variability because some paths will require more clock cycles than other paths (yes, I have done this type of optimization in my life for very critical timing systems). I doubt that you will be that paranoid. Just to get an idea of what I am talking about, you might try writing a test system that has an interrupt handler that schedules a task to run that generates an output, e.g. drives a bit on a parallel port high and then low again. On a periodic basis generate the interrupt and see how long it takes for the output to respond. I bet you will discover that there is some variability in the response time on the order of 10's to 100's of microseconds (dependent on what the other tasks the system are doing). This is of the same order of magnitude as the variability in packet delivery on a lightly loaded ethernet. > >>Do you want us to develop it? That seems to be a tall order to me, but I > >>don't know, I don't have experience in that type of coding. > > >But you are already saying that you need to do that for CAN. I don't see > >the difference other than it is already done for Ethernet and it still > >needs to be done for CAN. > > No we don't. We can use CDA101 ST2000 CAN Kingdom software as an example > starting point. As we and Purdy's CDA101 folks progress we will (I > think)find ways of using Ethernet for this sort of work. Maybe it is > simpler than I think. Even if it is simple, we still need something like > CDA101 & CAN Kingdom. We need some sort of commonality for all data transports. Complexity added to the system because we can conceive of a problem might not be needed. Just because you can imagine a problem doesn't mean that it is a real problem. That is what I was alluding to when I spoke of OSI vs. TCP/IP back in the early 90's. The OSI folks worried about things such as you are worrying about and spent lots of time "fixing" the problems when the TCP/IP folks just tried doing things the simple way to see how they behaved. Turns out most of the problems that appeared to be problems on paper never materialized in reality. As a result TCP/IP got done and put to use while the OSI folk were still solving imagined problems and adding layer upon layer of complexity. They never really got the job done and their protocols were so bloated that noone ever really implemented the whole thing leading to a lack of interoperability. Now I am not saying that CAN, CDA101, and CAN Kingdom are bloated but I am saying that you don't need to layer a bunch of stuff over stochastic Ethernet to "solve" the latency jitter "problem." In the real world it won't be a problem. > >And I guess that I just didn't want to assume that CAN is a slam-dunk. > > I think CAN is nearly a slam-dunk at this point in time. What pieces are > not filled in? Ethernets ability to transfer large messages, if not > properly controlled can be a (time delay)headache, not a help. A full-sized ethernet packet takes 1.22 ms to transfer over the buss. That is the longest you have to wait for someone to transfer 1500 bytes of payload. A minimum length ethernet packet takes 0.072 ms to transfer. Those are your bounds. If a 1500 byte payload is too long, limit yourself to smaller payloads. This isn't rocket science. > Again I agree > about a common HLP approach, but I think it would be prudent to take a wait > and see approach to the use on Ethernet for all of the reasons mentioned > above. Please convince me I'm wrong, because as I said I'd love to use it > for audio and video as well. A realtime control oriented HLP is the real > important issue. You know I like the idea of 2 buses for redundancy. How > about one CAN and one Ethernet. We can use the Ethernet for less critical > (non control oriented jobs) until we sort out exactly how to garentee > timeing. You still haven't shown me what the timing constraints are. What ARE the timing limits? You talk about control oriented jobs as being time critical and you imply that CAN is sufficient and that Ethernet is not but you haven't said what the limits are. I pointed out some time ago that our aircraft are *safely* hand-flown by human beings with response times measured in SECONDS, not microseconds. I hold that a few milliseconds difference will have NO effect on the accuracy of the flight control system. If not then the latency issue with Ethernet is moot. I have pointed out that you are going to have latency issues in the code that generates your flight control signals that probably rivals the latency jitter with Ethernet (actually I suspect it will be much greater causing the latency jitter with ethernet to disappear into the noise). Latency jitter will just appear as noise in the control signals and will statistically cancel out as integrated over time (airframe as low-pass filter). Throw in gross turbulance, boundary layer turbulance, dead zones, slop in the mechanical control linkages, stick-slip friction in the bearings, etc., and all your worry about millisecond control signal jitter disappears in the noise. You really need to view the entire control system, including aircraft behavior, as a closed-loop servo system. You can introduce delay into the feedback in the model until the system becomes unstable and then back off again. I betcha that when you are all done you will find that, even at Ethernet worst case, you still have scads and scads of stability margin for most aircraft since we aren't trying to use the feedback to stabilize a dynamically unstable aircraft. So what it boils down to is that you THINK there MIGHT be a timing problem but you don't know what the constraints are so let's just go with CAN. If you don't know what the constraints are, how do you know that CAN will be any better than Ethernet, hmmm? But everyone else is right about one thing, talking won't get anywhere. Doing will. If experimenting with CAN will get something we can experiment with and gain experience, that is a good thing. Frankly I think we can do the same thing with Ethernet and since most PCs already have that, we can begin testing code right away without having to wait to build hardware. This is really a software project with a little hardware thrown in. It is the software and not the hardware that is going to be the challenge. That which allows us to begin testing software is going to advance the project more rapidly. Being able to proceed in parallel with hardware and software would be a really big win. My two-cents worth. Your milage may vary. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Jan 10, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN vs Ethernet Common Message Set
On Mon, 10 Jan 2000, J Livingston wrote: > > Dave, > > The way CDA101 and other real time control HLPs work they can be made to > guarantee a maximum time delay (or data latency) , this is because modules > are not given unlimited access to the net, but are constrained to work > together by the real time HLP. This is what the documents and specs say. I > have no idea what is done to handle various failure modes but I'm told there > are ways. So you are saying that it is the code and not the network hardware that guarantees all this. Fine. That same code will work just as well with Ethernet. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Greg Young" <gyoung@cs-sol.com>
Subject: CAN vs Ethernet Common Message Set
Date: Jan 11, 2000
I would agree with Brian that we need to look at the real world problem/behavior and move forward. But I see it in a much broader sense. Maybe I missed it early on, but I've never seen a discussion much less agreement on the mission requirements for this system. All this talk of closed loop control systems with <1ms latency may be necessary for a fly-by-wire fighter but is way overkill for anything I'm going to build. Dismissing fly-by-wire (no one is seriously considering that are they?) we've got a system with a pilot with multi-second response time, with eyes that integrate anything greater than 10hz and probably can't discern a 1% indicator change. And then we've got a display with a 75hz refresh. Updating this bio-optical subsystem any faster is pointless. As an example consider the altimeter. During a 2000fpm climb you could display a 1% indicator change (10ft on a 1000ft dial) with only 3 updates per second. This is perfectly adequate for my VFR mission requirements. BTW you ought to check out http://www.meggittavi.com/. This is a link Dave offered for displays but they've implemented the data bus architecture using ARINC429 with multiple displays, redundant sensors and a data acquisition unit for engine sensors instead of individual sensors modules on the bus. Regards, Greg Young - Houston (DWH) RV-6 N6GY (reserved) 90%done, 90% to go "Always do right- this will gratify some and astonish the rest." - Mark Twain (1835-1910) ________________________________________________________________________________
Date: Jan 11, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Sunlight Readable Displays
>Also consider the angles involved... if you picture a mirror mounted falt >on the panel, you would not see a reflection of the windows. You'd see >your lap, the copilot's seat, the floor, etc. Bust a mirror mounted on >the floor angled up will have anice view of the windows (or throgh the >canopy!). You are going to want some kind of anti-glare coating on the display. OCLI used to make very nice anti-glare coating. I had a monitor with their coatings on it and it was a real joy to use. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN vs Ethernet Mission Regs
Date: Jan 11, 2000
Brian, Greg, >from Brian: ...You talk about control oriented jobs as being time >critical and you imply that CAN is sufficient and that Ethernet is not but >you haven't said what the limits are... Gee, I hope I didn't imply that. I'm not just saying I'd like to use Ethernet, I really mean it. I hope I conveyed my concerns over numerous issues including signal time delay and example software for an Ethernet based control system. You answered the time delay issue very well and I no longer have that concern. As far as time delay requirements: I'm sure if we can limit time delays to 10ms this would more than enough. This is assuming the most we will be doing is an autopilot. 0.05 to 0.1 second update time with an order of magnitude thrown in for overhead etc. Does this seem about right? I'm being conservative it may be only 30 ms. In either case it appears that Ethernet even at its largest packet size is plenty fast enough. As you and I have both pointed out they both will still require the proper HLPs to guarantee this level of time delay. >...you THINK there MIGHT be a timing problem >but you don't know what the constraints are so let's just go with CAN. If >you don't know what the constraints are, how do you know that CAN will be >any better than Ethernet, hmmm?... I never said CAN would be better than Ethernet, you just thought I said that:-) I said we can get (are getting) what I am told is a pretty complete set of software for a complete CDA101 (based on CAN Kingdom) implementation of a control system(the ST2000 boat). This system is similar in complexity and timing and handles many of the same messages as we will need in a full avionics suite. I also said that there is a community of people doing control system design and implementation using CAN and associated HLPs, most importantly CAN Kingdom. The CDA101 group (which to date has been the most forth coming of any of them) is starting to work Ethernet. I think it would be a good idea to suck their brains. I would feel very confident using Ethernet if we could talk to or get our hands on similar Ethernet work, but I haven't seen it yet. I expect we may see it in the near future. Maybe we can help bring this about. Please don't paint me a qualitative theoretician. I'm just trying to do some research to find possible stumbling blocks. >...Frankly I >think we can do the same thing with Ethernet and since most PCs already >have that, we can begin testing code right away without having to wait to >build hardware. This is really a software project with a little hardware >thrown in. It is the software and not the hardware that is going to be >the challenge. That which allows us to begin testing software is going to >advance the project more rapidly. Being able to proceed in parallel with >hardware and software would be a really big win. I tend to agree with you here. This is a strong argument. I suggest we: 1)first look at the CDA101 spec and associated ST2000 code and see how they are doing thing and use this for quidance or a baseline. 2)at that time see if it can't be used (with mods) to drive Ethernet as well. Questions: Why aren't other people using Ethernet for this type of application? What do the Ethernet controllers sell for? Can we still use small 8 and 16 bit processors. Are we still talking $20-30 worth of parts for a module? -----Original Message----- From: Greg Young [mailto:gyoung@cs-sol.com] Sent: Tuesday, January 11, 2000 3:57 AM Subject: RE: Avionics-List: CAN vs Ethernet Common Message Set I would agree with Brian that we need to look at the real world problem/behavior and move forward. But I see it in a much broader sense. Maybe I missed it early on, but I've never seen a discussion much less agreement on the mission requirements for this system. All this talk of closed loop control systems with <1ms latency may be necessary for a fly-by-wire fighter but is way overkill for anything I'm going to build. Dismissing fly-by-wire (no one is seriously considering that are they?) we've got a system with a pilot with multi-second response time, with eyes that integrate anything greater than 10hz and probably can't discern a 1% indicator change. And then we've got a display with a 75hz refresh. Updating this bio-optical subsystem any faster is pointless. As an example consider the altimeter. During a 2000fpm climb you could display a 1% indicator change (10ft on a 1000ft dial) with only 3 updates per second. This is perfectly adequate for my VFR mission requirements. BTW you ought to check out http://www.meggittavi.com/. This is a link Dave offered for displays but they've implemented the data bus architecture using ARINC429 with multiple displays, redundant sensors and a data acquisition unit for engine sensors instead of individual sensors modules on the bus. Regards, Greg Young - Houston (DWH) RV-6 N6GY (reserved) 90%done, 90% to go "Always do right- this will gratify some and astonish the rest." - Mark Twain (1835-1910) ________________________________________________________________________________
Date: Jan 11, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN vs Ethernet Mission Regs
> Questions: Why aren't other people using Ethernet for this type of >application? Well, Boeing and Airbus are using Ethernet for mission-critical data, i.e. everything except the actual flight control system itself. This means avionics, engine data collection, etc. The fact that it is the buss of choice in the B-777 and the new version of the 767 implies that it might have some application in aviation. >What do the Ethernet controllers sell for? I haven't looked recently but they were in the $6-$10 range a few years ago. >Can we still use small 8 and 16 bit processors? It depends on how small you are talking about but, yes, you can. It will work very nicely with processors like the 80186. (Can you even get those any more?) I don't know enough about the current crop of programmable controllers to say. > Are we still talking $20-30 worth of parts for a module? I don't know. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN boards
Date: Jan 11, 2000
All I can't remember if anyone had posted this site. http://www.zanthic.com some nice small cheap boards. John ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN chips
Date: Jan 13, 2000
All, Has anyone found a source for small quanities of any of the CAN chips? John ________________________________________________________________________________
Date: Jan 14, 2000
Subject: Collins Avionics Available
From: "Shelby Smith" <shelbyrv6a(at)mindspring.com>
I am removing one of my VOR indicators and also have NAV unit available. These are IND 350 and VIR 350 or 351. I will be pricing them below what is listed in TOP. -- Shelby Smith 68 B-23 N4004T serial #1110 Based at M88 - Nashville, TN Direct E-mail shelbyrv6a(at)mindspring.com ---------- ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Jan 14, 2000
Subject: Re: Avionics-List Digest: 01/13/00
> Has anyone found a source for small quanities of any of the CAN chips? After too many hours on the internet and the phone, I found that I could get the Microchip MCP2510 from Pioneer (www.pios.com), and the TI TMS320F241 from Arrow and one other vendor (I forget which, my notes are at home). Arrow seems to be higher priced than anyone else, and my first impression is that they are difficult to deal with. I got the Atmel ATM-ATSK200 eval board from Insight, and some Atmel parts from Pioneer. Both vendors were quite satisfactory. The Microchip CAN development system, about $250, was not in stock anywhere. It appears that there is high demand for this and for the MCP2510. There is also high demand for the uC I want to use, the Atmel AT90S4433, but it is possible to get them. I would like to use the TI part, but so far have not been able to find any low cost development software. To do the job right with the TI part it would be desirable to have a JTAG pod, about $1000, in addition to the rather expensive debug software. Were this a commercial venture I would go with TI, for my hobby project I think I'll stick with Atmel and an external CAN controller. A big fat "F" to Motorola, Fujitsu, Infineon, and various others. Actually it is not an issue of right or wrong, it is perfectly reasonable for companies to discourage small hobby orders. My own company does not sell in small quantities or to individuals, and that is OK. I am just thankful that there are a few companies that seem to encourage small orders - Microchip and Atmel, in particular. You can even get Microchip parts at Radio Shack! One discouraging discovery was that many vendors imply or state on their web sites that certain parts are available when in fact they are still in development and in some cases will not be available for many months, if ever. Fujitsu is particularly bad in this regard, as are Motorola and some others. cheers, g. ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Re: Avionics-List Digest: 01/13/00
Date: Jan 14, 2000
Glen, Thanks. Did you see the prices of the Zanthic development boards? John ________________________________________________________________________________
Date: Jan 14, 2000
From: barlow(at)thegrid.net
Subject: Re: Avionics-List Digest: 01/13/00
Glen, all, I'm still out here in the boonies at the end of a bad phone line. I'm using someone else's computer and don't have all my info with me so I can't offer much concrete help right now. I will, however, make some general observations. The current parts availability problem is bigger than most of you realize, I suspect. In general, chip demand is out running production capacity at the moment. Also, the semiconductor business has become somewhat fragmented in recent years. We have many chip companies that don't have their own fab lines, and others, like Taiwan Semi, that do mostly contract manufacturing for others. This greatly complicates production scheduling. With most of the available fab capacity tied up filling real orders, no one wants to stop and crank out a batch of some new design just to fill up distributors shelves. The net result is that most of what is available from distributors is older chip designs that have been in production for some time. Look at the date codes on the stuff you get from Digi-Key, etc. Microchip (the old GI semi) is one of the best about getting their newer stuff into distribution, and even they are just now getting their 16F877 on the shelves. They were giving out samples last July! Perhaps I should explain "samples". These are chips that are produced in small quantities on separate, small, slow fab lines both to verify the design and provide engineering samples for customers. Our problem seems to be that the better CAN chips are mostly new designs and they are sold mostly to customers in industries with rather long design cycles (i.e. automotive, industrial equipment). This translates to chips that are being sampled now maybe not being available "off the shelf" for a year. On the other hand, given the part time nature of our endeavor, we also, realistically, have a long design cycle. (I hope none of you think we are going to have anything useful running this year.) So, I think parts that are sampling now are just about right for us, time wise. I can assure you that the chips are real, they are out there. It's just that rather than sitting on distributors shelves, they are in the trunks of the company cars that the reps drive around. The trick is to move them from there to our workbenches. I've played this game before, it takes some patience, it can be frustrating, but it can be done. Regarding development software: This, as you seem to have noticed, can be a killer. Much of my recently developed fondness for the Fujitsu parts is based on the fact that I have in my posession a full set of development software that Fujitsu sent me for free. It's roughly comparable to what Microchip gives out for their chips except it also includes a C compiler. In addition, the Fujitsu chips have a built in serial boot loader, which combined with their target monitor (debugger) and the ability to run code out of external RAM, pretty much replaces an ICE unless you really need a real time trace. This combined with free development software is a lot like a $5000 gift. Oh, BTW, the chips themselves are rather nice also. So, when I get back to the mainland next week, I will resume my quest for the chips. I'll keep you folks posted on my progress. Right now I'm going for a hike, and then I'll spend a few more hours reading CAN Kingdom stuff. Later, Jeff > > > Has anyone found a source for small quanities of any of the CAN chips? > >After too many hours on the internet and the phone, I found that I could >get the Microchip MCP2510 from Pioneer (www.pios.com), and the TI TMS320F241 >from Arrow and one other vendor (I forget which, my notes are at home). > >Arrow seems to be higher priced than anyone else, and my first impression >is that they are difficult to deal with. > >I got the Atmel ATM-ATSK200 eval board from Insight, and some Atmel parts >from Pioneer. Both vendors were quite satisfactory. > >The Microchip CAN development system, about $250, was not in stock anywhere. >It appears that there is high demand for this and for the MCP2510. There >is also high demand for the uC I want to use, the Atmel AT90S4433, but it >is possible to get them. > >I would like to use the TI part, but so far have not been able to find any >low cost development software. To do the job right with the TI part it would >be desirable to have a JTAG pod, about $1000, in addition to the rather >expensive debug software. Were this a commercial venture I would go with TI, >for my hobby project I think I'll stick with Atmel and an external CAN >controller. > >A big fat "F" to Motorola, Fujitsu, Infineon, and various others. Actually >it is not an issue of right or wrong, it is perfectly reasonable for companies >to discourage small hobby orders. My own company does not sell in small >quantities or to individuals, and that is OK. I am just thankful that there >are a few companies that seem to encourage small orders - Microchip and >Atmel, in particular. You can even get Microchip parts at Radio Shack! > >One discouraging discovery was that many vendors imply or state on their web >sites that certain parts are available when in fact they are still in >development >and in some cases will not be available for many months, if ever. Fujitsu >is particularly bad in this regard, as are Motorola and some others. > >cheers, >g. > ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Headset cable?
Date: Jan 15, 2000
Hi all, about a year and a half ago, I built myself an active noise reduction headset by using the earphones (with their little microphones built in) and the electronics of a commercial consumer ANR headset (called "Noisebuster extreme" - and meant for commercial flight passengers). I took this headset apart and installed the earpieces in the shells of a David Clark hearing protector (the ones for ground staff without any electrics in them at all). I purchased a microphone boom and had an aviation mike given to me by another pilot. I then wired everything up using a separate thin shielded single core cable for the mike and the "noisebuster" cable for everything else. It works phantastic! In fact, in a new plane of a friend which is particularly quiet (Rotax 912 engine) I felt for a while that I had to switch the noise reduction off, because I couldn't hear enough of the engine until I got used to it.... I'm using it in my Sapphire all the time (two stroke engine right behind my head) and find it very good indeed. I'm telling you this level of detail because others might like to do this.... However: the cables used by the efficient and cost-effective Chinese manufacturers have skimped on the cables.... 5 VERY tiny copper strands per tiny conductor only... I've had to slice open, find the break in the copper and repair it 5 times now and the cable is getting shorter all the time. Unfortunately, I've not found any (single) cable which contains 2 shielded conductors, insulated from each other (from the noise detecting microphones), as well as 2 pairs of unshielded speaker conductors. An additional shielded conductor for the aviation mike would be nice as well, instead of the separate cable. Obviously the speaker wires could be shielded pairs, as long as they were insulated from each other.... Does anyone have any idea where I could source something like this? I don't mind if the cable is reasonably thick, as long as it's nice and flexible. Joe Hovel ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Jan 15, 2000
Subject: 1999 List of Contributors #2!
Dear Listers, Below is the final List of Contributors for 1999 as promised. Again, I would like to thank everyone that made a generous contribution in 1999 to support the continued operation of these email Lists. Your support directly makes the quality and quantity of this service possible. Thank you! Matt Dralle EMail List Administrator RV-4 Builder, #1763 - N442RV =================== 1999 List of Contributors #2 ==================== Adamson, Arden Allender, Patrick Anonymous from MN Asher, M.E. Baxter, Rob Bell, Doug Bendure, Ryan Bergh, David Berrie, Robert Blake, J.I. Boucher, Michel Bragg, Medford Briegleb, Ross Brietigam, Charles Broomell, Glenn Brusilow, Michael Chatham, Robert Clary, Buck Coats, Lonnie Cook, Craig - Golf Instruments Co. Cooper, James Cribb, William Jr. Crosby, Harry Dane, Bill Von Dziewiontkoski, Bob Ellenberger, Mike Embree, Roger Faatz, Mitch Fasching, John Gibbons, Robert Glauser, David Gold, Andy -Builder's Bookstore 10% Gregory, Steve Grenier, Raymond Guarino, Michael H., Harold - E.P.M.AV Corp Hale, Brian Hunt, Wallace Johnston, Leroy Jordon, Don Killion, Clay Klingmuller, Dr. L.M. Magaw, David Mains, Ralph Maltby, Michael Martin, Cliff - Martin Metal Fab Mazataud, Hyun Sook McBride, Duncan McDonald, James Mendenhall, Elbie - E.M Aviation Mitchell, Duane Morley, Harold Peck, Phil Pessel, Garnett Rodebush, James Ross, Jonathan Schmidt, John Scully, William Smith, Steven Spence, Stephen Triff, Wes Wagoner, Richard Weaver, Brian Wiegenstein, John Wiley, Robert Wilson, Donald -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: embedded GPS Receivers
Date: Jan 16, 2000
I know this is a bit early for the glass cockpit prototypes, but some of you may want to start at this end.... Here are a couple of embeddable GPS receiver URLs. I'm particularly fascinated by the Rojone unit as it can provide acceleration data which might allow a virtual turn and bank indicator, G-meter etc as well as nav data...? http://www.rojone.com.au/gpsgenius.htm http://www.trimble.com/oem/om_embed.htm The trimble unit is cheaper but not as capable.... Joe Hovel ________________________________________________________________________________
Date: Jan 17, 2000
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: embedded GPS Receivers
Joe Hovel wrote: > I know this is a bit early for the glass cockpit prototypes, but some of you > may want to start at this end.... Here are a couple of embeddable GPS > receiver URLs. I'm particularly fascinated by the Rojone unit as it can > provide acceleration data which might allow a virtual turn and bank > indicator, G-meter etc as well as nav data...? > http://www.rojone.com.au/gpsgenius.htm > http://www.trimble.com/oem/om_embed.htm > The trimble unit is cheaper but not as capable.... Thanks for the URLs. However: I tend to think that with handheld GPS being relatively cheap, it doesn't make too much sense to build our own. (Having said that, I'm intending to use one of the $20 GPS boards in my plane). What we need to look at is a standard interface to a GPS. The obvious candidate is NMEA-0183. Reading the Rojone page, it doesn't say that it can output acceleration data. What I think it means when it says "Acceleration 4g max." is that it can maintain lock under those conditions. Or perhaps you read that somewhere else? Frank. ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Jan 16, 2000
Subject: Confusion Over "List of Contributors"...
Hi Listers, I'm really sorry for the confusion over the most recent posting of the List of Contributors #2. List #2 contained only the contributor names *since* the List #1 was posted. So, if you weren't on List #2, you were likely on List #1. Below are URLs to each of the LOC #x postings. Again, sorry for the confusion. I should have made it more clear in the verbiage. Thanks to everyone, Matt Dralle Email List Admin. ============================= LOC #1 and #2 ================================ List of Contributors #1 - 1999 ------------------------------ http://www.matronics.com/searching/getmsg_script.cgi?INDEX=29144?KEYS=list_of_con?LISTNAME=Homebuilt?HITNUMBER=2?SERIAL=11144111847?SHOWBUTTONS=NO List of Contributors #2 - 1999 ------------------------------ http://www.matronics.com/searching/getmsg_script.cgi?INDEX=29144?KEYS=list_of_con?LISTNAME=Homebuilt?HITNUMBER=2?SERIAL=11144111847?SHOWBUTTONS=NO ============================================================================ -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
Date: Jan 16, 2000
From: Matt Dralle 925-606-1001 <dralle(at)matronics.com>
Subject: Re: (Whoops) Confusion Over "List of Contributors"...
> >Okay, here are the *real* URLs. Sorry... > > >Matt Dralle >Email List Admin. > > >============================= LOC #1 and #2 ================================ > > > List of Contributors #1 - 1999 > ------------------------------ > > >http://www.matronics.com/searching/getmsg_script.cgi?INDEX=29144?KEYS=list_ >of_con?LISTNAME=Homebuilt?HITNUMBER=2?SERIAL=11144111847?SHOWBUTTONS=NO > > > List of Contributors #2 - 1999 > ------------------------------ > > >http://www.matronics.com/searching/getmsg_script.cgi?INDEX=53146?KEYS=list_ >of_con?LISTNAME=Homebuilt?HITNUMBER=1?SERIAL=11144111847?SHOWBUTTONS=YES > > >============================================================================ ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Jan 16, 2000
Subject: Re: (No, Really - Here are the URLs) Confusion Over "List
of Contributors"... Geeze, I can't seem to type today. Here are the *real*, *REAL* URLs. Sorry for so many posts... Ack Matt Dralle Email List Admin. ============================= LOC #1 and #2 ================================ List of Contributors #1 - 1999 ------------------------------ http://www.matronics.com/searching/getmsg_script.cgi?INDEX=29144?KEYS=list_of_con?LISTNAME=Homebuilt?HITNUMBER=2?SERIAL=11144111847?SHOWBUTTONS=NO List of Contributors #2 - 1999 ------------------------------ http://www.matronics.com/searching/getmsg_script.cgi?INDEX=53146?KEYS=list_of_con?LISTNAME=Homebuilt?HITNUMBER=1?SERIAL=11144111847?SHOWBUTTONS=NO ============================================================================ -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Sunlight Readable Displays - non-glare
Date: Jan 18, 2000
>>Also consider the angles involved... if you picture a mirror mounted falt >>on the panel, you would not see a reflection of the windows. You'd see >>your lap, the copilot's seat, the floor, etc. Bust a mirror mounted on >>the floor angled up will have anice view of the windows (or throgh the >>canopy!). > >You are going to want some kind of anti-glare coating on the display. OCLI >used to make very nice anti-glare coating. I had a monitor with their >coatings on it and it was a real joy to use. Clearly, that is true... however, what is acceptable in my panel may be unacceptable in direct sunlight, or in a plane with a completely clear canopy... Steve steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Jan 18, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Sunlight Readable Displays - non-glare
On Tue, 18 Jan 2000, Steven J. Devine wrote: > >>Also consider the angles involved... if you picture a mirror mounted > flat > >>on the panel, you would not see a reflection of the windows. > >You are going to want some kind of anti-glare coating on the display. > > Clearly, that is true... however, what is acceptable in my panel may be > unacceptable in direct sunlight, or in a plane with a completely clear > canopy... Well, antireflection coatings are going to help regardless. I notice that King puts antireflection coatings on their high-end instruments and it makes a huge difference. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Jan 21, 2000
From: Scott Stewart <kstewart(at)tisd.net>
Subject: Antenna connection to transciever
I'm making a connection from RG-58 to a right angle tray connector. Looks like center conductor just solders on, but how does the shield connect? Is this just crimped with the small metal tube between the center dielectric and the shield braid? Any help/comments/etc are appreciated. Scott Stewart Fisher Flying Products Dakota Hawk Bay City, TX ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: CDA101/CAN Kingdom CD rom
Date: Jan 22, 2000
Hey Guys, I just recieved the CDA101 CD rom from Dave Purdy. It includes quite a bit of info including software for the ST2000. I just recieved it yesterday so I haven't been able to go thru all of it yet. Any ideas on how we might distribute the contents? Their web sight is suposed to be up in another couple of weeks. John ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: TTP Time Triggered Protocal
Date: Jan 22, 2000
Guys, Check this out. http://www.eet.com/story/OEG19990507S0007 A news release which talks about this protocal for real time control. This or similar is the approach that Boeing used with eithernet for the 777. Purdy's group is also working on this. There are some web sites listed on the CD and you can find more by searching. Try the following: http://www.tttech.com/ http://www.ttpforum.org/ John ________________________________________________________________________________
From: "Dennis Elkins" <elkinde1(at)hotmail.com>
Subject: Narco radio
Date: Jan 22, 2000
I'm in the process of cutting a deal to buy a NARCO Model Mark 12 NAV/COM. Does anyone know if this is a good radio or how old it might be? Dennis Elkins ________________________________________________________________________________
From: "Cy Galley" <cgalley(at)accessus.net>
Subject: Re: Narco radio
Date: Jan 22, 2000
Better check to see if it is not a 720 channel radio that it is legal to transmit with the FCC. Cy Galley - Editor, B-C Contact! (Click here to visit our Club site at http://www.bellanca-championclub.com) -----Original Message----- From: Dennis Elkins <elkinde1(at)hotmail.com> Date: Saturday, January 22, 2000 11:18 AM Subject: Avionics-List: Narco radio > > >I'm in the process of cutting a deal to buy a NARCO Model Mark 12 NAV/COM. >Does anyone know if this is a good radio or how old it might be? > >Dennis Elkins > > ________________________________________________________________________________
Date: Jan 22, 2000
From: Allan Chong <allan(at)alum.mit.edu>
Subject: Re: Avionics-List Digest: 01/21/00
> > I'm making a connection from RG-58 to a right angle tray connector. > Looks like center conductor just solders on, but how does the shield > connect? Is this just crimped with the small metal tube between the > center dielectric and the shield braid? I'm not sure what a right angle tray connector is, but... Go to an electronics store (radio shack might have them, but probably not.) Jameco is one mail order place around here. They usually have modular crimp tools for RG-58, RG-59, and RG-62 as well as all the little end parts. You really need to crimp them to make them work right. Cheaper tools should be about $30. ________________________________________________________________________________
Date: Jan 23, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN Kingdom Module Scheduling
Back from Bali. In transit and layover in the Hong Kong airport, I read most of the CAN documents I brought with me: 1. CAN Higher Layer Protocols: http://www.stzp.de/papers/icc97/icc97_e.html 2. A CAN Kingdom Rev. 3.01 http://www.kvaser.se/canking/std/index.htm In http://www.kvaser.se/canking/std/chap5.htm , Chapter 5 - Kingdom Time, the protocol address the desirability of being able to sequence messaging between modules over the CAN. In the second paragraph: "There are two major classes of realtime systems: Event driven and Time driven. Over the years there have been discussions about which class is best. In society we mix both classes without thinking about it. For example, think about people transport systems: Underground represents a time driven system and taxi an event driven system. If you want to use the underground to get to a meeting you have to check the schedule and be at the station on time for the train departure. Alternatively you can call for a taxi and you will have it as soon as there is one available. Which alternative is the best one? There is no definite answer. From that point, the discussion goes on about synchronization messages. Marlin ________________________________________________________________________________
Date: Jan 23, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN Kingdom Pros and Cons
Pros: *** Makes optimal use of the bandwidth: High priority messages can be transmitted that are very small in size (number of bytes). *** Makes optimal use of the CAN hardware protocol: 1. Allows more than eight bytes known as lines to be transmitted by coordinating the transmission of multiple messages known as letters. (A document consists of a complete message comprising one or more letters) 2. Allows data to "float" into the identifier field when the identifier size is short. *** Allows both time synchronization as well as event driven messages. Additionally, handles message prioritization. *** Compartmentalization of development of modules: By following the rules, Ted and Alice may design their modules independently. Later Larry (the kingdom founder or system integrator) should be able to easily integrate these two modules. Cons: *** No quick resets: System malfunction or power failure requires a fair amount of data passage between modules and the king module, wherein each module passes a "form" (a description of the format and units of the data the module transmits, or in Kingdom lingo: a description of the format and units of the products the city exports) For flexibility, each module might have several forms to appease a wide range of Kingdom designers (like for different units or data arrangements). I do not know how long this would take in our simpler GA (General Aviation) applications, but it certainly will be a serious issue in a complex system. [Q: Is it legitimate in CAN Kingdom to perform this initialization only once at installation and have the King store these results on EEPROM or other form of reliable nonvolatile memory] *** Probably more complex than most other higher layer protocols: CAN Kingdom 1. does a lot, and 2. Enables plugging in CAN-Kingdom-conforming Off-The-Shelf products (though none probably exist yet). These two factors make CAN Kingdom more complicated to program. Each module must follow many rules and operate in several different modes. This will, no doubt, add time to the software development (though, I'm heartened to learn that we now have some examples in-hand to model after) and may require MCUs with more memory so that the more complex programs can be accommodated. Marlin ________________________________________________________________________________
Date: Jan 23, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Narco radio
On Sat, 22 Jan 2000, Dennis Elkins wrote: > > > I'm in the process of cutting a deal to buy a NARCO Model Mark 12 NAV/COM. > Does anyone know if this is a good radio or how old it might be? You need to say which Mark-12 it is. The Mk-12 and Mk-12a models are vacuum tube radios. They were great in their day (early/mid 1960's) but are mostly boat-anchors today. The Mk-12D is a modern solid-state radio that is quite nice. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Jan 23, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Antenna connection to transciever
On Fri, 21 Jan 2000, Scott Stewart wrote: > > I'm making a connection from RG-58 to a right angle tray connector. > Looks like center conductor just solders on, but how does the shield > connect? Is this just crimped with the small metal tube between the > center dielectric and the shield braid? Your radios and trays should have come with an installation manual that covers the cable installation. That said, let me try to answer from memory. The connectors on avionics trays usually have a nipple whose opening is large enough to admit the center conductor and insulation but not the braid and outer sheath. Some come with a collar that fits over the nipple that allows you to crimp the braid over the nipple. If there is no collar you are expected to push back the braid enough so that it compresses and enlarges enough to fit over the nipple. You then solder the braid to the nipple. You also solder the center conductor internally. I just reread what I wrote above and realize how inadequate it is without pictures. Hopefully it helps. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Jan 24, 2000
Subject: Re: Audio question
From: "Shelby Smith" <shelbyrv6a(at)mindspring.com>
Brian, Could you give me a little more detail on how to do this? Where to look for the right specifications etc. I just bought a camcorder DV and would like to set this up. Thanks, -- Shelby Smith shelbyrv6a(at)mindspring.com RV6A - Skinning Fuselage - 200HP N95EB - reserved ---------- >From: Brian Lloyd <brian(at)lloyd.com> >To: avionics-list(at)matronics.com >Subject: Re: Avionics-List: Audio question >Date: Tue, Dec 28, 1999, 10:18 AM > > >> > I'd like to take the headphone audio output from an aircraft's >> > intercom/radio system and use that to feed the microphone input to a >> > camcorder. Since the microphone, I'm sure, uses much lower voltage and >> >> Headphone levels are usually somewhere near 0 dbm (zero decibels relative >> to on milliwatt). At 600 ohm impedance, that means a voltage level of >> about 0.7 V. > > Oh, another thought; if your camcorder has a line-level input, you can > probably plug the headphone output directly into that with no attenuation. ________________________________________________________________________________
Date: Jan 25, 2000
From: Warren Gretz <gretz_aero(at)h2net.net>
list-aviation , list-avionics , list-beech , list-cessna , list-engines , list-ez , list-glasair , list-lancair , list-piper , list-tailwind , list-seaplane , list-yak , list-zenith
Subject: wire lacing string
Greetings to the List, I have eight spools of the wire lacing string I told many of you about a few weeks ago. If any of you are interested please call, leave a detailed message, or send an e-mail (off List), include your VISA or MASTER CARD number, expiration date of the card, your name, address, and how many rolls you want. FIRST EIGHT THAT CONTACT ME GET THE SPOOLS OF STRING. The spools of string are new and $12 ea. including shipping to a US address. This is a very low price for this product. What is this string anyway you ask! It is string or lacing tape used to tie up wires into bundles. It is the most light weight, and most inexpensive product for doing this job. I have used this type of material extensively and I really like it.. It is extremely fast to tie and use.-- Make a clove hitch around the bundle, and then a square knot to finish. I think you will like it as much as I do. It is self extinguishing polyester #MIL-T-43435B, Type II, Finish C, Size 3. In short this is what is used most often for this job. It is flat braided so it will not cut into or deform as badly as round string. The finish of this material makes knots stay tied. The spools are 500 yd. spools. Granted, a spool is enough to do many airplanes, but your will find many uses for this stuff as I have. Or, sell what you have left over to another builder when your are done. Thanks Warren Gretz Gretz Aero 303-770-3811 gretz_aero(at)h2net.net ________________________________________________________________________________
Date: Jan 28, 2000
Subject: Re: Brian Lloyd Audio question for
From: "Shelby Smith" <shelbyrv6a(at)mindspring.com>
---------- >From: "Shelby Smith" <shelbyrv6a(at)mindspring.com> >To: avionics-list(at)matronics.com >Subject: Re: Avionics-List: Audio question >Date: Mon, Jan 24, 2000, 9:54 PM > > > Brian, > > Could you give me a little more detail on how to do this? Where to look for > the right specifications etc. I just bought a camcorder DV and would like to > set this up. > > Thanks, > > > -- > Shelby Smith > shelbyrv6a(at)mindspring.com > RV6A - Skinning Fuselage - 200HP > N95EB - reserved > > ---------- >>From: Brian Lloyd <brian(at)lloyd.com> >>To: avionics-list(at)matronics.com >>Subject: Re: Avionics-List: Audio question >>Date: Tue, Dec 28, 1999, 10:18 AM >> > >> >>> > I'd like to take the headphone audio output from an aircraft's >>> > intercom/radio system and use that to feed the microphone input to a >>> > camcorder. Since the microphone, I'm sure, uses much lower voltage and >>> >>> Headphone levels are usually somewhere near 0 dbm (zero decibels relative >>> to on milliwatt). At 600 ohm impedance, that means a voltage level of >>> about 0.7 V. >> >> Oh, another thought; if your camcorder has a line-level input, you can >> probably plug the headphone output directly into that with no attenuation. > > > ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Jan 31, 2000
Subject: Re: Avionics-List Digest: 01/22/00
> I'm in the process of cutting a deal to buy a NARCO Model Mark 12 NAV/COM. Does anyone know if this is a good radio or how old it might be? The Mk 12 is a tube radio, unless you are starting a museum you do not want it at any price. It is not reliable, and probably not even legal due to new frequency tolerance regs. The Mk12E, however, is, based on my experience, a really nice radio. g. ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Free PCB design software?
Date: Feb 01, 2000
I found a source of GPL PCB design software. Unfortunately it's not complete because it requires AutoCAD. However, those interested in taking a look can check this out: Announcing availabilty of SATCAD source code. SATCAD is a schematic capture, pcb design and tooling package. SATCAD used to be a commercial package called SATCAM. * - DOS based * - used AutoCAD as the graphics editor * - text based system * - extensive component; schematic and pcb library * - library components are extracted into AutoCAD DWG format * - extraction of schematic, board and tooling information is from AutoCAD DWG format * - sold a number of copies during the mid to late eighties * - company that paid for development went bankrupt in late eighties * - no development since 1990 * - was used to design (and manufacture) many complex multi-layer boards * - emphasis on manufacturability * - metric, imperial units - technology tables to allow arbitrary technology * - built-in tables for 8/8, 12/12 technology. Surface mount... * - SATCAD consists of some 40 programs. I approached the current intellectual property owner in June 1998, (Loctech) and they agreed to release the source and library under the GPL. Part of that agreement is that the program be called some other name than SATCAM, hence SATCAD. (SATCAM is a trading name of Loctech in Australia. Loctech does PCB design work). The source code, dos executables, manual and many other bits and pieces are at ftp://ftp.progsoc.uts.edu.au/users/jhonan/satcad This description (in case you have come by through other means than web browsing) is http://www.progsoc.uts.edu.au/~jhonan/satnotes.html Please note that without the full kit, including the missing manual and AutoCAD package, this package only suitable for hacking on, even though this system was used to design many, many PCB's. Possible uses: * - library might be a good for other PCB design packages (I have tried to place the library under a stricter form of the GPL, whereby it can't just be ripped out and used in commercial packages). * - some of the ideas are quite good. The seperation between the drawing editor and the post and pre-processing tools is reminiscent of how compilers work. * - if you have AutoCAD (release 9 to 11, from memory), then you could actually design circuit boards. Difficulties: * - have to have a graphics editor. Would need to tailor output and input routines for the required drawing format. * - some bad coding practises - writing structures. * - libraries are out of date * - some files are missing from the disks I have. Specifically some of the drawing sheets are not the latest version. If someone has a set of installation disks they might get in touch with me (jhonan(at)mpx.com.au) and send me the missing files. Until I can get these disks, it is probably not worth trying to run SATCAD. * - the manual is written in Ventura format. This makes it easy to turn into html. However I only have the source for version 2.0 of the manual, 2.1 was the latest. The interface is somewhat different, thought the major components are the same. Philosophy behind SATCAD. SATCAD is actually a text based system. This is somewhat hard to square with the notion that PCD and schematic design are inherently visual processes. If you think of a drawing editor in the same way as a text editor, then it goes part of the way to explaining it. SATCAD makes up parts as building blocks. You insert your parts into your drawing, then connect up. When done, you 'compile your drawing', extracting parts, interconnections etc. Thus a trace line can be drawn with a zero width line. This line is extracted, and depending on context is a metal trace with a definite width, or simply the notion that a pin is connected to another pin. Parts, for example, are heirarchical blocks. There are various attributes, and text entities. These can be pin numbers, pin names or part number. There are circles on various layers. These can be pins, or mounting holes, again depending on layers. What would be good * - get a more recent copy of the manual (scanned in?) * - get missing files so a full working version under DOSEMU would be possible * - convert the software to run under Linux / Unix. This would not be hard. * - get the software to work with a graphics editor that works under Linux * - update the libraries * - extend features to full EDA Under DOS To run the software, you need at least these things in your config.sys / autoexec.bat CONFIG.SYS DEVICE=\DOS\ANSI.SYS FILES BUFFERS=30 AUTOEXEC.BAT PATH = C:\ACAD;C:\SATCAM SET ACAD=C:\ACAD SET SATCAM=C:\SATCAM ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Free PCB design software?
Date: Feb 01, 2000
For free PCB design software, check out www.ivex.com. Free demos are, I think, limited to 100 pins, at which point you must whip out your credit card. They have schematic capture and PCB layout programs. -Matt ________________________________________________________________________________
From: Matthew Mucker <mmucker(at)airmail.net>
Subject: FW: Zenith-List: (AHRS) for General Aviation Aircraft
Date: Feb 04, 2000
This was posted to the Zenith-List. I thought I'd forward it to this list. The abstract sure sounds promising! -Matt -----Original Message----- From: Grant [SMTP:gfcorriv(at)total.net] Sent: Friday, February 04, 2000 6:15 PM Subject: Zenith-List: (AHRS) for General Aviation Aircraft --> Zenith-List message posted by: Grant Well, as posted earlier, I am on the hunt for an affordable Attitude/Heading Gyro system for a Zodiac that might serve to replace the vacuum system. It doesn't look like there's anything readily available just yet, but from the following research paper from Stanford University, I suspect that it won't be too long before we will see an affordable AHRS (i.e. electronic attitude/heading reference systems) available for our aircraft, using GPS to provide the basic information rather than gyros) http://einstein.stanford.edu/gps/ABS/ahrs_for_ga.html Inertially Aided GPS Based Attitude Heading Reference System (AHRS) for General Aviation Aircraft Roger C. Hayward, Demoz Gebre-Egziabher, Matt Schwall, J. David Powell, Department of Aeronautics and Astronautics Stanford University John Wilson Seagull Technology Presented September 1997 at ION GPS-97, Kansas City, Missouri ABSTRACT GPS was used with ultra-short baselines (2-3 carrier wavelengths) in a triple antenna configuration to obtain attitude for General Aviation (GA) aircraft. Through algorithm selection and error source calibration, accuracies of 0.1 0.15 and 0.2 rms were obtained for pitch roll and yaw respectively. The accuracy and robustness of the system was enhanced by combining the ultra short-baseline GPS attitude solution with an attitude solution derived using inexpensive automotive grade rate gyros. The solid state gyros allow coasting through temporary GPS outages lasting 2 minutes with attitude errors less than 6 degrees. The combined GPS-inertial system has a 20Hz output sufficient to drive glass cockpit type displays. A prototype system was built and flight tested in a Beechcraft Queen Air. The system installed and flight tested in the Queen Air compares favorably to the performance of the existing vacuum driven instruments. It is currently being used in ongoing research at Stanford with futuristic high resolution displays[1]. ________________________________________________________________________________
Date: Feb 04, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: FW: Zenith-List: (AHRS) for General Aviation Aircraft
That's interesting. I'll have to read more about it, but it reminds me of the Seagull Technologies system: http://www.seagull.com , who claim they have tested such a system on a LongEze (I think). Though I can't seem to find the description on their website. Marlin Matthew Mucker wrote: > > > This was posted to the Zenith-List. I thought I'd forward it to this list. The abstract sure sounds promising! > > -Matt > > -----Original Message----- > From: Grant [SMTP:gfcorriv(at)total.net] > Sent: Friday, February 04, 2000 6:15 PM > To: Zenith list at Matronics; Robert L. Nuckolls, III; Bob Masters > Subject: Zenith-List: (AHRS) for General Aviation Aircraft > > --> Zenith-List message posted by: Grant > > Well, as posted earlier, I am on the hunt for an affordable Attitude/Heading > Gyro system for a Zodiac that might serve to replace the vacuum system. It > doesn't look like there's anything readily available just yet, but from the > following research paper from Stanford University, I suspect that it won't > be too long before we will see an affordable AHRS (i.e. electronic > attitude/heading reference systems) available for our aircraft, using GPS to > provide the basic information rather than gyros) > > http://einstein.stanford.edu/gps/ABS/ahrs_for_ga.html > > Inertially Aided GPS Based Attitude Heading > Reference System (AHRS) for > General Aviation Aircraft > > Roger C. Hayward, Demoz Gebre-Egziabher, Matt Schwall, J. David Powell, > > Department of Aeronautics and Astronautics > Stanford University > > John Wilson > Seagull Technology > > Presented September 1997 at ION GPS-97, Kansas City, Missouri > > ABSTRACT > GPS was used with ultra-short baselines (2-3 carrier wavelengths) in a > triple antenna configuration to obtain attitude for General Aviation (GA) > aircraft. Through algorithm selection and error source calibration, > accuracies of 0.1 0.15 and 0.2 rms were obtained for pitch roll and yaw > respectively. The accuracy and robustness of the system was enhanced by > combining the ultra short-baseline GPS attitude solution with an attitude > solution derived using inexpensive automotive grade rate gyros. The solid > state gyros allow coasting through temporary GPS outages lasting 2 minutes > with attitude errors less than 6 degrees. The combined GPS-inertial system > has a 20Hz output sufficient to drive glass cockpit type displays. A > prototype system was built and flight tested in a Beechcraft Queen Air. The > system installed and flight tested in the Queen Air compares favorably to > the performance of the existing vacuum driven instruments. It is currently > being used in ongoing research at Stanford with futuristic high resolution > displays[1]. > ________________________________________________________________________________
Date: Feb 05, 2000
From: dab(at)froghouse.org
Subject: Re: FW: Zenith-List: (AHRS) for General Aviation Air
craft On 4 Feb, Marlin Mixon wrote: > That's interesting. I'll have to read more about it, but it reminds me > of the Seagull Technologies system: http://www.seagull.com , who claim > they have tested such a system on a LongEze (I think). Though I can't > seem to find the description on their website. I talked to the Seagull folks a couple years ago at Oshkosh. Basically, their plan was to take the Stanford research and commercialize it. They went to even shorter baselines than the Stanford work, less than a wavelength, to avoid the integer wavelength problem. They seem to have removed the device from their web page though I did find a press release from last summer saying they were aiming for certification in 2001. -Dave ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Feb 07, 2000
Subject: RE: (AHRS) for General Aviation Aircraft
>Well, as posted earlier, I am on the hunt for an affordable Attitude/Heading Gyro system for a Zodiac that might serve to replace the vacuum system. It doesn't look like there's anything readily available just yet, but from the following research paper from Stanford University, I suspect that it won't be too long before we will see an affordable AHRS ... A commercial company, I forget who, has or will have soon such a system. it is not cheap, tho... I used electric gyros in my 601HD. Another alternative is to install a vacuum pump on your Rotax 912 (if you are using that engine) and then use standard vacuum gauges. Either system will be much cheaper than the AHRS now, although in a few years the AHRS system has the potential to be cheaper. cheers, g. ________________________________________________________________________________
Date: Feb 07, 2000
From: Mac Barksdale <skyranger(at)hartcom.net>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
Don't forget that venerable old venturi system ! Dependable, always works, [except in ice] No moving parts; doesn't wear out; no overhaul; and no parts to buy ! flown with those many many hours. The latest Aviation Consumer [Feb2000] has a good report on Attitude Indicators. Also don't forget the turn coordinator is easy to fly and is electric. Also the S-tec simplest wing leveler auto pilot works with the turn coordinator AND can always fly your plane in the event of Captain Confusion ! Just some thoughts. Regards, Mac ________________________________________________________________________________
Date: Feb 07, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
On Mon, 7 Feb 2000, Mac Barksdale wrote: > > Don't forget that venerable old venturi system ! Dependable, always works, > [except in ice] No moving parts; doesn't wear out; no overhaul; and no > parts to buy ! flown with those many many hours. Mount the venturis on the belly in the outflow from the exhaust and engine cooling air to keep the venturis warm and ice-free. That is the right place to put your venturis anyway. Having just installed a set of vacuum gyros in my 1949 Piper PA-16 Clipper last year (it is now full IFR) I found out some interesting things about venturis and vacuum instruments. Modern vacuum gyros are air hogs. They need a LOT of airflow to operate properly. I had to install two of the biggest venturis I could find to operate a standard AI and DG. Even so I rarely see anything close to 5" of vacuum. In full-throttle climb at 80 mph I see about 4". At normal approach speed on an ILS (80 mph) I get just about 3" of vacuum. 100 mph (IAS) cruise nets me about 4" also. Fortunately the gyros seem to perform properly with that much suction. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Feb 07, 2000
From: Mac Barksdale <skyranger(at)hartcom.net>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
Right ON ! Brian ! I forgot about putting them in the engine air exhaust. Glad they are working well. Mac ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
Date: Feb 08, 2000
Another neat trick I read in the Subaru list (airsoob) is to place a tube--not a venturi--directly into the exhaust flow so that the end of the tube exits downstream of the exhaust gasses. The poster claimed that he got so much suction out of it that he considered putting in a relief valve in the system. Fact or fantasy? Try it, it's not too intrusive and probably worth experimenting with. Also, I don't know if its important, but this method would seem to to me to admit less spent exhaust gasses into the system than putting a venturi in the exhaust flow. Marlin >From: Brian Lloyd <brian(at)lloyd.com> >On Mon, 7 Feb 2000, Mac Barksdale wrote: > > > > > > Don't forget that venerable old venturi system ! Dependable, always >works, > > [except in ice] No moving parts; doesn't wear out; no overhaul; and no > > parts to buy ! flown with those many many hours. > >Mount the venturis on the belly in the outflow from the exhaust and engine >cooling air to keep the venturis warm and ice-free. That is the right >place to put your venturis anyway. > >Having just installed a set of vacuum gyros in my 1949 Piper PA-16 Clipper >last year (it is now full IFR) I found out some interesting things about >venturis and vacuum instruments. Modern vacuum gyros are air hogs. They >need a LOT of airflow to operate properly. I had to install two of the >biggest venturis I could find to operate a standard AI and DG. Even so I >rarely see anything close to 5" of vacuum. In full-throttle climb at 80 >mph I see about 4". At normal approach speed on an ILS (80 mph) I get >just about 3" of vacuum. 100 mph (IAS) cruise nets me about 4" also. >Fortunately the gyros seem to perform properly with that much suction. > >Brian Lloyd >brian(at)lloyd.com >+1.530.676.6513 > > ________________________________________________________________________________
Date: Feb 07, 2000
From: Mac Barksdale <skyranger(at)hartcom.net>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
Exhaust gases INTO system, Marlin ? You think it is going to go against the suction pressure, Huh ? ? Mac > >=========================== > ________________________________________________________________________________
Date: Feb 07, 2000
From: Warren Gretz <gretz_aero(at)h2net.net>
list-aviation , list-avionics , list-beech , list-cessna , list-engines , list-ez , list-glasair , list-homebuilt , list-lancair , list-piper , list-rocket , list-sailplane , list-seaplane , list-tailwind , list-ultralight , list-warbird , list-yak , list-zenith
Subject: [Fwd: RV-List: Aeroelectric.com]
I wanted to pass this on to all of you. Warren Gretz Date: Mon, 07 Feb 2000 20:24:22 -0700 From: Warren Gretz <gretz_aero(at)h2net.net> Subject: Re: RV-List: Aeroelectric.com --> RV-List message posted by: Warren Gretz I just talked to Bob yesterday and asked him if his internet host/provider has a problem. They do. He said he has not been able to do anything since last Thursday. Today, Monday he was going to seek out a new provider that hopefully will provide continous service. It may be a few more days, but he will be back. Warren Gretz Fran Malczynski wrote: > --> RV-List message posted by: "Fran Malczynski" > > Has any body else had a problem connecting to "Electric Bob's" website? I > printed off a document on it last week and haven't been able to connect > since. > > Fran Malczynski > RV6 (fuse) > Olcott, NY > ________________________________________________________________________________
Date: Feb 07, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
On Tue, 8 Feb 2000, Marlin Mixon wrote: > Another neat trick I read in the Subaru list (airsoob) is to place a > tube--not a venturi--directly into the exhaust flow so that the end of the > tube exits downstream of the exhaust gasses. The poster claimed that he got Good for an experimental aircraft, not so easy to do with a certifed aircraft. > Also, I don't know if its important, but this method would seem to to me to > admit less spent exhaust gasses into the system than putting a venturi in > the exhaust flow. No exhaust gets in. Remember, the venturi is sucking air out of the gyros, not putting in back in. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Cy Galley" <cgalley(at)accessus.net>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
Date: Feb 08, 2000
Done all the time in all sorts of aircraft, certified on not! Cy Galley - Editor, B-C Contact! (Click here to visit our Club site at http://www.bellanca-championclub.com) -----Original Message----- From: Brian Lloyd <brian(at)lloyd.com> Date: Tuesday, February 08, 2000 12:19 AM Subject: Re: Avionics-List: RE: (AHRS) for General Aviation Aircraft > >On Tue, 8 Feb 2000, Marlin Mixon wrote: > >> Another neat trick I read in the Subaru list (airsoob) is to place a >> tube--not a venturi--directly into the exhaust flow so that the end of the >> tube exits downstream of the exhaust gasses. The poster claimed that he got > >Good for an experimental aircraft, not so easy to do with a certifed >aircraft. > >> Also, I don't know if its important, but this method would seem to to me to >> admit less spent exhaust gasses into the system than putting a venturi in >> the exhaust flow. > >No exhaust gets in. Remember, the venturi is sucking air out of the >gyros, not putting in back in. > >Brian Lloyd >brian(at)lloyd.com >+1.530.676.6513 > > ________________________________________________________________________________
Date: Feb 08, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: (AHRS) for General Aviation Aircraft
On Tue, 8 Feb 2000, Cy Galley wrote: > > Done all the time in all sorts of aircraft, certified on not! I would have thought that the FAA would have a hissy fit over people modifying their exhaust systems. I like working on experimental aircraft because the FAA keeps their nose out of things for the most part. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Feb 15, 2000
Subject: Internet Explorer and List Subscription Page Problem...
Listers, I have just identified a problem between any version of Microsoft's Internet Explorer and the email List Subscription Form found at http://www.matronics.com/subscribe Please note that this problem *ONLY* affects users of Internet Explorer! Netscape users are *not* affected by the issue. Users of Internet Explorer should use the Netscape browser for now until a work around can be developed. IMPORTANT: If you have tried to subscribe *or* unsubscribe from any of the following email lists using *Internet Explorer* since the announcement of the 7 new Email Lists this past weekend, your request was not properly received and you should resubmit the request using the Netscape Browser, or wait until a solution for the problem with Internet Explorer is completed. The Lists affected by the Internet Explorer issue are: RVCanada-List RVEurope-List Skymaster-List SmithMini-List Sonerai-List Tailwind-List Please note that the Netscape Browser *IS NOT* affected by this problem and all lists can be subscribed to and unsubscribed from without a problem. I will post a message to the Lists when I have come up with a solution to this problem. Sorry for the inconvenience, Matt Dralle Matronics Email List Admin. -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Feb 15, 2000
"Internet Explorer and List Subscription Page Problem..." (Feb 15, 10:19am)
Subject: Re: Web Subscription Page Operation for Internet Explorer
Restored... Dear Listers, I have rewritten the web page and CGI code for processing List Subscription Requests to now be more compatible with command line limitations of Microsoft's Internet Explorer and some very old versions of Netscape. The page seems to be working fine now on whatever browser I try. Please feel free to resume your normal List Subscription habits. The URL is: http://www.matronics.com/subscribe Best regards, Matt Dralle Matronics Email List Admin. >-------------- > > >Listers, > >I have just identified a problem between any version of Microsoft's >Internet Explorer and the email List Subscription Form found at >http://www.matronics.com/subscribe Please note that this problem >*ONLY* affects users of Internet Explorer! Netscape users are >*not* affected by the issue. Users of Internet Explorer should >use the Netscape browser for now until a work around can be >developed. > >IMPORTANT: > >If you have tried to subscribe *or* unsubscribe from any of the >following email lists using *Internet Explorer* since the announcement of >the 7 new Email Lists this past weekend, your request was not properly >received and you should resubmit the request using the Netscape >Browser, or wait until a solution for the problem with Internet Explorer >is completed. The Lists affected by the Internet Explorer issue are: > > RVCanada-List > RVEurope-List > Sailplane-List > Seaplane-List > Skymaster-List > SmithMini-List > Sonerai-List > Tailwind-List > Ultralight-List > Warbird-List > Yak-List > Zenith-List > > >Please note that the Netscape Browser *IS NOT* affected by this problem >and all lists can be subscribed to and unsubscribed from without a >problem. > >I will post a message to the Lists when I have come up with a solution >to this problem. > >Sorry for the inconvenience, > >Matt Dralle >Matronics Email List Admin. >-------------- -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: 3-phase instrument power supplies
Date: Feb 16, 2000
Hi, I've raised this issue once before but now there is a different slant: I finally received the (old) AH which I had intended using (in my last message about this I mentioned I was told that it required 110V AC 400Hz). It now transpires that the instrument actually requires 24V AC (at probably 400Hz) - there is no electrical reference on the label. I'm looking to confirm the electrical data from any of you knowledgeable people and am also looking for anyone who knows of a circuit for an appropriate power supply for it. A friend (who I think lurks on this list - David? are you there?) has a turn and bank indicator which also runs on 24V AC 400Hz. We might be able to kill two birds with one stone here. My AH is an: "Indicator Attitude" Type J-8 Specification Mil 1-51338 stock no ... order No.... MFR'S Serial No AF52-19195 Bendix Aviation Corporation Eclipse-Pioneer Division "U.S. Property" I measured the resistance between the THREE electrical connectors and found it to be 225 Ohms between any pair (giving rise to my expectation of around 0.1A at 24V.... I imagine that the small 2-pole looking 3-phase gyro motors would need 400Hz to get to a useful speed (that's 20,000 rpm, right? - or 10,000 rpm on a 4-pole motor?). Brian said once that a "3-phase powers supply is a non-trivial design issue" ... so I don't know if that related to 110V or to 400Hz or to 3-phases. David (see above) is a circuit designer but all input would be welcome! I'd like to see the little instrument run again. Joe Hovel ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: 3-phase instrument power supplies
On Wed, 16 Feb 2000, Joe Hovel wrote: > It now transpires that the instrument actually requires 24V AC (at probably > 400Hz) - there is no electrical reference on the label. > > My AH is an: > "Indicator Attitude" > Type J-8 Specification Mil 1-51338 > stock no ... order No.... > MFR'S Serial No AF52-19195 > Bendix Aviation Corporation Eclipse-Pioneer Division > "U.S. Property" > > I measured the resistance between the THREE electrical connectors and found > it to be 225 Ohms between any pair (giving rise to my expectation of around You can't use a DC measurement to determine power requrirements because it may be AC coupled. You may actually be seeing a transformer or some of the circuit may be capacitor coupled. > Brian said once that a "3-phase powers supply is a non-trivial design issue" > ... so I don't know if that related to 110V or to 400Hz or to 3-phases. > > David (see above) is a circuit designer but all input would be welcome! > I'd like to see the little instrument run again. As for the actual power requirement, I would call a good instrument overhaul shop (especially one with whom you have done business) and ask. I use The Gyro House in Auburn, CA. (Having spend many thousands of dollars over the last 10 years with them, they are very responsive to my requests. : ) They are good about answering such questions for me. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Gregory Young" <gyoung@cs-sol.com>
"Avionics List Member"
Subject: CDI switch for VOR-GPS
Date: Feb 16, 2000
I'm starting to wire the radios for my RV-6. I've got an UPSAT SL30 nav/com and GX65 gps/com with a Mid-Continent MD200-306 indicator. My original plan was to just wire the indicator to the nav/com but after I got the radios I realized I could wire my GPS into the CDI if I had a switch/relay. UPS has an ACU unit for $695 list that does the switching and has all the annunciator lights and such for IFR. Seems like overkill since, for now anyway, I'm not going to get it IFR certified. It looks like there are 10 signal lines to switch, plus the mode light. Are there other, cheaper options to do this? Should I just gang up a dozen relays? Maybe I should really ask if the GPS CDI display has any usefulness since I'll have a moving map on the GX65 plus will eventually drive a large screen display from it? Just because I can doesn't mean I should. Thoughts & suggestions are welcome. Regards, Greg Young - Houston (DWH) RV-6 N6GY 90%done, 90% to go "Always do right- this will gratify some and astonish the rest." - Mark Twain (1835-1910) ________________________________________________________________________________
From: "Todd Chisum" <toddc12(at)hotmail.com>
Subject: Military Instruments
Date: Feb 16, 2000
I have a VSI and a VOR pulled from a Huey helicopter going on display. These instruments appear to be in perfect shape. Are they suitable for use in an airplane? What about voltage (12, 14, 24, 28???) Thanks, Todd Chisum Tulsa, Oklahoma Wag Aero Super Sport project ________________________________________________________________________________
From: "Ronnie Brown" <rolandbrown(at)sprintmail.com>
Subject: Re: CDI switch for VOR-GPS
Date: Feb 16, 2000
Can't help with the switch, but I can tell you the CDI is useless. We have a Cessna 172 with a Apollo SL60 GPS/Com with the FAA mandated CDI/Annunciator panel. Not only does it take up valuable panel space, it only tells you if you are on course or if off course which way to turn - just like a VOR for the old timers. It doesn't tell you how much off the required heading you are or even what heading you need to be flying. The SL60's digital display of course tells you what your heading is and what heading you need to be on to get on course - very simple display - but of course it is digital and doesn't meet the FAA requirements - by the way TSO-129 is GUIDANCE - NOT LAW!!!! I fly VOR and LOC approaches using the SL60's digital display for both distance and heading displays. My approaches are much more accurate than when I use only the VOR/LOC CDI. I am building a Velocity and am planning to install an Apollo GX60 or GX65 - and I will not install a CDI for it - no need wasting my money on something that doesn't help me fly safely!!! But if you are used to flying CDI needles, then by all means spend the money. Ronnie Brown 173 Elite RG Velocity (21% complete) -- --- Original Message ----- From: Gregory Young <gyoung@cs-sol.com> Sent: Wednesday, February 16, 2000 1:21 PM Subject: Avionics-List: CDI switch for VOR-GPS > > I'm starting to wire the radios for my RV-6. I've got an UPSAT SL30 nav/com > and GX65 gps/com with a Mid-Continent MD200-306 indicator. My original plan > was to just wire the indicator to the nav/com but after I got the radios I > realized I could wire my GPS into the CDI if I had a switch/relay. UPS has > an ACU unit for $695 list that does the switching and has all the > annunciator lights and such for IFR. Seems like overkill since, for now > anyway, I'm not going to get it IFR certified. > > It looks like there are 10 signal lines to switch, plus the mode light. Are > there other, cheaper options to do this? Should I just gang up a dozen > relays? Maybe I should really ask if the GPS CDI display has any usefulness > since I'll have a moving map on the GX65 plus will eventually drive a large > screen display from it? Just because I can doesn't mean I should. Thoughts > & suggestions are welcome. > > Regards, > Greg Young - Houston (DWH) > RV-6 N6GY 90%done, 90% to go > > "Always do right- this will gratify some and astonish the rest." - Mark > Twain (1835-1910) > > ________________________________________________________________________________
From: HornetBall(at)aol.com
Date: Feb 16, 2000
Subject: Re: CDI switch for VOR-GPS
Having the GPS hooked to an old-style CDI is a requirement for an IFR certified installation. The thinking behind it is that the "CDI" on the GPS screen is too far removed from your normal instrument scan. As the CDI now can have multiple driving sources, the need arises for switches and indicators. All in all, it adds a whole bunch of clutter to the cockpit with very little added functionality. That is especially true in your case since the radio stack of an RV-6 panel is well within an acceptable range for an instrument scan (compared to an installation in some large spam can where the GPS is put in the "second" radio stack in front of the passenger). An added advantage is that now there is no question in your mind as to what you are viewing. If you are looking at the standard CDI, you know that you are looking at VHF nav info. If you are looking at the GPS receiver's CDI, you know that you are looking at GPS info. No confusion. No annunciators required. As you surmised, very often what is done in spam cans should not be emulated in our experimentals. We have the freedom to do it right. : ) Rick Price - Houston (9X1) Velocity N355BH 400 Hours and almost debugged Sierra Flight Systems avionics test aircraft Call me for a ride sometime ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CDI switch for VOR-GPS
> >Having the GPS hooked to an old-style CDI is a requirement for an IFR >certified installation. No, it is not a requirement. >The thinking behind it is that the "CDI" on the GPS >screen is too far removed from your normal instrument scan. If the GPS receiver is sufficiently removed from your primary scan then you need and auxilary CDI display. I hold that having the GPS receiver in your center stack next to your "6 pack" qualifies as being in the primary scan especially when you consider some of the aircraft still flying with side-stack radios and instruments scattered all over the panel. >As the CDI now >can have multiple driving sources, the need arises for switches and >indicators. All in all, it adds a whole bunch of clutter to the cockpit with >very little added functionality. That is especially true in your case since >the radio stack of an RV-6 panel is well within an acceptable range for an >instrument scan (compared to an installation in some large spam can where the >GPS is put in the "second" radio stack in front of the passenger). An added >advantage is that now there is no question in your mind as to what you are >viewing. If you are looking at the standard CDI, you know that you are >looking at VHF nav info. If you are looking at the GPS receiver's CDI, you >know that you are looking at GPS info. No confusion. No annunciators >required. As I said in a previous post, I have two CDIs in one airplane and they are labled differently. No confusion. In my RV-4 I had just the Tri-Nav-C and it worked well, especially since the Argus moving map display also had a CDI for the GPS on the bottom of the screen (of course I would *never* use that in leu of the "real" CDI since the Argus 3000 is not IFR certified.) >As you surmised, very often what is done in spam cans should not be emulated >in our experimentals. We have the freedom to do it right. : ) And right is relative. As you say, there is more than one way to skin a cat but the cat skin can still be used in a spam can if you hold your tongue just right when you submit your 337 to the FSDO. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Military Instruments
> >I have a VSI and a VOR pulled from a Huey helicopter going on display. >These instruments appear to be in perfect shape. Are they suitable for use >in an airplane? What about voltage (12, 14, 24, 28???) The VSI certainly should be. The VOR indicator probably is standard but you need to verify this. You can expect them to be 24VDC-28VDC for internal lighting if they have it. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CDI switch for VOR-GPS
> >Can't help with the switch, but I can tell you the CDI is useless. Certainly less useful but not useless. I like having the radio display bearing and track and then get the off-course info from the CDI. (I have the SL-60 in two of my airplanes.) > We have >a Cessna 172 with a Apollo SL60 GPS/Com with the FAA mandated >CDI/Annunciator panel. Not only does it take up valuable panel space, it >only tells you if you are on course or if off course which way to turn - >just like a VOR for the old timers. It doesn't tell you how much off the >required heading you are or even what heading you need to be flying. So you have to learn to track just like you did with VOR. No big deal. >I am building a Velocity and am planning to install an Apollo GX60 or GX65 - >and I will not install a CDI for it - no need wasting my money on something >that doesn't help me fly safely!!! Remember that all IFR GPS receivers must be signed off on a form 337. The FAA has to put their sig on it. If you have all the things they expect, such as a CDI, it is a slam-dunk. If you want to use the built-in display you need to be prepared to prove/justify that the built-in display is in your primary scan area and that all the necessary information is still displayed. >But if you are used to flying CDI needles, then by all means spend the >money. In one aircraft, I used a very old VOR CDI which I picked up for a song. I plan to fill that hole with another instrument someday since I already have the CDI info from the GPS going into a Terra Tri-Nav-C too. I hold that the Tri-Nav meets the requirement just fine but there was some argument from the FSDO. Rather than argue, I just dropped in the second CDI. Poof! No hassle. In the other aircraft I used a pair of KI-209a's, one for the front seat and one for the back. (The new KI-209 supports using the L/R CDI with a GPS.) Since I needed them for VOR/LOC/GS display, the switch wasn't a big deal. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CDI switch for VOR-GPS
> >I'm starting to wire the radios for my RV-6. I've got an UPSAT SL30 nav/com >and GX65 gps/com with a Mid-Continent MD200-306 indicator. My original plan >was to just wire the indicator to the nav/com but after I got the radios I >realized I could wire my GPS into the CDI if I had a switch/relay. UPS has >an ACU unit for $695 list that does the switching and has all the >annunciator lights and such for IFR. Seems like overkill since, for now >anyway, I'm not going to get it IFR certified. You probably don't need that since the GX65 is not certified for approaches. The FSDO will be much less stringent when you are just using the GPS for enroute/terminal operations. >It looks like there are 10 signal lines to switch, plus the mode light. Are >there other, cheaper options to do this? Should I just gang up a dozen >relays? Maybe I should really ask if the GPS CDI display has any usefulness >since I'll have a moving map on the GX65 plus will eventually drive a large >screen display from it? Just because I can doesn't mean I should. Thoughts >& suggestions are welcome. Yes, there are a bunch of signals that need to be swtiched if you are going to share a CDI between your GPS and your VOR/LOC/GS receiver. Frankly, I like the Terra Tri-Nav-C (if you can still find one) since the required switching is built right into the indicator. There is a toggle switch on the front to select nav source for the L/R CDI. It is even smart enough to automatically switch back to the NAV receiver if the NAV receiver starts receiving a valid localizer signal. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Feb 16, 2000
From: Arthur Glaser <airplane(at)corecomm.net>
Subject: Re: CDI switch for VOR-GPS
Brian Lloyd wrote: > > > > >Having the GPS hooked to an old-style CDI is a requirement for an IFR > >certified installation. > > No, it is not a requirement. Mention has been made of a 337 for experimental aircraft. It has been passed on to me that at least some FAA personnel do not believe the 337 is applicable to experimental aircraft. Opinions? ________________________________________________________________________________
Date: Feb 16, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CDI switch for VOR-GPS
>> > >> >Having the GPS hooked to an old-style CDI is a requirement for an IFR >> >certified installation. >> >> No, it is not a requirement. > >Mention has been made of a 337 for experimental aircraft. It has been passed on >to me that at least some FAA personnel do not believe the 337 is applicable to >experimental aircraft. Opinions? There was a really interesting discussion about this on the RV-list a year or two ago. Someone actually read all the pertinent docs and then carefully interpreted them. The FSDO bought their interpretation. One of the key points was that the owner of the RV-6 in question pointed out that the 337 is intended for a modification and/or major repair and that, since the GPS receiver in question was being installed in the aircraft as part of the aircraft's initial complement of instruments/avionics, the form 337 definitely did not apply and no 337 would be required in that case. He didn't press beyond that. But even so, it is a good idea to perform the tests specified in the AC for installing a GPS and log that information. The key point there is to show that, even tho' your aircraft is experimental, you are attempting to conform to the spirit of the regs/procedures for certified aircraft and not taking anything for granted. Does that make sense? Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Feb 16, 2000
From: Pete Hudes <phudes(at)gte.net>
Subject: Re: CDI switch for VOR-GPS
Greg, We got the ACU unit free from UPS when we bought our GX65. It's a nice unit. Pete Hudes ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: AH power supply
Date: Feb 18, 2000
In response to: >> I measured the resistance between the THREE electrical connectors and found >> it to be 225 Ohms between any pair (giving rise to my expectation of around > You can't use a DC measurement to determine power requirements because it > may be AC coupled. You may actually be seeing a transformer or some of > the circuit may be capacitor coupled. I have had the instrument case open (to check for any obvious damage and wiring condition etc) and found only direct connections to the three motors - all in parallel, no other electrical or electronic components. I was surprised in fact that the little "OFF" flag had it's own motor! It is simply geared to let the tiny motor run up a few turns against a gear quadrant which moves the OFF flog behind the rim of the AH face and then it will sit there stalled... it must only draw a tiny current so as not to overheat once stalled. I understand your concern for "guessing" power requirements and voltages, but in light of this, I think it's an "educated guess" to think in terms of 24V AC 400Hz.... > As for the actual power requirement, I would call a good instrument > overhaul shop (especially one with whom you have done business) and > ask. I use The Gyro House in Auburn, CA. (Having spend many thousands of > dollars over the last 10 years with them, they are very responsive to my > requests. : ) They are good about answering such questions for me. I'll e-mail them now, you sent their URL in December last year, when I first raised this. I asked them at the time about a 110V AC inverter but they were unable to help. This time I might be a bit more successful, having the instrument and it's label actually in hand! Thanks for your helpful input - as always! Joe Hovel Senior Lecturer Centre for Rural Health & Centre of Medical Informatics Monash University =========================================== www.med.monash.edu.au/crh www.monash.edu.au/informatics ________________________________________________________________________________
Date: Feb 18, 2000
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: AH power supply
>I understand your concern for "guessing" power requirements and voltages, >but in light of this, I think it's an "educated guess" to think in terms of >24V AC 400Hz.... Probably 115 vac/400 Hz the only 26 vac loads I've seen are syncro excitation which is single phase. The 225 Ohm dc reading also suggests 115 vac coils. A single gyro instrument will require about 30 va . . . Bob . . . -------------------------------------------- ( The only time you don't fail is the last ) ( time you try something, and it works. ) ( One fails forward toward success. ) ( C.F. Kettering ) -------------------------------------------- http://www.aeroelectric.com ________________________________________________________________________________
Date: Feb 18, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: AH power supply
On Fri, 18 Feb 2000, Joe Hovel wrote: > > You can't use a DC measurement to determine power requirements because it > > may be AC coupled. You may actually be seeing a transformer or some of > > the circuit may be capacitor coupled. > > I have had the instrument case open (to check for any obvious damage and > wiring condition etc) and found only direct connections to the three > motors - all in parallel, no other electrical or electronic components. > ... > I understand your concern for "guessing" power requirements and voltages, > but in light of this, I think it's an "educated guess" to think in terms of > 24V AC 400Hz. That may be but you still cannot use a DC measurment to determine power requirements of an AC-operated device. The DC resistance of the windings is only part of determining power requirements. There is also inductance and/or capacitance that affects phase (power factor). The only way to know for sure is to find out from the source (manufacturer) or someone with complete docs on the device, hence my suggestion below: > > As for the actual power requirement, I would call a good instrument > > overhaul shop (especially one with whom you have done business) and > > ask. > > I'll e-mail them now, you sent their URL in December last year, when I first > raised this. I asked them at the time about a 110V AC inverter but they were > unable to help. This time I might be a bit more successful, having the > instrument and it's label actually in hand! That makes a big difference. And if they can't help you, grab a copy of Trade-A-Plane and look in the ads for instrument overhaul shops that advertise used instruments. They will also probably have what you need. > Thanks for your helpful input - as always! You are welcome. I am always happy to help a fellow airplane nut. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Feb 18, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: AH power supply
On Fri, 18 Feb 2000, Robert L. Nuckolls, III wrote: > > >I understand your concern for "guessing" power requirements and voltages, > >but in light of this, I think it's an "educated guess" to think in terms of > >24V AC 400Hz.... > > Probably 115 vac/400 Hz the only 26 vac loads I've seen > are syncro excitation which is single phase. The 225 Ohm > dc reading also suggests 115 vac coils. That isn't an absolute Bob. I have a vertical gyro (AI) that uses 36VAC, three-phase. Go figure. > A single gyro instrument will require about 30 va . . . Some are less too. I still think he should find someone who has the doc and can give him info specific to his gyro. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: AH power supply
Date: Feb 19, 2000
Brian et al, I e-mailed Richard Anderson from the Gyro house and he was most helpful - just as you predicted! His reply was: "The J8 type Attitude Gyro requires 115Vac, 400HZ, 3 Phase power with a BAC rotation. Typical current draw (after 3 minutes of operation) is A-C leg not to exceed 185ma, B leg = not to exceed 225 ma. It will of course draw higher current during the initial start up prior to full rotor spin up. There are some power supplies available which will supply this output." .... He also informed me that the powersupplies for these instruments are in the order of US $800 - $1000 ... which will probably puts it out of contention... pity. I think when the time comes I'll buy a second-hand 14V unit, rather than spending this much on a power supply and then getting the J-8 checked out or overhauled. I told Richard that you, Brian, referred me. Joe Hovel ________________________________________________________________________________
Date: Feb 19, 2000
From: Chuck Deiterich <cfd(at)tstar.net>
Subject: Re: Avionics-List Digest: 02/16/00
Dragging up old memories, the J-8 gyro is 115 V, 400 cycle, 3 phase. And I believe you can roll 360 degrees with out tumbling it. In 1960, I worked in a small instrument shop and the instrument mechanic had shown me this. Chuck D. > __________________________________________ > From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au> > Subject: Avionics-List: 3-phase instrument power supplies > > > Hi, > I've raised this issue once before but now there is a different slant: > I finally received the (old) AH which I had intended using (in my last > message about this I mentioned I was told that it required 110V AC 400Hz). > It now transpires that the instrument actually requires 24V AC (at probably > 400Hz) - there is no electrical reference on the label. > I'm looking to confirm the electrical data from any of you knowledgeable > people and am also looking for anyone who knows of a circuit for an > appropriate power supply for it. > A friend (who I think lurks on this list - David? are you there?) has a turn > and bank indicator which also runs on 24V AC 400Hz. We might be able to kill > two birds with one stone here. > > My AH is an: > "Indicator Attitude" > Type J-8 Specification Mil 1-51338 > stock no ... order No.... > MFR'S Serial No AF52-19195 > Bendix Aviation Corporation Eclipse-Pioneer Division > "U.S. Property" > ________________________________________________________________________________
Date: Feb 19, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: AH power supply
On Sat, 19 Feb 2000, Joe Hovel wrote: > > Brian et al, > I e-mailed Richard Anderson from the Gyro house and he was most helpful - > just as you predicted! His reply was: > ... > I told Richard that you, Brian, referred me. I'm glad you got the info you needed. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Feb 24, 2000
From: Warren Gretz <warrengretz(at)gretzaero.com>
list-aerobatic , list-aviation , list-avionics , list-beech , list-cessna , list-engines , list-ez , list-glasair , list-homebuilt , list-lancair , list-piper , list-rocket , list-rvcanada , list-seaplane , list-tailwind , list-warbird , list-yak , list-zenith
Subject: New Gretz Aero website!
Greetings to all, I am glad to announce that my new webpage is up and running. If you would like to see the aircraft products I offer, and the information I provide on options for equipment installed on aircraft, you may want to check out my website. Be sure to bookmark this site as it will continue to grow. The webpage address is: http://www.gretzaero.com I hope you find it interesting. Warren Gretz Gretz Aero ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Feb 29, 2000
Subject: activity?
Hi all - Have not seen any activity on this list for quite a while. Is something broken? Did everyone disappear when I asked for volunteers to do some actual work? My CAN project is progressing slowly, with both the Atmel/Microchip and TI TMS320F241 projects continuing... g. ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: activity?
Date: Feb 29, 2000
> Have not seen any activity on this list for quite a while. > Is something broken? Did everyone disappear when > I asked for volunteers to do some actual work? I can't speak for anyone else, but I got really busy with both work and some home improvement projects... My shop (garage) is too cold to do airplane work (and needed to be cleaned out anyway) so I started doing some work in there, as well as upgrading the electrical service in the house to accommodate the shop needs... What volunteer work did you have in mind (though I have been watching the list, I don't recall the post)? Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: activity?
Date: Feb 29, 2000
Glen, I've been pulled away on airplane shop upgrades. I did recieve the CDA101 CD-ROM with their CAN Kingdom software. I'm still trying to decide on how to best get started in MPU development. I've never done it before. How is your project coming? I've decided to use a seperate CAN controller chip so that I can take advantage of a broader range of cheap MPUs, and also so that I can get working on other aspects of the designing with MPUs. I've got so much to learn. I have decided that each of my MPUs will probably have some form of simple local display as well as a datanet connection. I'm currently working on 2 designs. An angle of attach intrument, and a turn and bank instrument. The angle of attack instrument will use solid-state pressure sensors. I'm really doing 2 designs. One will be completely analog, using a Burr-Brown MPY100 analog divide chip and outputing to a line of leds through 3914s. The other will be a digital attempt. The turn and bank instrument will attempt to use a couple of rate gyros to measure yaw and bank in a more or less traditional display format. My idea is to try a few basic things and see how hard it is and where it leads. John >-----Original Message----- >From: Glen_Worstell(at)notes.seagate.com > > >Hi all - > >Have not seen any activity on this list for quite a while. >Is something broken? Did everyone disappear when >I asked for volunteers to do some actual work? > >My CAN project is progressing slowly, with both the >Atmel/Microchip and TI TMS320F241 projects >continuing... > >g. > > ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: GlassCockpit CDA 101 CAN Update
Date: Feb 29, 2000
All, I received the following letter from Dave Purdy today. The Systronix site has what appears to be some very interesting development boards for Dallas Semiconductor MPUs & all sorts of serial communications including CAN devices. Very interesting. >John, >How are things going? We just had another CDA class (I believe we invited >you?!?). I think we will have one more. We had a pretty big group from >Northrop-Grumman at this one and a small company called Systronix >http://www.systronix.com/ >I thought of you since systronix was excited about CAN, CAN Kingdom and CDA >and are working with Dallas Semiconductor on writing the CAN software for >the new dual CAN 8 bit microcontroller (very cheap). Systronix was also >very interested in the microchip processors. They were looking at >implementing CAN protocol stacks and are also working with Java and ethernet >with the Tini processor. >Anyway, just checking and seeing how things are doing. >David Purdy ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Glass cockpit project
Date: Mar 20, 2000
Hey guys, you all still there? I was just wondering if anyone has made any progress on the project, or thought any more about it. Seems like the discussio9n just trailed off back in January... Admittedly, I've gotten busy at work and with soime home improvemment projects, so I wasn't exactly making any contributions either... Just checking to seee who's still around and interested... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Mar 20, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Glass cockpit project
On Mon, 20 Mar 2000, Steven J. Devine wrote: > > Hey guys, you all still there? Yeah. > I was just wondering if anyone has made any progress on the project, or > thought any more about it. Seems like the discussio9n just trailed off back > in January... Admittedly, I've gotten busy at work and with soime home > improvemment projects, so I wasn't exactly making any contributions > either... I am working on this but from a slightly different tack. It will take some time to produce results. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Subject: Re: Glass cockpit project
Date: Mar 20, 2000
From: "D.F.S." <dfs(at)xmission.com>
> > > Hey guys, you all still there? > > I was just wondering if anyone has made any progress on the project, or > thought any more about it. Seems like the discussio9n just trailed off back > in January... Admittedly, I've gotten busy at work and with soime home > improvemment projects, so I wasn't exactly making any contributions > either... > > Just checking to seee who's still around and interested... > I don't know how it fits into the current projects and such... BUT. I just saw the ads for the "Netpliance" It is a dedicated internet "Terminal". Here is the upshot, it is based on PC type technology and with a very few modifications can be changed back into a basic PC. The only real change required is changing the keyboard for a standard one, and adding a hard disk, they can take a 2.5" drive inside the case. It has a 10" color flat panel screen with all the electronics built into it. People have it running Linux and Windows. They are severly back-ordered, but they are $99.00, and it would appear many people are having good luck picking them up without the internet service subscription. If nothing else, I figured they would be great for running Jeppview. The Jeppesen Electronic Charts. Marc ________________________________________________________________________________
Date: Mar 21, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: SBC with CAN + Ethernet + async serial + Java for ...
$50!!!!!! Dave Bridgham sent me some info that got me so stoked I can hardly stand myself. This thing is awesome! It is an SBC for embedded systems that already has TCP/IP, Ethernet, CAN buss, async serial, and a multitasking Java OS all for $50. Yes, you read that right, fifty bucks. The stated purpose is to Internet enable appliances but it sure looks like it would be able to do some of the things we want to do. It is called TINI (Tiny InterNet Interface) and is made by Dallas Semiconductor, the folks who brought us the Java Ring. The whole SBC is on a single 68pin SIMM. There are various hosting boards that provide power supplies and connectors for the various signals available. Some even have breadboarding areas for interfacing other devices. One vendor, Systronix, has a keypad and a 4-line LCD display available. Anyway, if you want more info go see: http://www.ibutton.com/TINI/ I got a motherboard with various interfaces and a breadboard area from Systronix. They will also sell you the TINI board for $5 more than Dallas Semiconductor (iButton folks). http://www.systronix.com/ It strikes me that this is a really, really simple way to start doing things without breaking the bank. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: SBC with CAN + Ethernet + async serial + Java for ...
Date: Mar 22, 2000
Brian/Dave... that thing looks AWESOME dude... thanks for the info. ----- Original Message ----- From: "Brian Lloyd" <brian(at)lloyd.com> Sent: Tuesday, March 21, 2000 4:44 PM Subject: Avionics-List: SBC with CAN + Ethernet + async serial + Java for ... > > $50!!!!!! > > Dave Bridgham sent me some info that got me so stoked I can hardly stand > myself. This thing is awesome! It is an SBC for embedded systems that > already has TCP/IP, Ethernet, CAN buss, async serial, and a multitasking > Java OS all for $50. Yes, you read that right, fifty bucks. The stated > purpose is to Internet enable appliances but it sure looks like it would be > able to do some of the things we want to do. > > It is called TINI (Tiny InterNet Interface) and is made by Dallas > Semiconductor, the folks who brought us the Java Ring. The whole SBC is on > a single 68pin SIMM. There are various hosting boards that provide power > supplies and connectors for the various signals available. Some even have > breadboarding areas for interfacing other devices. One vendor, Systronix, > has a keypad and a 4-line LCD display available. > > Anyway, if you want more info go see: > > http://www.ibutton.com/TINI/ > > I got a motherboard with various interfaces and a breadboard area from > Systronix. They will also sell you the TINI board for $5 more than Dallas > Semiconductor (iButton folks). > > http://www.systronix.com/ > > It strikes me that this is a really, really simple way to start doing > things without breaking the bank. > > > Brian Lloyd Lucent Technologies > brian(at)lloyd.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6513 - voice +1.530.676.3442 - fax > > ________________________________________________________________________________
Date: Mar 22, 2000
From: Joshua Lamorie <jpl(at)xiphos.ca>
Subject: New FAR 23 Advisory Circular
Gidday all, I'm a recent lurker, and I've not noticed the following in the archives. The FAA has released an updated Advisory Circular for the FAR 23.1309 requirement about the reliability of Systems and Installations on part 23 aircraft. This is revision C of the document, and was released Dec 1999. It talks about reliability testing of all types of systems. I think it may be of use to the Glass-Cockpit project. Anyway, they've got it as a PDF, on their website, and the URL is; http://www.faa.gov/avr/air/acs/1309.pdf It also refers to several useful documents (RTCA, FAA and ARINC) that would be helpful to look at. The equivalent document for Part 25 documents (named AC-25.1309..) is not online (circa 1992), but I'm sure your friendly FAA office would send you a copy. That being said, the folks at AS-TECH engineering, have placed an unofficial copy (though it looks the same as the paper I have) on their website. Go get it at... http://www.astech-engineering.com/systems/avionics/aircraft/faaac251309a.html They have an interesting expert's corner.. but it's empty, other than nice titles (including a future section on Quaternions and Euler angles). Anyway, I'm very interested in figuring out how to create a nice free ( la FSF) suite of software configuration management tools that would enable people/teams to create software/hardware/firmware that conforms to a combination of DO-178B/ISO-12207 (old MIL-STD-498, which superseded DOD-STD-2167). I plan on using a combination of CVS/RCS and PGP (or GPG) with perhaps some changes. Has anyone else seen any attempts to make this process easier? thanks Joshua ________________________________________________________________________________
Date: Mar 25, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: SBC with CAN + Ethernet + async serial + Java for ...
Looks pretty neat. Couldn't find info on it's processor. What kind is it, and what software do you need to program it? Or do you do you program it in all in Java? Marlin Brian Lloyd wrote: > > > $50!!!!!! > > Dave Bridgham sent me some info that got me so stoked I can hardly stand > myself. This thing is awesome! It is an SBC for embedded systems that > already has TCP/IP, Ethernet, CAN buss, async serial, and a multitasking > Java OS all for $50. Yes, you read that right, fifty bucks. The stated > purpose is to Internet enable appliances but it sure looks like it would be > able to do some of the things we want to do. > > It is called TINI (Tiny InterNet Interface) and is made by Dallas > Semiconductor, the folks who brought us the Java Ring. The whole SBC is on > a single 68pin SIMM. There are various hosting boards that provide power > supplies and connectors for the various signals available. Some even have > breadboarding areas for interfacing other devices. One vendor, Systronix, > has a keypad and a 4-line LCD display available. > > Anyway, if you want more info go see: > > http://www.ibutton.com/TINI/ > > I got a motherboard with various interfaces and a breadboard area from > Systronix. They will also sell you the TINI board for $5 more than Dallas > Semiconductor (iButton folks). > > http://www.systronix.com/ > > It strikes me that this is a really, really simple way to start doing > things without breaking the bank. > > Brian Lloyd Lucent Technologies > brian(at)lloyd.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6513 - voice +1.530.676.3442 - fax > ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: SBC with CAN + Ethernet + async serial + Java for ...
Date: Mar 25, 2000
> > Anyway, if you want more info go see: > > > > http://www.ibutton.com/TINI/ > > Looks pretty neat. Couldn't find info on it's processor. What kind > is it, and what software do you need to program it? Or do you do > you program it in all in Java? It appears to natively process Java bytecodes... no other language? Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
From: PSMarket(at)aol.com
Date: Mar 26, 2000
Subject: Engineering Position
I have been reading the discussions on this bb for several months and have enjoyed and learned a lot. We currently have a BSEE position available. The candidate must have at least 3 years of design experience in analog, digital and firmware. Our company uses PIC processors, FPGAs, analog filters, amplifiers and power supplies. DSP experience is a plus. We are located in East Tennessee (Knoxville) which is just 1 hour from the Great Smoky Nathional Park, no state income tax, low realestate taxes, and in general, low cost of living. Plenty of lakes abound due to the TVA and its work in the 1930's. I would enjoy hearing from any design engineer who would like to join a team that is dedicated at being the best at what we do. Our web site is www.ps-engineering.com Thanks Mark Scheuer President PS Engineering ________________________________________________________________________________
Date: Mar 26, 2000
From: dab(at)froghouse.org
Subject: Re: SBC with CAN + Ethernet + async serial + Java fo
r ... On 25 Mar, Marlin Mixon wrote: > Looks pretty neat. Couldn't find info on it's processor. What kind > is it, and what software do you need to program it? Or do you do > you program it in all in Java? An unofficial TINI page (http://www.smartsc.com/tini/index.html) might help with finding out information. They think the processor is a Dallas Semiconductor 8051 clone, the DS80C390 but, oddly, aren't sure. See http://www.dalsemi.com/DocControl/PDFs/80c390.pdf for the datasheet on that processor. Systonix also says that's the processor and has a slightly different datasheet at http://www.systronix.com/uCAN2/80C390_index.pdf. -Dave ________________________________________________________________________________
Date: Mar 26, 2000
From: dab(at)froghouse.org
Subject: Re: SBC with CAN + Ethernet + async serial + Java fo
r ... On 25 Mar, Steven J. Devine wrote: > It appears to natively process Java bytecodes... no other language? I don't think so. I think it's just that the hackers are excited about a Java VM in so small and cheap a package and so have been concentrating on that. It may be that Java will be good enough that people will never have the urge to try other programming environments on it but that seems rather unlikely. From glancing through the processor datasheet, it has a multiply-accumulate instruction and a 40-bit accumulator. At 60MHz I wonder if it'll get pressed into mild DSP use as well. Could be just the thing for the fast scanning VOR receiver Brian was talking about. -Dave ________________________________________________________________________________
Date: Mar 26, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Engineering Position
>We currently have a BSEE position available. The candidate must have at least >3 years of design experience in analog, digital and firmware. Our company >uses PIC processors, FPGAs, analog filters, amplifiers and power supplies. >DSP experience is a plus. > >Thanks >Mark Scheuer >President >PS Engineering I see you are still looking. I really hope you find someone. I have to hang in there at Lucent until my options all vest. I just can't leave that money behind. It means I can retire. When you called me on the phone several weeks back we left something up in the air but I just don't remember what it was. Since then I have been thinking about your products and I realize I need a feature in the audio panel/intercom for my high-noise-level environment. It would be really, really nice to have the audio panel preprocess the mic audio before feeding it to the comm. I would like to have tight bandwidth filtering followed by noise reduction (autocorrelation) in order to get rid of a lot of the white noise and engine noise being fed to the comm. I often wonder how ATC understands a thing I say to them if my sidetone audio is any indication. So why should I buy the PS-7000 over the -6000 again? I am doing an all-IIMorrow panel (SL-60, SL-30, SL-70) for my new CJ6a and am planning on either the -6000 or -7000 (SL-10, SL-15) audio panel. I only have two seats but I have a really high noise environment. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Mar 26, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Engineering Position
> >>We currently have a BSEE position available. The candidate must have at >least >>3 years of design experience in analog, digital and firmware. Our company >>uses PIC processors, FPGAs, analog filters, amplifiers and power supplies. >>DSP experience is a plus. >> >>Thanks >>Mark Scheuer >>President >>PS Engineering > >I see you are still looking. Oh, crap. This was supposed to be a private message. Sorry. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: PSMarket(at)aol.com
Date: Mar 26, 2000
Subject: Re: Engineering Position
Hi Brian! I understand, don't blame you, you have worked hard and by the sounds of it, you'll be in good shape to do your own thing again soon! The PMA7000 has 6 pole filters vs 2 poles. The amount of noise is signifcantly reduced. And the Intellivox eliminates any VOX adjustments at all. UPS AT has done a really great job with their radios. I believe they will be the company to recon with in the future for avionics. Thanks for your comments, I hope that you'll use one of our products. Sincerely, Mark ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Subject: =?us-ascii?B?UmU6IFNCQyB3aXRoIENBTiArIEV0aGVybmV0ICsgYXN5bmMgc2VyaWFsICsg?
=?us-ascii?B?SmF2YSBmb3IgLi4uAA==?Date: Wed, 29 Mar > It appears to natively process Java bytecodes... no other language? Reading the specs carefully, it appears that the native instruction set is 8051-like, which has nothing whatsoever to do with Java. There is a Java bytecode interpreter in ROM (or FLASH, I forget which). The marketing hoopola seems designed to trick you into thinking that it is a Java processor, which it isn't. I agree that the $50 board sounds like a great deal. The bare chip, however, is about $16 in small quantities, not such a great deal considering that it needs some more stuff to make a system. I think the TI TMS320F241 is better. It is available in small quantities for the same price, and has FLASH and RAM on-chip. My conclusion: if you want to use the $50 board for all the nodes in your system, that might be a really fast way to get started. If you are going to design your own board to minimize per-node cost, other solutions might be better. cheers, g. ________________________________________________________________________________
Date: Mar 29, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: =?us-ascii?B?UmU6IFNCQyB3aXRoIENBTiArIEV0aGVybmV0ICsgYXN5bmMgc2VyaWFsICsg?
=?us-ascii?B?SmF2YSBmb3IgLi4uAA==? On Wed, 29 Mar 2000 Glen_Worstell(at)notes.seagate.com wrote: > > > > It appears to natively process Java bytecodes... no other language? > > Reading the specs carefully, it appears that the native instruction > set is 8051-like, which has nothing whatsoever to do with Java. There > is a Java bytecode interpreter in ROM (or FLASH, I forget which). Flash. They are still in beta on the board and they have updated code pretty regularly. > The marketing hoopola seems designed to trick you into thinking that > it is a Java processor, which it isn't. I never got that feeling. The only thing about this board is that they are not supporting it running native code, only Java. Personally, I have decided that I like the language after having written some code. That they have the networking and multitasking primitives already in there speeds up development substantially. They are adding the low-level CAN primitives so that part will get out of your way as well. > I agree that the $50 board sounds like a great deal. The bare chip, > however, is about $16 in small quantities, not such a great deal > considering that it needs some more stuff to make a system. I think > the TI TMS320F241 is better. It is available in small quantities for > the same price, and has FLASH and RAM on-chip. By the time you breadboard something, you will have spent a lot more on ANY system than they want for the TINI board and the socket board which has the power regulator, line drivers, and connectors. > My conclusion: if you want to use the $50 board for all the nodes in > your system, that might be a really fast way to get started. If you > are going to design your own board to minimize per-node cost, other > solutions might be better. Or you can start with the TINI as it is and then move it onto your own board when you are ready to go into production. The other thing to look at is their one-wire buss. You can daisy chain a bunch of these little data collection chips on a single twisted pair that carries power and data. They have thermometers (oil temp, OAT, carb air temp, etc.), a 4-channel A:D converter (EGT, CHT, etc.), counter/interval timer (tach, fuel flow, etc), digital I/O (remote control of various things, gear/flap position sensors, etc.). This would greatly reduce the amount of wire you have to poke through the firewall for an engine monitor. Since the TINI has Ethernet, CAN, and one-wire buss interfaces, you can make a really simple engine monitor pretty much with off-the-shelf parts. The more I look at this system, the simpler it all appears. Sure you can put together a more elegant system but this is the closest thing to electronic Legos I have seen. At $100 per network node ($50 for a TINI board and $50 for a support board and an enclosure for the whole mess) it is really, really cheap. How much would a TINI board driving a bit-mapped display in a 3ATI enclosure cost? $150 or so? Now you have your general purpose display ready to play with. You throw another TINI in a box, mount it on the firewall, and string some of these sensors together and, voila, you have your engine data collection box. When you consider the cost of even basic steam guages, these numbers sound quite reasonable, and well within the capability of most homebuilders, technically. We can argue about elegance and whether or not you can get to the native instruction set for the processor, but something running sure beats the snot out of nothing running. And having several people already experimenting with processors that they can plug into the internet for mutual testing of code and function ... Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Re: SBC with CAN + Ethernet + async serial + J
ava for ...
Date: Mar 29, 2000
I have to agree with Brian. The one-wire buss(for analog & digital) I/O, the software and the users sure make this look attractive. What I need is an easy start with support. Easy real world connectivity and easy networking in one product for a reasonable price. John ________________________________________________________________________________
Date: Apr 01, 2000
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: New TINI info
Dallas Semiconductor (DS) looks like it's trying to cater to the CAN market somewhat. Last month they released a product called the TILT that provides a slot that a TINI board can plug into (TINI is the same board mentioned in recent posts that claims to be CAN capable) http://www.systronix.com/home.htm (Affiliated with DS) At this web site they say: ------------------ We were challenged to create a low cost starter sockets board for TINI (tm Dallas Semiconductor) - our answer is the TILT board. Available now in a SIMM68 version and later this spring a SIMM72. Optional CAN Interface and twisted pair driver chip for Control Area Network experimentation. Price: $40 with CAN 2.0B ------------------ Observations: The TINI board looks just like a SIMM memory stick and as mentioned in previous posts, runs a subset Java Virtual Machine. I have already ordered a TINI board along with a $20.00 interface board--A TINI Sockets E-20, which has an RS-232 DB-9 port, An RJ45 Ethernet port which enables the TINI board to your LAN and act as a web server. Although the interface board I ordered is cool, I am not even sure if the comination will interface with CAN, but at least I can brag about owning the worlds smallest web server! The TILT board's CAN interface is described thusly: CAN net with 82C25X twisted pair driver. 5-way Device Net screw terminals. TILT.XX.CAN includes CAN cable driver and board connector. The pluggable 5-way screw terminal is optional and must be ordered individually. Marlin ________________________________________________________________________________
Date: Apr 01, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: New TINI info
On Sat, 1 Apr 2000, Marlin Mixon wrote: > > Dallas Semiconductor (DS) looks like it's trying to cater to the CAN > market somewhat. Last month they released a product called the TILT > that provides a slot that a TINI board can plug into (TINI is the same > board mentioned in recent posts that claims to be CAN capable) Yes, I purchased two TINI boards and I purchased DalSemi's "socket" board (it has the connectors and power supply to run the TINI), and Systronix' STEP+ board. STEP+ has everything "socket" has but it adds the CAN port and a breadboarding area. It is nice being able to write the code and then just use FTP from your workstation to download the code into the TINI to run it. TILT is like the DalSemi "socket" board in that it has the basic connectors but it doesn't have the additional serial ports nor does it have the second CAN buss connector. > http://www.systronix.com/home.htm (Affiliated with DS) Systronix is a reseller of DalSemi's stuff but is not directly affiliated). > At this web site they say: > ------------------ > We were challenged to create a low cost starter sockets board for TINI > (tm Dallas Semiconductor) - our answer is the TILT board. Available now > in a SIMM68 version and later this spring a SIMM72. Optional CAN > Interface and twisted pair driver chip for Control Area Network > experimentation. Price: $40 with CAN 2.0B > ------------------ > > Observations: The TINI board looks just like a SIMM memory stick and as > mentioned in previous posts, runs a subset Java Virtual Machine. > > I have already ordered a TINI board along with a $20.00 interface > board--A TINI Sockets E-20, which has an RS-232 DB-9 port, An RJ45 > Ethernet port which enables the TINI board to your LAN and act as a web > server. Although the interface board I ordered is cool, I am not even > sure if the comination will interface with CAN, but at least I can brag > about owning the worlds smallest web server! I hear you. Just go to Systronix' site and order the STEP+ board. It is more expensive but having the two CAN buss ports, the extra serial ports, and the breadboarding area seems like a win to me. > The TILT board's CAN interface is described thusly: > CAN net with 82C25X twisted pair driver. 5-way Device Net screw > terminals. TILT.XX.CAN includes CAN cable driver and board connector. > The pluggable 5-way screw terminal is optional and must be ordered > individually. Cool! That makes three of us then. Dave Bridgham said he was going to order one too. We would be able to do testing between the boards over the internet which should make testing easy. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Apr 06, 2000
Subject: NOTICE: Matronics Web Server Back Online...
Dear Email Listers, The Matronics Web and FTP server is finally back online! What a nightmare... But at least its finally done and in all honesty the system is running much better. Everything should be working now including the Search Engine, Archive Browser, various List-related pages, Matronics Product Pages, Online Ordering, Real Video server and Contribution pages. Again, I'm sorry it took so long to get things back - way longer than I ever intended. Have fun! Matt Dralle Matronics Email List Admin. -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Apr 30, 2000
Subject: PLEASE READ: Network Problems To Matronics...
Dear Listers, My ISP is upgrading their network today 4/30 and tomorrow 5/1. I noticed that Nameservice (DNS) went down last night around 3am which causes all sorts of problems. If your message post was rejected between about 3am 4/30 and 1pm 4/30, please repost as it was rejected do to the DNS being down. I've redirected my systems to a different DNS server in the mean time and things seem to be working right now. In any case, be aware that there may be continuing issues over the next couple of days both posting email messages and accessing the web server. My ISP *promises* that things are going to be so much better after the upgrade! We'll see... ;-) Best regards, Matt Dralle Matronics Email List Admin. -- Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551 925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft Great minds discuss ideas, Average minds discuss events, Small minds discuss people... ________________________________________________________________________________
From: "Craig Moen" <c.moen(at)mindspring.com>
Subject: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 01, 2000
Well let's try getting some I/O on this list... Anyone have any opinions on the new VAL all-in-one box coming out this year. They had prototypes at Sun-n-fun and it looks like a good unit for limited panel space. Craig ________________________________________________________________________________
From: "Paul McAllister" <pma(at)obtero.net>
Subject: Re: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 01, 2000
Hi all, My comments are general in nature. I took a long look at it during S&F and spoke with the VALCOM rep for quite some time. It is well thought out and very functional. By design they have chosen not to allow the unit to be coupled to IFR GPS units to give a CDI function, I don't think this a big minus. One thing it has is you can get a numeric read out of radials (like a Terra) which is nice if you are on an approach with more than one step down defined by a radial. As far as functionality goes in the real world, I own a Narco 122 and the concept of the 3 in one instrument works really well for me. I find this unit combined with a certified GPS gives me every thing I need to fly IFR, mind you, my idea of IFR is "on top" with a minimum amount of time in the clouds if possible. In conclusion this unit seems to represent better value than the Narco 122. Regards, Paul McAllister ----- Original Message ----- From: Craig Moen <c.moen(at)mindspring.com> Sent: Monday, May 01, 2000 10:57 PM Subject: Avionics-List: Thoughts on the New VAL VOR/LOC/Glideslope/MB > > Well let's try getting some I/O on this list... > > > Anyone have any opinions on the new VAL all-in-one box coming out this year. > They had prototypes at Sun-n-fun and it looks like a good unit for limited > panel space. > > Craig > > ________________________________________________________________________________
From: "Melvin C. Barlow" <melbarlow(at)worldnet.att.net>
Subject: New Val Com/VOR/LOC/GS/MB
Date: May 02, 2000
>>Anyone have any opinions on the new VAL all-in-one box coming out this year.<< I missed S&F. Did they mention a price? I'm looking at upgrading my -4 to allow light IFR and practice approaches to keep my new Instr. ticket current, this might be just what I'm looking for. How does it compare in functionality to the UPS (II Morrow) SL 30, which I'm also looking at? ________________________________________________________________________________
From: "Todd Chisum" <toddc12(at)hotmail.com>
piper-cub-builders(at)onelist.com, sonerai-list(at)matronics.com, STOL(at)onelist.com, volksplane(at)listbot.com
Subject: OTHER: Porterfield Info
Date: May 02, 2000
I apologize for the off-subject post, but maybe someone can help with this request. My brother is almost finished restoring a Porterfield 75C (sometimes called a CP-75). Information on this model is virtually non-existant, and he is looking for ANY information, photos, etc about this model of Porterfield. There is only one other listed in the FAA registry. If you have any info at all, please contact me OFFLINE at toddc12(at)hotmail.com Thanks...Todd Chisum ________________________________________________________________________________
From: "Mitch Williams" <mitchw(at)tanet.net>
Subject: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 02, 2000
I think the new INS422 is an evolutionary step from the ILS400. I've done some searching for ILS-400 opinions, and haven't found many. Val hasn't sold the ILS400 for a while and i think they stopped manufacturing them when they started developing the INS422. It has a digital CDI similar to Terra's TriNav (These are no longer manufactured either). I haven't started on an instrument rating, but have heard others comment that a digital CDI is harder to interpret then an analog - with the digital it's harder to see and react to small errors. I sent an email to Val to get on the list of the "1st 100" to buy at the special price. I also have been operating a ValCom 760 for about a 2.5 years, it has worked well, low cost, but is missing a couple of segments in the display. mitch '59-C172 > Anyone have any opinions on the new VAL all-in-one box coming out this year. > They had prototypes at Sun-n-fun and it looks like a good unit for limited > panel space. > > Craig > > Hi all, > My comments are general in nature. I took a long look at it during S&F and > spoke with the VALCOM rep for quite some time. It is well thought out and > very functional. By design they have chosen not to allow the unit to be > coupled to IFR GPS units to give a CDI function, I don't think this a big > minus. > > One thing it has is you can get a numeric read out of radials (like a Terra) > which is nice if you are on an approach with more than one step down defined > by a radial. > > As far as functionality goes in the real world, I own a Narco 122 and the > concept of the 3 in one instrument works really well for me. I find this > unit combined with a certified GPS gives me every thing I need to fly IFR, > mind you, my idea of IFR is "on top" with a minimum amount of time in the > clouds if possible. > > In conclusion this unit seems to represent better value than the Narco 122. > > > Regards, Paul McAllister ________________________________________________________________________________
From: "Paul McAllister" <pma(at)obtero.net>
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 02, 2000
Hi all, I noticed Mitch's comment about the digital read out. I seem to recollect that you can select an analogue representation as well, the Terra does this also, so you get the best of both worlds. Paul From: Mitch Williams <mitchw(at)tanet.net> Sent: Tuesday, May 02, 2000 5:25 PM Subject: Avionics-List: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB I haven't started on an instrument rating, but have heard others comment that a digital CDI is harder to interpret then an analog - with the digital it's harder to see and react to small errors. ________________________________________________________________________________
Date: May 03, 2000
From: Bruce Gray <brucegray(at)earthlink.net>
Subject: WTB PN-101 Publication
I'm looking for a Collins/Rockwell publication called, PN-101 Installation and repair manual, Collins part number 523-0755-824 Anyone have an extra copy they want to part with? Bruce ________________________________________________________________________________
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 03, 2000
From: "D.F.S." <dfs(at)xmission.com>
> > I noticed Mitch's comment about the digital read out. I seem to recollect > that you can select an analogue representation as well, the Terra does this > also, so you get the best of both worlds. > > Paul > >> I haven't started on an instrument rating, but have heard others comment >> that a digital CDI is harder to interpret then an analog - with the digital >> it's harder to see and react to small errors. What are the regulations on the digital readouts. I know with the new IFR approach certified GPS installs they have to run an analog indicator, for precisely the reasons mentioned I presume. (Or So I was told when they sold me my new KI-209 & /A indicators) Ie. a slightly cryptic and unintuitive interface can be annoying with your new word processor, but deadly flying a precision approach. Can a non-analog indicator be certified for a precision IFR approach setup? I don't know for sure, but I must relate to how our brains are hardwired to expect given kinds of indications of given conditions. Digital readouts are better, IMHO, for some things, but not all. A digital readout of a VOR radial, ie "232" is good doing cross country navigation, but the much more touchy-feely interpretation on a localizer making small changes or watching trends calls for something else. O a X O b O O O O O O O O O O Jumping from one Lit LED in the above array, is very coarse and is much harder to follow a trend or see you are slightly off because of the poor indication of intermediate positions. Say you are off the GS, and LED, or LCD pixel X is lit, you start a corection. You need to try something, then wait for the next LED to light. What is you under-corrected after several seconds "a" will light. Say you under-corrected a bit less, and stabilized off course, X will stay lit forever. If you did it right, "b" will light, but without moving several LED positions you will be hard pressed to recognise a trend. A physical needle will show trends faster. Now, very fine resolution digital indicators could address that, but I have not seen any, aside from the full graphical indicators, like Sandel sp? Note, I'm talking more like 100 LEDs rather than 7. Marc ________________________________________________________________________________
Date: May 03, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
On Wed, 3 May 2000, D.F.S. wrote: > > > > > I noticed Mitch's comment about the digital read out. I seem to recollect > > that you can select an analogue representation as well, the Terra does this > > also, so you get the best of both worlds. The CDI is a bargraph arrangement for both glideslope and LOC/VOR CDI. The Terra Tri-Nav does offer direct TO-bearing and from-radial readout for VOR. > >> I haven't started on an instrument rating, but have heard others comment > >> that a digital CDI is harder to interpret then an analog - with the digital > >> it's harder to see and react to small errors. I have flown a number of approaches behind the Terra display. It works just peachy and is no more difficult to interpret on an ILS than are analog needles. You just have to take a few minutes to get used to it. > What are the regulations on the digital readouts. They vary. It depends on how you read the regs. > I know with the new IFR approach certified GPS installs they have to run > an analog indicator, for precisely the reasons mentioned I presume. > (Or So I was told when they sold me my new KI-209 & /A indicators) Again, it is how you read the regs. The way I read them, a bargraph type CDI display either on an external indicator, e.g. Terra Tri-Nav, or interal to the GPS, is acceptable so long as: 1. it is in the primary visual scan while on instruments, and 2. all the other necessary nav information is still available on the face of the GPS receiver. The regs are somewhat cryptic but if you read them carefully, you can see where I am coming from. > Ie. a slightly cryptic and unintuitive interface can be annoying with your > new word processor, but deadly flying a precision approach. What is your definition of "digital"? My interpretation of the bargraph type of CDI is that it is an analog display regardless of how the display is generated. The display accepts an analog signal in, i.e. meter movement level DC voltage for the GS and composite VOR/LOC analog signal, and produces a meter-movement like display on its face. > Can a non-analog indicator be certified for a precision IFR approach setup? Bargraph type displays such as used in the Terra Tri-Nav and the VAL are acceptable. No reason not to use them for your GPS CDI as well. > I don't know for sure, but I must relate to how our brains are hardwired > to expect given kinds of indications of given conditions. Your brain is infinitely adaptable. Are you telling me that your brain is somehow hardwired to accept the raw data input from your panel, e.g. AI, DG, ASI, altimeter, VSI, VOR/LOC/GS CDI, etc., and magically turn that into an innate mental picture of where you are on the glidepath? I think not. > Digital readouts are better, IMHO, for some things, but not all. > > A digital readout of a VOR radial, ie "232" is good doing cross country > navigation, but the much more touchy-feely interpretation on a localizer > making small changes or watching trends calls for something else. > > > O a > > X > > O b > > O O O O O O O > > O > > O > > O > > > Jumping from one Lit LED in the above array, is very coarse and is much > harder to follow a trend or see you are slightly off because of the poor > indication of intermediate positions. Having flown with this type of display I can attest that it is absolutely no problem. You see, when you are flying an ILS, you only periodically glance at the CDI during the course of your scan. It is the trend information that tells you whether you need to make a heading change or a pitch change. ("Periodically" is a relative term given that a complete scan take me about 5 seconds so I am checking the CDI every 10 seconds or so. An HSI puts the nav info in the DG scan which is why an HSI reduces your workload -- fewer places you have to look.) > Say you are off the GS, and LED, or LCD pixel X is lit, you start a corection. > > You need to try something, then wait for the next LED to light. That is how you are supposed to fly an ILS. Once you are established, you are primarily holding pitch and heading, not chasing the needles. Beginning instrument students try to chase the needles and blow the approach that way instead of using the needle trend info to signal the need for pitch/power or heading changes. > What is you under-corrected after several seconds "a" will light. > Say you under-corrected a bit less, and stabilized off course, X will stay > lit forever. > If you did it right, "b" will light, but without moving several LED positions > you will be hard pressed to recognise a trend. > > A physical needle will show trends faster. Does it matter? With an ILS the CDI shows angular deviation. As you get closer to the runway the sensitivity increases. If when you are relatively far out, let's say in the vecinity of the OM/LOM, a lack of trend info probably has you as close to glidepath as you can reasonably hold given the corseness of the information provide by your DG and AI. > Now, very fine resolution digital indicators could address that, but I have > not seen any, aside from the full graphical indicators, like Sandel sp? > > Note, I'm talking more like 100 LEDs rather than 7. Seven is probably plenty. Now I haven't flown with the VAL but I have flown an ILS to CAT-I minimums with the Tri-Nav and it works just peachy keeno. I would not hesitate to qualify my airplane to CAT-II minimums using the Tri-Nav. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: May 03, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: New Val Com/VOR/LOC/GS/MB
At 00:18 5/2/2000, you wrote: > > > >>Anyone have any opinions on the new VAL all-in-one box coming out this >year.<< > >I missed S&F. Did they mention a price? I'm looking at upgrading my -4 to >allow light IFR and practice approaches to keep my new Instr. ticket >current, this might be just what I'm looking for. How does it compare in >functionality to the UPS (II Morrow) SL 30, which I'm also looking at? The VAL is a NAV-only box, no comm. The whole thing is built into the indicator so it is primarily competition for the Narco Nav-122D, not the SL-30. The SL-30 is a more typical Nav-Comm. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 03, 2000
From: "D.F.S." <dfs(at)xmission.com>
Snip > 1. it is in the primary visual scan while on instruments, and Well, like you say, it all depends on how "You" read the Regs, You in the end is the "local" Fed. I'm still in the process of getting my installation signed off, so I have to be nice. BUT... MY local fed says it needs needles. MY local fed defines "primary visual scan" as those 4 instruments in a T Setup. The problem is there is already 4 instruments and THEY are all required. His position in reality made everyone replace the DG and install an HSI to get an approved IFR GPS install. That I something I chose to fight, and we'll see what happens. > > 2. all the other necessary nav information is still available on the face > of the GPS receiver. > > The regs are somewhat cryptic but if you read them carefully, you can see > where I am coming from. > > > Ie. a slightly cryptic and unintuitive interface can be annoying with your > > new word processor, but deadly flying a precision approach. > > What is your definition of "digital"? My interpretation of the bargraph > type of CDI is that it is an analog display regardless of how the display > is generated. The display accepts an analog signal in, i.e. meter > movement level DC voltage for the GS and composite VOR/LOC analog signal, > and produces a meter-movement like display on its face. My definition is related to the display, not the inputs. In a setup like shown below you are EITHER 0,1,2 or 3 "Lines" above or below glidepath. you aren't one and slowly moving to 2. You ARE 1, then suddenly you ARE 2. > > > Can a non-analog indicator be certified for a precision IFR approach setup? > > Bargraph type displays such as used in the Terra Tri-Nav and the VAL are > acceptable. No reason not to use them for your GPS CDI as well. > > > I don't know for sure, but I must relate to how our brains are hardwired > > to expect given kinds of indications of given conditions. > > Your brain is infinitely adaptable. Are you telling me that your brain is > somehow hardwired to accept the raw data input from your panel, e.g. AI, > DG, ASI, altimeter, VSI, VOR/LOC/GS CDI, etc., and magically turn that > into an innate mental picture of where you are on the glidepath? I think > not. The problem is how fine the resolution is of the changes and how they happen. Sure, you can "Retrain" you brain to do lots of things. The problems comes if that "Retraining" doesn't stick, or is lost in very stressed or disoriented situations. As to explaining my points better, I see the exact same thing I would repeat in the quoted text, and can't really add much to it. Some may say it serves you right, you should have learned better, and it cleared out the gene pool. I figure you are better off not tempting fate. Go with what works and is the most intuitive and obvious solution. A few years back, they ran an airliner into the ground due to a poor user interface on an autopilot. They did a sustained decent of 3000'/minute instead of a decent to 3000'. They pushed and rotated a knob rather than pulled and rotated or some similar operation. > > > Digital readouts are better, IMHO, for some things, but not all. > > > > A digital readout of a VOR radial, ie "232" is good doing cross country > > navigation, but the much more touchy-feely interpretation on a localizer > > making small changes or watching trends calls for something else. > > > > > > O a > > > > X > > > > O b > > > > O O O O O O O > > > > O > > > > O > > > > O > > > > > > Jumping from one Lit LED in the above array, is very coarse and is much > > harder to follow a trend or see you are slightly off because of the poor > > indication of intermediate positions. > > Having flown with this type of display I can attest that it is absolutely > no problem. You see, when you are flying an ILS, you only periodically > glance at the CDI during the course of your scan. It is the trend > information that tells you whether you need to make a heading change or a > pitch change. > > ("Periodically" is a relative term given that a complete scan take me > about 5 seconds so I am checking the CDI every 10 seconds or so. An HSI > puts the nav info in the DG scan which is why an HSI reduces your > workload -- fewer places you have to look.) > > > Say you are off the GS, and LED, or LCD pixel X is lit, you start a corection. > > > > You need to try something, then wait for the next LED to light. > > That is how you are supposed to fly an ILS. Once you are established, you > are primarily holding pitch and heading, not chasing the > needles. Beginning instrument students try to chase the needles and blow > the approach that way instead of using the needle trend info to signal the > need for pitch/power or heading changes. > > > What is you under-corrected after several seconds "a" will light. > > Say you under-corrected a bit less, and stabilized off course, X will stay > > lit forever. > > If you did it right, "b" will light, but without moving several LED positions > > you will be hard pressed to recognise a trend. > > > > A physical needle will show trends faster. > > Does it matter? With an ILS the CDI shows angular deviation. As you get > closer to the runway the sensitivity increases. If when you are > relatively far out, let's say in the vecinity of the OM/LOM, a lack of > trend info probably has you as close to glidepath as you can reasonably > hold given the corseness of the information provide by your DG and AI. > > > Now, very fine resolution digital indicators could address that, but I have > > not seen any, aside from the full graphical indicators, like Sandel sp? > > > > Note, I'm talking more like 100 LEDs rather than 7. > > Seven is probably plenty. Now I haven't flown with the VAL but I have > flown an ILS to CAT-I minimums with the Tri-Nav and it works just peachy > keeno. I would not hesitate to qualify my airplane to CAT-II minimums > using the Tri-Nav. > > Brian Lloyd > brian(at)lloyd.com > +1.530.676.6513 ________________________________________________________________________________
From: "Ronnie Brown" <rolandbrown(at)sprintmail.com>
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 03, 2000
I just bought a Garmin GNS430. In the installation manuals, it says the 430 was approved WITHOUT any additional displays, buttons, annunicators. They also state that the permissible field of view is 120 degrees for the instrument scan. Your FSDO needs to be reminded of the old Bonanzas that have their CDI's down next to the left knee - certainly well out of the big six!!! Not even close! You apparently have a FSDO who is bucking the trend for GPS usage. I fly a 172 IFR with a Apollo SL60 and MAP 360 - I NEVER USE THE MID CONTINENT CDI - it was a total waste of money!!! There is a good write up from the RV folks which made excellent review and interpretation of the regs - I'll look that up if you need it. Ronnie Brown Velocity 173 under construction ----- Original Message ----- From: D.F.S. <dfs(at)xmission.com> Sent: Wednesday, May 03, 2000 7:45 PM Subject: Re: Avionics-List: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB > > Snip > > 1. it is in the primary visual scan while on instruments, and > > Well, like you say, it all depends on how "You" read the Regs, You > in the end is the "local" Fed. > > I'm still in the process of getting my installation signed off, so I have to > be nice. BUT... > > MY local fed says it needs needles. > > MY local fed defines "primary visual scan" as those 4 instruments in a > T Setup. > The problem is there is already 4 instruments and THEY are all required. > His position in reality made everyone replace the DG and install an HSI > to get an approved IFR GPS install. > > That I something I chose to fight, and we'll see what happens. > > > > 2. all the other necessary nav information is still available on the face > > of the GPS receiver. > > > > The regs are somewhat cryptic but if you read them carefully, you can see > > where I am coming from. > > > > > Ie. a slightly cryptic and unintuitive interface can be annoying with your > > > new word processor, but deadly flying a precision approach. > > > > What is your definition of "digital"? My interpretation of the bargraph > > type of CDI is that it is an analog display regardless of how the display > > is generated. The display accepts an analog signal in, i.e. meter > > movement level DC voltage for the GS and composite VOR/LOC analog signal, > > and produces a meter-movement like display on its face. > > My definition is related to the display, not the inputs. > > In a setup like shown below you are EITHER 0,1,2 or 3 "Lines" above or below > glidepath. you aren't one and slowly moving to 2. You ARE 1, then suddenly > you ARE 2. > > > > > Can a non-analog indicator be certified for a precision IFR approach setup? > > > > Bargraph type displays such as used in the Terra Tri-Nav and the VAL are > > acceptable. No reason not to use them for your GPS CDI as well. > > > > > I don't know for sure, but I must relate to how our brains are hardwired > > > to expect given kinds of indications of given conditions. > > > > Your brain is infinitely adaptable. Are you telling me that your brain is > > somehow hardwired to accept the raw data input from your panel, e.g. AI, > > DG, ASI, altimeter, VSI, VOR/LOC/GS CDI, etc., and magically turn that > > into an innate mental picture of where you are on the glidepath? I think > > not. > The problem is how fine the resolution is of the changes and how they > happen. > Sure, you can "Retrain" you brain to do lots of things. > The problems comes if that "Retraining" doesn't stick, or is lost in > very stressed or disoriented situations. > > As to explaining my points better, I see the exact same thing I would > repeat in the quoted text, and can't really add much to it. > > Some may say it serves you right, you should have learned better, and it > cleared out the gene pool. I figure you are better off not tempting fate. > Go with what works and is the most intuitive and obvious solution. > > A few years back, they ran an airliner into the ground due to a poor > user interface on an autopilot. They did a sustained decent of 3000'/minute > instead of a decent to 3000'. They pushed and rotated a knob rather than pulled > and rotated or some similar operation. > > > > > Digital readouts are better, IMHO, for some things, but not all. > > > > > > A digital readout of a VOR radial, ie "232" is good doing cross country > > > navigation, but the much more touchy-feely interpretation on a localizer > > > making small changes or watching trends calls for something else. > > > > > > > > > O a > > > > > > X > > > > > > O b > > > > > > O O O O O O O > > > > > > O > > > > > > O > > > > > > O > > > > > > > > > Jumping from one Lit LED in the above array, is very coarse and is much > > > harder to follow a trend or see you are slightly off because of the poor > > > indication of intermediate positions. > > > > Having flown with this type of display I can attest that it is absolutely > > no problem. You see, when you are flying an ILS, you only periodically > > glance at the CDI during the course of your scan. It is the trend > > information that tells you whether you need to make a heading change or a > > pitch change. > > > > ("Periodically" is a relative term given that a complete scan take me > > about 5 seconds so I am checking the CDI every 10 seconds or so. An HSI > > puts the nav info in the DG scan which is why an HSI reduces your > > workload -- fewer places you have to look.) > > > > > Say you are off the GS, and LED, or LCD pixel X is lit, you start a corection. > > > > > > You need to try something, then wait for the next LED to light. > > > > That is how you are supposed to fly an ILS. Once you are established, you > > are primarily holding pitch and heading, not chasing the > > needles. Beginning instrument students try to chase the needles and blow > > the approach that way instead of using the needle trend info to signal the > > need for pitch/power or heading changes. > > > > > What is you under-corrected after several seconds "a" will light. > > > Say you under-corrected a bit less, and stabilized off course, X will stay > > > lit forever. > > > If you did it right, "b" will light, but without moving several LED positions > > > you will be hard pressed to recognise a trend. > > > > > > A physical needle will show trends faster. > > > > Does it matter? With an ILS the CDI shows angular deviation. As you get > > closer to the runway the sensitivity increases. If when you are > > relatively far out, let's say in the vecinity of the OM/LOM, a lack of > > trend info probably has you as close to glidepath as you can reasonably > > hold given the corseness of the information provide by your DG and AI. > > > > > Now, very fine resolution digital indicators could address that, but I have > > > not seen any, aside from the full graphical indicators, like Sandel sp? > > > > > > Note, I'm talking more like 100 LEDs rather than 7. > > > > Seven is probably plenty. Now I haven't flown with the VAL but I have > > flown an ILS to CAT-I minimums with the Tri-Nav and it works just peachy > > keeno. I would not hesitate to qualify my airplane to CAT-II minimums > > using the Tri-Nav. > > > > Brian Lloyd > > brian(at)lloyd.com > > +1.530.676.6513 > > ________________________________________________________________________________
From: "Paul McAllister" <pma(at)obtero.net>
Subject: Re: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB
Date: May 04, 2000
Hi Ronnie, I would love to get a hold of the regulation review generated by the RV community. I am sure that a number of the folk in this thread would be interested. If you have time could you point me to it Thanks, Paul McAllister ----- Original Message ----- From: Ronnie Brown <rolandbrown(at)sprintmail.com> Sent: Thursday, May 04, 2000 3:04 AM Subject: Re: Avionics-List: RE: Thoughts on the New VAL VOR/LOC/Glideslope/MB > > There is a good write up from the RV folks which made excellent review and > interpretation of the regs - I'll look that up if you need it. > > Ronnie Brown > Velocity 173 under construction > ________________________________________________________________________________
From: "Ronnie Brown" <rolandbrown(at)sprintmail.com>
Subject: IFR Certification of GPS Installations
Date: May 05, 2000
Paul: This was copied from the Avionics-List posted back in October Here is the original message about IFR GPS installation and certification. Mark did a very good job of separating the facts from the rumor. Originally we were discussing the need for a TSO'd analog meter movement CDI as I had been told by my avionics shop. I had also contacted Terra to ask about their TriNav-C indicator (VOR/LOC/GS indicator with build in RMI and external CDI functions/switching) to which they had responded, "no, the TriNav-C doesn't qualify under TSO-C129," an invalid assumption based on Mark's evaluation. I hope others find this as interesting and useful as I did. >From: MLaboyteau(at)aol.com >Date: Thu, 4 Mar 1999 16:56:02 EST >To: rv-list(at)matronics.com >Subject: RV-List: GPS IFR installation continued...very long. >Sender: owner-rv-list-server(at)matronics.com >Reply-To: rv-list(at)matronics.com > >--> RV-List message posted by: MLaboyteau(at)aol.com > > Hopefully, I can help dispel some of the myth surrounding IFR certified >GPS installations. First, there are two different documents that will spell >out most of what is required of the installation. The technical standard >order, TSO-C129, covers what is required of the GPS receiver and input >sensors. This is the TSO that the units are built to. The second document is >Advisory Circular AC 20-138 "(GPS) NAVIGATION EQUIPMENT FOR USE AS A VFR AND >IFR SUPPLEMENTAL NAVIGATION SYSTEM". > >The TSO-C129 is available on the web at: >http://www.faa.gov/avr/air/air100/129intro.htm > >The Advisory Circular AC 20-138 is available at: >http://www.faa.gov/so/fs/fsdo15/files/ADVCIR/ac20-138.asc > > First off, free advice is worth what you paid for it! Don't take my word >for it; check out the information yourself. This message isn't intended to be >a "How to" document for certifying your GPS installation, but more of a list >of the information I used to guide me through the maze of requirements. If you >are contemplating installing a GPS for Instrument approaches, then I would >suggest that you download these documents and look them over. It would also be >in your best interest to contact your nearest FSDO, and talk to them about >what you plan to do. This is what I did during the construction of my -6A. I >sat down and made up a list of points to go over with the inspector, to help >persuade him that my installation was legal. Fortunately, I didn't have to use >them. Over the last couple of days, I've contacted a couple of inspectors with >the FAA in Dallas, and discussed GPS installations in Experimental aircraft. I >also contacted Terra in Austin, and inquired about using the TRINAV C >indicator with a certified GPS receiver for instrument approaches. > > Referring to TSO-C129, it spells out the requirements for the different >modes of navigation with the GPS sensor (receiver). Non-precision approaches >require a receiver built to TSO-C129 A(1) specs. Throughout this document, the >display or output requirements are quoted as follows: > >"2. Equipment certified to class A1, shall, in addition to the requirements >for class A2: >a. Provide a numeric (digital) display or electrical output of cross-track >deviation to a resolution of 0.01 nm for deviations less than 1.0 nm." > >All of the references to indications are for the receiver itself, or >specifications for the electrical output to drive an external CDI, HSI, or >EFIS. Nowhere have I found a specification in this TSO that requires a CDI to >have a mechanical indication. > > Referring now to AC 20-138, it states its purpose to be: > > "1. PURPOSE. This advisory circular (AC) establishes an acceptable > means, but not the only means, of obtaining airworthiness approval > of Global Positioning System (GPS) equipment for use as a > supplemental navigation system for oceanic and remote, domestic en > route, terminal, and non-precision instrument approach [except > localizer, localizer directional aid (LDA) and simplified > directional facility (SDF)] operations." > >Advisory Circulars are not regulatory in nature, but meant to be used as a >guideline. AC 20-138 states right up front that it's not the only means of >obtaining airworthiness approval for a GPS installation. But you can bet that >most inspectors are going to try and follow what it says, when faced with >approving an installation. >When we look through the background section, we see the following statement: > >g. General Operational Limitations. >(3) IFR Navigation Equipment. GPS equipment for IFR navigation > is for use as a supplemental navigation system. The > installation of GPS equipment does not affect the > requirement for a primary means of navigation appropriate > to the route intended to be flown. Within the contiguous > United States, Alaska, Hawaii, and surrounding coastal > waters, this requirement can be met with an operational, > independent VOR receiver. Additional navigation equipment > redundancy may be required for operation in oceanic and > remote airspace. > > >This is where we get the need for a second type of navigation equipment >required for IFR use. It's not limited to a VOR; it could be an ADF receiver >as well. Now we'll skip on down to section 8, titled: > >8. AIRWORTHINESS CRITERIA FOR GPS INSTALLATIONS USED AS A SUPPLEMENTAL > NAVIGATION SYSTEM UNDER INSTRUMENT FLIGHT RULES (IFR). > >a. Application Process. Operators wishing to obtain approval of > Class A() GPS equipment for IFR operations may do so via the > type certificate (TC) or supplemental type certificate (STC) > process. For equipment produced under TSO-C129 authorization > that has previously obtained initial installation approval > via the TC or STC process, approval may also be obtained via > data approved by the FAA (responsible Flight Standards > District Office) on FAA Form 337. The approval for return to > service must be signed by one of the entities noted in 14 CFR > part 43; i.e., repair station, manufacturer, holder of an > inspection authorization, etc. > >This is where it states that you'll need approval obtained through a Form 337. >But, in conversations with inspectors from the FAA, the Form 337 is for major >repairs or alterations. When the inspector came out to look at my aircraft, it >was brand new, why would I have to fill out a Form 337 for a new installation? >There weren't any repairs or alterations I had done, and Form 337's fall under >FAR Part 43 Appendix B. FAR Part 43.1 Applicability subpart (b) states that >"This part does not apply to any aircraft for which an experimental >airworthiness certificate has been issued." So the inspector and I both agreed >that no Form 337 would be required. > > Now, here is something else under section 8 that I find interesting: >b. Airworthiness Considerations. GPS navigation equipment > approved as a supplemental navigation system for oceanic and > remote en route, domestic en route, terminal, and > non-precision instrument approach (except localizer, LDA, and > SDF) operations does not require TSO-C129 authorization, > however it must meet the minimum navigation performance and > operation standards of Class A1 or A2 equipment, as > applicable, specified in TSO-C129 and this AC. Airworthiness > considerations should include the following: > The way I read this, your receiver doesn't require the TSO authorization, >just that it meets the minimum navigation performance standards! What a >minute, you mean I don't have to have a TSO'd GPS? Well I guess not, but I >don't know where you'd find one that would meet the requirements without >already having the TSO stamp of approval. But if this applies to the receiver, >wouldn't it also apply to the CDI? We'll get to that in just a minute. > > Further down in section 8, we find this next statement: > >(3) Location of the GPS Display. Each display element (i.e., > the cross track deviation display (CDI), horizontal > situation indicator (HSI), map display, etc.), used as a > primary flight instrument in the guidance and control of > the aircraft, for maneuver anticipation, or for > failure/status/integrity annunciation, shall be located > where it is visible to the pilot (in the pilot's primary > field of view) with the least practicable deviation from > the pilot's normal position and line of vision when > looking forward along the flight path. > > NOTE 1: CDI displays contained in the CDU will most likely not be > acceptable for IFR operations. > > After talking with the inspectors in Dallas, we think that this Note:1 is >causing confusion with the FSDO's. The main reason you need the external CDI, >is that during approach selection, most GPS units will not show a CDI >indication on the CDU. Also, it's likely that the CDU on the receiver will not >be located where it's visible to the pilot's view from a normal position. >Instead, the CDU shows available approaches, IAF's, FAF's, etc. In order to >continue to navigate, you need the external CDI to show course deviation while >selecting the approach. Therefore, NOTE 1 is referring to the need for an >external CDI for IFR operations, not that the CDI on the CDU is unacceptable >because it's electronic verses being mechanical. > >Moving on down, we see the following statement: > >(8) System Controls, Displays and Annunciators. All displays, > controls, and annunciators must be readable under all > normal cockpit conditions and expected ambient light > conditions (total darkness to bright reflected sunlight). > Night lighting provisions must be compatible with other > cockpit lighting. All displays and controls must be > arranged to facilitate equipment usage. Controls that are > normally adjusted in flight shall be accessible and > properly labeled as to their function. System controls and > displays shall be designed to maximize operational > suitability and minimize pilot workload. System controls > shall be arranged to provide adequate protection against > inadvertent system turnoff. Reliance on pilot memory for > operational procedures shall be minimized. > >Again, no reference to the CDI being TSO'd or mechanical. > >(10) Pressure/Barometric Altitude Inputs. An appropriate input > of pressure and/or barometric altitude must be provided to > the GPS equipment. > >This where we get the reference for having to input altitude information to >the GPS. It's also mentioned in TSO-C129. > > (11) Manufacturer's Instructions. The GPS equipment, including > antenna, shall be installed in accordance with the > instructions and limitations provided by the manufacturer > of the equipment. > >In the interconnect schematic for my Garmin GNC-300, it shows the CDI output >going through a switch/annunciator and into several different types of >indicators, such as KI525A, KI202,KI206, KPI552, KI207. Then underneath it >says, "Equivalent parts may be used". Now, these indicators are TSO'd under >TSO-C40a and -C34c, which apply to airborne ILS and G/S receiving equipment >and VOR radio receiving equipment, but none of them are TSO'd to -C129 for GPS >systems. And the manufacturer states that "equivalent parts may be used". Does >the CDI for an ILS system have to be TSO'd? NO. Referring to FAR part 91, the >only nav or communication equipment that has to be TSO'd is the Transponder. >So is it legal for me to shoot ILS approaches with my Terra TRINAV C >indicator, which is not TSO'd? Yes. I called Terra this morning and talked to >them about using their indicator with a certified receiver for instrument >approaches. They said that the indicator was not required to be TSO'd, and it >was acceptable to use it in this type of installation. Remember the quote that >said the GPS didn't have to be TSO'd but just meet the requirements? Well >couldn't it be said that this would also apply to the CDI? After all, you're >using it as part of the total GPS system. So if the CDI meets the same >criteria as a TSO'd one, but doesn't have a TSO, wouldn't it still be legal to >use? > Referring now to FAR part 91.205 (d)(2), Instrument flight rules, required >instruments and equipment; I need a two way radio communications system and >navigational equipment appropriate to the ground facilities being used. The >FAA says it's legal to use the GPS for any nonprecision approaches except >Localizer, Back course, LDA, and SDF approaches. As long as they are contained >in the current database. > > I showed the installation manual from the manufacturer for my GPS to the >inspector. In the introduction it specifies that after installation a form 337 >must be completed by an appropriately certified agency to return the aircraft >to service. His interpretation was that my aircraft was new, and this >installation was not a major repair or alteration. He read on down the page, >and there is a sentence that states "The article may be installed only if >further evaluation by the applicant documents an acceptable installation and >is approved by the Administrator." (this is required to be in the manual by >TSO-C129) He then went on to say that the installation looked ok to him, and >all that would be required is to perform a practice approach and log it in the >log book during my test phase. So I don't have a Form 337 for my installation. >But after talking to the FAA and Terra this morning, I'm satisfied that my >installation is legal to perform Instrument Approaches with. > Now, like the ads say "Your mileage may vary". It seems that there is a lot >of difference in how an inspector from one FSDO will interpret something when >compared to another inspector from a different FSDO. So, read the material >yourself, talk to the inspector from your local FSDO, and make up your own >mind about what is acceptable, and don't just take my word for it. > > >Mark LaBoyteaux >RV-6A N106RV >MLaboyteau(at)aol.com Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax > > ________________________________________________________________________________
From: "Nick Nafsinger" <nicknaf(at)prodigy.net>
Subject: Electronic Parts...
Date: May 05, 2000
I am trying to by a small quantity (4) of P-Mosfets, however I'm having a bitch of a time finding a distributor. I was just wondering if any of you have any leads? Very much appreciated! Nick Nafsinger ________________________________________________________________________________
Date: May 05, 2000
From: Bruce Boyes <bboyes(at)systronix.com>
Subject: Re: Electronic Parts...
> >I am trying to by a small quantity (4) of P-Mosfets, however I'm having a >bitch of a time finding a distributor. I was just wondering if any of you >have any leads? Very much appreciated! > >Nick Nafsinger DigiKey for small quantities, they have a great web site too. Or try the mfgr rep for samples. - Bruce Pretty nice socket boards & accessories for TINI Java /\/\/\/ Systronix /\/\/\/ Complete Systems for Rapid Embedded Control Development tel:801.534.1017 fax:-1019 http://www.systronix.com ________________________________________________________________________________
Subject: Re: Electronic Parts...
Date: May 05, 2000
From: "D.F.S." <dfs(at)xmission.com>
> > > I am trying to by a small quantity (4) of P-Mosfets, however I'm having a > bitch of a time finding a distributor. I was just wondering if any of you > have any leads? Very much appreciated! > What kind? What kind of package? What for? Any particular specs? I just got a batch, I think. Marc ________________________________________________________________________________
Date: May 05, 2000
From: jgarner <jgarner(at)netwiz.net>
Subject: Re: Electronic Parts...
http://www.digikey.com order from the net, have the parts quick. Joe Nick Nafsinger wrote: > > > I am trying to by a small quantity (4) of P-Mosfets, however I'm having a > bitch of a time finding a distributor. I was just wondering if any of you > have any leads? Very much appreciated! > > Nick Nafsinger -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Joe Garner IASEL-N35 Bonanza@OAK jgarner(at)elelink.org \ / jgarner(at)netwiz.net .____________(o)_____________. kc6utr@w6pw www.elelink.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ________________________________________________________________________________
Date: May 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: Thoughts on the New VAL
VOR/LOC/Glideslope/MB At 04:45 PM 5/3/2000, you wrote: > >Snip > > 1. it is in the primary visual scan while on instruments, and > >Well, like you say, it all depends on how "You" read the Regs, You >in the end is the "local" Fed. Certainly. But if you have your interpretation neatly laid out and documented, it is amazingly easy to have things go your way. >I'm still in the process of getting my installation signed off, so I have to >be nice. BUT... > >MY local fed says it needs needles. Then you need to do your homework BEFORE you go talk to your local fed. >MY local fed defines "primary visual scan" as those 4 instruments in a >T Setup. Of course it is (NOT). Pick a perfectly legal panel like the original panel in the Piper Comanche (which I lovingly refer to as the "Polish Piper Panel"). This panel has instruments scattered hither and yon with neither rhyme nor reason that I can discern. Please explain where the "primary visual scan" is on this panel. Given this, I include the entire panel as the "primary visual scan" area. You can certainly make a really good argument that, in a panel with "center stack" radios, everything to the left of the radios is in the "primary visual scan." >The problem is there is already 4 instruments and THEY are all required. >His position in reality made everyone replace the DG and install an HSI >to get an approved IFR GPS install. The regs do not require the ILS CDI to be in the "six pack" and yet it is perfectly acceptable to fly a CAT-II ILS under part 91 ops using nothing more than what is already in most panels. Now this guy wants to require an HSI for a nonprecision GPS approach? If you drop by my place I can give you a whole bunch of this stuff to fertilize your lawn. Our horses generate it by the truckload. >That I something I chose to fight, and we'll see what happens. You should be able to win this one. > > 2. all the other necessary nav information is still available on the face > > of the GPS receiver. > > > > The regs are somewhat cryptic but if you read them carefully, you can see > > where I am coming from. > > > > > Ie. a slightly cryptic and unintuitive interface can be annoying with > your > > > new word processor, but deadly flying a precision approach. > > > > What is your definition of "digital"? My interpretation of the bargraph > > type of CDI is that it is an analog display regardless of how the display > > is generated. The display accepts an analog signal in, i.e. meter > > movement level DC voltage for the GS and composite VOR/LOC analog signal, > > and produces a meter-movement like display on its face. > >My definition is related to the display, not the inputs. Please explain how the bargraph display is digital then? It displays a needle-like deflection of lighted segments, not numbers. Seems pretty analog to me. >In a setup like shown below you are EITHER 0,1,2 or 3 "Lines" above or below >glidepath. you aren't one and slowly moving to 2. You ARE 1, then suddenly >you ARE 2. No argument there. Regardless, bargraphs, even corse ones, work. You end up mentally integrating it over time, which you have to do anyway. If you have a proper scan, you aren't going to linger long enough on your CDI to see the rate of needle movement.d > > Your brain is infinitely adaptable. Are you telling me that your brain is > > somehow hardwired to accept the raw data input from your panel, e.g. AI, > > DG, ASI, altimeter, VSI, VOR/LOC/GS CDI, etc., and magically turn that > > into an innate mental picture of where you are on the glidepath? I think > > not. >The problem is how fine the resolution is of the changes and how they >happen. >Sure, you can "Retrain" you brain to do lots of things. >The problems comes if that "Retraining" doesn't stick, or is lost in >very stressed or disoriented situations. It doesn't require any retraining. I strongly recommend you go out and try it. I have. It works for me and for others too. If you haven't tried it, you don't have the background to question whether or not it works. >As to explaining my points better, I see the exact same thing I would >repeat in the quoted text, and can't really add much to it. > >Some may say it serves you right, you should have learned better, and it >cleared out the gene pool. I figure you are better off not tempting fate. >Go with what works and is the most intuitive and obvious solution. There is nothing inherently intuitive in flying the needles presenting raw ILS data. It is a learned skill. How it actually works in practice is neither intuitive nor obvious. In fact, if you try to treat the CDI "intuitively" your actual flight path will diverge rather alarmingly from the desired flight path. I state, based on the experience of flying an ILS in actual conditions using a bargraph type of display, that this display is perfectly adequate. >A few years back, they ran an airliner into the ground due to a poor >user interface on an autopilot. They did a sustained decent of 3000'/minute >instead of a decent to 3000'. They pushed and rotated a knob rather than >pulled >and rotated or some similar operation. And this has what to do with this discussion? For good or bad we have been learning and adapting to our cockpit environment. You have to keep doing so in order to remain safe. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: May 06, 2000
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: RE: Thoughts on the New VAL
VOR/LOC/Glideslope/MB At 07:04 PM 5/3/2000, Ronnie Brown wrote: >I fly a 172 IFR with a Apollo SL60 and MAP 360 - I NEVER USE THE MID >CONTINENT CDI - it was a total waste of money!!! > >There is a good write up from the RV folks which made excellent review and >interpretation of the regs - I'll look that up if you need it. Yes, it was excellent. I came from just this argument a couple of years ago. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: May 06, 2000
From: Richard Rosenthal <dcoyote(at)ix.netcom.com>
Subject: Re: RE: Thoughts on the New VAL
VOR/LOC/Glideslope/MB please find it I also never look at the cdi and would love to read it Rich > >At 07:04 PM 5/3/2000, Ronnie Brown wrote: >>I fly a 172 IFR with a Apollo SL60 and MAP 360 - I NEVER USE THE MID >>CONTINENT CDI - it was a total waste of money!!! >> >>There is a good write up from the RV folks which made excellent review and >>interpretation of the regs - I'll look that up if you need it. > >Yes, it was excellent. I came from just this argument a couple of years ago. > > >Brian Lloyd Lucent Technologies >brian(at)lloyd.com 3461 Robin Lane, Suite 1 >http://www.livingston.com Cameron Park, CA 95682 >+1.530.676.6513 - voice +1.530.676.3442 - fax > > ________________________________________________________________________________
Subject: Re: RE: Thoughts on the New VAL
Date: May 08, 2000
From: "D.F.S." <dfs(at)xmission.com>
> > > > Ie. a slightly cryptic and unintuitive interface can be annoying with > > your > > > > new word processor, but deadly flying a precision approach. > > > > > > What is your definition of "digital"? My interpretation of the bargraph > > > type of CDI is that it is an analog display regardless of how the display > > > is generated. The display accepts an analog signal in, i.e. meter > > > movement level DC voltage for the GS and composite VOR/LOC analog signal, > > > and produces a meter-movement like display on its face. > > > >My definition is related to the display, not the inputs. > > Please explain how the bargraph display is digital then? It displays a > needle-like deflection of lighted segments, not numbers. Seems pretty > analog to me. That is exactly what my next statment explains. You are EITHER.... It doesn't MOVE from position 1 to 2, it doesn't READ 1 & 2/3 high. It Reads 1 OR 2. You clearly understand my issue from your reply, if you don't think "Digital" is the right term, so be it, but is ure is NOT analog. > >In a setup like shown below you are EITHER 0,1,2 or 3 "Lines" above or below > >glidepath. you aren't one and slowly moving to 2. You ARE 1, then suddenly > >you ARE 2. > > No argument there. Regardless, bargraphs, even corse ones, work. You end > up mentally integrating it over time, which you have to do anyway. If you > have a proper scan, you aren't going to linger long enough on your CDI to > see the rate of needle movement. It is not so much as issue as "Watching" the movement. It is an issue of a several visual scans showing: "Just under a positive deflection of 1" "a positive deflection of 1" "One plus a bit" There is CLEARLY a trend here. It will be another minute, and 200 feet off course before an LED indicator will pop to 2 and show you as off course. until then you have no clue. > > > > Your brain is infinitely adaptable. Are you telling me that your brain is > > > somehow hardwired to accept the raw data input from your panel, e.g. AI, > > > DG, ASI, altimeter, VSI, VOR/LOC/GS CDI, etc., and magically turn that > > > into an innate mental picture of where you are on the glidepath? I think > > > not. > >The problem is how fine the resolution is of the changes and how they > >happen. > >Sure, you can "Retrain" you brain to do lots of things. > >The problems comes if that "Retraining" doesn't stick, or is lost in > >very stressed or disoriented situations. > > It doesn't require any retraining. > > I strongly recommend you go out and try it. I have. It works for me and > for others too. If you haven't tried it, you don't have the background to > question whether or not it works. I build user interfaces and readouts for a living. I think I do. I know what works, and what doesn't for me, What would I want to put my life at slight, but very real extra risk? There is no real reason to not stick with what works. Any difference in cost of such systems if pure marketing or pricing decisions. Parts wise there isn't 5 bucks Cost Diff. in your Kilobuck Indicator head. Probably 20 bucks either way in Qty. > > >As to explaining my points better, I see the exact same thing I would > >repeat in the quoted text, and can't really add much to it. > > > >Some may say it serves you right, you should have learned better, and it > >cleared out the gene pool. I figure you are better off not tempting fate. > >Go with what works and is the most intuitive and obvious solution. > > There is nothing inherently intuitive in flying the needles presenting raw > ILS data. It is a learned skill. How it actually works in practice is > neither intuitive nor obvious. In fact, if you try to treat the CDI > "intuitively" your actual flight path will diverge rather alarmingly from > the desired flight path. I never said FLYING the approach was intuitive. I did say seeing movement, tracking SMALL trends and FINE resolution physical movements was. We do it all the time in our lives. > I state, based on the experience of flying an ILS > in actual conditions using a bargraph type of display, that this display is > perfectly adequate. I'm glad you are happy with it. > > >A few years back, they ran an airliner into the ground due to a poor > >user interface on an autopilot. They did a sustained decent of 3000'/minute > >instead of a decent to 3000'. They pushed and rotated a knob rather than > >pulled > >and rotated or some similar operation. > > And this has what to do with this discussion? For good or bad we have been > learning and adapting to our cockpit environment. You have to keep doing > so in order to remain safe. And the DESIGN should evolve as well, this shouldn't be one sided. Poor and unintuitive user interfaces have everything to do with this discussion. The fact a user expected to turn a knob, see a readout, and cause a control input didn't work as expected caused death. A user expected to turn the knob, see 3000 (The Target Altitude). The user Turned the knob, pushed, instead of pulled, SAW 3000 and thought everything was fine. The problem is THIS 3,000 meant something completely different. It was a sustained 3,000 feet/minute decent. They crashed. The system designer obviously "Thought" the interface was "perfectly adequate" The addition of a few extra Display Segments could easily have saved many Lives that night. "3000" Becomes "3000 FT/MIN" OR "3000 FT MSL" No more problem, Unless you consider the extra cost of .1% to the Mfgr profit margin. The problem is Technology is used in a very unbalanced manner. The old adage, "Faster, Cheaper, Better..." is not applied nearly as much in the "Better" direction technology allows. Cheaper, by replacing "Expensive" mechanical movements and wafer switches is embraced quickly. Adding features or making the interfaces better is not, ie. That is all the info they had before, and that was "perfectly adequate". The reasons you needed to verify "Switch A was in position 1, Switch B was in position 3 and selector knob was in location X which means Indicator Y means Such-and-Such" With the new technology you should simply make Y SAY Such-and-Such. By your logic, it is all the pilots fault. I Disagree, I think the system design is also a large part of the problem and should be fixed. It's cheap, easy and should be considered in the design. An LED indicator with 70 LEDs/Axis instead of 7 AND tick marks composed of a pair of contrasting color LEDs which are always lit would be a good system. In my opinion 7 doesn't cut it. Disagree if you want. Buy what you want. Use whatever works best for you. I have nothing more to add. Marc ________________________________________________________________________________
From: "Dick Rourke" <dickrourke(at)earthlink.net>
Subject: displays
Date: May 09, 2000
Gentlemen: Thanks for your two explanations of points of view which helped me understand and make clear my own purchase priorities in light of safety issues.


December 28, 1999 - May 14, 2000

Avionics-Archive.digest.vol-ac