richfiles

How are you doing the third axis? Is it rotation of the entire stick and assembly? I guess you could try epoxy. I'd say that's a fair bit more durable than "hot snot". Building a platform sounds decent too. It gives the joystick assembly a solid base to mount to. It's really hard to see exactly how your 1 axis is set up in the pic, so it's hard to offer too many alternatives. There is one thing I could recommend. You could make your platform to mount the stick to, and drill out a hole in the center and simply mount it onto the shaft of a potentiometer. The potentiometer ought to keep the platform and stick base upright. You could do other things to help stabilize it and keep mechanical stresses off the potentiometer too. Have you ever seen those furniture sliders? It's a little round or rectangular pad to put under furniture so it slides easily over the floor. If you mount one of those to the bottom of your platform (with a hole in the center for the potentiometer shaft to pass through, and then have it rest against the base where the potentiometer is mounted to (maybe with a felt pad to reduce noise), it will take all the forces pushing down on the assembly when you move the stick, and keep the base leveled as you move the stick around. A pair of screws or nails int he corners of the platform, and a pair of springs attached to those are all you need to keep it centered. You can easily create a deadzone in software to compensate for variation in repeatability at the home position. Your 1 axis stick might be inaccurate due to a worn potentiometer. finding a replacement for it might solve the problem of repeatability and accuracy for it. Of course, whatever materials you get have potential costs. Personally, I chose the easy route, so this is what I'm using. Far simpler than trying to build something that will see constant motion, and trying to make it both durable and accurate. The two joysticks are about $18 US off of ebay, come with rubber boots to keep dust from accumulating in the ball pivot (which is metal). They move forward and back, left and right, rotate clockwise and counter clockwise, and have a single clicky button on the top. Both of them use three 10K potentiometers for the three analog axes, and the button is just a switch. The middle device is going to be my translation (RCS) controller. It's salvaged from a Fairchild Channel F game console from the mid 1970s. It's a digital controller, but it's actually a genuine 4 axis controller... up and down, left and right, in and out, and rotate CW and CCW. I got the controller from ebay, only cause I remembered the unique controller, thanks to my owning a Channel F as a kid. It's about as close as any controller ever got to the real translation controls on the Apollo and Shuttle vessels. I have no intention of modding the controller... I just want to make an opening where it can insert through, and then have a soft clamping mechanism to secure it. It'll plug in to a DIN-9 socket on the inside of the panel. That lets me preserve a vintage video game artifact, while still making use of it. Also, preview of my next diode ROM module in the background! I'll post all that stuff in my own build thread.

Personally, I'd consider the 1 axis stick as a viable potential throttle control. The Joystick will see extensive use, and in my experience, hot glue is good for securing loose wires down, but is certainly not something well suited for structural elements. The best cheap source of 3 axis joysticks I've found happens to be ebay. Just do a search for 3 axis joystick or 4 axis joystick, and you come up with a nice 3 axis joystick with a metal shaft, metal pivot ball, and a decent finger operable handle. The "4 axis" version has a tactile pushbutton on the top. I have not decided what I want my pushbutton to do... I've considered a secondary staging button, kill throttle, abort... I'm thinking kill throttle. I already have big glowy red and green "palm slammers" as my stage and abort buttons! The ebay joysticks are pretty affordable. About $17-25, depending on seller. On a side note... It's been great knowing all you guys. In a week and a half, I will probably disappear, not to be seen again for ages. That's just what happens when a new Zelda game comes out! LOL

This seems like a great iteration of the KSP communication concept. The KSPserialIO packet size did seem like an issue. Getting one Arduino to receive and distribute everything where it needed seemed like it was becoming a more and more daunting task for the minimal CPU, and particularly RAM. My own setup would likely have had no less than four different Arduinos, all performing some beefy functions. I need one to handle my digital displays, one to handle the motor and encoder of my tape meter, one to handle my FDAI (navball), and probably one to handle switches, analog meters, joysticks, etc. Depending if the latter unit had enough spare memory or CPU cycles to send and receive packets, as well as send to secondary micros, that's a minimum of either four to five Arduinos... It's be pretty awesome to just have each one get it's own custom packets! It'd eliminate the need for a packet arbitrator.

Just sharing that I finally did it... I started my own thread for my build. Kerbal Instrument Panel: In-Desk Apollo Themed Hardware Controller doesn't have a whole lot of content yet. It's more of a preview at the moment, but since I seem to have had a huge burst of progress lately, I think it's time that I should put all build details there, and keep any posts here more restrained. Don't worry though! I ain't leaving! I'll still share any help I can offer to people with questions. I might still post SOME progress here from time to time, but It'll be lighter posts, more limited to milestones, and definitely not the huge build progress posts that I'm known for. I do think keeping the repository lively is important, but it was time... a year and a half ago... I just kept putting it off. I won't delete any posts from this thread, as those posts have served to inspire a lot of discussion, however I will likely consolidate all the data I've posted here into the new thread over time, focusing on sections of the build. And of course, all new build posts will be there.

