[MT] Craft Design Walkthrough - M589 Sangendar

[Major B]

Other than the MT starship design example (which still has some problems despite the latest corrections), I haven’t run across any detailed walkthrough for vessel design. I thought it might be useful, so here is a relatively brief explanation of my latest design. I wish I had found a good example when I was getting started, it would have saved me many mistakes and re-calculations. I hope this is useful to someone here. If this workup is well-received, I will try to do another as I go through the design for a frontier vessel, based on the specifications currently under discussion in another thread (this one).

Some time back I experimented with a small satellite, something like a maneuverable drone that could act as a communications relay and an intelligence-gathering platform. It didn’t turn out exactly as I’d have liked – for one it wasn’t as capable an intel-gatherer as I wanted and for another it used the vehicle grav drive, as opposed to the thrusters that are necessary for efficient inter-planetary travel. That design is still in the file library (but I can't find it to link just now...) and I plan to go back to that and re-do it with a more limited operational scope, but the purpose of this design walkthrough is to create something better that can perform in both the surface-support and extra-planetary operational realms.

I had to do some fiddling and house-ruling to do it, but I’ve come up with a design for a remotely-piloted craft that is both an effective sensor platform and communications relay. The fiddling I did resulted in deriving smaller thruster sizes, intermediate sensor packages (for the between tech-levels and ranges not on the current RM charts), and a system to derive what is required in the parent vessel in order to control remote craft. Note, I used the MT design sequence updated with the most current version of the errata (thanks Don!) and some house rules that will be noted and explained below.

I’ll try to split the steps out into multiple posts, so comments and questions can be linked to a step in the design sequence. I will omit the calculations to keep it shorter and since they are all available in the spreadsheet posted in the file library (here). Please take note of where I depart from the published rules, and let me know if you think my reasoning is valid. I value the feedback I receive here on CotI (both the positive and negative), because both kinds help me do better work.

 

[Major B]

M589 Sangendar Design Parameters

First, the design parameters:

I wanted a system capable of at least 2G maneuver, using thrusters (TL11+) rather than anti-grav (TL9-10) which does not perform well outside of a gravity well. Agility was not a requirement, just the ability to go where it was needed relatively fast, rather than having to be ‘dropped off’ by the carrying vessel.

It needed to be as small as possible, as space on any vessel is a premium and every kiloliter used to carry craft is a kiloliter that can’t be used for any other important needs. It needed to carry a sensor suite capable of active, passive, and energy scans and pinpoints at ‘routine’ difficulty (MT RM pages 87-88). It also had to carry three secure, directional communication systems (laser or maser, maser preferred) one each to handle craft control, intel transmission, and communication relay duties. Additional communications systems as backup and/or supplemental capability were desirable too.

I also wanted at least 30 days endurance, with 60 days optimal, and I wanted to provide a solar power system that would allow unlimited operational endurance once it arrived at the desired location.

I had no price cap in mind in the design parameters, but a low overall price was considered optimal, so at each design stage I tried to keep costs at a minimum.

After I finished the first prototype design, I sketched out two more variants to represent systems from other manufacturers competing for the contract. I’ll cover those variants later in the thread.

 

[Major B]

Hull & Communications Array

So, the design process went something like this: First, I set the hull size at 1 Td, knowing I could come back and adjust it if everything I wanted wouldn’t fit. Since I didn’t see a need for operation in atmosphere, I chose configuration 7 (irregular) USL (unstreamlined) for the weight and cost savings, and left armor at 40 (minimum allowed) G (bonded superdense – minimum weight at no added cost).

Next, I figured out the communication systems. First I put in the three maser systems for primary communication, then I added another as an alternate. Note, when figuring out commo requirements, I think in terms of the acronym I learned as a young lieutenant – PACE – meaning for any operation you should have a Primary, Alternate, Contingency, and Emergency method of communication. For a contingency system I added a laser commo system (as this took half the volume and cost of a maser system) and added a radio for the emergency system. Then I decided that only the three primary systems needed to draw power at all times, as the others would only be switched on when a primary system failed. Then, I put the radio system on the list to be powered at all times, as it would always be good to be able to record any radio signals received so they could either be subject to direction-finding or run through the computer decryption program for analysis. Then, since the radio took up so little space, I added another to allow recording of twice as many frequencies at once.

I chose ‘far orbit’ as the range for all of my communication systems, since I did not foresee this craft operating at further ranges. This meshed well with the sensor systems, since they all ended up with the same range, as you will see in the next step.

 

[Major B]

Sensors

Next, I started working on the sensor package, and had to build some house rules since the design evaluation section of the MT RM does not exactly match the sensors and electronics section on pages 68-70). My goal was to be capable of a ‘routine’ difficulty on all three forms of scan and pinpoint (passive, active, and energy).

