gremlinWrangler

A suggestion for mysterious halting is to do something like lcd.print(millis()/100); This will print time since start in tenths of seconds and will tell you if your arduino is halting, or the KSP plugin. Most of my finished display projects do something like blink a pixel or toggle 1 to 0 to make it obvious things are still running. A suggestion while you sort this out is to print debug to line 1 of the LCD and KSP data to line 0 or similar. Hopefully prevent overwrites of something critical to understanding what is happening. For a halt after 40 seconds the normal contenders are overflow or memory exhaustion of some sort, in particular how often is that lcd.print block happening? You should only update it once for each data packet from KSP but suspect that is being updated faster than that at the moment which may be disrupting things.

@Reckental you probably want to start here then you test that your LCD actually works. That done you would add pretty much what you have in your post there, other than lcd.begin belongs under setup so it only runs once. Been a while since I looked at i2C LCD printing and long/floats and you may need to customise a print function for them to get reliable placement of the decimal point. For the moment would suggest lcd.print(floor(VData.AP); to just strip the decimal point.

Yep, but I've already got left over square pixels, and options to fab precisely spaced square holes. So it's working for me. That said, if I was starting over I'm thinking those strands you've got would be the way to go for a bullet proof build that allows round holes and less critical spacing. Those spots where they join strips often produce a step in the length which can be fun if you don't plan ahead. What I want now is a similar strip of serial addressable inputs, so you run one behind your panel as a snake, jumper your buttons to it, and clock all your inputs in as SPI on a couple of pins. At least for things like gear select or action buttons that don't need really low latency but you do want a simple wiring harness.

Re excessive wiring I like using the keypad library http://playground.arduino.cc/Code/Keypad Or more precisely it's teensy equivalent - unsure if the linked library has any gotchas on a mega. Especially good if my buttons will be in a physical grid, just screw them in on a 45 degree angle and run wires vertically and horizontally. It's way less fun when you want to wire 12 buttons in a row as a 3*4 matrix. I've also moved to LED strips/pixels for my panel LEDs, see adafruits neopixels/dotstars and the ebay generics they are branded from (WS2812/AP102 I think). I just make my indicators and switches round numbers of pixels apart, and glue the strip behind the panel in one go. Even if I'm 'wasting' every other pixel (where buttons are bigger than normal) it's still way fewer wires to keep track of, and I'm ok trade money for time and reliability in a case like this. Similar to the serial chips mentioned above you could also buy a 'bare' Arduino of choice and use it as a port expander, say dedicated just to capturing all the inputs from the joystick and spitting them out on a serial port or i2C

Other than the structs thing have had no hassles with my Teensy 3.6 on early 2017 version of the library. @happytor if you have a 3.3. volt FTDI USB<->serial adaptor editing can be a lot less painful if you point KSP io at the adapter where it can happily stream serial data and leave you with the Teensy USB to program and debug. Also if trying to do use the floating point unit don't forget to use the floating point unit commands (sqrtf for example), otherwise it assumes you wanted double and does them the long way.

Simple method to convert a current meter to volts, assuming it's a 5V Arduino and the meter movement is a perfect zero ohms. Target pegging meter current is 0.0001 A Ohms law says R = Voltage/Current R= 5V/0.0001A R= 50 000 4= 50k Don't have the table handy but think the nearest standard size is 47K, which will mean the needle may peg a bit early, then again we probably don't have a perfect 5V drive and the meter resistance will be adding as well. If it's not quite right change resistance or put a trim pot in there as well. Since all analog meters are actually current devices you can normally convert any meter into any other sort of meter by changing resistor values around/moving shunts so if you find a cool looking coil meters for the right price you can probably convert it to Arduino drive without too much trouble unless it's a truly massive mains voltage device designed to have serious currents directly driven through it with no series resistor.

@Sputnix - yes that's the Teensy that I used to drive things. The T3.2 is much more mature for all the other bits and piece's you'd use in a control panel but was looking for a project to stretch it's legs, hence trying to do the needlessly complex spherical render. Would be far more sensible to do what generations of aircraft HUD designers have done for displaying heading/pitch/roll and run separate heading and pitch lines across a rectangular display and keep all the math simple. Where's the fun in sensible though, this is a game about exploding rockets!

Re hardware choice, Pi et al is valid but if doing so I'd probably skip KSPIO and use telemechus via browser. Pi's and similar don't do real time interaction that well so since I wanted anlog gauges , 7 segment displays with lots of buttons and lights an Arduino got me where I needed with the programing skills I had. Someone with better python/java etc skills would make different choices for the same outcome. On a related comment that may have already come up for people using DUEs or other native USB boards, it can make life a lot easier to prototype using a seperate FTDI cable running to a hardware serial port (normally Serial1) for KSPIO. That means the serial port KSP uses stays static while you reprogram your Arduino via USB, and also leaves the Arduino serial port free for debug information on what the board is up to.

Re getting vector information for display I'm cheating: float currentLat = VData.Lat/180*PI; float currentLong = VData.Lon/180*PI; float NorthAngularChange = currentLat-oldLat; float eastAngularChange = currentLong-oldLong; float northSpeed = sinf(NorthAngularChange)*(VData.Alt+600000)/lastLatData*1000; float eastSpeed = sinf(eastAngularChange)*(VData.Alt+600000)/lastLatData*1000; Gets north and east speeds, and we already have the vertical speed so can place to/from vectors on the nav ball. This means it's dependent on the update rate and needing that 600k replaced when sphere of influence changes. What it should be doing is using the orbital elements but my math wasn't up to the job of converting that data into current vectors.

Hi, just to chip into the 'how much horse power' question have a work in progress panel based on the Teensy 32 bit Arduino offshoots. The current generation runs 180mhz and has a floating point unit, also natively supports USB interaction so bypasses the windows input problem by sending keypresses when I press buttons. That gave me enough processing and RAM to have a colour LCD showing a rendered spherical navball. Made more fun by the fact that some of the pointing information for vectors wasn't available so had to process it out. My vector math was a touch rusty. So yes with more horsepower you can do more interesting things without having to spend ages optimising code. Critical thing for anybody moving to 32 bit CPUS is that you need to add struct __attribute__((__packed__)) VesselData To your message structure definition in the Arduino code, otherwise all the bytes in the message get mixed together.