Avionics-List Archive Browser

Avionics-Archive.digest.vol-ab
November 24, 1999 - December 28, 1999

On 24 Nov, To: avionics-list(at)matronics.com wrote: > I know there are chips available, looks like some pretty nice stuff > actually; I was just wondering if there were SBC's around that used > those chips or if we'd have to make our own hardware right from the > start. To answer my own question: http://www.emicros.com/cantec11.htm http://www.lawicel.com/e_c505cbbf.htm http://www.phytec.com/USAmerica/Mm515.html spend some time looking around this site, they got some cute little cards http://www.arcom.co.uk/products/icp/pc104/modules/AIMcan1.htm -Dave ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: AGATE Databus update
Date: Nov 24, 1999
All, I have talked to Walter Green (NASA/AGATE) about their AGATE DATAbus. It is based on Echelon's Lon Bus. (oh great, another bus). Walter said it is much faster ( 10 vs 1mps?) than CAN and cheaper. Here is what I have so far... Walter S. Green, Leader, Flight Systems Work Package Advanced General Aviation Transport Experiment Crew Vehicle Integration Branch. Tel. 1+757+864-3355 Mail Stop 152 Fax. 1+757+864-7793 Building 1268A, Room 1170, NASA Langley Research Center, Hampton, VA 23681 -----Original Message----- From: James K. Meer <microflight(at)att.net> Date: Wednesday, November 24, 1999 8:53 AM Subject: Re: Avionics Databus Architecture Walt Green has asked me to provide you with some information on the AGATE Databus. AGATE is an industry government consortium that was initially chartered with the goals of reviving general aviation and then as is now to create a Small Aircraft Transportation System. The AGATE portion was heavily technology based. As a part of the development of required technologies, the Databus was identified as an essential element. Over the last few years, many databuses have been evaluated, including CAN. As a result of these reviews, Echelon's Lon Bus was selected. The Lon bus is a multidrop, CSMA CD bus or translated has an open topology with Carrier Sense Multiple Access bus and Collision Detection. There are many features of the bus which are desirable including a very low cost -- approximately $1-2 per node and approx $6-8 with a microprocessor. The protocol is a fully defined 7 layer OSI compliant protocol. This provides for greater interoperability and commonly defined data packets. Further AGATE has developed software which will maintain the databus database packets and generate the required C code when the element is selected as well as provide other programming and architectural aids. The bus may be used for most sensors and controls including FADEC and control surfaces with a deterministic version. If you would like more information, I would suggest that you attend the session in Hampton on December 8th, 1999 at the Raddison Hotel. Regards, JKM James K. Meer, Principal Microflight ----- Original Message ----- From: Walter S. Green Sent: Tuesday, November 23, 1999 11:07 AM Subject: Fw: Avionics Databus Architecture Walter S. Green, Leader, Flight Systems Work Package Advanced General Aviation Transport Experiment Crew Vehicle Integration Branch. Tel. 1+757+864-3355 Mail Stop 152 Fax. 1+757+864-7793 Building 1268A, Room 1170, NASA Langley Research Center, Hampton, VA 23681 -----Original Message----- From: John W. Livingston <john.livingston@ascxp/wpafb.af.mil> Date: Tuesday, November 23, 1999 10:15 AM Subject: Avionics Databus Architecture >I am part of a sport aviation group trying to develop standards for >advanced avionics. Our aim is to reduce cost, improve performance and >allow for easy expansion of avionics systems . Our efforts have led us >to focus on the various databus architectures, particularly CAN, DoD's >CDA 101 and NMEA2000. I noticed your upcoming meeting to discuss the >same. Can I get your thoughts on where AGATE currently stands on this? >What are the current existing standards that you are looking at. > >John W Livingston >Senior Design Engineer >USAF ASC/ENFD > > ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: The CAN Bus Architiecture, Software and Softwa
re
Date: Nov 24, 1999
Dave >> In another vain, I found a Web sight that has JAVA on a >> microcontroller chip. > >With a CAN interface? Either way could you send me the URL? Thanks. > > - http://members.xoom.com/_XMCM/simpleRTJ/home.html John ________________________________________________________________________________
Date: Dec 01, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Getting back to the bus
Any further thoughts, anyone, on bus architecture? I started to muck around in the bowels of "The kvaser CDA101 specs" to see if there were any details about CAN that were deal killers as far as avionics are concerned. One thing I'm sure of--military documentation sucks! (Though the CDA101 documents aren't too loaded with jargon and "see obscure reference XYZ" I also wanted to grease the wheels by pre-interpreting the documentation a little bit so that it might help those of you who know more than I about embedded systems and interfaces. Here's a table of documents available at CANKing ( http://www.kvaser.com/archive/cda_specs/ ) Each of the following lines preceded by a number is a zipped PDF document that can be downloaded from the above site. Lower Level Specification 101/01 High-Level Specification 101/11 System Messages 101/12 D Parameter Definitions 101/21 P Controller Area Network * 101/22 P MIL-STD-1553 Bridge * 101/23 P UDP/IP Bridge * 101/24 P RS-232/422 Bridge 101/25 P Radio Frequency Transponder Bridge 101/26 P Routers 101/31 D Seaborne Target Systems 101/32 D Ground Vehicle Target Systems 101/33 D Sub-scale Aerial Target Systems 101/34 D Full-scale Aerial Target Systems 101/35 Rotary Wing Target Systems 101/41 D Common Controllers, Sensors, and Actuators 101/42 D Target System Augmentation P = Physical Layer Specifications D = Data Specifications * = Apparently not available Marlin Mixon ________________________________________________________________________________
Date: Dec 02, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: What about the Echelon Bus?
Refresher from John Livingston: I have talked to Walter Green (NASA/AGATE) about their AGATE DATAbus. It is based on Echelon's Lon Bus. (oh great, another bus). Walter said it is much faster ( 10 vs 1mps?) than CAN and cheaper. I went to the http://www.echelon.com/ page and found what appears to be a wealth of information--I didn't dig too deeply into it. What makes the Lon (ANSI/EIA 709.1) protocol cheap is it's consumer electronics approach--Echelon has a "vision of pervasive networking" and wants to put all your home appliances on a network including light switches, home entertainment systems, ovens, telephones, doorlocks etc. The high-volume mass-production of their chips would thus make them cheap. One question I'd want to look into is "What premium will we pay for the chips that can handle -50F" In any case, there is a document called: The LonTalk Protocol, An Open Standard for Controls. LonTalk is heavily patented by Echelon, but I'm ASSUMING that the patents and associated royalties apply only to the purchase of the chips that manage the protocol. Here's a relevent quote from a press release: The ANSI/EIA 709.1 protocol can be embedded into any processor, from 8-bit microcontrollers to 32-bit microprocessors. For cost-sensitive applications, developers can use Neuron Chips, a family of microcontrollers optimized for intelligent distributed control applications that include a built-in, interoperable implementation of ANSI/EIA 709.1. Neuron Chips are manufactured and distributed worldwide by Cypress Semiconductor ( http://www.cypress.com ) and Toshiba Corporation ( http://www.toshiba.com ). One drawback that I DO see is that the ANSI document describing the 709.1 protocol is not free online. A guess on the cost is $60 to download? Marlin Mixon ________________________________________________________________________________
From: dralle(at)matronics.com (Matt Dralle)
Date: Dec 02, 1999
Subject: 1999 List of Contributors #1 and a Special Thank You Message!!
Dear Listers, I would like to personally thank each and everyone that has contributed this year to 1999 List Fund Raiser! As you can see from the list of names below, there were many, many generous people from the Lists this time around and I want everyone to know just how much your support has meant to me. The list of members below includes those that have contributed during this year's List Fund Raiser as well as those that have contributed throughout the year and also those that made a donation to my Legal Defense Fund earlier in the year that was sponsored my our own Bob Nuckolls of Aero Electric. I want everyone to know just how much it means to me to receive the type of financial support for these Lists that I have this year. As the Lists have grown so much over the last few years, so have the equipment costs as well as the monthly costs such as the Internet connectivity. Your generosity during the Fund Raiser and throughout the year, truly makes the continued operation, and more importantly, the continued upgrade and improvement of these aviation-related services directly possible. That is the bottom line. Please accept my most sincere appreciation of the amazing and, at times, overwhelming generosity of so many of you wonderful people! Thank you!! For those of you that didn't quite get your contribution in on time for this first List of Contributors - be it by check or by credit card - I will be posting a followup List of Contributors #2 for 1999 in a few weeks to make sure that I properly acknowledge each and everyone of the generous List members. One last time, the addresses to make a contribution are: http://www.matronics.com/contribution or Matt Dralle c/o Matronics PO Box 347 Livermore, CA 94551 Finally, thank you all so much for your support this year both in terms of the financial contribution but also in the form of the letters and moral support during what can only be categorized as a very stressful and unsettling time. And I think you know what I'm referring to... Your support and encouragement meant more to me than you'll ever know. I felt as if I had 2500 friends all behind me, and that's a *powerful* force! Well done one and all! Thank you! Best regards for the upcoming year. Your Email List Administrator, Matt Dralle RV-4 Builder #1763 =================== 1999 List of Contributors #1 ==================== Abell, John Acker, Rob Adams, Bob Adamson, Larry Ahamer, Karl Albachten, Rudy III Alcazar, Jesus Allen, Brent Allison, Steven Ammeter, John Amundsen, Blair Anderson, Edward Armstrong, Robert Arnold, James Aronson, David Ashford, James Ashton, Kent Atkinson, Harold Baggett, Robert Baker, Gary Baker, Ray Baldwin, James Barlow, Melvin Barnes, Thomas Barnes, Tom Barnhart, Dave Barrenechea, Godo Battles, Brenton BB Diversified Services, LTD Bechtel, Amos Bell, Bruce Belted Air Power LTD. Benhan, Dallas Bennett, Peter Besing, Paul Bieber, Mike Bilodeau, Paul Bird, Carroll Blanton, Stan Bleier, Roger Blomgren, Jack Blum, Ronald Boadright, Kyle Boardman, Don III Boatright, Kyle Boatright, Robert Bodie, Pete Bonesteel, Wayne Booze, Gregory Borne, Charles Bourgeois, Rion Bourne, Larry Bovan Pe, Vaso Bowen, Larry Bowen, Miles Bower, Bob Bowhay, Eustace Bowman, Brian R Boyd, Rodney Branscomb, Warren Bray, Garrett Brian Lloyd Brick, John Bridgham, David Brogley, Mike Brooks, Chris Brooks, John Brott, Marvin Brown, Kent Brown, Scott Buckwalter, David - Avionics Systems Burlingame, Ralph Burnham, Dave Calhoun, Ronald Calvert, Jerry Cantrell, Ken Capen, Ralph Cardinal, Gregory Carey, Christopher Carr, David Carter, Jerry Carter, Ron Casey, Jeremy Chapple, Glen Chesnut, Bruce Chesnut, William Christensen, Peter Christie, William Churchill, Frank Ciolino, John Clabots, Gerald Clark, Howard Clark, James Clary, Buck Clay, Dennis Cloughley, Bill Cole, Ed Colontonio, Moe Colucci, Anthoney Conaway, James Cook, David Sr. Cooley, John Copeland, Forrest Corder, Michael Corriveau, Grant Cotter, Timothy Cox, Carson Croby, Harry Crosley, Richard Cullen, Chuck Czinkota, Garnet Dall, Richard Daudt, Larry Davidson, Jeff Davis, Christopher Davis, Jared Davis, Steve - The Panel Pilot Davis, William Day, Robert Deffner, David Del Peso, Jose Derrik, Chuck Desmond, Richard Devine, Steven Devlin, John Dewees, Ron Dial, J.R. Dominey, Clifford Dorsey, Bob Downing, Jeff Dubroc, Tommy Dudley, Richard Duffy, Russell Duncan, John Dunlap, E.T. Dziewiontkoski, Bob Eagleston, Ron Eagleston, Ronald Eastburn, James Elder, William Elhai, Irv Emrath, Marty Ensing, Dale Ervin, Thomas Erwin, Chip - Czech Aircraft Works Evans, Monte Exstrom, Daniel Faile, David Farrar, Jeffrey Farris, Paul Fetzer, George Fiedler, Mike Filucci, Michael - Red Dragon Aviaion Finch, K Flaherty, Edward Floyd, Joseph Ford, David Forrest, Gerald Forsting, Robert Fortner, Earl Four Star Products Frank, Dan Franz, Carl Frazier, Vince Frederick, Mark French, Edwin Friedman, Frank Froehlich, Carl Fromm, John Fry, John Funk, Edwin Jr. Funnell, Augustus George, William Gilbert, Mark Giusti, Roberto Glaser, Arthur Glass, Roy Glover, Ken Gold, Andy - Builder's Book Store Goldberg, Mark Good, Chris Gooding, Lawrence Goolsby, Jim Gott, Shelby Goudreault, Jacques Graham, James Jr. Grant, Jordan Griffin, Bill Griffin, Randy Groom, Larry Guillosso, Alain Hale, Michael Hales, Sherman Hall, Bob Hall, Thomas Hamer, Steven Hamilton, Thom Hamilton, William Hand, Chris Hansen, Ronald Hargis, Merle Harmon, John Harper, Malcom Harrill, Roy Harris, John Hart, Daniel Harvey, Doug Hassall, J.C. Hastedt, Margaret Hatch, Fletcher III Hatcher, Clive Hatfield, Cecil Hays, Wes Henderson, George Henderson, Randall Heritch, Ian Herndon, Richard Herren, Bill Hevern, Jerry Hiatt, Mark Hiers, Craig Hinch, Christopher Hine, Joe Hinkley, Curtis Hinrichsen, James Hodge, Jack Hodgson, Bob Hodson, Frank Hoffman, Carl Holcombe, Richard Horton, Kevin Hoshowski, Ken Hrycauk, Dave Hughes, Robert Hulen, Fred Hundley, Richard Hurd, James Hurlbut, Steve Hutcheson, Ken Ihlenburg, Fred Ingram, Jim Irace, Bill Irwin, Eric Isler, Jerry Ivers, James James, Larry Janes, Bob Janicki, Steven Japundza, Bob Jeens, Ken Johannsson, Johann Johnson, Jackie Johnson, Stephen Jones, Bryan Jones, Rob Jones, Russ Jonker, Bill Jordan, Thomas Jory, Rick Kampthorne, Hal Kayner, Dennis Keithley, Rick King, Da Ve Kirby, Dennis Kirby, Graham Kirtland, Charles Kitz, John Knezacek, Dan Knievel, Gerald Knoll, Bruce Kosta, Michael Kowalski, Ed Krueger, Dan Krueger, Scott Kuss, Charlie Laczko, Frank Sr. Lamb, Richard Lane, Kevin Lassen, Finn Laurence, Peter Laverty, Mike Lawson, John Leaf, Dave Lee, John Lee, Ric LeGare, Garry Leggette, Len Leonard, William Lerohl, Gaylen Lervold, Randy Lewis, Terry Lewis, Tim Ligon, Howard Lind, Laird Linebaugh, Jeffrey Loeber, Wayne Ludeman, Bruce Lutes, Rick Mac Donald, Lawrence MacKay, Alex Malczynski, Francis Mandell, Tom Marino, Anthony Marion, Chris Markert, Michael Marshall, Robert Martin, Tom Maxson, Phil Mazatuad, Mme Hyun Sook McElhoe, Bruce McFarlane, Lloyd McGee, Michael McHarry, Joe McHenry, Tedd McKibben, Gerald McNamara, Don Melder, Frank Melia, Tom Metzger, Stephen Meyers, John Miller, Jim & Dondi - Aircraft Technical Support Mitchell, Duane Moen, Craig Mojzisik, Allan Molzen, Jason Mondy, Malia Moore, Thomas Moore, Warren Morelli, Bill Morelli, William Morris, Daniel III Morrison, Mark Morrow, Dan Moulin, Roger Munn, Mike Murphy, Ray Jr. Neal, Danny Nellis, Michael Nelson, James Nelson, Jim Newell, Alan Nguyen, Thomas Nice, James Nicely, Vincent Norris, Rob Nowakowski, Donald Noyer, Robert Nuckolls, Robert Olendorf, Scott Olson, Larry Olson, Tom Orear, Jeffrey Owens, Laird Palinkas, Gary Pardue, Larry Paulson, Craig Peck, Bill & Kathy Peer, Michael - Jem Aviation Peryk, Dennis Peternel, Stanley Petersen, Eric Petersen, Paul Peterson, Alex Pflanzer, Randy Phillips, Mark Pickrell, Jim Pike, Richard Pinneo, George Pittenger, Dick Plathey, Claude Point, Jeff Polstra, Philip Porter, Richard Porter, Robert Potter, Mark Pretzsch, Robert Ragsdale, Bill Randolph, George Ransom, Ben Rathbun, Richard Reeck, Jay Reed, Derek Reed, Frank Reisdorfer, Mark Reynolds, Richard Richardson, Ray - Powersport Aviation Inc. Riedlinger, Paul Riley, Stuart Roach, Brian Rodgers, Brian Rosales, Paul Rowbotham, Charles Rowles, Les Rozendaal, Doug Rutherford, Ted Sa, Carlos Sager, Jim Sailer, Martin SanClemente, Andrew Sapp, Doug Sargent, Tom Sax, Samuel Schemmel, Grant Schippers, John Schmitt, Clayton Schneeflock, Robert Schrimmer, Mark Schwarz, Guillermo Selby, Jim - JKL Aviation Sales Seward, Douglas Shackleford, Howard Shafer, Jim Shank, Bill Sheets, Douglas Shenk, Doug Shepherd, Dallas Shettel, Maurice Shipley, Walter Sigmon, Harvey Silverstein, Chuck Sipp, Dick Slaughter, Mike Small, Thomas Smith, Clayton Smith, Edmund Smith, Philip Smith, Shelby Smithey, Lloyd Snyder, David Solecki, John Sparks, Timothy Stafford, David Staub, Skip Steer, Bill Stobbe, Bruce Stoffers, Larry Stone, James Strandjord, Eric Swaney, Mark Tauch, Eric Tauchen, Bryan Taylor, Tod Team Rocket Thayer, George Therrien, Michel Thistelthwaite, Geoffrey Thoman, Daniel Thomas, Lee Thomas, Tim Thompson, Michael Todd, John Tompkins, Jeff Tower, John True, George Tucker, Harold Tuton, Beauford Tyrrel, Charles Upshur, Bill Uribe, Guillermo Uribe, Gullermo Utterback, Thomas Van Der Sanden, Gert Vandervort, Ronald VanGrunsven, Stanley Varnes, William Volum, Peter Von Ruden, Dennis VonLindern, Paul Vosberg, Roy Waligroski, Gregg Walker, Tommy Walrath, Howard Ward, Ed Warren, John Washburn, Oliver Watson, Dennis Watson, Terrence Watson, William Webb, Randol Weber, Ed Weber, Edward Weller, Michael Wendel, Jim Wentzell, David Werner, Russ Werner, Russell Westridge, David Whelan, Thomas Whiler, Douglas Whitehead, Arthur Wiesel, Dan Wigney, John Williams, Jimmy Williams, Keith Williams, Lawrence Willig, Louis Wills, Mike Wilson, Billy Wittman, James Wood, Denton Wood, John Wood, Mark Worstell, Glen Worthington, Victor Wotring, Dale Wymer, Gerald Young, Charles Young, Rollin Youngblood, Barry Zeidman, Richard Zigaitis, Kestutis Zinkham, Ralph Zwart, Frank -- 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: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: What about the Echelon Bus?
Date: Dec 02, 1999
Marlin, All, I've been a little frustrated by my research into Echelon's LonTalk databus and the fiber-optic media by Raytheon. It sounds good in many ways, but I can't seem to find anything related to the availability and cost of hardware or software. Echelon's site has got lots of PR and overview papers etc, but when you try to find standards or other technical documents or prices it comes up short. I get the feeling that Echelon has held this very close(just there circle of developers) and is just now in the process of opening it up. Also, details and availability of the redundant fiber-optic technology from Raytheon is not on the net, just PR. I have not found anything on frequencies greater than 1.25mbs for LonTalk.( the fiber-optic media should be able to go much faster, but may be limited by the Neuron chips. Has anyone found a site that sells these and gives a price? At this stage of my research I have more questions than answers. I sure would like to attend that Dec 9 AGATE databus meeting, but I can't swing it. How can you have a low cost open architecture and standard when no one knows anything about it. No one talks about it (except Echelon and one or two others). No one has prices listed. The draft standards aren't available. etc. Go figure. Maybe I've missed something. Can anyone give me a lead on this????? John -----Original Message----- From: Marlin Mixon [mailto:myshkin(at)worldnet.att.net] Sent: Thursday, December 02, 1999 1:13 AM Subject: Avionics-List: What about the Echelon Bus? Refresher from John Livingston: I have talked to Walter Green (NASA/AGATE) about their AGATE DATAbus. It is based on Echelon's Lon Bus. (oh great, another bus). Walter said it is much faster ( 10 vs 1mps?) than CAN and cheaper. I went to the http://www.echelon.com/ page and found what appears to be a wealth of information--I didn't dig too deeply into it. What makes the Lon (ANSI/EIA 709.1) protocol cheap is it's consumer electronics approach--Echelon has a "vision of pervasive networking" and wants to put all your home appliances on a network including light switches, home entertainment systems, ovens, telephones, doorlocks etc. The high-volume mass-production of their chips would thus make them cheap. One question I'd want to look into is "What premium will we pay for the chips that can handle -50F" In any case, there is a document called: The LonTalk Protocol, An Open Standard for Controls. LonTalk is heavily patented by Echelon, but I'm ASSUMING that the patents and associated royalties apply only to the purchase of the chips that manage the protocol. Here's a relevent quote from a press release: The ANSI/EIA 709.1 protocol can be embedded into any processor, from 8-bit microcontrollers to 32-bit microprocessors. For cost-sensitive applications, developers can use Neuron Chips, a family of microcontrollers optimized for intelligent distributed control applications that include a built-in, interoperable implementation of ANSI/EIA 709.1. Neuron Chips are manufactured and distributed worldwide by Cypress Semiconductor ( http://www.cypress.com ) and Toshiba Corporation ( http://www.toshiba.com ). One drawback that I DO see is that the ANSI document describing the 709.1 protocol is not free online. A guess on the cost is $60 to download? Marlin Mixon ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Glass Cocokpit: Environmental concerns (was Echelon
Bus)
Date: Dec 02, 1999
>One question I'd want to look into is "What premium will we pay >for the chips that can handle -50F" I hadn't really thought about environmental concerns until I read that line... My subconsious was thinking that "the system" would be in the panel, so its environment would be the same as mine... in operation, the environment would be reasonably moderate in temperature, humidity, etc. But now the conscious kicks in... These devices will be located various parts of the aircraft, and some will be subjected to pretty harsh environments... high altitude winter flight will make most areas or the plane pretty damn cold. And the engine sensor package will be in an area which can get quite warm, particularly in the summer... Hmmm... yet another thing to think about when designing/building this thing. 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: Glen_Worstell(at)notes.seagate.com
Date: Dec 02, 1999
Subject: Lon vs CAN
It appears that controllers for and information about the CAN bus are readily available, while the Lon bus is proprietary and currently does not have wide support from multiple manufacturers. With a bit of net surfing I found that I can order a CAN controller (or micro with a CAN controller built in) from multiple manufacturers, and transceivers for CAN; and I suspect that in a very short time I could have a CAN bus working. The situation for Lon looks much more hazy. My non-expert opinion, if I had to vote today, would be to go with CAN. cheers, Glen. ________________________________________________________________________________
Date: Dec 02, 1999
From: dab(at)froghouse.org
Subject: Re: Lon vs CAN
On 2 Dec, Glen_Worstell(at)notes.seagate.com wrote: > The situation for Lon looks much more hazy. My non-expert opinion, > if I had to vote today, would be to go with CAN. If we want to build something now, Lon doesn't look like an option. However, if we design for CAN it really should be a pretty small effort to move it over to any other bus that comes along later that provides equal or greater functionality. I'd say there's no reason not to move forward with what's available now and build and experiment to our heart's content. -Dave ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Lon vs CAN (485?)
Date: Dec 02, 1999
>> The situation for Lon looks much more hazy. My non-expert opinion, >> if I had to vote today, would be to go with CAN. > >If we want to build something now, Lon doesn't look like an option. >However, if we design for CAN it really should be a pretty small >effort to move it over to any other bus that comes along later that >provides equal or greater functionality. > >I'd say there's no reason not to move forward with what's available >now and build and experiment to our heart's content. I concur. Does anyone have any argument AGAINST deciding on the CAN bus and moving on to the messaging component? I have to admit, working with an open standard, and using your choice of components availaible from multiple vendors in a competetive market does sound like a good thing... :) Incidentally, has the RS-485 been completely ruled out? Why/why not? It seems like we just stopped talking about it... Steve steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 02, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Lon vs CAN (485?)
On Thu, 2 Dec 1999, Steven J. Devine wrote: > Incidentally, has the RS-485 been completely ruled out? Why/why not? It > seems like we just stopped talking about it... I don't think it is completely ruled out but I think it is suboptimal because RS-485 uses a standard character-at-a-time serial interface to the computer. It is lowest common denominator but doing block-mode or packet type data transfers is nontrivial. If the CAN buss automates this process it is going to be easier to program and less prone to bugs and failures. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 02, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Glass Cocokpit: Environmental concerns (was
Echelon Bus) On Thu, 2 Dec 1999, Steven J. Devine wrote: > ... high altitude winter flight will make most areas or the > plane pretty damn cold. And the engine sensor package will be in an area > which can get quite warm, particularly in the summer... No reason not to put your engine sensor interface module behind the firewall. That is where I located mine in my RV-4 (AFA AV-10) and then just ran the sensor wires through the firewall. Even so, it is a good idea not to exceed the environmental range on the components. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Lon vs CAN (485?)
Date: Dec 02, 1999
>> Incidentally, has the RS-485 been completely ruled out? Why/why >> not? It seems like we just stopped talking about it... > >I don't think it is completely ruled out but I think it is suboptimal >because RS-485 uses a standard character-at-a-time serial interface >to the computer. It is lowest common denominator but doing >block-mode or packet type data transfers is nontrivial. > >If the CAN buss automates this process it is going to be easier to >program and less prone to bugs and failures. I was thinking along these same lines... if the hardware of the CAN controller "framed" the packets like an ethernet chip does, it would make the system less error prone... Steve steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 03, 1999
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: Lon vs CAN (485?)
"Steven J. Devine" wrote: > >> Incidentally, has the RS-485 been completely ruled out? Why/why > >> not? It seems like we just stopped talking about it... > >I don't think it is completely ruled out but I think it is suboptimal > >because RS-485 uses a standard character-at-a-time serial interface > >to the computer. It is lowest common denominator but doing > >block-mode or packet type data transfers is nontrivial. I don't think that data comms is going to be a bottleneck, so the fact that RS-485 is suboptimal really isn't important. There's no reason (apart from more work) why a packet-based RS-485 board couldn't be built. I envisage something like an 8051 which would do all the comms work and only interrupt the main CPU when it had a good packet. This is more or less how Ethernet cards work. Having said that, I think there would be a lot of work involved, for very little gain over CAN. And I agree with the earlier comments about LON -- it has been around for several years without gaining major backing. I assume that's because the system designers at major companies are leary of proprietary standards. People might also be interested in looking at Steve Eberhart's Aerocomputer page at http://www.evansville.net/~newtech/ -- this stuff is a summary of the rec.aviation.homebuilt glass cockpit discussions some years ago. Frank. (Incidentally, feel free to put the mini-bio I posted up on your Web page Steve) ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Lon vs CAN
Date: Dec 02, 1999
Glen, All I agree, but will continue to monitor and pass along anything I find about the AGATE/LonTalk/Raytheon databus. -----Original Message----- From: Glen_Worstell(at)notes.seagate.com The situation for Lon looks much more hazy. My non-expert opinion, if I had to vote today, would be to go with CAN. ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Re: Glass Cocokpit: Environmental concerns (wa
s Echelon Bus)
Date: Dec 02, 1999
Steve, All, I think I read where the auto industry stuff is good to -50. John -----Original Message----- From: Steven J. Devine [mailto:steve(at)tzogon.com] Sent: Thursday, December 02, 1999 9:32 AM Subject: Avionics-List: Re: Glass Cocokpit: Environmental concerns (was Echelon Bus) >One question I'd want to look into is "What premium will we pay >for the chips that can handle -50F" ________________________________________________________________________________
Date: Dec 03, 1999
From: dab(at)froghouse.org
Subject: Re: Lon vs CAN (485?)
On 2 Dec, Steven J. Devine wrote: > Incidentally, has the RS-485 been completely ruled out? Why/why not? It > seems like we just stopped talking about it... In addition to Brian's comments, I'd add that the access method CAN has blows the doors off anything I've seen written for RS-485. CAN isn't quite as ubiquitous as RS-485, but it appears to be available enough. -Dave ________________________________________________________________________________
Date: Dec 04, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: What's our name?
I guess most efforts like the one we are undertaking usually don't have a name they call themselves, but I'd find it useful when grabbing documents off the net if I could use a specific organization identifier. I have been using: "Affiliation of Avionics Hombuilders on the Internet", but it's kind of long and I can't consistently reproduce it. What do you think? Should we name ourselves? Do we already have a name? If we DO come up with a name, I think it should not be a name that anyone has commonly heard before--this is so if people are doing searches on our organization on the internet, they can find us by keyword without getting a bunch of false hits. Marlin ________________________________________________________________________________
Date: Dec 04, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN employs an unusual "kingdom" metaphor
Since it sounds like we're going to go with CAN, I started to study it. I downloaded two documents from the archive: http://www.kvaser.com/archive/cda_specs 101/11 (System messages) and 101/21 (Controller Area Network). In 101/11 I noticed CAN's unusual and pervasive kingdom metaphor. I don't understand these terms yet, but here they are: capital city kings document * kings pages * city, cities mayors document * mayors pages * * Clearly these are posessives, but the documentation doesn't use the apostrophe "S" CAN has has a sophisticated feature that enables it to load software over the network. This and other complexities appear to me to be the reason why the kingdom metaphor was chosen. I think the reason why they use this kingdom metaphor is to objectize the task of multiple designers working on the same project, but at the same time each designer or team may work in their own compartmentalized area. (Sounds potentially helpful to us.) Although the metaphor is used in CAN documents dealing with the software layer, I don't see it being used in the physical layer. 101/21 describes everything you need to know to cable up CAN, though it does refer you to the NMEA 2000 spec. Marlin Mixon ________________________________________________________________________________
From: "Matthew Mucker" <matthew(at)mucker.net>
Subject: Re: What's our name?
Date: Dec 04, 1999
Gee, I always call it "The Glass Cockpit Project" in my thinking! For what it's worth, the Internet domain name "glasscockpitproject.com" is available. "glasscockpit.com" is taken. www.glasscockpit.com takes me to a web site that seems to be vacant. -Matt -----Original Message----- From: Marlin Mixon <myshkin(at)worldnet.att.net> Date: Saturday, December 04, 1999 10:32 AM Subject: Avionics-List: What's our name? I guess most efforts like the one we are undertaking usually don't have a name they call themselves, but I'd find it useful when grabbing documents off the net if I could use a specific organization identifier. I have been using: "Affiliation of Avionics Hombuilders on the Internet", but it's kind of long and I can't consistently reproduce it. What do you think? Should we name ourselves? Do we already have a name? If we DO come up with a name, I think it should not be a name that anyone has commonly heard before--this is so if people are doing searches on our organization on the internet, they can find us by keyword without getting a bunch of false hits. Marlin ________________________________________________________________________________
Date: Dec 05, 1999
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: What's our name?
Matthew Mucker wrote: > Gee, I always call it "The Glass Cockpit Project" in my thinking! Me too. However, I kind of like Steve Eberhart's "Aerocomputer". > For what it's worth, the Internet domain name "glasscockpitproject.com" is > available. "glasscockpit.com" is taken. www.glasscockpit.com takes me to a > web site that seems to be vacant. Do we need a domain name? I personally don't think so. Frank. ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: What's our name?
Date: Dec 04, 1999
>Gee, I always call it "The Glass Cockpit Project" in my thinking! Me too... though we may want to add another word to distinguish ours, such as Homebuilt Glass Cockpit Project, or some such. (or something more imaginative if anyone can come up with something better)... Or, come up with a name that also describes the architecture, bus, or some such. That way people have some way of identifying compatible components... >For what it's worth, the Internet domain name "glasscockpitproject.com" >is available. "glasscockpit.com" is taken. www.glasscockpit.com takes >me to a web site that seems to be vacant. Hmmm... I *COULD* just add another virtual domain to my linux box... is it worth it??? Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 05, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN Implementations
Hi all, According to http://www.omegas.co.uk/CAN/implement.htm there are several different modes of operations that you can use to implement CAN. One question that came up earlier was: do we want to use CAN 2.0A (11 bit identifier) or CAN 2.0B (29 bit identifier)? One respondent wanted to defer that question to a CAN expert. Until we can chat with a CAN expert, I have some ideas on the subject. 11 bits would give us, at the most, 2048 different identifiers, whereas 29 bits would give us 529 billion. Identifiers allow us to identify which module is sending or is to receive a message. You can certainly develop a glass cockpit for a GA airplane without exceeding the 2048, even if you placed Angle of Attack pressure sensors (Motorolla MPX100s) with 1" spacing along the whole leading edge of your wing top and bottom, you'd still only be using up 600-700 identifiers, but even then, you'd probably put all those sensors on their own dedicated buss. This, of course, assumes that we would be serially numbering/identifying each module. When we DO that, it means that we need to keep track, somehow, of all the modules that we've installed so far. It also means that the main CPU needs to know what every ID does. What we have is a configuration issue. There is another approach: Develop a numbering scheme using 29 bit identifiers that does two things: 1) uniquely identifies each module (so you don't get any id conflicts) by a serial number and 2) Encodes the function of the module, i.e. code 210 might mean upper AOA pressure sensor, left wing and code 221 might mean lower AOA pressure sensor, right wing. By identifying the module correctly, it can be integrated into the net work sort of like "plug and play." The drawbacks of the "Plug and Fly" approach are: 1. The longer identifiers reduce network capacity by a certain percentage. CAN is limited to 1 Mbit/S for data PLUS network overhead. We will probably want all the bandwidth we can get. 2. The Mice and Men problem: as much as we plan, we still can't anticipate all possible configurations that people would want to experiment with in an aircraft. So my recommendation is to go with CAN 2.0A, and develop configuration techniques that make it easy to set up the network. Marlin Mixon ________________________________________________________________________________
From: "Chris Atkinson" <chris-atkinson(at)home.com>
Subject: What's our name?
Date: Dec 05, 1999
HI guys, you'll all probably start flamin' me for this, but who cares. I'm going back to my original concepts...i.e. use pre-built hardware & software components with minimal re-inventing-the-wheel. This thread has become way too academic for me....the chances of making a real system any time soon seems to be losing ground with every post. Anyways, I'm sure you're all wonderful guys & great pilots...I apologize for the negativism. ...sincere best wishes for your scheme. Over & out. Chris ________________________________________________________________________________
Date: Dec 06, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: CAN Implementations
Marlin Mixon wrote: > So my recommendation is to go with CAN 2.0A, and develop configuration > techniques that make it easy to set up the network. It might be that we'll have to go with CAN 2.0B anyway because I was looking at MCU chips at Motorolla and all they seemed to offer were for CAN 2.0B. Marlin Mixon ________________________________________________________________________________
Date: Dec 06, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN Module board
I'm interested in what you think about this board: 1) will it accept a Motorola CAN chip? and 2) Can it be interfaced to the CAN bus? 3) Any other solutions out there that are cheaper or less required modifications out there? This kit board is a simple board that the Seattle Robotics Society sells for $60. It uses the 68HC12 chip. The reason why I'm interested in a board that has as much power as this one does because one of my personal goals for the GCP is to build an engine monitor. The 68HC12 has eight A/D input channels that get you most of the way there (I will probably have to put two of these on the bus in order to monitor all the analog inputs that I want to monitor). There's a circuit diagram and building instructions at: http://www.nwlink.com/~kevinro/b32brd.pdf Does anyone know if I could swap in a 68HC912BC32 Microcontroller (that runs CAN 2.0B) in place of the 68HC912B32 (the MCU that comes with the kit)? The only interface that this board comes with is a TTL serial interface, however, as you can see from the PC board diagram in the documentation, theres a handy little breadboard off to the right allowing you to expand it somewhat. Anyone know how hard it would be to interface CAN properly? I know that some people are using Intel 82527 chips to interface CAN to 68HC11 MCUs. Would that be feasible in this instance? Thanks, Marlin Mixon ________________________________________________________________________________
Date: Dec 06, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Implementations
>One question that came up earlier was: do we want to use CAN 2.0A (11 >bit identifier) or CAN 2.0B (29 bit identifier)? One respondent wanted >to defer that question to a CAN expert. Until we can chat with a CAN >expert, I have some ideas on the subject. 11 bits would give us, at the >most, 2048 different identifiers, whereas 29 bits would give us 529 >billion. One of the things we have discovered in designing the Internet is that you should give yourself a lot more room than you think you need. 29 bits makes a lot more sense. >This, of course, assumes that we would be serially numbering/identifying >each module. When we DO that, it means that we need to keep track, >somehow, of all the modules that we've installed so far. It also means >that the main CPU needs to know what every ID does. What we have is a >configuration issue. Dave and I have been tossing this back and forth for the last week in private email. My take on this "problem" is that configuration is a one-time issue, i.e. performed when a module or modules are installed on the buss, and therefore is not a big problem. >There is another approach: Develop a numbering scheme using 29 bit >identifiers that does two things: 1) uniquely identifies each module (so >you don't get any id conflicts) by a serial number and 2) Encodes the >function of the module, i.e. code 210 might mean upper AOA pressure >sensor, left wing and code 221 might mean lower AOA pressure sensor, >right wing. By identifying the module correctly, it can be integrated >into the net work sort of like "plug and play." Actually, it isn't quite that easy since you might want a module to source more than one of a particular attribute from the same module. Engine parameters like CHT and EGT come to mind here. As much as one might hate it, this is where something like SNMP (simple network management protocol) experience comes in handy. (FYI, Dave Bridgham is one of the world-wide industry experts in network monitoring and managment, a skill that impinges directly on our project.) Dave and I have been using a shorthand that looks something like this: engine1.CHT.1 engine1.CHT.2 engine2.EGT.1 engine2.oilp Clearly we need to get a list of interesting attributes sooner rather than later so that we can decide if they are repeated (indexed). From this we can take a stab at how we want to partition up the 29 bits in attribute identifier. Box ID is certainly one of the fields we want but how many bits to allocate is not so clear. >The drawbacks of the "Plug and Fly" approach are: >1. The longer identifiers reduce network capacity by a certain >percentage. CAN is limited to 1 Mbit/S for data PLUS network overhead. >We will probably want all the bandwidth we can get. If giving up 18 bits per message causes us heartburn, we have a serious problem and need to be really rethinking the buss. The MIL-STD-1553 avionics buss is 1Mbps and the military is only just now starting to think about upgrading it to 10Mbps. IMHO their buss traffic is likely to be a lot greater than anything we are likely to find in any GA aircraft. Given that I suspect rather strongly that 1Mbps is sufficient for our current and future needs. >2. The Mice and Men problem: as much as we plan, we still can't >anticipate all possible configurations that people would want to >experiment with in an aircraft. Right, so build in overkill. 29 bits is probably sufficient in that respect. 11 bits is, IMHO, woefully inadequate. >So my recommendation is to go with CAN 2.0A, and develop configuration >techniques that make it easy to set up the network. Then we are in opposition. IMHO we cannot do things in a clean fashion with only 11 bits and still have room for expansion. 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: CAN Implementations (A vs B, attributes)
Date: Dec 06, 1999
Concerning CAN 2.0A vs 2.0B... I agree with Brian on all points, and also feel that the 29 bit resolution is the way to go. However, I think that it would be best to simply decide that the group as a whole approved of the use of the CAN bus (those who have an opinion), regardless of which version for the time being. As we start to work on our message and numbering scheme, our requirements will start to become evident. Again, we want to design something that can not only be used by this group developing the standard, but also anyone down the road who may want to benefit from our work. Things like multi-engine and such need to be considered and incorporated... So lets move on to the attribute list for the time being. Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 06, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: aircraft attributes/parameters
Dave and I went through this exercise a couple of years ago. I didn't hang on to my original message so I will try to recreate it here where it can live in the archives indefinitely. In my shorthand below I will indicate with a period and a number after the attribute name my guess as to how many instantiations we might have for a given attribute. For example, my big radial engine has four rows of nine cylinders leading me to want at least 36 instantiations of CHT and EGT per engine. You know, if we determine that the largest index on a parameter is something like 64, we can encode the 6-bit index right into the attribute value. We need discussion on whether dedicating 6 of our 29 attribute ID bits to an index is sensible. Attributes: Airframe: pitch position roll position pitch rate roll rate yaw rate magnetic heading (this is yaw position) true heading pressure altitude absolute altitude true altitude IAS dynamic pressure (this is pitot absolute pressure) OAT Angle of attack cabin pressure cabin rate-of-climb elevator position.2 rudder position.2 (the "Connie" has three rudders so is 2 enough?) aileron position.4 (accommodate biplanes?) flap position.4 (L&R, inner and outer flaps) spoiler position.8 slat position.4 landing gear position.8 (multiple trucks?) door status.8 brake system pressure.4 brake temperature.8 fuel tank float position.16 fuel quantity.16 hydraulic system pressure.4 hydraulic fluid quantity.4 hydraulic fluid temperature.4 pneumatic system pressure.4 DC electrical buss voltage.4 DC electrical buss current.4 AC electrical buss voltage.4 AC electrical buss current.4 alternator/generator load.4 buss cross-connect state.8 (this is a placeholder -- need discussion) Universal engine attributes: prop/PTO RPM torque oil pressure oil inlet temperature oil outlet temperature fuel flow fuel pressure "chip" status fuel source (which tank is feeding the engine) Recip engine attributes: crankshaft RPM crankshaft position (I am reaching here) mag/ignition timing.8 CHT.64 EGT.64 TIT.2 (is there anything with more than 2 turbochargers?) MAP upper deck absolute pressure induction air temp turbocharger RPM.2 Turbine engine attributes: (I need help here) gas generator RPM N.4 (interstage pressures as I recall) Avionics and navigation attributes: comm frequency.4 comm xmit state.4 comm audio level.4 nav freq.4 nav obs.4 nav valid.4 nav mode.4 (localizer vs VOR) nav radial.4 nav CDI.4 nav to/from.4 nav ID.4 nav audio level.4 GS freq.2 GS CDI.2 GS valid.2 DME freq.4 DME distance.4 DME speed.4 DME ID.4 DME audio level.4 ADF freq.2 ADF bearing.2 ADF valid.2 ADF ID.2 ADF audio level.2 (should nav, ADF, and DME be combined for TACAN?) TACAN frequency.2 TACAN bearing.2 TACAN distance.2 TACAN speed.2 TACAN valid.2 TACAN audio level.2 XPDR mode.2 (off, stby, mode-A, mode-C, ???) XPDR squawk.2 XPDR reply.2 (do we want to dump this on the buss?) LORANC GRI.2 (would you ever have more than two LORANC receivers?) LORANC lat/lon.2 LORANC course/track.2 LORANC groundspeed.2 LORANC station valid/blink.64 (how many LORANC stations are there?) GPS lat/lon.2 GPS altitude.2 GPS course/track.2 GPS groundspeed.2 GPS pitch.2 GPS roll.2 GPS yaw.2 GPS pitch rate.2 GPS roll rate.2 GPS yaw rate.2 (the following are generated by the appropriate devices in a repetitive manner) lightning strike (bearing, dist, and intensity) WX radar return (bearing, dist, tilt, intensity) traffic (bearing, dist, alt, velocity) FMS stuff: (FMS stuff will require lots of editing) desired heading desired altitude desired airspeed desired rate-of-climb/descent barometric setting waypoint (can we encode lat/lon, alt, and type into one CAN msg?) Lever, button, knob movement: lever (ID, position) button (ID, press/release) knob (ID, direction of rotation, number of clicks) --------- At this point my brain is starting to fade. I suspect that what I have above will generate sufficient discussion to keeps us busy for several hours at least. ; ) 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: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Source for cheap displays
Date: Dec 07, 1999
I just came across this page with lots of references and cheap sources for displays - I imagine we require some cheap sources for early test and demonstration units.... Joe Hovel ________________________________________________________________________________
Date: Dec 07, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Re: Source for cheap displays
Joe Hovel wrote: > > > I just came across this page with lots of references and cheap sources for > displays - I imagine we require some cheap sources for early test and > demonstration units.... > Sounds good. Are any of them color? Do you know if any of the color displays are brighter than 110 Candellas/m2? Marlin Mixon ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: tiny mobile computer & display
Date: Dec 07, 1999
Came across this site while looking at the Sharp display site: http://www.eio.com/sage2.htm impressive! Might be just what we are looking for to run all sorts of avionics software (including moving map etc) Joe Hovel ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Re: Source for cheap displays
Date: Dec 07, 1999
Marlin, they are color, but I did not see any brightness data - yes I have: I just downloaded the spec sheets: it's 100 - 120 nt ('nits' I think - that's not very bright as far as I know, given that there are 500 and 1200 nt displays). I also just realized that I omitted to put the URL in my original message .... duh.... sorry.... it is: http://www.eio.com/colorlcd.htm Joe Response to message: From: Marlin Mixon <myshkin(at)worldnet.att.net> Subject: Re: Avionics-List: Source for cheap displays Joe Hovel wrote: > > > I just came across this page with lots of references and cheap sources for > displays - I imagine we require some cheap sources for early test and > demonstration units.... > Sounds good. Are any of them color? Do you know if any of the color displays are brighter than 110 Candellas/m2? Marlin Mixon ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: aircraft attributes/parameters
Date: Dec 07, 1999
Brian, All, Most if not all of these are included in "CDA101/12, Parameter Definitions" including format and units. We should start with CDA101/12. Most of our concerns have already been addressed by CDA101 which is a CAN Kingdom (HLP,real-time) architecture tailored for aircraft and marine use. I have written to David Purdy asking for latest updates and info. This group also hinted that software was available. This may be helpful. See http://www.kvaser.se/canking/cda101/index.htm and download the file. John -----Original Message----- From: Brian Lloyd [mailto:brian(at)lloyd.com] Sent: Monday, December 06, 1999 3:21 PM Subject: Avionics-List: aircraft attributes/parameters Dave and I went through this exercise a couple of years ago. I didn't hang on to my original message so I will try to recreate it here where it can live in the archives indefinitely.......... ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: aircraft attributes/parameters CDA101
Date: Dec 07, 1999
>Most if not all of these are included in "CDA101/12, Parameter >Definitions" including format and units. We should start with >CDA101/12... sounds liek a reasonable course of action... I have downloaded some of this documentation and given it a cursory review... it seems to be what we're looking for. It also provides another feature that we're looking for... interoperability and standardization. >This group also hinted that software was available. Downloadable from the specified web site. Some of it may be more helpful than others, particularly the Windows based CAN bus monitoring tools and such... sorta like a packet "sniffer" fo rthe CAN bus... lets us put a Windows machine on the bus to monitor and analyze our data and performance while testing the system. 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 to the rescue
Date: Dec 07, 1999
Brian, All, I'll start my comments with /// Subject: Re: Avionics-List: CAN Implementations >... do we want to use CAN 2.0A (11 bit identifier) or CAN 2.0B (29 bit identifier)? One of the things we have discovered in designing the Internet is that you should give yourself a lot more room than you think you need. 29 bits makes a lot more sense. /// I agree we should use CAN2.0B >This, of course, assumes that we would be serially numbering/identifying >each module. When we DO that, it means that we need to keep track, >somehow, of all the modules that we've installed so far. It also means >that the main CPU needs to know what every ID does. What we have is a >configuration issue. Dave and I have been tossing this back and forth for the last week in private email. My take on this "problem" is that configuration is a one-time issue, i.e. performed when a module or modules are installed on the buss, and therefore is not a big problem. /// All of the above issues are what the CAN Kingdom and CDA101 are for. CDA101 is an implementation of CAN Kingdom oriented to the monitoring and control of aerial and naval Unmanned Vehicles (UV's). CDA101 is a great starting point for us. CAN Kingdom is a High Level Protacal (HLP) for designing real-time networked systems. The CAN Kingdom HLP has a setup phase where it communicates with its nodes and organizes the operation of the network. We should be investigating how CAN Kingdom and CDA101 does this and not reinvent this stuff. CAN Kingdom3.01 and CDA101 specifications are all free from http://www.kvaser.com/canking/index.htm >There is another approach: Develop a numbering scheme using 29 bit >identifiers that does two things: 1) uniquely identifies each module (so >you don't get any id conflicts) by a serial number and 2) Encodes the >function of the module, i.e. code 210 might mean upper AOA pressure >sensor, left wing and code 221 might mean lower AOA pressure sensor, >right wing. By identifying the module correctly, it can be integrated >into the net work sort of like "plug and play." Actually, it isn't quite that easy since you might want a module to source more than one of a particular attribute from the same module. Engine parameters like CHT and EGT come to mind here. As much as one might hate it, this is where something like SNMP (simple network management protocol) experience comes in handy. (FYI, Dave Bridgham is one of the world-wide industry experts in network monitoring and managment, a skill that impinges directly on our project.) Dave and I have been using a shorthand that looks something like this: engine1.CHT.1 engine1.CHT.2 engine2.EGT.1 engine2.oilp Clearly we need to get a list of interesting attributes sooner rather than later so that we can decide if they are repeated (indexed). From this we can take a stab at how we want to partition up the 29 bits in attribute identifier. Box ID is certainly one of the fields we want but how many bits to allocate is not so clear. /// CAN Kingdom and CDA101 deals with all of these issues, See CDA101/12 Parameter Definitions. >2. The Mice and Men problem: as much as we plan, we still can't >anticipate all possible configurations that people would want to >experiment with in an aircraft. Right, so build in overkill. 29 bits is probably sufficient in that respect. 11 bits is, IMHO, woefully inadequate. /// Use CAN2.0B (29 bits) and use CAN Kingdom/CDA101 for flexible system reconfiguration. CAN Kingdom is designed to be modular, in that each module/node(ie: engine instruments module etc) can be designed without having to know how the system designer is going to use it. John ________________________________________________________________________________
Date: Dec 07, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Kingdom to the rescue
On Tue, 7 Dec 1999, Livingston John W Civ ASC/ENFD wrote: > > /// I agree we should use CAN2.0B > > /// All of the above issues are what the CAN Kingdom and CDA101 are for. > CDA101 is an implementation of CAN Kingdom oriented to the monitoring and > control of aerial and naval Unmanned Vehicles (UV's). CDA101 is a great > starting point for us. CAN Kingdom is a High Level Protacal (HLP) for > designing real-time networked systems. The CAN Kingdom HLP has a setup > phase where it communicates with its nodes and organizes the operation of > the network. We should be investigating how CAN Kingdom and CDA101 does > this and not reinvent this stuff. CAN Kingdom3.01 and CDA101 specifications > are all free from http://www.kvaser.com/canking/index.htm I am having trouble reading between the lines. Are you perhaps suggesting that we maybe ought to look at CAN Kingdom and CDA101 for guidance? Perhaps you could be more forceful and forward with your suggestions. ; ) Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN Kingdom to the rescue
Date: Dec 07, 1999
....I am having trouble reading between the lines. Are you perhaps suggesting that we maybe ought to look at CAN Kingdom and CDA101 for guidance? Perhaps you could be more forceful and forward with your suggestions. ; ) Brian Lloyd subtlety was always one of my strong traits. :-) John ________________________________________________________________________________
Date: Dec 08, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: CAN Module board
> >I'm interested in what you think about this board: 1) will it accept a >Motorola CAN chip? and 2) Can it be interfaced to the CAN bus? 3) Any >other solutions out there that are cheaper or less required >modifications out there? > >This kit board is a simple board that the Seattle Robotics Society sells >for $60. It uses the 68HC12 chip. The reason why I'm interested in a >board that has as much power as this one does because one of my personal >goals for the GCP is to build an engine monitor. The 68HC12 has eight >A/D input channels that get you most of the way there (I will probably >have to put two of these on the bus in order to monitor all the analog >inputs that I want to monitor). > >There's a circuit diagram and building instructions at: >http://www.nwlink.com/~kevinro/b32brd.pdf >Does anyone know if I could swap in a 68HC912BC32 Microcontroller (that >runs CAN 2.0B) in place of the 68HC912B32 (the MCU that comes with the >kit)? You can download all of the technical data on any Mot device from their website at http://mot-sps.com/products/ Some of the tech docs are HUGE and time consuming/risky downloads. I have cable modem and can cut big downloads to CD Rom. If anyone needs that service, e-mail me. >One question that came up earlier was: do we want to use CAN 2.0A (11 >bit identifier) or CAN 2.0B (29 bit identifier)? One respondent wanted >to defer that question to a CAN expert. Until we can chat with a CAN >expert, I have some ideas on the subject. 11 bits would give us, at the >most, 2048 different identifiers, whereas 29 bits would give us 529 >billion. >One of the things we have discovered in designing the Internet is that you >should give yourself a lot more room than you think you need. 29 bits >makes a lot more sense. You might want to take a peek at how ARINC 429 bus structures orchestrate party line communications with literally hundreds of potential sources and users of data. I've got contacts with folk who work in that arena at Raytheon Acft here in Wichita. They might be able to point me to some websites or reference some basic turorial documents that describe the architecture. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN Module board
Date: Dec 08, 1999
Bob, Nice to here from you. If anyone can help us on the pitfalls of instrumentation (analog and digital) and the vagueries of electricity in general, your the one. You said: ...You might want to take a peek at how ARINC 429 bus structures orchestrate party line communications with literally hundreds of potential sources and users of data. I've got contacts with folk who work in that arena at Raytheon Acft here in Wichita. They might be able to point me to some websites or reference some basic turorial documents that describe the architecture.... It so happens that Raytheon seems to be heavily involved with this new AGATE/NASA databus standard. I've been trying to find technical info on it, but have not been to successful. Perhaps one of your contacts could help. They claim it is low cost, failsafe, etc. It appears that the physical bus will be fiber-optic and the protocal will be some form of LonTalk. The problem is I can't find out anything about it. I have a hunch it won't be cheap or open. John ________________________________________________________________________________
Date: Dec 09, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: CAN Module board
> >Bob, > > Nice to here from you. If anyone can help us on the pitfalls of >instrumentation (analog and digital) and the vagueries of electricity in >general, your the one. You're very kind . . . I'll try. > > You said: > > ...You might want to take a peek at how ARINC 429 bus structures > orchestrate party line communications with literally hundreds > of potential sources and users of data. I've got contacts with > folk who work in that arena at Raytheon Acft here in Wichita. > They might be able to point me to some websites or reference some > basic turorial documents that describe the architecture.... > >It so happens that Raytheon seems to be heavily involved with this new >AGATE/NASA databus standard. weeelllllll . . . . sort of. The last word I had on AGATE bus structures was that it's dead . . . that could change in 30 seconds. > . . . I've been trying to find technical info on it, >but have not been to successful. Perhaps one of your contacts could help. Haven't been made privy to anything proposed in the past or being considered by any of the so-called "partners" except that bus structures being offered were to be held close to the chest by the offerors. I would have expected this of Allied Signal, et. als. but I was surprised that a little start-up operation was taking the same posture. >They claim it is low cost, failsafe, etc. It appears that the physical bus >will be fiber-optic and the protocal will be some form of LonTalk. The >problem is I can't find out anything about it. I have a hunch it won't be >cheap or open. I cannot disagree. Fiber is the latest buzz but does AGATE really, Really, REALLY justify it? What's the longest data run? 15 feet? What's the fastest necessary data rate? I'm betting 1 MBs is plenty. Why spend $millions$ to invent a new wheel when there's wheels avaialble off the shelf that meet the requirements? Aviation has a long history of shooting itself in the foot and AGATE is no exception. Revitalize GA? Gimme a break. The real leading edge of GA technology is in people's basements and garages. I'd use GA's history for guidance but not as an example of something to strive for or exceed in terms of sophistication. There's a sign over my desk with with a saying by a anomynous sage that says, "Sometimes, the best way to drive a nail is with a hammer." If you guys are interested in truly low cost technologies with adequate performance, you're more likely to find it on an 18-wheeler or a big piece of agricultural equipment. >John > > Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 09, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Module board
On Thu, 9 Dec 1999, Robert L. Nuckolls, III wrote: > > ...You might want to take a peek at how ARINC 429 bus structures > > > >It so happens that Raytheon seems to be heavily involved with this new > >AGATE/NASA databus standard. > > weeelllllll . . . . sort of. The last word I had on > AGATE bus structures was that it's dead . . . that could > change in 30 seconds. It appears they are doing something but it also appears that they are basically ignoring the most obvious source of datacomm experience: people doing commercial datacomm for process control. > ... except that bus structures being offered > were to be held close to the chest by the offerors. > I would have expected this of Allied Signal, et. als. > but I was surprised that a little start-up operation > was taking the same posture. How does the saying go, "those who ignore history are doomed to repeat it." If there is anything we have learned from the history of the Internet, open standards and free software promote growth. Companies in the past that have tried to hang onto their lead by keeping systems and protocols proprietary have invariably lost in the long run. > >They claim it is low cost, failsafe, etc. It appears that the physical bus > >will be fiber-optic and the protocal will be some form of LonTalk. The > >problem is I can't find out anything about it. I have a hunch it won't be > >cheap or open. > > I cannot disagree. Fiber is the latest buzz but does AGATE > really, Really, REALLY justify it? No. > What's the longest > data run? 15 feet? What's the fastest necessary data rate? > I'm betting 1 MBs is plenty. Why spend $millions$ to invent > a new wheel when there's wheels avaialble off the shelf > that meet the requirements? Until you get to really high data rates or long runs the real advantage of fiber is electrical isolation. When designing a cabling plant for a campus I always use fiber between buildings because fiber survives in buried conduit better than copper and it provides isolation since the grounds between buildings tend to be a different potential. Neither of these reasons impact GA. Oh, and one other thing, it is a heck of a job to make a multidrop fiber buss. > Aviation has a long history > of shooting itself in the foot and AGATE is no exception. > Revitalize GA? Gimme a break. The real leading edge of > GA technology is in people's basements and garages. That is what this group is all about. The big question is how to come up with something that is both simple and elegant that will foster experimentation and still be accepted by the establishment. Some of us here recall the IP vs. OSI war that went on the in '80s. The whole world was going to adopt the OSI networking standard and IP was going to fall by the wayside. I personally have been thrown out of a building by a client for suggesting that the Internet Protocol suite might meet their need for open data communications between their disparate systems. I suspect that same type of attitude is likely to exist in the aviation community. So the big question then is NOT how to build an elegant, simple cockpit avionics system; we know how to do that. The question is how to get the Powers That Be to even consider our work as useful. None of us are part of the aviation establishment and therefore our work is likely to be dismissed as being too amateur to have any merit in spite of the fact that we have some really top-notch data communications experts participating. > I'd > use GA's history for guidance but not as an example of > something to strive for or exceed in terms of sophistication. > There's a sign over my desk with with a saying by > a anomynous sage that says, "Sometimes, the best way > to drive a nail is with a hammer." The corolary to this is, "When all you have is a hammer, everything looks like a nail." ; ) > If you guys are interested in truly low cost technologies > with adequate performance, you're more likely to find it > on an 18-wheeler or a big piece of agricultural equipment. That is why we are looking at the CAN buss. CAN was developed to network sensors and control systems in automobiles. It seems to be pretty darned simple. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: AGATE databus vs CAN
Date: Dec 09, 1999
Bob, All, ... If you guys are interested in truly low cost technologies with adequate performance, you're more likely to find it on an 18-wheeler or a big piece of agricultural equipment. Bob . . . Well, most if not all of the auto and marine industry world wide is going with CAN. I can see no reason why we shouldn't either. So far we've identified: - CAN 2.0B serial comm protocal, basic comm services - CAN Kingdom High Level Protocal (HPL), Real Time Control (RTC) - NMEA 2000 marine use, HLP, RTC J1939 implementable in CK - CDA101 aerospace and marine use, HPL, RTC (CAN Kingdom) and a new player I found... - CAN Aerospace HPL for aerospace very simple, we may want to look at this more. see http://www.can-cia.de/NN3.htm and http://www.mstock.com/ John ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: CAN Aerospace
Date: Dec 09, 1999
>and a new player I found... > >- CAN Aerospace HPL for aerospace very simple, we may want to >look at this more. see http://www.can-cia.de/NN3.htm and >http://www.mstock.com/ Started reading their documentation. Thgis looks interesting, definitely a contender. 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 Aerospace
Date: Dec 09, 1999
Steve, All, Yeh, It might not be as flexible as CDA101/CAN Kingdom but it seems simpler. We could cut our teeth on it until we run into a wall. If that happens we should be smart enough by then to try something more complicated, if we need to. There may be some performance issues, but for what we need it may not matter at all. The pdf files hinted that C++ software may be available. The software availability and cost issues are what we have to sort out now. I definately don't want to spend a fortune on software development tools. I also don't want to attempt something this complex without a good Object oriented tool set. Lets see... - CAN microcontroller with multiple analog, frequency and digital IO - Many different analog sensor interfaces. - one or more SBCs with displays - C++ Software development environment for a PC - bus diagonstic hardware & software Lots of work to do, but we've got a start and we're getting the lay of the land. John ....Started reading their documentation. This looks interesting, definitely a contender.... Steve ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: CAN Aerospace
Date: Dec 09, 1999
I found the following document encouraging. I think we're on the right track using CAN. Here's an excerpt from ftp://ftp://www.mstock.com/pub/ (filename=CAN_FlightSim.pdf) CAN is used as cockpit interface network in three EUROCOPTER development simulators and the BO 105 Procedure Trainer. It has proven to be an excellent solution for complex true-to-life flight simulators due to a.) its object orientation, b.) the efficient error handling and c.) the flexibility which simply outperforms any other fieldbus for this application. In the meantime, the Grob STRATO 2C research aircraft has shown the way that CAN might go in aero-space: This high-altitude aircraft is equipped with a CAN-based engine control system which has been designed by the Industrieanlagen-Betriebsgesellschaft (IABG) in Germany. The STRATO 2C has already been tested in flight levels close to the stratosphere (60.000ft/ 18.000m) and demonstrated that CAN works without any problems in a harsh environment. CAN offers all the advantages of dedicated aerospace bus systems like MIL-STD 1553B or ARINC629 at a much lower cost and complexity level. Therefore, there is a good chance that we will see this network in flight critical applications like primary flight control sooner or later. Marlin ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CAN Aerospace
Date: Dec 09, 1999
Marlin, ...there is a good chance that we will see this network in flight critical applications like primary flight control sooner or later.... Marlin Later for me, thank you. I still prefer steel cable and tubing control systems. :-) John ________________________________________________________________________________
Date: Dec 09, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Aerospace
On Thu, 9 Dec 1999, Livingston John W Civ ASC/ENFD wrote: > > Marlin, > > ...there is a good chance that we will see this network in flight > critical applications like primary flight control sooner or later.... > > Marlin > > Later for me, thank you. I still prefer steel cable and tubing control > systems. :-) I think that autopilot communications is a very real possibility for this. In that case we are talking about flight control systems. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: CAN Aerospace
Date: Dec 09, 1999
At first glance, this seems to be a well-thought-out standard that we can easily adopt. I think this definitely deserves closer scrutiny. One thing that concerns me is that the specification calls for metric units. I wonder if we could find a bit flag somewhere in the datastream to indicate English units of measurement? (With the blessing of the specifications author, of course.) I'll look at this over the weekend some more. It certainly looks promising! -Matt ________________________________________________________________________________
Date: Dec 09, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Aerospace
> >At first glance, this seems to be a well-thought-out standard that we can >easily adopt. I think this definitely deserves closer scrutiny. > >One thing that concerns me is that the specification calls for metric units. >I wonder if we could find a bit flag somewhere in the datastream to indicate >English units of measurement? (With the blessing of the specifications >author, of course.) Why bother? One of the tricks we use in internet protocols is to adopt an intermediate standard on the wire that may differ from what is presented to the user. In this case it is just fine to use metric units on the wire. The operator just selects English units in his/her display and the display does the conversion. Frankly, I like the idea of sticking with a single system of units on the wire and Metric units appeals to me from the point of view of doing calculations. If you want my opinion, stick with MKS and let's move on. 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: CAN Aerospace
Date: Dec 10, 1999
Looking at the necsl_um.pdf document at ftp://ftp://www.mstock.com/pub/ My only question is "Jeez, are we allowed to see this?" Even if we can't duplicate it for proprietary reasons, it answers a lot of hardware questions. Marlin Mixon ________________________________________________________________________________
Date: Dec 09, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: CAN Aerospace
> >Marlin, > >...there is a good chance that we will see this network in flight >critical applications like primary flight control sooner or later.... > >Marlin > >Later for me, thank you. I still prefer steel cable and tubing control >systems. :-) We're about to demonstrate GPS guided auto-land in the 'agate' Bonanza. This is a fly-by-wire airplane with really fat servos capable of doing anything a pilot would need to do to fly the airplane with hand/foot controls. I keep hearing "data bus" and "fly by wire" spoken in the same sentence . . . but if one did EVERYTHING by serial data bus except flight controls, I doubt that it would add 1 pound of wire to a small airplane. Data bussing critical, high repetition rate data in with more mundane things like latitude and oil pressure doesn't make much sense to me. Flight control systems would also have to add complexity in terms of serial bus transceivers just to accomodate doing your fly-by-wire on the same bus. Might make sense in a B767 but don't see any benefits in a light plane. There are other relatively simple tasks like closing a switch to turn on nav lights, vent blowers, etc . . . don't see any economies in doing these things via the bus either. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 09, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: AGATE databus vs CAN
>Well, most if not all of the auto and marine industry world wide is going >with CAN. I can see no reason why we shouldn't either. So far we've >identified: > > - CAN 2.0B serial comm protocal, basic comm services > - CAN Kingdom High Level Protocal (HPL), Real Time Control (RTC) > - NMEA 2000 marine use, HLP, RTC J1939 implementable in CK > - CDA101 aerospace and marine use, HPL, RTC (CAN >Kingdom) > > and a new player I found... > > - CAN Aerospace HPL for aerospace very simple, we may want to look >at this more. see >http://www.can-cia.de/NN3.htm and > http://www.mstock.com/ >John Neat stuff. Got a peek at it a few minutes ago. I've be forwarding parts of these conversations to some of my fellow perpetrators out at Raytheon. Hope you guys don't mind being spied on . . . nothing would tickle me more than to see the "amateurs" get it done before government does. Come to think of it, EVERYTHING done for the first time is done by an amateur so perhaps we should call ourselves somthing more distictive to keep from being confused with those "other" guys . . . Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 09, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: CAN Module board
>That is what this group is all about. The big question is how to come up >with something that is both simple and elegant that will foster >experimentation and still be accepted by the establishment. Some of us >here recall the IP vs. OSI war that went on the in '80s. The whole world >was going to adopt the OSI networking standard and IP was going to fall by >the wayside. I personally have been thrown out of a building by a client >for suggesting that the Internet Protocol suite might meet their need for >open data communications between their disparate systems. I suspect that >same type of attitude is likely to exist in the aviation community. > >So the big question then is NOT how to build an elegant, simple cockpit >avionics system; we know how to do that. The question is how to get the >Powers That Be to even consider our work as useful. None of us are part >of the aviation establishment and therefore our work is likely to be >dismissed as being too amateur to have any merit in spite of the fact >that we have some really top-notch data communications experts >participating. Get it working, let's sell 'em to the homebuilders (and perhaps into the Owner Maintained aircraft in Canada - if that program ever gets off the ground) . . . there were about 10,000 Lorans flying before the FAA got around to admitting that they were a pretty good thing. > >> I'd >> use GA's history for guidance but not as an example of >> something to strive for or exceed in terms of sophistication. >> There's a sign over my desk with with a saying by >> a anomynous sage that says, "Sometimes, the best way >> to drive a nail is with a hammer." > >The corolary to this is, "When all you have is a hammer, everything looks >like a nail." ; ) Very good! >> If you guys are interested in truly low cost technologies >> with adequate performance, you're more likely to find it >> on an 18-wheeler or a big piece of agricultural equipment. > >That is why we are looking at the CAN buss. CAN was developed to network >sensors and control systems in automobiles. It seems to be pretty darned >simple. Go for it! I think it's a winner . . . Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 10, 1999
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: CAN Module board
Brian Lloyd wrote: > > What's the longest > > data run? 15 feet? What's the fastest necessary data rate? > > I'm betting 1 MBs is plenty. What about my digital intercom? And my digital camera? But seriously, you're right. I was involved on the perphery of a security/access control project which required digital camera images and intercom messages to go over the same wires as the door unit access control comms (and the same wires to be used for power supply... i.e. just two wires to any unit). Those gimmicky requirements pushed up the complexity and cost of the project *enormously*. Can you say 'didn't meet deadline'? How about 'budget overrun'? Knew you could! Frank. ________________________________________________________________________________
Date: Dec 09, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Aerospace
> > I keep hearing "data bus" and "fly by wire" spoken in > the same sentence . . . but if one did EVERYTHING by > serial data bus except flight controls, I doubt that it > would add 1 pound of wire to a small airplane. Data > bussing critical, high repetition rate data in with > more mundane things like latitude and oil pressure doesn't > make much sense to me. To paraphrase the TV ad, "bits is bits." It doesn't matter whether the bits are oil pressure data or elevator position commands. We have been pushing critical management and control data over the internet for a long time now. People have recently started to segregate the traffic for two reasons: 1. traffic levels have reached a point that the latency for time-critical data/commands has started to increase; 2. there are nasty people out there who would like to break the net if they could get into the control systems. Neither of these are a problem in an aircraft. We know the data rates for all the components so we can bound the latency problem. We also know that there are no hostile components so that is a non-issue. > Flight control systems would also > have to add complexity in terms of serial bus transceivers > just to accomodate doing your fly-by-wire on the same > bus. Might make sense in a B767 but don't see any > benefits in a light plane. Well, so long as the buss is fail-safe, i.e. no failure mode of a single component can cause the buss to fail to carry the information for all the other devices, there is no reason not to put all your data on the buss. I would rather have two redundant busses each capable of carrying all the information than to have a sensor buss separate from the flight control buss. The complexity is the same in both cases but you have more redundancy with the former. At a couple of bucks, transceivers don't cost very much. Microprocessors aren't much more. You know, it is very likely that the connectors and enclosure will cost more than all the electronics they carry. I can put a whole bunch of microprocessors in an airplane for what most people pay for circuit breakers. You know, it may actually be as cheap to build on/off modules as it would to install a switch, a breaker (I know, fuses are cheaper and better), and some #18 tefzel wire. The economies are shifting in favor of silicon. > There are other relatively > simple tasks like closing a switch to turn on nav lights, > vent blowers, etc . . . don't see any economies in doing > these things via the bus either. Maybe. You might have a solid-state relay box that talks to your buss and performs the function of the switch panel. This whole thing is like the internet in miniture. Once you have ubiquitous, high-speed, reliable data communications you start thinking about doing things that you never considered before. If we can come up with low-cost fly-by-wire systems that are as reliable as torque tubes and steel cables, why not switch to FBW. (Have you ever asked yourself, just how reliable are the traditional mechanical systems, anyway?) Hey, we have the technology. We start with sensor boxes and move to avionics and FMS. FADEC will be not-so-far behind. FBW is not long after that. But it all starts with reliable, universal communications. With that in place, anyone can dream up a new feature and build a box that plugs into the buss to take advantage of all the information that is already there. Yeah, we gotta build this. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 09, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Module board
> >Brian Lloyd wrote: >> > What's the longest >> > data run? 15 feet? What's the fastest necessary data rate? >> > I'm betting 1 MBs is plenty. > >What about my digital intercom? And my digital camera? Dave and I planned to put all the audio on the buss. The current crop of codecs used in PCS phones operate at bit rates under 10 kbps. One very nice codec in use is variable rate and switches between 1 Kbps and 10 Kbps depending on the complexity of the audio. With a 1Mbps buss you can put an awful lot of communications quality audio on there without impacting your critical stuff. MPEG-3 (MP3) audio delivers two channels of almost CD quality sound at 128Kbps. No, audio isn't going to break the bank. And your camera? No problem there either unless you are trying to do full motion video. A still camera image is on the order of 100KB. One image per second would stress your 1Mbps buss but do you take pictures that rapidly? Remember, we are going to have a way to guarantee bandwidth and latency for critical functions. >But seriously, you're right. > >I was involved on the perphery of a security/access control project >which required digital camera images and intercom messages to go over >the same wires as the door unit access control comms (and the same wires >to be used for power supply... i.e. just two wires to any unit). Those >gimmicky requirements pushed up the complexity and cost of the project >*enormously*. Can you say 'didn't meet deadline'? How about 'budget >overrun'? Knew you could! That is because they didn't think the problem out ahead of time or because the requirements changed after the fact, usually after the initial design is done and noone had the cojones to say, "well, we should throw it out and start over with a clean sheet." The data transmission problem looks like it is already solved. The messaging looks like it might be solved too. With CAN we have close to 1Mbps of capacity. That is a LOT of capacity considering that most of what is happening in the cockpit today is done at data rates measured in hundreds of bits per second, not millions. For example, the new S-Tec GPS steering system is giving heavy-iron quality autopilot performance and the data rate is 4800 bps (I think that is right -- 4800 bps is the default data rate for the NMEA interface used by most GPS receivers). Maybe it is 9600 bps. You can do 100 x 9600 bps on a single 1Mbps buss with some room left over. (I know, we have overhead and dead times, etc., but the order of magnitude is correct.) Now let's get something built. 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: Glass Cockpit documentation
Date: Dec 10, 1999
I have reworked the definitions and reference data. I have moved all of the definitions, links, etc., over to a separate page, and added hyperlinks within the body of the text to the definitions... This primarily affects the architecture page, as that is what we have been working on the most lately... There are quite a few shortcomings with my definitions, perhaps some important links I missed. Please email me direct (off list) with any definitions, links, etc., that should be added or corrected (in addition to any other comments you may have). If there are any places where terms should be linked to their definitions, let me know about those as well. I will get on the changes as soon as possible. Thanks, 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: Re: CAN Aerospace (units of measure)
Date: Dec 10, 1999
>Why bother? One of the tricks we use in internet protocols is to >adopt an intermediate standard on the wire that may differ from >what is presented to the user. In this case it is just fine to use >metric units on the wire. The operator just selects English units >in his/her display and the display does the conversion. Yeah, we sorta jumped ahead of ourselves here, but that's exactly right... heck, we don't know that all of our "users" will want/need English units... let the rendering software decide on that and convert as needed. >Frankly, I like the idea of sticking with a single system of units >on the wire and Metric units appeals to me from the point of view >of doing calculations. If you want my opinion, stick with MKS >and let's move on. That's what I used for my first year Physics, and it worked well... changed schools, and the second year the other school used English units (in science!!!!)... it was like the dark ages... I felt like we were measuring mass with stones and distance with our "feet" (on the ends of our legs). So internally using the MKS (meters, kilograms, seconds) sounds *FINE* to me. Next... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 10, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: CAN Aerospace (units of measure)
> >>Why bother? One of the tricks we use in internet protocols is to >>adopt an intermediate standard on the wire that may differ from >>what is presented to the user. In this case it is just fine to use >>metric units on the wire. The operator just selects English units >>in his/her display and the display does the conversion. > >Yeah, we sorta jumped ahead of ourselves here, but that's exactly right... >heck, we don't know that all of our "users" will want/need English >units... let the rendering software decide on that and convert as needed. Existing protocols like ARINC429 assign fixed lables and data formating so that anyone can generate or decode that data item. Unless there are strong technical reasons for changing formats, you might want to adopt the ARINC429 suite of messages and add your own unique packets as needs be. This would save you a lot of time setting up a new system. It MIGHT encourage some existing vendor of high-dollar ARINC compatable stuff to service your market if all they need to do is change their bus interface. Clumsy as it may be, there's a LOT of 429 stuff out there. A new system might enjoy faster acceptance if it had familar features. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Java CAN simulator
Date: Dec 10, 1999
Java idea summary: Integrate a software CAN simulator to Dave B's Java Flightsim allowing us to verify that CAN and JAVA are suitably fast enough when linked together. I was initially sending this to Dave B. (who is in offline in California for a couple more days), but I thought I'd also mention it to the group. Dave wrote a Java Flightsim package and some members of the group have taken a look at it: http://www.froghouse.org/~dab/inst.tar.gz -or- http://www.froghouse.org/~dab/inst.zip To run say "java Simulator". I ran it and flew it around a little and was impressed with it. It demonstrates that a Java display can run fast enough to be suitable as a display system. So here's the idea: we could modify the Java Classes by writing a new class that interposes itself between the Dave's on-screen joystick, and Dave's instrument panel. This new class would read the flight simulator model data as it changes in real time and encodes it into CAN messages just as if a bunch of sensors were encoding real-life data. Once the basic functionality of this is working, we can then impose a speed limit of (1 Mbit/s) on the data encoding process. Although the CAN simulator would not be used in the aircraft, it would serve as a stepping stone used during development. This computer modeling exercise will let us verify that CAN is fast enough, and that the Java display is sufficiently powerful enough. Also, it will let us start to develop the software that will be used for display because we'll have a source of CAN data (albeit an artificial one). Finally, it will help us in fine tuning module transmission cycle rates. As far as Java goes, I especially like the fact that we can all work with it because Java Virtual Machines (JVMs) exist for most Hardware/OS platforms.) Also, some of you probably aren't aware that Java can run as a stand-alone application meaning that you wouldn't have to run a browser on your display unit, just the JVM and the display application. We're not talking about scrolling text Applets here! Marlin Mixon ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Data Bus
Date: Dec 10, 1999
All right, I admit it. I haven't been able to keep up. As I understand things, most of us are in agreement that the CAN bus looks like a good choice for data communications at the lower levels, but we're debating two or three standards at the higher levels. Is this about where we are? If so, I'd move that we plan on CAN if there are no objections and move on to deciding on a high level protocol. Geez, folks, if we keep up this pace, sooner or later we're going to have to BUILD something! -Matt ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Java CAN simulator
Date: Dec 10, 1999
Ummm.... embarassing question here.... How do I run it? I've downloaded the files to my drive (Windows NT running IE5). Do I need to create a skeleton web page that instantiates the simulator? -Matt -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Marlin Mixon Sent: Friday, December 10, 1999 1:29 PM Subject: Avionics-List: Java CAN simulator Java idea summary: Integrate a software CAN simulator to Dave B's Java Flightsim allowing us to verify that CAN and JAVA are suitably fast enough when linked together. I was initially sending this to Dave B. (who is in offline in California for a couple more days), but I thought I'd also mention it to the group. Dave wrote a Java Flightsim package and some members of the group have taken a look at it: http://www.froghouse.org/~dab/inst.tar.gz -or- http://www.froghouse.org/~dab/inst.zip To run say "java Simulator". ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Data Bus
Date: Dec 10, 1999
>All right, I admit it. I haven't been able to keep up. **YOU** can't keep up? Try documenting the thing (around your full-time job!) >As I understand things, most of us are in agreement that the CAN >bus looks like a good choice for data communications at the lower >levels, but we're debating two or three standards at the higher levels. > >Is this about where we are? Yes. >If so, I'd move that we plan on CAN if there are no objections and move >on to deciding on a high level protocol. I second the motion... Actually, I think that you're seconding MY motion that was made last week some time... :-) but who's counting... 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: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Java CAN simulator
Date: Dec 10, 1999
>From: "Matthew Mucker" <mmucker(at)airmail.net> > > >Ummm.... embarassing question here.... > >How do I run it? > >I've downloaded the files to my drive (Windows NT running IE5). Do I need >to create a skeleton web page that instantiates the simulator? No, first of all, forget everything you know about Java! It's not an applet, so IE5, even though it has Java capabilities, won't do a bit of good. Instead, go to java.sun.com and download their JDK 1.1.x. JDK 1.2.x will work too, but I had some display problems with it where the flightsim is concerned. (JDK 1.1.7 for win32 is 8.4 MB). Install it, then from a command line prompt (DOS window in win32) type "java Simulator" which IS CASE SENSITIVE. Marlin ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Data Bus
Date: Dec 10, 1999
I have a question for the group that would have big impact on the data bus standards chosen. Looking at the Can Aerospace specifications, all data on the bus is transmitted in real-world units of measurement. (Pascals, meters, etc.) This is great for listening devices, since no conversion is needed to get a usable piece of data. However, such an implementaion requires the individual data collection units on the bus to convert from their sensors' native units (volts, for instance, in a pressure-to-voltage transducer) into real-world units. This kinda scares me. This would require floating point math to be done at the sensors. Since our sensors would probably use small microcontrollers, we're talking quite a bit of debugging and coding time. My original thought when I started this whole thread was that the sensors would send the raw data back to the listeners (probably a Pentium-class machine), and that that machine would do the conversion. Call me crazy, but I'd rather do floating point math in a full-blown development environment on a PC than in assembly on a micro. (And my personal prejudice is that if you're programming on a micro, assembly is the only way to go!) So, the decision on whether the bus will contain real-world data or raw sensor data boils down to where we do the conversion from raw data to real-world data: do we do it at the data collection unit, or at the listening (display) unit? As I indicated above, there are advantages in each case. I've never done any floating-point work on a micro, so just that in itself scares me. I might find out that it's not as bad as I fear. On the other hand, it might be worse than I fear! So, where do we want to do this data conversion? Do we want raw data on the bus, or real-world data on the bus? -Matt ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: CDA101/CAN Kingdom update
Date: Dec 10, 1999
Gentlemen, (its just a figure of speech) I wrote to David Purdy who is deep into CDA101 activities. This is his responce: > -----Original Message----- > From: Livingston John W Civ ASC/ENFD [SMTP:John.Livingston(at)wpafb.af.mil] > Sent: Tuesday, December 07, 1999 8:08 AM > To: 'David Purdy' > Subject: CDA101 Status > > David Purdy, > > I'm part of an informal group working on Glass Cockpit architecture for > Sport aviation. We've been studying the CAN bus and CAN Kingdom as a > candidate architecture for this effort. Your offices work with CDA101 has > been helpful, and I was wondering what the current status is? Is there a > web sight (other than kvaser) where I can find the latest updates. > > Also, do you have any thoughts on the AGATE/NASA databus > (Echelon/Raytheon) effort. How will this effect CDA101? > > John W Livingston > > >David Purdy's responce: > >We are still working on getting our web site approved. We (DoD) got real >touchy about firewalls during this last year. We do offer a CD with a lot >of stuff (the latest greatest) and will be offering a another class early >next year with space available free attendance to interested parties. > >While I am not intimately familiar with the AGATE/NASA initiative our look >at echelon said that it was not geared toward real time control loops. It >does appear to work very well at moving switch data and non-time critical >sensor data. I think it would make an excellent home network standard. > >CAN is very good at closing control loops but is limited to 1 MBit. If you >are moving large amounts of plot data (i.e. video, radar) I would consider a >higher throughput system. Also, CAN has limited small packets. Again, >excellent for control data, not so great for streaming files. > >That said, we like CAN and the CAN Kingdom approach to plug and play >architectures and it is in my opinion, the best there is for CAN. We have >been looking at extending the approach to other media, for example ethernet. > >Our present work is centered around implementation inside to aerial >vehicles, the BQM-74 from Northrop-Grumman and the MQM-107 built by Tracor >with a design package owned by the Army. These vehicles are stepping >stones, that is, the entire avionics is not distributed on a bus. We do >have a remote control boat which is completed distributed and it is entering >production. > >If you have any more question please free feel to contact me again... > >David Purdy CDA101/CAN Kingdom still looks very good to me. A system based on CAN Aerospace will not have the same level of modularity and flexibility. The best I can tell, with my limited knowledge to date, is that CAN Aerospace modules predetermine the priorities for various messages based on preconceived notions of their importance to the system. CAN Kingdom modules would make no such decisions but allows the system designer(engineer) to do this based on his system's requirements. CAN Kingdom message priorities are set(following the designer's instructions) during the system setup mode(when the system is turned on). This makes the modules and thier messages alittle more complex but way more flexible. It also puts the fewest constraints on the system designer; Something we will really need. Also I read on the web where a concept car was using 2 different buses. One for systems data another optimized for audio and video. John ________________________________________________________________________________
From: "Sten Svensson" <sten(at)stonab.se>
Subject: Degauss
Date: Dec 10, 1999
Anyone know where to find information how to remove magnetism in steel cage fuselage, by running high current through the frame with battery and jumper cables? Sten S Sweden ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Data Bus
Date: Dec 10, 1999
Matt, My responces begin with /// -----Original Message----- From: Matthew Mucker [mailto:mmucker(at)airmail.net] Sent: Friday, December 10, 1999 4:04 PM Subject: RE: Avionics-List: Data Bus I have a question for the group that would have big impact on the data bus standards chosen. Looking at the Can Aerospace specifications, all data on the bus is transmitted in real-world units of measurement. (Pascals, meters, etc.) This is great for listening devices, since no conversion is needed to get a usable piece of data. However, such an implementaion requires the individual data collection units on the bus to convert from their sensors' native units (volts, for instance, in a pressure-to-voltage transducer) into real-world units. This kinda scares me. This would require floating point math to be done at the sensors. Since our sensors would probably use small microcontrollers, we're talking quite a bit of debugging and coding time. My original thought when I started this whole thread was that the sensors would send the raw data back to the listeners (probably a Pentium-class machine), and that that machine would do the conversion. Call me crazy, but I'd rather do floating point math in a full-blown development environment on a PC than in assembly on a micro. (And my personal prejudice is that if you're programming on a micro, assembly is the only way to go!) ///We are talking about simple floating point equations. I personally prefer code I can easily read, so I would much rather program in C/C++, Pascal, FORTRAN, JAVA etc. I have seen software some very low price) for microcontollers in Pascal and JAVA and I know it is available in C. Very small ram requirements. So, the decision on whether the bus will contain real-world data or raw sensor data boils down to where we do the conversion from raw data to real-world data: do we do it at the data collection unit, or at the listening (display) unit? ///The data module must communicate messages of various types to the CAN bus. In a CAN Kingdom, for instance some of these identify it and its services to the Main computer(King) at start up. My point is we will be doing small but none trivial programming for the microcontollers in each of our different data modules to support CAN and our HLP. We want to be doing this in a readable, documentable way using a good language. Lets say C and C++. Not my first choice but its OK. As I indicated above, there are advantages in each case. I've never done any floating-point work on a micro, so just that in itself scares me. I might find out that it's not as bad as I fear. On the other hand, it might be worse than I fear! ///Take what I say with a grain of salt. I haven't done any programing with a microcontroller, but I've done some assembler coding and I know I don't like that. I never could easily read what I wrote 2 weeks after I wrote it. It's hard enough to write supportable,documented,easy to read code in a high level language. So, where do we want to do this data conversion? Do we want raw data on the bus, or real-world data on the bus? ///At the risk of being vague and misunderstood, I say we bite the bullet, and make these little modules as smart as we need them to be. Real-world data on the bus. High level language coding. Take that you bit head! :-) John ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: Degauss
Date: Dec 10, 1999
Sten, This is just hear-say, since I haven't done it, but plan to. I think you need AC current. I was told to insulate your airframe and just hook it up in series with a light bulb on an AC house line. Beeeee verrrry careful. John -----Original Message----- From: Sten Svensson [mailto:sten(at)stonab.se] Sent: Friday, December 10, 1999 4:35 PM Subject: Avionics-List: Degauss Anyone know where to find information how to remove magnetism in steel cage fuselage, by running high current through the frame with battery and jumper cables? Sten S Sweden ________________________________________________________________________________
Date: Dec 10, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Data Bus
On Fri, 10 Dec 1999, Matthew Mucker wrote: > However, such an implementaion requires the individual data collection units > on the bus to convert from their sensors' native units (volts, for instance, > in a pressure-to-voltage transducer) into real-world units. This kinda > scares me. This would require floating point math to be done at the > sensors. Since our sensors would probably use small microcontrollers, we're > talking quite a bit of debugging and coding time. My original thought when > I started this whole thread was that the sensors would send the raw data > back to the listeners (probably a Pentium-class machine), and that that > machine would do the conversion. There are several ways to do the math without having to do floating point. Remember, the data as it comes in is integer data in the form of an 8- to 12-bit signed/unsigned raw value. Yes you have to change the slope and intercept points to match the transducers you are using but you can do the floating point multiply as a fraction. For instance, if I want to use a scaling factor of 1.353, I can instead multiply by 23 and then divide by 17 (23/17 = 1.3529). Now I am doing integer arithmetic again. Not a big problem. > Call me crazy, but I'd rather do floating point math in a full-blown > development environment on a PC than in assembly on a micro. (And my > personal prejudice is that if you're programming on a micro, assembly is the > only way to go!) Maybe. You can do a lot with C and it is pretty darned efficient. Memory is not the problem it used to be. > So, the decision on whether the bus will contain real-world data or raw > sensor data boils down to where we do the conversion from raw data to > real-world data: do we do it at the data collection unit, or at the > listening (display) unit? If you are trying to do a standard, you want to standardize on the messages on the wire. If you send raw data you have to have a way to describe that data so that all devices will understand it. Do you plan to broadcast the conversion factors (slope/intercept for most transducers) or do you plan to hand enter them in every box that decides it wants to use that data? If you use standard units on the wire, all devices will be able to immediately use the information when they receive it. > As I indicated above, there are advantages in each case. I've never done > any floating-point work on a micro, so just that in itself scares me. I > might find out that it's not as bad as I fear. On the other hand, it might > be worse than I fear! Fractions are your friend. Use them. > So, where do we want to do this data conversion? Do we want raw data on the > bus, or real-world data on the bus? No ifs, ands, or buts about it, I want real world data on the buss. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 10, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Degauss
On Fri, 10 Dec 1999, Sten Svensson wrote: > > Anyone know where to find information how to remove magnetism in steel > cage fuselage, by running high current through the frame with battery > and jumper cables? No, that will actually magnetize the fuse even more. I have seen people demagnetize a steel tubing fuse by wrapping it with wire forming a solenoid (metal fuse inside a coil of wire) and then connect the wire to a variable autotransformer (a Variac). You turn up the voltage until the coil of wire is pulling as much current as the Variac can handle and let it sit for awhile. Then you slowly turn down the voltage so that the alternating magnetic field goes away slowly. When you are done your fuse should be demagnetized. If not, repeat the process until the permanent field is gone. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 10, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Java CAN simulator
On Fri, 10 Dec 1999, Matthew Mucker wrote: > > Ummm.... embarassing question here.... > > How do I run it? > > I've downloaded the files to my drive (Windows NT running IE5). Do I need > to create a skeleton web page that instantiates the simulator? You need a Java run-time environment (JRE). You don't need to use your browser at all. Go get the JRE from Javasoft.com. Brian Lloyd brian(at)lloyd.com 530.676.6513 ________________________________________________________________________________
Date: Dec 10, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Java CAN simulator
On Fri, 10 Dec 1999, Brian Lloyd wrote: > You need a Java run-time environment (JRE). You don't need to use your > browser at all. Go get the JRE from Javasoft.com. Actually that is java.sun.com. Sorry. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Data Bus
Date: Dec 10, 1999
> Call me crazy, but I'd rather do floating point math in a full-blown > development environment on a PC than in assembly on a micro. (And my > personal prejudice is that if you're programming on a micro, assembly is the > only way to go!) Maybe. You can do a lot with C and it is pretty darned efficient. Memory is not the problem it used to be. Yeah, but that would require me to learn C! :-P I don't disagree with you, and have to admit that real-world data on the bus makes a heckuva lot of sense. I just wanted to throw the idea out there. -Matt ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: I'm back..........
Date: Dec 10, 1999
Hi again, I've been out of the loop here for a few weeks. I didn't intend to abandon you guys. Been busy with other stuff. I expect that will continue for a while. I don't think I've actually lost any messages, though, and I've just been catching up with reading them. I will now attempt to redeem myself with another of my long winded missives. One of the other things I've been doing has been looking at the CAN bus for an unrelated application. The more I look the better I like it. Apparently there is a consensus forming here that it fits this application also. I'll add my vote to that. I would stay far away from the LON bus, BTW. What I'm referring to is just the CAN spec itself, which covers only the physical and link layers (roughly). I'm less sure about the upper protocol layers, but the CAN Kingdom looks about as good as any. There is a CAN mail list, BTW. To subscribe send mail to <majordomo@vector-informatik.de> with the following in the body of your message: subscribe canlist -------------------------------- Here are a few misc. links I've collected: Bosch CAN Homepage (THE CAN spec.) http://www.bosch.de/k8/can/ Chips: CAN - AVAILABLE DEVICES http://www.omegas.co.uk/CAN/devices.htm Philips http://www-eu2.semiconductors.philips.com/can/ Infineon http://www.infineon.com/us/micro/can/content.html Fujitsu http://www.fujitsu-fme.com/products/micro/can/04.html Some board level stuff: http://www.hmcomp.demon.co.uk/canbus.htm http://www.hitex-automation.com/ehican.htm http://www.dipinc.com/products/pd.html ---------------------------------- A few random thoughts re bus data semantics and the design of the "sensor boxes" (we need a better name): I think airspeed works well as an example. Do we want to display indicated airspeed in knots or true airspeed in mph, or...? I don't know, and I sure don't want our "sensor boxes" to have to care. At the other end of the chain, what's really in the "sensor box" is a pair (at least) of pressure sensors, a few opamps, an analog mux, an A/D converter, and a processor. The pitot and static ports are plumbed to the pressure sensors, which, in turn, output a voltage that is, while proportional to pressure, otherwise quite arbitrary. The A/D converter then converts that voltage to a binary number that is even more arbitrary. (It's not even in volts, it's just a ratio). The processor then does a little digital filtering on these numbers to get rid of noise. The result is these two numbers that are proportional to pitot and static pressure but otherwise meaningless. As if that wasn't bad enough, they may not even be linearly proportional to pressure. We may need to do a little curve fitting. So, do we just ship these raw numbers out onto the bus and let the receiver(s) do the math? How would they know what conversion equation to use? I think you get my point, no raw data on the bus. A somewhat fuzzier issue, I think, is do we send two pressures (in psi, kPa, or whatever) or one indicated airspeed? Sending the two pressures seems cleaner to me, but I'm open. Considering the way the bus design is going, I don't think we're going to get very far with a real low end (i.e. PIC, 8051, etc.) "sensor box" processor. It could be done, I'm think, but I fear the effort would be a little too painful. There are C compilers available for these things, but the chip architecture forces them to generate very inefficient code. That, combined with the limited memory available, limits what can be done in C to fairly trivial projects. (Don't even think about C++, Java, etc.). I have used these chips (and Z80's, 8085's, and even older things) to do some fairly tricky stuff, but that has always been with very tight assembly code. I personally don't aspire to do any more of that "hand polishing each bit" sort of coding. (And I'm actually pretty good at it, if I say so myself). Trying to do that sort of thing in the context of a geographically diffuse group project would be a recipe for frustration. It will do us no good to have a real cheap box if the firmware is never done. At the other end of the scale, I doubt these "sensor boxes" can be built with off the shelf, board level products and remain cost effective. I don't think anyone sells a board that you can hook up to a bunch of thermocouples, pressure sensors, etc. and to the CAN bus, and program in C. It wouldn't be that hard a thing to design but there isn't much of a market for it. I fear we would end up having to buy a stack of boards, each of which contained stuff we don't need, and interface them to each other. This would still be a fairly large engineering job, and we would end up with an overly expensive box. Yeah, I know, you're waiting for the third option. There are some relatively new 16 bit microcontroller chips that seem to be a pretty good fit. I've been looking at the Infineon C167 and the Fujitsu 905xx series. Their architectures were designed with compilers in mind and they have larger address spaces and pointers and more on chip memory. They seem to be intended for the automotive market so they have on chip A/D, CAN, etc. So far though, all I know is what I read in the data sheets, and I'm not sure when I'll have time to go further. I'll keep you posted. Later, Jeff ________________________________________________________________________________
From: "Sten Svensson" <sten(at)stonab.se>
Subject: Degauss
Date: Dec 11, 1999
Thanks! I need to get in touch with theese people (either method). The fuselage on my Pete Jones 450 Stearman is really badly magnetized, making it practically impossible to compensate the compass deviation. It has the battery in the rear, with the fuselage acting as minus conductor = high current running through the steel frame when the starter engages. Ones I get the frame degaussed I figure I need to run a separate heavy gauge ground cable from the battery to the engine? Sten > No, that will actually magnetize the fuse even more. I have seen people > demagnetize a steel tubing fuse by wrapping it with wire forming a > solenoid (metal fuse inside a coil of wire) and then connect the wire to a > variable autotransformer (a Variac). You turn up the voltage until the > coil of wire is pulling as much current as the Variac can handle and let > it sit for awhile. Then you slowly turn down the voltage so that the > alternating magnetic field goes away slowly. When you are done your fuse > should be demagnetized. If not, repeat the process until the permanent > field is gone. > > Brian Lloyd > Sten, > > This is just hear-say, since I haven't done it, but plan to. > > I think you need AC current. I was told to insulate your airframe and > just hook it up in series with a light bulb on an AC house line. Beeeee > verrrry careful. > > John > Anyone know where to find information how to remove magnetism in steel cage > fuselage, by running high current through the frame with battery and jumper > cables? > > Sten S > Sweden ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: Data Module formatting...
Date: Dec 11, 1999
-----Original Message----- From: Jeff Barlow <barlow(at)thegrid.net> Date: Friday, December 10, 1999 11:36 PM Subject: Avionics-List: I'm back.......... > >...A few random thoughts re bus data semantics and the design of the "sensor >boxes" (we need a better name): > >I think airspeed works well as an example. Do we want to display indicated >airspeed in knots or true airspeed in mph, or...? I don't know, and I sure >don't want our "sensor boxes" to have to care. > >At the other end of the chain, what's really in the "sensor box" is a pair >(at least) of pressure sensors, a few opamps, an analog mux, an A/D >converter, and a processor. The pitot and static ports are plumbed to the >pressure sensors, which, in turn, output a voltage that is, while >proportional to pressure, otherwise quite arbitrary. The A/D converter then >converts that voltage to a binary number that is even more arbitrary. (It's >not even in volts, it's just a ratio). The processor then does a little >digital filtering on these numbers to get rid of noise. The result is these >two numbers that are proportional to pitot and static pressure but otherwise >meaningless. As if that wasn't bad enough, they may not even be linearly >proportional to pressure. We may need to do a little curve fitting. > >So, do we just ship these raw numbers out onto the bus and let the >receiver(s) do the math? How would they know what conversion equation to >use? I think you get my point, no raw data on the bus. we process the data in the data module into a standardized aggreed upon variables, units, and formats. These are placed in messages and this data is made known to the system using a HLP such as CDA101/CAN Kingdom. See CDA101/12 for a list of aircraft related parameters that they have already defined. > >A somewhat fuzzier issue, I think, is do we send two pressures (in psi, kPa, >or whatever) or one indicated airspeed? Sending the two pressures seems >cleaner to me, but I'm open. Using CAN Kingdom its easy to do both. The data module lists all the possible data that it can send out The system setup master program picks and chooses what it is going to use from the various data modules and their data lists. Each module is free to offer what ever it wants to, and in various forms. Very modular approach. It makes it easy to provide general purpose modules that don't have to know how they will ultimately be used. This is just what we are looking for. > >....There are some relatively >new 16 bit microcontroller chips that seem to be a pretty good fit. I've >been looking at the Infineon C167 and the Fujitsu 905xx series. Their >architectures were designed with compilers in mind and they have larger >address spaces and pointers and more on chip memory. They seem to be >intended for the automotive market so they have on chip A/D, CAN, etc. So >far though, all I know is what I read in the data sheets, and I'm not sure >when I'll have time to go further. I'll keep you posted. > I agree with your observations. Chips of this ilk is probably what we need. I'd like us to come up with at least one small generic 8 channel analog to CAN microcontroller board with a little space for analog signal processing parts. We should also provide some sort of software development environment for our PCs(probably C/C++). If you haven't yet read the pdf document on the ST2000 boat project. It contains alot of useful information. It bridges the gap between the theory of CDA101/CAN Kingdom and its application. ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Data Module formatting...
Date: Dec 11, 1999
Hi John, Do you have a URL handy for "the pdf document on the ST2000 boat project"? BTW, re the Fujitsu chips I mentioned: Fujitsu is rumored to have a C compiler, linker, debugger, etc. package available for free! I'm currently trying to track this down. Am I still the only hardware designer (EE) type in our little group? I sure would like to see someone with more analog circuit design experience turn up. I've been studying up on things like interfacing to thermocouples, but it would be nice to have someone on board who has actually done this stuff for a living. Later, Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of J Livingston Sent: Saturday, December 11, 1999 8:39 AM Subject: Re: Avionics-List: Data Module formatting... I agree with your observations. Chips of this ilk is probably what we need. I'd like us to come up with at least one small generic 8 channel analog to CAN microcontroller board with a little space for analog signal processing parts. We should also provide some sort of software development environment for our PCs(probably C/C++). If you haven't yet read the pdf document on the ST2000 boat project. It contains alot of useful information. It bridges the gap between the theory of CDA101/CAN Kingdom and its application. ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Data Module formatting...
Date: Dec 11, 1999
Never mind, I found it. -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Jeff Barlow Sent: Saturday, December 11, 1999 11:19 AM Subject: RE: Avionics-List: Data Module formatting... Hi John, Do you have a URL handy for "the pdf document on the ST2000 boat project"? ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: ST2000 boat project
Date: Dec 11, 1999
Hi again, Just looked at the CDA101 Seaborne Target 2000 documents. It seems to be a small world. This work was done by the "toy boat and airplane" guys up at Point Mugu NAS. They make expensive R/C model planes and boats to give the navy something to practice shooting at. My ex-brother-in-law used to work there. Anyway, their design just the sort of thing I was thinking about for our "sensor box" design. To go along with the small world theme, the processor chip they used is one of the two I just mentioned. Later, Jeff ________________________________________________________________________________
Date: Dec 11, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Data Module formatting...
>Am I still the only hardware designer (EE) type in our little group? I sure >would like to see someone with more analog circuit design experience turn >up. I've been studying up on things like interfacing to thermocouples, but >it would be nice to have someone on board who has actually done this stuff >for a living. > >Later, >Jeff I can probably help a little there . . . Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 11, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: Data Module formatting...
>>At the other end of the chain, what's really in the "sensor box" is a pair >>(at least) of pressure sensors, a few opamps, an analog mux, an A/D >>converter, and a processor. The pitot and static ports are plumbed to the >>pressure sensors, which, in turn, output a voltage that is, while >>proportional to pressure, otherwise quite arbitrary. The A/D converter then >>converts that voltage to a binary number that is even more arbitrary. (It's >>not even in volts, it's just a ratio). The processor then does a little >>digital filtering on these numbers to get rid of noise. The result is these >>two numbers that are proportional to pitot and static pressure but >otherwise meaningless. As if that wasn't bad enough, they may not even >>be linearly proportional to pressure. We may need to do a little curve fitting. The very best value in solid state air data as of this writing was done for us on AQM-37D supersonic target a couple of years ago . . . jelly-bean, silicon strain gage presssure transducers are biased up with precision constant current sources. A 16 bit a/d looks at BOTH excitation voltage (temperature dependent) and output signal (ratiometric product of excitation and pressure). During screening, all units are tested on automatic pressure and temperature cycling equipment such that the integrity of system is proven while at the same time, you gather data on non-linearities and offsets due to temperature. After screening, a set of 3 lookup tables provided the ability do deduce pressure altitude to plus/minus 20 feet at 50,000 feet and pitot pressure to .1% for all effects combined. These units sold to us fully screend for about $2500 . . . the bill of materials for the electronics was under $200. >>So, do we just ship these raw numbers out onto the bus and let the >>receiver(s) do the math? How would they know what conversion equation to >>use? I think you get my point, no raw data on the bus. if you borrow from any of the contemporary data bus structures, the data packets are real numbers, ready to be used by other clients listening in. Whether BCD, Binary, Hex matters not as long as they're plug-n-play numbers. >> >>....There are some relatively >>new 16 bit microcontroller chips that seem to be a pretty good fit. I've >>been looking at the Infineon C167 and the Fujitsu 905xx series. Their >>architectures were designed with compilers in mind and they have larger >>address spaces and pointers and more on chip memory. They seem to be >>intended for the automotive market so they have on chip A/D, CAN, etc. So >>far though, all I know is what I read in the data sheets, and I'm not sure >>when I'll have time to go further. I'll keep you posted. >> > >I agree with your observations. Chips of this ilk is probably what we need. >I'd like us to come up with at least one small generic 8 channel analog to >CAN microcontroller board with a little space for analog signal processing >parts. We should also provide some sort of software development >environment for our PCs(probably C/C++). If you haven't yet read the pdf >document on the ST2000 boat project. It contains alot of useful >information. It bridges the gap between the theory of CDA101/CAN Kingdom and >its application. The system I described above does 20 Hz updates to a D/A ouput and uses an 8085 microprocessor. I think it runs at 8 or 10 Mhz. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 12, 1999
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: Data Module formatting...
Jeff Barlow wrote: > BTW, re the Fujitsu chips I mentioned: Fujitsu is rumored to have a C > compiler, linker, debugger, etc. package available for free! I'm currently > trying to track this down. Let's hope it's reasonable quality -- one of the free development systems I used (Z8 micro) wasn't worth the asking price. > Am I still the only hardware designer (EE) type in our little group? I sure > would like to see someone with more analog circuit design experience turn > up. I've been studying up on things like interfacing to thermocouples, but > it would be nice to have someone on board who has actually done this stuff > for a living. I have done this stuff for a living, but I'm not an EE. However I do know a bit about interfacing thermocouples, etc, picked up by osmosis whilst working with EEs. I couldn't design an analog circuit if my life depended on it though. Frank. ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Data Module formatting...
Date: Dec 11, 1999
Hi Bob, I sort of overlooked you, I guess. Steve hasn't added you to his "players" list yet. I hope you can find time to help out a bit with the design chores, it would make me feel less "out on a limb". When you say "jelly-bean, silicon strain gage pressure transducers" are you talking about the $15 ones that Lucas and others make for the automotive market? I was hoping these would be good enough if we temperature compensate and linearize them in firmware. The old table lookup and interpolate trick. Lots of prototype R&D work though. Later, Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Robert L. Nuckolls, III I can probably help a little there . . . Bob . . . The very best value in solid state air data as of this writing was done for us on AQM-37D supersonic target a couple of years ago . . . jelly-bean, silicon strain gage presssure transducers are biased up with precision constant current sources. A 16 bit a/d looks at BOTH excitation voltage (temperature dependent) and output signal (ratiometric product of excitation and pressure). During screening, all units are tested on automatic pressure and temperature cycling equipment such that the integrity of system is proven while at the same time, you gather data on non-linearities and offsets due to temperature. After screening, a set of 3 lookup tables provided the ability do deduce pressure altitude to plus/minus 20 feet at 50,000 feet and pitot pressure to .1% for all effects combined. These units sold to us fully screend for about $2500 . . . the bill of materials for the electronics was under $200. ________________________________________________________________________________
Date: Dec 11, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: Degauss
>Thanks! I need to get in touch with theese people (either method). The fuselage on my Pete Jones 450 Stearman is really badly magnetized, making it practically impossible to compensate the compass deviation. It has the battery in the rear, with the fuselage acting as minus conductor = high current running through the steel frame when the starter engages. Ones I get the frame degaussed I figure I need to run a separate heavy gauge ground cable from the battery to the engine? I ask my homebuiders to do just that. Engine mounts, fuselage structures, etc, are always mediocre to poor electrical system conductors. Idealized ground systems are described in appendix Z to our book which may be downloaded: http://www.aeroelectric.com/errata/z8_0299.pdf >Sten > >> No, that will actually magnetize the fuse even more. I have seen people >> demagnetize a steel tubing fuse by wrapping it with wire forming a >> solenoid (metal fuse inside a coil of wire) and then connect the wire to a >> variable autotransformer (a Variac). You turn up the voltage until the >> coil of wire is pulling as much current as the Variac can handle and let >> it sit for awhile. Then you slowly turn down the voltage so that the >> alternating magnetic field goes away slowly. When you are done your fuse >> should be demagnetized. If not, repeat the process until the permanent >> field is gone. >> >> Brian Lloyd > > >> Sten, >> >> This is just hear-say, since I haven't done it, but plan to. >> >> I think you need AC current. I was told to insulate your airframe and >> just hook it up in series with a light bulb on an AC house line. Beeeee >> verrrry careful. >> >> John One of those Sears buzz boxes (ac arc welders) makes a good, relatively constant current source to demagnitize large hunks of steel. Clip both leads to opposite ends of structure . . . or over the ground path presently used by the battery to get electrons to the crankcase. Start out at mimimum amps and turn the critter on. Step up rather quickly to max amps and back to minimum . . . about as quickly as you can move the controls. In my experience this technique has about a 75/25 chance of doing a useful thing . . If you have access to a fat Variac (mentioned> above, then put it in the AC line feed to the welder, set the welder for max current, then sweep the Variac from min to max to min as fast as you can go. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 11, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Data Module formatting...
> >Hi Bob, > >I sort of overlooked you, I guess. Steve hasn't added you to his "players" >list yet. I hope you can find time to help out a bit with the design chores, >it would make me feel less "out on a limb". Be glad to help when and where I can squeeze it in . . . working about 2-1/2 full time jobs now. >When you say "jelly-bean, silicon strain gage pressure transducers" are you >talking about the $15 ones that Lucas and others make for the automotive >market? I was hoping these would be good enough if we temperature compensate >and linearize them in firmware. The old table lookup and interpolate trick. >Lots of prototype R&D work though. That's the ones. I think the first interation used devices from ICS . . . the last ones were another vendor but I don't think they were over $25. I can probably get a schematic of how it was done and perhaps some good words from the guy who did the software as well. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: "Ian Molesworth" <ian(at)imolesworth.demon.co.uk>
Subject: Re: Data Module formatting...
Date: Dec 12, 1999
> > > >Am I still the only hardware designer (EE) type in our little group? I sure > >would like to see someone with more analog circuit design experience turn > >up. I've been studying up on things like interfacing to thermocouples, but > >it would be nice to have someone on board who has actually done this stuff > >for a living. > > > >Later, > >Jeff > > I can probably help a little there . . . > I'm just sitting quietly in the wings here.Does designing and manufacturing GPS data logging equipment, digital altimetry and a host of sensor equipment for military helicopters and surveilance aircraft, HUD's , Tank rangefinding, sighting and gun stabilisation equipment help at all? I put a long post together about the benefits of formatting bus data as XML but it got bounced by the list engine since it looked vaugely like HTML. I have attached the returned interpretation so it might get past the engine this time..... > Hi All > > Forgive my late intrusion to the fray but has anyone considered > formatting data on the bus as XML? > > At first thought the idea may seem a little silly but if you think about > it all the reasons that XML is getting so popular in the current IT > arena tend to apply to an open source, open architecture, such as is > being proposed here. > > XML makes messages human readable so debugging a misbehaving device > becomes easier. > XML is VERY java friendly, classes are available for free to do all the > data manipulation. C has libraries available too. > XML data is self describing so ............. > A device attached to the bus 'publishes' data to the bus. Devices > that already understand the data can act upon it. Devices that don't > comprehend the data dont go into a flat spin, they simply ignore it. The > advantage is that different versions of firmware can exist on bus > devices with far less chance of problems with data format. > > Take for example the old NMEA standard stuff that comes out of most > GPS's > > $GPRMC,212949,A,4915.61,N,12310.55,W,000.0,360.0,11119Mag8,020.3,E*6B > > Now unless you have the NMEA 1.5 and NMEA 2.0 standards next to you > whilst writing your firmware you are in a bit of a bind!> > If you were to see > > [GPAviationMessage] > [Source]Garmin GPS-12xl[/Source] > [ReceiverHealth] OK [/ReceiverHealth] > [Timestamp] > [time]21:29:49[/time] > [zone]UTC[/zone][/zone] > [/Timestamp] > [Position] > [Latitude] 49=B015.61[/Latitude] > [LatHemisphere]N[/LatHemisphere] > [Longitude] 123=B010.25 [/Longitude] > [LngHemisphere]W[/LngHemisphere] > [GPSAltitude] > [Height] 111198[ > [Units Feet > [/GPSAltitude] > [/Position] > [TrueHeading]360[/TrueHeading] > [MagDeviation]20.3[/MagDeviation] > [DevHemisphere] E[/DevHemisphere] > [MessageHash] EF445010[/MessageHash] > [/GPSMessage] > > It may be about 4 times more verbose but if we're talking megabit comms > rates does it matter all that much? > > Has anyone looked, or is anyone looking at what will 'reasonably' be expected to travel on a common bus in terms of messages? > > GPS position. Barometric pressure, Compass (Magnetic) Heading(Gyro) 3 axis of horizon info, Temperatures ( about a dozen Airspeed, Rate of climb perhaps ), A handfull of 'digital' signals. > > Remember that inventing a new bus means having to invent the sensors > that go at BOTH ends of the wire. Can you buy a GPS that interfaces to > anything but the standard aviation busses?? I would love to play with a > ring laser gyro to match it to an open system but they are pricey, even > to very dedicated home enthusiasts!!! > > On another front..... someone else posted ( Matt ) that developing in > assembler for micro based systems was the only way to go or would > require him to learn C - I thought I was a dinosaur!!!!! A copy of K&R's > C book and a couple of hours with something like Kiels C for the 8051 > and your away Matt.> ________________________________________________________________________________
Date: Dec 12, 1999
From: Steven Eberhart <newtech(at)newtech.com>
Subject: new list member
The following email was received from a friend of mine located in France. I invided him to join the list. His reply speaks for itself. Steve Eberhart mailto:newtech(at)newtech.com ---------- Forwarded message ---------- Date: Sun, 12 Dec 1999 21:23:29 +0100 From: Stefan B. <stefan.balatchev(at)wanadoo.fr> Subject: Re: Translation I will be glad to subscribe to the new Glass Cockpit list. As I work with National Instruments' LabVIEW (visualization software, may-be you know it) and with CAN (Controlled Area Network), I had already decided to develop a small Glass Cockpit for my bird, of course after completing the construction of my "Centaure". It will be great to participate in the discussions of this mailing list. I am working as an EE in a small company (we are 12 in France and 5 in Germany) specialized in the liquid leak detection and location systems. As I am the only "electrical" person here, I develop our systems from A to Z. I begun with the detection/location method (some physics of materials), then I worked on the mechanical and corrosion properties of the detection cable (some chemistry and ME), after it was the real development in electronics (microcontrollers, displays, power supplies, EMC, etc.) and now I am working on the supervision software based on LabVIEW... Oh, I also develop the testing equipment for our products. As you say, the world is small... As a student in Bulgaria, I had specialized in the Medical Electronics. In France I obtained my MSc in the Microwave Electronics and now as you see, it is another field of electronics. C'est la vie! I like it. Stefan Balatchev. > > I didn't know that you were an EE. THere is a relatively new mail list > that is developing a Glass Cockpit system for Experimental aircraft. They > are using a dedicated network bus for all of the sensors and computers to > talk over. One person has developed the software for the cockpit display > in Java. It is very impressive. If you are interrested I can send you > the information to subscribe to the mail list. > > Before getting a second major in Computer Science I was an Electronic > Engineer for Potter & Brumfield and worked on microcomputer systems for > testing Relays made by Potter & Brumfield. Before that I worked for > Motorola building the test equipment for the worlds first solid state > memory modules, circa 1968. It truly is a small world. > > 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: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: Data Module formatting...
Date: Dec 12, 1999
Welcome Ian. I too am a student of XML. I think XML is going to take everyone by suprise in a few months! The only problem with using it in this context is the CAN specification is limited in the amount of data we may transmit. Each "data frame" in CAN is limited to between zero and eight bytes in the data field. This is extremely small when you consider IP packets are typically limited to 512 bytes of user data. For our purposes, we can look at CAN from two layers: Chip layer and CAN Kingdom layer. On the chip layer: we can buy microcontroller chips that have built-in CAN communications from most any chip manufacturer. To see details of this, check out http://www.mot-sps.com/ and search for "Bosch Controller Area Network v2.0 Protocol Standard" which is 1.4 MB. (Also see MCAN8 & MCAN12 document). On top of this is the CAN Kingdom (CDA101) layer. For a good intro to this, check out these HTML pages: http://www.kvaser.com/canking/std/index.htm . Marlin ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Java flight simulator - now what?
Date: Dec 13, 1999
I've downloaded the java simulator (zip file), unzipped it into a directory (c:\Program Files\JavaRE\FS) and then the JRE (installed in (c:\Program Files\JavaRE), opened a DOS prompt in the simulator directory and this is the result: C:\Program Files\JavaRE\FS>..\bin\java.exe simulator Exception in thread "main" java.lang.NoClassDefFoundError: simulator (wrong name : Simulator) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$1(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) What am I doing wrong? I have no idea what I'm doing with java.... (BTW: running Win98) Joe Hovel ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: Java flight simulator - now what?
Date: Dec 13, 1999
I haven't run the simulator in JRE--I've only gotten it to work in JDK, but I DID notice that you referred to the simulator with a lowercase 's'. Try 'java Simulator' instead. Let me know if this works. Marlin ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Introduction, Bob?
Date: Dec 13, 1999
>Hi Bob, > >I sort of overlooked you, I guess. Steve hasn't added you to his >"players" list yet. I hope you can find time to help out a bit with >the design chores, it would make me feel less "out on a limb". Hey, Bob, care to write up a small bio for the players page? Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 13, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: Introduction, Bob?
> >Hey, Bob, care to write up a small bio for the players page? > >Steve I guess I could do that. My resume (only a couple of years out of date) is available on our website at: http://www.aeroelectric.com/resume.pdf Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: HornetBall(at)aol.com
Date: Dec 13, 1999
Subject: CAN Bus Solid State Attitude Device
Came across this AHRS. It advertises CAN bus compatibility. Here's the link: http://www.imar-navigation.de/ahz_eng2.htm ________________________________________________________________________________
Date: Dec 13, 1999
From: "Stefan B." <stefan.balatchev(at)wanadoo.fr>
Subject: Introduction
Hello to all from France, I am a new member to this mail list and I saw from the recent archives of the list that Steve Eberhart has already presented me. My name is Stefan Balatchev and I am building a KR-style very large prototype. I am an EE and I am more hardware than software and work well with the low-level languages as assembler and quite bad with C++, Pascal, Java, etc. I have already worked with National Semiconductor's CAN microcontrollers and I had also decided to develop a small glass cockpit including the tacho, oil pressure and temp., speed, altitude, and so on. Prior to enter the discussions I will read all the archive to not discuss something dj vu. Stefan Balatchev, Paris, France mailto:Stefan.Balatchev(at)wanadoo.fr ________________________________________________________________________________
Date: Dec 13, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Aerospace (units of measure)
> Unless there are strong > technical reasons for changing formats, you might > want to adopt the ARINC429 suite of messages and > add your own unique packets as needs be. The ARINC messages are kinda kludgy. ARINC is still talking about OSI protocols which are otherwise pretty much dead and buried. They could use some datacomm help over there. > It MIGHT encourage some existing vendor > of high-dollar ARINC compatable stuff to service > your market if all they need to do is change their > bus interface. Clumsy as it may be, there's a > LOT of 429 stuff out there. A new system might > enjoy faster acceptance if it had familar features. We actually considered that (see the archives). The CAN stuff looks like it will be more useful. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 13, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Data Module formatting...
>Am I still the only hardware designer (EE) type in our little group? I sure >would like to see someone with more analog circuit design experience turn >up. I've been studying up on things like interfacing to thermocouples, but >it would be nice to have someone on board who has actually done this stuff >for a living. I have access to a resource to do this. Let me see if I can make it work out. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 13, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Data Module formatting...
>> Forgive my late intrusion to the fray but has anyone considered >> formatting data on the bus as XML? Let's not go there. I spent time this summer fighting off XML as the "solution" for AAA. >> At first thought the idea may seem a little silly but if you think about >> it all the reasons that XML is getting so popular in the current IT >> arena tend to apply to an open source, open architecture, such as is >> being proposed here. Well, it isn't THAT poplular. The XML camp strikes me as suffering from the, "when all you have is a hammer, everything looks like a nail," syndrome. >> XML makes messages human readable so debugging a misbehaving device >> becomes easier. Well, I don't expect to have too many people attached to the CAN buss. Everything else will be a uP doing the interpretation. >> XML is VERY java friendly, classes are available for free to do all the >> data manipulation. C has libraries available too. >> XML data is self describing so ............. >> A device attached to the bus 'publishes' data to the bus. Devices >> that already understand the data can act upon it. Devices that don't >> comprehend the data dont go into a flat spin, they simply ignore it. The >> advantage is that different versions of firmware can exist on bus >> devices with far less chance of problems with data format. We have that with CAN and CAN Kingdom too. >> Take for example the old NMEA standard stuff that comes out of most >> GPS's >> >> $GPRMC,212949,A,4915.61,N,12310.55,W,000.0,360.0,11119Mag8,020.3,E*6B >> >> Now unless you have the NMEA 1.5 and NMEA 2.0 standards next to you >> whilst writing your firmware you are in a bit of a bind!> >> If you were to see >> >> [GPAviationMessage] >> [Source]Garmin GPS-12xl[/Source] >> [ReceiverHealth] OK [/ReceiverHealth] >> [Timestamp] >> [time]21:29:49[/time] >> [zone]UTC[/zone][/zone] >> [/Timestamp] >> [Position] >> [Latitude] 49=B015.61[/Latitude] >> [LatHemisphere]N[/LatHemisphere] >> [Longitude] 123=B010.25 [/Longitude] >> [LngHemisphere]W[/LngHemisphere] >> [GPSAltitude] >> [Height] 111198[ >> [Units Feet >> [/GPSAltitude] >> [/Position] >> [TrueHeading]360[/TrueHeading] >> [MagDeviation]20.3[/MagDeviation] >> [DevHemisphere] E[/DevHemisphere] >> [MessageHash] EF445010[/MessageHash] >> [/GPSMessage] ... you would have run into the mountain 5 miles down the road by the time you transferred that across your buss. >> It may be about 4 times more verbose but if we're talking megabit comms >> rates does it matter all that much? Maybe. I don't see that verbosity for the sake of verbosity is a win. >> Has anyone looked, or is anyone looking at what will 'reasonably' be >expected to travel on a common bus in terms of messages? Yes. Read the archives. >> GPS position. Barometric pressure, Compass (Magnetic) Heading(Gyro) 3 axis >of horizon info, Temperatures ( about a dozen Airspeed, Rate of climb > perhaps ), A handfull of 'digital' signals. >> >> Remember that inventing a new bus means having to invent the sensors >> that go at BOTH ends of the wire. Can you buy a GPS that interfaces to >> anything but the standard aviation busses?? I would love to play with a >> ring laser gyro to match it to an open system but they are pricey, even >> to very dedicated home enthusiasts!!! Read the archives. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 13, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Data Module formatting...
At 11:11 PM 12/12/99 GMT, you wrote: > >Welcome Ian. > >I too am a student of XML. I think XML is going to take everyone by suprise >in a few months! So will AIDS or Hepatitus-B too. >The only problem with using it in this context is the CAN >specification is limited in the amount of data we may transmit. Each "data >frame" in CAN is limited to between zero and eight bytes in the data field. >This is extremely small when you consider IP packets are typically limited >to 512 bytes of user data. The limit on the size of IP datagrams is 65535 bytes/octets. Most networking components transmit datagrams up to 1500 bytes/octets without fragmenting. 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: Data Module formatting...
Date: Dec 13, 1999
> >I too am a student of XML. I think XML is going to take everyone by >suprise > >in a few months! > >So will AIDS or Hepatitus-B too. Of course. And not to mention hemoragic fevers such as hantavirus and ebola; hep-C, cryptospiridium and Vancomycin Resistant Enterococcus. But I digress. ________________________________________________________________________________
From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: AGATE databus vs CAN
Date: Dec 13, 1999
All, I have here some correspondence with Jim Meer about AGATE(Lon)databus. I thought I'd pass it on for what it is worth. I will continue to monitor this activity, and try and get some technical details. -----Original Message----- From: James K. Meer [mailto:microflight(at)att.net] Sent: Sunday, December 12, 1999 1:05 PM Subject: Re: Avionics-List Digest: 12/09/99 Craig, This looks like a very good forum to follow. They are talking about the right issues and may be excused for their indiscretions about AGATE. We have looked at CAN 2.0 many times and don't think we can get to Level A -- Flight Critical. Without Level A, there is no market. The Kit and Home market might be able to support a lower technology bus. There are right about 1553B and ARINC 629 -- overly expensive and complicated. I saw mention of ARINC 429 which is a point to point bus which is a pain to implement. All databuses have warts. Its a matter of picking your bus and trying to solve the problems. We are not there yet but the need and potential is there. It will be only a matter of time. Echelon Lon is the best of the bunch. There are numerous issues to overcome on Lon as well. Lon is a full 7 OSI compliant stack and may be used as a multidrop bus. It has better collision handling algorythms than ethernet. It has been developed for the home and commercial automation martkets which are mega huge in comparison to aviation -- translate to cheap and reliable. Lon has been used in railroad break safety and human monitering systems successfully. One of the guys (John Livingston) on the discussion is at WPAFB and has asked us for more information. I hope he will stay with us and I would like to hear from this forum from time to time. I doubt that really answers your question. Your planning/dreaming should allow for the possibility of sending digital packets through a virtual wiring system. This will allow changes to be made by dropping nodes onto the network at a later time and being able to rewire the airplane with software. Regards, JKM James K. Meer, Principal Microflight My responce: James Meer, Don't get me wrong, all of what I did find sounded very good. What bothered me was what I didn't find. Maybe I'm not looking in the right place. I could not find (draft) specifications on the net. I could not find a source for the controllers or fiber-optic bus dirvers. There seemed to be few Neuron chip manufacturers. What little I did find was from Eschelon and Raytheon but this was more in the form of PR. Our goup is interested in getting hardware, software and development tools at reasonable rates so that we can develope avionics modules and systems. If we can't get this our little project will be still born. My feeling is that we need to be able to procure something like the following in order to get folks started: - specificatons that can be freely circulated - basic 8 channel sensor module (includes bus drivers) parts < $100 (or complete < $200) exclude sensors - software development environment (for PC, most likely C/C++) for <$500 - example (C/C++) starter software that can be freely circulated. You get the idea. Costs to get into the game must be minimized even for serious hobbyists. I hope I'm wrong, but it so far the AGATE databus has all the hallmarks of being tailored for companies that can drop multiple thousands of dollars before they build their first board or write their first line of code. We can't afford that, and I personally don't think it is in aviations best interests. The more people we can get working in this area the better. If you could direct us to this sort of info, it would be much appreciated. I'm very sorry none of us could get to the AGATE databus meeting. Is there a way to get info on what transpired? Would you mind if I share your responces with the group? If theire are things you don't want shared I'll understand, but I'd rather this be done with the group as much as possible. There also appears to be some major discrepencies between what is said about deterministic timing with reguard to CAN Kingdom and LonTalk. CAN Kingdom supports this. Some say LonTalk doesn't support it at all and so can't be seriously considered for a critical control system. Others obviously say otherwise. Do you know of any papers that compare these protocals WRT deterministic timing? John John, I was not being negative and the reason I copied you was to let you know there is some activity in AGATE in this area. Whether we will be successful is an open question. Your and other's statments about databuses are all true. I would like to stay informed of your discussions and I will try to keep you apprised as well. Regards, JKM James K. Meer, Principal Microflight James, I know and I appreciate your input. We are trying to establish links where ever possible, and we definately want to keep informed with AGATE's work. I personally think that optical cabling is the way to go for safety and bandwidth, but I have just scratched the surface and have no supplier, technical or cost data yet. I hope you don't mind if I bother you from time to time. John ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Java Simulator
Date: Dec 14, 1999
Thanks, Jerry et al! It now loads OK (it crashes my computer, but that's another issue....)- at least I can see what it looks like. Joe From: "Jerry Coston" <Jerryc(at)Silverglobe.com> Subject: Re: Zenith-List: Java simulator - now what? --> Zenith-List message posted by: "Jerry Coston" Joe, I'm a software developer (mainly C++ but in the process of learning java) and unfamiliar with the particular program you're running, but it looks to me like you need to set a class path for your simulator execution. This is done simply with a "-cp" parameter prior to the executable class name - ie: c:\program files\JavaRE\FS> java -cp "c:\program files\JavaRE\FS" simulator Also, if the simulator is in a ".jar" or ".zip" format, there is another parameter "-jarfile" which may need to be used. You can type in "java" with no parameters to see these options. Hope this helps, --Jerry 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: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
Subject: AGATE databus from James Meer
Date: Dec 14, 1999
All, An update from James Meer. I guess I was wrong about the fiber-optics. ................. John, I prefer that you bother me. We need as much participation as possible in whatever form if we are to succeed with a inexpensive databus for GA. By the way, the Echelon implementation that uses fibre has been developed by Raytheon Electronic Systems. I believe they now have a launch customer for it but have not been in contact for a few months. The Raytheon implementation uses an asych on top of the protocol to attain determinism. The asych, among other things, provides a round robin scheduler. Agate's problem with the Raytheon implementation is that it is very expensive -- possibly as high as $100 per node. The Agate Lon bus will use shielded twisted pair. Our goal was to be under $20 per node based upon the avionics being about 35% of the airplane cost on an airplane with $150,000 list price. Echelon was initially 6$ per node for just a neuron (3120) without microprocessor which would be ok for simple sensors and controls. It was $12$ for a neuron and microprocessor (3150) which could be used with avionics and more complex avionics even an autopilot. Since then the neurons have decreased in cost to approximately 1-2$ with a corresponding decrease in the neuron with microprocessor. These numbers and the full protocol make Echelon very attractive. Having said that there are many issues to be worked involving the technology, standards and business issues. If our February meeting is successful, we will be launching an open standardization effort for the bus. The standards organization will most likely be EIA since they have the 709.1 standard for the Echelelon LON technology. After 5 years as an EIA standard, the standard can become an SAE standard by application. Another important element of the standard process is to have a repository for standard data packets such as altitude, longitude, etc. This databus database is being developed and will reside on a server at the Agate Alliance Association, Inc. (AAAI) which has been established by Agate as an administrative facility for Agate programs. If you and/or your other forum members are interested, I will insure that you receive notices of the meetings. This should help establish a better understanding of the technology and its potential use. Regards, JKM James K. Meer, Principal Microflight ________________________________________________________________________________
Date: Dec 14, 1999
From: dab(at)froghouse.org
Subject: AGATE databus from James Meer
On 14 Dec, Livingston John W Civ ASC/ENFD wrote: > The Agate Lon bus will use shielded twisted pair. This reminded me of something I ran across in researching various link layers. It said that shielded twisted pair had a shorter range than unshielded twisted pair for the same drivers and data rate. The range for RS-485 or CAN ove UTP even at 1Mb/s was ample so using sheilded wire might be something we ought to consider as well. -Dave ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: AGATE databus from James Meer
Date: Dec 14, 1999
Hi, Well designed balanced systems (i.e. CAN, RS-485, 10baseT, etc.) inherently have a low sensitivity to common mode noise without shielding. Adding a shield to them adds cost, typically doesn't help, and tends to create ground loops. It is generally better to attenuate the noise at it's source. I view shielding as a last resort. Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of dab(at)froghouse.org Sent: Tuesday, December 14, 1999 11:05 AM Subject: RE: Avionics-List: AGATE databus from James Meer On 14 Dec, Livingston John W Civ ASC/ENFD wrote: > The Agate Lon bus will use shielded twisted pair. This reminded me of something I ran across in researching various link layers. It said that shielded twisted pair had a shorter range than unshielded twisted pair for the same drivers and data rate. The range for RS-485 or CAN ove UTP even at 1Mb/s was ample so using sheilded wire might be something we ought to consider as well. -Dave ________________________________________________________________________________
From: "Ian Molesworth" <ian(at)imolesworth.demon.co.uk>
Subject: Re: XML and other data formats
Date: Dec 14, 1999
Almost ignoring the rather scathing comments about XML......... Can anyone point me in the direction of free tools for developing with things like LONworks? Last time I looked LON tools cost a small mint. Its OK for those that are going to steal a copy of the tools from their employers but the rest of us are left out in the cold by having to aquire decent tools. Ian ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Dec 14, 1999
Subject: Lon
>... It has been developed for the home and commercial automation martkets which are mega huge in comparison to aviation -- translate to cheap and reliable. Lon has been used in railroad break safety and human monitering systems successfully. CAN was developed for the auto market, also "mega huge". I don't yet know enough to campaign for any particular solution, but I am about ready to order some CAN stuff for experimentation. I have not yet ordered because there are so many different suppliers to choose from, and I want to make a good choice. The Motorola MC68HC912BC32 looks really nice, but it isn't the cheapest. In my net surfing, I found nothing, zero, zilch available for Lon. Not saying that there isn't anything, just that it is my impression that the hype about the "mega huge" home automation market is mostly just the marketing hopes of the Lon vendor wannabees. Please correct me (and point me to vendors who are delivering) if I am wrong. g. ________________________________________________________________________________
Date: Dec 14, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: shielded vs. unshielded twisted pair
> >Hi, > >Well designed balanced systems (i.e. CAN, RS-485, 10baseT, etc.) inherently >have a low sensitivity to common mode noise without shielding. Adding a >shield to them adds cost, typically doesn't help, and tends to create ground >loops. It is generally better to attenuate the noise at it's source. I view >shielding as a last resort. A twisted pair is a form of balanced transmission line. Anything that causes an imbalance, e.g. something in proximity to one conductor and not the other will imbalance the line and cause radiation. A shield will reduce the capacitive effect of nearby conductors and it will act as a faraday shield. Yes, a shield will help to keep things quieters, EMI-wise. You avoid ground loops by grounding only one end of the shield. The cost of shielded vs. unshielded wire is usually pretty minimal. 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: RobertR237(at)aol.com
Date: Dec 15, 1999
Subject: Re: shielded vs. unshielded twisted pair
In a message dated 12/15/99 1:45:19 AM Central Standard Time, brian(at)lloyd.com writes: > > > >Hi, > > > >Well designed balanced systems (i.e. CAN, RS-485, 10baseT, etc.) inherently > >have a low sensitivity to common mode noise without shielding. Adding a > >shield to them adds cost, typically doesn't help, and tends to create > ground > >loops. It is generally better to attenuate the noise at it's source. I view > >shielding as a last resort. > > A twisted pair is a form of balanced transmission line. Anything that > causes an imbalance, e.g. something in proximity to one conductor and not > the other will imbalance the line and cause radiation. A shield will > reduce the capacitive effect of nearby conductors and it will act as a > faraday shield. Yes, a shield will help to keep things quieters, EMI-wise. > > You avoid ground loops by grounding only one end of the shield. > > The cost of shielded vs. unshielded wire is usually pretty minimal. Brian, I agree completely with your statements and would add that given a situation where we can be in control of ALL possible noise generating sources the use of shielded wire might be unnecessary. We do not however have that option and control with our panels and should anticipate that any noise sensitive cable will need to be shielded. The cost of shielded wire will be one of the least of our costs. Bob Reed, KIS Cruiser in progress...http://RobertR237.virtualave.net/ (KIS Project) ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: shielded vs. unshielded twisted pair
Date: Dec 15, 1999
From NEAMA 2000 draft: 2.7.2 Light Cable This cable is the type used with industrial bus systems (e.g., DeviceNet, Profibus, and SDS, and Seriplex). Light cable used in NMEA 2000 applications willshall have the following characteristics: a) Light cable may be five-wire constructed with two individually shielded pairs enclosed by an overall shield with a shield drain wire connecting all three shields. The [optional] shields may be foil or braid. b) The five wires shall be stranded-copper with each strand individually tinned to improve corrosion resistance. c) The light pair used for network power shall be No. 22 AWG (0.38 sq. mm) or better. d) The light pair used for signals shall have the following electrical characteristics: Size: No. 24 AWG (0.24 sq. mm) or better, Characteristic impedance: 120 95 - 140 Ohms, Propagation delay: 5 nanoseconds per meter, maximum, Capacitance, wire-to-wire: 40 *F/meter. e) The light cable drain wire shall be No. 22 AWG (0.38 sq. mm) or better. f) Insulating materials shall be oil and fuel resistant and capable of withstanding 80C or higher. g) When the recommended wire colors shown in Table 2-6 are not used the cable shall be permanently labeled to indicate the color code in use: Table 2-6 Light Wire Color Codes Name Pair Color Shield drain bare PS+ power Red PS- power Black CAN+ signal White CAN- signal Blue John -----Original Message----- From: RobertR237(at)aol.com <RobertR237(at)aol.com> Date: Wednesday, December 15, 1999 8:30 AM Subject: Re: Avionics-List: shielded vs. unshielded twisted pair > >In a message dated 12/15/99 1:45:19 AM Central Standard Time, brian(at)lloyd.com >writes: > >> > >> >Hi, >> > >> >Well designed balanced systems (i.e. CAN, RS-485, 10baseT, etc.) >inherently >> >have a low sensitivity to common mode noise without shielding. Adding a >> >shield to them adds cost, typically doesn't help, and tends to create >> ground >> >loops. It is generally better to attenuate the noise at it's source. I >view >> >shielding as a last resort. >> >> A twisted pair is a form of balanced transmission line. Anything that >> causes an imbalance, e.g. something in proximity to one conductor and not >> the other will imbalance the line and cause radiation. A shield will >> reduce the capacitive effect of nearby conductors and it will act as a >> faraday shield. Yes, a shield will help to keep things quieters, EMI-wise. >> >> You avoid ground loops by grounding only one end of the shield. >> >> The cost of shielded vs. unshielded wire is usually pretty minimal. > >Brian, I agree completely with your statements and would add that given a >situation where we can be in control of ALL possible noise generating sources >the use of shielded wire might be unnecessary. We do not however have that >option and control with our panels and should anticipate that any noise >sensitive cable will need to be shielded. The cost of shielded wire will be >one of the least of our costs. > >Bob Reed, >KIS Cruiser in progress...http://RobertR237.virtualave.net/ (KIS Project) > > ________________________________________________________________________________
Date: Dec 15, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: shielded vs. unshielded twisted pair
On Wed, 15 Dec 1999 RobertR237(at)aol.com wrote: > Brian, I agree completely with your statements and would add that given a > situation where we can be in control of ALL possible noise generating sources > the use of shielded wire might be unnecessary. We do not however have that > option and control with our panels and should anticipate that any noise > sensitive cable will need to be shielded. The cost of shielded wire will be > one of the least of our costs. I am more worried about our wiring radiating and interfering with the avionics than I am with other devices interfering with the buss. ADF, stormscope/strikefinder, and LORAN are all very susceptable to LF/MF/HF EMI. Anything we can do to reduce crud getting in OR out is a good thing. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 15, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: shielded vs. unshielded twisted pair
On Wed, 15 Dec 1999, J Livingston wrote: > > >From NEAMA 2000 draft: > > 2.7.2 Light Cable Wow, someone got it right! The more I see of the CAN buss, the more impressed I am. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: shielded vs. unshielded twisted pair
Date: Dec 15, 1999
Well, we can table the shielded/unshielded issue for the time being. This would come much, much later. And, because the same conductors are used, we can even leave this particular detail up to builder's discretion (though I probably would install shielded cable myself, all grounded at one common junction...) Which reminds me... what is the physical installation of CAN? Does it require some sort of hub/controller (like 10BT UTP Ethernet, which would also be the ideal location of that ground connection), or does one device connect to the next (like 10B2 Coax Ethernet)... or is there another method? Please elaborate (those of you who know) so that I may update the documentation... 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: shielded vs. unshielded twisted pair
Date: Dec 15, 1999
Gee, I didn't intend to stir up such a hornets nest over a minor point. One idea I was trying (and, evidently, failing) to get across was that I have seen shielding used as a crutch to get otherwise poorly designed systems to work. I want us to get this to work without it, and then we can add it as insurance. We do need to be very careful about ground loops, though. The CAN bus includes a ground reference wire that is separate from the shield. That plus a shield plus a metal airframe can make the ground loop problem rather trickier than it might seem. We just need to be sure that everyone who installs this is suitably educated. (I guess you can tell I've had some frustrating experience with this sort of thing.) Regarding CAN topology: It is a true bus, not a star, there is no hub. There are bus termination requirements to avoid signal reflections, and therefore, limits on stub length, depending on the termination strategy used. Again, this is primarily an installation issue. I think this is pretty well documented in the various specs. It's just that every installer must RTFM and comprehend it. Jeff -----Original Message----- Well, we can table the shielded/unshielded issue for the time being. This would come much, much later. And, because the same conductors are used, we can even leave this particular detail up to builder's discretion (though I probably would install shielded cable myself, all grounded at one common junction...) Which reminds me... what is the physical installation of CAN? Does it require some sort of hub/controller (like 10BT UTP Ethernet, which would also be the ideal location of that ground connection), or does one device connect to the next (like 10B2 Coax Ethernet)... or is there another method? Please elaborate (those of you who know) so that I may update the documentation... Steve ________________________________________________________________________________
Date: Dec 15, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: shielded vs. unshielded twisted pair
> >Gee, I didn't intend to stir up such a hornets nest over a minor point. One >idea I was trying (and, evidently, failing) to get across was that I have >seen shielding used as a crutch to get otherwise poorly designed systems to >work. I want us to get this to work without it, and then we can add it as >insurance. That is the case with balanced twisted pair. It will work just fine and will be very robust. And we will do shielding over it to make it even more robust and resistant to generating EMI. >We do need to be very careful about ground loops, though. The CAN bus >includes a ground reference wire that is separate from the shield. That plus >a shield plus a metal airframe can make the ground loop problem rather >trickier than it might seem. We just need to be sure that everyone who >installs this is suitably educated. (I guess you can tell I've had some >frustrating experience with this sort of thing.) Been there, done that too. One of the tricks to do with a shield is to ground it through a 10 ohm resistor. That will limit any current in the shield while still allowing it to function as an electrostatic shield. >Regarding CAN topology: It is a true bus, not a star, there is no hub. There >are bus termination requirements to avoid signal reflections, and therefore, >limits on stub length, depending on the termination strategy used. Again, >this is primarily an installation issue. I think this is pretty well >documented in the various specs. It's just that every installer must RTFM >and comprehend it. Well, we can hope that people working on airplanes have a greater propensity to RTFM than your everyday bozo but there will be some [hopefully small] minority that will screw it up. Dave and I discussed this in private email. He talked about finding a jack that would automatically terminate the data buss when nothing was plugged in. The connectors he found were not what you would call aviation grade. OTOH, I am of the, "read the manual and do it right," school of thought. I feel it is better to make the system simpler but require the installer to read the manual and do it right. Hey, Electric Bob! You have eons of experience with avionics installers. Are they generally bozos or brainiacs (or something in the middle)? 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: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: CAN Aerospace
Date: Dec 15, 1999
All, Well, the debate about the protocol has died down some, it seems. I read the spec for CAN Aerospace this weekend. While the basic design seems very well suited to what we want to do, I have to admit that the spec is just too immature and ill-defined to be put to use. There are quite a few gaping holes in the spec, and a LOT of ambiguity. I haven't looked over CAN Kingdom yet, but others have had good things to say about it. I'll have to crack that one open this weekend. In any case, I'd advise against us using CAN Aerospace, much as I hate to lose such a simple interface. It's just not ready for prime time, IMHO. -Matt ======================== "I don't care what anybody says, there ARE user serviceable parts inside. " ________________________________________________________________________________
Date: Dec 16, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: shielded vs. unshielded twisted pair
>>Regarding CAN topology: It is a true bus, not a star, there is no hub. There >>are bus termination requirements to avoid signal reflections, and therefore, >>limits on stub length, depending on the termination strategy used. Again, >>this is primarily an installation issue. I think this is pretty well >>documented in the various specs. It's just that every installer must RTFM >>and comprehend it. At 1 Mhz bit rates, and given the limited physical size of airplanes, it seems doubtful that one would get into trouble with stubs. >Hey, Electric Bob! You have eons of experience with avionics installers. >Are they generally bozos or brainiacs (or something in the middle)? > From CEOs to floorsweeps, they come in all flavors. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 16, 1999
From: "Stefan B." <stefan.balatchev(at)wanadoo.fr>
Subject: Re: Lon
Glen_Worstell(at)notes.seagate.com wrote: > > I don't yet know enough to campaign for any particular solution, but I am about > ready to order some CAN stuff for experimentation. I have not yet ordered > because > there are so many different suppliers to choose from, and I want to make a > good choice. The Motorola MC68HC912BC32 looks really nice, but it isn't the > cheapest. > You could try these URL's for pricing and samples: http://www.national.com/pf/CO/COP888EB.html http://www.national.com/pf/CO/COP884BC.html http://www.national.com/pf/CO/COP87L88EB.html http://www.national.com/pf/CO/COP87L84BC.html (sorry, no HTML support by the mail list) You could also find a cheep (relatively to Motorola's) programmer/debugger from NS (or NS' subcontractor as ICE Technology or MetaLink) but I haven't got an URL for it. Stefan Balatchev. ________________________________________________________________________________
Date: Dec 16, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Aerospace
On Wed, 15 Dec 1999, Matthew Mucker wrote: > Well, the debate about the protocol has died down some, it seems. I read the > spec for CAN Aerospace this weekend. While the basic design seems very well > suited to what we want to do, I have to admit that the spec is just too > immature and ill-defined to be put to use. There are quite a few gaping > holes in the spec, and a LOT of ambiguity. In your opinion, what gaping holes and ambiguity exist in the spec? This is a common problems with specifications since often what seems obvious to the author is nonobvious to the uninitiated reader. It may be that a discussion with the author of the CAN Aerospace spec would fill in the blanks an eliminate the ambiguity. Since we were already starting from scratch it seems to me that it would be easier to remove the holes and ambiguity than to go back to square one. Is there something you would prefer to CAN Aerospace? Are you saying that we should reject CAN with 29 bit tags as a base protocol? > I haven't looked over CAN Kingdom yet, but others have had good things to > say about it. I'll have to crack that one open this weekend. In any case, > I'd advise against us using CAN Aerospace, much as I hate to lose such a > simple interface. It's just not ready for prime time, IMHO. Even if we rolled our own HL protocol, why would you reject CAN for the physical and base messaging protocol? It seems rather simple and straight forward for general interfacing. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 16, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: shielded vs. unshielded twisted pair
On Thu, 16 Dec 1999, Robert L. Nuckolls, III wrote: > At 1 Mhz bit rates, and given the limited physical size of airplanes, > it seems doubtful that one would get into trouble with stubs. You would be surprised. I have actually run into problems with stubs at audio rates. Granted I was dealing with mile long stubs (phone company not removing unterminated pairs) but I would never had expected it would be a problem. > >Hey, Electric Bob! You have eons of experience with avionics installers. > >Are they generally bozos or brainiacs (or something in the middle)? > > From CEOs to floorsweeps, they come in all flavors. I kinda expected that. What I was really getting at is, can they handle putting terminators on the connectors at the ends of the buss or are they more likely to ignore that requirement? Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 16, 1999
From: "Stefan B." <stefan.balatchev(at)wanadoo.fr>
Subject: Re: shielded vs. unshielded twisted pair
Belden has a special DeviceBus (DeviceNet or Honeywell SDS - so CAN-oriented) cables - 3082A, 3083A, 3084A, 3085A, 3086A and 3087A. This information is from their 1995 catalog. These cables have two shielded individually pairs - power supply pair and a data pair. The DeviceNet cable has also an additional general shield. Stefan Balatchev ________________________________________________________________________________
Date: Dec 17, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Java CAN simulator update
I've begun modifying the Flight Simulator code that Dave kindly contributed. The design is starting to get really interesting because of the extensive use of threads. Threads, for the uninitiated are also known as "lightweight processes" which are autonomous bits of code, sort of like small programs which run independently of each other, but at the same time are all controlled by their mother Java program. In the simulator, we can launch a thread for each sensor on the CAN network that we want to simulate. This way, we can start to see how various sensor module behaviors can affect the overall system good or bad. These sensor threads won't have to "invent" their data, rather, they can take a peek at the flight simulator information that Dave's original program generates when it "flies." Dave made a nice java class called flightEnvironment that makes this simple to do. Yet another thread monitors all of the messages that each sensor pumps out and ensures that the network adheres to the simulated bus's speed limit. The last thread will be one that we can actually use with few modifications in the final product. It monitors the CAN dataframes as they appear on the simulated network and communicates that information back to Dave's flight instruments, completing the loop. Marlin ________________________________________________________________________________
Date: Dec 17, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: CAN Kingdom "King" software
Anybody know if there is source code available for a "King?" It makes sense to have the "main display" also run the king. My reasoning is that the main display in the cockpit is going to have the most sophisticated processing power and the king will need a lot of processing power--at least it will tax the typical MCU. Note: Dissenting opinions and reasonings are welcome here. I'm starting to develop some Java software to simulate the CAN network and I will want to start integrating the king code soon. Although I'm doing this work in Java, I realize that any existing king software is going to be in C or C++. That's OK, I'll be ahead of the game if all I have to do is convert it. ________________________________________________________________________________
Date: Dec 17, 1999
From: dab(at)froghouse.org
Subject: Re: Lon
On 16 Dec, Stefan B. wrote: > You could try these URL's for pricing and samples: > > http://www.national.com/pf/CO/COP888EB.html > > http://www.national.com/pf/CO/COP884BC.html > > http://www.national.com/pf/CO/COP87L88EB.html > > http://www.national.com/pf/CO/COP87L84BC.html Careful. These only support CAN 2.0B passive. The word "passive" is the gotcha. That means they won't crash when they get 29-bit tags but they won't receive or transmit them either. I'm pretty sure we're going to end up wanting 29-bit tags. -Dave ________________________________________________________________________________
Date: Dec 17, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Kingdom "King" software
> >It makes sense to have the "main display" also run the king. My >reasoning is that the main display in the cockpit is going to have the >most sophisticated processing power and the king will need a lot of >processing power--at least it will tax the typical MCU. >Note: Dissenting opinions and reasonings are welcome here. I agree with you 100%. Processing power is cheap. I was originally thinking of a pretty powerful processor in each MFD, at least the equivalent of a Pentium II but probably a Motorola PowerPC chip. We want it to be able to do display updating at at least a 15 updates/second rate for the display. People like things that look analog. >I'm starting to develop some Java software to simulate the CAN network >and I will want to start integrating the king code soon. > >Although I'm doing this work in Java, I realize that any existing king >software is going to be in C or C++. That's OK, I'll be ahead of the >game if all I have to do is convert it. Frankly I like Java and Dave's work makes it attractive but we are going to want to make this fly at some point in time and the FAA is NOT going to buy off on Java. We just don't have enough control over the libraries unless we want to go back and review/rewrite them to ensure they are suitable for life-critical processes. OTOH, Java and C++ are sufficiently close that there *might* be some possibility to do some code reuse down the road. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 17, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: fixed vs. floating point calculations
I was browsing for something else and found a web site that talks about using fixed-point (integer and BCD) calculations instead of floating point calculations in uPs used for process control applications. See: http://www.noga.de/legOS/ if you are interested in this subject. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: fixed vs. floating point calculations
Date: Dec 17, 1999
While we're on the subject, Jack Crenshaw has written at least one book on this. Must reading if you're doing embedded process control stuff. -----Original Message----- I was browsing for something else and found a web site that talks about using fixed-point (integer and BCD) calculations instead of floating point calculations in uPs used for process control applications. See: http://www.noga.de/legOS/ if you are interested in this subject. ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN Kingdom "King" software
Date: Dec 17, 1999
Marlin, All, -----Original Message------------------------------------------------ From: Marlin Mixon <myshkin(at)worldnet.att.net> Date: Friday, December 17, 1999 1:51 AM Subject: Avionics-List: CAN Kingdom "King" software >Anybody know if there is source code available for a "King?" David Purdy eluded to the fact that CDA101 C/C++ code written for the ST2000 remote control boat, etc. would be available. They are also currently working on aircraft target drones. CAD101 is a CAN Kingdom implementation right down our alley. See my post awhile back on CDA101 update. David said they were currently in the process of setting up a web sight for CDA101, etc. I'll try and get a hold of him and see what we have to do. to get it. >It makes sense to have the "main display" also run the king. My >reasoning is that the main display in the cockpit is going to have the >most sophisticated processing power and the king will need a lot of >processing power--at least it will tax the typical MCU. >Note: Dissenting opinions and reasonings are welcome here. Makes sense to me. By the way, did you know that once the net(Kingdom) is setup the King doesn't even have to be part of it's normal operation. > >I'm starting to develop some Java software to simulate the CAN network >and I will want to start integrating the king code soon. > >Although I'm doing this work in Java, I realize that any existing king >software is going to be in C or C++. That's OK, I'll be ahead of the >game if all I have to do is convert it. I plan to work in Pascal and C++ as much as possible. I've found embedded Pascal software systems which are compatible with Borland/Inprise products. If you like well documented, easy to read code, Pascal is hard to beat. John ________________________________________________________________________________
Date: Dec 18, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Kingdom "King" software
On Fri, 17 Dec 1999, J Livingston wrote: > >Although I'm doing this work in Java, I realize that any existing king > >software is going to be in C or C++. That's OK, I'll be ahead of the > >game if all I have to do is convert it. > > I plan to work in Pascal and C++ as much as possible. I've found embedded > Pascal software systems which are compatible with Borland/Inprise products. > If you like well documented, easy to read code, Pascal is hard to beat. Having done systems programming in Pascal, I found that it requires enough extensions that it really isn't standard Pascal anymore. It is more like C with Pascal syntax and the extensions bypass the strong type and boundary checking inherent in Pascal. For that reason I finally punted Pascal and switched to C. I think that we will also find that more people know C than know Pascal. But I still prefer Java if we can make it work. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "J Livingston" <jliving(at)erinet.com>
Subject: Re: CAN Kingdom "King" software
Date: Dec 19, 1999
-----Original Message----- From: Brian Lloyd <brian(at)lloyd.com> Date: Saturday, December 18, 1999 12:57 PM Subject: Re: Avionics-List: CAN Kingdom "King" software >Having done systems programming in Pascal, I found that it requires enough >extensions that it really isn't standard Pascal anymore. It is more like >C with Pascal syntax and the extensions bypass the strong type and >boundary checking inherent in Pascal. For that reason I finally punted >Pascal and switched to C. I think that we will also find that more people >know C than know Pascal. > >But I still prefer Java if we can make it work. C will probably work fine for low level programing, but I really would like an object oriented language for the more complex stuff that we are going to get into for the King (and other higher level modules) and its multi-function graphics display, etc. What do you think of Delphi/Pascal or C++Builder IDEs? Are there Java compilers that are efficient enough for the King? I would think C++ or Object Pascalwould be preferred? Would you really want to use Java for the little data modules? It probably would be a very good idea to try and do everything in one language with one IDE if at all possible; at least initially, in order to simplify our lives. I guess this will solve its self as we get down to specific hardware and software. I want to get started!!!! What data module chip/s? What software IDE C++ Builder, MS C ? What main computer OS: Windows CE? How do we want to download software to our microcontrollers? We need to reclarify our short term objectives. I think they should be to get starter kits out to our members. So why don't we try and identify some basic development kits and sources if they exist. Kits we need: Data module Kit for gathering analog and digital signals. Data module Kit for controlling actuators such as trim & autopilot etc. Main Graphics Multi-Funciton display. Secondary alphanumerics Multi-Function display. John ________________________________________________________________________________
Date: Dec 20, 1999
From: Greg Reid <gregreid(at)sympatico.ca>
Subject: AGATE
I'm sure y'all have seen this by now. I'm wondering how the Glass Cockpit ideas of this forum are related (or completely divorced) from this AGATE work? It would sure be nice if these new "AGATE compliant" instruments and sensors could also "plug in" to our homebuilt bus. :-) Greg Reid (I'll introduce myself in a follow-on append) NASA Hosts Conference On Avionics Standard Databus New Standard Could Lead To Lower-Cost "Plug-and-Play" Avionics In recent years we've seen computer manufacturers adopt "plug-and-play" data transfer standards to simplify and reduce costs for peripherals. Could a similar standard for GA avionics put a few more pennies in pilots' pockets some day? Earlier this month NASA Langley hosted a one-day meeting in Hampton, Va., to establish a databus standards working group under the Advanced General Aviation Transport Experiments (AGATE) program. Their primary goal will be to develop an open architecture, open standard databus that could reduce the manufacturing and installation costs for GA avionics in the future. Some of the potential players attending the meeting were Allied Signal/Honeywell, Rockwell Collins, Garmin, B.F. Goodrich Avionics, Avidyne, Archangel, Raytheon Aircraft, Cessna Aircraft, Textron Lycoming, and Advanced Creations. The meeting also addressed the work required for FAA certification of the new databus, and proprietary issues related to converting to an open standard format. According to NASA, the AGATE industry/government team has already spent $2.8 million conducting research into a low cost, high speed, bi-directional databus, producing a significant amount of technical data that will be shared with new members. Funding for future work will be provided by the AGATE alliance, with minimal NASA funds also available. Both NASA and the FAA are supporting deployment of the new databus technology and the certification effort, and are encouraging more companies to participate. The first working meeting of the new group is scheduled for Feb 3 & 4, 2000, in Kansas City, Mo. The AGATE alliance is open for membership to all U.S. companies, universities and non-profits in either Principal, Associate or Supporting member categories. Go to NASA's AGATE Web site http://agate.larc.nasa.gov to learn more about this interesting, and we hope, worthwhile effort to reduce the costs of GA avionics. ________________________________________________________________________________
Date: Dec 20, 1999
From: Greg Reid <gregreid(at)sympatico.ca>
Subject: New interested participant: Greg Reid
Hi all, I've been following this forum (in its daily Digest form) for a few weeks now -- ever since someone from this group made an append in rec.aviation.homebuilt to invite others. (Thanks.) I'm just starting work on a Vision homebuilt (http://www.visionaircraft.com) and hope very much to put a "glass cockpit" into it. Hence my interest in this group ... although it will likely be 2+ years before I'll actually do any wiring. By then, my hope is that this technology will be fairly commonplace -- and even more powerful and yet less expensive. I'll likely be mostly an interested bystander (i.e. reading much more than participating), although if I had the TIME to actively participate in another hobby, this is where I'd do it. This is very interesting stuff. :-) A bit of background (and how I might "fit in" here): I have my PPL, with about 250 hours, although I haven't flown much since selling my Arrow in '90. I live in Toronto and work for IBM on the C/C++ compiler back-end (which is also used for the High-performance Java compiler back-end). While my responsibilities are for the OS/390 (mainframe) compilers, the same optimizing back-end technology is also used for the PowerPC, Intel, Sparc, and several other platforms. Naturally, I'd be most comfortable if C/C++ was chosen for this glass cockpit work -- although I have to admit that my own C/C++ skills are not all that strong. (I must caution now that my opinions stated here are entirely my own and do not necessarily reflect those of IBM ... blah blah blah ... but seriously, I may need to watch what I say.) My thought is that I may be able to help with the actual compilation process of your C/C++ or Java code (on the platform(s) of your choice), and help shoot any bugs ... on my own personal time and equipment of course. Unfortunately I don't have much of the former! Oh, and I also like to dabble in electronics. I have 3 years of a 4-year EE degree ... a "personal matter" forced my withdrawl from the course, and since joining IBM, I've never felt the urge to go back and complete it. :-| Anyway, I can speak electronic-speak (tho' am very rusty) as well as bit'n'bytes. I'm also pretty good with a wrench, having rebuilt numerous engines of various types over the years (I'm 43). Greg Reid ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: New interested participant: Greg Reid
Date: Dec 20, 1999
Welcome Greg. We have discussed Agate plus we have been communicating with a couple of the Agate folks. I think we should keep an eye on Agate's progress, but the consensus here is that the bus they are choosing (LON bus right?) is not as open, nor accessible as CAN seems to be. Hopefully that will change later and GA will benefit. Marlin Mixon >From: Greg Reid <gregreid(at)sympatico.ca> >I've been following this forum (in its daily Digest form) for a few >weeks now -- ever since someone from this group made an append in >rec.aviation.homebuilt to invite others. (Thanks.) ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Software
Date: Dec 20, 1999
> C will probably work fine for low level programing, but I really would >like an object oriented language for the more complex stuff that we are >going to get into for the King (and other higher level modules) and its >multi-function graphics display, etc. > > What do you think of Delphi/Pascal or C++Builder IDEs? > <> > > It probably would be a very good idea to try and do everything in one >language with one IDE if at all possible; at least initially, in order to >simplify our lives. I guess this will solve its self as we get down to >specific hardware and software. I am thinking along similar lines... We could create some C++ classes which can run on either side of the bus... if we could virtualize the CAN interface, create well defined message objects, etc... As far as IDE's go, I would plan on writing code to the standard as much as possible... If we chose, for example, MS developer studio to write code for our King, using the MFC classes for the GUI, in addition to requiring windows on our King (which many of us DON'T want to do), we couldn't port this code over to our little microcontrollers... However, some common low level classes could be written where commonality is required (bus and messages), and integrated into whatever development environment is appropriate for the module being developed. 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: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: Introduction: Seth Fuller
Date: Dec 20, 1999
Hello All, > > I should introduce myself such as Greg Reid. I am a student pilot, less than 10 hrs, but > have been increasingly intrigued by the topics that I am receiving news on, > namely Avionics, Aerobatics, and Homebuilding. I come as a third generation > aviator, but have just now been able to afford to fly. I appreciate all of > your inputs and am learning quite allot, mostly I will be just a listener > but as an Electrical Engineer I hope to be able to supply input if at all > possible. > > Thanks, > Seth ________________________________________________________________________________
From: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: Reply to Instrumentation discussion
Date: Dec 20, 1999
Has anybody considered connecting these instruments over IEEE-488. This is a very well defined architecture. I'm not sure about the interface between this and the microcontroller but this type of instrumentation bussing has been going on for years. Now there is the question of speed? You guys would have to decide how much data you need and what clock speeds you require to make good decisions from. Then we could investigate the correct electrical architecture. Seth > C will probably work fine for low level programing, but I really would >like an object oriented language for the more complex stuff that we are >going to get into for the King (and other higher level modules) and its >multi-function graphics display, etc. > > What do you think of Delphi/Pascal or C++Builder IDEs? > <> > > It probably would be a very good idea to try and do everything in one >language with one IDE if at all possible; at least initially, in order to >simplify our lives. I guess this will solve its self as we get down to >specific hardware and software. I am thinking along similar lines... We could create some C++ classes which can run on either side of the bus... if we could virtualize the CAN interface, create well defined message objects, etc... As far as IDE's go, I would plan on writing code to the standard as much as possible... If we chose, for example, MS developer studio to write code for our King, using the MFC classes for the GUI, in addition to requiring windows on our King (which many of us DON'T want to do), we couldn't port this code over to our little microcontrollers... However, some common low level classes could be written where commonality is required (bus and messages), and integrated into whatever development environment is appropriate for the module being developed. 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 <<...>> <<...>> Seth A. Fuller Project Leader Custom Product Branch Mixed Signal Wireless 8505 Forest Lane, MS 8727 Dallas, TX 75243 (214)480-2933 (972)598-8991 Beeper s-fuller1(at)ti.com (wk) sethfuller(at)worldnet.att.net (hm) ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Software
Date: Dec 20, 1999
Steve, I don't know of any C++ compilers for the kind of chips we have been talking about for the "little" boxes. C++ is much more RAM hungry than C and these things only have a few kb of RAM. I don't see any way around that without significantly driving up the cost. Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Steven J. Devine Sent: Monday, December 20, 1999 1:16 PM Subject: Re: Avionics-List: Software I am thinking along similar lines... We could create some C++ classes which can run on either side of the bus... if we could virtualize the CAN interface, create well defined message objects, etc... As far as IDE's go, I would plan on writing code to the standard as much as possible... If we chose, for example, MS developer studio to write code for our King, using the MFC classes for the GUI, in addition to requiring windows on our King (which many of us DON'T want to do), we couldn't port this code over to our little microcontrollers... However, some common low level classes could be written where commonality is required (bus and messages), and integrated into whatever development environment is appropriate for the module being developed. Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 20, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: AGATE
> >I'm sure y'all have seen this by now. I'm wondering how the Glass >Cockpit ideas of this forum are related (or completely divorced) from >this AGATE work? It would sure be nice if these new "AGATE compliant" >instruments and sensors could also "plug in" to our homebuilt bus. :-) > >Greg Reid (I'll introduce myself in a follow-on append) > > >NASA Hosts Conference On Avionics Standard Databus > >New Standard Could Lead To Lower-Cost "Plug-and-Play" Avionics >> . . . . . . The AGATE alliance is >open for membership to all U.S. companies, universities and non-profits >in either Principal, Associate or Supporting member categories. Go to >NASA's AGATE Web site http://agate.larc.nasa.gov to learn more about >this interesting, and we hope, worthwhile effort to reduce the costs of >GA avionics. Thus far, I've personally seen little evidence that the grand consortium is doing much to revitalize general aviation. I'm working in the AGATE program at Raytheon (Beech) and if there's great progress being made anywhere, I'm unaware of it. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
Date: Dec 20, 1999
From: dab(at)froghouse.org
Subject: Re: CAN Kingdom "King" software
On 19 Dec, J Livingston wrote: > What do you think of Delphi/Pascal or C++Builder IDEs? Never used any of them. I'm stuck in the past with emacs as my "ide". I've been called a curmudgeon before. Can those IDEs even build for processors other than *86's? Can their debuggers work against an embedded platform? > Are there Java compilers that are efficient enough for the King? > I would think C++ or Object Pascalwould be preferred? Would you > really want to use Java for the little data modules? Sure, I'd love to use Java for the little data modules. Even though there's a JVM for the 68HC11, I don't think I will though because C would just be so much easier. > It probably would be a very good idea to try and do everything in > one language with one IDE if at all possible; at least initially, in > order to simplify our lives. I guess this will solve its self as we > get down to specific hardware and software. One thing to always remember. If we spec the bus and protocol, there's nothing at all requiring the different devices to be running code that has any commonality. Whoever builds each device can do it whatever way they're most comfortable with. On the other hand, one person or a group of people working together and building multiple devices would very likely find it easier to have some common code just to reduce the amount of work. > I want to get started!!!! Well, here are my suggestions then. > What data module chip/s? I decided one day that I'd look around and just pick one. It turned out not to be quite that simple but I finally decided that I'd go with one of the PIC's. I actually didn't pick which one but none of them have built in CAN controllers anyway. PIC (whatever's the name of the company that makes them) makes a CAN controller that communicates via an SPI interface. They also have A/D converters that talk over SPI so I was thinking that a little board with one of the microcontrollers, a CAN controller, and room for one or two (or maybe more) A/D converters would make a fine little data module. The PIC stuff seems to still be available in DIP packages so this makes this approach accessible to experimenter level people. > What software IDE C++ Builder, MS C ? As I said, I just use emacs and gcc. > What main computer OS: Windows CE? By "main computer" do you mean the MFD? By the time it gets to something installed in the panel, I wouldn't have any OS in it at all; just an event scheduler. I could see experimenting with whatever you've got though. > How do we want to download software to our microcontrollers? Back to the PIC. Since they're in DIP packages you can put a zero insertion force socket on a test board and use inexpensive programmers connected to a serial port on your development machine. That would work with either the flash or EPROM versions (or OTP versions too I suppose but that's not useful for experimenting). For flash versions, it might be possible to arrange for the chip to be programmable in place with a special cable. > Main Graphics Multi-Function display. Probably the easiest way to get started on this one is to just use a laptop. If the data module also has a serial port, a different software load makes it a bridge between the laptop and the CAN bus. A step up from that is to use a single board computer that's basically a PC clone, again with the data module playing bridge. Finding a suitable LCD might take some effort. One possible source here is the Panel PCs from Advantech. The displays are disappointingly dim but they are available as touch panels which might be interesting. http://www.advantech.com/products/panel_pc/ppc-60.htm If you wanted to get away from Intel based stuff Motorola has a fascinating new microcontroller called the MPC555. It's got a PowerPC core with 448KB flash, 26KB SRAM, 32 analog inputs, and two CAN interfaces on chip. It would be more hardware and software work than a PC clone of course. Here are a couple boards based around the chip: http://www.axman.com/cme555.htm http://www.wuerz-elektronik.com/MPC555.htm > Secondary alphanumerics Multi-Function display. Do you mean like one of those 4 line 20 character, serial alpha-numeric displays? An interesting idea. Those can be driven a lot more easily than a full up color LCD. -Dave ________________________________________________________________________________
From: "Marlin Mixon" <marlin_mixon(at)hotmail.com>
Subject: Re: Software
Date: Dec 21, 1999
I dunno, it may be that C++ is the way to go. It's certainly faster, but when we start talking MFC, we start to narrow down the operating system, don't we? (hint: that 'M' in MFC doesn't stand for multi-platform) What about X Windows? Is there anything there that would allow us to write in X and cross compile for different OS's? Marlin >From: "Steven J. Devine" <steve(at)tzogon.com> > > C will probably work fine for low level programing, but I really would > >like an object oriented language for the more complex stuff that we are > >going to get into for the King (and other higher level modules) and its > >multi-function graphics display, etc. > > > > What do you think of Delphi/Pascal or C++Builder IDEs? > > > ><> > > > > It probably would be a very good idea to try and do everything in one > >language with one IDE if at all possible; at least initially, in order to > >simplify our lives. I guess this will solve its self as we get down to > >specific hardware and software. > >I am thinking along similar lines... We could create some C++ classes >which can run on either side of the bus... if we could virtualize the CAN >interface, create well defined message objects, etc... > >As far as IDE's go, I would plan on writing code to the standard as much >as possible... If we chose, for example, MS developer studio to write code >for our King, using the MFC classes for the GUI, in addition to requiring >windows on our King (which many of us DON'T want to do), we couldn't port >this code over to our little microcontrollers... > >However, some common low level classes could be written where commonality >is required (bus and messages), and integrated into whatever development >environment is appropriate for the module being developed. > >Steve ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Software
Date: Dec 20, 1999
>I don't know of any C++ compilers for the kind of chips we have been >talking about for the "little" boxes. C++ is much more RAM hungry >than C and these things only have a few kb of RAM. I don't see any >way around that without significantly driving up the cost. Jeff, OK... screwed up the details, but the concept sill remains... we should build one library of standard C functions and structures for CAN interfacing and messaging... for the king, we can write a C++ wrapper aroud those functions if people want that sort of interface... the point was to write one common library, particularly for the messaging component... >I dunno, it may be that C++ is the way to go. It's certainly faster, >but when we start talking MFC, we start to narrow down the operating >system, don't we? (hint: that 'M' in MFC doesn't stand for multi- >platform) What about X Windows? Is there anything there that >would allow us to write in X and cross compile for different OS's? >Marlin > >By "main computer" do you mean the MFD? By the time it gets >to something installed in the panel, I wouldn't have any OS in it >at all; just an event scheduler. I could see experimenting with >whatever you've got though. >Dave (I just used Micro$oft's MFC to illustrate the point (and certainly don't want to use it in the system))... Marlin, I'm thinking more along the lines of what Dave is saying... we will have *SOME* sort of OS, but very minimal... we write the code for the display ourselves, and not depend on MS Windows, or X services... we're most likely talking about standard VGA controllers... they are easy to program, and graphics libraries are a dime a dozen... plenty of free libraries to assist in this... 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: Hungry Programmers
Date: Dec 20, 1999
I seem to be hearing noises that sound to me like a bunch of hungry application programmers wanting to tare into some code. Woe, steady boys! I'm hearing things like: I want to get started!!!! What main computer OS? What software IDE? What data module chip? What language? Etc. Let me make a few rash statements: OS? Who said we were going to use an OS? There sure as hell isn't going to be room for much of an OS in the little sensor boxes. It's not clear to me that there's much need for one in the display module either. It's not as though it's going to have a disk and a file system and all that. And let's get rid of this "main computer" talk. The whole point of the bus design is that there is no "main computer". After the system is configured, and the "King" code is dormant, we should be able to smash any one box with a hammer and have the rest of the system keep right on going. (visualize pink bunny) I think someone said something like "How do we boot up the sensor modules?". Huh... The code's all in EPROM, there's nothing to boot. If you mean how does the code get into the EPROM's, well, it depends on what chip we use. But what difference does that make to the design? There is no rotating memory in the system. This system will look nothing like a PC. (though we may use PCs to prototype some parts) It may well be that no two boxes use the same CPU. Some boxes may use more than one CPU. I don't even want to hear the words "garbage collector". An IDE is something that runs on each persons development system. It's not part of our system. I see no need to pick ONE. As long as we can each load each other's source files and generate hex files from which to burn EPROM's that's all the commonality we really need. (More might be handy, though) A Microchip PIC would be the worst choice for a sensor box CPU. (that'll light some flames). Ok, I've got my flame proof suit on, have at me. ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Software
Date: Dec 20, 1999
Steve, I understand what you're getting at, I think. It would nice to at least have common header files (".h") for the various processors. That would give us a way to get some semblance of configuration control. Common code is ifyer. For instance, what if some boxes are little endian and some are big endian? It can get ugly. Jeff -----Original Message----- >I don't know of any C++ compilers for the kind of chips we have been >talking about for the "little" boxes. C++ is much more RAM hungry >than C and these things only have a few kb of RAM. I don't see any >way around that without significantly driving up the cost. Jeff, OK... screwed up the details, but the concept sill remains... we should build one library of standard C functions and structures for CAN interfacing and messaging... for the king, we can write a C++ wrapper aroud those functions if people want that sort of interface... the point was to write one common library, particularly for the messaging component... ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Hungry Programmers (hee hee hee)
Date: Dec 20, 1999
Jeff... Have to admit, I got quite the chuckle reading this... (but I'm weird like that). >I seem to be hearing noises that sound to me like a bunch of >hungry application programmers wanting to tare into some >code. Woe, steady boys! Yah dude. >I'm hearing things like: > >I want to get started!!!! >What main computer OS? >What software IDE? >What data module chip? >What language? >Etc. > >Let me make a few rash statements: > >OS? Who said we were going to use an OS? I already covered this last message... agreed. >And let's get rid of this "main computer" talk. It's *A* display module people! Not the "main" computer, (especially considering the fact that I intend to have three (or more?))... (you can tell the true geeks because they nest their parenthesis(like me)). (I *HAVE* to get around to looking at this CAN Kingdonm stuff... can we have multiple kings? Or is one *THE* king? grr... not enough time...) >I think someone said something like "How do we boot up the sensor >modules?". Huh... The code's all in EPROM, there's nothing to boot. >If you mean how does the code get into the EPROM's, well, it depends >on what chip we use. sBut what difference does that make to the design? Yup yup! I was wondering if anyone else was thinking along this line... >There is no rotating memory in the system. Well, perhaps not in yours... that is up to the user... if I want to build in a CVR or FDR, I'll need permanent storage... >This system will look nothing like a PC. (though we may use PCs to >prototype some parts) Uhhh... I'm thinking that my display module will look like a PC... a lame laptop with a standard VGA screen and no real keyboard and certainly no mouse... >It may well be that no two boxes use the same CPU. >Some boxes may use more than one CPU. > >I don't even want to hear the words "garbage collector". *snicker* hee hee hee >An IDE is something that runs on each persons development system. It's not >part of our system. I see no need to pick ONE. As long as we can each load >each other's source files and generate hex files from which to burn EPROM's >that's all the commonality we really need. (More might be handy, though) Hmmm... might prove difficult? If we were to all be producing code for the modules (to burn eproms), then we would all need to have compilers which build to the target CPU... This is where the different experience and capabilities of the players comes in handy. I might be inclined to get a EPROM burner, and exchange coded EPROM's for ready to solder etched boards... >Ok, I've got my flame proof suit on, have at me. No flames from me... I may burst into hysterics, but not burst into flames... 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: Re: Software... Cowboys and Endians...
Date: Dec 20, 1999
>Steve, > >I understand what you're getting at, I think. It would nice to at least have >common header files (".h") for the various processors. That would give us a >way to get some semblance of configuration control. Common code is ifyer. >For instance, what if some boxes are little endian and some are big endian? >It can get ugly. One little, two little, three little endians... OK... just kidding... (in rare form tonight!) One thing we know for sure... the messages *on the bus* will all be consistent... so one data structure can be built to represent this... if there is code required to parse the message, and convert it to a native data type (such as byte ordering), that can be an included helper function in the library. ...isn't that what #defines are for? That's how we write "portable" code across different flavors of UNIX... you set certain #define's based on your local configuration... whatever, you get the idea... Steve Steven J. Devine, President, Consultant, TZOGON Enterprises Incorporated steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com http://www.tzogon.com/~steve/glass_cockpit http://www.tzogon.com/~steve/stolch801 ________________________________________________________________________________
Date: Dec 20, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: CAN Kingdom "King" software
> What do you think of Delphi/Pascal or C++Builder IDEs? > > Are there Java compilers that are efficient enough for the King? I would >think C++ or Object Pascalwould be preferred? Would you really want to use >Java for the little data modules? There was some talk not long ago of true Java compilers. I heard that someone was going to do a Java front-end for GCC thus allowing you to compile Java to object code. This eliminates dynamic extensions to code which is something we have discovered is very nice. Even so, our tests about 3 years ago put Java with JIT in the 70% performace realm relative to GCC. If you don't have 30% slack in your processor, you have probably underdesigned your system in the first place. > It probably would be a very good idea to try and do everything in one >language with one IDE if at all possible; at least initially, in order to >simplify our lives. I guess this will solve its self as we get down to >specific hardware and software. This is where protocols and interfaces are more important than specific software and hardware. You should be free to create any hardware running any software you want and still have it play on the network. Look at the Internet. It works in spite of the rather eclectic mix of Unix, Mac, Windoze, mainframes, and various smarter-than-the-average-bear process control whoopties. The model works. > I want to get started!!!! We need our best guess at protocols and messages first. >What data module chip/s? Which one do you like? >What software IDE C++ Builder, MS C ? You forgot Java. Even so, which one do YOU want to work with? >What main computer OS: Windows CE? Pardon me but someone just shoved a spoon down my throat. This has triggered my gag reflex. >How do we want to download software to our microcontrollers? Well, it might be nice if we could do it over the net. That should be part of our protocol suite, i.e. a firmware download protocol. >We need to reclarify our short term objectives. I think they should be to >get starter kits out to our members. So why don't we try and identify some >basic development kits and sources if they exist. It may make sense to do a pseudo system first. Dave's simulator is a perfect example of something that people can use now as a base without having to run custom hardware. All you need is a CAN interface and some driver software. We can play with code on our PCs. Here is a wacko idea: let's come up with a CAN-over-IP encapsulation so we can test across the Internet. That way if one developer comes up with a data source and another with a data sink, they can test each other's implementations over the net. >Kits we need: > >Data module Kit for gathering analog and digital signals. I know where this is being developed. >Data module Kit for controlling actuators such as trim & autopilot etc. We probably need a sim for this first. >Main Graphics Multi-Funciton display. Use your PC for now. >Secondary alphanumerics Multi-Function display. Use your PC for 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: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Hungry Programmers (hee hee hee)
Date: Dec 20, 1999
Steve, Glad to hear I'm at least entertaining. Know what you mean about the CAN Kingdom stuff. I've only skimmed it myself. I think there is only one King allowed, but he only has to be there during system configuration. Someone please correct me if I have this wrong. For data logging those flash modules that they sell for digital cameras are pretty cheap and drop proof. By "This system will look nothing like a PC" I meant in terms of software and look and feel. You're correct that we could steal some parts of laptop hardware designs. You said: "then we would all need to have compilers which build to the target CPU" ...Ur, um, well yeah. We will have to standardize on one compiler per target CPU. But the development environment in which we run that compiler is optional. Then you said: "This is where the different experience and capabilities of the players comes in handy. I might be inclined to get a EPROM burner, and exchange coded EPROM's for ready to solder etched boards..." You know, it's kinda hard to email those EPROM's. But seriously folks, depending on our chip choices, those may be EEPROM's embedded in flat pack CPU chips that are soldered to boards before they are programmed. This "in circuit programming" seems to be the trend these days in the embedded processor world. This is a detail we can cope with when we get there. I've been doing that kind of stuff most of my life, it's not a big deal. Jeff -----Original Message----- Jeff... Have to admit, I got quite the chuckle reading this... (but I'm weird like that). >I seem to be hearing noises that sound to me like a bunch of >hungry application programmers wanting to tare into some >code. Woe, steady boys! Yah dude. >I'm hearing things like: > >I want to get started!!!! >What main computer OS? >What software IDE? >What data module chip? >What language? >Etc. > >Let me make a few rash statements: > >OS? Who said we were going to use an OS? I already covered this last message... agreed. >And let's get rid of this "main computer" talk. It's *A* display module people! Not the "main" computer, (especially considering the fact that I intend to have three (or more?))... (you can tell the true geeks because they nest their parenthesis(like me)). (I *HAVE* to get around to looking at this CAN Kingdonm stuff... can we have multiple kings? Or is one *THE* king? grr... not enough time...) >I think someone said something like "How do we boot up the sensor >modules?". Huh... The code's all in EPROM, there's nothing to boot. >If you mean how does the code get into the EPROM's, well, it depends >on what chip we use. sBut what difference does that make to the design? Yup yup! I was wondering if anyone else was thinking along this line... >There is no rotating memory in the system. Well, perhaps not in yours... that is up to the user... if I want to build in a CVR or FDR, I'll need permanent storage... >This system will look nothing like a PC. (though we may use PCs to >prototype some parts) Uhhh... I'm thinking that my display module will look like a PC... a lame laptop with a standard VGA screen and no real keyboard and certainly no mouse... >It may well be that no two boxes use the same CPU. >Some boxes may use more than one CPU. > >I don't even want to hear the words "garbage collector". *snicker* hee hee hee >An IDE is something that runs on each persons development system. It's not >part of our system. I see no need to pick ONE. As long as we can each load >each other's source files and generate hex files from which to burn EPROM's >that's all the commonality we really need. (More might be handy, though) Hmmm... might prove difficult? If we were to all be producing code for the modules (to burn eproms), then we would all need to have compilers which build to the target CPU... This is where the different experience and capabilities of the players comes in handy. I might be inclined to get a EPROM burner, and exchange coded EPROM's for ready to solder etched boards... >Ok, I've got my flame proof suit on, have at me. No flames from me... I may burst into hysterics, but not burst into flames... 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: Software... Cowboys and Endians...
Date: Dec 20, 1999
Yup and yup. -----Original Message----- One thing we know for sure... the messages *on the bus* will all be consistent... so one data structure can be built to represent this... if there is code required to parse the message, and convert it to a native data type (such as byte ordering), that can be an included helper function in the library. ...isn't that what #defines are for? That's how we write "portable" code across different flavors of UNIX... you set certain #define's based on your local configuration... whatever, you get the idea... Steve ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: CAN Kingdom "King" software
Date: Dec 20, 1999
Brian, Tell me you're not seriously suggesting we use Java on the little boxes! Read my lips: no garbage collectors! I want code that I can prove works. Besides which you're doing well get a C compiler for those chips. I know there is a GNU Java front-end for GCC project. Last I heard it wasn't working yet. Lend me that spoon when you're done with it. This "download code over the net" talk is making me nervous. In an operational system, I don't want there to be any way to reprogram a module that doesn't involve unplugging it and unscrewing the lid. Even in a prototype environment this seems like doing it the hard way to me. That CAN-over-IP idea is not all that wacko. You said: "Data module Kit for gathering analog and digital signals. I know where this is being developed." Really? Is it a secret? What chip have "we" picked? Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Brian Lloyd Sent: Monday, December 20, 1999 6:37 PM Subject: Re: Avionics-List: CAN Kingdom "King" software > What do you think of Delphi/Pascal or C++Builder IDEs? > > Are there Java compilers that are efficient enough for the King? I would >think C++ or Object Pascalwould be preferred? Would you really want to use >Java for the little data modules? There was some talk not long ago of true Java compilers. I heard that someone was going to do a Java front-end for GCC thus allowing you to compile Java to object code. This eliminates dynamic extensions to code which is something we have discovered is very nice. Even so, our tests about 3 years ago put Java with JIT in the 70% performace realm relative to GCC. If you don't have 30% slack in your processor, you have probably underdesigned your system in the first place. > It probably would be a very good idea to try and do everything in one >language with one IDE if at all possible; at least initially, in order to >simplify our lives. I guess this will solve its self as we get down to >specific hardware and software. This is where protocols and interfaces are more important than specific software and hardware. You should be free to create any hardware running any software you want and still have it play on the network. Look at the Internet. It works in spite of the rather eclectic mix of Unix, Mac, Windoze, mainframes, and various smarter-than-the-average-bear process control whoopties. The model works. > I want to get started!!!! We need our best guess at protocols and messages first. >What data module chip/s? Which one do you like? >What software IDE C++ Builder, MS C ? You forgot Java. Even so, which one do YOU want to work with? >What main computer OS: Windows CE? Pardon me but someone just shoved a spoon down my throat. This has triggered my gag reflex. >How do we want to download software to our microcontrollers? Well, it might be nice if we could do it over the net. That should be part of our protocol suite, i.e. a firmware download protocol. >We need to reclarify our short term objectives. I think they should be to >get starter kits out to our members. So why don't we try and identify some >basic development kits and sources if they exist. It may make sense to do a pseudo system first. Dave's simulator is a perfect example of something that people can use now as a base without having to run custom hardware. All you need is a CAN interface and some driver software. We can play with code on our PCs. Here is a wacko idea: let's come up with a encapsulation so we can test across the Internet. That way if one developer comes up with a data source and another with a data sink, they can test each other's implementations over the net. >Kits we need: > > >Data module Kit for controlling actuators such as trim & autopilot etc. We probably need a sim for this first. >Main Graphics Multi-Funciton display. Use your PC for now. >Secondary alphanumerics Multi-Function display. Use your PC for now. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 20, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Kingdom "King" software
On Mon, 20 Dec 1999, Jeff Barlow wrote: > Tell me you're not seriously suggesting we use Java on the little boxes! > Read my lips: no garbage collectors! I want code that I can prove works. > Besides which you're doing well get a C compiler for those chips. I am not suggesting one way or another. That is why I am focusing on the wire protocols. That said, I happen to like Java. If you have a Java compiler you can change how memory is managed. Even so, we have done a lot of event-driven server programming with java. Frankly, once we allocate an object, we reuse it rather that throw it away. That pretty much eliminates the garbage collector ever running. We got tired of garbage collection putting spikes in the response time. Another way of putting it: "Java! It's not just a programming language; it's an adventure!" > I know there is a GNU Java front-end for GCC project. Last I heard it wasn't > working yet. I'm not surprised. Nothing ever happens as fast as you want it to. > Lend me that spoon when you're done with it. Just as soon as we define the virtual spoon passing protocol (VSPP). > This "download code over the net" talk is making me nervous. In an > operational system, I don't want there to be any way to reprogram a module > that doesn't involve unplugging it and unscrewing the lid. Even in a > prototype environment this seems like doing it the hard way to me. Most newer avionics boxes permit database downloads and some support software upgrades over a serial link. It is much nicer to be able to fix a problem by plugging new code into the box than by having to pull the box out of the aircraft. Once you have your avionics buss installed it is the logical channel for such upgrades. Sure you want some sort of sanity check the prevents an upgrade in-flight, of course. (Hey Ralph! Just hold that left turn until the FMS reboots after the upgrade.) > That CAN-over-IP idea is not all that wacko. I don't think so either. Actually I think it would be a REALLY useful tool. > You said: "Data module Kit for gathering analog and digital signals. I know > where this is being developed." Really? Is it a secret? What chip have "we" > picked? It doesn't matter since you probably won't get to fiddle with the guts. It will be a black box to you. If it happens sooner rather than later (sometimes we win) I will get the info here sooner rather than later. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 20, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Hungry Programmers (hee hee hee)
On Mon, 20 Dec 1999, Jeff Barlow wrote: > ...Ur, um, well yeah. We will have to standardize on one compiler per target > CPU. But the development environment in which we run that compiler is > optional. That might be nice but it shouldn't be mandatory. > > Then you said: "This is where the different experience and capabilities of > the players comes in handy. I might be inclined to get a EPROM burner, and > exchange coded EPROM's for ready to solder etched boards..." > > You know, it's kinda hard to email those EPROM's. I used to ship EPROMs in padded envelopes all the time. Use conductive styrofoam. It provides sufficient rigidity to protect the pins. PLCCs are even better; no pins to bend. > >OS? Who said we were going to use an OS? You need some sort of low-level executive that will handle starting processes, interprocess communications, and a way to generalize device interfacing. This sounds like an OS to me. Some people call this a real-time executive. Trying to build any sort of semi-complex software without one is like beating your head against a brick wall; it feels really good when you stop. > >And let's get rid of this "main computer" talk. > > It's *A* display module people! Not the "main" computer, (especially > considering the fact that I intend to have three (or more?))... It should be sufficiently general that you can move processing functions from one box to another. One of my failure modes has critical processing moving from one display to another automatically. This implies some sort of intermodule health monitoring. > (you can tell the true geeks because they nest their parenthesis(like me)). > > (I *HAVE* to get around to looking at this CAN Kingdonm stuff... can we > have multiple kings? Or is one *THE* king? grr... not enough time...) > > >I think someone said something like "How do we boot up the sensor > >modules?". Huh... The code's all in EPROM, there's nothing to boot. The modules should be autonomous if possible. > >If you mean how does the code get into the EPROM's, well, it depends > >on what chip we use. sBut what difference does that make to the design? If a box has flash and the equivalent to a boot ROM, you can force working code into it and reboot it to start the new code. This strikes me as being *really* useful. Imagine you discover you have a code problem but you are in the middle of nowhere. You land, whip out your cellphone, grab the fixed code from the author/vendor, upgrade the errant box, and take off again 30 minutes later. If you want to get really crazy and you have an in-flight telephone ... > Yup yup! I was wondering if anyone else was thinking along this line... > > >There is no rotating memory in the system. > > Well, perhaps not in yours... that is up to the user... if I want to build > in a CVR or FDR, I'll need permanent storage... Consider multiple flash modules. 96MB seems relatively common now. You can also get 1GB type-III PCMCIA disks. Tiny and capable of handling more G than you or your airplane. > >This system will look nothing like a PC. (though we may use PCs to > >prototype some parts) > > Uhhh... I'm thinking that my display module will look like a PC... a lame > laptop with a standard VGA screen and no real keyboard and certainly no > mouse... > >It may well be that no two boxes use the same CPU. > >Some boxes may use more than one CPU. > > > >I don't even want to hear the words "garbage collector". > > *snicker* hee hee hee Hey, it is just another algorithm and data structure. It may prove very useful in some aspects of the design. Let's not get too religious here. (Except XML which is just evil. : ) Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: CAN Kingdom "King" software
Date: Dec 20, 1999
Brian, Java is just not the sort of adventure I want to take flying. What do you mean by: "you probably won't get to fiddle with the guts". I'm an EE, fiddling with the guts is what I do. I don't believe in black boxes. What in hell are you talking about, anyway? Dave's PIC project? Jeff -----Original Message----- Another way of putting it: "Java! It's not just a programming language; it's an adventure!" > You said: "Data module Kit for gathering analog and digital signals. I know > where this is being developed." Really? Is it a secret? What chip have "we" > picked? It doesn't matter since you probably won't get to fiddle with the guts. It will be a black box to you. If it happens sooner rather than later (sometimes we win) I will get the info here sooner rather than later. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Hungry Programmers (hee hee hee)
Date: Dec 20, 1999
Brian, For clarity I've prefixed my comments (below) with "===" Jeff -----Original Message----- On Mon, 20 Dec 1999, Jeff Barlow wrote: > ...Ur, um, well yeah. We will have to standardize on one compiler per target > CPU. But the development environment in which we run that compiler is > optional. That might be nice but it shouldn't be mandatory. === Ok, let me try again, all I was trying to say was that all the code in any one ROM image has to come out of one compiler. That is unless you can find two that have the same rules for stack layout, calling conventions, etc. > > > You know, it's kinda hard to email those EPROM's. I used to ship EPROMs in padded envelopes all the time. Use conductive styrofoam. It provides sufficient rigidity to protect the pins. PLCCs are even better; no pins to bend. === email, I say Email, It's a joke, son. > >OS? Who said we were going to use an OS? You need some sort of low-level executive that will handle starting processes, interprocess communications, and a way to generalize device interfacing. This sounds like an OS to me. Some people call this a real-time executive. Trying to build any sort of semi-complex software without one is like beating your head against a brick wall; it feels really good when you stop. === Well, to be sure, I at least WANT some sort of RTOS. I'm just worried that some are thinking of something like WinCE. <--pun alert. Also, you'll have a very hard time trying to wedge an RTOS into a low end PIC, for instance. If a box has flash and the equivalent to a boot ROM, you can force working code into it and reboot it to start the new code. This strikes me as being *really* useful. Imagine you discover you have a code problem but you are in the middle of nowhere. You land, whip out your cellphone, grab the fixed code from the author/vendor, upgrade the errant box, and take off again 30 minutes later. If you want to get really crazy and you have an in-flight telephone ... === Please tell me you're just kidding! I at least want a jumper on the board to disable this "feature". > >I don't even want to hear the words "garbage collector". > > *snicker* hee hee hee Hey, it is just another algorithm and data structure. It may prove very useful in some aspects of the design. Let's not get too religious here. (Except XML which is just evil. : ) === Repeat after me: "Non-deterministic code doesn't belong in airplanes". I'll vote against XML if you vote against garbage collection. ________________________________________________________________________________
Date: Dec 21, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: MCU programming
Display modules will require a powerful processor, that much is agreed. For them third generation languages like C, C++ or Java makes sense. Now, the Sensor modules, OTOH, will be running on MCUs. Unless I'm really naive here, I can't imagine a sensor having more than, say, three pages of assembly code because all the program needs to do is poll the A/D ports and convert them to real-world units and encode them into CAN ( [sensor id] [data value] ) and put the dataframes onto the bus. It would also poll the counter ports and encode them as well. Then it might enter a timing loop and finally start at the top again. Any hidden complexities there? Also, I agree with Jeff about storing the code for each MCU on a local EPROM. I assume that this means if power is interrupted for whatever reason, the MCUs can be back to work in less than a second, right? Note the above disregards the complexities of interracting with the king. Marlin ________________________________________________________________________________
Date: Dec 21, 1999
From: Marlin Mixon <myshkin(at)worldnet.att.net>
Subject: Pink Bunny
"Jeff Barlow" wrote: > we should be able to smash any one box with a hammer and have the > rest of the system keep right on going. (visualize pink bunny) Does that mean we're going to call this project "pink bunny" with a logo consisting of a pair of dark glasses perhaps? Marlin ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: MCU programming
Date: Dec 20, 1999
Marlin, Well, I think the code will end up a bit bigger than three pages of assembly, but I think you've got the general idea right. The timing will end up being driven by interrupts from the CAN controller and the A/D, etc. The CPU may spend most of the time halted, waiting for an interrupt. They should be alive within milliseconds after power on. For an example of the sort of chip I would like to use see: http://www.fujitsu-fme.com/products/micro/can/03.html Jeff -----Original Message----- From: owner-avionics-list-server(at)matronics.com [mailto:owner-avionics-list-server(at)matronics.com]On Behalf Of Marlin Mixon Sent: Monday, December 20, 1999 10:36 PM Subject: Avionics-List: MCU programming Display modules will require a powerful processor, that much is agreed. For them third generation languages like C, C++ or Java makes sense. Now, the Sensor modules, OTOH, will be running on MCUs. Unless I'm really naive here, I can't imagine a sensor having more than, say, three pages of assembly code because all the program needs to do is poll the A/D ports and convert them to real-world units and encode them into CAN ( [sensor id] [data value] ) and put the dataframes onto the bus. It would also poll the counter ports and encode them as well. Then it might enter a timing loop and finally start at the top again. Any hidden complexities there? Also, I agree with Jeff about storing the code for each MCU on a local EPROM. I assume that this means if power is interrupted for whatever reason, the MCUs can be back to work in less than a second, right? Note the above disregards the complexities of interracting with the king. Marlin ________________________________________________________________________________
Date: Dec 21, 1999
From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
Subject: Re: MCU programming
Marlin Mixon wrote: > Now, the Sensor modules, OTOH, will be running on MCUs. Unless I'm > really naive here, I can't imagine a sensor having more than, say, three > pages of assembly code because all the program needs to do is poll the > A/D ports and convert them to real-world units and encode them into CAN > ( [sensor id] [data value] ) and put the dataframes onto the bus. It > would also poll the counter ports and encode them as well. Then it > might enter a timing loop and finally start at the top again. I think a couple of pages of C might be nearer the mark... there's the business of handling incoming commands and so on. Also things like a watchdog timer, initialisation code, etc. But this does depend on how smart a particular module is going to be and this leads to a philosophical design point; are we going to have one module reading all 4 CHTs (for example), or one module for each? A 4-into-1 CHT measuring module is going to be more complex than a 1-to-1 module obviously. > Also, I agree with Jeff about storing the code for each MCU on a local > EPROM. Do we want to add a layer of complexity by storing code in Flash memory... i.e. reprogrammable in situ? Just playing Devil's Advocate here; I tend to think not. In fact, I'd go for a single-chip controller with on-board ROM and RAM. Do we want to download calibration constants and suchlike to the unit? If so, store it in EEPROM or Flash? Or just download at start-up? > I assume that this means if power is interrupted for whatever > reason, the MCUs can be back to work in less than a second, right? You tell us! :-) How long can you live without an altimeter? A VSI? An ASI? A CHT? My actual feeling is that almost always I'd be OK if it came back within 10 seconds. OTOH, I see no particular difficulty with meeting your 'back in one second' spec. Frank. ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Pink Bunny
Date: Dec 21, 1999
>> we should be able to smash any one box with a hammer and have the >> rest of the system keep right on going. (visualize pink bunny) > >Does that mean we're going to call this project "pink bunny" with >a logo consisting of a pair of dark glasses perhaps? I like it... the Pink Bunny Glass Cockpit project... I'll have the wife draw up the logos... we can paint it on the side of the cowl (though I'll have to cover up some of the hot rod style flames). Steve :) ________________________________________________________________________________
Date: Dec 21, 1999
From: dab(at)froghouse.org
Subject: Re: Hungry Programmers
On 20 Dec, Jeff Barlow wrote: > Ok, I've got my flame proof suit on, have at me. It's not that bad. I only half disagree with one thing you said and want clarification of another. > I don't even want to hear the words "garbage collector". This is the one I half disagree with. The reason I like garbage collection is it eliminates something like half the bugs in a complex program (where complex is defined in this case as actually allocating and discarding memory regularly). In fact, some studies have shown garbage collection to be faster than the same algorithms coded using the malloc and free library functions (which may really be more of an indictment of the general poor quality of malloc and free). It's only a half disagrement because it's just so damned easy to do GC wrong and have it be a pig. > A Microchip PIC would be the worst choice for a sensor box > CPU. (that'll light some flames). No reason to flame but I do want to know why you think this. To me it was just another microcontroller. So what's wrong with the little buggers? -Dave ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Kingdom "King" software
> >Brian, > >Java is just not the sort of adventure I want to take flying. Have you written and debugged software with it? Our experience is that using java tends to result in programs that have fewer bugs. Its performance is good too. If you constrain the library, it can be relatively compact. >What do you mean by: "you probably won't get to fiddle with the guts". I'm >an EE, fiddling with the guts is what I do. I don't believe in black boxes. Yes you do. You already treat a microprocessor as a black box. Do you treat a PC motherboard as a bunch of chips or do you treat the motherboard as a component? I bet you use potted modules and monolithic power supplies as "black boxes." What we accept as a "component" varies with our current point of view. >What in hell are you talking about, anyway? Dave's PIC project? I should have kept my mouth shut. There is a possibility that a module will become available that does analog data collection that provides that data on a CAN buss. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Hungry Programmers (hee hee hee)
> >Brian, > >For clarity I've prefixed my comments (below) with "===" > >Jeff > >-----Original Message----- > > >On Mon, 20 Dec 1999, Jeff Barlow wrote: > >> ...Ur, um, well yeah. We will have to standardize on one compiler per >target >> CPU. But the development environment in which we run that compiler is >> optional. > >That might be nice but it shouldn't be mandatory. > >=== Ok, let me try again, all I was trying to say was that all the code in >any one ROM image has to come out of one compiler. That is unless you can >find two that have the same rules for stack layout, calling conventions, >etc. That is obvious but I was thinking on a macro scale where we are working with multiple modules. We may choose different tools to build the different modules. I think that people are diving too deeply into this right now. We need an overall interconnection architecture before we can dive in and start to build anything. If nothing else we need to at least agree that we are going to use CAN and CAN Kingdom with the protocols and messages that entails. >> You know, it's kinda hard to email those EPROM's. > >I used to ship EPROMs in padded envelopes all the time. Use conductive >styrofoam. It provides sufficient rigidity to protect the pins. PLCCs >are even better; no pins to bend. > >=== email, I say Email, It's a joke, son. Duh. I read that as "mail" not "email." Never mind. : ) >> >OS? Who said we were going to use an OS? > >You need some sort of low-level executive that will handle starting >processes, interprocess communications, and a way to generalize device >interfacing. This sounds like an OS to me. Some people call this a >real-time executive. Trying to build any sort of semi-complex software >without one is like beating your head against a brick wall; it feels >really good when you stop. > >=== Well, to be sure, I at least WANT some sort of RTOS. I'm just worried >that some are thinking of something like WinCE. <--pun alert. Also, you'll >have a very hard time trying to wedge an RTOS into a low end PIC, for >instance. A nonpreemptive scheduler using shared memory and semaphores for IPC can be very, very small. This assumes that the processes are burned into the final system image so you don't need loader functions. > > >If a box has flash and the equivalent to a boot ROM, you can force working >code into it and reboot it to start the new code. This strikes me as >being *really* useful. Imagine you discover you have a code problem but >you are in the middle of nowhere. You land, whip out your cellphone, grab >the fixed code from the author/vendor, upgrade the errant box, and take >off again 30 minutes later. If you want to get really crazy and you have >an in-flight telephone ... > >=== Please tell me you're just kidding! I at least want a jumper on the >board to disable this "feature". I was half-kidding about the upgrades in-flight but the rest is very real. The system should be upgradable in the field without a forklift or even a screwdriver. A technician should be able to plug into the buss in order to troubleshoot and upgrade the system on the ground. Sure we should have interlocks to prevent someone from yanking the system out from under you while you are using it but it shouldn't be a jumper. I might give you a keylock switch somewhere but that is just an input to the software. > > >> >I don't even want to hear the words "garbage collector". >> >> *snicker* hee hee hee > >Hey, it is just another algorithm and data structure. It may prove very >useful in some aspects of the design. Let's not get too religious here. >(Except XML which is just evil. : ) > >=== Repeat after me: "Non-deterministic code doesn't belong in airplanes". >I'll vote against XML if you vote against garbage collection. As I pointed out, the tendency should be toward preallocation and reuse of resources without needing to rely on recovery of released resources, i.e. roughly translated, "avoid using garbage collection." But I can see times when I have two mutually exclusive functions on the same component that get used at different times. When I am done with function 1 and invoke function 2, I probably want to deallocate the memory and device resources allocated to function 1 so that function 2 may use them. This is a form of "garbage collection." It is very real and has a place in this system. It doesn't necessarily violate non-determinism in the code. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: CAN Kingdom "King" software
Date: Dec 21, 1999
Brian, Actually, I do tend to think of a PC motherboard as a bunch of chips. I've never bought one yet without looking to see what chips it's using for what. I started out working with tube circuits; my mind tends to operate at a very low level of detail. That's not to say I recommend that point of view, drives me nuts sometimes. Ooh... very hush, hush. -----Original Message----- >What do you mean by: "you probably won't get to fiddle with the guts". I'm >an EE, fiddling with the guts is what I do. I don't believe in black boxes. Yes you do. You already treat a microprocessor as a black box. Do you treat a PC motherboard as a bunch of chips or do you treat the motherboard as a component? I bet you use potted modules and monolithic power supplies as "black boxes." What we accept as a "component" varies with our current point of view. >What in hell are you talking about, anyway? Dave's PIC project? I should have kept my mouth shut. There is a possibility that a module will become available that does analog data collection that provides that data on a CAN buss. ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: MCU programming
> >Display modules will require a powerful processor, that much is agreed. >For them third generation languages like C, C++ or Java makes sense. > >Now, the Sensor modules, OTOH, will be running on MCUs. Unless I'm >really naive here, I can't imagine a sensor having more than, say, three >pages of assembly code because all the program needs to do is poll the >A/D ports and convert them to real-world units and encode them into CAN >( [sensor id] [data value] ) and put the dataframes onto the bus. It >would also poll the counter ports and encode them as well. Then it >might enter a timing loop and finally start at the top again. > >Any hidden complexities there? Yes. You want some sort of watchdog that will reinitialize the module if it becomes comatose. You might also want to overlap the data collection, processing, and data transmission (I am reaching a bit here but I would rather be conservative). You might want a listener to allow you to modify the sampling rates under user control from a remote device. >Also, I agree with Jeff about storing the code for each MCU on a local >EPROM. I assume that this means if power is interrupted for whatever >reason, the MCUs can be back to work in less than a second, right? I don't think that anyone was ever implying that the box would want to remote boot although that would be a really nice option for getting the box on its feet the first time. I do want a way to download new code to a box remotely. Every box should have sufficient flash that you can have two complete copies of code residing in flash concurrently. The box is running one image out of flash while downloading a new image to the other half of the flash (this implies that the flash may be erased a piece at a time). The last thing you change is the pointer that identifies the active image. This mechanism will allow one to interrupt a download and reboot the system and guarantee that it will reboot with a valid image. >Note the above disregards the complexities of interracting with the >king. Right. This is just plain old good design practice. I deal with this sort of thing all the time. In big networks, I need to be able to upgrade the network piecemeal while the network is still running. I may never be able to "reboot" the whole network all at once. As avionics systems get more complex and begin to look more like large datacomm networks, they are going to need the same sorts of features. 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: Glen_Worstell(at)notes.seagate.com
Date: Dec 21, 1999
Subject: language
> I plan to work in Pascal and C++ as much as possible. I've found embedded Pascal software systems which are compatible with Borland/Inprise products. If you like well documented, easy to read code, Pascal is hard to beat. I plan to use Pascal for my initial CAN experiments on the Atmel micros. I am a big fan of Modula-II, but don't know of any implementations on micros. g. ________________________________________________________________________________
From: Glen_Worstell(at)notes.seagate.com
Date: Dec 21, 1999
Subject: uP for CAN experiments
I previously posted: > I don't yet know enough to campaign for any particular solution, but I am about > ready to order some CAN stuff for experimentation. I have not yet ordered > because > there are so many different suppliers to choose from, and I want to make a > good choice. The Motorola MC68HC912BC32 looks really nice, but it isn't the > cheapest. > Someone responded with the url's for some National Semiconductor parts, that are all ROM or OTP. A requirement for me is Flash or EPROM. After some hours of surfing, I have selected the Atmel AVS series, and ordered a development kit. Cheap, available, flash, nice instruction set, nice range of part sizes and costs. Also-rans: PIC - very available but the instruction set is not as nice. Wanted to use because the company is so hobbyist friendly. Motorola 68HC12 - not available in cheap packages, and somewhat difficult to get. TI MSP - my first choice for architecture, but very difficult to get. Indications are that the flash parts really don't exist. For the CAN controller, I plan to try the one from the PIC folks. Have not yet tried to order one. Curious what others are using... g. ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Reply to Instrumentation discussion
> >Has anybody considered connecting these instruments over IEEE-488. This is >a very well defined architecture. I'm not sure about the interface between >this and the microcontroller but this type of instrumentation bussing has >been going on for years. Now there is the question of speed? You guys >would have to decide how much data you need and what clock speeds you >require to make good decisions from. Then we could investigate the correct >electrical architecture. We have been beating on this for some time now. I suggest you go back and read the archives. We have more or less converged on the CAN buss and the vehicle for moving bits around. 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: language
Date: Dec 21, 1999
Glen, I can't believe it! There are two of us? I love Modula II. John -----Original Message----- From: Glen_Worstell(at)notes.seagate.com <Glen_Worstell(at)notes.seagate.com> Date: Tuesday, December 21, 1999 1:59 PM Subject: Avionics-List: language > >> I plan to work in Pascal and C++ as much as possible. I've found embedded >Pascal software systems which are compatible with Borland/Inprise products. >If you like well documented, easy to read code, Pascal is hard to beat. > >I plan to use Pascal for my initial CAN experiments on the Atmel micros. I am a >big fan of Modula-II, >but don't know of any implementations on micros. > >g. > > ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Hungry Programmers
Date: Dec 21, 1999
Dave, Gee, it sure is hard to stir up trouble, here. My main problem with garbage collectors is that they tend to be a crutch to make sloppy code with memory leaks sort of work anyway. (You said "eliminates ", I say "hides") I don't much care for malloc and free either, for that matter. Let me back up a little and make sure we're all on the same page here. First of all I assume we are only talking about the display boxes here. The little sensor boxes aren't likely to have enough RAM in them to handle that kind of overhead, anyway. Second, I assume we'll be running the displays under some sort of lightweight prioritized preemptive RTOS. In that environment any sort of global (across processes) dynamic memory allocation tends to stir up a lot of priority inversion and deadlock problems. Adding GC to that typically makes matters worse since it runs in a low priority process. There are ways around that, but they add even more complexity. Maybe I'm just old fashioned, but I like dedicated, per process (or per priority level) memory allocation. That way, when you don't have enough RAM to run well, you can tell right away. Obviously, things like intertask message buffers must come from a global pool. (Well, not necessarily...) Here is what I see happening: We will have a lot of folks, with various levels of experience on real time systems, writing code. They will each do some kind of module level testing with appropriate stubs. At that point some of this code that appears to work will still have reentrancy bugs, memory leaks, and such like. The "real" debugging will happen when we start to do system integration. Things will sort of work, till we crank up the load on the system. Then we will start to see: stack blowouts, deadlocks, tasks that seem to hit performance walls, etc. Much of this seems inevitable, it goes with the territory. (BTDT) My experience has been that if you keep the memory allocation as straightforward and deterministic as possible it makes this system level debugging much less painful. I attribute at least half of my gray hair to this sort of debugging. On the PIC issue I will first quote myself from a prior message: > Considering the way the bus design is going, I don't think we're going > to get very far with a real low end (i.e. PIC) "sensor box" > processor. It could be done, I'm think, but I fear the effort would > be a little too painful. > > There are C compilers available for these things, but the chip > architecture forces them to generate very inefficient code. That, > combined with the limited memory available, limits what can be done > in C to fairly trivial projects. (Don't even think about C++, Java, etc.). > > I have used these chips (and Z80's, 8085's, and even older things) > to do some fairly tricky stuff, but that has always been with very tight > assembly code. I personally don't aspire to do any more of that "hand > polishing each bit" sort of coding. > Trying to do that sort of thing in the context of a geographically > diffuse group project would be a recipe for frustration. It will do > us no good to have a real cheap box if the firmware is never done. To get an idea of a reasonable alternative take a look at: http://www.fujitsu-fme.com/products/micro/can/03.html I have the CDROM with the C compiler, etc. on it and I'm currently trying to chase down some sample chips. I keep you posted. Jeff -----Original Message----- On 20 Dec, Jeff Barlow wrote: > Ok, I've got my flame proof suit on, have at me. It's not that bad. I only half disagree with one thing you said and want clarification of another. > I don't even want to hear the words "garbage collector". This is the one I half disagree with. The reason I like garbage collection is it eliminates something like half the bugs in a complex program (where complex is defined in this case as actually allocating and discarding memory regularly). In fact, some studies have shown garbage collection to be faster than the same algorithms coded using the malloc and free library functions (which may really be more of an indictment of the general poor quality of malloc and free). It's only a half disagrement because it's just so damned easy to do GC wrong and have it be a pig. > A Microchip PIC would be the worst choice for a sensor box > CPU. (that'll light some flames). No reason to flame but I do want to know why you think this. To me it was just another microcontroller. So what's wrong with the little buggers? ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Hungry Programmers (hee hee hee)
Date: Dec 21, 1999
Brian, I think you must have more faith in hardware than I do. I don't even trust an EEPROM not to erase itself spontaneously. I have seen it happen! I really do want that jumper. You can leave it off yours if you want. Re the memory allocation issue, see my reply to Dave. Jeff -----Original Message----- I was half-kidding about the upgrades in-flight but the rest is very real. The system should be upgradable in the field without a forklift or even a screwdriver. A technician should be able to plug into the buss in order to troubleshoot and upgrade the system on the ground. Sure we should have interlocks to prevent someone from yanking the system out from under you while you are using it but it shouldn't be a jumper. I might give you a keylock switch somewhere but that is just an input to the software. > > >> >I don't even want to hear the words "garbage collector". >> >> *snicker* hee hee hee > >Hey, it is just another algorithm and data structure. It may prove very >useful in some aspects of the design. Let's not get too religious here. >(Except XML which is just evil. : ) > >=== Repeat after me: "Non-deterministic code doesn't belong in airplanes". >I'll vote against XML if you vote against garbage collection. As I pointed out, the tendency should be toward preallocation and reuse of resources without needing to rely on recovery of released resources, i.e. roughly translated, "avoid using garbage collection." But I can see times when I have two mutually exclusive functions on the same component that get used at different times. When I am done with function 1 and invoke function 2, I probably want to deallocate the memory and device resources allocated to function 1 so that function 2 may use them. This is a form of "garbage collection." It is very real and has a place in this system. It doesn't necessarily violate non-determinism in the code. ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: uP for CAN experiments
Date: Dec 21, 1999
Glen, Take a look at: http://www.fujitsu-fme.com/products/micro/can/03.html Jeff -----Original Message----- I previously posted: > I don't yet know enough to campaign for any particular solution, but I am about > ready to order some CAN stuff for experimentation. I have not yet ordered > because > there are so many different suppliers to choose from, and I want to make a > good choice. The Motorola MC68HC912BC32 looks really nice, but it isn't the > cheapest. > Someone responded with the url's for some National Semiconductor parts, that are all ROM or OTP. A requirement for me is Flash or EPROM. After some hours of surfing, I have selected the Atmel AVS series, and ordered a development kit. Cheap, available, flash, nice instruction set, nice range of part sizes and costs. Also-rans: PIC - very available but the instruction set is not as nice. Wanted to use because the company is so hobbyist friendly. Motorola 68HC12 - not available in cheap packages, and somewhat difficult to get. TI MSP - my first choice for architecture, but very difficult to get. Indications are that the flash parts really don't exist. For the CAN controller, I plan to try the one from the PIC folks. Have not yet tried to order one. Curious what others are using... ________________________________________________________________________________
Date: Dec 21, 1999
From: dab(at)froghouse.org
Subject: Hungry Programmers
On 21 Dec, Jeff Barlow wrote: > Gee, it sure is hard to stir up trouble, here. Good thing it's so much fun. > My main problem with garbage collectors is that they tend to be a > crutch to make sloppy code with memory leaks sort of work > anyway. (You said "eliminates ", I say "hides") I don't much care > for malloc and free either, for that matter. Actually, I look at it as letting the computer handle garbage collection rather than the programmer. > Let me back up a little and make sure we're all on the same page here. > > First of all I assume we are only talking about the display boxes here. The > little sensor boxes aren't likely to have enough RAM in them to handle that > kind of overhead, anyway. I'm willing to accept that. Even with a JVM available for the 68HC11, I was mainly thinking about the larger systems like a display. > Second, I assume we'll be running the displays under some sort of > lightweight prioritized preemptive RTOS. I make no such assumption. Though if the display code was written in Java, the language itself sort of comes with a lightweight, prioritized, preemptive threads package. We're not required to use it though. > In that environment any sort of global (across processes) dynamic > memory allocation tends to stir up a lot of priority inversion and > deadlock problems. Adding GC to that typically makes matters worse > since it runs in a low priority process. There are ways around that, > but they add even more complexity. Those are good reasons not to run a prioritized, preemptive RTOS. I like non-prioritized, non-preemptive event schedulers myself. Very simple, very small, very easy to understand. They do have the problem that the whole program needs to be designed to work together. Piecemeal work is likely to have bad interactions. > [Examples of the many problems of manual memory management.] > My experience has been that if you keep the memory allocation as > straightforward and deterministic as possible it makes this system > level debugging much less painful. I attribute at least half of my > gray hair to this sort of debugging. It's interesting that the problems you bring up are exactly why I'm intrigued by garbage collected languages and systems. Write the garbage collector right once, and then you don't have to worry about those class of problems anymore. It's pretty nice. Of course the real world is never so simple, that's why garbage collectors are still somewhat unusual. > On the PIC issue I will first quote myself from a prior message: Sorry, I guess I missed it the first time. You're right that they are very limited little processors. > To get an idea of a reasonable alternative take a look at: > > http://www.fujitsu-fme.com/products/micro/can/03.html Looks like nice stuff. The only concern I'd have is we either have to find someone making a single board computer with these processors on them or we've got to build our own. These are surface mount only chips and for now that's beyond my hardware ability. Any volunteers? > I have the CDROM with the C compiler, etc. on it and I'm currently > trying to chase down some sample chips. I keep you posted. I'm very interested in what you find out. -Dave ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: uP for CAN experiments / modules
Date: Dec 21, 1999
Since a good portion of the group seems to be focusing on the microprocessors, perhaps we should build a table listing the attributes of the various processors mentioned, and add it to the hardware pages. Some items to consider... cost, clock speed, instruction set, built in interfaces, RAM, ROM, ability to obtain pre-made SBC's, compiler options, etc... as well as some freeform text noting any other pros/cons or other special considerations. Once the data starts flowing, I will compile this into a table on the hardware page... Once we have a firmer grasp on thew requirements for each module, we will have an easier time selecting the appropriate part for the job... Steve (again with the 130 message inbox... got to find some way of making sense of this and updating the web site) 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: Hungry Programmers
Date: Dec 21, 1999
Dave, See === lines Jeff -----Original Message----- On 21 Dec, Jeff Barlow wrote: > My main problem with garbage collectors is that they tend to be a > crutch to make sloppy code with memory leaks sort of work > anyway. (You said "eliminates ", I say "hides") I don't much care > for malloc and free either, for that matter. Actually, I look at it as letting the computer handle garbage collection rather than the programmer. === Last time I looked your average programmer was still smarter that your average computer. > Let me back up a little and make sure we're all on the same page here. > > First of all I assume we are only talking about the display boxes here. The > little sensor boxes aren't likely to have enough RAM in them to handle that > kind of overhead, anyway. I'm willing to accept that. Even with a JVM available for the 68HC11, I was mainly thinking about the larger systems like a display. > Second, I assume we'll be running the displays under some sort of > lightweight prioritized preemptive RTOS. I make no such assumption. Though if the display code was written in Java, the language itself sort of comes with a lightweight, prioritized, preemptive threads package. We're not required to use it though. > In that environment any sort of global (across processes) dynamic > memory allocation tends to stir up a lot of priority inversion and > deadlock problems. Adding GC to that typically makes matters worse > since it runs in a low priority process. There are ways around that, > but they add even more complexity. Those are good reasons not to run a prioritized, preemptive RTOS. I like non-prioritized, non-preemptive event schedulers myself. Very simple, very small, very easy to understand. They do have the problem that the whole program needs to be designed to work together. Piecemeal work is likely to have bad interactions. === It's a group project, not a one man show. "Piecemeal work" is going to be the name of the game. Also non-preemptive event schedulers have terrible performance in terms of interrupt latency. (I've done both) > [Examples of the many problems of manual memory management.] > My experience has been that if you keep the memory allocation as > straightforward and deterministic as possible it makes this system > level debugging much less painful. I attribute at least half of my > gray hair to this sort of debugging. It's interesting that the problems you bring up are exactly why I'm intrigued by garbage collected languages and systems. Write the garbage collector right once, and then you don't have to worry about those class of problems anymore. It's pretty nice. Of course the real world is never so simple, that's why garbage collectors are still somewhat unusual. === Gee, I guess that's another assumption that I should have stated. I'm thinking of this as a real world project, not just hanger flying. > On the PIC issue I will first quote myself from a prior message: Sorry, I guess I missed it the first time. You're right that they are very limited little processors. > To get an idea of a reasonable alternative take a look at: > > http://www.fujitsu-fme.com/products/micro/can/03.html Looks like nice stuff. The only concern I'd have is we either have to find someone making a single board computer with these processors on them or we've got to build our own. These are surface mount only chips and for now that's beyond my hardware ability. Any volunteers? === You software guys, you always want that predigested, ready to use hardware. Where's the fun in that? Actually surface mount is no harder to work with than thru hole, once you get used to it. You just use a smaller soldering iron and a big magnifying glass. You might as well get used to it, DIP's are on the way out. See http://www.twinhunter.com/Products/T_SMT_Prod.htm for SMT proto boards. I can solder a chip to one of these for you if need be. > I have the CDROM with the C compiler, etc. on it and I'm currently > trying to chase down some sample chips. I keep you posted. I'm very interested in what you find out. ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: Reply to Instrumentation discussion
Date: Dec 21, 1999
>>Has anybody considered connecting these instruments over IEEE-488... > >We have been beating on this for some time now. I suggest you go back >and read the archives. We have more or less converged on the CAN buss >and the vehicle for moving bits around. I really ought to keep the complete list of considered busses and such online... that way we can simple refer people to the web site for a summary of the prroject and current status... Steve (*still* behind in web site maintenance, but working on it) 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: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: Web Site
Date: Dec 21, 1999
Steve, I have just finished lurking through your site. I found my name up there and wanted to extend to you a thanks for having me on the team. I hope that I will be able to contribute a bit. At my former position, recently transferred to Texas Instruments, we use a UNIX based software called QNX. It was a real time operating system used to track satellites. Of course this was our application. Not being a Software Engineer, I am not going to stick my neck out too far but just submitting ideas. Most of our Software Engineers wrote code in a Visual C++ environment. Secondly, I am very familiar with the Trimble versions of GPS. I have particular experience with the Lassen SK-8. This is what we used to get our site local and altitude for the antennas. Do not use this receiver for altitude reporting as it is not differential and the accuracy is only about 50 ft. As far as location, it was excellent! It utilizes the standard 'egg' style of antenna and the total package is less than $1500.00 Well there is my two cents! Seth ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: CAN Kingdom "King" software
> >Brian, > >Actually, I do tend to think of a PC motherboard as a bunch of chips. I've >never bought one yet without looking to see what chips it's using for what. >I started out working with tube circuits; my mind tends to operate at a very >low level of detail. That's not to say I recommend that point of view, >drives me nuts sometimes. I started out with empty-state devices too. I have this variable view of what is the component level. Sometimes the motherboard is a bunch of chips and sometimes it is an opaque module. Brian Lloyd Lucent Technologies brian(at)lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax ________________________________________________________________________________
Date: Dec 21, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Hungry Programmers (hee hee hee)
> >I think you must have more faith in hardware than I do. I should hope so. I tend to fly single-engine aircraft a lot. >I don't even trust >an EEPROM not to erase itself spontaneously. I have seen it happen! I really >do want that jumper. You can leave it off yours if you want. If the hardware isn't reliable then this is all window dressing and we should quit now. I think we are talking more about software reliability than hardware 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: Glen_Worstell(at)notes.seagate.com
Date: Dec 22, 1999
Subject: three random comments
1) I intend to try to allow for the nodes on my experimental CAN network to be programmable over the network. I see no reason why this is not reasonable in an aircraft, as the programming (the way I will do it) would require connecting a PC to the network, something I'd do only on the ground. There is zero probabality that a node could accidently program another node, given that there will be some sort of protocol. My experimental network, btw, will not be in an a/c. 2) Steven J. Devine wrote: > ...Since a good portion of the group seems to be focusing on the microprocessors, perhaps we should build a table listing the attributes of the various processors mentioned, and add it to the hardware pages. > ...Once the data starts flowing, I will compile this into a table on the hardware page... Great idea. To minimize the noise on this forum I'll send my comments to Steven (except that I'll post a little one now:) 3) My selection of silicon for my experimental CAN network has been frustrating. I want something with flash or eprom, low cost but powerful enough, easy to get in small quantities, etc etc. So far I have not found anything exciting, except promises. A new contender on my list is the TMS320-F241. Anyone had experience with it? Meanwhile, continuing with Atmel and trying to find a stand-alone CAN controller that I can actually get. g. PS - my take on Java, garbage collection, RTOS, and all that is very pragmatic: I am comfortable with any or all of it, as long as it works and tests/analysis show it to be reliable. ________________________________________________________________________________
Date: Dec 22, 1999
From: dab(at)froghouse.org
Subject: Hungry Programmers
On 21 Dec, Jeff Barlow wrote: > === Gee, I guess that's another assumption that I should have stated. I'm > thinking of this as a real world project, not just hanger flying. That's an assumption we agree on and is also a middlin-fair criticism of garbage collection. -Dave ________________________________________________________________________________
Date: Dec 22, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: three random comments
> >1) I intend to try to allow for the nodes on my experimental CAN network >to be programmable over the network. This makes sense to me. A feature such as this will prove very useful during development and will be useful for upgrading a system in the field. If it scares you, don't use it but don't try to hamstring everyone else by eliminating the capability. >2) Steven J. Devine wrote: > >> ...Since a good portion of the group seems to be focusing on the >microprocessors, perhaps we should build a table listing the attributes of >the various processors mentioned, and add it to the hardware pages. > >> ...Once the data starts flowing, I will compile this into a table on the >hardware page... > >Great idea. To minimize the noise on this forum I'll send my comments to >Steven (except that I'll post a little one now:) I don't see why this shouldn't be open discussion on the list. >PS - my take on Java, garbage collection, RTOS, and all that is very >pragmatic: I am comfortable with any or all of it, as long as it works >and tests/analysis show it to be reliable. Ahh, I like this attitude. Sounds like you want to base you decisions on fact and test results rather than hearsay and innuendo. 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: RobertR237(at)aol.com
Date: Dec 22, 1999
Subject: Some Interesting Aviation Sized Computers
I found these four sites which have some very interesting products which fit our size and weight requirements for processors and drivers. Check them out and give your opinions. http://www.cellcomputing.com/ http://www.emjembedded.com/ http://wearables.stanford.edu/ http://www.jumptec.com/ They don't have any prices listed but look most interesting from a size, weight, and portability standpoint. The Embedded Systems site has some interesting A/D boards worth taking a look at. ============================================================= Bob Reed ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Inverter needed
Date: Dec 23, 1999
This is a bit off-topic (it's avionics but not glass cockpit related)... I've got hold of an Attitude Indicator (AH) which runs on 115V 400Hz and wondered if any of you clever people either have a circuit design or can come up with one for a 12V DC to 115V 400Hz inverter? There is apparently a commercial aviation version of these things, called a "peanut inverter", but I've not found one thus far. I'm obviously capable of building a small electronics project like this safely and to an appropriate standard for aviation (or I wouldn't ask or consider it), but have no skills to design one. I've also got an electric turn co-ordinator which needs 28V DC 200mA and want to do something about getting it going on 12V - I have a 12 V DC to 18.5V DC inverter (NEC Laptop computer car power adapter) which I could modify to produce 28V... I could draw the circuit of by following it's internals and get one of you EEs to look at that?). Maybe someone has a circuit to build one of these from scratch too? Joe Hovel ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Fw: DMU-AHRS
Date: Dec 22, 1999
-----Original Message----- From: Stephan Gallegos <sgallegos(at)xbow.com> Date: Wednesday, December 22, 1999 8:48 PM Subject: Re: DMU-AHRS Dear Matthew, Thank you for your message. The specifications for the DMU-AHRS can be downloaded from our website at www.xbow.com in the Products section. The price of the AHRS is $6,500. Regards, Stephan Gallegos Crossbow Tech. -----Original Message----- From: Matthew Mucker <mmucker(at)airmail.net> Date: Wednesday, November 10, 1999 10:35 AM Subject: DMU-AHRS >I'm a hobbyist interested in designing a 'glass cockpit' for my experimental >aircraft. I'm looking for a sensor that would give me pitch angle, roll >angle, and heading. It looks like the DMU-AHRS is what I'm after. > >I was wondering if I could get further technical information and the price >of this unit. > >Thanks, > >-Matthew Mucker > ________________________________________________________________________________
From: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: AHRS email
Date: Dec 22, 1999
All, I apologize for sending the last email before it was ready to hit the 'net. Anyway, you can see that Crossbow responded to my question about a month and a half after it'd been asked. Other than that, not much information that we don't already have! -Matt ======================== "I don't care what anybody says, there ARE user serviceable parts inside. " ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: AHRS email
Date: Dec 22, 1999
Matt, You've got to learn to stop using that "hobbyist" word. In sales rep language that translates to "I just want to waste your time; I'm not going to give you any money". They already know that 99 leads out of 100 are dead ends. That doesn't mean you are obligated to tell them up front that you are one of the 99. Jeff -----Original Message----- All, I apologize for sending the last email before it was ready to hit the 'net. Anyway, you can see that Crossbow responded to my question about a month and a half after it'd been asked. Other than that, not much information that we don't already have! -Matt ________________________________________________________________________________
Date: Dec 22, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Inverter needed
On Thu, 23 Dec 1999, Joe Hovel wrote: > > This is a bit off-topic (it's avionics but not glass cockpit related)... > I've got hold of an Attitude Indicator (AH) which runs on 115V 400Hz and > wondered if any of you clever people either have a circuit design or can > come up with one for a 12V DC to 115V 400Hz inverter? Do you need single phase or three phase? > There is apparently a commercial aviation version of these things, called a > "peanut inverter", but I've not found one thus far. I'm obviously capable of > building a small electronics project like this safely and to an appropriate > standard for aviation (or I wouldn't ask or consider it), but have no skills > to design one. Check with a gyro/instrument overhaul shop like The Gyro House in Auburn, CA. They might have what you need. > I've also got an electric turn co-ordinator which needs 28V DC 200mA and > want to do something about getting it going on 12V - I have a 12 V DC to > 18.5V DC inverter (NEC Laptop computer car power adapter) which I could > modify to produce 28V... I could draw the circuit of by following it's > internals and get one of you EEs to look at that?). Maybe someone has a > circuit to build one of these from scratch too? I used an eval kit from Maxim (http://www.maxim-ic.com). They make all kinds of analog and power supply chips. They have an eval kit on a little postage stamp sized circuit board. You need to change the output caps and the voltage sense divider but it will work. I used this to power my 28V attitude gyro in my RV-4. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: AHRS email
Date: Dec 23, 1999
>>>I'm a hobbyist interested in designing a 'glass cockpit'... >>> >>>I was wondering if I could get further technical information >>>and the price of this unit. >>> >>I apologize for sending the last email before it was ready to hit the >>'net. >> >>Anyway, you can see that Crossbow responded to my question >>about a month and a half after it'd been asked. Other than that, >>not much information that we don't already have! > >You've got to learn to stop using that "hobbyist" word. In sales >rep language that translates to "I just want to waste your time; >I'm not going to give you any money". They already know that >99 leads out of 100 are dead ends. That doesn't mean you >are obligated to tell them up front that you are one of the 99. Perhaps when dealing with suppliers/vendors, we should use language such as... ...I am representing a group of 20 software and electrical engineers... ...our design tem is working on the development of a glass cockpit project targeting the experimental/homebuilt aircraft market... etc... Never imply that you are acting alone... always represent a group or TEAM of folks with a common goal. Implication of larger sales when the project is completed successfully does not hurt either. 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: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: DC-DC Converter
Date: Dec 23, 1999
This is a bit off-topic (it's avionics but not glass cockpit related)... I've got hold of an Attitude Indicator (AH) which runs on 115V 400Hz and wondered if any of you clever people either have a circuit design or can come up with one for a 12V DC to 115V 400Hz inverter? There is apparently a commercial aviation version of these things, called a "peanut inverter", but I've not found one thus far. I'm obviously capable of building a small electronics project like this safely and to an appropriate standard for aviation (or I wouldn't ask or consider it), but have no skills to design one. I've also got an electric turn co-ordinator which needs 28V DC 200mA and want to do something about getting it going on 12V - I have a 12 V DC to 18.5V DC inverter (NEC Laptop computer car power adapter) which I could modify to produce 28V... I could draw the circuit of by following it's internals and get one of you EEs to look at that?). Maybe someone has a circuit to build one of these from scratch too? Joe Hovel First thing I would check would be Burr-Brown. They make DC-DC converters and have a very wide selection. If you just want to do it your self then remember you are performing a 'transformer' task and power in is equal to power out divided by the efficiency of your circuit. Example: 115V @ 20ma with a converter that is 87% efficient. You would need 2.64 watts in and at 12VDC you would have approximately 220mA in. Radio Shack has a good starter book on Buck-Boost Switching Converters. They usually use a 555 Timer and are simple, no more than one or two transistors. If you would like, I would be glad to take a look at your design once you are done. As well, I will look around for a design or two in my library. I'm a book nut! As far as using the Car Power Adapter, it should be fine, unmodified. Try to get the max and min voltage requirements of the instruments that you want to power and this will give you the design window that we will work in. As well, the max and min current requirements are a must. The voltage should be easy to create, we just don't want to overload any circuit protection devices upstream. I just moved to my present position from a power intensive design position so I should be able to help you with whatever you come up with. Thanks, Seth ________________________________________________________________________________
Date: Dec 23, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: Fw: DMU-AHRS
> > >-----Original Message----- >From: Stephan Gallegos <sgallegos(at)xbow.com> >To: mmucker(at)cyberramp.net >Date: Wednesday, December 22, 1999 8:48 PM >Subject: Re: DMU-AHRS > > >Dear Matthew, > >Thank you for your message. The specifications for the DMU-AHRS can be >downloaded from our website at www.xbow.com in the Products section. The >price of the AHRS is $6,500. FWIW, we're using a derivation of this product in the next production upgrade to the AQM-37 rocket powered target . . . hope to fly it late next year. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: RobertR237(at)aol.com
Date: Dec 23, 1999
Subject: Re: Inverter needed (list note)
In a message dated 12/23/99 6:45:27 AM Central Standard Time, steve(at)tzogon.com writes: > > > > > >This is a bit off-topic (it's avionics but not glass cockpit related)... > > That's sad... that we're hogging this list so much that people think > avionics questions are off topic... > > Perhaps we want to set up an alternate list for the Glass Cockpit project? > I do not want to flood this list to the point where people who are not > involved in the Pink Bunny Glass Cockpit project are afraid to ask other > questions and/or do not ask (or join) because the answer to their question > will be lost in all the noise... > > Not to be argumentative but I would suggest that we leave it alone and just make sure and include some general interest topics from time to time. The best thing you can do for any list is to KEEP IT ACTIVE! The Glass Cockpit discussion at least keeps an ongoing interest level that many lists lack. Now back to mostly lurking and learning...... Bob Reed KIS Cruiser in progress at: http://robertr237.virtualave.net/ ________________________________________________________________________________
From: RobertR237(at)aol.com
Date: Dec 23, 1999
Subject: Re: AHRS email
In a message dated 12/23/99 6:54:44 AM Central Standard Time, steve(at)tzogon.com writes: > > Perhaps when dealing with suppliers/vendors, we should use language such > as... > > ...I am representing a group of 20 software and electrical engineers... > > ...our design tem is working on the development of a glass cockpit project > targeting the experimental/homebuilt aircraft market... > > etc... > > Never imply that you are acting alone... always represent a group or TEAM > of folks with a common goal. > > Implication of larger sales when the project is completed successfully > does not hurt either. > > Steve > And, there is not a single word of deception in any of the above statements. You may in fact be understating the size of the team and the total interest. ________________________________________________________________________________
From: RobertR237(at)aol.com
Date: Dec 23, 1999
Subject: Re: DC-DC Converter
In a message dated 12/23/99 7:57:53 AM Central Standard Time, s-fuller1(at)ti.com writes: > > > This is a bit off-topic (it's avionics but not glass cockpit related)... > I've got hold of an Attitude Indicator (AH) which runs on 115V 400Hz and > wondered if any of you clever people either have a circuit design or can > come up with one for a 12V DC to 115V 400Hz inverter? > There is apparently a commercial aviation version of these things, called a > "peanut inverter", but I've not found one thus far. I'm obviously capable of > building a small electronics project like this safely and to an appropriate > standard for aviation (or I wouldn't ask or consider it), but have no skills > to design one. > > I've also got an electric turn co-ordinator which needs 28V DC 200mA and > want to do something about getting it going on 12V - I have a 12 V DC to > 18.5V DC inverter (NEC Laptop computer car power adapter) which I could > modify to produce 28V... I could draw the circuit of by following it's > internals and get one of you EEs to look at that?). Maybe someone has a > circuit to build one of these from scratch too? > > Joe Hovel > > First thing I would check would be Burr-Brown. They make DC-DC converters > and have a very wide selection. If you just want to do it your self then > remember you are performing a 'transformer' task and power in is equal to > power out divided by the efficiency of your circuit. Example: 115V @ 20ma > with a converter that is 87% efficient. You would need 2.64 watts in and at > 12VDC you would have approximately 220mA in. Radio Shack has a good starter > book on Buck-Boost Switching Converters. They usually use a 555 Timer and > are simple, no more than one or two transistors. If you would like, I would > be glad to take a look at your design once you are done. As well, I will > look around for a design or two in my library. I'm a book nut! As far as > using the Car Power Adapter, it should be fine, unmodified. Try to get the > max and min voltage requirements of the instruments that you want to power > and this will give you the design window that we will work in. As well, the > max and min current requirements are a must. The voltage should be easy to > create, we just don't want to overload any circuit protection devices > upstream. I just moved to my present position from a power intensive design > position so I should be able to help you with whatever you come up with. > > Thanks, > Seth > OK, I fear that I may be about to show my total ignorance regarding this but that's never stopped me before. You indicate that the attitude indicator uses 115 volts. I suspect that the 115 volts is subsequently transformed to something more in line with typical electronics using 5-6 volts DC. Instead of converting 12 v to 115 v to then be converted back, why not determine the required voltage for the circuitry and replace the current transformer with an appropriate one? NOW fire away all you electronic experts. I intend to learn from your flames. Bob Reed ________________________________________________________________________________
From: HornetBall(at)aol.com
Date: Dec 23, 1999
Subject: Re: Fw: DMU-AHRS
Careful gents. I've flight tested most of the Crossbow products, including the DMU-AHRS. They perform VERY POORLY in aircraft. Most sensors are plug and chug directly into aircraft. Attitude sensors are a different matter. If you want to try out an inexpensive attitude sensor, go for it. However, make sure that you put the purchase on a credit card and that you are in a position to fly the sensor very rapidly thereafter so that you have the power to return a sensor that works great on the ground but not at all in the air. I, for one, got stuck with a DMU-6VG a few years back. I have continued to flight test for Crossbow, hoping that they'll get it right, but I've always taken the sensors on loan since that time. Here's a link to a page that lists a lot of AHRS type sensors and manufacturers: http://www.cee.hw.ac.uk/~tena/ins/ Now, back to lurking. ________________________________________________________________________________
From: "Fuller, Seth" <s-fuller1(at)ti.com>
Subject: DC-DC Converter
Date: Dec 23, 1999
Bob, I have re-read the correspondence and it appears that his instrument takes an AC Voltage that requires a 115V 400Hz signal. I lumped this in with the DC-DC converters and was mistaken. Thanks for pointing that out. But in the same arena, he will need some type of switching converter that will look at the DC Signal coming in, Chop it at the appropriate frequency, filter out all of the unwanted harmonics and then boost the AC Signal to the required voltage. The major problem with this is that to boost 15 to 115 he will need some type of transformer either an Auto Transformer, or an Isolation Transformer. I would suggest, for size and efficiency considerations that he use a Toroidal, Auto Transformer. These types of transformers have a round core with less flux leakage. The Auto Transformer part shares a common ground/neutral with the incoming signal and can be sized smaller as there are not two separate windings. This type of transformer is always sized for the High Current side. What he is sounding like he is doing is operating some type of resolver winding inside that needs a reference voltage. Although I am not familiar with the internal workings of this instrument, by the description this sounds like the case. A resolver is basically a small, highly sensitive motor operating in the reverse, like a generator. Small movements in the armature/rotor will be translated to the field/stator windings as a voltage level difference. As I am writing you I am becoming more aware of his need. My former position was with RSI Precision Controls. We designed antenna servo systems used to track satellites. The antennas position reporting system was very critical as tracking 0.0016 degree movements was our goal. We used resolvers to do this. We had several that used 115V, 400Hz reference signals to excite the windings. Analog Devices has a complete book on Resolvers and Synchros. I don't think that before I understood the nature of his problem. We often had problems in that we would have drift in the reference signal phasing and this would throw off our readings, as the out going signal was compared to the generated reference. Hopefully Joe will not have to deal with any of these problems and he will only have to provide the voltage, but I would suggest that when he is creating this reference voltage that he takes into account frequency drift with temperature as well as efficiency drift over temperature. Both of which could affect the way that the device behaves and its ability to correctly report the attitude of the aircraft. All though a quick check with the manufacturer would tell him the min and max specifications of the voltage and Joe can determine from there how accurate he needs to be in creating the power source. If the specifications are too tight, such as a need for precision references in the switching circuit or Non-Linear Circuits devices then he may want to farm this out to a design house or just continue to look on the Web for a supplier. This could be easy or it could be extremely difficult. I will need to know the specs from the manufacturer on the power requirements to make a better decision. Joe, if you get this let me know what you know and I will try to help you. Seth In a message dated 12/23/99 7:57:53 AM Central Standard Time, s-fuller1(at)ti.com writes: > > > This is a bit off-topic (it's avionics but not glass cockpit related)... > I've got hold of an Attitude Indicator (AH) which runs on 115V 400Hz and > wondered if any of you clever people either have a circuit design or can > come up with one for a 12V DC to 115V 400Hz inverter? > There is apparently a commercial aviation version of these things, called a > "peanut inverter", but I've not found one thus far. I'm obviously capable of > building a small electronics project like this safely and to an appropriate > standard for aviation (or I wouldn't ask or consider it), but have no skills > to design one. > > I've also got an electric turn co-ordinator which needs 28V DC 200mA and > want to do something about getting it going on 12V - I have a 12 V DC to > 18.5V DC inverter (NEC Laptop computer car power adapter) which I could > modify to produce 28V... I could draw the circuit of by following it's > internals and get one of you EEs to look at that?). Maybe someone has a > circuit to build one of these from scratch too? > > Joe Hovel > > First thing I would check would be Burr-Brown. They make DC-DC converters > and have a very wide selection. If you just want to do it your self then > remember you are performing a 'transformer' task and power in is equal to > power out divided by the efficiency of your circuit. Example: 115V @ 20ma > with a converter that is 87% efficient. You would need 2.64 watts in and at > 12VDC you would have approximately 220mA in. Radio Shack has a good starter > book on Buck-Boost Switching Converters. They usually use a 555 Timer and > are simple, no more than one or two transistors. If you would like, I would > be glad to take a look at your design once you are done. As well, I will > look around for a design or two in my library. I'm a book nut! As far as > using the Car Power Adapter, it should be fine, unmodified. Try to get the > max and min voltage requirements of the instruments that you want to power > and this will give you the design window that we will work in. As well, the > max and min current requirements are a must. The voltage should be easy to > create, we just don't want to overload any circuit protection devices > upstream. I just moved to my present position from a power intensive design > position so I should be able to help you with whatever you come up with. > > Thanks, > Seth > OK, I fear that I may be about to show my total ignorance regarding this but that's never stopped me before. You indicate that the attitude indicator uses 115 volts. I suspect that the 115 volts is subsequently transformed to something more in line with typical electronics using 5-6 volts DC. Instead of converting 12 v to 115 v to then be converted back, why not determine the required voltage for the circuitry and replace the current transformer with an appropriate one? NOW fire away all you electronic experts. I intend to learn from your flames. Bob Reed ________________________________________________________________________________
Date: Dec 23, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: AC powered gyros (Was: DC-DC Converter)
There seems to be some misunderstanding as to why the gyros might need 115VAC at 400 Hz. AC tends to be used in the cockpit for two things: AC motors in gyros and angular resolvers. AC motors tend to be smaller and lighter. Also, you can transfer power by inductive coupling that requires no contacts with the concomitant friction that they cause. Even the 14VDC and 28VDC electric gyros that are popular today are really AC powered. They just have the inverter built into the case of the gyro. Solid state inverters have made this possible. The problem comes when you run across a gyro that needs three-phase power (not unusual). Building an inverter that accepts 14VDC and produces 115VAC, 400Hz, three-phase power is nontrivial. It will probably be a lot cheaper and easier to get a different gyro. I know because I ran into this problem myself a few years back. I finally gave up trying to build or find a three-phase inverter at a reasonable price and cut a deal with the local gyro shop to use my AC gyro as a trade-in and got a freshly-overhauled 28VDC powered attitude gyro for $700. I then made a 14V-to-28V upconverter using an upconverter eval kit from Maxim (http://www.maxim-ic.com). It worked pretty well but was a bit noisy electrically. If you go this route be sure to put the inverter in a small metal box with feed-through capacitors to keep the RF noise in check. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 23, 1999
From: Tim Shankland <tshank(at)megsinet.net>
Subject: Re: Inverter needed (list note)
Hi there, I've been receiving this list for about a month now and watching this project develop. I to am planing to put a "glass cockpit in the airplane I'm building but I am using a different philosophy. My plan included the small modules that have been discussed here each with enough smarts to do its job. I'm not sure yet if I'll use a bus structure, because honestly considering how small my plane will be I'm not sure if the savings in wire are worth the complexity. The major point where I differ is that I intend to run the whole thing with a laptop running Labview under Linus. The point is that with mass marketing it is impossible to custom build a computer that can compete at the price. I am trying to use parts for my aircraft project that have high volume production and competition, a suburu for the engine etc. The only part that of the computer I am planning to custom design is a LCD panel with push button switches. These will be connected directly to the laptop mounted out of sight. This way as new more powerful (and cheaper) computers become available swapping out will be a simple matter. I can tell by the tenor of this thread that some of you are itching to start building and programing. I have been designing electronic test equipment for the telecommunications industry for the part 25 years and still write many routines in C, but I have found that it is not worth my time to try and design a PC , they're just too cheap to buy. By the way with Labview I can put together some of the screens with all the dials gauges and buttons I see in ads for glass cockpits in minutes. Just my view of things Tim Shankland Lucent Technologies RobertR237(at)aol.com wrote: > > In a message dated 12/23/99 6:45:27 AM Central Standard Time, > steve(at)tzogon.com writes: > > > > > > > > > > >This is a bit off-topic (it's avionics but not glass cockpit related)... > > > > That's sad... that we're hogging this list so much that people think > > avionics questions are off topic... > > > > Perhaps we want to set up an alternate list for the Glass Cockpit project? > > I do not want to flood this list to the point where people who are not > > involved in the Pink Bunny Glass Cockpit project are afraid to ask other > > questions and/or do not ask (or join) because the answer to their question > > will be lost in all the noise... > > > > > > Not to be argumentative but I would suggest that we leave it alone and just > make sure and include some general interest topics from time to time. The > best thing you can do for any list is to KEEP IT ACTIVE! The Glass Cockpit > discussion at least keeps an ongoing interest level that many lists lack. > > Now back to mostly lurking and learning...... > > Bob Reed > KIS Cruiser in progress at: http://robertr237.virtualave.net/ > ________________________________________________________________________________
Date: Dec 24, 1999
From: "Robert L. Nuckolls, III" <nuckolls(at)aeroelectric.com>
Subject: Re: AC powered gyros (Was: DC-DC Converter)
>The problem comes when you run across a gyro that needs three-phase power >(not unusual). Building an inverter that accepts 14VDC and produces >115VAC, 400Hz, three-phase power is nontrivial. It will probably be a lot >cheaper and easier to get a different gyro. I know because I ran into >this problem myself a few years back. Years ago, I used to build and supply single phase, square wave, 400 Hz inverters to a local instrument shop for spinning up military surplus 3-phase gyros. One phase was tied directly to one side of the output. A capacitor was used in series with a second leg to the second phase. A resistor was tied from capacitor/inverter junction to the third motor phase. The quasi-three phase thus generated did not exhibit the most desired 120 degress phase shift between legs but it was enough to have the motor's rotor perceived rotation of the field in which it resides. The gyros took longer to spin up but ran only about 5% below the fully configured 3-phase speed. The resistor and capacitor had to be choosen for each type of motor . . . not sure if he used some means for measuring derived phase shift or just used a stopwatch on it to measure spin up time. This technique must have been successful . . . we built hundreds of these inverters for him. Bob . . . http://www.aeroelectric.com ________________________________________________________________________________
From: "Joe Hovel" <joe.hovel(at)med.monash.edu.au>
Subject: Mea culpa!
Date: Dec 25, 1999
Thank you all for your helpful comments and suggestions and leads to solve my power conversion problems for my odd and old instruments (12 to 28V DC & 12V DC to 115V AC 400Hz). I'm sorry that I didn't put the question to the list in the first place! I just thought everyone was pre-occupied with the "pink bunny" project.... but overlooked the learning opportunities for everyone else. I'll follow up your leads and will report on my progress. Seasons greetings to you all! Joe Hovel Australia ________________________________________________________________________________
From: "Your Name" <llbish(at)worldnet.att.net>
Subject: Please don't make another list!
Date: Dec 24, 1999
All, As a lurker (ignorant but interested!!) to this list I'd like to see it continue as it has... it's always possible to learn even when it seems over one's head. Sometime in the future it's possible something that's been written here will come back to me when I'm facing a problem. I don't think I'd feel intimidated and wouldn't ask a question of you all if I had a problem... re the one just asked about the horizion, etc. Thanks, Larry Bishop llbish(at)worldnet.att.net >Perhaps we want to set up an alternate list for the Glass Cockpit project? >I do not want to flood this list to the point where people who are not >involved in the Pink Bunny Glass Cockpit project are afraid to ask other >questions and/or do not ask (or join) because the answer to their question >will be lost in all the noise... > ________________________________________________________________________________
From: "Steven J. Devine" <steve(at)tzogon.com>
Subject: Re: DMU-AHRS
Date: Dec 27, 1999
> >Careful gents. I've flight tested most of the Crossbow products, >including the DMU-AHRS. They perform VERY POORLY in aircraft. <> >I have continued to flight test for Crossbow, hoping that they'll get it >right, but I've always taken the sensors on loan since that time. OK.. have you flight tested any others? Anything that performs well in this application? Any other items to avoid? Also, what was the problem with the xbow units? Anything that can be solved? Was it vibration related? Something that a decent mounting system might fix? Thanks for the heads-up. 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: Re: First Solo
Date: Dec 27, 1999
> > Well, it's not related to the Pink Bunny project... Hmmmm... it appears as though this name seems to have stuck... going to have to have someone draw up a logo... >...but nevertheless, this seems an appropriate forum in which to >announce that I made my first solo on Christmas day this year. Congrats! I just had mine earlier in December! Wow, your instructor worked on X-mas Day? > I had four of the sweetest touch-and-go landings you could ask for. Mine were nice and smooth as well... even got a go around due to prior landing traffic not clearing the runway... bonus! 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: "Matthew Mucker" <mmucker(at)airmail.net>
Subject: Audio question
Date: Dec 27, 1999
Okay, here's a non-pink-bunny question for everyone: 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. Any help is appreciated. Thanks, -Matt ======================== "I don't care what anybody says, there ARE user serviceable parts inside. " ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Audio question
On Mon, 27 Dec 1999, Matthew Mucker wrote: > > Okay, here's a non-pink-bunny question for everyone: > > 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. 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. You need to check your camcorder's input voltage level which will probably on the order of 1 mV to 10 mV. That means that you are stepping down from about on the order of 1V to on the order of 1mV which implies something like a 100-fold to 1000-fold reduction in voltage. A simple voltage divider will suffice. Here is the schematic: headphone output >------[ R1 ] ---+----------> camcorder input | R 2 | headphone ground >----------------+----------> camcorder ground The ratio of R1 to R2 sets your attenuation level. The sum matches the output impedence of the headphone jack. Since in this case the impedence match isn't all that critical we can be flexible about the values of R1 and R2. For instance, a value of 1000 ohm for R1 and 10 ohm for R2 would reduce the signal level by 100, i.e. 1V at the input becomes 10 mV at the output. If you need more signal decrease the value of R1. If you need less signal increase the value of R1. So what are you working on? Sounds like you are going to be doing some video taping in the cockpit. Will you be making a training video for something? Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: DMU-AHRS
On Mon, 27 Dec 1999, Steven J. Devine wrote: > >Careful gents. I've flight tested most of the Crossbow products, > >including the DMU-AHRS. They perform VERY POORLY in aircraft. > > OK.. have you flight tested any others? Anything that performs well in > this application? Any other items to avoid? The one that Collins adopted for their new AHRS come from Systron Donner. That implies that their sensors may be adapted to AHRS use. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: First Solo
On Mon, 27 Dec 1999, Matthew Mucker wrote: > > Well, it's not related to the Pink Bunny project, but nevertheless, this > seems an appropriate forum in which to announce that I made my first solo > on > Christmas day this year. Contratulations! Good Christmas present! Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Ham licenses
How many people here are hams? I am (WB6RQN), Steve Devine is (N1YZJ), and Dave Bridgham is (I forgot his callsign). Anyone else? Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
Date: Dec 28, 1999
From: Brian Lloyd <brian(at)lloyd.com>
Subject: Re: Audio question
On Tue, 28 Dec 1999, Brian Lloyd wrote: > > 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. Brian Lloyd brian(at)lloyd.com +1.530.676.6513 ________________________________________________________________________________
From: "Jeff Barlow" <barlow(at)thegrid.net>
Subject: Ham licenses
Date: Dec 28, 1999
Brian, Well... Many, many years ago I was (WB6CSV).

November 24, 1999 - December 28, 1999

Avionics-Archive.digest.vol-ab