Author Topic: Sensor Model for C# Aurora  (Read 10578 times)

0 Members and 1 Guest are viewing this topic.

Offline Praetori

  • Able Ordinary Rate
  • P
  • Posts: 4
Re: Sensor Model for C# Aurora
« Reply #15 on: March 28, 2017, 03:03:29 AM »
My 2c to the discussion.  This is not mechanic specific but more food for thought.
If I may I'll begin with an oversimplified rant (and I do mean it, but there's a lot going on behind this reasoning) of how most RL military longer-range (as in stuff viable for space) sensors work.
They're all based around particle detection, and emission but that's self explanatory (mostly photons of varying wavelengths).
I won't be going into other types of sci-fi sensors since then it's more literature and preference than anything else.

Range and resolution is a combination of:
Wavelength/Bandwidth: Radio<->MW<->IR/heat<->Visible Light<->UV (in modern day practical solutions) but cost, power and size increases exponentially with output and bandwidth.
Aperture/antenna-size: This can be actual massive antennas, networked arrays or synthetic arrays (ie the sensor is moving forming a virtual large-size antenna over time and processing for LR detection with multiple returns).
Output Power: the more the merrier but it's like shining a flashlight in a dark forest, your beam will be seen at much longer ranges than the range it provides in any case.
Processing power: Think SETI@home or supercomputing if you are to make the most of sent/collected information.

High resolution can, for explanatory reasons, be simplified down to a function of wavelength, time, distance, antenna-size and processing-power.
Long wavelength radio provides less possible resolution and requires larger antennas (actual or arrays) compared to high wavelengths and for single non-networked sensors the wavelength provides a fixed range-vs-resolution (ie arc second limitations vs array size) but can get away with simpler antennas/apertures.
High wavelength does provide higher bandwidth and good resolution but does require a lot of power to be useful (basically techniques for various degrees of collimation/beam-forming is the only thing making it feasible for active sensors over range and then with limited FOV (or time to scan a section of space if you will), think laser rangefinding).  There's always a problem with multipathing from various objects the higher you go (basically increases with wavelength/resolution) which means you'll have to rely on encoding your emissions more which requires more processing-power and so forth.

We could dig deeper into beamwidths and Fresnel sizes etc but it's sufficient to say that narrowbeam is better than omnidirectional in terms of power req vs resolution vs overall noise.


Now one might think that I'll build a gazillion of smaller sensors in all the different flavors and spread them out everywhere which is fine in principle but less so in practicality (power, maintenance etc) .
If they're active and share bandwidth/wavelength they need to be completely synchronized or you'll basically have created a huge noise-machine which could be further diminished in use by a hostile adding to the noise-level (ECM) so they'd all need to be networked and then it's just a big can of worms in terms of micro-management (as far as a game goes).

