katton

I was around where you are a while ago, and got some code up and running for my display they you will probably be able to reuse. I was only using 4 digit 7segment displays, but was using k- or m- modifier lights to extend their range. The main problem that I ran into was that the arduino did not have enough power to translate a dozen float values into what I needed to send to the displays (basically just formatting the numbers into four digits, plus the two modifiers and the decimal position) in a timely enough fashion. If you were only using one or two displays it shouldn't be a problem. I eventually decided that I would have to format the values on the computer before sending them over serial, but that would require forking zitronen's plugin, so I kind of gave up for a bit. I have a feeling that if I were more clever at coding, I might be able to optimize it enough, but I got busy right around that time anyways. This is where I got to, and was able to get all the values populated, but the refresh rate was down to one or two seconds, so basically unusable: http://i.imgur.com/JYEeGEm.jpg

It's exactly what you guessed - it just tells which part of the packet to put each setting into before sending it back to the computer.

I have had some excellent success finding components (especially in larger quantities) on aliexpress. Just from a quick look, you could easily get those displays (with controller chips) for under $10 each shipped, and if you scoured around a bit more, I bet you could go even lower. I don't know if I've just been lucky, but I've done probably close to a dozen orders through them, and despite the slow-ish shipping, never had a serious problem. (for example this might work: http://www.aliexpress.com/item/IIC-I2C-1602-blue-LCD-module-provides-libraries-For-Arduino/1062018842.html )

I was wondering - what happens to the control packet when a control panel doesn't actually have buttons for every function (and let's say for example you want SAS to be controlled normally). It seems like you'd have to send a value for everything, or else have a different command packet structure for each control board. Or is there going to be some sort of config so define what the command struct will be? I guess that would be the easiest way?

That makes sense, I hadn't thought of it that way. Thanks for the patient explanation

That is excellent progress zitronen! Very exciting stuff As for the options, I would definitely prefer the second one (one bit per toggle, keeping as much space as possible for options that will need more degrees of resolution). I am curious about why you've chosen this way of sending commands. It is a nice counterpoint to the data-to-arduino sending (and maybe having both structured in the same way makes it easier to keep track of), but I was wondering why you would need to send all the commands all the time. For the display data (in the other direction), it makes sense, because you don't want to make the arduino have to ask for particular variables, but I don't know how often you'll be sending more than a handful of commands at a time. Would there be any benefit in limiting yourself to say 16 commands at once (probably a safe assumption?), and having the variables be passed as: struct ControlPacket { byte VariableNumber1; byte VariableValue1; byte VariableNumber2; byte VariableValue2; ... } Where you could define a list of variables that are changeable (RCS = 1, SAS = 2, throttle = 3, etc.), and then pass them whatever value you want to be assigned to that particular one. If you had a max of 16 variables (per packet), that would cut down your packet size to 32 bytes, instead of 255 (or something around there, with checksums and whatnot). That way you could have thousands of possible variables (which is total overkill), and I think it would make it easier to add new ones later on. This would also make it so you wouldn't have to keep track of (and retransmit) the state of all the variables every time. Of course, the down-side is that if you somehow managed to miss a packet, it wouldn't be fixed on subsequent ones. Just a thought, I am still super excited about your way, I don't mean to sound unappreciative. The work that you've been doing is amazing!

To be perfectly honest, I fear that getting the joysticks working through the arduino is going to be way more trouble than it's worth - in hindsight I wish I'd just gone with some normal ones.

