Request Data MFD for extended use of DGIV's long-range antenna, satellites and remote control

[Mr.Anderson]

Hello, I think it would be cool to have a "Data MFD" module to extend the usability of satellites and remote controllable vessels/devices. A general usage application: a deployed satellite is targeted by the DGIV's long range antenna to receive actual data (such as its orbital elements, system status, current task/operation status, measured/detected data like altitude, solar activity, or even surface photos... etc.) and see/manage it on the Data MFD. Other application could be to send commands to sat (send data, send status, stop sending, execute predefined program, suspend, re-activate, shutdown, ping (can be a simple ping or to "mirror" back sent data to check for transmission errors), or, in case of remote controllable vessel, to enter/change to specified orbit by sending it the target orbital elements... etc.). Further extension could be the use of communication relay satellites, a possible basic scenario for this could be for example: "land a research team on the far side of the Moon, then deploy a comms satellite for them to be able to communicate with ISS or Earth, then return to ISS and use the long range antenna to check transmission".
Remote-controllable devices/vessels could be operated by Data MFD either with direct comm (DGIV antenna - RC device/vessel) or through relay sats (DGIV-sat-[more sats if needed]-vessel/device). Possible scenarios may include "fleet commanding" several RC vessels from one DGIV... etc.

 

[Wishbone]

What kinds of data links, transmission modes and modulations would you like to see in such a plug-in?

In short, what level of fidelity do you expect from it? Would be nice to have some links to online documents with details on the comms protocols used, too.

 

[Mr.Anderson]

