mjukis

The value of getting "local time" for a given longitude would be in predicting whether or not a landing site will be in sunlight or darkness.

Addon: This has me super confused. The numbers have been bothering me because there is no rational reason for it to display crossing an arbitrary altitude. Ran this same test again, but with an orbit that has an encounter with Mun, but never crosses the orbit. The results do not support my previous post at all. I then altered my orbit and watched the SOI and o.timeToTransition1/2 change... Well, see for yourself. I am stumped

This + Telemachus = omg

I tested several orbits which had encounters with Mun, Minmus or just escaped Kerbin into Kerbol orbit, and none of them ever had any correlation to the values of o.timeToTransition1 or o.timeToTransition2. I also noted that they were both always the same number. This was the reason for my original question, I was wondering if I was misunderstanding the name. I decided to go back and double check my math and code, and my numbers correctly show what is represented in the API, assuming the number given is in seconds. I did some more double checking and found that while the number doesn't correspond to any transition between spheres of influence, it DOES very closely correspond to the time at which the vessel crosses the orbit of Mun! The only way to check it easily was to visually place a maneuver node near where my trajectory crossed that orbit, with the following results :

Hmm, Rich, what does o.timeToTransition1 and o.timeToTransition2 show, exactly? I can't get the values to correspond to anything really.

Did some more observing just now. f.throttle value reads the status of the throttle as set by the pilot unless p.paused has a value other than 0. If you pause the game, retract the antenna or run out of power, f.throttle will have the same value as p.paused, regardless of pilot throttle setting, leading to some cool 2-300% throttle indications in telemetry

I am not Rich, the terminal system just uses his Telemachus API to get the data. Currently it's just some python scripts that we run on a Linux machine, but if you PM me I'd be happy to hand over the very ugly source

Moar updates! Our terminal system now has some advanced warnings and errors. Yay. First picture, Flight Overview and EECOM screens, during normal operation. The vehicle is in orbit around Mun, which means radar position and orbit data are unavailable. Telemetry however is coming in normally. The EECOM screen now also shows total consumables weight including fuel, for manual maneuver calculations. Second picture, DISTASTER STRIKES! There is something wrong with the solar panels, and the batteries have discharged. The Master Alarm is lit on both the FO and EECOM screens, and the EECOM screen shows a BAT warning. Third picture, now we're doomed. The batteries are empty, and as such, both screens' systems overview show that telemetry is offline. Because it's a power failure, all of the data is still coming in, but is either in error (weights, horizontal bar charts, etc.) or garbled (altitudes, container amounts, etc.) If the antenna had been destroyed or turned off manually, these would simply show no data at all. Mission Time, Universal Time and radar data (when available) however comes through regardless of antenna condition.

Sorry to reawaken zombie thread, but the easy way to calibrate your radar altimeter is to put it on the surface of Kerbin during construction, read off the radar altimeter reading and write it down.

I have a friend who writes code for Kindles, I can ask him to take a look at this if you'd like. This is so exciting I lack words. Telemachus is really giving us the ability to turn a funny little game into a morbidly complex quagmire, much more representative of actual spaceflight. And that is smegging awesome Edit: Just noticed, f.throttle out of the API seems to be reading the position of the throttle as set by the user, and not the throttle setting sent to the engines. If I use an autopilot system to make a throttle adjustment, f.throttle still reads the old value. Confirmed this with a MechJeb2 launch, where f.throttle read 0 the whole way up. More edit: Also, f.throttle reads "1" when the game is paused, regardless of throttle setting. No clue if this data is Telemachus or KSP.

Is there a plan, if it's even possible, to read the resource state of a specific module? For example, fuel remaining in a certain tank? My specific issue is one of electric charge. I can tell how much total charge is available, but not whether or not any of it is in the capsule. If the capsule is drained, but there is charge in other batteries, a landing would be very hazardous, since I would be immediately out of power as soon as I jettisoned any service parts from the capsule. In theory, I could calculate the rate of charge / discharge and track when the last charge / discharge cycle began, and use that data to keep running tabs on how much should be available in various parts of the ship, but it's very susceptible to continuously increasing errors due to rounding etc. On the other hand, it sure is exciting not knowing

Figured I'll drop off a little update on the terminal using the Telemachus API. We've done some early tests with a pilot in a Raster Prop Monitor capsule with two mission controllers. We found that two scripts running continuous requests for data was... a bit much for our system, or Telemachus. But never fear, I did some rewriting and now have a separate script which gathers the data from Telemachus and then distributes it via RabbitMQ to as many separate screens as we want. So now we're on to designing screens for EECOM, FDO and Booster. Here's a pic of the latest version of the Flight Directors summary screen.

