[PLUGIN, PART, 0.15+] crxTelemetryMk2 Module alpha

[esd]

I\'m looking at using this plugin as a pathway to grab data to put on my G13\'s LCD screen. I was originally hoping to hook the data direct.

I\'m not much of a coder, but so far I\'ve managed to create a listener form-program. Getting there.

Is there a way to make the telemetry always-on (eg, with a command-capsule telemetry part or a .5m part to sit atop the command-capsule, but preferably without any parts if possible) or even togglable?

Where might I find this Elderberry Ni thing so I can have a peek at your source? (Sourcy, nudge, nudge)

Also, and here\'s me exposing my star-nublet credentials... any chance of a whole-word explanation of the contents? I have no idea what Pstat, Pdyn, Pmult, UTC or MET mean.

Cheers for this plugin. Looking forward to having a look under it\'s hood!

{Edit: Realised 'tmp' referred to 'temperature'. Oops.}

[Corax]

I\'m looking at using this plugin as a pathway to grab data to put on my G13\'s LCD screen. I was originally hoping to hook the data direct.

I\'m not much of a coder, but so far I\'ve managed to create a listener form-program. Getting there.

Is there a way to make the telemetry always-on (eg, with a command-capsule telemetry part or a .5m part to sit atop the command-capsule, but preferably without any parts if possible) or even togglable?

You could always make (or copy) a part and edit its part.cfg; that way, you could have a zero-drag, zero-mass – even nearly zero-size – telemetry module... regarding 'always on', it\'s always on once you activate it, deactivating is currently not very high on the to-do list (i.e. not planned). The 'always on' is relative though, once you get further away than 2.5km, the part is 'put on rails', that is, it\'s deactivated and its physics calculations are approximated to reduce processor load. There\'s nothing I can do about that.

Also, and here\'s me exposing my star-nublet credentials... any chance of a whole-word explanation of the contents? I have no idea what Pstat, Pdyn, Pmult, UTC or MET mean.

Coming in the next update. For now, P are pressure values, UTC is Universal Time as always, MET is Mission Elapsed Time.

Cheers for this plugin. Looking forward to having a look under it\'s hood!

Thanks, source code is included in the download as always (see first post, you only need the latest ). Have fun

[Warringer]

Where might I find this Elderberry Ni thing so I can have a peek at your source? (Sourcy, nudge, nudge)

Find it here . Source is included in the file.

But be warned. I have yet to comment the source so you are mostly on your own.

[esd]

I\'m well on the way to making the LCDStudio plugin... but I\'m having trouble getting my head around the three HDG figures. How do I convert those into a compass bearing?

*edit*

Hmm, well - the plugin is kinda done. It works to stream the telemetry data onto the screen of my gamepad (and will work on anyone\'s little LCD screen). Having some problems with the actual data though.

The Pitch, roll, etc. They\'re all rates of change, right? What I really need is current yaw/heading/pitch figures for the current craft/telemetry module. Any chance..? Otherwise the flight instruments won\'t look right...

[togfox]

Winning! Thx.

Edit: so, using telemetry on a simple rocket, I\'m now looking at the stats and there is something not quite right. I don\'t think it is a problem with the plugin but instead with the physics engine.

After 1 second of flight, the telemetry shows an acceleration of 13.9 m/s. This is real acceleration I assume - after gravity and drag applied. If my acceleration is 13.9 m/s in the first second, then in the first second should my altitude (above ground level) be 13.9 metres?

Telemetry says: 8.0 metres (AGL).

Either the physics is out by a smidgen OR their is a slight lag in the telemetry so that some values are out of sync. The second reason being acceptable. I\'ll see if I can recalibrate the data to prove/disprove this.

Edit: After checking the numbers, the telemetry error rate drops significantly over time, which is good. The first few seconds shows some pretty unpredictable telemetry but it improves after the first few seconds. I\'m talking about some down-in-the-weeds accuracy here. If you\'re using this for graphs and curves then there won\'t be a problem however if you\'re looking for hard stats then you\'re best to ignore the first few seconds.

Here is a graph of the error rate dropping over 15 seconds of telemetry gathering. It takes 8 seconds for the error rate to get below 10%. That\'s fine. Just saying.

Love ya work. 8)

[Corax]

I\'m well on the way to making the LCDStudio plugin... but I\'m having trouble getting my head around the three HDG figures. How do I convert those into a compass bearing?[...]