I thought that sending commands through the arduino program rather than emulating a keyboard would be good for a few reasons. - it seems a bit kludge-y. If we've got a direct route between the arduino and the game, why go the roundabout route. - arduino limitations: I was under the impression that if you started the arduino-keyboard mode, you would have trouble doing other things. I could be completely off base on this one, though. - non-mapped keys: going directly through the arduino lets you use commands that currently aren't mapped to the keyboard (for instance RCS on, rather than RCS toggle) I am interested in the joystick command sending because I found a pair of (relatively) cheap 3-axis potentiometer joysticks, but that means they're not really plug-and-play compatible. Also, just for simplicity's sake, it would be nice to have everything go through the arduino. As far as a list of variables to pass back to the arduino, my wishlist is (with the ones you've already implemented marked with an X): - Flight Time - Time to Node - Real Time (from the system clock, just for the heck of it) X Time to Apo X Time to Peri - Time to Sphere of Influence Switch - Current Stage Number - Current Throttle X Current G Force - Heading - Pitch - Roll - Orbital Velocity X Surface Velocity - Target Velocity - Altitude (normal) X Radar Altitude - Target Distance X Apoapsis - Target Apoapsis X Vertical Velocity X Periapsis - Target Periapsis - Horizontal Velocity (lazy to ask for both instead of computing it... but there's a lot more spare power in the computer than in the arduino) - Liquid Fuel Total - Liquid Fuel on Current Stage - Liquid Fuel Consumption - Electric Charge Total - Solid Fuel Total - Solid Fuel on Current Stage - Mono Propellant Total - Oxidizer Total - Xenon Total (?) - Current Time Warp - Current time warp state (physical or not) - Max Time Warp State (I guess you could also just get this from altitude) - SAS, RCS, Precision Mode, Lights, Gear and Brakes: Current Status - Whether action groups 1-10 have any actions assigned to them (maybe just on startup, does't really need to be polled at any frequency) I've crossed off the ones that I think you've already got. Looking at this list, there are a lot of variables, hopefully that stays in your 255 bytes limit. I'm sure there are important ones that I've completely forgotten to consider.

The ones that I had in mind were: - Action groups 1-10 (+ Abort) (if you could have the plugin tell the arduino whether these had actions assigned to them, ie. whether they're empty or not it would be pretty neat) For the following, it could either be a toggle-the-value type of command, or two dedicated commands for each (plus, if the plugin once again could report on the state of all of them, it would be helpful for indicators and the like) - SAS on / off - RCS on / off - Precision mode on/off - Lights on/off - Gear on/off - Brakes on/off - Set throttle to X (also, once again, returning the current throttle to the arduino would be neat) - Stage (of course) - Time Warp (eventually, I assume that this one is going to be hard to program) (set to X multiplier command from arduino, and return to arduino current warp multiplier, whether it's physical or not, and perhaps the max multiplier, if possible) - Rotation and Translation Commands - I'm not sure if this is the best way to do it, but eventually hooking up joysticks through the arduino would be neat. I don't know if the refresh rate would make it possible or not, but sending pitch, yaw, roll, and x, y z translation commands would be peachy.

Hi Zitronen and Mulbin, I just tried the sample sketch on an (off-brand) Mega 2560, and it worked fine. So, I don't think it's the Mega2560 that's the problem. On the other hand, I'm trying to shoehorn my own display stuff in there too, and that's not going nearly as well

I've been using MAX7219s to drive my displays, so my code might help. I have four digit displays, though (I figured that you're only really interested in four digits worth of information anyways), so my function outputs either the number, the number in thousands, millions or billions, and then lights up a separate LED to indicate the range that it's in. It relies pretty heavily on LedControl (found here), but hopefully it's of some help. The selector part is probably not of any use to you, but it lights up another led to indicate which of three options is chosen for the display (as here) /* We start by including the library */ #include "LedControl.h" /* * Now we create a new LedControl. * We use pins 12,11 and 10 on the Arduino for the SPI interface * Pin 12 is connected to the DATA IN-pin of the first MAX7221 * Pin 11 is connected to the CLK-pin of the first MAX7221 * Pin 10 is connected to the LOAD(/CS)-pin of the first MAX7221 * There will only be a single MAX7221 attached to the arduino */ LedControl lc = LedControl(12,11,10,2); void setup() { //start up the various led readouts lc.setIntensity(0,8); lc.clearDisplay(0); lc.shutdown(0,false); lc.setIntensity(1,8); lc.clearDisplay(1); lc.shutdown(1,false); } void show4digit (float value, int displaynum, int selector) { //show the info on a 4 digit 7 segment display, with leds for kilo and mega prefixes, selector is 0,1,2 for switch position int prefix = 0; float tempnum = value; while (tempnum >= 1000) { tempnum = tempnum /1000; prefix ++; //make it so we have a value less than 1000 and the prefix shows if we're in the range of ones, thousands, millions, billions, etc } //if we're above a trillion max everything out int dec2spot = 9; int decspot = 9; int ones = 9; int tens = 9; int hundreds = 9; if (prefix < 4 ) { long tempint = (long)(tempnum*100); //if we're in a good range, get some ints that we can work with... actually need to use long, because int it only good up to 30k, and wee need up to 100k ... maybe get rid of the second decimal place and use int later to get better performance dec2spot =(tempint%10); //use two decimal places, because if the value is less than 100, we have hte room to show it decspot = ((tempint/10)%10); ones = (tempint/100%10); tens = ((tempint/1000)%10); hundreds = ((tempint/10000)%10); } if (hundreds == 0) { if (tens == 0) { //if our value is less than ten, leave one digit dark, and show it to two decimal places lc.setChar(displaynum,0,' ',false); lc.setDigit(displaynum,1,(byte)ones,true); lc.setDigit(displaynum,2,(byte)decspot,false); lc.setDigit(displaynum,3,(byte)dec2spot,false); } else { //if our value is greater than ten but less than a hundred, show it to two decimal places lc.setDigit(displaynum,0,(byte)tens,false); lc.setDigit(displaynum,1,(byte)ones,true); lc.setDigit(displaynum,2,(byte)decspot,false); lc.setDigit(displaynum,3,(byte)dec2spot,false); } } else { //if our value is greater than a hundred, show it to one decimal place lc.setDigit(displaynum,0,(byte)hundreds,false); lc.setDigit(displaynum,1,(byte)tens,false); lc.setDigit(displaynum,2,(byte)ones,true); lc.setDigit(displaynum,3,(byte)decspot,false); } switch (prefix) { //set the leds to show the multiplier applied to the value - leds are wired up as digit 4 leds 1 and 2 (led 0 is colon) case 0: // less than 1000, no multipliers lit up lc.setLed(displaynum,4,1,false); lc.setLed(displaynum,4,2,false); break; case 1: // between a thousand and a million, light up K multiplier lc.setLed(displaynum,4,1,true); lc.setLed(displaynum,4,2,false); break; case 2: // between a million and a billion, light up M multiplier lc.setLed(displaynum,4,1,false); lc.setLed(displaynum,4,2,true); break; default: // above a billion, light up both multipliers (oh god what's going on!) lc.setLed(displaynum,4,1,true); lc.setLed(displaynum,4,2,true); } //light up selector lc.setLed(displaynum,4,3+selector,true); } void loop(){ show4digit(2.965874E6,0,1); }