stibbons

Sure. I've been buying Sparkfun LEDs, part number COM-12986 for the diffused body, or COM-12999 for the clear body. I like Little Bird for a great Australian reseller. And for some reason it never occurred to me to just print them on a transparency sheet and stick a translucent sheet behind it. That sounds like a more reasonable option. Hrmn.

Yeah, I know. Most of this build has been great, but those cables were the most backbreakingly tedious part of the job. Not even joking when I say I spent six hours soldering those little 26AWG conductors together. Invented a few new swear words along the way. Today I built an annunciator panel. I'd been avoiding using one in my earlier designs, because I preferred to keep controls and displays grouped by function. There's still some random LEDs strewn around the board, hopefully enough to look interesting. But I've come around to thinking a central annunciator is a good idea after all. So here we are. Started by using a box design tool to draw up a box with lots of internal dividers, making a series of six compartments long by four deep. Laser cut that out of some scrap perspex and put it together. It's deliberately fairly deep because I had a number of clear LEDs on hand, which have a fairly direct light. I then hand-drilled mounting holes for the LEDs in the base of the box, because some numpty had forgotten to add them to the laser cut design. The box sections were a remarkably tight fit, but I gave the final thing a coat of paint on the interior walls anyway to try to seal any remaining gaps and give it a brighter surface than the black scrap I'd used. That was all a few weeks ago. Today I started by sanding the outer side walls to roughen them up a little, and attached a couple of small angle brackets with superglue. Then I used used the same glue to fix 24 RGB LEDs in to the mounting holes in the bottom. The LEDs I used for the annunciator, and indeed everywhere else on the panel, are addressable RGB lights. They have a standard 5mm LED housing, but embed a little WS2812 IC. That makes them great for applications like this. I just had to supply 5V to all of them in parallel, and daisychain the data lines together. They end up taking a single pin of your microcontroller to drive, and the FastLED arduino library makes controlling them super easy. Here's what the back of the annunciator looks like after wiring everything together. It looks complicated but it's really not that bad. Each column of LEDs has the anode on the right hooked up with red wire, cathode on the left hooked up with black wire, and the data pins run through the middle with blue wire joining columns. For the faceplate, I loaded up the original box outline in inkscape and used that as a template to draw up a top-down cross-section. Filled the gaps between compartments in black, and then added my labels. Deciding what to put on the annunciator and where was another one of those agonising things that I'll never be certain I got quite right. Once that was done, I just printed it out on a sheet of blank white paper and cut to shape. Then used a sheet of thin clear plastic salvaged from an old document holder, also cut to shape, as a protective cover. Taped the two together, cut a couple of mounting holes. And then finally bolted the box to a perspex top panel, with the faceplate sandwiched between. The end result: The paper blocks out a lot more light than I was expecting, this will end up completely washed out in sunlight. But it's functional and I'm pretty pleased with the effect. May try printing another one on a more translucent paper soon, but it's not really pressing compared to all of the other stuff I want to get done.

Spent all day making four of these and then hated everything. And then I had some confusion about how to drive the MAX7219 chips I'm using for the displays. That led to breaking some LEDs and scrapping one of my boards, but at 10pm I finally got my code talking to a completed display. Nowhere near as much progress as I would have liked. But I reckon I can finish up the display assembly on Sunday.

The last components I'd ordered finally arrived this afternoon, so this evening I started assembling and testing the display boards. That quickly uncovered another fairly major mistake I'd made designing the PCBs. Half of the pins on my IDC connections between displays and controller are flipped. Fixing that is going to be very fiddly, I'll break all of the cables out to a piece of protoboard and link up the conductors manually. But it's doable, and will save me $150 or so and another month of waiting for new boards and replacement parts.

Sorry I wasn't quite clear before. In theory it would have worked if you changed all the types from byte to long. But that's probably by the by now. I'm not sure what might be going wrong now. Putting numbers in the function and variable names is fine. If you'd like, upload all of the code you've written to pastebin or something and I can take a look at it.

In Ubuntu, the binfmt-support package sets up Linux' binfmt_misc module to run assorted file formats with their required interpreter. Install it with apt-get install binfmt-support You might then have to reinstall the mono package so that it registers properly with binfmt-support. apt-get --reinstall install mono-complete After that you should be able to launch C# apps like ckan by just executing them.

All of your current problems are happening because your warnings variable is a byte, only 8 bits long, and you're trying to read and write more than that. It's a textbook example of a buffer overflow. There are a couple of approaches you could take to fix this. One is to use three byte variables, one representing the contents of each shift register. You'd then number the bits of each variable 0-7, and just shift each out in turn when you need to. This is the approach I'd take, mostly because associating one shift register with one variable makes sense to me. But I would take it a little bit further by using a single array of byte, like byte warnings[3]; (incidentally, the thought of having registers chained together using an array of bytes like this is one reason why I suggested not calling shiftOut in the warningSet function yesterday ) There is another option that springs to mind, and your code is almost all of the way towards implementing it. You can use a larger data type for the warnings variable, and then shift out chunks of it at a time. For three shift registers you need 24 bits. There's no native 24 bit data type, but there are a few that are 32 bits. I would suggest using an unsigned long. I think just changing the type of warnings like this is enough to get your code working unsigned long warnings; It's worth pointing out, though, that the Arduino shiftOut docs shift out in the opposite order to what you're doing. If you're still getting unexpected results it might help to switch that around.

