The purpose of all these explanations is that with the current state of the solution it is already possible for me to act on any element of the simulator from a physical control , as the element is properly declared in the configuration.
Many improvements have yet to be brought for a product " User Friendly " with graphic tools and configured to full electronic diagram for wiring . That will do the point in a next chapter . U will See That it's very basic
Rotary encoder seems to make me mad for the moment and are not easy to manage in the loop. I need to sharp my knowledge on multi threading to manage them. Work in progress ...
FG Hardware Interace (FGInt)
Re: FG Hardware Interace (FGInt)
FGFS Interface Beta Version 1.0
64 input
256 output
Based on rasberry pi 2 (Quad Core ARM 7 + 1 Gb RAM)
Setup in 1U case
Software written in python
In progress
- Power & input / ouput connectors
- Stackable system
Full view
RPI2
Output board (x2) based on I2C HT16K33 driver
Input board (x2) based on I2C MCP23017 i/O driver
Power in dev mode
RJ45 on the faceplate
I ll release documentation technical drawings & pcb plans when all will tested and ok, this the first one, i already saw some details i need to correct. I am building a blog where all will be available
Daweed
64 input
256 output
Based on rasberry pi 2 (Quad Core ARM 7 + 1 Gb RAM)
Setup in 1U case
Software written in python
In progress
- Power & input / ouput connectors
- Stackable system
Full view
RPI2
Output board (x2) based on I2C HT16K33 driver
Input board (x2) based on I2C MCP23017 i/O driver
Power in dev mode
RJ45 on the faceplate
I ll release documentation technical drawings & pcb plans when all will tested and ok, this the first one, i already saw some details i need to correct. I am building a blog where all will be available
Daweed
Re: FG Hardware Interace (FGInt)
So does this require new code in planes, or works as an add-on?
Re: FG Hardware Interace (FGInt)
Hello there,
Sorry for the sooooo late answer.
Well, the interface itself is autonomous galaxy, just an hardware and some python library made for communicate with flightgear.
At the moment you have to see this concept as a toolbox. You have to create the configuration file by hand.
I am thinking about a gui to create the configuration, but i am hurting the fact that the gui need to be execute on a terminal (pc / mac / windows [user side]) and need to communiate with the rpi to have information on what hardware is connected on the rpi. That the point i am facing ...and not in my knowledge for the moment
Regarding this, so in fact, you tell to the interface that the switch (the real) setting nav light have to update the designed property
A full client / server working between fg and the interface.
So as long as plane are standard ..... and it0uchpods your question answer is here, there is no need to made any change in airplane files. Just writing the good configuration files is needed as :
Interface configuration
Input / Output XML file for FG [ fgfs need to be started with some additional parameters ]
BUT for example for our A330 serie .... that is not as simple as explain before. Nasal have a big fingerprint in this type of plane and lots of "clickable" surface don't just update a property, lots of Nasal code can be executed, as like it's done in the MCDU section or FCU code - look at the a332.flightdeck.xml and how rotary encoder are coded -
In that particulary case, yes, an add on is necessry, but will be avail as add on (no direct update in plane file except in the common to load the add on)
Hop to have answer
Here the first test
Daweed
Sorry for the sooooo late answer.
Well, the interface itself is autonomous galaxy, just an hardware and some python library made for communicate with flightgear.
At the moment you have to see this concept as a toolbox. You have to create the configuration file by hand.
I am thinking about a gui to create the configuration, but i am hurting the fact that the gui need to be execute on a terminal (pc / mac / windows [user side]) and need to communiate with the rpi to have information on what hardware is connected on the rpi. That the point i am facing ...and not in my knowledge for the moment
Regarding this, so in fact, you tell to the interface that the switch (the real) setting nav light have to update the designed property
A full client / server working between fg and the interface.
So as long as plane are standard ..... and it0uchpods your question answer is here, there is no need to made any change in airplane files. Just writing the good configuration files is needed as :
Interface configuration
Input / Output XML file for FG [ fgfs need to be started with some additional parameters ]
BUT for example for our A330 serie .... that is not as simple as explain before. Nasal have a big fingerprint in this type of plane and lots of "clickable" surface don't just update a property, lots of Nasal code can be executed, as like it's done in the MCDU section or FCU code - look at the a332.flightdeck.xml and how rotary encoder are coded -
In that particulary case, yes, an add on is necessry, but will be avail as add on (no direct update in plane file except in the common to load the add on)
Hop to have answer
Here the first test
Daweed
Re: FG Hardware Interace (FGInt)
very cool
https://raw.githubusercontent.com/IAHM-COL/gpg-pubkey/master/pubkey.asc
R.M.S.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it?
R.M.S.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it?
Re: FG Hardware Interace (FGInt)
Hello there,
Well, i didn't success in repairing my TerraGit. Always stuck in the same error.
So as i can't fly ... , i have worked on my interface project .
Documentation writing is in process and airbus radio panel for documentation exemple have been made :
In the video, Flightgear Radio stack is linked to mumble via FG Extend.
Well, i didn't success in repairing my TerraGit. Always stuck in the same error.
So as i can't fly ... , i have worked on my interface project .
Documentation writing is in process and airbus radio panel for documentation exemple have been made :
In the video, Flightgear Radio stack is linked to mumble via FG Extend.
Return to “Hardware Development”
Who is online
Users browsing this forum: No registered users and 2 guests