Sputnix

I've randomly discovered the 'basic engine' board; which has an RCA video out - maybe that could be used to somehow purpose this monitor? https://basicengine.org/

Just as a tip, what I found helped was doing a handful of the Tutorials on the Arduino website. Get comfortable with the code, and how physically connecting things works. Then when you jump into someone elses code, you can decipher it much easier! At the top of "KSPIODemo16' you have: //pins for LEDs #define GLED 5 #define YLED 6 #define RLED 7 #define SASLED 11 #define RCSLED 12 #define CG1LED 13 //pins for input #define SASPIN 8 #define RCSPIN 9 #define CG1PIN 10 #define THROTTLEPIN 0 This is the nicest and easiest way to 'store' the pin numbers as a text variable, so you can reference them more easily in the code. By default, the switch to turn on SAS plugs into pin 8 [#define SASPIN 8]; The switch to turn on RCS plugs into pin 9 [#define RCSPIN 9] Then jump over to the 'output' tab, and you will see if (digitalRead(SASPIN)) { //--------- This is how you do main controls MainControls(SAS, HIGH); setSASMode(SMSAS); //setting SAS mode //setNavballMode(NAVBallSURFACE); //setting navball mode } else { //setNavballMode(NAVBallTARGET); MainControls(SAS, LOW); } if (digitalRead(RCSPIN)) MainControls(RCS, HIGH); else MainControls(RCS, LOW); I will do a tutorial video in the next little while (this is something I wanted to do for a long time) which will explain the code... but honestly, most people here have fought with the code and figured it out! ) But basically, the first part looks at the switch connected to pin 8 (SASPIN) and works out if it is HIGH - that is, is there current going to it. If so, it will send a signal to the game to enable SAS. Same for the RCS. If this is clear as mud, you should go check out those arduino tutorials The 'utilities' tab controls the LEDs that are connected. Once again, you will see a relationship between the code, and the 'defining' of the variables to pins on the board on that first 'KSPIODemo16' tab.

So apparently you have it in a folder called: "KSPSerialIO-master" (line 79) Try renaming that to just "KSPSerialIO" Because there's nothing actually happening in yours otherwise. Not even an attempt; In a non-connection, you'll have: [LOG 17:21:08.332] [AddonLoader]: Instantiating addon 'KSPSerialPort' from assembly 'KSPSerialIO' [LOG 17:21:08.334] KSPSerialIO: Version 0.19.0 [LOG 17:21:08.334] KSPSerialIO: Getting serial ports... [LOG 17:21:08.334] KSPSerialIO: Output packet size: 200/255 [LOG 17:21:08.335] KSPSerialIO: Found 2 serial ports [LOG 17:21:08.335] KSPSerialIO: trying default port COM7 [LOG 17:21:08.347] Error opening serial port COM7: CreateFile Failed: 2 [LOG 17:21:08.348] KSPSerialIO: trying port \Device\Serial0 - COM1 [LOG 17:21:12.857] KSPSerialIO: KSP Display not found [LOG 17:21:12.857] [AddonLoader]: Instantiating addon 'KSPSerialIO' from assembly 'KSPSerialIO' A successful connection will have: [LOG 20:04:57.422] [AddonLoader]: Instantiating addon 'KSPSerialPort' from assembly 'KSPSerialIO' [LOG 20:04:57.423] KSPSerialIO: Version 0.19.0 [LOG 20:04:57.423] KSPSerialIO: Getting serial ports... [LOG 20:04:57.423] KSPSerialIO: Output packet size: 200/255 [LOG 20:04:57.425] KSPSerialIO: Found 3 serial ports [LOG 20:04:57.425] KSPSerialIO: trying default port COM7 [LOG 20:05:01.452] KSPSerialIO: found KSP Display at COM7 [LOG 20:05:01.453] [AddonLoader]: Instantiating addon 'KSPSerialIO' from assembly 'KSPSerialIO' Would you agree @Freshmeat ?

Still sounds like it's probably the outstanding Win10 issue (mainly from the lack of comms). As for the Due -- watch it! It's 32Bit, so you need to adapt it slightly -- You can do a search for 'Due' in this thread / topic and see all the references and discussion. It might be tedious, but I actually encourage most to read through the 80 pages of discussion. I did that before I embarked on my journey (I think it was about 40 pages back then) - and I learned a lot, and got to know the capabilities pretty well of KSPSerialIO.