Passive detection is important but, for the sake of simplicity, should give much less accurate positions (a single passive sensor or multiple non-networked ones would in reality only give a very rough estimate from bearings as they can't range the target).  Large networked arrays of passive sensors could be modeled as single installations of great size instead (and cost accordingly).  For a passive sensor to be really useful it needs to be networked and convey collected information in one way or another which means that even a passive sensor is actually active (in terms of transmissions for networking).  Emissions control is paramount to avoid passive detection.  That includes getting rid of heat in various clever ways while absorbing as much incoming photons as possible (man made or natural) or deflecting them in directions where the enemy has no sensors.

To keep it simple I would suggest a noise-level for a given system.  If you add a gazillion of sensors with all the bells and whistles and large output-power you will get diminishing returns somewhere along the line where you're basically just adding background static noise reducing the efficiency of your active sensors and broadcasting a huge bulls-eye for passive sensors.
Background ECM could add to said noise-level and so could environmental stuff (nebulae, quasars etc) with the base-line that it's always easier to destroy than to create.

TLDR; (without any further regard to other mechanics)
Sensor basic attributes could be divided into power, bandwidth, cost and size.
Complex systems with large BW would be expensive and have very high maintenance requirements.
Systems with a large power output could be a bit cheaper (but with higher power requirements) but then visible from afar and noisy.
Large systems are. . .  large and thus cost accordingly and require processing power and networking (if arrayed).  Large stuff is easier to hit and harder to protect.
Lots of active sensors with lots of power means good coverage but also lots of noise (reducing resolution at range).

Also.  Atmospheres are bad.  Earths atmosphere for example is semi transparent to visible light and some ELF but practically opaque to a lot of other wavelengths (as far as reasonable deep-space sensors go).  Sensors on planets can be built to huge sizes and the orbital movement can be used for very long range synthetic arrays but it's highly dependent on the atmospheric conditions of the specific planet.

Also.  Anti-radiation passive warheads are super simple compared to active sensors and kills expensive active sensors and comms IRL.  Like Alex wrote they're the scourge of active sensors and really really nasty IRL.  In sci-fi terms in space a ARM could creep along with not a hurry in the world (loitering mode) and then jump you when you turn on your sensor back on.
Real ARMs guide by back/side lobe artifacts from the transmitter so they don't even have to be in the main sequence lobe (and can thus come from anywhere).
 

Offline MarcAFK

  • Vice Admiral
  • **********
  • Posts: 2005
  • Thanked: 134 times
  • ...it's so simple an idiot could have devised it..
Re: Sensor Model for C# Aurora
« Reply #16 on: March 28, 2017, 06:49:27 AM »
Some interplay between active sensor noise (friendly and hostile) and ECM/eccm should probably be considered for any future changes to the ecm mechanics. Interesting read Praetori.
At the moment increasing wavelength (active sensor range) just gives a set range increase across the board for free. What if that increased range also required increased power? Sensors could and perhaps should require power from a power plant to function, and said power plant should add to thermal emissions.
Finally power plants should consume sorium fuel to operate, perhaps at the same rate as shields.
" Why is this godforsaken hellhole worth dying for? "
". . .  We know nothing about them, their language, their history or what they look like.  But we can assume this.  They stand for everything we don't stand for.  Also they told me you guys look like dorks. "
"Stop exploding, you cowards.  "
 

Offline swarm_sadist

  • Lt. Commander
  • ********
  • s
  • Posts: 263
  • Thanked: 21 times
Re: Sensor Model for C# Aurora
« Reply #17 on: March 28, 2017, 08:09:47 PM »
To keep it simple...
Failed on the first attempt.  ;D

Quote
I would suggest a noise-level for a given system.  If you add a gazillion of sensors with all the bells and whistles and large output-power you will get diminishing returns somewhere along the line where you're basically just adding background static noise reducing the efficiency of your active sensors and broadcasting a huge bulls-eye for passive sensors.
Background ECM could add to said noise-level and so could environmental stuff (nebulae, quasars etc) with the base-line that it's always easier to destroy than to create.
Having a noisy system would actually make it easier for passive sensors to detect objects in certain situations. I remember Germany used BBC radio signals to detect bomber formations in WW2. Effectively you would have an active sensor where the emitter is separate from the receiver dish (a passive "active" sensor, you could say).

I do like the idea of natural emission sources such as Gas Giants or Stars blocking out smaller emissions. Not sure how my CPU would take that though.

Quote
Also.  Atmospheres are bad.  Earths atmosphere for example is semi transparent to visible light and some ELF but practically opaque to a lot of other wavelengths (as far as reasonable deep-space sensors go).  Sensors on planets can be built to huge sizes and the orbital movement can be used for very long range synthetic arrays but it's highly dependent on the atmospheric conditions of the specific planet.
Good point. Having 50 DSTS on Venus wouldn't make much sense unless they were searching for radar sources. Not so good for telescopes. Maybe DSTS should be used to track long range passive targets that have already been detected by other sources instead? Let you track targets who move in and out of your ship passive sensor range?

One important thing that most military sensors have in RL is c lag. To determine range against targets emitting ECM, the radar array has to pulse the radar in intervals/different frequencies and calculate based on the return of those signals. Effectively, even when the target is within range, the radar system won't pick up the target right away. The sensors need to be left on for a period of time long enough to find the target and get an accurate range/bearing. RL phased array sensors also have methods of masking their emissions (again through side pulsing, multiple weak emissions, etc) that make it harder for passive sensors to track their range and bearing instantly. Thus with the right technology, both passive and active sensors require time to find their target, making naval warfare a game of cat and mouse (or whack a mole).

By the way, welcome to the forum.
« Last Edit: March 28, 2017, 08:11:45 PM by swarm_sadist »
 

Offline Praetori

  • Able Ordinary Rate
  • P
  • Posts: 4
Re: Sensor Model for C# Aurora
« Reply #18 on: March 31, 2017, 04:47:56 AM »
Quote from: swarm_sadist link=topic=9465. msg102099#msg102099 date=1490749787
Failed on the first attempt.   ;D

That WAS simple in my book  ;D
Quote from: swarm_sadist link=topic=9465. msg102099#msg102099 date=1490749787
One important thing that most military sensors have in RL is c lag.  To determine range against targets emitting ECM, the radar array has to pulse the radar in intervals/different frequencies and calculate based on the return of those signals.  Effectively, even when the target is within range, the radar system won't pick up the target right away.  The sensors need to be left on for a period of time long enough to find the target and get an accurate range/bearing.  RL phased array sensors also have methods of masking their emissions (again through side pulsing, multiple weak emissions, etc) that make it harder for passive sensors to track their range and bearing instantly.  Thus with the right technology, both passive and active sensors require time to find their target, making naval warfare a game of cat and mouse (or whack a mole).

Actually the PRF is not the only way to deal with c lag.  Encoding each pulse (in PD) or arbitrary wave packet (in CW) in encrypted packets and utilizing orthogonal modulation (basically symbol encoded pulses) makes it possible to not only distinguish unique echoes on the first try but also deal with rudimentary delay jammers and multipathing issues.  It also helps if you have multiple systems operating in the same area (and can include IFF as well).  It does use more of the precious bandwidth though so you'll saturate the spectrum quite quickly for long range applications.  For stealthy short range systems with limited output or very wide spectrum abilities it's pretty darn nifty though.

Quote from: swarm_sadist link=topic=9465. msg102099#msg102099 date=1490749787
By the way, welcome to the forum.
Thanks.  I've been a member since 2012 but I've been a first class lurker apparently.   8)
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: Sensor Model for C# Aurora
« Reply #19 on: March 31, 2017, 02:25:31 PM »
I like the change. Making a somewhat more complicated but realistic sensor model is great and would bring Aurora closer to Harpoon, which would be my ideal.

