Optimal Space Scanner Build

[TunderLock]

Hi all, 

Wondering if others have input on what the optimal space scanner build is. By optimal I mean it should:

1. Maximise uptime of the solar panels
2. Minimise the energy spent on the scanner network

My current theory would be:

1. Build a network with 100% scanning quality, guaranteeing 200 second forecast
2. Turn the network on briefly every X seconds
3. If positive signal received, then meteror shower is in minimum (200-X) and maximum 200 seconds.
4. Time the doors to close just in time for the meteor shower assuming (200-X) seconds, lose maximum X seconds of sunlight.

The bigger we make X, the more energy we save on the scanner network, but the more light we will lose in closing the doors early. Potentially we could solve equations (given number of scanners, doors and panels) to achieve maximum wattage under given meteor cycles, but I'm wondering what thoughts/builds others in the community have?

[tzionut]

Already discussed

 

[TunderLock]

58 minutes ago, tzionut said:

Already discussed

 

I'm aware of that post (I helped contribute to it) I don't see how it discusses the optimization I have described in this thread. 

[ruhrohraggy]

I'm gonna take a stab at this...

[ZA_sT3V3]

I have been looking at the same issue and have decided to a combination of the following 3 suggestions:

 

If it works plus rep/thanks to the authors

[ruhrohraggy]

Here are my findings after about 4 hours of theorycrafting and number crunching for a potential 6x Pulsed Scanner network, versus the 2x Scanner Network I spent nearly 400 cycles developing / testing.

I don't have any actual designs laid out for the 6x...but Theoretically, the way I would run 6x pulsed scanners would be as follows : 

Stick them high up under 1x bunker door with a double airlock door-floor automated to get rid of meteor debris. I would automate all 6 scanners to pulse for 1-2 seconds after the bunker doors fully opened using the airlock-door-floors, then shut off. I would pulse them every 37.2 seconds until meteors were detected. When incoming meteors are detected, I would use a filter or buffer gate (whichever happens to be easier to automate) and set it for 200 seconds, where it would hold and then output the signal to my bunker doors. I would have all of my scanners become completely inactive for this 200 seconds by opening the airlock door-floors, to save additional power. After 200 to 238 seconds are up, the meteor showers hit, I would have 1 scanner re-activate after the 200 second mark to hold signal on the bunker doors. Once it lost signal / the meteor shower was over and the bunker doors began to open, I would disable it once again to save power until the doors opened. From here, the cycle would repeat.

Now here's my efficiency number crunching for this 6x scanner setup vs. my 2x scanner setup that I've already built...

The map has 252 usable horizontal tiles, enough for 36 Solar Panels in a line.

2x scanners can use 35 solar panels, 6x scanners can use 33 solar panels if you place them side by side.

This means during peak light, maximum total potential energy lost is 13,300 watts for 35 dishes, and 12,540 watts for 33. Since solar dishes start out at 0 watts, increase to 380 watts over 90 seconds, hold at 380 watts, for 345 seconds, and then decrease back to 0 over 90 seconds...we can have some fun and just use the E.max of 380 watts.

6x Scanners need 4.3 kJ for every one second of pulse. They would most likely have at minimum, 6x bunker doors protecting them. 6x doors run for 38.2 seconds @ 120 watts each to open, and again to close, for a total of 55 kJ. The scanner pulse is, ideally once every 37.2 seconds, for one second. (Maybe 2?, this would need testing)

6x Scanners lose 2 solar panels for a non-staggered solar panel setup occupying the entire length of map. (4x tile scanner x 4 scanner = 16 tiles, solar panels are 7 tiles wide)

6x Scanner system has an average detection error of 19.1 seconds if you are pulsing them. with the max error being 38.2 seconds. This is because it may pick up incoming meteors 162.8 seconds before falling, up to 200 seconds before falling, if the network picks up the leading edge of the shower.

Meteorology guide tells us there are 2 meteor seasons, peace and meteor. Meteor season lasts 10 cycles, peace lasts for 4 cycles.

Meteor season is divided into break and shower. Break is between 300-1200 seconds, shower is between 100-400 seconds. We could say break totals 600 seconds on average, and shower 200 seconds on average.

If the meteorology chart is reliable you can actually wait to start pulsing your scanners again for 100 seconds once a meteor shower is over. From here, at minimum, you will need 1 pulse to detect the next signal, and at maximum you will need 25 pulses ((1200 - 100 - 38.2)/38.2)

For one break period, 6x scanners will use P.min = 55.7 kJ, P.max = 73.7 kJ.

For one break period, 2x scanners will use P.min =  56.7 kJ, P.max = 296.3 kJ