Thanks! Be sure to visit the Custom Hardware Simpit Repository thread, as I've actually been there for a year and a half, and only just now decided to finally light my SRBs and make my own dedicated thread! Trust me, there's a lot of amazing projects there too, and a sneak peek as to what will eventually show up here! ... Also, reserving this post for future expansion if I end up needing it.

Construction of the custom desk is complete! It just needs electrical work! Electrical work is done! The Desk Has Landed! (Top shelf still needs to be installed, but that'll be done soon) Pictured above, the current (as of Dec 2020) mockup of my end goals for this project. I've been working on this project on and off since around June of 2015... I initially first appeared on Page 6 of the Simpit Repository where I showed off some really nice hardware I'd collected for the project. The goal is to create a controller using real instruments to provide readouts of orbital data, temperature, fuel, electricity, and other critical values. The controller will have joysticks and toggle switches and other controls to command the in game vessel. I'm using this project as an opportunity to force myself to learn C programming, and as a furthering of my electronics hobby. While this thread has a LONG way to go to catch up with my progress, I'll work on it over time. INSTRUMENT PANEL PROGRESS STATUS DESIGN HARDWARE SOFTWARE Assembly: Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Analog Resource Meters 0% • Vertical Velocity Meter 90% • 0% • Radar Altimeter Tape Meter 80% • 0% • DSKY Numeric Readouts 10% • DSKY Units Readouts: ------- ------- ------- Diode ROMs ------- Address Decoders 75% • 25% • 0% •/• DSKY Annunciators 90% • 75% • 0% • DSKY Keypad 90% • 90% • 0% • Delta V Carriage Meter 25% • 0% • 0% • Navball Controller: ------- ------- ------- 400Hz Sine Gen ------- 115vac Amplifier ------- Synchro Emus 25% • 0% • 5% • AUX Data Display 25% • 0% • 0% • Velocity Readout 95% • 0% • Attitude Rate Meters 50% • 0% • 0% • Bezels 10% • 0% • ------- As of September 9, 2024, the desk is fully completed! Desk -- CONTROLLER PROGRESS STATUS Not yet officially started, but many individual components and designs have been established, including the support frame. The control panel, fortunately, is a much simpler build electronics wise. It's mostly machining panels and mounting hardware. Solder all the bits together, add some communication to the instrument panel's main controller, and that's it! Part of why this has taken so long, is it's not only a learning process, but I've split my time with other projects. My custom mechanical keyboard was built to work with this Kerbal controller build, and will actually slot into the controller! The number pad magnetically detaches, so when my keyboard tray is extended, I have full use of the extended keyboard, but with the tray pushed in, I can set the number pad aside, and use only the core keyboard! This is the button that started it all. I was inspired by how AWESOME this button looked, and how big and red and "Aborty" it could potentially be! The Instrument panel enclosure is a re-purposed Harris Stereo 5 console that was saved from the local AM radio station. You can see several instruments here. On the right is my analog vertical velocity meter, and in the middle, my FDAI. The Flight Director-Attitude Indicator, more commonly known around these parts as a navball, is a real awesome find! I'm in the process of building a controller for it, but that is a daunting task... It requires nine 28 volt amplitude modulated sinusoidal outputs that are controlled by multiplying DACs, and a 115 volt sinusoidal reference source to provide both power and synchronization for all the 9 other signals. This is the keypad I made for my "DSKY", inspired by the DSKY (DiSplay KeYboard) of the Apollo Guidance Computer (AGC). It normally lights green, but can flash red if there is an alarm condition... Such as the "I'm about to pop like an overheated popcorn kernel" condition. My throttle lever (as well as the keys for my DSKY keypad) were salvaged from an old video effects controller board. I have a LOT of these relegendable, backlit push buttons, in two different sizes. My analog meters are inspired by the edgewise meters used in the Apollo Command Module, Lunar Module, and Space Shuttle. I'm taking the extra effort to print proper scales that use the Futura typeface that NASA used, and follow an overall design that visually resembles the Apollo instruments. Likewise, Tape Meters were also used as instruments on Apollo, and even more so in the first revision of the Space Shuttle, before the glass cockpit upgrades. Tape meters have a long tape on spools. The numbers scroll passed a stationary pointer, the opposite of what an analog meter does, where the pointer moves over a fixed scale. This allows very large scales to be depicted, limited only by tape length. The meter I have will be reprinted with numbers corresponding to the radar altimeter. This is the complete DSKY. I'm currently working on it, and getting it to the point where I can control all the LEDs right now. Current progress has all the large numeric LEDs controlled by MAX7219 controller chips, and the small 7 segment display and one of the three alphanumeric displays is currently functional. https://www.youtube.com/watch?v=8Cwm_xQZsFo https://www.youtube.com/watch?v=LwXZKIfvEkI https://www.youtube.com/watch?v=1Wlv3oyobcg Flashy, isn't it! I've been making diode ROMs to decode characters for some of the LEDs. These cost me literally nothing but time to make, and they satisfy my interest in basic digital circuits. I also rather find I enjoy three dimensional free form circuitry! So yeah... I'm enjoying this part! In all honesty, I really should have started this post back then! I was just collecting parts back in those days, and always said I'd start a dedicated thread when I began assembling things... The Simpit Repository is now up to 23 pages at the moment I'm typing this... It just grew to incredible proportions, and a few times I felt a little bad for dominating the thread with build posts (that really belonged here), but at the same time, I knew my work was showing other people how to do things, and keeping the Repository frequently in the lime light. It just grew to a size that felt too big to abandon, and too big to move the content. I'm starting this post, because I think this build HAS started moving at an accelerated pace, and It should have a dedicated place. I'll build this post up gradually, to cover not only the new content, but to consolidate the content I posted in the Simpit Repository here as well, so the entire build process is properly detailed. I had debated whether I should move content (remove from the Simpit Repository, and replace it here), but I think that'd be unfair to those who replied or were inspired by that content. I'll eventually consolidate everything here, but I'll leave my old posts at the Repository alone. as for new posts, I'll still post at the repository, but I'll no longer post massive multi-image mega build posts... I'll keep my posts there a bit more basic, and put the details all in this post. I'll still offer my knowledge to answer questions people have at the repository. That won't change. It's just silly that I've taken THIS LONG...

https://www.youtube.com/watch?v=LwXZKIfvEkI Enjoy the final results! I found some usable resistors and installed them onto the alphanumeric displays.That allowed me to drive the ROM at the full 5 volts and allowed the ROM to operate as designed. The irony of me making such a compact diode ROM to code my characters for the units display, is it kinda brings me full circle, all the way back to page 6 of this thread. Page 6 was the very first time I had ever commented here! Turns out my off topic comment about diode logic is FINALLY on topic! LOL **EDIT** https://www.youtube.com/watch?v=1Wlv3oyobcg Well, I guess I DO have some pics after all! I like batteries for scale reference... Everyone knows how big batteries are. Coins can be different sizes in different countries. Have the best of both worlds... A coin cell battery for scale! I went ahead and built the small diode ROM to control the "Time to" event indicator. I only needed 4 characters, but for consistency, I also added the all segments test character, and a basic dash, just because. This particular diode ROM is VERY small. It only has to drive a single 7 segment LED after all. Character test function will be it's own line that attaches to all the ROMs that I'll install. That one line will activate every segment at once.

Here's a quick tip for anyone who does have wood power tools (like a table saw or circular saw), and need to cut metal, but don't have a proper metal cutting blade. Reverse your blade. If your rough cutting blade has those carbide "chunks" at the tips, then flipping the blade so it spins backwards will let you cut metal. It'll almost certainly ruin the blade, but I've cut through 1/16 inch steel without any trouble using that method. Actually a really unique use for an old dull blade. By reversing it, the blade can't "grab" into the metal and jam, since the angle of the blade pushes the metal out of the gaps between teeth. The the carbide "chunks" at the end will still cut on the back edge, and take the fine bites out of the metal, like a fine toothed metal blade would. Of course, if you can find a proper metal cutting blade, stick with it. As for panel nomenclature, You could consider going to a shop that does silkscreening and have them do reverse art on the back side of an acrylic or polycarbonate sheet. If the text is done by either an absence of ink, or a transparent one, and the background is opaque, you can even backlight the panels. That's pretty much how it was done for the Apollo instrument panels. If you wanna keep it on the cheap side though, a quality label maker can do wonders. Another tip for those, trim the corners of your labels so they are rounded. Corners seem to peel up more easily than edges, and a rounded corner seems more resilient, and it kinda looks nice, I think.

I realized none of my pics really offered a sense of scale for my Diode ROM, so i took one next to a AA and a AAA battery for scale. Sorry, I had no bananas.

Honestly, it's hard to tell. The key will be finding an angle and camera position that lets you get as much of the controls and readouts as reasonably possible within the field of view. I'd definitely look into wide field angle security cameras, and go HD if you want to actually be able to see any details. Regarding the camera tilt angle, that's gonna be dependent on the lens you end up with, and whether you're able to catch the overhead panel, main controls, screens, etc, while avoiding seeing the back of your head. Tricky business, those camera angles!

Made even nuttier 'cause us Americans have to go and spell them both as meters

I must embarrassingly admit that I stared at this post and re-read it like THREE times, thinking to myself "Three meters of what?" Last night I built the units display decoder for my DSKY, so I have SI units on my mind, not analog meters! LOL I like the idea of the third person and helmet cam views, though I'd go nuts wearing a helmet! Could make for interesting YouTube videos, recording flights with captures of the actions in the cockpit. I know some people use cams to show themselves... Showing the cockpit controls seems very fitting. Have you considered trying to get some kind of fish eye lens so you can capture both pilot views of the main and and overhead panels. A mild fish eye would only distort things a little, but give a very wide angle. I'm not really certain what kind of wide field of view lenses are available. It would seem to me that having a camera mount on the center console (or hanging the mount from above, either way), between the seats, set back just a small amount would seem to be the simplest camera mounting position for getting both sides. So, a shorter focal length lens seems to give a wider shot. It introduces perspective distortion, but you get one of these mounted between the head position between the two seats, and it might be able to capture much of the controls for third person view. Searching for "wide view HD security camera" comes up with a few all in one solutions that are compact, and already are built for permanent mounting.

Well I'll be a Kerbal's uncle! A big fat "K" on the Altimeter! You're right! I suppose part of the reason for not noticing it, is that I spend most of my time either in LKO, or shooting out to Mm and Gm ranges via time warp. In light of my lack of perception, It now occurs to me that I'm going to have to carefully profile KSP's altimeter units display. Also, fortunately, i finally got a response on my motherboard RMA. I'll have to pay, cause I'm out of warranty, but It's worth it to be up and running again! I'll have to just record in detail when KSP likes to do it's altimeter units switches, and program my controller to match the switch points. And you prove why it was indeed wise to encode ALL the primary SI units on my hardware!

Well, I built it! I ended up encoding all the following SI prefixes, m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym, m.S, ΔV, --, as well as an all segments test character. I decided to play it safe and encode everything I might need, so it's there if I ever do need it. It's a 270 bit diode ROM matrix (100 ones, 170 zeroes). It has 30 LED segment outputs, and 13 inputs, to select each of the desired characters. I appreciate the information I got here. It certainly helped me decide to play it safe. The highest distance I think I've ever seen in a YouTube video I think ended up being Yottameters, and the game was getting pretty glitchy by then, if I recall. All in all, I don't think the game even could go higher than that, due to floating point rounding errors. These available units ought to be able to cover anything KSP throws at my controller. Here's what the diode ROM actually looks like. It took all afternoon and evening, but I finished it! It mounts directly behind the LED displays. Again, thanks for the advice and suggestions.

https://www.youtube.com/watch?v=Rjf7sO0aXUA It's ALIVE!!! My units are lit up! I really like how the units ROM turned out. The module is tiny! It's small enough to fit within the footprint of each pair of alphanumeric displays. I still have some work to do, but not much. I can either build two more of these, or try multiplexing. I built this one tonight. A complete module takes me about one full afternoon+evening, so it's not unreasonable to just build two more. It also occurs to me that the wiring to parallel up all the alphanumeric displays, while simpler, will still take some time to do, and that would still require software multiplexing control. Quite frankly... I enjoy the hardware element too much, and find software tedious. I'd say my decision is made. I'm going the multiple ROM modules route. I can control them all with a simple shift register chain. It is capable of displaying m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym, m.S, ΔV, --, as well as an all segments test character. Well, here's one complete Diode ROM module. It is a 270 bit capacity module that produces 30 LED segment outputs based on selecting one of 13 character select inputs. Thankfully, 0 bits are represented by the absence of a diode. Every zero bit makes the soldering just a bit easier! Ultimtately, there are 100 ones and 170 zeroes, so that means there are exactly 100 diodes in the complete ROM (technically, i need 8 more diodes in the interconnection between the to boards, so the final total will be 108 diodes). The module is in two segments. The larger segment drives the first alphanumeric LED display, and the smaller unit drives the second display. The sockets on the side are to interconnect the two modules into one unified module (4 required wires are not shown in the photo) It's exactly 2 inches (4.9 cm) tall and 1 inch (2.45 cm) wide. Overall both the tall and short board stacked together, it's 1.25 inches (3 cm) thick. Each board is 0.7 inches (1.7 cm) thick, but they overlap a little bit. This is essentially what's inside a mask ROM chip, only made with individual diodes. A mask ROM is simply a matrix of rows and columns with a "fuse" or diode at the intersection of every logical "one". A ROM chip contains addressing logic as well. My addressing logic will be on another board, and will consist of a pair of 74HC138 3-to-8 decoder chips and one inverter chip, per display pair. I'll use shift registers to send the 4 bit binary value for each character to display. Due to me being dumb, I forgot to install resistors before installing the socket for the ROM. This means I need to desolder the socket, install the resistors, and then reinstall the socket. It's also why I have not tested the second LED display ROM module with the first... I have tested the second character module, and it works, but I've only tested it individually. For testing I used a current limited power supply, but that only works for single diode fan-out. The second module relies on two diode fan-out when paired to the first module, and that means a voltage drop of 1.4 volts, instead of just .7 volts. That's a significant portion of the forward bias voltage for the LEDs. It means the second module wouldn't even light with my current supply setup. I need to install the current limiting resistors onto each LED pin, so I can then run the power supply at 5 volts, with no current limit. That means 3.6 volts will still reach the second module, and be enough to light the LEDs. So yeah, that's why I don't yet have pictures of the second character lit up. I'll update with those pics when I figure out the resistor values. I told you guys I was planning on utilizing "structural electronics". My struts really do perform actual logic! And boy did I add moar struts! You can see the first character module socketed onto the DSKY main board, and more specifically, how small the unit is. It's about one pin spacing taller and wider than the pair of alphanumeric displays, and vertical clearance between the displays allow the modules to be mounted adjacent to each other. One thing I'll do differently... I'll make a diode schematic for each of the four sides individually. I had to go back and fix a few rows I initially started wrong, thanks to reading the pin numbers wrong. Also why I checked each row as I soldered them in. If I didn't get a fully formed, correct character with each added row, then I fixed it before moving on.

Hmm... Maybe I should make a single diode ROM with a 4 bit character select and a 4 bit display select, and then multiplex the alphanumeric LED displays... Hmm... It'd only take a single 74HC595 and a pair of 4-to-16 decoder circuits (4x 74HC138 plus one inverter chip with at least a pair of free inverters) to address up to 16 of the alpha displays, as long as the Arduino can update it fast enough for persistence of vision. While I COULD software control it, I could also try doing a 4 bit counter and a hardware solution. It'd likely be slightly complex, but still probably a lower part count than individual diode character ROMs for each alphanumeric display. Why diode ROMs though? Cause I can. I love old school tech, and just wanna make some part of this build super old school! For now, I'm just gonna build a ROM card that can drive every character I need, and go from there. *EDIT* I did a diagram for a full ROM, and then figured out a viable layout for it. I decided to add a "segment test" character row that allows me to perform an all segments self test, and is structural! You'll get it when I have pics. My struts perform logic!

Great news! Another productive weekend! https://www.youtube.com/watch?v=8Cwm_xQZsFo The bottom row is lit, trust me... The bottom display is dim because it is running my old test program. The old test program expected a red LED display there, which was of a high brightness variety, thus the brightness was turned down in the code. it will be the same brightness as the other LEDs when the programming is updated... Something I can't do at the moment without re-downloading the Arduino software and installing it to the tablet I'm borrowing. Still haven't gotten my motherboard replaced... While I did not have time to start work on the diode ROM circuitry for character generation on the units alphanumeric displays, I did complete all the wiring for the actual numeric readout displays on my DSKY. 5 pins provides power, ground, and SPI data to drive all 5 lines of the DSKY. I'm running a burn in test as I type this, and will let it run for a while to make sure I won't have any troubles. The LED modules came from Mouser, a proper electronic components distributor, and not ebay. I expect better results from these than the Chinese garbage I got before. I actually wired the entire thing without any schematics or references. I also may have wired the displays in SPI device order from bottom to top... Oh... uhh, yeah... I totally meant to do that! And yeah... Cutting and stripping insulation from all those bits of wire, and then soldering one end to the PCB and using tweezers to hold the other end to solder it to the LEDs... It took a while. While not wired yet, I did start the basic wiring for the annunciators that label the numeric displays. This was mainly because the annunciators for apoapsis and periapsis are harder to get to than the other annunciators, due to their positioning. I wanted to get their wiring started while it was still accessible. I still need to add a resistor to each pair of LEDs, and then wire that into a transistor to drive each bank of LEDs. The annunciator LEDs vary from 2 to 8 LEDs each, and LEDs will typically be wired in banks of two in series. I'll control each transistor from either an Arduino line, or from a shift register or port expander... I have a few of the latter on hand, even if they are overkill. The diode ROM mentioned before uses diodes to selectively light segments of the alphanumeric displays to generate each unique character. Each character is selected by one signal line, and before the diodes will be a 1-of-x selection logic to convert from a source signal (probably binary coding) to the individual character select signals. It's a technique also referred to as "diode steering". I can't drive the 14 segment alphamnumeric displays with the MAX7219 boards, because they are common anode. My spool of over 9000 diodes tells me that diode ROM is how I will handle it... The other thing I need to consider is whether I need to enable the display of all SI unit prefixes or not. I'll have to do some experiments maybe, to see what units are actually displayed by KSP. I had another thread asking the question... and quite frankly, the responses left me as uncertain as I was when I posted the thread. Currently, It looks like there are 11 units to display, but not all displays must display every unit. Some displays might only ever display a single unit, and could thus be hardwired, or maybe wired for two units, switched by a single I/O line. It's hard to imagine many space vessels needing more than 99999999 m.S (the displays can do "m.S", but can't put a slash between, so no "m/S"). I suppose I could toggle "m.S" and "K.S"... that covers up to 333x the speed of light. That ought to be enough! I can also display "ΔV" on the alphanumeric displays. Again, some displays might have static hard wired characters dispalyed, or have a very limited set of possible characters displayed, but anything related to distance has to cover a wide range of scales including up to m, km, Mm, Gm, Tm, Pm, Em, Zm, and Ym. I don't know if KSP goes higher than that. The sad truth, is it's been far too long since I've played, and with my motherboard dead, it's not as simple to boot into the game. I suppose I could run it on this tablet. What that all comes down to is that there are 9 SI units... I could use 3 bit encoding if I eliminated one unit and got it down to 8. I can probably eliminate km from the apoapsis and periapsis, as the game does favor sticking to meters up to the first 999999 m. I'm not 100% certain on dropping km though... I don't think I actually need it for those readouts. If I get it to 1-of-8 encoding, then I can also use the 74HC138 3-to-8 line decoder chips I already stock (thanks to my use of them on my robots). Those chips decode 3 bit binary to 8 outputs, exactly what I'd need to drive an 8 character diode ROM.

I suppose to play it safe, I should just encode all the SI prefixes in the hardware. At least then, it's easy to let software sort it out.

I was wondering which SI prefixes KSP uses in game, and are there any that are skipped? I ask because I know it skips km on your altimeter... (I'm so wrong! i guess I must typically timewarp from LKO to any other body and never noticed Km before! LOL ). It just goes from counting hundreds of thousands of meters and then rolls over into, if I recall correctly, Megameters. After that, I know I've seen Gigameter measurements before in the map views. Does KSP skip any other units than km, or is it just that one unit that gets skipped? I think I recall seeing km used in map view for distance to target, and in standard view to show distance to other objects. I just don't know if km is used for any orbital data... Altitude, Apoapsis, Periapsis, etc. I'm currently in the process of building a digital orbital data readout to fit into a larger scale custom controller for the game. I'd like to keep the units displayed on the controller matching the units displayed on screen. It'd be disorienting to have my readout show 100 km, and the altimeter on screen say 100000 m. I know they are the same, but it's not consistent. I'm occupying myself with continuing my controller build, since my motherboard unfortunately died. It's hard to run KSP to check for units of measure when your computer ain't even functioning. Who knows... Maybe I can get some progress in before the motherboard is repaired/replaced. Adittionally, I also wonder how high do the SI prefixes go? I want my readouts to go as high as they need to go to cover whatever KSP can throw at it... m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym... What's the largest SI prefix KSP actually supports? Are there any other prefixes that KSP tosses out due to the number of digits the altimeter displays? Does the map view use km for any orbital characteristics? I got some nice 14 segment alphanumeric displays that are smaller than my main numeric displays. They are at the end of each relevant numerical display, and will show the correct SI units. I can make the displays support all units (as well as "m.S" and "ΔV"), but it will require more work to add the extra characters. Don't ask me why, but I'm doing a diode matrix ROM for them. It'll be kinda retro, but extra work to have extra characters supported. So... yeah... Just curious if I should plan on supporting them? Thanks in advance. *UPDATE* So, apparently, I am just blind. I never noticed the use of Km as an altimeter measurement, likely cause it occurs in a range that I rarely orbit at (or stay at for long). I can salvage this post though, as now I need to catalog the transition points. Where does KSP switch from m to Km, Km to Mm, Mm to Gm and so on. When I get my motherboard back from being serviced, I'll fire up KSP and check it out, recording the transition points here (unless someone beats me to it).

Well, Aside from the small oops at the lower right corner, I milled out the window for my tape meter. I want to remove that big crown gear and replace it with something that's a lower profile (Gotta push/drill out a very stubborn pin to do that). If I replace the crown gear with a standard gear, I can interface it with a motor set behind the tape meter, rather than beside it. As for the tape itself, I will flip the tape inside out, and stamp the altitude values from 0-9990 (repeating digits are limited due to the number of stamp sets I have) on the blank side of the tape. My mill is pretty small, and I'll admit I was a bit impatient and took some thick cuts during my passes. Living in an apartment also meant i ran the mill at a far lower speed than i'd have liked, to avoid bugging the neighbors. As a result, I got a bit of chatter, but from the front, it looks pretty decent. I honestly didn't even see that wide cut in the corner till I saw it in the photos. Not sure if the flash highlighted it? I dunno. You'll notice I left a pair of milled points in the metal at the center of the window to serve as my pointer. I figured that would be the best way to provide my indication mark, since I had to cut the metal anyway. I really like how it turned out! The part slipped out of my vice while I was trying to cut the massive switch frame off the side of the tape meter. I honestly almost broke it when that happened. Things got a bit hairy for a moment. Made me glad my mill had a conveniently placed emergency stop button. Never underestimate the importance of big red buttons! In the end, I was able to bend the thing straight again, and finish cutting the switch frame off. With the switch frame in place, there was barely room for the vice to grip it, hence the little "incident". While cutting it, you can see I bit into the post of one of the spindles, though it does not affect anything. I had to bore it down from both top and bottom to reach all the way through, and I didn't bother to line up the bores. I just wanted it cut off, and ultimately, that's what I did. It's as messy a cut as they come, but that's all gonna be hidden away, and I couldn't care less about it. The window and the tape are the only things that really matter. Someday, a real machinist is gonna see this... and cry! When installed, It'll have a sheet of polycarbonate to serve as a window, and it'll have some LED lighting to illuminate the tape. I will try edge lighting the polycarbonate, to see if that sufficiently illuminates the tape, but otherwise, I'll have LED lighting inside the tape reel box. I still need to find out what type of ink I need to be using for such a flexible surface, so sometime I'll have to stop by a local screen printing shop and see if I can buy something there. As far as the drive gear goes, I've considered both direct meshing gears, but also pulley drives as options. A toothed belt has the benefit of not slipping, and since the tape inside is spun on a toothed drum, I know that if I put an index on the drum (or gear/pulley), that I can always re-home my tape position with every single index pass. That's not to mention the option of simply using a motor with an encoder. Since I will have fixed travel, I can actually rely on the encoder to provide reliable position feedback... Now if only i could get the existing gear off... The set screw was easy to loosen, but it has a set screw AND a friction pin, and that pin has some red crud that isn't letting it budge!

I have a manual mini mill... The things you can do with the ability to precisely cut metal and plastic is AMAZING! I may very well have some of the only HLMP series rectangular annunciator LEDs on the planet that glow a color besides red, yellow, or green, thanks to milling out the old LEDs and epoxying new LEDs in their place, while keeping the same diffuser and shape. My mill is gonna save me a metric buttload of hand cutting or dremeling for my DSKY bezel! You will love owning a mill!

It's a simple, but effective solution. Nvidia's software is... less than stellar for anything besides a symmetrical monitor setup. I can't use it on my setup, cause I have a pair of 2048x1152 displays, and a single 3D 1080p display. The one different display breaks the Nvidia solution... Doesn't really matter to me now... My motherboard is dead... RIP... So dead, it trips the fault protection on the power supply. Shop tried four different known good supplies. Since it's a board for an i7 3770K, it's the older LGA1155 socket... There have been TWO sockets since then, meaning I have to either find a way to get the board repaired, or replace it with an old board (to continue using my 3770K), or replace EVERYTHING... CPU, RAM, and Motherboard with all new, but matching, hardware! In the meantime, i'm borrowing a tablet with an i5 mobile processor... It's a far cry from my old rig, but I can still play Kerbal on it, if I keep the parts counts low! So yeah... In the meantime, I'll be jealously eyeing the greatest Kerbal build in history!

She lights up like a Christmas tree! A beautiful Christmas tree that's telling you you have a high temp warning and are about to pop! So this will be a part of my Master Alarm system. The DSKY keypad will normally stay lit green, but in conditions that would trip an alarm or an error, the DSKY will flash between red and green. Simple, but attention grabbing! I also have a longer YouTube Link showing the DSKY fading and doing other effects. I could transition to orange/yellow as well, if I adjust the duty cycle. **UPDATE** Confirmed... Motherboard is dead... I was given an old Core 2 Duo machine, which is a definite upgrade from the single core Pentium 4, but I haven't set it up... The i5 tablet I'm borrowing is better. Waiting on response from Gigabyte, and hoping repair are A: Possible, and B: affordable. If that option fails, I've also asked on a forum what a good replacement board would be that ditches features I don't use, but still maintains my Hackintosh compatibility. I'd like to just plug my SSD back into a new board and it boot.

Not sure how long it'll be for my next update... It would appear my computer has decided to go on strike. I was restarting for an update, and just poof. shuts down without warning and never comes on again. When I press the power button, it trips the power supply's protection circuit, and lights the red status LED on the back of the case. Not cool! I find that I have to unplug the 8-pin CPU power cable for it to not trip the power supply's protection circuit. The motherboard still lights up all it's standby LEDs, and without the CPU power cable plugged in, it'll try to start, the PSU status LED goes green, till the mobo shuts itself down (due to the CPU power cable not being plugged in), and the PSU returns to it's orange standby mode... Either it's the PSU, or the motherboard. The Power supply might have either 12v2 or 12v3 failed (the PSU has six 12 volt power rails, 12v1-12v6). The 8-pin CPU power cable is supplied by 12v2 and 12v3. The WORSE scenario, is the power regulation on my motherboard has failed. I worry about this, as I have had similar startup issues on another power supply with this motherboard. Both my CPU and mobo were end of life products. the Intel i7 3770K was LITERALLY the highest end, and very last of the LGA1155 socket CPUs, before they switched to the LGA1150 socket. It basically means if the mobo is bad, I have to literally find a 3-4+ year old motherboard to use with my existing CPU, or I'm forced to replace CPU, Mobo, and RAM all at the same time. Right now, I'm stuck using a single core Pentium 4 right now... Life is pain. We are all slowly dying, but this PC is apparently even slower than that... Meanwhile, I decided to work on my DSKY for a bit. I have the annunciator LEDs soldered and mounted to the main digital readout board. Still no control circuitry. I also marked a sheet of alodine treated aluminum for the windows for the LEDs and the keypad. Alodined aluminum has a gold color to it. It's a chemical passivation process that isn't as nice as proper anodizing, but for materials I have on hand, it'll do just fine. The goal is to create a panel to make the DSKY stand out from the rest of the panel. The alodine process was something I commonly performed on parts for military and aerospace products that we used to make at my old job. Trust me, the other side looks nice. This side is the side I'll do my cutting on. I think I have an idea of HOW I'll do the cutting. Rather than try to free hand it with a dremel, or destroy my arm hand sawing it, I'm going to screw the plate to a piece of wood. That piece of wood will itself be attached to a narower piece of wood that I'll be able to clamp onto my mill. I'll use my smallest endmill and just cut the borders. Any corner that I want sharply 90 degrees, I can use a file on to finish off. i might leave a small rounded corner on the display windows though. I'm also trying to find a filter to go over the LEDs that will give a uniform nondescript appearance, but that can also shine through from underneath. I'll have to research filter materials when i have my regular computer up and running... Even when my main Kerbal rig is dead as a no revert/no resurrection rapid disassembly victim... I'm still thinking Kerbal! I feel so helpless without my main rig... Since it's a Hackintosh, it has Mac formatted drives, so I can't even pop my data onto this old PC... I'm stranded... **EDIT** Finally popped all the keycaps off the DSKY keypad and replaced the yellow LEDs with red/green bicolor LEDs. I had enough green LEDs to cover all 19 keys, but then I realized how freakin' cool it'd be if the whole keypad would flash red in any alarm state (High Temp, Master Alarm, etc)!

the navball has crosshairs, basically two meters, with needles that cross over the surface of the ball. Where they cross (hence the name crosshairs), is where the active marker is. The crosshairs function like the markers on the navball on the KSP screen. The different color LEDs will indicate what marker the crosshairs show, prograde, retrograde, normal, anti-normal, etc. They will be the left column of annunciator LEDs on my DSKY (Picture on page 18). I can only show one marker at a time, due to there being only one crosshair pair, so I will select which marker to show with a rotary switch (on Page 13) to select grade, normal, radial, maneuver, or target, and a toggle switch to toggle between pro or retro/anti. I'll still need the on screen navball for docking maneuvers, but all general maneuvering ought to still be possible on the physical navball. The reason docking is troublesome, is because it's typical to need to move your target marker relative to your prograde and retrograde markers. I suppose you could still do it, but that'd be a LOT of flipping back and forth to compare between two markers, when your hands need to be on the controls. Maybe I can have a 6th position that auto toggles back and forth between grade and target modes? Hmm??? I wonder if that would be good enough to actually work?