First problem is that I do not know enough to answer this for I don't know too much about the data transmission methods/formats used. I suppose there must be data integrity checks as sumcheck or similar and I don't know how to implement those. I mean the most important is to be able to transmit text and numerical data (is ASCII suitable?). I also thought of a simple scripting language by which commands can be given to devices/vessels, and these commands could be pre-defined (no need to transmit whole words, just the command code) and scripts can be built out of these. For example a command sequence would consist of an "agent" (the vessel/device to do task), the "command" (what to do), parameters (where/when/how) and and "end statement" which could be "execute" (execute command instantly), "execute[time/delay]" (execute command at exact time or start with specified delay), "append" (if there is a running sequence of tasks on a satellite, this would append the new command as a new step in the sequence and will be executed accordingly). Conditions could be specified upon which commands can be executed (e. g. a satellite monitoring Jupiter could be instructed: "IF SolarIrrad<50% THEN TRANSMIT[LowCharge] STOP TRANSMIT" which instruct sat to first send a status signal then stop continuous transmission to conserve power if anything obstructs its solar panels.
I know I wandered away from your original question, I just realized that even the concept is more complex than I had thought...
On second thought, it would add some more fun if the data transmission is not compressed and "ultra-safe" and takes some time, for example the speed could be linked to the DGIV's antenna signal level (lower level lower speed).

 

[Pyromaniac605]

I'm sorry but I can't read your posts having paragraphs really helps in readability, just saying.

So I suppose you want some sort of MFD that gives data, but what sort of data?

Darren

 

[Mr.Anderson]

Hi
Yes, data MFD, for a start, it could give the targeted object's orbital elements (those can be extracted from the simulation, I suppose).
It could be then used to check a deployed satellite's low orbit whether it is stable or decaying due to atmospheric friction.

Second idea is surface photographing: there is a Camera MFD downloadable from Orbithangar, which simulates having a PTZ camera on your craft with zoom in/out function and displays its feed on the MFD screen. The surface photographing function could simulate a similar camera on the satellite and its image feed would be displayed as "transferred data" on the Data MFD if the satellite is targeted with the long-range antenna.

Commands could partly be standard DGIV autopilot commands (PROGRADE, KILLROT... etc) to be issued to the targeted vessel.
For example if I want to dock to another vessel in low orbit, it will be likely rotating due to gravitational torque, in this case I could send it a KILLROT command just before aligning to dock.

 

[Wishbone]

This is all stuff that can be done already via Lua, in a Lua console window or in the Terminal MFD ({g} I suppose it's called Terminal because its UI induces terminal thoughts in the user).

 

[SiberianTiger]

A purpose for inter-satellite data exchange?

Imagine flying in Orbiter when you have your own orbital elements with a grain on uncertainty (Orbiter engine knows your state vectors, but you can't immediately have them at your instruments). Determination of your status and whereabouts is in hands of ground control. They mark your position and return back you navigation data (which feed your instruments with fresh updates). Some more sophisticated additions to this scheme are possible.

 

[Mr.Anderson]

Yes, that is a good idea.
Also, satellite-communication networks can be set up with simple relay-satellites which do nothing more than re-transmit received data to all directions, to the target or to other relay-sats.
This way a set of scenarios could be created like this: "Establish constant communications line between Galileo Station on Europa and Earth/Moon".
In this scenario you would be required to deploy several relay-sats carefully placed in a way that there must be at least one sat always visible from Galileo Station, some more around Jupiter so there would always be two sats which "see" each other, and so on, the point is that the communications be uninterrupted.

Also, a new addon would be cool: an "uplink" cargo which, when deployed on a planet surface, extends a targetable antenna similar to that of DGIV, to communicate with any relay-sat in range.
It could be set up to follow the target sat, and it could have its own Data MFD to send and receive data.
It could have several communication modes:
Simple nav beacon (if left on surface to mark a landing spot)
Relay (re-transmits anything it receives, so all vehicles/UMmus in its range can receive and send transmissions into the satellite network)
Direct communication post (as an "interplanetary phone booth", used to monitor satellites or vessels/devices (if targeted directly to them)) or, if it logs all received data, it can serve as "mailbox": any UMmu can walk to it and read received messages.

 

[Tommy]

The only real problem I see in this is the attempt to use the DG-IV's antennae. This would require Dan build some sort of interface into the DGIV, no-one else could do it (unless Dan allowed them access to the source, etc).

An MFD that "simulated" using the long range antennae would be possible, it just wouldn't actually use the DGIV's LRA which would slightly lower the immersion/eye candy factor. On the other hand it would work with ANY vessel, not just the DGIV.

Relay sat's could be very simple vessels - the MFD could check for vessels of the correct class to see if they are in range of your vessel, and each other for relays. You could possibly even figure out a way to use SC3 vessels for this.

 

[Wishbone]

We need to know at least antenna gain (easy to do from antenna dimensions), frequency (S-, L-, Ku-, X-bands), max power and an abstract noise/processing gain figure. Otherwise it's la-la land.

 

[Mr.Anderson]

Probably dumb question but maybe not...: is there no way to retrieve the DGIV antenna data that is displayed on the data transfer display? And feed this data to Data MFD so it can use that for communications.

 

[Wishbone]

The range and angles are computable via Orbiter API, also accessible through the Lua side, and from what I can see in DGIV, there are no extra computations involved (e.g. line-of-sight blockage, ionospheric propagation, solar noise blackout, rain eating up 40 dB off the downlink, this sort of stuff).

Please feel free to ask, the only dumb question is the one that is never asked.

 

[Mr.Anderson]

So if I get it right: antenna direction and target range can be retrieved into the would-be Data MFD, but that's all, nothing more, so this way, the antenna would see through planets which makes no sense.
Another dumb question: could the Data MFD itself be able to add at least the blockage info to the whole stuff? Considering that the simulator tracks all object, I assume that it "knows" whether there is a third object between the two communicating vessels.
The downlink could be a separate addon I detailed before, not dependent on DGIV antenna control, so all features could be implemented to it (at least I think).
What I don't know whether there are weather effects implemented in atmosphere models, if not, only the atmo density profile (and probably components?) affects the transmission.

 

[Wishbone]

Re: LOS checks - no, the simulator doesn't perform them on its own, relying on the rendering engine to put objects in the correct 3D locations blocking each other visually.

 

[Mr.Anderson]

I wonder whether it is possible to incorporate LOS handling into the new Data MFD as a workaround to simulate transmission blockage?
This way the antenna direction and range would extracted via Lua and fed to Data MFD and the blockage data would be computed by Data MFD itself (and the uplink's Data MFD could simulate the atmospheric effects on transmission), so I suppose that would be enough for a rough "test-drive"-like implementation of sat communication.