Thread: [Opengc-devel] Linux Hardware
Status: Pre-Alpha
Brought to you by:
madmartigan
Menu
▾
▴
opengc-devel
|
From: John W. <ca...@mm...> - 2003-09-18 17:52:07
|
Hi,
Over the course of the last year I've been trying to find simulation =
hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support =
open source programs like FlightGear and OpenGC. All I could find was =
Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot =
of interest in developing stuff for open source software under Linux.
Well, I never followed the herd and was not about to move over to =
Windows or FSxxxx.
So I sat down and designed an interface board for the MCP and EFIS as =
starters. Turns out, the board is somewhat generic in that it takes =
rotary enconder data and key scan circuits and along with the Linux =
driver stuffs the data into a small file that the application can =
read/write. Using the board goes like this:
The board has a standard parallel port interface (I wanted to use =
IEEE1284 EPP but opted for the most common, simplest for the moment). It =
will run either on your printer port or any additional parallel port =
board (ISA or PCI) you care to install or I've got a custom ISA board =
with three programmable ports I used for development and testing.
Installing/using the board is standard Linux.
Compile the module driver -- source and makefiles will be provided
Create the device -> mknod /dev/mcp u 254 0
Install the modules -> insmod mcp.o
Create you application -> something like this
/**********************
main()
{
:
fd =3D open( "/dev/mcp", O_RDWR);
int result =3D read(fd, mesg, sizeof mcp_data);
// Convert from char string to data types
memcpy( char * &mcp_data, char * &mesg, sizeof mcp_data );
// Now do your application stuff whatever
:
:
close(fd);=20
}
*******************/
So if you were running a MCP panel the data would be airspeed, mach, =
heading, vvi, and altitude. Plus the state of the pushbutton switches on =
the panel which would go to the FMC for the appropriate action and =
control of the system autopilot(s) and such. Or you could configure it =
as a NAV/RADIO panel and process the data as frequencies. Or =
whatever.....=20
The board and driver run in kernel space and use an interrupt to process =
changes in the state of the connected panel
I'm still testing the board but getting close to a decision on moving =
from a breadboard to a PCB layout. Best guesstimate on cost is between =
$100 and $200. ( I have no idea on what the manufacturing costs beyond =
the production of the bare PCB look like, as always very dependent on =
size of the lot and quantity discounts for parts and amortization of =
start-up costs,etc,etc)
Trying to gauge the interest in such an item and welcome any feedback, =
questions, etc.
For a look at some of the hardware panels I plan to use check out =
http://www.a-g-t.com
Regards
John W.
|
|
From: Gene B. <ge...@de...> - 2003-09-18 18:06:18
|
On Thu, 18 Sep 2003, John Wojnaroski wrote: > Hi, > > Over the course of the last year I've been trying to find simulation > hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support > open source programs like FlightGear and OpenGC. All I could find was > Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot > of interest in developing stuff for open source software under Linux. John, you missed out on the Phidget (httpd://www.phidgets.com). There is a Linux driver available on SourceForge and someone has also done work on a Mac OSX version. It works very similar to EPIC, but is _vastly_ cheaper to use and more oriented to software developers. g. -- Proud Owner of 80-0007 http://www.f15sim.com |
|
From: John W. <ca...@mm...> - 2003-09-18 18:34:41
|
Hi Gene I looked at that site a while back, but again not convinced it meets the test. For example, how would you drive an array of 16 7-segment LEDs? OTH there are some items there that are interesting, but again did not see anything that would drive/interface to something like an MCP and EFIS panel as a single package. Have you used these products in your sim? Regards John W. ----- Original Message ----- From: "Gene Buckle" <ge...@de...> To: <ope...@li...> Sent: Thursday, September 18, 2003 11:16 AM Subject: Re: [Opengc-devel] Linux Hardware > > > On Thu, 18 Sep 2003, John Wojnaroski wrote: > > > Hi, > > > > Over the course of the last year I've been trying to find simulation > > hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support > > open source programs like FlightGear and OpenGC. All I could find was > > Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot > > of interest in developing stuff for open source software under Linux. > > > John, you missed out on the Phidget (httpd://www.phidgets.com). There is > a Linux driver available on SourceForge and someone has also done work on > a Mac OSX version. It works very similar to EPIC, but is _vastly_ cheaper > to use and more oriented to software developers. > > g. > > -- > Proud Owner of 80-0007 > http://www.f15sim.com > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel |
|
From: Gene B. <ge...@de...> - 2003-09-18 19:57:19
|
> I looked at that site a while back, but again not convinced it meets the > test. For example, how would you drive an array of 16 7-segment LEDs? OTH > there are some items there that are interesting, but again did not see > anything that would drive/interface to something like an MCP and EFIS panel > as a single package. > There is a 7 segment controller that will drive 8 digits each. I'm using one of them to handle my VHF radio panel. They're very easy to use and since they're USB, you can use as many as you need. (up to the USB max of course) > Have you used these products in your sim? > I currently use both EPIC and Phidgets in my sim. I'm using 1 of the 7 segment controllers as I mentioned as well as 3 of the 32/32 I/O boards and 1 of the 0/256/0 boards. I'm also using 2 of the 8 servo boards and 1 of the 4 servo boards for driving custom built gauges. The 7 segment controller can also be set up to drive 64 LEDs directly. You might want to check out http://www.737flightsim.com - David is using Phidgets exclusively with his project. If you have any questions about Phidgets, I'd be more than happy to help. g. |
|
From: John W. <ca...@mm...> - 2003-09-18 20:20:37
|
Hi Gene, > There is a 7 segment controller that will drive 8 digits each. I'm using > one of them to handle my VHF radio panel. They're very easy to use and > since they're USB, you can use as many as you need. (up to the USB max of > course) > Looked and looked; could not find the above mentioned item. Is there a part number? I do like that 0/256/0 prototyping kit. Will it handle static switches and momentary switches? Thanks for the input. Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-18 20:39:47
|
> > There is a 7 segment controller that will drive 8 digits each. I'm using > > one of them to handle my VHF radio panel. They're very easy to use and > > since they're USB, you can use as many as you need. (up to the USB max of > > course) > > > Looked and looked; could not find the above mentioned item. Is there a part > number? > It's called the PhidgetLED. I didn't spot it either - Chester may have not begun to sell them yet. > I do like that 0/256/0 prototyping kit. Will it handle static switches and > momentary switches? > It works just like the EPIC does. You can get it in a 16x16 matrix or an EPIC wiring-compatible 8x32 matrix. You use diodes just like in EPIC to isolate the switches. Both momentary and on/off switches can be used. g. |
|
From: John W. <ca...@mm...> - 2003-09-18 21:53:36
|
> > > I do like that 0/256/0 prototyping kit. Will it handle static switches and > > momentary switches? > > > It works just like the EPIC does. You can get it in a 16x16 matrix or an > EPIC wiring-compatible 8x32 matrix. You use diodes just like in EPIC to > isolate the switches. Both momentary and on/off switches can be used. > Not all that familiar with EPIC. Sounds like you are using Windows. And the software provided by phidget is windows based. so you either roll your own for Linux or make do with the stuff in sourceforge. I still like my board that drives 16 digits and runs in Linux kernel space on an interrupt basis. I never liked windows as an OS for simulation. As an engineer I like to know ALL the details and I don't think MS is going to release source any time soon... Is your Eagle a C or E model? Still living with steam gauges... ;-) Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-20 02:49:36
|
> > > Not all that familiar with EPIC. EPIC is a fairly high end solution due to the cost of the gear. It's not cheap. :) > Sounds like you are using Windows. And the software provided by phidget is > windows based. so you either roll your own for Linux or make do with the > stuff in sourceforge. > I'm using Windows for all my initial development work. Once I've got all the hardware done, I'll run both Windows & Linux. > I still like my board that drives 16 digits and runs in Linux kernel space > on an interrupt basis. I never liked windows as an OS for simulation. As an > engineer I like to know ALL the details and I don't think MS is going to > release source any time soon... > Well remember, FlightGear does run in Windows. :) > Is your Eagle a C or E model? Still living with steam gauges... ;-) > It's a C model. Everything with the exception of the MPCD, VSD and TEWS is steam. I got really lucky and nailed down a real HSI and a built-for-simulation-use ADI. All my hydraulic and engine guages are scratch built by a friend of mine and the others will be gutted and rebuilt, with the exception of the ADI and HSI. Those will eventually be driven "as designed". g. |
|
From: John W. <ca...@mm...> - 2003-09-20 17:58:15
|
> Well remember, FlightGear does run in Windows. :) > Well, I don't want to get into a flame war, however FG runs on windows because a few dedicated souls (like Curtis Olson) strive to make the program cross-platform compliant, and it's not always easy or fun... If you want to build a world-class simulator you need access to the OS internals and the ability to control hardware other than through the application layer. And peek and poke just don't cut it. But from what I've seen, the market is for hardware and interfaces to work with and in the windows environment so one either goes with the flow, sets their own course, or does without. Enjoyed the stories and pics on your website. These projects have a way of consuming us, don't they? ;-) Regards John W. |
|
From: John W. <ca...@mm...> - 2003-09-20 18:21:49
|
a quick addendum regards windows; check out http://www.beyondlogic.org/index.htm#DeviceDrivers might be helpful if your building your own boards JW |
|
From: Gene B. <ge...@de...> - 2003-09-20 18:23:49
|
> cross-platform compliant, and it's not always easy or fun... > Nothing worth doing ever is. I keep telling myself this every time I cut my hand or bust a knuckle working on the F-15. :0 > application layer. And peek and poke just don't cut it. > You keep referring to "peeking and pokeing". What are you referring to? No simulator that I've ever seen would use such a method. The closest I've seen is Falcon 4 using shared memory segments to expose a small data set to drive a master caution panel and some basic instruments. > But from what I've seen, the market is for hardware and interfaces to work > with and in the windows environment so one either goes with the flow, sets > their own course, or does without. > Well keep in mind that these guys are hackers at heart and if you can show them a need for other platform drivers they'll be happy to comply. > Enjoyed the stories and pics on your website. These projects have a way of > consuming us, don't they? ;-) Thanks. Yeah, it gets out of hand now and again. :) g. |
|
From: John W. <ca...@mm...> - 2003-09-21 00:10:44
|
> > Well keep in mind that these guys are hackers at heart and if you can show > them a need for other platform drivers they'll be happy to comply. > I talked with some of them, but doubt if a market of one is going to make anyone do somersaults... And the use of FG and open source stuff for building cockpits is either not reported or not happening... I suspect the latter Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-21 20:25:42
|
> > Well keep in mind that these guys are hackers at heart and if you can show > > them a need for other platform drivers they'll be happy to comply. > > > I talked with some of them, but doubt if a market of one is going to make > anyone do somersaults... And the use of FG and open source stuff for > building cockpits is either not reported or not happening... I suspect the > latter The lack of "amateur" use of FG is most likely due to the high barrier of entry (you _must_ know what you're doing) and the lack of cockpit oriented third party infrastructure. For instance, there is a LOT of cockpit support software available for MSFS that's made by Project Magenta. It's pretty high dollar software too. However, it sells itself because of how easy it is to configure and hook up to MSFS via network, etc. There are other packages out there that offer similar features for free as well. OpenGC provides a small subset as you know. For FlightGear to really take off as a core tool for the home cockpit builder, it has to be more widely supported by the user community. One thing that would prove to be a big boost to FlightGear's popularity would be FSUIPC support. All you'd have to do is set up a shared memory segment that Pete could get at with his software, and you'd instantly obtain 100% compatibility with all those cool add-ons that the MSFS folks enjoy. Even the Project Magenta stuff would work right out of the box for the most part. I wish I could do it myself but I don't have the time - I've got my hands full already. :) g. |
|
From: John W. <ca...@mm...> - 2003-09-21 22:37:33
|
> > The lack of "amateur" use of FG is most likely due to the high barrier of > entry (you _must_ know what you're doing) and the lack of cockpit oriented > third party infrastructure. > I like your use of the word "amateur" I was struggling to find the right expression. It's sorta a chicken and egg thing, provide the support and you'll have an audience that will justify the effort to produce the support > For instance, there is a LOT of cockpit support software available for > MSFS that's made by Project Magenta. It's pretty high dollar software > too. However, it sells itself because of how easy it is to configure and > hook up to MSFS via network, etc. There are other packages out there that > offer similar features for free as well. OpenGC provides a small subset > as you know. > I talked over a year ago with the Magenta folks and all it left in my mouth was a bad taste, what an arrogant bunch of SOBs and their stuff is not all THAT great. I've got stuff running derived from OpenGC which is a full 747 flightdeck with a functional FMC and better,as attested to by a few airline pilot types I've worked with. But (here's the catch) since Damion went off on a different direction with the OpenGC project it's become incompatible and I just don't have the time, talent or resources to set up a website and CVS server or try to sync up with X-Plane or FSxxx. It runs under Linux and networks with FG, and is just as easy to set up as FSUIPC and has a lot more potential and will remain free under the GPL license.. > For FlightGear to really take off as a core tool for the home cockpit > builder, it has to be more widely supported by the user community. > So true. the FG crowd is rather an ecclectic bunch (based mostly on the email one sees) and just no way of knowing who else is out there or were their interests lie. ATM the task(s) de jour seems to be building airplane models and cultural features. And it is becoming a little top-heavy. IMHO it needs a got technical thrashing by a couple of heavy-duty gearheads to improve performance and supportability. I think one of the big barriers is Linux itself. While the installation and support has improved dramatically over the past few years it still takes a little work to get it installed and running when things don't go as expected. Again MS has a lock on windows and can dictate how things work, so installation can be guaranteed while Linux has to be a little more "democratic" (small d, no reference to politics) and that can lead to a few mis-steps on occasion. Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-23 01:55:21
|
> > The lack of "amateur" use of FG is most likely due to the high barrier of > > entry (you _must_ know what you're doing) and the lack of cockpit oriented > > third party infrastructure. > > > I like your use of the word "amateur" I was struggling to find the right > expression. It's sorta a chicken and egg thing, provide the support and > you'll have an audience that will justify the effort to produce the support > Bingo. :) > I talked over a year ago with the Magenta folks and all it left in my mouth > was a bad taste, what an arrogant bunch of SOBs and their stuff is not all > THAT great. I've got stuff running derived from OpenGC which is a full 747 > flightdeck with a functional FMC and better,as attested to by a few airline > pilot types I've worked with. But (here's the catch) since Damion went off > on a different direction with the OpenGC project it's become incompatible > and I just don't have the time, talent or resources to set up a website and > CVS server or try to sync up with X-Plane or FSxxx. It runs under Linux and > networks with FG, and is just as easy to set up as FSUIPC and has a lot more > potential and will remain free under the GPL license.. > While you might have some really cool stuff running, if no one has heard that it's been done then how will they know they've got a choice? :) > So true. the FG crowd is rather an ecclectic bunch (based mostly on the > email one sees) and just no way of knowing who else is out there or were > their interests lie. ATM the task(s) de jour seems to be building airplane > models and cultural features. And it is becoming a little top-heavy. IMHO it > needs a got technical thrashing by a couple of heavy-duty gearheads to > improve performance and supportability. > The problem with FG right now is that they're concentrating on the "sexy" features and letting the back end slide a bit. Curt is helping cure this a bit with the recent aircraft tree reorg. g. |
|
From: John W. <ca...@mm...> - 2003-09-23 06:20:02
|
> > It runs under Linux and > > networks with FG, and is just as easy to set up as FSUIPC and has a lot more > > potential and will remain free under the GPL license.. > > > While you might have some really cool stuff running, if no one has heard > that it's been done then how will they know they've got a choice? :) > Well, I've been trying to get the word out, but have had very few takers. Posted a series of snapshots at the end of May, seemed to get a lot of hits on the site, but very few questions or "How do I get one of these?" So maybe it wasn't all that cool after all or those who saw it (assuming it's mostly the FG audience) just weren't interested. Once I get a little further along with the flightdeck I'll post a few more pics > The problem with FG right now is that they're concentrating on the "sexy" > features and letting the back end slide a bit. Curt is helping cure this > a bit with the recent aircraft tree reorg. > The network aspects could use a little work. Actually, the interface protocoils to FG are quite numerous but it requires a little more work than FSUIPC but with the plib library it's not all that difficult and well worth the effort. Regards John W. |
|
From: Manuel B. <li...@va...> - 2003-09-23 23:14:13
|
On Mon, Sep 22, 2003 at 11:18:35PM -0700, John Wojnaroski wrote: > Well, I've been trying to get the word out, but have had very few takers. > Posted a series of snapshots at the end of > May, seemed to get a lot of hits on the site, but very few questions or "How > do I get one of these?" So maybe it wasn't all that cool after all or those > who saw it (assuming it's mostly the FG audience) just weren't interested. > Once I get a little further along with the flightdeck I'll post a few more > pics The screenshots were great. But I cannot remember if you posted a link the the sources/your modifications. Are you working on getting your changes back into the main OpenGC development branch ? Maybe that would generate more "takers" :-) Regards, Manuel |
|
From: Damion S. <be...@cs...> - 2003-09-23 13:18:52
|
Well, just to chime in with my 2c... > pilot types I've worked with. But (here's the catch) since Damion went > off > on a different direction with the OpenGC project it's become > incompatible > and I just don't have the time, talent or resources to set up a > website and > CVS server or try to sync up with X-Plane or FSxxx. It runs under > Linux and > networks with FG, and is just as easy to set up as FSUIPC and has a > lot more To clarify, OpenGC did not go off in a different direction. The reason I made the decision to axe the older FlightGear interface is that it did not (and could not) build under Windows. This was the same reason that I switched to CMake over autoconf for the build system. The only reason (in my mind) that it's acceptable to not support all possible platforms is if it's not _technically_ possible, as with FSUIPC. I was concerned that the FlightGear stuff was evolving into a separate project within OpenGC, since the interface itself would not work on Windows and FMC would not work with other simulators (or under Windows). I certainly plan to offer cross-platform bidirectional communications along with a FMC in the future. The only thing I insist on is that whatever gets designed work in as generic a manner as possible. This is not the only way to do things - the FlightDeckSoftware guys have differentiated their project from OpenGC by choosing to only support FS200x and Windows, while offering a more complete feature set than OpenGC. However, the original premise of OpenGC was to try and be as cross-platform as possible, and I'd like to stick with that. Cheers, -Damion- --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
|
From: Manuel B. <li...@va...> - 2003-09-21 23:25:04
|
On Sun, Sep 21, 2003 at 01:36:40PM -0700, Gene Buckle wrote: > > > Well keep in mind that these guys are hackers at heart and if you can show > > > them a need for other platform drivers they'll be happy to comply. > > > > > I talked with some of them, but doubt if a market of one is going to make > > anyone do somersaults... And the use of FG and open source stuff for > > building cockpits is either not reported or not happening... I suspect the > > latter Well... I do some home cockpit building (and its flightgear exclusivly :) A friend and I were working on a fully enclosed B744 cockpit. But due to space constraints and a few other reasons, we had to cancel that. Now he has built a Piper Cub cockpit (that runs flightgear of course) and I have parts like yoke, rudder pedals and throttle of our old 744 cockpit here at home. > The lack of "amateur" use of FG is most likely due to the high barrier of > entry (you _must_ know what you're doing) and the lack of cockpit oriented > third party infrastructure. > > For instance, there is a LOT of cockpit support software available for > MSFS that's made by Project Magenta. It's pretty high dollar software > too. However, it sells itself because of how easy it is to configure and > hook up to MSFS via network, etc. There are other packages out there that > offer similar features for free as well. OpenGC provides a small subset > as you know. I totally agree with you on the way overpriced Project Magenta. They even want you to purchase two licenses if you want their software for both pilot and copilot (unless you use something like VGA splitting.) > For FlightGear to really take off as a core tool for the home cockpit > builder, it has to be more widely supported by the user community. I agree. However since most development goes on on unix/linux, and most people working on it are of the "unix kind" (which is good :), setting fgfs up on windows, esp. if you want to use CVS, is not that easy for what the average MSFS pilots are used to. > One thing that would prove to be a big boost to FlightGear's popularity > would be FSUIPC support. All you'd have to do is set up a shared memory > segment that Pete could get at with his software, and you'd instantly > obtain 100% compatibility with all those cool add-ons that the MSFS folks > enjoy. Even the Project Magenta stuff would work right out of the box for > the most part. I don't think FSUIPC is necessary. there's enought ways of getting data in and out of fgfs. I don't see why Project Magenta (being expensive $-wise) should "profit" from fgfs (being free). Then there is the "FSUIPC now costs money thing"... I'd rather stay with opensource. When I post in a german home cockpit builders forum that I visit regularly, all my posts have a signature line pointing to flightgear. :-) Regards, Manuel |
|
From: John W. <ca...@mm...> - 2003-09-26 21:42:37
|
Hi Manuel, Thanks for the schematics. I wanted to sent you a couple but for some reason I can't move them from the clipboard after converting them to bitmaps. If you have the PCB layout software from ExpressPCB, I can send them to you in that format. Regards JW ----- Original Message ----- From: "Manuel Bessler" <li...@va...> To: <ope...@li...> Sent: Sunday, September 21, 2003 3:45 PM Subject: Re: [Opengc-devel] Linux Hardware > Well... I do some home cockpit building (and its flightgear exclusivly :) > A friend and I were working on a fully enclosed B744 cockpit. But due to > space constraints and a few other reasons, we had to cancel that. Now he > has built a Piper Cub cockpit (that runs flightgear of course) > and I have parts like yoke, rudder pedals and throttle of our old 744 > cockpit here at home. > > I'd rather stay with opensource. > > When I post in a german home cockpit builders forum that I visit > regularly, all my posts have a signature line pointing to flightgear. :-) > > > Regards, > Manuel > > |
|
From: Gene B. <ge...@de...> - 2003-09-23 19:35:42
|
> > I do like that 0/256/0 prototyping kit. Will it handle static switches and > momentary switches? > > Thanks for the input. > Here's something to think about - why not write a kernel mode driver for the Phidgets? Chester has made noises in the past about releasing the actual Phidget code (that runs on the uP on the board) under the GPL. I'm sure he'd be happy to give you any info you needed. I'd attempt it myself, but drivers are way out of my league. :) g. |
|
From: John W. <ca...@mm...> - 2003-09-23 19:55:14
|
> > > > I do like that 0/256/0 prototyping kit. Will it handle static switches and > > momentary switches? > > > > Thanks for the input. > > > > Here's something to think about - why not write a kernel mode driver for > the Phidgets? Chester has made noises in the past about releasing the > actual Phidget code (that runs on the uP on the board) under the GPL. I'm > sure he'd be happy to give you any info you needed. I'd attempt it > myself, but drivers are way out of my league. :) > I sent off an email last week regards that board, but have not heard back. I was planning to write one for Linux but afraid I don't do windows. I'll give it a few more days and send off another email... Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-23 20:04:07
|
> > Here's something to think about - why not write a kernel mode driver for > > the Phidgets? Chester has made noises in the past about releasing the > > actual Phidget code (that runs on the uP on the board) under the GPL. I'm > > sure he'd be happy to give you any info you needed. I'd attempt it > > myself, but drivers are way out of my league. :) > > > > I sent off an email last week regards that board, but have not heard back. I > was planning to write one for Linux but afraid I don't do windows. I'll give > it a few more days and send off another email... > Windows is very well covered, it's Linux that needs the driver set. :) Chester is pretty busy - you might want to try calling him. I think there is a 800 number on his website. g. |
|
From: Manuel B. <li...@va...> - 2003-09-19 22:32:22
|
Hi John, On Thu, Sep 18, 2003 at 10:50:24AM -0700, John Wojnaroski wrote: > Hi, > > Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux. Sadly, this is true. Maybe Flightgear will change this in the future. In the home cockpit building community, Linux and flightgear don't seem to be very well known and used. I think that flightgear is especially suited for that since its open source so you can get information in and out easily and dont have to rely on peek'ing and poke'ing the memory of the running simulator program. > Well, I never followed the herd and was not about to move over to Windows or FSxxxx. That would be a step back, wouldn't it :-) > So I sat down and designed an interface board for the MCP and EFIS as starters. Turns out, the board is somewhat generic in that it takes rotary enconder data and key scan circuits and along with the Linux driver stuffs the data into a small file that the application can read/write. Using the board goes like this: > > The board has a standard parallel port interface (I wanted to use IEEE1284 EPP but opted for the most common, simplest for the moment). It will run either on your printer port or any additional parallel port board (ISA or PCI) you care to install or I've got a custom ISA board with three programmable ports I used for development and testing. I've done something very similar. I'm using the serial port, however. The whole thing is based on microchips PIC line of microcontrollers. (Like someone else pointed out in this thread, these are very good for our purposes) Right now I'm tying things together to build a board that can take up to 1024 inputs (switches/rotaries/..), 35 analog input channels, and 64 digital 8 bit channel outputs for things like 7segment displays, steppers, Digital to analog,... I've written a joystick kernel driver for linux for a earlier 16 channel analog to digital system. And its Flightgear tested :-) I've made Panels myself for a 747-400 MCP and EFIS. I thing all other things except the analog inputs will not be driven by a kernel driver, but rather by a user mode program that can connect to flightgear. That way, I can specify mappings eg. for the switches without having to unload/reload the kernel module over and over. > So if you were running a MCP panel the data would be airspeed, mach, heading, vvi, and altitude. Plus the state of the pushbutton switches on the panel which would go to the FMC for the appropriate action and control of the system autopilot(s) and such. Or you could configure it as a NAV/RADIO panel and process the data as frequencies. Or whatever..... > > The board and driver run in kernel space and use an interrupt to process changes in the state of the connected panel > > I'm still testing the board but getting close to a decision on moving from a breadboard to a PCB layout. Best guesstimate on cost is between $100 and $200. ( I have no idea on what the manufacturing costs beyond the production of the bare PCB look like, as always very dependent on size of the lot and quantity discounts for parts and amortization of start-up costs,etc,etc) Costwise, I estimate my currently "in-progress" circuit schematic would cost around $50-70 in components, depending on the prices of your suppliers. > Trying to gauge the interest in such an item and welcome any feedback, questions, etc. > > For a look at some of the hardware panels I plan to use check out http://www.a-g-t.com I'm glad I'm not alone doing things like that under linux. Some older circuits and pics of my MCP/EFIS panels can be found at my home cockpit site: http://cockpit.varxec.de/ If you are interested, I can send you a png of the circuit I'm working on right now. Oh, and - of course - everything is released under the GPL, including the PIC assembly language firmware programs. Regards, Manuel |
|
From: John W. <ca...@mm...> - 2003-09-19 23:21:07
|
Hi Manuel, > > Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux. > > Sadly, this is true. Maybe Flightgear will change this in the future. > In the home cockpit building community, Linux and flightgear don't seem > to be very well known and used. > I suspect if you surveyed the users you would find most are not deeply involved in software, but rather the hardware aspects of building something tangible so windows and windows-related hardware provide a nice comfort zone. > I think that flightgear is especially suited for that since its open > source so you can get information in and out easily and dont have to > rely on peek'ing and poke'ing the memory of the running simulator > program. > Right, you need to get to the kernel and leave the application alone. > I thing all other things except the analog inputs will not be driven by > a kernel driver, but rather by a user mode program that can connect to > flightgear. That way, I can specify mappings eg. for the switches > without having to unload/reload the kernel module over and over. > Running is kernel space is both risky and very effective. In my case, the driver works with the hardware and never bothers the application (FG and OpenGC) which simple poll the driver. Displays, LEDs, switch states are all updated based on hardware interrupts and the application never sees or hears about it. > Costwise, I estimate my currently "in-progress" circuit schematic would > cost around $50-70 in components, depending on the prices of your > suppliers. > There are some sites that provide circuit design, PCB layout software and prices vary also as well with quantities purchased. Looks like my component costs for the MCP are around $30 to $35 but then I've kept the interface simple by using the parallel port so after you buy a PCI board ($40) it turns out to be a wash... And the start-up costs for the PCB range from $50 to $80 for the first unit. Then throw in some sockets, connectors, and you're over the century mark.The panel, produced by AGT, is excellent and with all the lights and switches goes for $325. This can be an expensive hobby... > > I'm glad I'm not alone doing things like that under linux. > I don't think there are a lot of us ;-) > If you are interested, I can send you a png of the circuit I'm working > on right now. > I would appreciate that; Don't have a schematic of the my circuit, just a bunch of notes and scribbles which I need to turn into a finshed product with a circuit design tool to do a PCB layup. There are some boards at www.phdigit.com that you might take a look at, only drawback ( I think ) is software is for windows. Still researching it. BTW, if your not familiar with Rubini's book on linux device drivers, recommend it highly. Google on device drivers or go to the O'Reilly website. Text and source are online and GPL'd Thank you for your comments Regards John W. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X