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.

And regarding my project, I'll do an update soon.

Oh, I only now realized you replied to that thread. Well, there you go. The Arduino software version running on the photos is luminous04a. See https://github.com/cm2227/Arduino/tree/master/luminous04a for source code. Just a little bit of explanation on the code. It does much more than just display some numbers on an LCD. It reads switches and controls some status LEDs, as well as an analog output. Basically you can just run take Zitronens code https://github.com/zitron-git/KSPSerialIO and add the LCD Library. In the header of my main file I include the LiquidCrystal library and initialize 2 LCDs (eecom and pilot) in 4bit mode: // include the library code: #include <LiquidCrystal.h> // initialize the library with the numbers of the interface pins LiquidCrystal eecom(23, 25, 27, 29, 31, 33); LiquidCrystal pilot(22, 24, 26, 28, 30, 32); Now some lines from my void setup(), I left out some less important lines. It sets up the serial connection and starts to write a Title, Monopropellant and electric charge as static text to the EECOM LCD. void setup(){ Serial.begin(9600); // set up the LCD's number of columns and rows: eecom.begin(20, 4); // Print a message to the LCD. eecom.setCursor(0,0); eecom.print("Luminous04a EECOM"); eecom.setCursor(0,1); eecom.print("ECharge "); eecom.setCursor(0,2); eecom.print("MProp "); } In the loop() section I show you as an example how I update the EECOM LCD in every cycle: // update EECOM display eecom.setCursor(8,1); eecom.print(VData.ECharge); eecom.print("/"); eecom.print(VData.EChargeTot,0); eecom.setCursor(6,2); eecom.print(VData.MonoProp); eecom.print("/"); eecom.print(VData.MonoPropTot,0); eecom.setCursor(0, 3); eecom.print("MET: "); eecom.print(VData.MissionTime,0); And yes, the "MET:" text can be moved to the static text in the setup() routine, as it doesnt't have to be refreshed but stays the same throughout the mission. For the pilot LCD I have different routines, where the displayed information depends on switch states where the pilot selects between different sets of data. Does this help?

Guys, just a quick heads-up from me. I'm currently working on the seven segment displays, and I'm pretty sure I'll accomplish what I've planned. And there are people out there who don't know much about digital electronics. Yes, it is definitely possible to use a Max 7219 IC with common anode displays.

Sounds great! I just read this in Samuel L. Jackson voice.

This time I have a serious suggestion for improvement, which imho should find its way to your main release. You know I've been working on setups where more than one arduino is involved, which requires one unit to handle the serial communication with KSPSerialIO and the distribution to the other Arduinos. What puzzles me is that you developed a cool architecture with the three packet types, but then give the vessel data and the control packet the same id. For exchange of information it would be easier to have the id byte distinguish between CPacket and VData.

Daughter in a sling sounds like buddy ejection seats. I don't dare to think about permanent decals and labels yet. I changed my plans too often to think I can finalize anything at this point.

Afaik COM3 is an internal modem on the laptop I use for the dev work. My gaming pc should have no devices except for the hardware COM1 and the arduino. The point is: I would prefer if KSPSerialIO would try no other COM port than the one listed in config.xml. But I should be able to change that myself in the config file or even add an option wether your code should scan the COM ports or use nothing but the default. Okay, the Mission time issue is something different. I forgot to specify the base of the unsigned long integer. Now it works. Somehow. Not really. I'll look into it, but it doesn't seem to be your fault in any way.

Zitronen I have two simple followup-questions. 1) How many bytes does the VesselData packet usually have? I'm trying to find out the minimal baud rate I need, as higher baud rates and update rates seem to be unstable on my arduino code, probably because I have several modules for display on LCDs and LEDs which result in a significantly lower loop rate than in your example, I guess. 2) At which point is the config file read by your plugin? I don't think it is possible to change for example the baud rate without restarting KSP. And you might consider an option in your plugin to not scan for the correct com port but use the default provided in the config file and just retry that connection every other second until it works. Problem is somehow your plugin considers the internal modem of my laptop a serial display and continues to use the wrong COM port until I restart KSP. Forget Question 1), it's 165 bytes. It seems that 9600 Baud and 0.5 seconds is working fine, 9600 Baud and 0.2 seconds interval is too much. Damn. Math says 165 bytes times 5 would still be well below 9600 baud, but at those settings KSPSerialIO tries to connect at the wrong COM port (3 instead of 2) which I consider a handshake issue. But don't forget: I achieved a huge milstone today, which I owe to you and your work. Actually a third question came up. VData.MissionTime seems to contain unreadable Data, as my LCD turns the raw value into a single chinese character. Any suggestions on troubleshooting? By the way, I managed to make one arduino handle all data and handshake and simply write all data received to Serial1 for the second arduino. So having multiple serial connections on your plugin is no more an issue for me.

I think I have to look into how your code determines the COM port it is using. I set up my arduino on a USB TTL converter adressed COM6 and changed the default com port in config.xml to COM6. Now when I start the game scene KSPSerialIO claims to have established a connection on COM3 (which is not listed in device manager) and prints [Log]: KSPSerialIO: Handshake received - 123, but the arduino (of course) does nothing. Okay, just take this as some sort of bug report. I now tried another configuration. Regarding what I posted yesterday about the reboots I suspected a power supply issue and added external DC 7.5 Volts. Now the arduino still reboots several times during the loading screen, but IT WORKS INGAME as desired, with my modified code for LCDs. Now I have to raise baud rate and update interval, which I lowered when I suspected a bad connection issue. Zitronen, you are still very helpful and responsive considering you are doing it for fun and free. Thanks alot, man!

Zitronen we've had a problem. I start the simulation, KSPSerialIO states it opened the com port, and the green LED indication connection is on. I can read true numbers on my displays (like AP and PE), and then the connection LED goes off but still the RX blinks. It never stops blinking, but the numbers remain static until at a random point in the next minutes the green light goes back on and the numbers are updated, but only once. It seems the connection is somehow erratic. From your experience, do you know possible causes for this behaviour? Thanks alot for your help! Strange behaviour just observed: The arduino did four resets between Space Center an the loaded scene, and then KSPSerialIO said there was no display found. Very strange.