richfiles

Here's the latest revision. For one, I stopped working on Liquid Fuel, cause it's gonna be sharing a dual edgewise meter with Oxidizer, and will have a different style scale legend. Switched to Electric Charge instead. I still need to narrow the left strip, just a hair to show the true pointer shape. Nothing's bonded down, so a few bits are flapping' in the breeze here. I think the horizontal legend at the top needs to be attached to the left strip, not the right. Unfortunately, there are three different "levels" in this meter. the center white bar is the "lowest" level, being beneath the pointer. The right scale is in the middle, and the left scale is on top, covering the pointer. The left strip has absolutely NO support to keep it's shape. It's just suspended from the ends. I think I need to use a piece of wire running from top to bottom as a guide to keep the left scale perfectly curved. Otherwise, with it being paper, vs the old aluminum scale, it can sag and jam the pointer. I think I need to bring the horizontal section down a bit though, and compress the scales just a little bit more than I already have. The text is barely visible from any angle above straight on or below. I want that to be very visible. I'm sure there will be a few more revisions, but I'm getting there! Now that I know the scales are easy enough to make, I'm gonna focus on moving the housing to allow backlighting to function. One thought I had was to dremel out spots for light to shine through, and in large areas, where it might interfere with the structural stability of the label, I might just use some clear plastic, cut to match the size of the scale label to add some rigidity and thickness... Aluminum scales were originally mounted in this.

Max... MAX!!! NOOOOOOOOO!!! Looking good though! You have anything planned for the other 3 columns the MAX7219 chip supports? Is that gonna be other panel lights, or are you ignoring the columns?

A few minor formatting edits: On Spacedock, the listing of the planets and moons in the description is a little busted. Tekto's image is shifted down to Urlum's entry, and that shift continues all the way down to the entry to Tal, which has Wal's image, and there appears to be no image of Tal at all. Tal seems to not even have an entry at Curse. Also, it'd be cool to see a proper update of the Delta V map, since Karen is not there at all yet, and the GitHub files for the map are clearly out of date. It hasn't seen an update for 9 months, and doesn't even have any moons for Neidon! EDIT: Also what @OhioBob said.

Thanks! It's always a joy to both work on and share this stuff! Not just the results, but the process too! I'm gonna go crash into a bed now! Apparently, it's 5 am here!

And this is my first test fitting! I'll need to actually separate the scale and the white band into two pieces, because if the white band is attached to the scale, it's high enough to interfere with the pointer. The legend label is also ENTIRELY unsupported. The old one was silkscreened aluminum, to it retained it's shape on it's own. I'll have to do something like glue it to a pair of wires, to make it a little bit more rigid. That'll be easy. I may also go ahead and to the horizontal "header" like on the Apollo meters. Turns out, the pointer... is the EXACT SAME SHAPE pointer as the Apollo meters have, but the narrow portion of the arrow is covered by the legend strip. There is plenty of width for the white band, so if I make it wider, and the legend strip narrower, I can show off more of the pointer. I think that'll be my next experiment.

If i were you @infinitybound721, I would check the integrity of your KSP install, redownload the correct versions of Copernicus and OPM and basically do a fresh install. It's a hassle, but I can't help but wonder if drawing things around didn't have you accidentally drag something literally where it didn't belong. I know I've done it before. Sometimes things break... You try to fix it, but when repair fails, get a new one!

