morgeturd

Well don't you just want to set different SASModes then? Read the various control states in front of you, build the table of what you should do then code it. I.e., if main sas switch is set, and then there's a multi-select dial set to a specific mode, read the mode switches, then choose what to do. If you have different buttons for different modes, you'll have to read the master SAS state, and select it, perhaps toggling a hidden state variable in your MEGA about whether the next button push enables, or disables the master SAS mode. You might use encoding of a bit-field and read the field from another "sub-controller" on your board. And switching SAS modes with SAS disabled may make sense (like if you have a rotary switch control), or it may not make sense (if you just have buttons that may, or may not light up if the mode is chosen, and the mode is active). I.e. push prograde twice (once to switch from target to prograde, then from prograde to off). As in any control system, it really does help to make a little table of what things should be first, otherwise debugging becomes a pain in the neck. I use whiteboards (easy to erase) or pencil (easy to refer to my sheet of paper). Without knowing exactly what you're up to I think you're just looking to set various nav ball modes based on the user's switches, but since we don't know exactly what switches you have, it's hard to guess at what's best for you.

LiquidFuelTot is a 32bit float in little-endianness. my suggestion is to log to file or console on your arduino to ensure that you're getting the right value you want before sending it to the display. I also note that you're not sending whatever the heck "1000, ALIGN_LEFT" is so ... not sure what's going on but there's some clear differences in your API calls between testing and data. Probably something simple... like display.show() quietly choking on a float when you wanted to give it an integer? you should probably have a look at doing rounding to convert the float to an int, or just truncate it (eww). Also note: LiquidFuelTotS (per-stage) might be what you want instead for your display, but it's your display

Unknown. i'm still on 1.2.2 at the moment. i'll dig around other open source mods that are loading configs and see if there's something I can fix. I have the websockets working now, pumping the ~224 byte packet from KSPSerialIO and i'm working on the RPi side parser in node.js (cuz i'm lazy). I didn't want to re-write the Arduino stuff to C++ as it seemed overly complex a data-path, but meh... right now my setup looks to be bottlenecked in the I2C OLED display channel actually performing refreshes (ha!) so i'll be back in hardware land again soon. note: i have no command feedback from the RPi to KSP yet, my solution is 1-way right now, although the callbacks in websocket4net look pretty simple so I suspect it'd just be another few hours to get that working and adapted back to the KSPSerialIO code. I'll probably spend another few hours on it this weekend and/or next week. Glad to know you're around and open to pull-requests

FYI, I'm working on a websocket implementation (using websocket4net) to a raspberry PI running node.js and ws. I've gotten it sending from KSP successfully. Once I get a bit further, i'll clean up the code and share via a pull-request to the original author (the COM implementation is still an option, but I can't test that I didn't break it since I don't use COM). Let me know if anyone is interested. Also since there's a few folks active here, is it just me or is the SettingsNStuff class not getting it's config values properly? I'm on a Mac and have just resorted to using the default-supplying version of the config.getValue<>() fn with hard-coded values that work for my setup.