cyberKerb

I was using the KSPIO Demo files. The config.xml file that comes with the mod under \GameData\KSPSerialIO\PluginData\KSPSerialIO has a setting called refreshrate. Set it to a second (or two or three, just something slow) and then go through your own code and ensure you are not use 'delay' anywhere at all. I quickly learnt that is very important. Here the source I used to learn that from: https://www.baldengineer.com/millis-tutorial.html My solution was custom kludge code written as I learnt the necessary code to get the data to the LCD. I used the LiquidCrystal_I2C library to drive the LCD display and incorporated the guide from here: https://learn.adafruit.com/i2c-spi-lcd-backpack Sorry it's non-specific as I don't have any of my test code anymore. I know others on the forum here have used the LCD module - they might have more tips for you.

Yep - been there a few times. From my own experience, it was usually the serial buffer filling up because I coded it badly. This resulted in the time it took the Arduino to display the LCD taking too long and it would miss a few receives from the computer. I lowered how fast I was sending data to the Arduino until it got steady and they I investigated what I could do to speedup the process with getting data to the LCD.

Thanks for this - knowing the KSPlogging exists was what I was after!

The issue was that in wanting a "single file" with only a "single line", the mod would 'append' rather than 'overwrite'.

Sorry - very confusing typo there: Works as advertised when onePerFile = true and singleLine = true with the value (per file) being constantly overwritten each update. Updated original post

Hi @linuxgurugamer - did a quick check of the functionality for a project (looks promising by the way ) and found that when the config option 'onePerFile = false' , the mod doesn't follow the 'singleLine = true' option. It'll keep appending the updated full string of all values to the end of the single file. Is that as expected or an exception? Works as advertised when onePerFile = true and singleLine = true with the value (per file) being constantly overwritten each update.

Just realised that despite thinking about this for the better part of the afternoon, I hadn't thought enough about it. I only just now realise that if I do get the data to an external screen, how am I going to control the 'selecting' part? That external data window wouldn't be the active window (KSP will be) so it wont recognise commands from the keyboard. I'd have to pass the input key to the application and action it based on that command. Might work...

I've been playing around with SerialIO a fair bit, but there was some tasks I didn't want to burden the tiny Ardunio with. Anyone know what my options are for getting the following data and streaming it to a window on the same desktop that KSP is running? CelestialBody List TargetVessel List Target Range List TargetVessel PortName List My hope is to pass this information to a bit of code that allows me to pick from an available set of targets and I can code the return message to listen for a response that would 'set the target' in game. I only thought of taking the data from the arduino and passing it back to the PC via a different COM port which an application would be listening to. But that sound rather stupid on my part. I hoping someone can point me in the direction of some bootstrap idea seeing as I've read unity doesn't allow popup windows outside the game scene. Is there some reference I can add to my mod to allow me to pass data to a window that I can code to display a custom GUI? Or is the only option to hand the data to a listening program and having that independent program do what it I code it to do?

Hi @MOARdV, the mod is awesome in how much game data is available to get in front of a user. Just wondering how developed the back end calculations are? I've spent the last week scanning the available variables and it looks as extensive as RPM and didn't see anything I couldn't think of. Are there any areas of calculations that still need work or that you would consider 'missing'?(outside of external proxies mods) Or is the focus now purely IVA, asset creation seeing as existing calcs are already done.

The HUD is gorgeous! Love the addition of the ground indicator for the wheels - nice touch!

For me, it was to create an atmosphere gauge to view on a physical controller while in IVA view. I didn't use the alt vs maxheight calculation as that a linear value. The gauge is sourced from an exponential value, but it's converted somehow so it moves different to the values you'd expect it to use. The formula I had is not perfect by any means but it at least replicates the atmosphere gauge +- 0.5%. Not idea why 4th root gets close or works as well as it does. Main reason I posted it is there have been a couple of threads (here and reddit) querying what the calcs are behind the gauge. I figured I'd try. Also aware there are opinions that the atmosphere gauge is useless and takes up screen space, so no loss if no one interested. Richfiles even mentioned the scale was weird, the tick marks don't make sense and the color bands are another mystery Atmos MaxAlt Gauge vs Alt% 90.0% 96.0% 80.1% 90.9% 70.1% 86.0% 60.0% 81.4% 50.0% 76.0% 40.0% 69.5% 30.0% 61.1% 20.0% 48.7% 10.0% 23.5% 0.7% 0.1% This is the stuff I need to learn but don't know it's contextual application.