If Avg. break is 600 seconds, and average shower lasts 200 seconds = 800 seconds. so 10 x 600 / 800 = 7.5 meteor attacks per Meteor season on average. Lets call it 8.

For a full, average Meteor Season :

The 6x scanner system uses P.avg. 294.4 kJ for scanning, losing 19.1s x 12.6 kW = 240 kJ due to scanner error, totaling  534.4 kJ used / lost over 8 Meteor Showers

The 2x scanner system uses P.avg 1148 kJ, losing 8703.5 kJ potential power due to scanner error, totaling 9851 kJ potentially used / lost over 8 meteor showers from early closes. With a higher frequency of meteors, this system fairs even worse, a lower frequency, it fairs better.

On average though, the 6x scanner system comes out a sizeable 1843% more efficient during your average Meteor Season, netting us an additional 8853.6 kJ over 10 cycles , but again, we're assuming the meteor shower always hits during peak time...

If the meteor shower happens to land 90s before nightfall, or just after nightfall, the 2x scanner setup only loses a little less than 17 kJ per panel. Where'd this number come from? Using area under the curve and some trig, I found a singe solar panel gains roughly 17 kJ for the first and last 90s of the day cycle. Our average time wasted is 81 seconds. This means around 550 to 600 kJ total loss across all 35 panels and around 4,400 to 4,800 kJ total loss over the 8 cycles of meteor showers....losing even less power if it hits right before, or during night. This means the 6x pulse scanner setup is now only 900% more efficient, give or take.

But, the 6x scanner setup has 2 less solar panels. So far I've been giving the advantage to 6x scanners, so now we're going to assume that all 8 meteor showers happen roughly 62.5 seconds before night, which would center the storm on the night cycle... this would mathematically cost us the most possible power lost from our 2 missing solar panels, since solar panels collect the most energy for the 345s period during the middle of the day.

I had to do a bit more trig here to subtract areas for power under the curve, so I won't go into it, but if you want to see my fancy diagram I can post it, otherwise...

The total power lost from 2 solar panels not collecting power for the above scenario, is 147.8 kJ x 2, or 295.6 kJ.

Over 10 cycles there will be 8 showers, so for simplicity sake, lets say there will be 8 meteor cycles with interruption, and 2 full cycles of light gathering.

2 Full cycles is 165.3 kJ * 2 * 2 = 661.2 kJ lost

8 cycles with meteors landing 63s before night loses us  147.84 kJ * 2 * 8 = 2,365.44 kJ

For a total of 3026.4 kJ lost during the 10 cycle meteor storm, by not having those 2 solar panels.

Now, During Peace time, which is 4 cycles, we also aren't benefiting...

(4 cycles x * 165.3 kJ * 2) = 1322.4 kJ

For a grand total of 4348.8 kJ lost, from not having 2 dishes over a Meteor Season, and a Peace Season.

Taking into account only the meteor season, we have a total of 9851 kJ lost on average with the 2x scanner setup, and 3560 kJ power lost on average with the 6x Pulse Scanner theorycraft. If meteors tend to happen towards the middle of the day, 6x scanners handily win out, being ~ 280% more efficient. If more of the meteor strikes happen at night...it doesn't come out ahead as much...only ~38% more efficient.

Conclusion : The 6x scanning array can be quite a bit more power efficient, but will require much more planning and automation. It also benefits more from having more dishes. With less dishes, I don't see it being as efficient. Now, if you filled the entire cross-section of the map with staggered dishes...it would be leaps and bounds more energy efficient than a 2x dish setup for sure.

Oh, and if you're interested...my 2x scanner build / guide that I've been comparing to this 6x scanner theorycraft idea is here :

 

[Mullematsch]

 

[ruhrohraggy]

