zitronen

Hey @Freshmeat @#Pseudo, can you try this: https://sites.google.com/site/zitronfiles/KSPSerialIO0188dll.zip I think the SAS problem should be fixed. I think this broke when they added the new SAS modes, and I also had some weird logic stuff in there. Not sure what I was thinking.

@Freshmeat & @#Pseudo Yeah the whole axis thing is a bit hacky. The only way I can get joystick to work is to temporarily disable SAS and turn it back on again. Not being able to toggle SAS while using the stick is just how it works, but SAS engaging by itself does seem like a bug. If this is too annoying, the better way is to use a arduino leonardo or some other 32u4 to emulate a usb joystick (it's what I use right now), which will give you the normal operation. I had a look around a while ago to see how other mods did axis control, couldn't find a better option. If someone can point me to a better solution I'll have a look.

@Osel Oh yeah, I need to update the download link. @HyperCoffee The github version has as the tweak scale implement by Osel, you can submit a pull request for the sound mod as well. I presume it doesn't cause problems for people not using the mod?

Update 0.18.7: Changes: Fixed broken axis control hooks reported by @AmeliaEatyaheart and @Freshmeat Download link: https://sites.google.com/site/zitronfiles/KSPSerialIO_018_7.zip This now becomes the recommended version, you will need the data structure from Arduino code "demo 16".

Jesus, how many wires are you.. you know what I don't even want to know . Thanks, I'll update the the recommended version to this one this weekend.

@AmeliaEatyaheart, @Freshmeat can you try this: https://sites.google.com/site/zitronfiles/KSPSerialIO.dll. You need the data struct from Demo16.

Hmm.. when you say "end up on the runway", is that a euphemism for "after it exploded" or did you actually land on the runway and it suddenly stops working? It seems like axis control hooks are not working properly, but I thought I fixed this. What happens if you switch vessel? The latest version is 0.18.6, but I have not changed anything with the axis controls since 0.18.3. Also for teensy people: I'm not 100% sure, but If you are on a teensy you should be able to run some insanely fast serial speeds with USB serial right? (if you are not using it for debugging) You should be able to crank the refresh speed up by a lot.

Cool, I think you are the only one using a teensy 3.6, let us know how it works. I'm not German. I needed a user name when I lived in Austria many years ago, and had a bottle of zitronensaft on my table...

If you are using a teensy, you will need to add struct __attribute__((__packed__)), because it is 32bit. @stibbons is the person you need to ask.

Cool thanks for that!

Someone mentioned making a video tutorial. Can't remember who or if it happened. If someone want to make one I'll put it on the first page.

Huh... you can receive the controls packet as well? Maybe fake some button or axis movement in the sketch just to be sure. But I guess if it receives the handshake then it should work. Does this mean the problem is limited to the uno's with their atmega based USB thingie?

Are you sure you are looking at target prograde and not target retrograde?

You need to use something like if (digitalRead(pin1)) { CPacket.Roll = 500; } else if (digitalRead(pin2)) { CPacket.Roll = -500; } else { CPacket.Roll = 0; }

Now on github! https://github.com/zitron-git/WheelsCollection

Sorry for the late replies, I'm away on holiday right now. I don't know much about tweakscale, I presume I just need to paste some stuff into the cfg files? Are you willing to submit a pull request with the updates if I put it on github? Cool! I don't have a logo or anything, but if you decide to make one I might steal it from you.! Yeah the base plate is pretty crude, I made that one before I started working with @electronicfox, I think it clearly shows who actually had talent in modelling & texturing! I don't think I can make one much better myself.

Oh oops I put the error message in the wrong place, so it always says 0/25. Try this version: https://sites.google.com/site/zitronfiles/KSPSerialIO_018_6b.zip But that suggests the arduino is sending packets that are not the correct length, possibly 8/32bit struct padding problem. Mine works

Update 0.18.6a: NOTE: FOR DEBUG ONLY Changes: Dumps the entire receive buffer on checksum pass/fail Output when packet size mismatch You may want to slow down the update rate of the control packet so you don't get spammed in debug log Download link: https://sites.google.com/site/zitronfiles/KSPSerialIO_018_6a.zip

what is going guys... Has anyone tested the Due on windows 7/8 just to rule out some kind of 32 bit issue? It could be caused by the new KSP update or a recent windows update or something. You can use a trim pot to get the meter scale correctly if you don't have exactly 50k resistors like @gremlinWrangler suggested.

What... Have you been drinking or taking drugs?

Can you show us what kind of meter it is? Is it a volt meter or amp meter? I'll have some time this weekend to make a debug version for you to test.

Huh? Did this just start happening all of a sudden?

Since I don't have windows 10, I can't check myself right now, but I remember we made debug versions to check what's going on. Basically nothing is received, the receive event never fires.

That looks correct? Each packet starts with "0xBE 0xEF". The control packet is shorter and is sent more frequently it will only have a lot stuff in it if you are using lots of switches and axes.

struct padding has to do with how things are stored in memory. On 32bit, when you have a struct with some bytes the compiler can choose to add padding so each individual property are 32bit long instead of 8. This is done not to just make our lives miserable, but for performance reasons. So something like struct { byte A //compiler will add padding to make this 32 bits long B } end up taking 64 bits in memory instead of 40 bits as you would expect. Obviously if you try to copy data into the struct like we are doing and the struct is not the right size you will get the wrong result. "__attribute__((__packed__))" forces the compiler to make the struct as small as possible.