Nah, put a door in the back, then there's room for the beer fridge under the console.

Lovely build. It looks fully enclosed - how do you plan on getting in and out?

Where you do it. Landed is on land. Splashed down is in water.

I have a late 2013 11" Air, with the base (slowest) i5 processor and RAM bumped to 8GB. Only really run KSP for testing plugin code I'm writing. My install is currently stock + hyperedit. The first important thing to note is that the video card uses shared RAM. Mine claims to dynamically allocate RAM, up to 1.5GB from my 8 total. If you're running with the 4GB that was standard on this model, then that will heavily eat in to how much is available for the game. I'd be surprised if video and OS overhead left more than 3GB for KSP. I've decreased render quality to simple and texture quality to quarter res. The game seems playable with these settings but probably sluggish. I'm looking at the game running fullscreen on the internal display with a Kerbal 2 in Mun orbit, and the physics rendering is flickering in to the yellow range occasionally.

RemoteTech's humble Reflectron DP-10 antenna. Short range, low power, on by default. The most vital, and therefore most often forgotten part of my uncrewed launches.

I don't have a Windows machine handy, but I did just load up the KSPIODemo13 sketch on a spare Uno and got it syncing on my OS X machine with the plugin release I posted above, at 57600 baud. Not sure yet what could be wrong with your setup. Still concerned it's got something to do with overflowing the serial buffer in the arduino, but it's a little late for me to logic very good.

Does it work better if you decrease the baud rate a little? Try 57600 or even 38400.

Thanks. I've built a new cross-platform release - https://github.com/phardy/KSPSerialIO/releases/tag/v0.17.4-1

I've merged 0.17.4 and built a new cross-platform release. Give it a try: https://github.com/phardy/KSPSerialIO/releases/tag/v0.17.4-1

Sometimes it can be worth switching to the tracking station and back again to unstick contracts like that (I've only had this happen once, but that helped). Failing that, you're justified bringing up the debug menu and cheating the contract to completion.

D) all of the above. I started work on this more than a year and a half ago, and it's awesome to finally be getting close to a finished state. But there's still an awful lot to do.

I play career, tend to multiplex a lot and haven't really travelled very far. Haven't had a game go longer than about three years, but I do end up with some fairly large stations around the Kerbin system.

You definitely do need to include shift out code. Even if a single bit changes, you'll have to shift out the entire byte. If you're setting bits in the Indicators() function, then it makes sense to do the shift out at the end of that.

Oh, I messed it up yesterday sorry. In the function definition for warningSet, the first word defines what that function returns. I accidentally set it to void when it later returns a byte. Try this instead: byte warningSet(byte warnings, byte n, boolean s) { if (s) { warnings |= (1 << n); // forces nth bit to 1 } else { warnings &= ~(1 << n); // forces nth bit to 0 } return warnings; } (future readers, I totally went back and fixed yesterday's post too)

That's probably the easiest way to do it, yeah. The only real changes in the demo sketch will be in the VesselData and ControlPacket definitions. You should be able to just make sure that you update those definitions in your code to match, to make your sketch run with the new plugin. Hey zitronen, could I bug you to update your git repository again? I'd like to keep marzubus' cross-platform fork up to date while they're MIA.

Still waiting on quite a few parts to arrive before I can build the display panels. But still managed to get a lot done today. Starting with completing the enclosure assembly. The lid is held on with a piano hinge along the bottom. Very easy to work on things, it opens right up. Will probably add something to limit how much it opens, and a clasp to hold it closed. And then all of the finished panels went in. I designed and made a quick cover for the back letting power and USB in. I didn't have any of my prepared perspex boards, so hacked something up from MDF instead. Finished up by mounting the internal electronics. These are both MDF board clipped on to short lengths of DIN rail. Easy to remove to work on. First the Arduino mega and my custom display control board. And then the 5 volt transformer and a terminal block for the power rails. In the next couple of days I expect to have all of this stuff wired up properly and will be able to verify the existing stuff still works. Really hope the rest of the display components arrive soon too.

You just need to call the function once for each bit in the byte. The function changes one bit, and leaves all others unchanged. So first you'd check the fuel state, and then call `warnings = warningSet(warnings, 0, true);` or false or whatever. Then you'd check the power state, and call `warnings = warningSet(warnings, 1, true);` or false. Then you'd check the landing gear, and call `warnings = warningSet(warnings, 2, true);` or false. Then check whatever you've got bit 3 representing, and so on.

So basically you want each output of the register to represent a different warning? No problem. You assign each bit of your display byte to a different warning. You might say bit 0 is out of fuel, bit 1 is out of electric charge, bit 2 is whether the landing gear is deployed, and so on. Now, when you want to activate a warning LED, you just have to set the appropriate bit to 1. Use a function like this (I'm totally copying and pasting a slightly-modified function from zitronen's code here ) byte warningSet(byte warnings, byte n, boolean s) { if (s) { warnings |= (1 << n); // forces nth bit to 1 } else { warnings &= ~(1 << n); // forces nth bit to 0 } return warnings } Using the above example, if you deploy the landing gear, you call the warningSet function like this to turn on bit 2 warnings = warningSet(warnings, 2, true); And then, every time you update the display, just shift out the entire warnings byte. Make sense?