• Content Count

  • Joined

  • Last visited

Community Reputation

50 Excellent

About MrOnak

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi everyone, it's been a long long time. I need help. My KSP MKS 1.4.5 playthrough has now finally reached the point where I want to go on a Grand Tour and turn Kerbals into a multi planetary species. For that I want to set up a Karborundrum farm on EVE to fuel my not-at-all-oversized mothership. The goal are autonomous miners with 4 Automated Industrial Strip Miners on them and a orbital logistics setup to get the Karborundrum into space. I can't for the life of me figure out how to cool the Automated Industrial Strip Miners from USI. I've tried - attaching the Strip Miners to Kontainers and then Radiator Panels to the Kontainers (both the Radiator Panels and the Thermal Control System (large)) - attaching the Strip Miners to various other parts and then Radiators to those => the type of part the Strip Miners are attached to doesn't seem to make a difference. I've now settled on attaching the miners to TweakScaled structural fuselages for ease of attachability / weight. - having a Miner without a Nuclear Reactor since I thought the 1000k core temperature of the reactor maybe affects the 500k optimum of the Strip Miners but that is not the case. They overheat just as fast when my power comes through Microwave Power Receivers. - with the reactor back on the mining vessel I tried insulating it from the rest of the craft with a Heat Shield (long shot, but again asuming the reactor core temp affects the rest). Again this doesn't help, not that I expected it to. - Using the 'Ranger' Thermal Control System (lots of them) instead of the stock radiators but they're simply not transfering enough heat and they're somewhat hard to attach to the kind of layout I have on the miner. By now I'm running out of ideas. I do have a working MaterialKit / Machinery farm on Mun with perfectly cooled MEU-500-A Pulse Drills so I believe I do understand the basic mechanics. With the Karborundrum miner I can run it with one separator on each of the four drills and it won't overheat. Activating the other separators makes it go above optimum temp. The "cooling" readout on the radiators is constant at around 16%, no matter how many separators are active or if the Strip Miners are running at all -- there's a change of around 0.2% in the cooling percentage readout but it doesn't seem to reflect the actual heat output of the Strip Miners. All tests were done with the Strip Miners configured for dirt and on the KSC launchpad. Environment is KSP 1.4.5, Karbonite, MKS If anyone has working Miners I'd love to see them, or a general explanation how the cooling is supposed to work. For reference, my current variant of the craft file is public. Other than the USI mods, you'll need TweakScale, probably nothing else. Control group 1 activates all the things. Many thanks in advance. o7
  2. The design was done with Inkscape. I ordered it from the first "custom dibond" result on google
  3. I think you still have a few options here. First, you could ditch the TM1638 - although I see its charm - and chain all 7 segments and LEDs over SPI. 5 pins total, plus whatever is needed to run the LCD. Second, there are analog-to-digital converter chips which are addressable over SPI. That way you'd get ADC without using more pins. The MCP3208 is one example that gives you 8 analogue pins over SPI. But then I don't think the analogue pins are your problem? Third, I mentioned this already, if you need more digital inputs, the 74165 family of chips gives you those, over SPI. Again, no additional pins required once you have SPI set up. Fourth, I really like the idea of communication between Arduinos and it will be possible if you have the pins for the rest. That said you could perfectly well ditch the idea of having the 2 arduinos talk to each other and run them independently. Sure, KSP can only talk to one of them but you can make the other one be recognized as an USB joystick using VUSB: - I've done exactly that and have a single microcontroller run 6 analogue axis and something in the order of 60 buttons. My computer thinks its a joystick/keyboard combo-device. You'll actually find my code in the VUSB forums. KSP has no idea that microcontroller even exists - the one "my" KSP talks to only handles a few buttons through a R2R ladder config and lots and lots of outputs. If you click the link in my footer I hope my initial post does a decent job of describing my approach. All that said, I really hope you find a way to pull this off. It'd be awesome. Free those pins!
  4. I just found this: Seems the default is 4Mhz, or 500kbit per second. However you might want to check the maximum ratings on the receiving end of the connection to avoid some nasty debugging (not an issue with the 74595s).
  5. SPI sends one byte at a time by definition of the protocol but as usual you can make up your own "protocol" (big word for that) quite easily if you know what comes when. the KSPSerialIO communication between KSP and the microcontroller itself isn't much else tbh.
  6. hardware SPI is orders of magnitude faster, I remember 400kbps or something, but I might be wrong Oh and about the money: A 74595 costs around 30 cents in a local shop, much less if you order online. buy one and see what it does for you.
  7. @Psycho80: You can use really cheap ICs 74HC595 or 74HCT595 to expand your output ports. They are addressable over SPI and you'll need only a fixed number of pins (4 for output-only) on your arduino, no matter now many ICs you're addressing. Each 74595 will add eight output pins and you can chain them together. I'm using 6 of them chained together to give me 48 outputs to drive 37 7-segment displays and 30 standard-LEDs in my work-in-progress controller. Soon I'll add another two 74595s for another 10 LEDs. All that requires 4 pins on the microcontroller. There's a schematic in the thread linked in my footer. Note that the 74595 provides only outputs. If you need inputs the 74HC165 is your friend. It works pretty much like the 74595 but provides 8 inputs per chip. And yes you can chain the 165s and the 595 together pretty much endlessly, requiring a fixed 5 pins (you need one more for the input line, which you don't need for output-only operation).
  8. Looks like the effort required to do what I had in mind is not worth the result. I welcome my new 46-case switch-statement overlord! :-( In other news @Zitronen, the config.xml file has ThrottleEnable set to 2, which seems to require a "throttle-off" ("x" key) upon launch, in order to make the hardware throttle actually able to put the throttle in game to zero. Without the "x" the game throttle simply jumps back to the 50% that it was at launch when the hardware throttle goes to zero. I've changed the ThrottleEnable to 1, which seems to work better.
  9. Now that you point that out a 16-bit address seems logical. Although the serial comms KSPBoardReceiveData() uses uint8_t to store the address of VData as a whole. Interesting that that works. Regarding the typecasting you definitely have a point, I didn't think that one through . I think I have a rough idea that involves storing the values behind the address in a buffer and then comparing the buffer with a typecast to long of that buffer - if that's the same it's long, otherwise it's float. That might not work though... hmmm More thinking required I believe... if anyone has a better approach (see question 3 above ) let me know.
  10. Hmmm, time for me to ask a question . This is more about C itself rather than the plugin since it is not my first language I'm looking for an efficient way to access individual values in the VesselData struct. Let me explain: KSPSerialIO's VesselData struct contains all flight information in a handy format, 45 of them at the moment. On a test-rig of mine I want to display any four of them on a 4-row LCD. The naive approach to this would be to use a gigantic switch-statement for each row (code is untested): #define DISPLAY_LINES 4 byte lineIndex[DISPLAY_LINES]; // these would be derived through inputs and not fixed as in this example lineIndex[0] = 2; // AP lineIndex[1] = 10; // TAp lineIndex[2] = 16; // alt lineIndex[3] = 40; // VOrbit for (byte i = 0; i < DISPLAY_LINES; i++) { switch (lineIndex[i]) { case 1: lcd.print(; break; case 2: lcd.print(VData.AP); break; // add another 43 case-statements here } } ...but this solution makes me sad Instead, I would like to store the address in memory at which the data that I want is located and use that so print it out directly, something like this: #define DISPLAY_LINES 4 byte lineAddress[DISPLAY_LINES]; byte lineSize[DISPLAY_LINES]; // again, these would be derived through inputs and not fixed lineAddress[0] = (byte*)&VData.AP; lineSize[0] = sizeof(VData.AP); lineAddress[1] = (byte*)&VData.TAp; lineSize[1] = sizeof(VData.TAp); lineAddress[2] = (byte*)&VData.alt; lineSize[2] = sizeof(VData.alt); lineAddress[3] = (byte*)&VData.VOrbit; lineSize[3] = sizeof(VData.VOrbit); for (byte i = 0; i < DISPLAY_LINES; i++) { for (byte j = 0; j < lineSize[i]; j++) { lcd.write(*lineAddress[i]+j); } } Now, couple of questions - partially because I can't test this code until the weekend: - will the lineAddress[0] = (byte) &Vdata.AP; part work as intended and give me the value of the address in memory where the apoapsis value is stored? - in the lcd.write(*lineAddress+j); line, will this really point to each byte in the value I want or does the pointer dereference before I add j to the address? - and most importantly: is there a better way to do all this? Thanks a TON
  11. The term you were looking for is "borrow" I think Oh and... have a close look at the top right
  12. @Zitronen, RasterProp seems to have a proposal for the Autopilot stuff: