cm2227

Hello everyone, can anyone help me with a strange issue I encounter? Nothing is wrong until I actually open the interface in my browser (that is http://127.0.0.1:8085/telemachus/index.html). If I do so, I get data - at least for a few seconds. Then KSP stops responding and I have to kill the task. The logfile reveals a flood of messages like... I just copied a few lines from tens of thousands of log entries. In fact Telechamus wrote about 50 000 lines into the log file starting and ending with a block of "Falling back on default handler". Does anyone have a clue what it means? There is thousands of lines with "SIZE OF" expressions and thousands of repetitions of the GETTING and FINDING NODE combination. Thank you, any help is aprecciated! BR CM2227 Edit: It crashed again, this time only adding "Falling back on default handler" 11 times to the end of the log file. Edit2: I experimented further. The crash occurs when I open the houston gui. Also the last messages in the log are now "[LOG 15:55:57.946] [Telemachus Debug] Start GET".

April 14th, 2016 As I'm a Dad since November I have even less time for my project. Still I managed to do some progress, which I'd like to show you. Last Summer I got my hands on a collection of different analog gauges, mostly ampmeters for 0-20mA signals but also some voltmeters. So I had to find a way to add a lot of gauges to my console, because I just love gauges! My solution was to build a separate enclosure which can be placed anywhere near or on top of the main console. My cockpit is supposed to be suitable for one or two pilots - some time when it's finished. Anyway take a look at the progress pics and feel free to ask if you have questions. Of course I will add a faceplate with labels and stuff, the massive board is for stability reasons only. Next update will be soon I hope. I'm working on my 16 LED caution & warning display. My next goal is having a few basic functions (gauges, LEDs, switches, Joysticks) ready to actually fly a mission with this thing.

@richfiles: My approach is similar, I also have one Arduino Mega as a central unit handling communications with KSPserialIO and as many analog gauges as needed/possible plus other displays, but limited to output only. Any input is handled by other units but will in the future partially be passed through the main arduino by serial communications. I also urge everybody to spend a few moneys extra on a higher level arduino to avoid RAM shortages. @zitronen: For many numeric values like battery or xenon gas it could be sufficient to transmit a single byte representing only the level, e.g. current / max * 255 which would indeed save memory. At least in my case where the consumables are only used for analog display. In addition I will rarely need VData members 4,5,12,28-31. Also some of the values could be calculated if needed on the arduino, like eccentricity from major and minor axis.

If you are open to discussion - which would essentially mean letting other people interfere with your voluntary work - I have several ideas. How about adding a few float variables whose content is determined by command in the control packet, i.e. the arduino requests which values it needs? Or a second type of packet which contains more static information, like the consumables max values or SOI and is only sent every few seconds? Or an optional packet with rarely used info, which is only sent on request by the arduino?

Well that is not an option for me, as I'm a USB joystick (Saitek X52) and its throttle. Also I plan on implementing an arduino-based autopilot, which would require reading back throttle to see if the command was executed correctly. I would gladly take part in a discussion on what to add to the VData packet. Orbital vector stuff would also be pretty interesting. What is the space limitation?

Dear zitronen, I finally found the time to continue my project - which would be impossible without your work, so thank you very much for everything you have provided for us. I will probably never finish my mechjeb compatible version of your plugin, so you can delete that reference from your first post. Second, if I may ask, I have a personal request for the next version of your plugin. I would like to read back the actual throttle of my vehicle. This would not be the input command, but the value from FlightCtrlState. http://wiki.kerbalspaceprogram.com/wiki/API:FlightCtrlState I considered modifying your source code (which is feasible for me) but if you could be so kind to add this call in your source code I could avoid a fork. Code would be something like #region outputs . . KSPSerialPort.VData.Throttle = (float)FlightCtrlState.mainThrottle; Of course this would require adding Throttle to the struct in both C# for KSP and C for Arduino. I have this wonderful 0-100% analog dial I want to use to display the current throttle, independent from the control mode. Pictures will follow very soon! Thanks in advance cm2227 Edit: And if I happen to motivate you on changing your code, you might consider my even wilder personal request to add the total mass of the current vessel to the VData packet from ActiveVessel.GetTotalMass().

Maybe I can inspire you with my intentions for expanding my project. The second arduino in my console (the module I named COLOSSUS) will read a precomputed ascent trajectory calculated by Ascent Komputron from a SD card. It then gives you ascent guidance by displaying the desired pitch angle for your trajectory at the current altitude. More interesting for you is that Ascent Komputron has thrust data for all stages available // KHDL description of vessel "Kerbal X" with final sequence stage = 4 // Komputron version: 1.4.2.0, file generated on 12/18/2014 12:13:12 PM // This is an automatic conversion: please make sure the source design is compliant with the conversion rules and check the results for consistency << VESSEL=Kerbal_X DRYMASS=46.820 DRYDRAG=0.1945 // Region #5, 2 parts // Region is treated as payload, total mass = 4.300t << // 1 x Mk1-2 Command Pod // Region #4, 14 parts // Region is treated as payload, total mass = 11.700t << // 1 x Rockomax X200-16 Fuel Tank, resources = [LiquidFuel / Oxidizer] // 1 x Rockomax "Poodle" Liquid Engine, propellants = [LiquidFuel / Oxidizer] // Region #3, 14 parts, dry mass = 12.520t // Region not decoupled << // 1 x Rockomax "Mainsail" Liquid Engine, propellants = [LiquidFuel / Oxidizer] ENGINE=LFE3_8 THRUST=1500.000 VACISP=360.000 KSLISP=320.000 // 3 x Rockomax X200-32 Fuel Tank, resources = [LiquidFuel / Oxidizer] TANK=LFT3 FUEL=48.000 FUELDRAG=0.2000 RESERVE=0.000 CONNECTSRC=LFT3 CONNECTDEST=LFE3_8 From this data you can read dry weight and thrust of the vehicle and the individual stages. I let my arduinos communicate on i2c bus and share that information. One day I want to see chamber pressure and temperature on my console and have status lights for individual engines. One day...

I have a similar problem with an almost antique amp meter. It seems to be more common than I thought. Damn, I trusted analog meters for years before I got my digital multimeter!

Thank you for the compliment. I thought about disassembling the X-52 but I probably won't do it. You see, I started this project without a plan. I just but my joysticks on a board, and I left the joysticks intact because I didn't know how it would turn out - I expected me to take it apart after a few days. No its been 18 months that I'm working on this console, and my plans and specifications still change every time I lay my hands on the project. I didn't even find out about the holes for mounting the joystick until after I encased them in wood. And I don't see much potential for a sleeker setup. I could gain area or depth, if you know what I mean. Area doesn't help me much, as I still have space free on the level part of the panel. More switches there would take up arm rest space. And I don't think I could gain more than a few millimeters of installation depth, and then? The distance between the base board and the wooden panel is already fixed. Hardware cost is not that much, I'd say 150€ without the X-52. Of course I spent more on materials wasted, tools and components never installed. I bought extensive collections of resistors, capacitors and other components because I need the variety. Oh and for the MFD, that only works with the X-52 pro which I don't own. So it's just a clock and a stopwatch. But a good pilot needs a stopwatch and track of time on his home planet

I also settled for a solution with two separate joysticks (actually switches) for translation control. This has two reasons. No. 1 is that in reality RCS has no throttle, so you don't need analog input for translation. Second reason is I can't handle rotation and translation at once, it just puts too much stress on me. You can see my joysticks in my hardware thread. At first I had two full joysticks where I used one twist rudder as up/down control.

So, here's my update "soon" - five months later. I made a new EECOM panel with consumables LCD, switches and voltmeter as battery and generation/drain gauge. The right most switch will toggle between battery level and power generation or drain.

Dear Mulbin, please change my project picture: http://i.imgur.com/o5MjOxF.jpg Thanks!

Look at controls() and MainControls() in output.ino. These values are not pin assignments but indicate which bit of the control byte represents the status of which system.

Well, that's a little embarrassing. I missed out on the update introducing the control modes. So to say, my problem is already solved! Thanks for pointing that out. Now back to soldering...

Hello Zitronen, do you think it is possible to add a way of enabling or disabling control of inputs with a control packet? <bool name="ThrottleEnable">0</bool> <bool name="PitchEnable">0</bool> <bool name="RollEnable">0</bool> <bool name="YawEnable">0</bool> <bool name="TXEnable">0</bool> <bool name="TYEnable">0</bool> <bool name="TZEnable">0</bool> You could use one of the additional control bytes bit wise. I think it would be a huge advantage for autopilot-style applications, to be able to explicitly switch control from the pilot to the arduino and back by software.