Regarding Arduinos and TV signals... I'd say TVOUT on Arduino is, at best, a cool gimmick, and at worst, a bit of a hack that exists to prove TV on an Arduino exists. Considering the Raspberry Pi has native composite outputs, it's pretty much a given that it would serve as an ideal platform for rendering to a CRT with a composite or RF signal input. An LCD will likely have wider support for what you can use though, thanks to digital interfacing, but you still need the hardware "umf" to actually generate the data needed to drive to it. The only reason 1 and 2 MHz 8 bit computers of the 1980s could do graphics, was cause most of them had video chips that handled the majority of the hard work. That 12 MHz, enhanced Z80 based Brother Word Processor I found (from several pages back) can only do a high resolution bitmapped screen on that wide screen amber CRT because it has that dedicated video hardware that offloads the work from the CPU. An Arduino has no such hardware. One of the faster models, or another fast device like a Teensy 3.x is more suited for brute forcing graphics, to render to an LCD (via digital interface). The Pi is hands down, the best solution for an analog output (or any output, for that matter) though, as it natively supports it. In other news, I did my first work on the scales for my meters! It's only my earliest work, but I think it's looking pretty good! Close, though not an exact copy of the Apollo style meters. For lighting, I think I want to do white lighting with some green tint to it. Maybe 75% white, and 25% green. That'll give enough white light to make the red and yellow bars light correctly, but still offer a slight green "Kerbalish" glow to everything else. I hope! Anyway, the image above is my raw "scratch file". I know there's a lot of white space, but once the scales look right, I'll duplicate the "percentage" scale 8 times, and then mod the "Legend" scale 4 times and make two of each... There's a reason for that... I don't have the alignment and content 100% selected, yet. That's why this is a scratch file, but so far, I like how it looks! Here you see the very first test printing! The original meter scales were scanned into the computer on the flatbed scanner, and the file was edited 1:1 scale, to keep the size accurate. I inverted the image after cleaning the edges and then used the scale as a guide to draw in new uniform scales with heavier lines. The font used is Futura. I haven't decided if I'll remove or leave the manufacturer spec marks on the legend scale. I have to admit, I kinda like them! Dang, I wish Signature Plastics had rights to Futura for their double shot injection molding... My Danger Zone keyboard would have been WAY cooler with Futura vs Gorton Modified. Gorton is pretty close in style, but it's not quite the same. I'm also considering manually squashing the A and G in STAGE to make the width of the vertical text a little more uniform. Not sure if I want to do that or not. This is me using my flashlight to backlight the test sheets. The flashlight is pretty bright (for a single AAA battery), shining 32 lumens just a few inches behind the paper. At that brightness, I had to print two copies, and layer them to prevent bleed through in the black areas. The final scales will be printed on Nekoosa Coated Products 'Synaps XM' 5-mil "synthetic paper". It's a polymer sheet that has paper like characteristics, but is diffusely translucent (and water proof, though that doesn't matter for me). You can also feed them through a laser printer, and the toner will bond to it, without melting the page or the toner flaking off. It's entirely possible that I won't need two layers if I use the Synaps stuff... I might be able to just use dimmer lighting, thanks to the better shine through quality of the stuff. I've only got a limited supply of the synaps stuff though, so I'm not gonna use it till I can feed a whole sheet through with as many scales on it as will fit. One test I'll do with my new printer, is test the registration when duplexing. If the alignment when I flip a page is really close, then I may flip the page and print a reverse image on the back to double mask the scales. Regarding the scales themselves, I'll dremel and drill out areas that need to be backlit, but leave the plastic in all black areas. Since all the meters have transparent windows, I don't care if I have scales "flapping in the breeze", as long as something is maintaining the correct arc and holding it in place. An old favorite image here... but it IS a perfect image to show off the look I'm after. Look at the lovely glow of those meters! Shame there's so much vertical space on the ones I have... I LOVE the "header" style labeling of the Apollo ones. The Apollo ones are more squat than my meters are. Maybe I COULD recreate that though. It'd be easy enough... put a label up there, backlight it, and don't drive the meter to 100%. It still leaves the massive vertical space to fill though. My dual edgewise meters would actually be very suited to this, but having 2 like that, and 4 vertically printed would be a style mismatch... Hmm? I'll think about it. That's why I'm printing test sheets.

Another option, if you decide to go the safest route and use an LCD, is if you can get a rectangular lens, you can not only mimic the imagery of a CRT using an LCD, but even mimic the curvature of one... And ironically, due to the small size of portables, few portables have the CRT curvature of vintage CRTs anyway! You can get a cheap rectangular magnifying lens to do this trick, and it'll cost very little, and be very safe.