Active Object Scan and Pinpoint both require an active EMS array with a range of at least Far Orbit (500,000 km). I built a house rule chart (located here) for Active EMS arrays, expanding the chart on RM page 70, and then plugged a system with the right range into the craft design.

To obtain a Passive Object Scan at ‘routine’ difficulty requires a densitometer of at least TL14, but a ‘routine’ Passive Object Pinpoint requires a densitometer with 250 m penetration, so I chose the TL15 low penetration densitometer on RM page 69.

Passive Energy Scan at ‘routine’ difficulty required either a Passive EMS sensor of Interplanetary range or a combination of a smaller Passive EMS array and a neutrino sensor. Since the Passive Energy Pinpoint chart on page 88 showed that a neutrino sensor sensitive to 10 kw minimum magnitude was required for ‘routine’ difficulty, I installed one of those in the design. That meant I only needed a Passive EMS sensor suite with ‘far orbit’ range to obtain a ‘routine’ difficulty on the Passive Energy Scan ability, but the chart on page 70 omitted that range band so I created another house rule chart (located here) and installed the system into the craft.

Aside: The Passive EMS chart still needs some work, as I’m confused by the difference in range bands listed on page 88 of the RM (they are slightly different from those listed elsewhere in the RM). Once I find someone who can figure that one out (I’m not smart enough for this one), I’ll finalize the chart and replace the one I’ve posted.

 

[Major B]

M-Drive & Craft Controls

The maneuver drive was my next difficulty. The MT design sequence (page 65) only shows drive sizes for hulls down to 20 displacement tons, so I built another house rule table for hulls down to .5 tons. I haven’t formatted that for posting yet, but it will end up in the file library soon.

I haven’t fully thought the problem through, so I’m not yet sure where to place the lower limit on thruster drive volume, but at this point I still had a hull size of 1 Td which required a thruster volume of .675 kl to achieve 2G acceleration. This unit also required 3.5 MW of power.

Later I ended up reducing the hull size and that reduced the size of required M-Drive too, but I’ll cover that when it comes up.

Since this craft was not intended for combat, I used a model 0 computer initially. Later I saw that I could save some space in control panel requirements by using a model 0/bis. The more powerful computer cost a little more, but cut the number of control panels required in half at no increase in volume. I also chose to use computer linked control panels, rather than dynamic linked or holo linked, because this saved considerably in required volume and power.

 

[Major B]

Environmental Controls & Solar Power

Since it was a remotely-piloted craft, I did not install any environmental systems. Check me on this one everyone, because if there is something out there that says I need to install some environmental controls, then I’ll need to revise the design. That said, at this point, I had all of my subsystems installed and could determine how much power plant I needed, then calculate how much fuel I could hold.

Next I tried to install a solar backup power system, but quickly saw that the power requirements for the sensor suite and the comm systems were much more than what could be fit on the usable hull surface area, so I reduced the solar backup to a size that would power the computer and control panels plus one maser system.

This still allows the option that the craft could be told to turn off the power plant at a point where it was low on fuel, but still remain in communication, awaiting the order to fire up again and return to a specified point for recovery. It cannot, however, operate the sensors while running off solar power.

 

[Major B]

Power Plant & Fuel

Finally, the power plant. To ease calculating endurance, I added all of the systems that required power during normal operation separately from the power required by the maneuver drive. The M-drive required far more power than all of the other systems combined. Then I used all of the remaining space in the hull for fuel, by allocating enough fuel for six days of maneuver power and used all the remaining space to determine how much additional fuel could be allocated for operational power.

At this point, I realized that 1 Td was more than enough space, so I scaled back the hull size, then scaled back the M-drive size, then scaled back fuel, all by .1 Td steps – finally settling on .6 Td as the optimum. The final size of the required M-Drive (reduced for the smaller hull) was .405 kl drawing 2.1 MW from the power plant.

That done, I figured that (since all of the fuel is in one tank after all) I could determine the limits of endurance at max power and at the reduced power needed just to operate the sensors, comm. systems, and control systems. That worked out to 881.45 hours at max power (36.73 days) and 3,667.08 hours (152.79 days) at operational power. In reality, the craft’s true endurance will be somewhere in between these two numbers, depending on how long it is required to operate the maneuver drive in order to reach and maintain station. I was also happy that having full solar solar backup power was less of a concern than I had thought, since the craft carries enough fuel to operate at full power for over a month.

 

[Major B]

Remote Operations Terminal

Next, I tried to figure out what would be required aboard the parent vessel to remotely-control this craft.

Of course, a maser comm system dedicated to transmit control instructions and receive craft operating data was needed.

The computer that would have been the on-board backup for the craft was the main component of the control unit (My first assumption was that this computer should be at least as powerful as the one on the controlled craft, so I started with a model 0/bis).

Either a HUD or HHUD would be required for the remote pilot to exercise control (I chose the HUD to save on costs and volume).

Of course a seat for the pilot was needed (a roomy crew position from table 6 on page 82 of the RM).

Then, I decided that the remote position would have to be able to handle the same number of control points as the controlled craft needed, but the HUD add-on easily handled that requirement (276.88 needed, 500 sourced) so only one CLinked CPanel was needed.

Then, I realized that a model 0 could handle the control requirements easily (when coupled with the HUD) at less than half the cost of a 0/bis, so I tried that configuration. My initial assumption was that the computer in the remote terminal had to be at least as powerful as that in the craft, but as long as the control points are all addressed, I suppose any computer will do, as long as the computer from the control station is used for calculating the modifiers in starship combat. At any rate, I chose the model 0, which when coupled to the HUD required only five Clinked CPanels.

Summing all of these up, the requirements for the control unit were: (.0225 MW; 5.078 kl; .339 MT; .19385 MCr). Pretty cheap, but using these criteria to build a remote station for, say, a large fighter, would make the necessary volume and cost requirements an issue. That was what I was hoping for, actually, as there should be a significant cost to remotely-control a combat craft, but not so high a cost that it is impossible (in situations where mission requirements outweigh or justify the expense in terms of cost and volume).

I’ll be doing some more experimenting with this workup in the future and welcome feedback. I can see the Zhodani using remote craft for combat more often than Imperials, but the Imperium would probably use them for non-combat roles fairly regularly.

 

[Major B]

Summary & Final UCP

I tried two other designs to test other options at this point. One had a backup computer and backup sensors on board and retained the 1 Td hull I started with, but endurance was lower and cost was higher than the first design.

Another had a 3G maneuver drive, but the extra performance took too much from endurance and also cost more.
I worked those other designs into the backstory for the system, as competitor designs that did not fare well in trials. Then I worked out the design evaluation details and finished the spreadsheets, posted in the file library (here).

I chose the name Sangendar for the craft – from the Vilani dictionary, the term means guardian or overseer.

A summary of the final craft design follows (more detail is available on the linked page):

[B][U][FONT=Courier New]CraftID[/FONT][/U][/B][FONT=Courier New]: M589 Sangendar [Guardian] RPC-CNICS (Remotely-Piloted Craft –[/FONT]
[FONT=Courier New]Communications, Navigation, & Intelligence Collection System), TL 15[/FONT]
 
[B][U][FONT=Courier New]Hull[/FONT][/U][/B][FONT=Courier New]: 1/2, Displ=0.6, Config=7USL, Armor=40G, Unloaded=7.33 tons,[/FONT]
[FONT=Courier New]Loaded=7.72 tons[/FONT]
 
[B][U][FONT=Courier New]Power[/FONT][/U][/B][FONT=Courier New]: 1/2, Fusion=2.76 MW, Dur=36/110[/FONT]
 
[B][U][FONT=Courier New]Loco[/FONT][/U][/B][FONT=Courier New]: 1/2, Maneuver=2, NOE=0, Cruise=1,590, Top=2,120, Agility=0[/FONT]
 
[B][U][FONT=Courier New]Commo[/FONT][/U][/B][FONT=Courier New]: 3x Maser=Far Orbit (500,000 km)[/FONT]
[FONT=Courier New]     Maser=Far Orbit (500,000 km) – backup (unpowered)[/FONT]
[FONT=Courier New]     Laser=Far Orbit (500,000 km) – backup (unpowered)[/FONT]
[FONT=Courier New]     2x Radio=Far Orbit (500,000 km)[/FONT]
 