I'm against sensor buoys or satellites becoming a necessity - as others stated, the micro-management will be hell. There's a reason why I never bother with mine fields. On the other hand, I already plop down one or two DSTS all over important systems despite knowing that it's better to have ten on a planet. Changing the effectiveness of DSTS to be like sector command is a great change and would make it more logical to spread them around. They don't need a colony to support them - Cold War era listening and radar installations along the Iron Curtain were certainly closed installations and many of them were in quite inhospitable places. With TN tech, it should be feasible enough to have listening posts on asteroids and moons without civilian infrastructure to support them.

I also support making them a bit more expensive - not as expensive as shipyards but perhaps going from 300 to 600 would be sufficient.

Anti-Radiation missiles are a great concept - I think they are currently not really feasible because the passive sensors you can put in missiles are so useless but maybe I'm wrong.
 

Offline swarm_sadist

  • Lt. Commander
  • ********
  • s
  • Posts: 263
  • Thanked: 21 times
Re: Sensor Model for C# Aurora
« Reply #20 on: March 31, 2017, 07:13:03 PM »
Thanks.  I've been a member since 2012 but I've been a first class lurker apparently.   8)
Holy crow!

I like the change. Making a somewhat more complicated but realistic sensor model is great and would bring Aurora closer to Harpoon, which would be my ideal.
It should probably be  simpler than that. Harpoon has you dealing with only one task group or task force at maximum, while Aurora has multiple task forces, multiple systems and an economy to deal with. Ditto on buoys, managing hundreds of surveillance buoys would be a nightmare.

Quote
I also support making [DSTS] a bit more expensive - not as expensive as shipyards but perhaps going from 300 to 600 would be sufficient.
I think DSTS should be rethinked completely. Currently they are like PDCs with passive sensors, but require no crew, no armour, no engineers to build, can be moved around with freighters, are nearly invisible to passives, completely invisible to actives, and cost a lot less. Their cost isn't the issue.
 

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 544
  • Thanked: 39 times
Re: Sensor Model for C# Aurora
« Reply #21 on: April 01, 2017, 06:23:00 AM »
I like the idea of reducing sensor range and adding some more complexity to the system but would welcomed me an improved system to set up task groups with detached pickets to help manage this. Potentially a way to set up carriers to run cap missions would be great.
 

Offline Titanian

  • Sub-Lieutenant
  • ******
  • T
  • Posts: 105
  • Thanked: 20 times
Re: Sensor Model for C# Aurora
« Reply #22 on: April 01, 2017, 01:49:18 PM »
I also support making them a bit more expensive - not as expensive as shipyards but perhaps going from 300 to 600 would be sufficient.
I guess the problem here is that their cost stays the same, but their effectiveness can be increased with research. Ship mounted passive sensors on the other hand have a constant cost effectiveness and only get smaller.
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: Sensor Model for C# Aurora
« Reply #23 on: April 02, 2017, 05:52:17 PM »
To be honest a 'wealth upkeep' for non-production facilities or production facilities currently not in use or shut down wouldn't be entirely amiss. And I mean all facilities, including mass drivers, deep space tracking stations, academies, spaceports and sector commands. You'd need to be able to offline part of your facilities though, rather than the current all or nothing for production stuff. Mostly this is to pay for all support staff and their supplies, and it doesn't even need to be a lot of money.

But with deep space tracking stations, it could escalate in costs as better sensor tech is developed, like what happens with researching boosts for production facilities as they need more money as they become more productive.
 

Offline Praetori

  • Able Ordinary Rate
  • P
  • Posts: 4
Re: Sensor Model for C# Aurora
« Reply #24 on: April 03, 2017, 06:46:48 AM »
Quote from: Garfunkel link=topic=9465. msg102188#msg102188 date=1490988331

I'm against sensor buoys or satellites becoming a necessity - as others stated, the micro-management will be hell.  There's a reason why I never bother with mine fields.

Maybe they could be abstracted somehow? There's really no reason to keep track of every single sat/buoy.  Much like maintenance now being a total you could have DSTSs with sensor consumables (maybe PDC/ship component requirements etc) and have the actual buoys be abstracted in some way.