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 |
I've had good success with the Watson Industries AHRS.
________________________________________________________________________________
From: | "Matthew Mucker" <mmucker(at)airmail.net> |
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
________________________________________________________________________________
From: | Brian Lloyd <brian(at)lloyd.com> |
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 |
>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 |
(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
________________________________________________________________________________
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 |
-----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 |
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
> >
>
>
>
>
________________________________________________________________________________
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 |
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
>
>
>
>
>
>
________________________________________________________________________________
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> |
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> |
>
>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
________________________________________________________________________________
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 |
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.
________________________________________________________________________________
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
________________________________________________________________________________
From: | "Stefan B." <stefan.balatchev(at)wanadoo.fr> |
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
________________________________________________________________________________
> 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. |
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."
________________________________________________________________________________
Subject: | Re: Ham licenses |
K1CAW
Ray Grenier RV-4 finishing fuse
________________________________________________________________________________
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.
________________________________________________________________________________
From: | dab(at)froghouse.org |
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
________________________________________________________________________________
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.
________________________________________________________________________________
From: | dab(at)froghouse.org |
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
________________________________________________________________________________
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
>
________________________________________________________________________________
From: | Brian Lloyd <brian(at)lloyd.com> |
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> |
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
________________________________________________________________________________
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 |
---->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 |
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> |
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> |
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
________________________________________________________________________________
From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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> |
Anyone out there? Am I still connected to the avionics list?
________________________________________________________________________________
From: | "Steven J. Devine" <steve(at)tzogon.com> |
Subject: | Re: No activity? |
>
>
>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
________________________________________________________________________________
From: | Brian Lloyd <brian(at)lloyd.com> |
>
>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? |
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) |
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
________________________________________________________________________________
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 |
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/
________________________________________________________________________________
From: | dab(at)froghouse.org |
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
________________________________________________________________________________
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) |
>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 |
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 |
>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) |
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> |
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
________________________________________________________________________________
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
________________________________________________________________________________
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> |
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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 |
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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> |
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 |
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 |
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 |
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> |
>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 |
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 |
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> |
Same here, CAN!
________________________________________________________________________________
From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
Subject: | Don't forget your CAN reading material |
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 |
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 |
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> |
Aye
Marlin
>From: "Steven J. Devine" <steve(at)tzogon.com>
>
>Aye.
>
>Steve
________________________________________________________________________________
From: | "Rob Luce" <robluce1(at)yahoo.com> |
Subject: | Re: CAN vs Ethernet |
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 |
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
> >
>
>
>
>
>
________________________________________________________________________________
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 |
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
>
________________________________________________________________________________
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 |
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
________________________________________________________________________________
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 |
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.
>
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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
>
>
________________________________________________________________________________
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 |
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 |
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 |
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
________________________________________________________________________________
Subject: | Sunlight Readable Displays |
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)
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
>
> 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 |
>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
________________________________________________________________________________
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 |
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 |
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
________________________________________________________________________________
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 |
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
>
>
________________________________________________________________________________
From: | John Lazear <tomlazear(at)netscape.net> |
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.
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
Subject: | 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)
________________________________________________________________________________
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 |
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)
________________________________________________________________________________
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> |
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> |
All,
Has anyone found a source for small quanities of any of the CAN chips?
John
________________________________________________________________________________
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 |
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 |
Glen,
Thanks. Did you see the prices of the Zanthic development boards?
John
________________________________________________________________________________
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> |
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) |
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 |
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
________________________________________________________________________________
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) |
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
________________________________________________________________________________
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) |
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 |
>>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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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 |
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> |
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> |
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
>
>
________________________________________________________________________________
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.
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
From: | Brian Lloyd <brian(at)lloyd.com> |
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
________________________________________________________________________________
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
________________________________________________________________________________
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.
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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? |
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? |
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 |
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].
________________________________________________________________________________
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].
>
________________________________________________________________________________
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 |
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.
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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
>
>
________________________________________________________________________________
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
>
>===========================
>
________________________________________________________________________________
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
>
________________________________________________________________________________
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 |
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
>
>
________________________________________________________________________________
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) |
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) |
"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 |
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
________________________________________________________________________________
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
________________________________________________________________________________
"Avionics List Member"
Subject: | 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: | "Todd Chisum" <toddc12(at)hotmail.com> |
Subject: | 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???)
Thanks,
Todd Chisum
Tulsa, Oklahoma
Wag Aero Super Sport project
________________________________________________________________________________
From: | "Ronnie Brown" <rolandbrown(at)sprintmail.com> |
Subject: | Re: CDI switch for VOR-GPS |
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 |
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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?
________________________________________________________________________________
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
________________________________________________________________________________
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> |
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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> |
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
________________________________________________________________________________
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"
>
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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> |
> 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> |
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 |
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 |
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
________________________________________________________________________________
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 |
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
________________________________________________________________________________
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 ... |
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
>
>
________________________________________________________________________________
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
________________________________________________________________________________
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 ... |
> > 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 |
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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.
________________________________________________________________________________
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 ...
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
________________________________________________________________________________
From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
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
________________________________________________________________________________
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) |
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) |
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 |
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 |
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 |
>>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 |
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 |
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 |
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.
________________________________________________________________________________
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 |
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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 |
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 |
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 |
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... |
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
________________________________________________________________________________
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... |
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
________________________________________________________________________________
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
________________________________________________________________________________
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
________________________________________________________________________________
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
________________________________________________________________________________
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 |
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> |
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