The Pitch, roll, etc. They\'re all rates of change, right? What I really need is current yaw/heading/pitch figures for the current craft/telemetry module. Any chance..? Otherwise the flight instruments won\'t look right...

The HDG values are the three components of a vector, I don\'t know yet what their point of reference is though. Y/P/R are indeed rates, as I hoped to indicate by putting an 'R' in front of each

[...] I\'m now looking at the stats and there is something not quite right. I don\'t think it is a problem with the plugin but instead with the physics engine.

After 1 second of flight, the telemetry shows an acceleration of 13.9 m/s. This is real acceleration I assume - after gravity and drag applied. If my acceleration is 13.9 m/s in the first second, then in the first second should my altitude (above ground level) be 13.9 metres?

Telemetry says: 8.0 metres (AGL).

First, the label reads 'Alt', when it really should say 'ASL', that\'s fixed in the next update.

Second, make certain you\'re looking up the right column, it\'s easy enough to get that wrong; a rocket on the launchpad should report at least an altitude of sixtysomething metres, as the launchpad itself is situated that high above sea level.

Either the physics is out by a smidgen OR their is a slight lag in the telemetry so that some values are out of sync. The second reason being acceptable. I\'ll see if I can recalibrate the data to prove/disprove this.

I think some of the physics is not too accurate, one can observe that easily, especially with the 'alt' value: sitting on the pad, the module\'s altitude changes by a millimetre or so per update.

The latency of telemetry data is related to the path the data has to take; that may be a few milliseconds if you route around the world, but if you display the data on the same computer KSP is running on, it should be negligible.

Also please everyone keep in mind that the plugin is in a very early state, especially with regard to the reliability and quality of the data. Use at your own risk, and definitely not in in production articles!

[togfox]

Yep. I\'m factoring the pad altitude of 60 point something metres (hence why i said alt should be 13m after 1 second). I\'m running on same pc btw.

Loving the stats. Keep it up.

[Corax]

Yep. I\'m factoring the pad altitude of 60 point something metres (hence why i said alt should be 13m after 1 second). I\'m running on same pc btw.

Loving the stats. Keep it up.

Thanks. There\'s a lot still to be figured out, for example how to properly interpret the pressure values (and 'multiplier'?!); I\'d like to move the output towards more 'realistic' sensor data – gyro and accelerometer readings, for example, as opposed to more or less abstract variables straight from the physics engine.

At the moment I\'m mostly sending some variables that can be found in the various game classes without really understanding most of how they are related to the actual module; some of the data is related to the 'ship' (i.e. command pod), regardless of where the sensor module is located (or if it\'s even in the same physical entity).

A lot of this is (hopefully) going to change in the future, so anyone who is building something to process the data I send, be prepared for a lot of sweat and tears (of joy or frustration remains to be seen)

[esd]

The HDG values are the three components of a vector, I don\'t know yet what their point of reference is though. Y/P/R are indeed rates, as I hoped to indicate by putting an 'R' in front of each

Cheers!

Question about your source - any objection to my butchering it to my own ends? Have reached a bit of a dead-end in hooking the values straight from the DLL, but know I can make it work using your plugin.

Basically I want to re-jig the variables that get exported to more suit external flight instruments as opposed to telemetry logging. Any publications would naturally credit you on the code template

[togfox]

I\'m re-evaluating all my stats and formula\'s. Any comment I made about the telemetry being odd can be completely disregarded!

[Corax]

Cheers!

Question about your source - any objection to my butchering it to my own ends? Have reached a bit of a dead-end in hooking the values straight from the DLL, but know I can make it work using your plugin.

Basically I want to re-jig the variables that get exported to more suit external flight instruments as opposed to telemetry logging. Any publications would naturally credit you on the code template

As long as you honour the licence (CC-NC-BY-SA), butcher away

You might want to wait for a few more days though, I\'m in the midst of refactoring the plugin to make it easier to modify.

[togfox]

Is it easy to put a cfg entry to specify the sample rate? It\'s spitting out an enormous amount of data at the moment which is good for some applications and not for others. It can default to the current rate but it would be nice to have a \'5 samples per second\' or a \'sample every 0.20 seconds\' option. This would reduce the load (I assume) and can let ppl tweak the output for their own purposes.

[Corax]

Is it easy to put a cfg entry to specify the sample rate? It\'s spitting out an enormous amount of data at the moment which is good for some applications and not for others. It can default to the current rate but it would be nice to have a \'5 samples per second\' or a \'sample every 0.20 seconds\' option. This would reduce the load (I assume) and can let ppl tweak the output for their own purposes.