A lot of portable B&W CRTs have a small jack on the side that can be used for video input. Sometimes it requires an adapter (they use a plug like earphones, not RCA jacks). Sometimes they have a similar connector marked antenna. This is not the same. You'll need a modulator to connect to that, along with an adaptor. One of those boxes that lets you plug composite video in and get a channel 3 or 4 signal out over coax, that's what you'd need for a TV with that style input. If you're not familiar with the high voltages used in CRTs, be careful. Depending on CRT size, voltages can range from several thousand volts, to over 20 thousand volts. Most small TVs will be int he thousands of volts range. I once burned/electrocuted my fingers on the bottom of a flyback transformer, on part of the horizontal circuit. It was on a Macintosh Performa 550 (around a 1993, all in one Macintosh computer). It had these two plastic ridges on the side that were perfect for picking it up by, so one day, when aligning the CRT, I instinctively grabbed the rails to adjust it's position, and instead grabbed onto high voltage. I lost the ability to see in color for about half a minute, and it hurt like a somebeach. My whole body went numb, and I was dazed for a good minute. I think I eventually figured out it was either 4 or 8 thousand volts, at the horizontal refresh frequency. It put what looked like 2 "whitehead pimples" on my finger tip... These were actually mounds of white ash. there would have been a path of similar white ash traveling from one finger to the other. had that been hand to hand, I'd be dead, and it would have gone through my heart, so BE CAREFUL with CRTs. PLEASE. Honestly, you can actually mimic the CRT look with a high enough resolution LCD, and still get color node markers and such. Think Fallout style imagery. If you use the CRT, exercise caution. If you are inexperienced, you might be better building an enclosure around the existing whole portable TV. It's the safest option. If you have some electronics experience, and are willing to go further, take safety precautions. When working with high voltage, work with one hand only. do not let other parts of your body be grounded. If you must be grounded, make it the hand you're working with. Wear insulating gloves. Learn how to discharge capacitors and the anode of the CRT... safely! Also, assume everything is live! Oh yeah! Those are called old rules of thumb for working with high voltages... cause only people who follow them get old!

Tiny black and White CRTs are actually extremely clear and crisp, so long as they are functioning correctly. That's because they operate by lines, rather than pixels. If the circuit can handle it, you can pack a lot of horizontal resolution into a line, and adjacently lit "pixels" actually are seamless. Color CRTs and LCDs split all pixels into quantitative regions, both horizontally and vertically. This creates clear divisions in resolution. LCDs and OLED displays can now be purchased with very tiny, almost imperceptible pixels, allowing the image quality to surpass classic B&W CRTs, cause the pixels are small enough to be seamless vertically and horizontally. Color CRTs will have the most visible pixel separation, as they will have the largest pixels, generally. Figure on most small color CRTs giving you around 300x200 to 340x280 resolution, roughly. Depends on model. That being said, occasionally, you can find a very nice, decent resolution CRT. My color CRT is a 3.5 inch RCA model, and it actually has great color and resolution. No higher than other portable CRT TVs, but due to the smaller 3.5 inch display, the pixels are more densely packed, and I find it still looks decent, even up close. It's by no means HD... Something you COULD get in an LCD, mind you, but for a navball, it ought to be possible. And DEFINITELY go Raspberry Pi if you go with a CRT. It's designed to produce a composite video output. You will struggle to do this on other boards. If you go with an LCD, then you could probably get away with using some other device without composite out, like a Teensy. Those still have a decent amount of CPU oomph, giving you enough room to work on the math and graphics elements of the software. A Raspberry Pi still works absolutely fine with an LCD as well. It's actually STILL more convenient with the Raspberry Pi, since most (all? *Zero?) will directly take an LCD display. *Correction: Raspberry Pi Zero does not take an LCD... Because it is a unicorn, and does not exist! Anywhere! Can't take an LCD if you don't exist... Anywhere! Disclaimer: I really do not know the Pi Zero specs, other than the spec that defines it as not existing anywhere I can get one.

@Gouttfi That's an excellent looking job! It's always shockingly amazing To see a big ol' picture dump like that too! Awesomeness out of the blue!

Nice article there! I'm going nuts right now! I finally have that printer, but I have a solid week or two of rush work, but I suspect I'll have to pick up more work after that. it's killing my free time, not cause I don't have any, but I've been set back cause my OTHER job had someone call in three days in a row, and I had to come in early and stay late more than half the week. On top of that, the whole month of May is entire;y derped up, and I'm covering extra weekend shifts! Part of me wants to sit down and start screwing around with this stuff. The fact that I now have what I need to start doing meter legends is a big deal for me! The fact that I can't... Well... AHRGLEBARGLE! That is a legit word. Totally true... It means "Frustrated!", including the exclamation mark! Soon™

