Antipaten

Ah! I didn't have the Tux lib. Classic RTFM error. Problem solved. Thanks!

KSP hangs at startup and complains that StageRecovery.dll version 1.9.5.3 isn't compatible with version 1.11.2 of KSP. :-(

Is this mod still alive? It's the best addon available for simpit builders and I really really miss it...

Depending on what you want to do you can handle a lot of calculations with simple fixed point arithmetics. Convert from float to integer, shift left ten bits (equivalent to multiplying with 1024) and you get approximately four decimals to work with, do your arithmetics, convert to a float and divide by 1024 and you get your result. You have to be aware of precision loss when multiplying and dividing to know how many decimals are actually valid in the end, but it makes a big difference in speed.

I haven't tried using the OneWire interface myself but I recommend that you start by using another pin. Pin 13 is also used for the red LED and the fact that there is a LED and a resistor connected to it can really screw things up. Use a clean I/O pin.

If it's a display that use modern bright LEDs and not stuff from the 80's they should be fully readable at 2mA. I use 4.7kOhm resistors for all my new LEDs and they are clearly visible as long as there isn't direct sunlight shining on them. If you can use 2mA you'll be looking at a total of only 60mA per display.

The first thing you learn when you´re finished building your panel is that you´ll never be finished building your panel.

I had the same problem which is why I decided to go for joystick emulation on the Arduino instead. That way I can emulate 32 buttons using this Joystick library: https://github.com/MHeironimus/ArduinoJoystickLibrary If you need more buttons, you may add another joystick device to the Arduino USB HID definition, which has proven to be a bit flaky, or you add another arduino and let it emulate another joystick, which work like a charm. Just map the joystick buttons instead of keyboard keys and it works like a charm. A note however is that if you use AGextended you can only map 20 buttons (if I remember correctly) from each joystick so in order to map 42 keys you may have to add a third Arduino.

Did likewise. Great building material. :-)

KSP is problematic in that way. After days of trying to get it to accept different combinations of ctrl, alt and shift modifiers I finally gave up on trying to use keyboard commands. The approach also added the problem of my controller sending commands that other programs would try to interpret if they inadvertently was in focus when I threw a switch. What I finally did was to emulate a joystick with 7 axes and 32 buttons and map most of the controls to a joystick button or axis. It looks like the most promising solution so far. For everything that cannot be mapped to a joystick i plan to use the kRPC mod. I tried using the Action Groups Extended mod for a while, but it drove me crazy having to map all those action groups, not only every time I built a new roscket, but every time Windows decided it would re-enumerate my joystick to a new ID (which happens fairly often after recompiling the Arduino software and every time I make changes to the USB HID definition).

Unless I borked my test this time, It's officially broken in 1.2. I tried it with MM 2.7.1 and it barfed exceptions all over and the engine kept burning bright after staging. :-(

If you want to use a serial connection with kRPC you need to make a server side script to manage serial communication. It should be possible, but I haven't tried it, to communicate directly using a Protocol Buffers library on the Arduino and add either a WiFi or an Ethernet adapter to the Arduino, but I haven't tried that as my goal is to be able to connect my control panel with a single USB cable to the computer for both data and power.

The K-42 TNG is off the ground. I decided to rework a few things in my current control panel and ended up scrapping almost all of it. I will go much slower this time and do some thinking and playing between each milestone in my build to avoid putting a weeks work into something that clashes with reality. First thing I learned from the first build was that complexity i a P.I.T.A. and should be avoided. The new take means no mod dependencies unless really necessary and if mods are needed, no tedious configuration for each ship in order of getting everything to work. First milestone that I mention in my late(-st) blog entry has already been reached and I have built the manual controls. I will not state that they work flawlessly yet, but they work well enough to retire my Saitek flight stick as the main controller for KSP. The new manual controls are logically equivalent to a seven axis controller with 17 buttons when detected on the USB bus so it has NO mod requirements at all in order to get it to work in the game. I will probably stick with the instrumentation provided in the game GUI for most parts instead of making pjysical displays for everything already implemented, but I will add a few extra readouts that I find useful to display in MechJeb when I fly manually. For this I will use kRPC wgich seems to work really well with no lag at all since multithreading in 1.2 became available. I also got my hands on a second NVIDIA 580 GTX just for running PhysX. I wish I could connect both 580's together but my motherboard have no support for SLI and I don't want to spend the money for a new one. I wish I had checked that detail before ordering the SLI connector though. EDIT: I thought I would embed a picture of how i currently looks but the rectal orifices at Google have decided to kill Picasa and block hotlinking to pictures in Google Pics. Anyway, try this link. Maybe it works, maybe it doesn't. https://lh3.googleusercontent.com/NlvoVB_HQP7KfFw2LwpISA-BnioENOsmWfPje8oNcjkURVgpf6imaL20LthDBa1Lz1dtAlW16CFQwuja2l6nGllm57pqAX2NN7POagaGaA4sMgR545cIc3oopwHySzJr-LL9nVp2Ypqsp1ccAEzH9FFHwYAitaMmQgGEK5UFEa85rt2w47PkvoMfNP-PnPkJYiOD0X_OSxSatVhVGO3DWkp0DzcDRvXO8EtjFjHGSU2r6ozTo51yMudXdRIel2L7Yr6TIUoC8uJH1pkSaVTt6U6h7UlVIW2ufMBWe2ji5NisUiZXzWVS_3C3wz0Fgeke6oClsIKAF9V9HF0H6rsM4nFatjW8CBZeh35YQWNsdr60F3LsioHZT_AfvxHMPTqPTwpmyycANj1qc1CxU-YOlv4nwLIJTcfCgh_bExOl7_CWZej1ENT7aIMVwk5qM1aJq6byqGrzI5OMZFwp-sm9KrU-axrQe_BUpNSLuCDUuIcs5Eqp7mm0v7zsqy_yhiX9GzkLTrHg6jSHn0xrKGK0vAlmQEZopB7LupC3tW54EKHyJ80_X3DLlphf6uB30R9ZCRmu6mk5ivJt8c-tscs4ajGDUamhdoSXEK2phgyehyw5u_aW=w640-h480-no