Should be easy enough. I don\'t think I\'ll put in a definite samples/s rate though, it\'ll more likely be some factor against the max sample rate, i.e. factor 5 would give you 1/5th the current rate.

Will be in the next update, along some other stuff I\'m working on (eg. user-selectable data fields in arbitrary sequence, altitude above ground, and a few fixes and cleanups). I hope to have it ready sometime next week.

[togfox]

Oh goodie!! My next request was to define the columns outputted and the order but I didn\'t want to push the friendship. ;P

[semininja]

Well, I updated everything, and now it works the way it should; I didn\'t even have to turn off COMODO. I don\'t know what the problem was, but it\'s resolved itself.

[Warringer]

Well, I updated everything, and now it works the way it should; I didn\'t even have to turn off COMODO. I don\'t know what the problem was, but it\'s resolved itself.

Even my tool?

[semininja]

Even my tool?

Yeah; as a matter of fact, I thought I posted that in your thread, and was confused when it didn\'t show up there when I was reading your thread a little bit ago...

Perhaps a moderator could move the post (and responses)?

[togfox]

When I set the \'field seperator\' to a comma (,) so it is in CSV format, the output has comma\'s, which is good, but every second row is a blank line for some reason. It\'s like there is a new line after each EOT.

That never happened with the TAB seperator.

[Corax]

When I set the \'field separator\' to a comma (,) so it is in CSV format, the output has commas, which is good, but every second row is a blank line for some reason. It\'s like there is a new line after each EOT.

That never happened with the TAB separator.

I\'d be surprised if this wasn\'t the case with the TAB, too; the field separator is in no way connected to the line ending.

It may be confusing, but in fact, there is one guaranteed linefeed (0x0a) after each EOT. There may be another LF, or CR+LF, or LF+CR, or just CR, or in fact anything, after that, depending on your OS.

Each record ends with '<EOT>\'\n\'' (3c 45 4f 54 3e 0a), plus whatever your OS thinks is a proper line ending. I think I\'ll change that with the next release, as that is not unlikely to break a few things anyway.

[Silverware]

It seems that the tgz files are broken. According to both 7zip and gzip.

This could possibly be my system, it is weird, or maybe the recent server move, but either way I am unable to get the files. And I would very much like to play with them. A re-upload, or an upload in a different format, say zip, would be cool.

[Corax]

It seems the forum move broke the attachments, and currently doesn\'t allow any new attachments. Here\'s a dropbox download for the time being. If you don\'t have a dropbox account (you don\'t need one to download), consider joining using this link.

EDIT:

Fixed attachments in OP.

[togfox]

If you do a right-click and \'Save As\' then don\'t. That doesn\'t work.

Just do a normal click on the file and you\'ll be taken to the correct download page. That one got me to. >

[Corax]

Hi, just a little update:

I\'m still in the midst of reworking the plugin, I will not announce another estimate... it\'ll be done when it\'s done.

For now, here\'s a preview of some of the changes:

• 
  [li]a new custom part. Same mass, but much shorter, to allow for more compact construction.[/li]
  [li]the data fields and their ordering will be configurable in the [tt]part.cfg[/tt], and will be persistent per craft. If you change the [tt]part.cfg[/tt], all new ships will use that, whereas existing ships will continue with their original configuration.[/li]
  [li]the data rate will be configurable, too.[/li]
  [li]a few new fields will be available, among them AGL ('above ground level') and rho ('?', atmospheric density)[/li]
  [li]some example gnuplot files will be included for data visualization (see spoiler for an example).[/li]
  [li]the transmitter itself will be a separate class, so other plugins can include a transmitter as well.[/li]
  

And of course, a few teaser images:

Mapping the Mun

Topographic Map

Just over two days into the mission; telemetry data accumulated: 0.6GB

Surface Panorama on White

Surface Panorama on Black

Map Sheet on White

Map Sheet on Black

Refining the Data Points

More Orbits!

[Warringer]

I\'d like to request the inclusion of the vessel name into the header of the TelemetryMK2 module.

Makes it easier to save multiple files for multiple craft. I\'d try to modify the source code myself, but MonoDevelop and Linux strangely enough don\'t like the UDP libraries...

And perhaps bring back a way to tell when a telemetry sender isn\'t online anymore.

[togfox]

Neat. Thx.