Eew! Too much glass cockpit! I need toggles! In all honestly, if you got yourself a few spare monitors, and set them up in portrait mode, you could probably recreate a LOT of what's there using Telemachus. I have, fortunately, overcome one of my minor, but still project impeding hurdles... I replaced my printer! It's HUGE! That APC machine below is an uninterruptible power supply that mounts into a 19 inch equipment rack. With this, I can now print replacement meter legends, as well as new button inserts for my DSKY and my new keypad... The keypad is to control a Hakko 927 Soldering station. I'll be building the soldering station into the Kerbal control panel, and mounting the socket to the front of the unit. I've mentioned before, that I sometimes like to take small projects to my desk to work on. A soldering iron built into my Kerbal controller will be nice! I need a 24 volt transformer to provide power for the current loop meters I have, and Hakko soldering stations run on 24 volt supplies. A pair of toggles will be available to power on the transformer and current loop hardware, and at the other to power not he transformer and the soldering station. Either switch will power up the transformer, but will also connect the appropriate device so it receives power. The keypad will have legends printed to match the DSKY keypad (obviously haven't done that yet). I had considered letting a button on the DSKY keypad control the Hakko board, and I might still do that, but I really wanted to throw together that little keypad, just because I like how it looks. I'll be replacing the red LED displays with green ones, on the Hakko board, so it matches the rest of the controller. The Hakko works perfectly fine, but was knocked off a work bench, and the case broke all the screw posts. If you have never used a Hakko soldering iron, you are missing out. They are, by far, the best brand of soldering irons I've ever used! I have a couple Hakko 936 stations at my workbench, with two different sizes of handle. The Chinese clones truly are no match, but on a budget, they certainly will do the job if you can't get a genuine Hakko. Also got a dual tracking power supply for my workshop, as well as a hot air rework station! I popped the top to examine it, before first powering it on (it was bought used). Everything checks out, and it works great!

Huh, I didn't know that. Cool! I can has Mach Speed readout when I ride into the DANGER ZONE!!!

public float MachNumber; //49 I was unaware that the game supported Mach number. is this tied into FAR or something, or does the game support this number, or is it calculated based on altitude, velocity, and pressure? The question then seems to be something that could possibly be applicable to MechJeb. Can we get a tie in to MechJeb's Total and Stage DeltaV values, and output them only in the presence of a valid MechJeb install?

This mod is so great! I've actually used it for auto asparagus staging and self filling landers and such. So useful!

Hmm... I was thinking... Dangerous! I know, right! Does Kopernicus/KSP currently support the option to: A: Change the color of a celestial bodies' orbit spline on the fly, from a changeable variable, vs a fixed config file state? B: Either toggle orbit splines on and off, or select a near invisible color (like black)? I know telescope mods exist. I presume it ought to be possible to also do progressive "unlocks" based on game progress. What if these larger dwarf planets (which are still planets... just dwarf sized, Mr Tyson... A Mr Kyson Kerman could be an interesting character for flavor text in small world descriptions) that lie beyond the orbit of Pluto got Kerbalized equivalents in OPM? If it's possible to toggle/make nearly invisible orbit splines, then I'd say to make a mechanism to progressively "discover" them, either by gameplay progression (say you've gotten orbital data from X, Y's orbit spline becomes "unlocked"). Maybe support could even be added for some of the telescope mods. I don't know how limited or capable KSP and Kopernicus are, in terms of "discovery", but if the feature exists to "hide" planets, I say take advantage of it for a "hard" gameplay mode. Even if such things are not supported, I still strongly support adding support for the multitude of dwarf planets that got cheated from being added to the nine by some eggheads.

Ship attitude is currently outputted, and work is being done on the node vectors. MechJeb is currently not handled, as far as I know. Someone mentioned wanting to add that functionality, but I'm not aware of any progress. You could, in theory, create an orbital map by knowing the absolute universe time, the SoI, and all the orbital data. I think that's all there, but you pretty much get to package it on your end. You'll need to have the data for every body and every SoI, so you can render that stuff on the screen. Beyond my skill level, unfortunately. I'd love to see an orbital display created though. It'd be awesome! Even a dual 2D configuration would be cool. A top down and an edge on view would still provide good info, and maybe two keys to rotate the view angle, and two to zoom in and out? Maybe?

My basic understanding of Raspberry Pi is that it's more like a tiny computer, complete with a light Linux OS, rather than an embedded microcontroller, like Arduinos. All you need then is a Pi with Ethernet or Wifi to connect to Telemachus, and then you can go from there, like @Freshmeat said.

Regarding my comments about the MAX7219 display controller library, I just was stating that I found it surprising that the library stopped where it did. Sure, it works as is, but I think it would have been quite nice to be able to just setup the display with the library, and then use the library to feed the display controller a whole integer, float, or string, and just make it generally a little bit simpler for a person to feed data into it. I suppose once you actually learn C, it's not as hard to do, but, well... I'm still learning. in regards to my prior comments regarding multiple packets and the buffer... I don't know if I'm just clueless on how any of this works... I really don't get coding all that well. What I was suggesting, was a structure, where a packet is sent, the significant data is pulled from the packet (presumably from the buffer? is that how this works?) and stored in appropriate fixed variables, and then the buffer is overwritten by the next packet. Data is read from it, and stored in appropriate variables, and then once again, the buffer is overwritten by the next packet. The buffer just holds the last packet sent... I think? It doesn't stack packets sequentially, right? Or am I wrong? My suggestion of a packet ID was a reference to 1 or 2 bits to define the content of the packet. I read over the packet content again, and I see there is a whole byte reserved as a packet ID! That'd work too, I suppose. What I was describing would mean that if a packet is sent, if its ID is 0 (presuming that means the default packet), then the individual bits and bytes of data are read from the buffer, and stored in the appropriate variables associated with packet ID 0. The next packet is sent, overwriting the buffer. Lets say that packet is packet ID 1. Now, because the packet ID is read as 1, the data would be moved from the buffer to variables associated with packet ID 1. Same would be true of other packet IDs, and variables associated with those specific packet IDs. I am not aware of any need for a larger size packet on sending from Arduino to PC, so I'm ignoring it, for the moment. Aside from the Control frame from Arduino to PC, where controls need to be quick, do we really need all the data updated on every single frame? If we really do need some data updated every packet, I don't see why a few pieces of data could be common, across multiple packet types, so that value is updated with any packet ID that contains it. If we are having buffer overflow problems, couldn't we use such a method to allow the switch to a smaller packet size (say, 128 bytes, instead of 256 bytes), and then use a rotating ID to send the data, sequentially spread out over a few packet "frames"? You'd end up with less data transmitted per each packet, but you'd still be able to send it all out, even more than 256 bytes, just spread out over more time. It'd give the Arduino more time to retrieve the received data (less at a time), while also allowing it to receive more total data (even exceeding the original 256 byte packet). Would smaller rotating packets solve the buffer overflow issue? Using four packet IDs, with 128 byte packets could send up to 512 bytes of data, but spread out over 4 packet "frames". Using three packet IDs, could allow 384 bytes of data to be sent over 3 frames, presumably. If the Arduino happens to miss a bit of data, that data will be back around in a few frames. Even sticking with 256 bytes of data, if you split it into a pair of 128 byte packets, you'd spread that data out over 2 frames, giving the Arduino double the time to do what it needs with each variable within the packets. It'd just handle the first half, then the second half, and repeat... On half the buffer size. I think. With most readouts needing to be read by human eyes, I have a hard time believing that we can't wait 3 or 4 frames for an update. Even with my abysmal coding skills, I still managed to put in an update rate counter on my LED display burn in code, back in August, so the displays would update at a rate you actually had a chance to read, and not be a blurry mess. Honestly, my only real issue, is me... I have never worked with C in my life, up until last August. Everything is new to me. I still don't understand half of the code I have on my Mega right now. Literally just copied code from two different examples, tweaked around on it till it compiled, and it functioned together to do what I wanted it to do. I have a Looooooong way to go before I'm even remotely proficient enough to have a clue how to even begin this project's more advanced functions. I'll certainly be able to figure out controlling LEDs, reading switches, setting analog meters and displaying data on the displays, but even if I get my FDAI hardware built, it'll be a good long while before I even know half what I need to know, to be able to write the code to make it actually operate. I honestly had to set this project aside for a few months. Getting the wrong displays last year was annoying... Finding out the replacements had a worse than 50% defect rate was infuriating. Finding out I got fed some impossible numbers on Arduino performance capability on another forum (which lead me to build a nearly $45 10 DAC signal generator... that turned out to be utterly useless to me)... That was kinda my final straw. Between all that happening within the span of around a month or so, and the wait for 1.1, I pretty much decided to put my Kerbal controller build aside. I needed to just step back from it. I switched 100% of my build efforts into my mechanical keyboard instead. I've planned, purchased, and built that for the last half year instead. Guess where I'm stuck... I have a finished keyboard with a blinking Caps Lock key... Cause it's still running the "blink" program. Unfortunately, that delay also has let every iota of what I did learn of C, back in August, to ooze out my ears. I really need to start from scratch again. I seem to recall C is fond of something called a "void"... No clue why I'm having so much trouble with C... You'd think my brain should do just fine learning C then, cause I feel like I've already got a big old void between my ears every time I try to stare glass eyed at a screen full of code!

I guess what i was asking before, isn't asking if it's possible to add more packets, but rather alternate packet frames. Each packet would use a couple bits to ID the packet type, and the code would transfer unique values where they need to be stored. In cases where a particular piece of data would benefit from being updated on every packet, you could even have that data, in the same location in every packet. It would allow portions of the packet to remain the same data on every frame, while other values could change. As long as the arduino software and the plug in both know what any given packet ID contains, the content that is the same between all different packet IDs gets handled the same way every time, aways moved to the same variable, regardless of the packet ID. The content that is unique per each packet ID would be moved to the appropriate variables, based on which packet ID is sent with each packet. As an example, let's say around 192 bytes are the same in all the packets, but with 4 possible packets (defined by a 2 bit ID, in this example), then you'd have 64 bytes that could be unique per each of the 4 packets, making 256 bytes that are flexible (192 bytes more than sticking with a single packet), and 192 bytes that are always the same, regardless of packet. You'd need additional memory for the extra variables to store data front he flexible packets (enough to store an additional 192 bytes of data). I don't know what the overhead is for variable storage, but If i and half an idea of what I was doing, that's probably how I'd handle things... Again, no clue if I'd be right or not. The following is a breakdown of this particular example. You wouldn't need to do it this way, but it's a thought. [Packet ID 00 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes D] [Packet ID 01 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes E] [Packet ID 10 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes F] [Packet ID 11 64 bytes A] [64 bytes B] [64 bytes C] [64 bytes G] Memory Variables required to store data from *<A, B, C>, *{D, *(E, F, G)} *<These values are always sent in all 4 packets. They are always the same, regardless of what packet was sent> *{These data sets are different in each different packet} *(An additional 192 bytes of data can be sent and needs to be stored in additional variables, but only when a packet is actually sent) I can't really say I even know what's going on under the hood, but I'm not talking about sending multiple sequential different packets. Maybe you send packet 00 over and over and over, and then a piece of data carried in packet 01 gets updated by KSP, so the plugin sends an alternate packet with ID 01, and then returns to sending packet 00 repeatedly. Maybe another variable is updated, and it sends packet 11, then returns to sending packet 00... The idea isn't to send packet 00, 01, 10, 11, 00, 01, 10, 11, 00... and so on... It'd me more like 00, 00, 00, 00, 00, ... 00, 00, 00, 01, 00, 00, 00, 00, 00, ... 00, 00, 00, 00, 11, 00, 00, 00, 00, ... Maybe there could be a handshake that occurs to confirm receipt of the alt packets. Plugin would resend the alt packet if no handshake occurs, before returning to the default. Again, I REALLY don't know the programming aspect of this all that well, but if values are moved into appropriate variables, then wouldn't the same serial buffer be used? If I'm totally wrong, and just don't get the way this stuff can be programmed, then never mind... I'm just sorta... Spewing ideas. I guess I also feel that it's not unreasonable to have two builds for different sized Arduinos. The normal build could be considered a standard version, and optionally, there could be an advanced version. No changes would be required for a "standard version". That'd just be what we have already (but updated for KSP 1.1, obviously). That version would obviously work for all Arduinos currently able to run it. An advanced version could simply require a Mega, or something, to handle the increased memory footprint. Or something. I don't know. Again, just ideas.

I do forget how small these things can be sometimes... It's also easier (for me) to remember them by the flash vs the SRAM, from a program storage point of view. Is it possible to consider the option of a KSP Serial IO "lite" (basically, just the current state of the plugin, which would run on any Arduino), and a second "extended data" version that maybe requires a Mega for installation, due to increased memory requirements? The difference would be that one version would enable at least one or three alternate packets (a single packet ID bit could, of course, represent 2 packets, while 2 packet ID bits would obviously be able to represent up to 4 packet configurations). I'm curious what this runs on currently. I have a pile of Megas and Pro Minis, myself. Those have 8K and 1K or SRAM respectively. I think the Uno has 2K SRAM. That means for a Mini, the packet is 1/4 of the entire RAM (would it even run on a Mini?). For the Uno, the packet is 1/8 the RAM. For the Mega, the packet is a far more comfortable 1/32 of the total SRAM. I think that could be a factor for those who want more from this plugin... If you want more, splurge on a higher end Arduino. Consider making the Mega a requirement for running more than 1 packet. It would make sense anyway... Someone running more packets most likely has more analog gauges, more displays, more LEDs... They probably would need the additional I/O anyway. I myself am already looking at a proposed minimum of 3 Arduinos for my project, and possibly a Raspberry Pi later on, just as it is! My intention is to have the main Arduino run as many analog gauges as possible, since those are just basic PWM writes. It's probably "cheaper", performance wise, to write the PWM values directly, than try to package the numbers up and communicate those serially to another device. It really already makes sense to me, that if a project is already large enough to potentially exceed the capacity of a single Arduino, that maybe asking for a better Arduino as your starting point might actually be reasonable, at least for more complex builds. Like I said... If a build only needs one packet, then there need not be a limit. If two or more packets are desired, I think it'd be fair to ask for a larger Arduino in the first place, to run it. As for splitting my Kerbal controller project off into different microcontrollers for different distributed functions, My FDAI (navball) is certain to require it's own controller. If an Arduino can't handle the processing grunt to calculate the attenuation and polarity values for the 9 synchro signal lines, based on the angle of the three attitude axes, then I have a Teensy 3.1 as an alternative controller. That runs a whooping 72 MHz, and has 64K of RAM, and 256K of flash... Surely that will be fast enough for the task! I also have to calculate the heading vector and translate that to a pair of crosshair configured needle meters that hover in front of the navball. That's how I would show my node/attitude markers. Again, all that would be offloaded from the main KSP Serial IO Arduino. All the main Arduino would have to do is send out the three attitude axes and the heading values Finally, I want it to send all numeric readout data to a second Arduino, where it will break the numbers down into their individual digits and send them out over SPI to my displays... I still find it amazing that it has to be done that way! I kinda (really) wish someone would come up with an "easy" library that handled breaking up simple numbers and strings and communicating with the MAX7219 chips automatically. I only got mine working by editing example code... I barely even understood how it works! Getting no compile errors was more trial and error than actually getting it... Anyhow... Those last two things ain't your problem. I just simply don't get C the way I used to get BASIC.

It might not be reasonable for a current build of the software, but I wonder if a future build could feature packet sets... Have alternate packets that have different data sets. Stuff that's incredibly important can be shared across packet types, but data that changes less frequently, wouldn't need to be sent with every frame. Switch the packet identity bits and send different data sets for a frame, then return to sending normal frames. I have to imagine it would allow a lot of data to be freed up. I imagine it might be more suited to a future build too. Not sure how difficult something like that would be. As long as the Arduino knows what's going on, it'll be able to direct the data based on the packet's identity bits. An SoI change is not very frequent, so IDing what SoI you are in would be a good candidate for an alt packet, just as one example.

I could tell you what parts or setups I always forget, except for the fact that I kinda forgot them!

Lets hope 1.1 addresses the axes/joystick binding and sensitivity issues.