The numbers moved out of sync with what I was seeing on the gauge when I used density / sea level. I tried that initially and these are the values for the foll0wing calc: ActiveVessel.atmDensity / FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel); atmDensity SL Density Result Actual Gauge 0.80186027 / 1.22988546 = 65.2% 90.0% 0.49960122 / 1.22988546 = 40.6% 80.0% 0.29447165 / 1.22988546 = 23.9% 70.1% 0.15967405 / 1.22988546 = 13.0% 60.2% 0.07618099 / 1.22988546 = 6.2% 50.0% 0.03136805 / 1.22988546 = 2.6% 40.1% 0.00990661 / 1.22988546 = 0.8% 30.0% 0.00197034 / 1.22988546 = 0.2% 20.0% 0.0001245 / 1.22988546 = 0.0% 10.0% 0 / 1.22988546 = 0.0% 0.6% I went back and tried some regression analysis and a far simpler formula popped out. SLDensity = (float)FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel); AtmosDepth = (float)Math.Pow(ActiveVessel.atmDensity / SLDensity,0.25f); As a quick test in the morning, I found it works for Duna, Kerbin, & Laythe - so I think that's the one . I'll test again tonight to see if I need to add some decimals to that 0.25 figure to be slightly more accurate. EDIT: Re-ran the numbers through the tool (here: https://planetcalc.com/5992/) and confirmed that the formula is best fit. Kinda chuffed that it worked @richfiles Calc all done for you when you get to your software stage. I've had a few attempts working with hardware a few times like what you've posted on the forums. This time around I'm trying to stick with software and work those issues out first. Hopefully I make it further than last time and have a few working components. @zitronen Not sure there's any point adding SL Density to the protocol on it's own. While it's required to do the calc, it would be a different Sea Level Density figure depending on what planet you were on. All that would result in would be getting ppl to do the calc on their microcontroller and it's preferable to avoid the log, ln, power function were possible on those little things. Probably be simpler to just replace Density with the Depth calculation below. Last option would be to read directly from the GUI Atmosphere gauge value. Suggestion to substitute the Density value and supply a atmosphere depth value that should be between 0 and 1. KSPSerialPort.VData.Density = (float)ActiveVessel.atmDensity; with KSPSerialPort.VData.Density = (float)Math.Pow(ActiveVessel.atmDensity / (FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel)), 0.25f);

Ok - I'm done for the night. I've taken the non-math/Kerbal route to try to get something together for this math problem. The results aren't bad, as all values are within +-0.5% I would be good if someone who is more knowledgeable that me in this area to see if they can tease out the correct formula. My fumbling in excel was just tweaking the shape of charts based on formulas to make expected lines match. Kludge Calculations Step 1 CalcAirDensity = (float)(ActiveVessel.staticPressurekPa*PhysicsGlobals.KpaToAtmospheres*1000/(287.058*ActiveVessel.atmosphericTemperature)); Or CalcAirDensity = (float)FlightGlobals.getAtmDensity(ActiveVessel.staticPressurekPa * PhysicsGlobals.KpaToAtmospheres, ActiveVessel.atmosphericTemperature); Note: Don't use (float)ActiveVessel.atmDensity My wild guess is that this might be a legacy property. The atmDensity field doesn't have a value until it's >= 0.00000001. I need to recheck if the GUI gauge is still showing > 0 in these cases or if it's zeroing ahead of time, but I don't think this is the case. My logging shows that GUI gauge still has values all the way until pressure is 0. Step 2 (float)(Math.Exp((Math.Log(CalcAirDensity) / 4) - BodyVal) * 10) Substitute the BodyVal with applicable value below. Don't ask me where '4' come from - I randomly entered it in and the gradient of the chart matched what I was looking for. So I went with it. BodyVal number based on testing Kerbin = 1.1983 Duna = 0.575 Laythe = 1.0811 Eve = 1.5071 If anyone works out how these can be derived from the celestial body properties, let me know. This gives me an atmosphere value between 0.0 - 1.0 that correlates closely to the Atmosphere Gauge on the GUI. If you fork your own KerbalSerialIO, you could add the code in C# to a variable in then you'll be able use the value for setting a physical gauge. However, this isn't intended to be a 'solution', just a step towards finding the right formula. Pinging a few people who might be interested / serious math god. @zitronen, @hugopeeters @richfiles @Arrowstar EDIT: found better formula - see below.

Thanks @richfiles for going back and looking through all that. It covered what I'd already read on the forum. Here's what my searching uncovered: RPM formula for Atmo Depth that is used when the gauge GUI object is unavailable:: upperAtmosphereLimit = Math.Log(100000.0); depth = (float) ( ( upperAtmosphereLimit + Math.Log ( FlightGlobals.getAtmDensity(vessel.staticPressurekPa * PhysicsGlobals.KpaToAtmospheres, FlightGlobals.Bodies[1].atmosphereTemperatureSeaLevel) / FlightGlobals.getAtmDensity(FlightGlobals.currentMainBody.atmospherePressureSeaLevel, FlightGlobals.currentMainBody.atmosphereTemperatureSeaLevel) ) ) / upperAtmosphereLimit ).Clamp(0.0f, 1.0f); I came up with the following formula trying to match the density curve to the GUI gauge curve during a test launch. VDensity = (vesselairpressure*1000)/(287.053*atmosTempK) Gauge % = 10^(LOG(VDensity)/4)-0.021808 In "spreadsheet land", it stays within 0.02% of the gauge (on average). It's worst when the pressure is really low near space. I'll run both calcs, the RPM & my kluged version, tonight to see how they compare to the actual gauge value. Edit: OK the kludged version works well, but only for Kerbin - kinda expected. Now to throw more formulas and to plug numbers in until I get the curve I'm expecting. KSPSerialPort.VData.AmtosDepth = (float)Math.Pow(10, ((Math.Log((ActiveVessel.staticPressurekPa * 1000.0f) / (287.53f * ActiveVessel.atmosphericTemperature), 10.0)) / 4) - 0.021808f); Edit2: Better calc at bottom of thread

Did you use the 'Density' value that is the only atmos value in the KSSerialIO mod? If so, what were you using as the max number you were dividing by to get the percent? github source line: KSPSerialPort.VData.Density = (float)ActiveVessel.atmDensity; Or did you fork the KSSerialIO and add your own value? I want interested to know what you ended up with sourcewise see at the Max value changes for each celestialbody.

I'm read a range of forum post, the wiki, the wiki discussion and reddit, but there doesn't seem to be a known calculation for deriving the Atmosphere Gauge value between 0-1 I've seen how the RPM/MAS mod hooks into the object to read the value directly, but I was wondering if anyone had worked out the calculations to match the gauges values? @richfiles - did you end up working out the details for your gauge? I saw the comment about atmos being " .000001 of 1 ASL atmosphere", but where do you calculate or grab that 1 ASL value from in the API? Is it a lookup table?

Awesome!. This should be interesting to implement. I finally have some time to code and will do some testing with Duty Roster tonight. Also adding obligatory @SQUAD ping to see if this is something they could support in the future stock API somehow to increase available modding support.

That's awesome. I look fwd to updates on how you go with checking torque. Curious as to why you used a geared drive from turning the half spheres, rather that direct from the motor shaft. A guess is only single shaft stepper or were there other reasons?

Just letting all know that I did get some time to work on the mod over last weekend. Just ran out of time for the last bit of testing I wanted to do. rebuilt and rearranged how the list of Kerbals is displayed added the CTI profession icons next the names - Kerbal profession trait stays regardless of On/Off Duty status broke the paging process when there are too many kerbals to display at once (should be an easy fix) added tourist support. They won't have any duty to maintain and any change buttons wont appear for tourists I intend on addressing the trait being tourist at all issue that Cakepie raised, but it won't be done in this update. got most of the way into adding the Overtime process, but need a bit more testing before releasing an update. WIP process is a press of button gives you an (default) 20 mins extra and is configurable. The "cost" for overtime is that they'll take a full extra day off duty (per button press - again configurable) before coming back for their next shift.

Not for force feedback. I only plan to have a motor drive it to the off and max thrust positions. Anything else will be set manually. A simple v-belt might be fine for this I think.

Yikes! I've been reviewed. Thanks @Kottabos! I really need to get onto some of those issues this weekend - including changing the labeling on the the "Change to" column to "Change to (Mins)"

Wasn't able to get to it last weekend. Hoping this weekend is better. This is on the list of this that came from earlier suggestions. Will do.

31.Mar Wheeeee! I'm quite happy when where I got to this weekend. It looks great! Managed another two hours in the shed before family got hungry and I needed to start making dinner. I sanded / filed everything flat relative to each other, this is why the button panel looks so ugly. It want be seem when painted, but I must of managed to glued it at an angle. The handle is temporarily on a drill-bit - yes it's crooked, it won't be when on its final shaft. The buttons are also just sitting free in the holes for demonstration. (I've already dropped two buttons into the housing - oops) Things to-do: Putty over the hole on the outside handle where I mounted the grip. Sand a bevel all the way around the side panels Cut massive hole in the right panel for my reverse thrust pullout section. Might raise the LCD panel up so it isn't recessed create mounting PCB for buttons to hold them at the correct height/angle add electronics into housing wire LCDs into perspex chips in grip and router a channel down inside of handle for wiring (4 wires total) add hardware for square tubing for mounting to desk/chair slop on a few coats of matte black paint work out how to have a motor drive a sliding shaft for the min/max buttons and then there's all the internals for min/max thrust end stops for both positive and negative directions. Phew! - plenty to go and this is just the throttle!

30.Mar Very small update from last 2 weekends. Only had a short time to work in the shed between getting home in the afternoon and sitting down for dinner. I mostly trimmed up the plastic bits that will be used to light up in hand grip. Also created the "pommel" and the end of the grip. Spent the rest of the time last weekend thinking how this is going to be assembled. This weekend I grabbed some 3/16" threaded rod and a decently long drill bit from the hardware store and I drilled through the middle of the grip and put it all together. It's only held together with friction from the screw at this point. Hoping to do a little work on the housing this afternoon, wont be much though - probably only get an hr tops. The 2nd picture shows the handle lit from behind with the torch on the left. It's gives an idea of the effect I'm going for. The LEDs will arrive next week and that'll be a stage I'm most be looking forward to aside from getting this mounted on the housing.

Thanks so much for all the feedback. I'll be digging into some of these over the weekend to see if I can't get a few improvements to the mod. Big thanks to @cakepie for all the UI considerations and code suggestions. That's probably what will have most of my attention.