At a glance that setup is already way less than perfect. Solar panels aren't staggered...door-floors cycle way more than they need to, (Why even bother collecting regolith? it should delete itself after awhile if you let your doors munch on enough of it) and there's no indication as to what the actual bunker door activation time is (I'm gonna assume the full 200 seconds). Heck, the extra scanners aren't even de-activated once they pick up the signal...

[Mullematsch]

1 hour ago, ruhrohraggy said:

At a glance that setup is already way less than perfect. Solar panels aren't staggered...door-floors cycle way more than they need to, (Why even bother collecting regolith? it should delete itself after awhile if you let your doors munch on enough of it) and there's no indication as to what the actual bunker door activation time is (I'm gonna assume the full 200 seconds). Heck, the extra scanners aren't even de-activated once they pick up the signal...

I continuously waste natural gas for polluted water. Power is really not a concern for me so I did not bother optimizing it.

I collect the regolith so I can automatically sort it from the iron, cool down the iron to a usable temperature in the base and ship of the regolith to different builds:

Got a regolith to clay project going on, planning on smelting regolith in my minor volcano and also using the heat of it in a couple locations.

Everything you mentioned is easily fixable with my design just by adding a couple filter gates and playing around with some timing. Really no fundamental flaw with the build itself.  

 

 

[Angpaur]

1 hour ago, Mullematsch said:

Really no fundamental flaw with the build itself.  

If it has flaws then it is not perfect, but yet you called it perfect.

[ruhrohraggy]

9 hours ago, Mullematsch said:

I continuously waste natural gas for polluted water. Power is really not a concern for me so I did not bother optimizing it.

I collect the regolith so I can automatically sort it from the iron, cool down the iron to a usable temperature in the base and ship of the regolith to different builds:

Got a regolith to clay project going on, planning on smelting regolith in my minor volcano and also using the heat of it in a couple locations.

Everything you mentioned is easily fixable with my design just by adding a couple filter gates and playing around with some timing. Really no fundamental flaw with the build itself. 

 

 

 

Right, but what I'm saying is you sorta missed what the op was getting at and just posted your own setup which does none of what he was wondering about...

Let's read the first part of his post again....

"Wondering if others have input on what the optimal space scanner build is. By optimal I mean it should:

1. Maximise uptime of the solar panels
2. Minimise the energy spent on the scanner network

Etc...

I have a genuine interest in optimizing solar, which is why I took a look at a potential design for pulsing 6x scanners. I worked out a reasonable mathematical model, to figure out how to pulse them and optimize up-time of the solar panels. After that, compared the system to the most current system that is commonly being used, and then decided whether or not it's worthwhile to even bother...

It irks me when people post in a thread and don't even bother to read what OP had to say.

Turns out...it's a fairly interesting and worthwhile idea...The crux of the 6x scanner pulse idea though, is how long dishes actually need to be pulsed to reliably pick up a signal from their off state. I believe it's 1 second...and if that's the case...

I'm currently working on building and testing OPs Idea...I think all of the automation needed is doable...

 

[Mullematsch]

4 hours ago, ruhrohraggy said:

 

Right, but what I'm saying is you sorta missed what the op was getting at and just posted your own setup which does none of what he was wondering about...

Let's read the first part of his post again....

"Wondering if others have input on what the optimal space scanner build is. By optimal I mean it should:

1. Maximise uptime of the solar panels
2. Minimise the energy spent on the scanner network

Etc...

I have a genuine interest in optimizing solar, which is why I took a look at a potential design for pulsing 6x scanners. I worked out a reasonable mathematical model, to figure out how to pulse them and optimize up-time of the solar panels. After that, compared the system to the most current system that is commonly being used, and then decided whether or not it's worthwhile to even bother...

It irks me when people post in a thread and don't even bother to read what OP had to say.

Turns out...it's a fairly interesting and worthwhile idea...The crux of the 6x scanner pulse idea though, is how long dishes actually need to be pulsed to reliably pick up a signal from their off state. I believe it's 1 second...and if that's the case...

I'm currently working on building and testing OPs Idea...I think all of the automation needed is doable...

 

You are right.

I was just coming from the perspective that the design I posted is pretty close to perfection "design" wise.

Adding automation to turn off the other scanners and opening/closing doors with perfect timing and so on is quite easy to add.

Let me know once you figure out how long to turn on the scanners and the other quirks. I am too lazy to mess with it currently but I would be happy to add it to the design if you give me the numbers!

[ruhrohraggy]

I'm already quite far along with design already. The automation is just not very straightforward....and the timing is the hardest part anyway, so yeah once you have the timing it's a little more trivial, but not by much.

The problem is, you have alot of automation signal interacting...so you have to be clever with how the signal is routed...

The most straightforward approach I can see, and what I'm in the process of building, is automating the airlock doors under the 6 scanners to handle the cycling at "xyz" interval for "xyz" duration.

When any scanner picks up a signal, this must end the cycling of the airlock doors, with the doors remaining open to disable the scanners, we know the meteors are coming, we have a really good idea when...we don't need them on anymore for the time being.

After any scanner picks up a signal it must also output it to a buffer gate to hold the signal to "close doors" after "xyz" amount of time, in this case, 200 seconds.

As soon as this signal is released, the doors should close, and another signal needs to be sent to only 1 of the Scanner's airlock door-floor to close, so it can be active again during the meteor cycle, and this must happen separately from the rest of them while still remaining on, and not affect the pulse automation. The best time for it to be active again, is right before the bunker doors close, so we're not wasting any extra power.

After this one scanner detects that the meteor shower is over and stops out-putting signal, it needs to then relay this to the bunker and airlock door-floor so they can again open.

This 1 scanner is again, not needed at this point, so that's why we open its' floor back up.

After all this takes place, the cycle starts up again...

Not very trivial if you ask me, though I don't have a whole lot of practice automating in oni.

[ruhrohraggy]

Fyi, I learned, after finally getting a circuit that actually works and does what I want it to do (mostly)...This idea will not work.

The reason it will not work, is because ONI does not save the state of your Automation gates. So trying to buffer any signal from a network like this will eventually lead to solar farm death by fiery meteors and regolith.

If you so happen to get an auto-save during an incoming meteor storm, where any signals are being buffered, they are reset to 0 upon loading back in. So if you save your game sometime just before a signal could be picked up, or some time after a signal is picked up, your solar farm is as good as dead. An optimized signal, by it's very nature, will not make it in time to close the doors.

The only way to avoid this is to only save and exit the game as soon as a meteor shower is up...Nobody would want to remember to have to do this...I don't want to remember to have to do this...so...yeah.

It's great in theory, bad in practice. I'll have to settle for my 2x scanner build that I'll NEVER have to worry about again once it's setup...and it doesn't waste all that much power, it's pretty darn efficient at what it does...

[mathmanican]

There are ways to automate things between save/loads.  You can use a small liquid pump, with a predefined amount of liquid, to basically do what you want perfectly. Just pump the liquid to above a door, till the liquid is gone which triggers whatever you want. Then have the door open, dropping the liquid back down, only to be pumped back up when you send a signal to the pump to start working again. 

[ruhrohraggy]

1 hour ago, mathmanican said:

There are ways to automate things between save/loads.  You can use a small liquid pump, with a predefined amount of liquid, to basically do what you want perfectly. Just pump the liquid to above a door, till the liquid is gone which triggers whatever you want. Then have the door open, dropping the liquid back down, only to be pumped back up when you send a signal to the pump to start working again. 

Thank you for this, I can already think of a way to make this immediately useful to my pulse scanner build if I get desperate enough to employ it.

If that's the case, since the filter / buffer times will always be the same, and the majority of my pulse-system is at rest when the important automation is happening...

I can simply replace the filter gate controlling the bunker doors with the liquid pump analog.

I guess the "easiest" way would be to use a mini-pump with a flow-restrictor and a pre-defined amount of water bottles dumped in from a pitcher-pump...do the math, work out what my flow-restrictor needs to be set at to give me the desired time, and then use a liquid sensor to trigger the automation.

Seems like a real pain in the butt though...Possibly fun? Almost like hooking an hourglass up to a computer...but it's still dumb that I'd have to do it...

I think what would be easier is to just make an override. Worst case scenario, you can route a switch all the way to base (automation wire is pretty cheap, and if you even manage to build a setup like this, you're probably already swimming in refined iron anyway), prio-9 it, and have a dupe flip it if that situation ever pops up...

Really I'm just annoyed that automation isn't saved...I mean like...how hard would that be to implement? Just make a save-state for each of the active automations during a save / auto-save.

[ruhrohraggy]

So, the hamster inside my head must have decided to hop back on the wheel again because...I did it...

I actually ***** did it...It's still not totally perfect...but I don't care...

I got it setup where all 6x scanners can pulse now.

Maybe it's because I finally have a solid grasp on how to use memory gates and deal with automation system lag....But...I finally did it.

All 6x scanners will pulse until a signal is received.

When that happens, aside from the main door automation happening,a pair of Buffer gates will hold that signal until the sweeper-doors under the far left scanner can shut again, and then that one scanner will stay on for the duration of the shower.

Once the shower is over, the doors will immediately open, the signal to reset the pulser will hold for 100 seconds, and then trip, resetting the pulser circuit allowing it to run again.

\o/

Now to test it for awhile and see if it's stable before getting too hyped.

Automating the left side was quite hard mentally...Trying to manage incoming / outgoing signals, isolate that one scanner in a way that lets it still act as the reset button while being able to receive external automation, and handling certain circuit default states was challenging...Hopefully this works reliably.

 

[Icywolf]

If you want a manual override I would recommend using a clock sensor - no need for dupe interaction and can be turned on/off in a vacuum state.

[TunderLock]

That's a great point. 

For those who read this far on this thread wondering where the optimal space scanner is. Ruhrohraggy's build was posted in this follow-up thread: