richfiles

Anyone have $179 US Dollars? You can buy ONE whole Honeywell tab lever toggle switch... Just found it on ebay... it's just one though, you'll need to hope one or two dozen more pops up someday, for any reasonable simpit project. It's not even the enclosed type, just an open frame aviation grade switch... New, these retail for around $400 each. http://www.ebay.com/itm/Honeywell-Microswitch-23AT473-T2-Aircraft-Toggle-Switch-2PDT-On-On-5A-NOS-/171310459602 I still think this lever style needs to be mimicked by China and their "top quality" manufacturing. I'd still buy cheap replicas. If you are cool with plastic tab levers... These ones are "only" $33-36 US Dollars... "only" http://www.ebay.com/itm/HONEYWELL-32NT391-1-C08-Toggle-Switch-DPDT-6-Conn-On-Off-On-/381021675889 http://www.ebay.com/itm/HONEYWELL-32NT391-7-C08-Toggle-Switch-DPDT-Mom-On-Off-Mom-On-/221560783935 i still think if a mold can be made, it ought to be possible to replicate the correct style tab lever and essentially mold it around switch levers using something like grey epoxy. You can see clearly that these plastic tab levers are pretty much exactly that, but with plastic, instead of epoxy. I'll be sticking to my cheap Chinese switches... cause I sure can't afford any of those puppies! Still, they are darn purdy, particularly that authentic tab lever style one! I'll admire from afar.

Wait... You have OPM working with this! Awesome! I have been saving OPM as a reward for when I finish my hardware simpit... I REALLY like OPM, but this is an exquisitely nice looking mod too. The idea of having both... ​yay! I'm also concerned about the total game time limit... I actually am not a big fan of "warp" mods... Say you sent a probe at a reasonably high velocity out at stockfish speeds... Just how many years would it take to reach the inner and outer systems? Can the game even handle times that large? I know the standard play method with this type of mod is to just install a warp mod... But what if I WANT a Voyager style probe to fly for decades and decades... Are the distances scaled to be possible in several decades... Or is it more on the order of several centuries or millennia, or more?

What I meant was possibly splitting the existing packet into two smaller packets, giving the buffer a chance to load and read one, before moving on to the other half. I know that'd be entirely dependent on the software being changed to make such a thing possible, but if you find that the issue IS caused by a buffer overflow type situation, then maybe that could be suggested to the creator of the software as an option for future development. I dunno. I've only been playing with the software side of things for 2 months... I've always been a hardware guy before that.

Interesting... I get most of that, though that all comes from my understanding of things from a hardware side... Bummer that something like that seems to be limiting growth of the packet content... I have a feeling that it's possibly a good thing that I bought a metric assload of cheap Arduino clones from Micro Center the last two times I went up to Minneapolis (Minnesota), for a robotics meet up... I have four Mega 2560 boards, four Pro Mini 5v boards, and a Teensy 3.1 board that I plan to use to make my Apple //c keyboard into a USB/HID keyboard. I'm actually wondering if I should pre-calculate the 9 multipliers for my synchro emulator, and transmit the 9 multipliers raw (then the sine wave generating Arduino only has to read the sine value from the lookup table, perform 9 multiplies, and then send the 10 sine values (original value, plus the 9 multiplied values) over I2C to the 10 DACs. The multipliers are calculated by bay of some trig calculations, and i'm concerned it might cause a hiccup in my 400 Hz sine waves, if it has to pause too long to both read the serial AND perform the trig calculations. I can either send 3 raw attitude values in degrees, and perform the trig formulas on them locally, or do that externally, but transmit 9 values... Decisions... I am certainly not opposed to splitting tasks across multiple pieces of hardware. On a side note... Has there ever been consideration for interleaving packets. Send smaller packets, but alternate between two or more data sets?

Aside from the fact that the new moons haven't been added to the description on the top of this forum and on Kerbal Stuff... I noticed what seems to be an image goof on Kerbal Stuff. It appears that Neidon's image is where Polta should be, and all the other images are shifted down by one, making it confusing, but still possible to follow. Very amazing work! I'm holding out on installing this as a reward for finishing my simpit. I'm making progress! Got LED displays lit up today!

I setup a burn in program and wired up 8 of my displays into a chain. The reason you see red LEDs in the bottom one... Is because what you see is ALL the green LED modules I had that didn't show signs of dead segments. I left enough wire length between each group of 4 to support both vertical (1x8) or horizontal (2x4) orientation. The program cycles through my sine wave program, generating the PWM sine wave output, and displaying the PWM value on an LED screen. The screen that displays the output cycles after a specific number of screen updates, and the screen updates only happen after so many increments of the sine output value. All other screens display 8.8.8.8.8.8.8.8. so that I can see if any segments are dim or dead. Sadly enough... Since starting burn in earlier today, I already have seen intermittently dim segments and a dead decimal point across two additional LED modules... This brings my failure rate back up to an inconceivable 50%. This photo was taken before the second display defect was detected. It looks like I found the ONE seller from China that can't get a good LED... That was the one thing I always had luck with... Oh well... Still, it is progress, and I have the displays pretty much wired up and ready to use.

The LEDs are 4 digit modules that are socketed to the board, two per board. The MAX7219 boards all appear fine, so far... it's the replacement LEDs that are 10 of 24 bad! Swapping out the red LED modules for green ones was my solution for the original issue. Its just that the replacements are garbage! This one was the worst... It's ridiculous. Pop in a good green, or the old red ones, and it's all 8s. Definitely the LED, cause the bad segments follow the module, regardless of if it goes into the right or left socket, or even another board.

I play windowed at 2040x1100. This gives me room for my menubar at the top of the screen and the window border on a 2048x1152 monitor.

Jeb: A "successful" landing! We walked away!

And THAT is how these are supposed to look! Glorious green! The "Kerbalish Kolor"! And 6 of the 12 LED modules have dead segments... Haven't gotten the other 12 modules yet... 50% failure rate!?! Dang it China... ** Update ** And I've tested the second batch, which arrived today... 4 of the 12 LED modules were bad, for a total of 10 bad modules out of 24. Seriously... You've got to be kidding me!

Clearly did not read my post, and ignored the bit about limiting part loading for limited systems... My option could be easily implemented as an interim solution till real dynamic loading is supported.

Since some people really like the old inline single seat cockpit, I'd say I'd support keeping it, and adding the new style one. The old one... I love the idea that someone had on making the "humps" into air intakes. Maybe it gets integral air intakes, but loses reaction wheel torque, to make it more inline with an atmospheric cockpit. Aside from that, I'd support the addition of two additional capsules and another cockpit that I feel are sorely missing from the game... A Gemini like 2 seater, and an Orion or CST-100 like 6 or 7 seater for the large diameter tanks. Honestly, I think the MK3 "shuttle" like cockpit should hold 7 kerbals, and a more streamlined variant should be limited to 4. The shuttle almost always went up with 6 or 7 person crews. Hmm... I should see if there's an Orion mod.

Jeb: "I can has speed naow?" You: "Yes Jeb, you can has all the speed." That you achieve this with not only a surviving pilot, but without vessel deconstruction... or even leaving the runway, is exquisitely amazing! YOU, can has all the speed! Kerbal Reporter: "Can you describe the experience?" Jeb: "WhahahahaaaaaaaaaAAAAAAAAAHHHHHHH!!!" Heavy on mods, but very, very sexeh speed run! Definitely win on style points! Bing-de-do-de-do... What was that alarm sound? Breaking Mach or something? That part of RPM?

The only planet mod that caught my eye is Outer Planets mod. I like the strong inspiration from our real solar system, but I think it's at the same time, both creative, and very "Kerbally". I've already decided that I will install Outer Planets mod as a reward for finishing my simpit. If I'm gonna have fancy controls and readouts, I might as well put them to good use! I have seen planet mods that change the Kerbal system all together, to rearrange things, and I just don't care for that. I like adding, not rearranging. Sarnus, Urlum, Neidon, and Plock... Those are the worlds (and their moons) that I shall be adding to my solar system! I'd support this mod being incorporated into stock more than any other mod, personally.

In other words... It's flagged because the file dared to be something that wasn't submitted to them... Like MOST code of this nature. It's a false positive flag, and nothing more than overzealous software flagging anything that it doesn't know. If you wrote some original code, it might flag it too!

Oh you! It's A0, not A3! Addresses start at 0, silly! LOL ◴‿◶ Eh, close enough, though. Here's your Jeb wearing shades! Specifically, the address select wire is only wired on the right most circuit.

I think they should add shiny spots after they figure out for certain what's up at Ceres. Ceres doesn't get enough love either. I still find people that don't even know Ceres exists. I say, let Dres be a good Ceres analog. Actually update Dres as Dawn updates us on our knowledge of Ceres!

As a collector of vintage computers and calculators... Why the hay do I live surrounded by endless rows of cornfields, in Nowhere, USA, where the most "vintage" computer is that Windows ME PC from 2001, with 47 worms and viruses that gets passed off as "still usable". We don't have ANY goodies like retired Crays and PDP machines...

Haha! I love that movie!

You know... For me, I'm just running K2 for now, and will hope that once KSP makes that official transition to 64 bits and unity 5, that we can just forget all this silly nonsense about limiting part counts, and see new complete diameter part sets in KSP 1.1+ I think it'd be also quite wise to have a "part limiter" in the configuration menu. Basically, a listing of every part in the game (it could be accessible from the main menu, not the in game limited config menu). It'd have a reload button to reload all parts (in the case that some are previously unchecked). It'd require a restart to implement (as it would not load unchecked parts). The basic premise, is you would have a simple graphical interface to restrict part and texture loading for parts you don't regularly use. I realize that 64 bit solves this issue, so it'll soon be a non issue, but where it DOES come into play, is that some people may still be limited to 32 bit systems, or may only have 4 GB RAM. It'd simply provide a means to keep KSP's bottom end from rising up, when the top end advances. Just a consideration for lower end users. It also makes it feasible to add things like a 1.8ish meter part lineup. I'd be totally supportive of that.

I finished the DAC + Amplifier board for my physical "navball" FDAI synchro emulator. The unit uses 10 MCP4725 12-bit I2C Digital to Analog converters, and 10 LM386 audio amplifiers to generate the 10 400 Hz sine waves that will be required to emulate the synchros that control the FDAI. The arduino will control the DACs, and a transformer will be tied to the output of the audio amplifiers to drive the inputs of the FDAI. I highly suspect the reference will require more current, since I believe the FDAI is also powered by the reference signal as well, so I will simply drive it through an LM675 power op-amp, if I need to. I even have enough room to fit it on the circuit board, If I end up needing it. If I end up needing LM675s for all ten outputs, I'll just mount them all on an intermediate board instead. Of course, that would be dumb, as I could have skipped the LM386 audio amp boards if that were the case, but they were cheap, so whatever. They're installed, and that's good enough. At $1.11 each... shipped, I can't even care if they end up redundant later on. The 4 pin connector is power and I2C serial data. The 10 pin connector is the DAC select. Since the I2C DAC chips in question can only support 8 unique addresses, it's necessary to use the external address select pin as a chip select instead. In software, I will ALWAYS write to the same I2C address, but I change which chip select pin is on before each write. Since only the chip who's address pin is high matches the address being sent, only it will receive the data. All the unselected pins would have identical addresses, but since their identical addresses (the address you'd get with the address select pin set low) are not sent over serial, none of them respond. At one point, I had considered an I2C multiplexer chip, and replacing the individual DAC chips with the correct addresses to address all the chips in software, but I think this will ultimately be simpler. I plan to use a Mega to control it, so it's not like I've got to conserve pins or anything like that. I like my little wire wrap tool... It lets me not care about making PC boards for simple jobs! And actually, there is one incomplete step in these pics... A free "Jeb wearing shades" smily to the first person that spots it! LOL! It's a step that should be repeated ten times, but is only done once on these pics. One teensy little detail!

Congrats on having your Kerbal Kontrol panel played by an interwebs celeb!

Your controller looks absolutely amazing! Actually, Regarding syncing to the 2 way switches, that's possible. it just takes some code and a little effort... Manual effort! the KSP Serial IO plugin sends a status state back to indicate whether stuff like SAS and RCS is on or off (ActionGroups status bit order: SAS, RCS, Light, Gear, Brakes, Abort, Custom 01 - 10). The microcontroller needs additional programming, and you need additional lighting, but it's possible to make the microcontroller "warn you" to manually synchronize. Set you master alarm light, or add a status alarm light and light that, if changes are detected. Basically, if the microcontroller detects that the status bits do not match the previous status bits and the physical switch bits, then it would store the new status state (from KSP) in memory, and set a bit indicating that status requires updates, and light up both a master status alarm led, as well as an LED by each toggle that needs updating... lets say a red LED next to the switch, maybe even flash it. It would ignore the setting the switch is in until you either flip the switch manually to match the status bit (which would clear that switch's status LED), or reset the master alarm. if you reset the master alarm, then the current physical switch positions then all get sent to update KSP. You only need to do this check for toggles, since pushbuttons will be programmed to only toggle the existing state, and can coexist with KSP and the keyboard. All status bit can be easily displayed by a green LED, for example. You can even use a bicolor LED, so one indicator provides feedback as to whether the function is on or off, and if the toggle matches KSP's internal status. As for the actual detection, it's about keeping a local copy of the status bits on the microcontroller, and comparing them to the newest received frame. If a change occurs, then the micro knows that KSP sent the changes. It stores the new changes in a location in memory, and keeps the status. If a switch changes, then the status bits from KSP will remain the same between frames, so the micro knows the change was manual, and can send the new change to KSP, and also change the stored bit, so it matches what it'll get on the next data frame. Hopefully that makes sense. - - - Updated - - - STIBBONS!!! Dave Jones of the EEVblog drove a rover on YOUR control panel! That's freaking AWESOME!!! :sticktongue: Never connected in my brain when you both announced going to a maker faire, that you both were going to the same one! So awesome! You've had your control panel played by an internet celebrity!

Antipaten, that is one NICE looking Kerbal controller! If you sunk that into a cutout into your desk, then made a six inch vertical section on the back, and had that wrap around the sides at angles similar to the monitors, I'd say that's close to the setup I'm aiming for. What kind of keyboard did you use? For that matter, do you have some high resolution pictures, I'd love to see details. I just looks SOOOOOO goooood!

I put together a 3.5 GHz i7, 32 GB, Hackintosh, and built it into a 1939 Philco radio cabinet. My initial parts cost was $630, and I later spent $50 to upgrade my GPU to a used ATI/AMD Radeon HD 5770, $100 For a good PSU, $50 for a kickin' Noctua cooler (so i can overclock), and whatever i spent to double my original 16 GB RAM to the 32 I have now, along with the pair of SSDs i have. If you want a Mac, look up "tonymac" and you'll find monthly build guides and the software needed to make it all function. My hackintosh has been my main computer since summer of 2013, and as a person that prefers using Mac OS... It was well worth it to build it myself!