I've been using the Orbiter API functions for all the values so far, as I could see that the GPC's and NAV system can't provide them yet. It wouldn't be too difficult to convert them when the GPC code can do this.
The thing I haven't been able to work out is how to get the DAP, throttle, speedbrake modes and so on. I can see there's code relating to 'bundles', which is what the switch classes appear to be connected to, but how I get the data out the other end remains a mystery to me. Could you explain how that works?
Bundles are just objects that each represent a number of analog or discrete lines, for slow DC signals (not serial digital data streams!). We use them to separate the VC from the simulation model, so there are no direct accesses to switches if possible. The data flow there is one-directional: It goes from a single DiscreteOutput to zero or more DiscreteInputs. You can also poll the bundles directly, but that way is not very robust, since changes in the bundle structure (eg, line order) would mean you need to change the way you read the data in your code, instead of just defining once where to get the data. Also it would be then harder to implement cable failures and defects, if you would poll them directly.
Once we have more time for detail stuff, the RCS would also be controlled by such bundles, going from the MDMs to the RJDs, which would require a small extension of the capabilities of the bundles (handling pulses instead of slow signals)
You would get all such flight data from the IDPs, so, even if the GPCs don't yet send messages to the IDPs with the calculated air data, it would be nice if you could implement the dirty fix inside the IDP, so we can easier switch to a proper simulation model.
How you connect IDPs and MDUs, is up to you, there is nothing in the interface that requires complex communication, since such stuff rarely reaches the astronauts. GPCs and periphery is different, since the behavior of the GPCs depends a lot on the Shuttle Bus behavior and requires it.
I currently allocate my freetime on the VAB, for getting the "proper way" (tm) running ASAP, I would also need more time finishing the MDMs. Most switches in the cockpit go to MDMs, which are polled by the GPCs. But I have not yet finished the IO modules, I just stopped at the PROM programs. It would take a while to explain what needs to be done there, so somebody else could finish it... it is a whole lot of detail work distilled from the Operational Data, waiting to be implemented. Like analog signals being converted to digital in 10 data bits with some status bits. Or discrete Output Modules permitting pretty complex binary math for setting/resetting signals.
For the air data and the inertial sensors, it is even possible to tell on which MDM they are connected and which format the data has that they produce, switches are a bit harder, there is a lot of guess work involved. Every switch has in reality three redundant outputs, we currently model them with just one output.
For the GPC code, the stuff would be a bit more complex in the final version: you would create a process object for the service routine for the IDPs, schedule it to be executed 12.5 times per second (eg). The routine takes the data calculated by other processes (eg, velocity from ADTA, GPC or IMU SOP), formats it in a memory buffer into messages and enqueues a DMA operation that writes the data from the memory into the desired Shuttle Bus channel to the desired IDP... yes, that is computer science, but it would work with both C++ x86 code simulating the software and AP-101S emulation code without requiring complete different versions of the Shuttle hardware simulation. It is virtualized to fit.
---------- Post added at 09:17 PM ---------- Previous post was at 07:43 PM ----------
Can somebody remind me once per week to write a book about the code details and conventions that we use in SSU? I want to be able to say "RTFM".