Hey All! It's been far too long (I don't even know where to begin)... Needless to say, I'd like to think I'm back I've updated to the current version of KSPIO (demo16 + KSPSerialIO_019_) -- [Well, I did just add the updated elements to my existing code, which I think was just the additional VesselData stuff; everything else looked the same] Everything seems to be working under KSP 1.4.3 (x32 / x64). One issue I've noticed (and I can't recall if this is historic - nor if it was fixed) is that when you 'switch to' vessels, there will be an initial comms with the arduino / controller, but then drop out (no active data going through); It usually re-connects, and data starts flowing both ways: however the length of time this takes varies (it's usually between 30 ~ 60 seconds) - and, add to this: it seems to be inconsistent / intermittent (it doesn't happen all the time). Has (or is) anyone else experienced this issue, or am I alone in this? It's not a big problem, and I'm happy to troubleshoot my setup to see if it's something here - in the event I'm the only one getting this!

Yeah... that would be me :'( Unfortunately, right when I was about to start the video series (I have about 3 or 4 planned) I had to move; so everything got packed up -- and I'm in the process of moving again, so now everything is in storage. Might be another couple months till I get to it. I'll start working on some of the documentation though. Will send you a PM @zitronen once I have some stuff to share

I saw that a little while back too - also felt inspired to create something similar on simpit v2 But it's only a toy Any schematics around for that bad-boy for inspiration?

Do you have a budget in mind? Logitech C920 HD Pro would be wide enough to put behind the seats to get 'cockpit' view; Then a logitech C270 could be easily modified to attach to a helmet for helmet vision... That's what I'd do most likely Alternatively, you could get a basic SD security camera of ebay; open it up from the enclosure - it's a basic board. 12volts on, and a simple composite video connection out. You could then have it attached to a multiplexing screen which also allows for single select view for 'close up' (Fill the screen). You're giving me lots of ideas for mine own (when / if I ever get a chance to build it )

Ahh, so were you using the windows screen alignment, or the Nvidia tool?

Uh, what are you referring to? I've played with the Bezel correction stuff on windows 7 x64 - still working beautifully

I take it you mean 'Hermes'? [I've not seen the movie yet - I know, shocking! - so going off best-guess here.] All I could find are these: Link 1 | Link 2 | Link 3 | Then there's this Tumblr that has a few things. Also there's "The Martian VR Experience" (on steam store, and other places) - which give you the opportunity to explore Mars + Vehicle + others in VR. Google is your friend

Believe it or not... they're next to me right now, as I'm thinking of connecting them up My biggest challenge is doing it in a way that will allow me to mount them - and deal with the fact that I've put 8x big holes in the aluminium for control-group buttons I never connected.I might use the holes to some how mount the joysticks. @AmeliaEatyaheart and @stibbons have joysticks on their controllers. They might be able to share some insight into this. AmeliaEatyaheart's | Stibbons

If you want to be smart and efficient - it'd be a neat way to save space and i/o on the board Simple switch would allow switching between... but you'd want to make sure you're in the right mode at that critical moment Wouldn't want to accidentally do an 'action' (such as separate the CM from the rest of the vessel) when you really wanted to face retrograde

You can do the maths to be exact - but that could be a possibility (with that much stuff connected to the board). Do you have external power running to the 'duino? If not, start with this. Further, you can also increase the baud rate; I run mine at 115200, and have set my refresh to "0.3" - and I found this helped with the random cut-outs. I also modified the board settings in my Arduino program files to have a 256 buffer size (like you have). Give these a shot

So, what you're asking for is a switch to change between 'surface' and 'target' modes, yeh?

Yup... that's how I'd do it or I'm also thinking of using a selector switch to activate the necessary mode - since you can only have one at a time.

I saw a video desk / mixer go for dirt cheap a couple months back; totally wanted it to salvage it for parts like you - but was interstate, and completely unrealistic to try collect. It was freakin' huge too! Proper production mixer! Ahh, yeah - I think someone here was going to do similar. I agree; plus yours uses a linear pot. I have a few of those lying around

I'm just sitting down to do some tests... hold tight Update Alrighty! It's pretty straightforward @zitronen - Just confirming, we don't need: else { CPacket.SASMode = SMOFF; } After that SASRETRO read do we? (It works both with and without... given that CPacket.SASMode = SMSAS; is set on SASPIN on, it would cause a lot of flip-flopping between the modes if SASPIN is on, but SASRETRO is off...)

Poor control board Did you get the neat buttons too? I'm actually planning something like this on my next build! Fantastic reference picture Different to how I was thinking - but definitely better!

Yeah, 1 axis is hard to find; I've gotten some of these with the intention of doing panel controls. And I still will (need to finish off v1! ). They are same style as these. My original plan was to somehow wedge / glue one axis so that it can only go in the remaining 'free' one. About the best one can do, I think!

Yup... your future reputation on this forum is now based on how well this code does or doesn't work I have faith I'll have to wire up another arduino I got lying around to do some tests -- but if @zitronen feels confident the code is good, then I think you'll be ok! Thanks for the dev

Yeah, that's the one! Gee they're quick Have you tried using in the configuration I suggested it? (Also, how did I miss that?! ) Nonsense; that's just the kerbal way

Was thinking bout your dual joystick conundrum... (can't recall if you'd solved it or not ) You could use something like this - http://www.ebay.com/itm/Black-7-Ports-USB-2-0-HUB-Splitter-Box-ON-OFF-Switches-and-LED-Lights-Power-/172257100640?hash=item281b52c360:g:CHwAAOSw5ZBWQEpO - and rewire it so you have a single 'flip switch' in the middle which would switch USB devices on / off, allowing you to switch between the joysticks? Can't seem to find any other type; I suppose you could make your own. Not sure how KSP likes devices being plugged/unplugged during game play. It should cope ok, though

What @richfiles said; Not sure of your background, so you may also like to see my overview of the in's and out's of processing / IO / instruction cycles here:

If you read thru the 60 odd pages (and I don't blame you if you didn't When I first joined up it was only about 30 I had to go thru ) - @zitronen commented: So we are running out of 'space' for what we can send / receive to the arduino and the game. Some of these are shortcuts which you could send as 'keystrokes' over the arduino; the others -- well, that's up for discussion with the almighty creator / curator