Corax

I think you should, too, so others can see you\'re up to no evil

You\'re right, it looked like only one data stream, because every module got the same ID assigned. If you had several modules on a rocket, all would send their (correct) data, but it would be very hard to programmatically discern the individual modules. I\'ve fixed this in the latest download. Also please note that the way the headers are sent has changed in the new version: [list type=decimal] [li]Each module reports online[/li] [li]Each module sends its ID along with the list of data fields[/li] [li]From here on, every module sends its data packets[/li] This change is in order to make it possible for individual modules to send different data fields than other modules. This isn\'t in yet, and probably quite a while away.

Glad to hear you\'re making progress. As I just said, massive amounts of data are produced - one packet of close to 300 characters per 20ms, you do the math... No problem, requests are free... no need to shout though. I\'ll look into how this could be done. I don\'t think it makes sense to send the stage number with every packet, but maybe when the sensor reports online. For the time being, you can detect staging events by monitoring the MET, it resets when the stage is decoupled.

Thanks, much appreciated It\'s always interesting to see how this plugin could be used, just be aware of the massive amounts of data it can produce

more efficient: having less than 70ish engines to lift about the same mass to the Mun Not that I claim it to be the most efficient, I guess there\'s still room for improvement. And yes, even this turns into a slideshow...

Update available, please let me know if you run into any issues.

The problem was when the part went on rails and came off again (like when switching vessels, or restarting KSP), another UUID was randomly assigned. On the other hand, the stage name only changes when the ship is generated, or a stage is separated from the rest of the rocket. It still was not perfect, but it gave you two, not entirely redundant yet not sufficiently reliable, ways of identifying a transmitter module. I have redone the whole stage name/module ID stuff; it should now take the initial flight name and the inital ModuleID, both should now get saved and reloaded. In case there were no values assigned (with previous save files), the last known stage name and a new ID are assigned and stored the next time the game saves its state. I have also added an option so you can set a custom field separator in the part.cfg. Currently doing some final tests, new version should be up tomorrow. EDIT: And fixed, thanks! Now I\'m curious about what you\'re up to

The data is made available as tab-separated values. It\'s no big deal to import them into a spreadsheet for post-flight analysis, or whip up some GUI using LUA, Python, Processing or what have you... of course, you could have that sit next to your KSP window for an almost-in-game GUI You wouldn\'t need to send telemetry across the network for an in-game MFD. Just code a plugin with a GUI. Again, this is not what this plugin is about. Its purpose is to allow a 'remote' (i.e. anywhere on the internet, even on your own PC ) 'ground station' (i.e. a separate program) record (and process if it wants to) flight information. Also, I hear cockpit views are coming at some point in the future.

Actually the vessel name was not meant to be part of the packet at all, and only added as an afterthought when I realized there could be potential demand for more than one module per rocket, or several (rockets with) modules in close vicinity. I\'m still not satisfied with the way I\'m handling this (vessel name and session-local module UUID), but I haven\'t come to a conclusion yet. In the meantime, I\'ll go with your suggestion, and I\'ll also add the corresponding field to the header... If you want this to be fixed urgently, feel free to shout and I\'ll see to it; otherwise it may take a while.

