Background_nose

This stuff is pretty new to me so its taking a little time. I have an external program running that communicates with KSP and renders a navball. From this program I will communicate with the arduino. Some basic communication is now happening, but my noobishness at arduino programming is slowing things down. There will be coder to share shortly!

I thought I would weigh in with where I have got to. I have been taking a different route to Cydonian Monk and feel like I'm making some progress. I have solved the problem by creating a new program that runs independently from KSP. This program controls all arduino communications and in addition displays a homebrewed Navball. KSP then communicates with this program by sending out and receiving the necessary data via UDP to the local 127.0.0.1 address. The code is still very much in an embryonic state and I'm calling it successful purely on the back of sending Roll, Pitch, Yaw data from KSP to the Navball Program this morning. There may well be trouble ahead I haven't found yet. The solution isn't elegant but for me it is great. I need to draw a navball on a separate monitor from KSP anyway, so it makes sense to have this program control arduino IO as well, away from KSP's oppressive security regime that has been causing problems. I'll publish some code once I have a more complete version working, with 2 way communication between the Ardiuno and KSP. But it is all simple stuff.

Since then I have stripped out windows specific stuff to the point that It fails to open a port as the name I am passing to SerialPort.Open() is not in the IP:PORT format it expects. Which is where I got stuck for the day. I can't grok how they go from a "/dev/tty..." style port (or even "COM1" style) to this format. Which I am guessing means I have fundamentally misunderstood something. I think I will try to get it running under windows and use prints to see how things are changing, then try to follow that under OSX. I would love to see what your approach has been and how far you've got to direct my own efforts. I've skim read through the the past few pages, but I will sit down and try to follow this thread in depth to catch up. If you could zip up your modifications that would be great to read through. Many thanks.

Hi, I thought I would poke my head in as I too am trying to get this working with OSX. I *believe* I am making progress by simplifying and stripping down the port selection to a hard coded port name. For me this is "/dev/cu.usbmodem1411" which is found from the arduino IDE. Doing this allows all the registry check to be stripped out and the port name set. Unfortunately this crude change hasn't completely worked and I have become a bit stuck. The log now reports: [Log]: Error opening serial port /dev/cu.usbmodem1411: kernel32 The stack trace is perhaps more interesting: [Log]: Stack Trace: at (wrapper managed-to-native) OpenNETCF.IO.Serial.Port:LocalAlloc (int,int) at OpenNETCF.IO.Serial.Port.Open () [0x00000] in <filename unknown>:0 at OpenNETCF.IO.Ports.Streams.WinStream..ctor (Int32 baudRate, Int32 dataBits, Boolean discardNull, Boolean dtrEnable, Handshake handshake, Parity parity, Byte parityReplace, System.String portName, Int32 readBufferSize, Int32 readTimeout, Int32 receivedBytesThreshold, Boolean rtsEnable, StopBits stopBits, Int32 writeBufferSize, Int32 writeTimeout) [0x00000] in <filename unknown>:0 at OpenNETCF.IO.Ports.SerialPort.Open () [0x00000] in <filename unknown>:0 at KSPSerialIO.KSPSerialPort.Awake () [0x00000] in <filename unknown>:0 This suggests that there is still some windows stuffs going on here in WinStream. It seems looking at the code that LocalAlloc is not good. This apparently should be changed to "calloc". I've located the source to OpenNETCF.IO.Ports and I'm thinking of trying to make the changes necessary to fix this. Does this seem to others to be sensible? I've not messed around with code like this before.