[B][U][FONT=Courier New]Sensors[/FONT][/U][/B][FONT=Courier New]: Act EMS=Far Orbit (500,000 km), Pass EMS=Far Orbit (500,000 km), [/FONT]
[FONT=Courier New]Densitometer=LowPen (250 m), Neutrino=10kw, ActObjScan=Routine, [/FONT]
[FONT=Courier New]ActObjPin=Routine, PassObjScan=Routine, PassObjPin=Routine, [/FONT]
[FONT=Courier New]PassEngScan=Routine, PassEngPin=Routine.[/FONT]
 
[B][U][FONT=Courier New]Off[/FONT][/U][/B][FONT=Courier New]: None[/FONT]
 
[B][U][FONT=Courier New]Def[/FONT][/U][/B][FONT=Courier New]: DefDM=+2[/FONT]
 
[B][U][FONT=Courier New]Control[/FONT][/U][/B][FONT=Courier New]: Computer=0/bis, CompLink x35[/FONT]
 
[B][U][FONT=Courier New]Accom[/FONT][/U][/B][FONT=Courier New]: Crew=3 (remotely-piloted), no life support installed[/FONT]
 
[B][U][FONT=Courier New]Other[/FONT][/U][/B][FONT=Courier New]: Fuel=5.455kl, Cargo=0, ObjSize=Small, EmLevel=Faint[/FONT]

 

[atpollard]

Since it was a remotely-piloted craft, I did not install any environmental systems. Check me on this one everyone, because if there is something out there that says I need to install some environmental controls, then I’ll need to revise the design.

A Basic Environment (RM, pg 81) provides heat and light.

While your remote electronics, fuel, power plant and drives should work fine in the dark, would 3 or 4 degrees Kelvin (background temperature in space) be a problem?

Hydrogen slush clogging lines and tanks comes immediately to mind.
Frozen atmosphere shorting electronics might be a possibility.

Would heat build-up from solar exposure cause problems without a system to dissipate excess heat?

I'm not sure that this applies to an 'unmanned' craft, but ...

Referee's Manual, page 60:
Life-Support and Sealed Environment: A craft may be
closed to the outside by being sealed; a craft in vacuum, trace,
exotic, corrosive, or insidious atmospheres must have life support.
Generally, a craft with life support must also be sealed.
However, life support may be used in an unsealed craft as a
substitute for oxygen tanks (although the crew must wear any
required protective suits).

 

[atpollard]

Next I tried to install a solar backup power system, but quickly saw that the power requirements for the sensor suite and the comm systems were much more than what could be fit on the usable hull surface area, so I reduced the solar backup to a size that would power the computer and control panels plus one maser system.
This still allows the option that the craft could be told to turn off the power plant at a point where it was low on fuel, but still remain in communication, awaiting the order to fire up again and return to a specified point for recovery. It cannot, however, operate the sensors while running off solar power.

At TL 14, a 500,000 km EMS Active Array weighs 0.030 tons and requires 0.3 MW of power, while a 50 km EMS Active Array weighs 0.005 tons and requires 0.05 MW of power. Is it reasonable to assume that an EMS (passive or active) Array could be operated at a lower power setting and reduced range?

At TL 14, (500,000 km) EMS Active Array operating at 0.05 MW rather than the full 0.3 MW of power would have its range reduced to 50 km [but that is 50 km more than you had before]. By power sharing, your craft might be able to alternate between scan mode and communications mode on some preset interval (say 20 minutes).

A small battery system might let you trickle charge the batteries for 24 hours and use the power to perform one full strength scan for 20 minutes.

Just brainstorming here.

 

[Major B]

I'm not sure that this applies to an 'unmanned' craft, but ...

I was hoping that it didn't...

 

[Major B]

A small battery system might let you trickle charge the batteries for 24 hours and use the power to perform one full strength scan for 20 minutes.

Just brainstorming here.

That is a great idea! Getting a workable solar system will make up for the space (and endurance) I'll lose by installing basic environment (and the larger solar system plus batteries).

I'll make a second version to see how that works out...

 

[Major B]

Basic Environment Added

I added basic environment to the craft.

By itself, the basic environment took up and additinal .041 kl and added .041 MT to weight. Cost was negligible (81 Cr).

I had to increase the power plant slightly to handle the additional load, and similarly increase the size of the solar backup.

All additional component volume forced a reduction in the fuel tankage, but it only had a slight effect on overall endurance. Max endurance at full power was reduced from 36.73 days to 36.32 days and max endurance at operational power was reduced from 152.79 days to 149.73 days.

 