OK I just stuck a ship with a MechJeb2 on it into orbit and monitored the surface info longitude in that side by side with the Telemachus map and v.long value. Interesting, if odd observations to follow. At the launch pad, we know that the longitude is about -74.55 degrees. The telemetry however is showing the proper map position, but giving a v.long of 285.442. As I launched, this number increased normally as I headed eastward, and then suddenly changed to a negative number which corresponded perfectly with the longitude readout of MechJeb2. At no point did the map display show an incorrect position. As I neared 0 degrees longitude, all displays were synchronized perfectly, as they were at 180 degrees. Here, they diverged, as MechJeb2 "crossed the dateline" and now began counting from -180 toward 0. The map displayed correctly, and v.long continued rising until a reading of about 240 degrees longitude. At this point it switched over to a negative number and was again synchronized with MechJeb2. Interestingly, upon passing KSC in orbit on this first pass, v.long read -74.55 degrees. I time accelerated to lock down exactly where the switch from positive to negative occurred, but on my second pass, it happened somewhere around 230 degrees. The next pass it was even earlier. The map was still displaying correctly however. I then did a revert to launch to see if the 285.442 reading on the launch pad might have been an error on my part, since it displayed correctly when passing overhead. It once again read 285.442. However, about a minute later it suddenly switched to the correct reading, without a launch. Not much in the way of a theory on my part, but hopefully the data will mean more to someone else than it did to me.

I am running 1.4.16.0, yes. I'll try to do some more testing and see if I can spot a pattern. So far I have never had an error with the reading on the launchpad. At prelaunch check everything matches up, it always pops up later.

Has anybody else stumbled upon an error that causes the longitude output (v.long) to have a strange offset? I normally have good readings at start but I've encountered several times that v.long was reading large negative numbers, such as -410. This causes the map display to show the ship well outside the map, and obviously causes my telemetry display some amount of confusion in converting to East/West coordinates Edit: Should note that it still seems to reset once per orbit, it's just that the number is offset.

I have no words, this looks amazing!

It seems to return 0 when normal, 1 when paused, 2 when out of power and 3 when the antenna is turned off. Perfect, exactly what I needed!

Well it's one hell of a game changer you've made. When I first saw it I thought "Neat." and then my mind exploded with possibilities. Any input on a method of reading the status of the Telemachus antenna via API? I am getting data even when it's turned off, which I like, but I'd like to be able to shut off most of it when the part isn't powered etc.

OK here's some pictures of a linux terminal screen running a first jab at providing flight data using the Telemachus API. There are two basic displays so far, one showing telemetry data about vehicle position, and the other showing some basic radar info. The radar info has about a 1% error, and rounds altitudes. The telemetry lat and long also have a built in error. First is a screen showing everything working as planned. The "-" next to telemetry altitude is no showing a negative altitude, it's showing that the number is trending downward. Second is a screen showing what the controller would see if telemetry was lost. It shows an error and displays the last data it got. I haven't figured out how to query whether or not the antenna is active (help!) so for now it just returns failures randomly about 10% of the time for testing. Radar data is unaffected. Last is a screen showing normal operation outside the range of the radar. The radar range is configurable but I have it set to only work around Kerbin between 500m ASL and 7Mm ASL.

I've done a whole bunch of integrating of Telemachus, RemoteTech 2 and some cameras in preparation for having a go at a mission where our pilot has only interior view + cameras and we only have Telemachus. Also our pilot is on a different continent. I've done some custom stuff where the data is being displayed on various terminal screens (text mode only, screenshots coming soon!) and for this mission I think we have everything we need. However, one thing I noticed in looking at bigger missions in the future is running out of action groups. When the pilot is in IVA mode, he can't access certain important vehicle functions. 1) Activate / Deactivate a specific module 2) Query the activation state of a specific module 3) Query the resource state of a specific container 4) Transfer resources Our first mission is pretty simple and none of these things should be necessary. Also, one could easily allow the pilot to leave IVA mode for a short period in order to perform these tasks. However, it would be far more awesome if flight control could read the status of a single tank and transfer fuel, or have the pilot perform the transfer. I think there is at least one fuel tank control panel mod, so that may be an option for not leaving the cockpit, but full integration into Telemachus would be much more immersive, imo.