The problem with LED:s is that, unlike incandescent light sources that emits black body radiation over a broad spectrum of frequencies, LED:s are resonators that emits only a narrow spectrum. They are not as good resonators as quartz crystals though, so the signal spectrum is much wider. This is a typical spectrum of a yellow LED: Any green filter will let the green part of the light throug, but there is very little of it, hence the light will only contain dull drab dirty remains of the emitted spectrum that leaks through as yellowish green (the filter isn't ideal either and will let a broad spectrum centered at green through). The light from a lightbulb (a flashlight in this case) is completely different from the LED: The curve is almost the ideal gaussian distribution that we should expect from a heat source at around 2700 kelvin but the enclosure of the bulb does some filtering by absorbing some of the visible light which is converted into heat causing the peak of infrared at 800nm. This light can be filtered without problem as there are plenty of light left when removing most of what lies outside of the 530-550nm that we sense as green. Spectrums linked from http://www.kerrywong.com/2015/08/16/yet-another-scanning-monochromator-build/ where there's a lot more measurements to see if you're interested.

Hi @djungelorm! I'm currently in the planning stage of hardware modules for my new control panel and had these crazy ideas about being able to pump fuel around or control docking ports using actual switches that say "click". A problem is that there's no way to identify which part is selected as all docking ports and fuel tanks of the same type have identical names. Would it be possible to add a function in the Parts class for turning highlighting off and on for a specific part? Pretty please with sugar on top?

Not in 1.0.x. I'll return to it in 1.1.x when I get to the instrumentation part of the rebuild. Hopefully it will run smoother now that it uses those other three cores of my CPU. There's some lagging sometimes in the current version (1.1.3) sometimes even without kRPC but it usually stops if I just switch between vessel and map views a few times. The current code cleaning for 1.2 should make everything run even better and give me some margins for RPC calls that wasn't there before. The current part of the project don't require any output from the game as it is just a joystick with some extra bells and whistles.

You´re not alone. I was amazed how things had changed when I took up digital electronics last summer after a 25 year hiatus. Everything can be purchased for peanuts from China and is delivered as fast as national mail order "in the days". LED's are ten times as bright or can be driven by one tenth the current of what they used to be. Almost anything can be done with $2 micro controllers that are almost as powerful as the $300 VIC-20 computer I learned to program in the mid 80's. Now I can risk letting the magic blue smoke out of every component I use. If it burns, there's plenty more to buy cheap where it came from. By the way. I just finished the communication code for my new take at the K-42 console. I've decided to do an almost complete remake of my modules after the initial learning experience. The first part is a clean 3 stick joystick controller for rotation and translation. After that I'll probably start on the instrumentation. When I've all that upp and running, I'll start planning a basic flight computer that can be used for automated launches, node burns and maybe soft touchdowns.

You don't need an advanced mechanical solution to handle two spools of tape with step motors. All you need is a spring loaded wheel that take up the slack of the tape that is caused by rounding errors between the two step motors. Put two sensors (optical or microswitches or whatever) that detects maximum and minimum allowable tape slack and adjust the relative speed of the reels when you reach one of the limits. The simplest algorithm should be to just stop one of the reels for a few steps when the slack is too small or too big. EDIT: You need indexing on the tape too in order to adjust for the changing tape feed per step, unless you add a third step motor and another slack roll.

Telemachus is alive and got an update quite recently. It seems like there are a few bugs in 1.1.2 still, but someone is workin on it again.

You could try to find someone who can 3D print rubber and print out custom stamps. Not sure if the rubber available for 3D printing works for stamps though, but it may be worth investigating.

Hey! I didn't mean you should stop writing in this thread. Without you it would be all but dead. (Oh! That was a rhyme. I'm a poet and I didn't know'et) :-)

You really own this thread @richfiles. With your work schedule and the level of perfection you aspire for. I wonder if you ever will have time to actually play the game, but I sure like reading your posts. They are really inspirational. I myself have a much lower level of productivity and mental energy and will probably stay at a much lower level of customization of parts in order to have a playable simpit some time within my own lifetime.

When thinking about it, I did my experiment at fairly high speed in dense atmo. I realize that I detached an almost full fuel tank with an engine from the large octo probe core. The core was probably so light that drag kept it pressed against the lower stage. I'll check again because I suspect you're right and it was bad testing on my part. EDIT: I've tried again in the upper atmo. You're right. It works perfectly to my absolute delight. Sorry for the desinformation.

Doesn't work in 1.1.0. Cuts engine but not thrust!?! I guess that's the end of this one unless someone picks i up and rewrites it. :-( EDIT: This is plainly wrong due to... stupidity.

Someone was working on integrating Mechjeb controls to kRPC a couple of months ago. I don't know if the patch has made it into the official release but there was a working fork done for 1.0.5 last time I checked.