[Major B]

Deployable solar collectors?

The maximum usable surface area on this craft is 2.846 square meters which can produce up to .231 MW.

I never thought before, but the solar power tables only consider hull surface area. Has anyone developed house rules for deployable collector panels?

To run the full sensor and comm suites, plus controls and environment, I'd need .673 MW requiring a collector with a surface area of 8.304 square meters. Any ideas on how small or a volume that size panel could fold down into?

 

[atpollard]

I never thought before, but the solar power tables only consider hull surface area. Has anyone developed house rules for deployable collector panels?

To run the full sensor and comm suites, plus controls and environment, I'd need .673 MW requiring a collector with a surface area of 8.304 square meters. Any ideas on how small or a volume that size panel could fold down into?

I'm still working on volume, but I found Weight:

A solar panel for Skylab measuring 31 feet by 27.3 feet and weighed 2,288 pounds [80 square meters = 1040 kg] so an absolutely worse case (space TL doesn't get much older than Skylab) would be 108 kg for your desired 8.304 square meters.


[EDIT] A 1995 NASA report describes "HIGH-PERFORMANCE, FLEXIBLE, DEPLOYABLE ARRAY DEVELOPMENT FOR SPACE APPLICATIONS" as working on a 1 kW system with an area of 13.3 square meters and a complete system weight of 10 kg that will roll into a stowage volume of less than 0.21 cubic meters. Since most of the weight and volume of any solar array is the supporting substrate (rather than the actual photovotaic film), this weight-volume-area data should be good for any solar cell above TL 7.

 

[Major B]

Solar Unit Weights

At TL 6, each m^2 of Solar Cell weighs .02 MT or 20 kg

So 80 m^2 would weigh 1600 kg or 1.6 MT

Slightly higher than the skylab panels, but the table in the RM is stipulating solar cells that affix to the hull - the collector panel alone would probably be lighter with some of the internal hardware from the cell placed inside the hull.

More importantly, the weight requirements decrease by half at TL 11 and a fraction more at TL 12 => from .02 at TL 6 to .01 at TL 11 and .008 at TL 12.

So... ((108 * .008) / .02) = 43.2 kg or .043 MT

Check my math - I'm a history major.

 

[Icosahedron]

So... ((108 * .008) / .02) = 43.2 kg or .043 MT
Check my math - I'm a history major.

You've used Arthur's 108kg instead of the TL6 value you gave of 160kg. Was that intentional?

 

[Major B]

You've used Arthur's 108kg instead of the TL6 value you gave of 160kg. Was that intentional?

Yes. On the assumption that the panels affixed to the hull would be heavier than deployable fold-out panels.

When I finalize the design, the difference in weight between the deployable panels and panels of comparable size affixed to the hull will be the weight I'll use for the components that remain inside the hull after the panels fold out, plus a little extra weight to account for the deploying mechanism.

I'll probably finish this off by drafting some errata to run by Don to see if he'd like to include it in his compendium. Might also run it past Commander Drax to consider for the next issue of Frontier Report, along with the final Sangendar design.

 

[Major B]

[EDIT] A 1995 NASA report describes "HIGH-PERFORMANCE, FLEXIBLE, DEPLOYABLE ARRAY DEVELOPMENT FOR SPACE APPLICATIONS" as working on a 1 kW system with an area of 13.3 square meters and a complete system weight of 10 kg that will roll into a stowage volume of less than 0.21 cubic meters. Since most of the weight and volume of any solar array is the supporting substrate (rather than the actual photovotaic film), this weight-volume-area data should be good for any solar cell above TL 7.

Missed your edit until I was reading back through the thread to check some of the numbers I've copied down.

Been trying to correlate the real-world data with what is in the RM, and keep hurting my brain. Probably need to stretch better before this type of exercise.

The biggest problem is that the power potential in the real-world data is far below the potentials listed on the RM, making it hard to correlate weight and volume to what is published. Example - the above panel provides 1 kw in a 13.3 m^2 surface, while a TL 6 panel in the RM provides the same power output in a 1 m^2 surface, and a TL 7 panel has twice the power output.

So, maybe a simplification is better. Does it make sense to state that a deployable panel (rather than the listed panels affixed to the hull) can be installed at +50% to listed weight, +50% to listed cost and -50% of list volume?

And if that is plausible, what should the upper limit on size be? Any limit beyond the amount of hull space available to hold the panel while stowed?