What it is: a plugin that sends data over IP. a part to put on your rocket a sample sounding rocket for the impatient What it does: send information about the module's state as records of fields; the field separator (default is TAB), the data fields, and the sequence in which they are sent are customizable use TCP or UDP A very basic UDP listener is included, you can start it with mono UDPReceiver.exe from a Linux shell. It should run under MacOS and Windows, too, but I haven't tested that. Alternatively I recommend ncat, which can be found at http://nmap.org/ or probably with your Linux packet manager. Or you could write your own ground control station software. format the data or send it raw (for increased precision and post-processing) What data you can get: // possible fields are: // rRoll, rPitch, rYaw: rotational velocities // velX, velY, velZ: linear velocities // hdgX, hdgY, hdgZ: heading vector // accX, accY, accZ: accelerations along the axes // accAbs: magnitude of acceleration ('total') // ASL, AGL: altitude above sea level, above ground level // Elev: ground elevation (=ASL-AGL) // Lat, Lon, Ref: latitude and longitude, reference body (Kerbin, Mun, ...) // rho: atmospheric density // pStat, pDyn: static/dynamic pressure // pMult: pressure multiplier (purpose unknown) // t_ext: external temperature // t_int: module's temperature // UTC, MET: universal time, mission elapsed time // AP, PE: apoapsis, periapsis // tAP, tPE: time to apoapsis, periapsis // SMA: semi-major axis // ECC: eccentricity // INC: inclination // LAN: longitude of ascending node // EPH: epoch // modID: unique ID for each telemetry module // fName: flight name, given in VAB or taken from ship file at launch // vName: vessel name, may change on stage separation (eg. 'XYZ Debris') // crew: an aggregate for crew data, more precisely a sequence of // {crwNm,crwID,crwPnc,crwWee} times the number of kerbals on board, // if any. // crwPnc and crwWee are the 'panic' and 'wheee' factors of each kerbal. // It's important to note that if there are kerbals in the vessel at the // activation time of the telemetry module and the module gets decoupled // from the command pod, the crew data will no longer be present in the // output. This may (will) break the column count, so it is advised to // put the 'crew' field as the last field, if at all. // Non-existant (invented or misspelled) fields _will_ show up in the header, // but will output 'NaN', i.e. invalid data. What it doesn't: Provide a means of processing telemetry data; you have to supply your own method, or simply look at the numbers scrolling by. The data can be visualized using gnuplot (see images attached to this post) or similar graphics packages, or imported into spreadsheet programs like OpenOffice Calc or MS Excel. I suggest having a look at Warringer's Elderberry Ni, a software package to process and graphically display the data. How to use: download from Kerbal Spaceport unpack the archive in your KSP directory, or unpack it elsewhere and move manually read the README file optionally edit the config file./Parts/crxTelemetryMk2/part.cfg to your preferences; basically adjust the address/port/protocol, and whether you want to have the data raw (recommended for further processing) or formatted (if you just want to watch the data pour in); defaults are udp, localhost:54345, unformatted You can also configure the data fields you want to receive, and the sequence in which they are sent. I recommend always including a way to identify the transmitter and packet, i.e. modID and at least one of UTC and MET. It is also advisable to include the body of reference if you plan to go further than LKO. The data fields, formatting, and network configuration parameters are stored for each module. Modules will use the configuration that was active at their launch, even if the part.cfg is changed later on. Editing the part.cfg only affects new modules pre-launchpad, once you have a flight scene, your 'flight' along with the current module configuration is stored to the persistence.sfs (and quicksave.sfs if you use it). I've tried to strike a balance between which options are saved with the module, and which are global for all modules; I'll also try and differentiate more clearly between the two in the next update. In the long run, I envision an in-game graphical interface where you can configure each module individually. [*]start up a TCP or UDP listener (see 'What it doesn't' above) [*]start up KSP and either launch the supplied Sounding Rocket, or build your own ship - the module can be found under Utility&Scientific [*]the telemetry module is activated like any other part; you can put it in a separate stage or activate it together with other parts [*]you may modify and improve the source code, provided you share the results, including your modified code, in the same way and do not use it commercially (CC BY-NC-SA, ), or you may contact me for individual license terms. Known issues: If activated, the formatting is very basic, don't expect it to look too pretty The icon still looks like a tricoupler icon... I haven't had any KSP crashes caused by this plugin, but it's always a possibility. Take your precautions, back up your data, and don't use this on a production system. 1-X Sounding Rocket telemetry transmitter: online 1-X Sounding Rocket Rpitch Rroll Ryaw Vx Vy Vz HDG HDG HDG Gx Gy Gz Alt: Lat: Lon: Ref: Pstat: Pdyn: Pmult: tmp: UTC MET UUID EOT 0.0016113652382046 1.29521840790403E-05 0.086711198091507 3.83874535560608 166.643569946289 -0.0534871891140938 0.995006084442139 0.0266666412353516 0.0961865484714508 -8.6301456074803 0.039719425200456 -4.54973377009973 1655.81667019054 -0.233266033670277 27.7977881278362 Kerbin 0.718429643093482 0.743062292309161 0 877.2913 811455.329306119 15.3799996562302 5fa171a5 <eot> 0.0046341591514647 1.21397288239677E-05 0.0872729644179344 4.04619789123535 166.753814697266 -0.0626779720187187 0.995170474052429 0.0267431139945984 0.0944480299949646 -8.63006530274464 0.0397173714324583 -4.54966955820886 1658.93072434736 -0.233256386716709 27.797674477903 Kerbin 0.717980764855356 0.742615105360699 0 877.7861 811455.349306118 15.3799996562302 5fa171a5 <eot> 1-X Sounding Rocket telemetry: 5fa171a5 carrier lost The ISA_RAM_Mapper is back from hibernation; kept here for historic reference ISA's format is LAT;LON;ALT so you would have to edit the following lines in part.cfg: statusMessages = false formatting = false fieldSeparator = ';' packetRate = 10 dataFields = Lat, Lon, Elev You can play with the packetRate, but if anything, I'd recommend increasing the value, unless you want to go crazy with resolution (and consequently get gargantuan data files). You have been warned Capture the telemetry data to isa_RAM_{Kerbin|Mun|Minmus|whatever}_Data.csv. Linux/Mac: $ mono UDPReceiver.exe > isa_RAM_XXX_Data.csv Win: :\> UDPReceiver.exe > isa_RAM_XXX_Data.csv EDITS: 2012-03-15: UUID persistence, configurable field separator, fixes 2012-03-19: UUID fixes, simple UDPReceiver included in download, header format slightly modified 2012-04-08: New part model and texture, user-customizable data fields (now with AGL and atmospheric density), example gnuplot files. 2012-05-22: More robust address resolution, new data fields (orbital elements), more configuration options, sound. 2012-06-10: Added info to configure for use with the ISA RAM Mapper 2012-06-12: Modified and updated a few passages for clarity 2012-07-26: Updated for KSP0.16 2013-04-22: Picking up bits and pieces from the latest and greatest forum crash - déjàvu... It is strongly advised that you start with a clean installation of KSP or at least back it up before upgrading. Anything may happen.

While I can\'t (and don\'t intend to) compete with either of you, here\'s something I threw together in a few sleepless nights: Works over TCP or UDP, spits out whatever I came across, has limited formatting options for the people who want it raw and those who don\'t. Maybe you can make use of it in whole or in parts. Plugin, example part and ship, source and whatnot included. Receiver software to be supplied by user (ncat appears to work fine for open source Linux hacker types ) EDIT: I\'ve made a separate post for the telemetry plugin, you can get and discuss it there; don\'t want to hijack this thread I should note that this is not complete, and it is certainly possible to break it, or it may break things, so use at your own risk. Also feel free to modify and improve the code, provided you share the results.

Apparently not everyone subscribes to the V0.0.1.0.0.7.1a-minor versioning scheme...

I actually thought about that, but what about on-kerbin ops? I don\'t know right now. Maybe an alternative command module that uses your plugin? That way you could use the stock command module for flights on Kerbin. On the other hand, even atmospheric flights would need an oxygen supply once a certain speed/height is reached.

Just a thought: Once the capsule is sealed for launch, the atmosphere outside doesn\'t matter any more...

4096x2048, need to flip the image.