Optimized 6x Pulse Scanning Solar Network

[ruhrohraggy]

Phew, finally, a working version...

This thing is almost totally optimized to save as much power as possible, and gain as much solar light as possible.

The time between pulses has been optimized to minimize power lost. This was done via Power lost from scanners Vs. Time between Pulses vs. Power lost from light if the doors close early before meteors actually hit.

What does this even mean, why bother? We want to pulse as often as we can to give us the smallest margin for error in detection time, and minimize the amount of time the doors close before a meteor shower hits without us blowing up.If we pulse too much though we also waste power.

(see graph for more details)

Spoiler

Heck, even the arrangement of the solar panels themselves is optimized for floor-space vs. solar real-estate.

So how's it work?

This setup pulses all 6 scanners at 100% scan quality for a 1s duration, holds any meteor signal for the bunker doors exactly as long as it needs to with the smallest margin for error possible (in favor of closing a little early), and then opens the doors up immediately when the storm passes. 5 out of 6 dishes disabled during the shower, 1 needs to be active to keep the pulser off, the doors closed and then reset the system when the shower is over.

Oh, and it even cleans the floor once it's done, with as few door cycles as possible.

Warning : This is not a completely stable build! This is a first working prototype.

I still have some small inconsistencies to iron out, so use at your own risk! (If you can manage to work out the timings for yourself :P)

 

Awww yeah, here it is in action...(Game speed is at 10x)

 

Some things I'm working on refining :

1) Allow the left scanner to remain inactive, after a signal has been picked up, until the bunker doors are fully closed, and then re-activate during meteor shower. (Saves more power)

2) De-activate the left scanner as soon as the doors open, and allow it to join the other scanners when they start pulsing again. (saves more power)

3) Iron out any potential errors the system might incur which might include :

- Mis-timed or errant signals resulting from scanners picking up meteors at different times, or buffered signals interfering with automation. Due to some very minor lag (less than a second) in this automation system, sometimes the dishes can output detected signals at slightly different times. The timing on everything is very tight...but the last thing we want is for the bunker doors to randomly open again. I'm ok with sacrificing a little efficiency for extra safety.

- Loading a game where the gates were counting down in the previous save, resulted in the bunker doors not closing on time because the progress of Buffer and Filter gates is reset when loading.(Analog automation will be needed as a backup to hold filter / buffer gate state between saves. Either that, or an emergency override switch setup in base that a dupe can toggle to close the doors immediately which I currently have installed for testing purposes, and it works)

[Saturnus]

I have absolutely no use for such a system in my game but I really enjoy seeing well thought out and executed builds. Kudos.

[ruhrohraggy]

Yeah, it's not super practical...I have a build / guide for a more practical one...but the idea was fun. And I learned some more advanced automation techniques. Cheers for the response.

[TunderLock]

Hey mate, 

Fantastic build! Congratulations on taking a loose idea through to something useful and concrete. I'm surprised how little logic there is controlling the blast doors and scanners, quite elegant. Please do keep us updated as you refine. Two questions and two comments:

Q1. Are your pulses truly only 1 second long, or is that how long the dishes are effective for after the their power-up sequence? Put differently, for how many seconds do the dishes consume power in this build?

Q2. Have you done any math to justify the benefit of not powering the regolith clearing doors? I've always had a single row of powered doors for speed but perhaps 2 rows (or more) of un-powered makes more sense in trading energy cost of the doors vs. sunlight blocked by longer close times. 

C1. You have likely already considered it, but it would also be possible to pulse the left scanner during a shower? It would come at the cost of complexity, and the breaks between pulses couldn't be too long as the cost/benefit profile of saving a single scanner vs. 6 isn't as great. 

C2. I see that a large portion of the logic pertains to the opening and closing of the regolith doors. Below I have an alternate approach you may like.

 

The left side of the OR gate is fed by an infinite loop, running 2 seconds on and 2 seconds off. The output of the OR gate goes to the doors and will always hold them open until you feed the right side with a timed measure of false. For example I feed it with 10 seconds of false to have the doors cycle 5 times. It's short and sweet, and because I don't often look at my solar array, the sound of the infinite loop here doesn't grate on me. 

Great build. Looking forward to your refinements. 

[ruhrohraggy]

Quote

Hey mate, 

Fantastic build! Congratulations on taking a loose idea through to something useful and concrete. I'm surprised how little logic there is controlling the blast doors and scanners, quite elegant. Please do keep us updated as you refine. Two questions and two comments:

Thank you, and to your credit, it was a good idea. I don't think it was all that loose. Seemed pretty straightforward. Can we save power by pulsing? Running the numbers before attempting the build wasn't too bad. But after seeing just how much power you save by pulsing...It just had to be done...

And it wasn't specific enough to limit creativity either. It was just left open with a question.

And yeah, the Memory Gates really made this build work. As soon as I focused on using 1 scanner as the reset button, and learned how to properly make use of the M.Gate, it all came together quite nicely. My very first attempt at running this automation was a laughable mess compared to the current version. And you can see it took awhile...I backed up and abandoned my current playthrough on cycle 119 to start working on this. So about 500 cycles later...

 

Quote

Q1. Are your pulses truly only 1 second long, or is that how long the dishes are effective for after the their power-up sequence? Put differently, for how many seconds do the dishes consume power in this build?

The pulses should be roughly a second long, and the scanner should only consume power for this one second.

From observation, the scanners will pick up a signal as soon as they have power and have a floor underneath them. Their animation for turning on has no bearing on this, and they can start picking up signal before the animation is complete. (You can even see this in the video)

I couldn't find any numbers for exactly how long it takes an un-powered airlock door to close, but through testing, I've found that it's around 3-4 seconds.

We set our buffer gate for 23 seconds, and our filter gate for 5 seconds. The buffer gate controls pulse frequency, and the filter gate controls pulse duration. The pulse duration is : [filter gate time] - [time for airlock doors to close]. So 5 - 4 = 1.

So walking through exactly what happens...

With the current setup, It will be 23 Seconds before the pulse happens and 4 seconds for the doors to close. (27 seconds until Scanner on)

The filter gate holds the close signal for 5 seconds.

The Scanners turn on after the 27th second for 1 second before airlock doors open again, shutting off the scanner once the filter gate lets go of it's signal after 5 seconds.

So the scanners are only physically active for this 1 second. Looking at the in-game power usage confirmed this for me.

 

Quote

Q2. Have you done any math to justify the benefit of not powering the regolith clearing doors? I've always had a single row of powered doors for speed but perhaps 2 rows (or more) of un-powered makes more sense in trading energy cost of the doors vs. sunlight blocked by longer close times. 

I have not, but it's a good point. Cycling the doors 3x times will cost us 24 seconds of light.

It *may* be worthwhile to optimize here, but it would be a minor optimization. That and the regolith will still take some time to fall no matter what, so not all of those 24 seconds are recoverable.

1x row of powered doors, vs. 1x pulse of 4 rows, etc...

It's an entirely new can of worms. I personally won't be bothering with it. If someone else wants to crunch the numbers and give us the result with the automation to go with it, that'd be awesome!

 

Quote

C1. You have likely already considered it, but it would also be possible to pulse the left scanner during a shower? It would come at the cost of complexity, and the breaks between pulses couldn't be too long as the cost/benefit profile of saving a single scanner vs. 6 isn't as great. 

To be honest, I actually haven't. I was happy enough just figuring out I could actually get it to pulse without being on all of the time.

I will at least set it up so the scanner is off until the doors are shut, and off again as soon as they open. This shouldn't be too hard, and should save a good chunk of power.

The main things I don't like about having the master scanner pulse while the bunker doors are closed :

1) Having the master reset signal pulse...or having to buffer this pulsed signal so we don't accidentally open the bunker doors again...

2) We don't know exactly how long meteor showers will last, because it's a randomized range value...so pulsing the 6th dish and having to buffer it's signal would add more RNG to the system.

You would have to buffer the master Scanner's signal, because it's the indicator that the shower is over. As soon as this signal goes from on, to off, the system gets reset. This entire build was based around that mechanic.

It's the one inefficiency we might just have to accept, while at least trying to minimize its' impact as much as possible.

 

Quote

 

C2. I see that a large portion of the logic pertains to the opening and closing of the regolith doors. Below I have an alternate approach you may like.

 

Spoiler

The left side of the OR gate is fed by an infinite loop, running 2 seconds on and 2 seconds off. The output of the OR gate goes to the doors and will always hold them open until you feed the right side with a timed measure of false. For example I feed it with 10 seconds of false to have the doors cycle 5 times. It's short and sweet, and because I don't often look at my solar array, the sound of the infinite loop here doesn't grate on me. 

This is actually pretty interesting. I'm just curious as to whether or not you can make it precise. I get exactly how it works and it seems neat, but even just thinking about it....

I would have to adjust alot of timings to get it working the way I'd want. And what happens if the loops is mid-cycle and I want the doors to either open or close right now. I just can't see it being as precise as the S-R latch, which opens and closes the doors exactly when i want it to every time, while also preventing any further signals from disrupting the doors until the reset signal is sent.

I will definitely build this and see how it interacts before making a final decision.

The only thing I have to worry about with the current system, is any errant reset signals being sent, or any errant input signals sent while the reset is inactive. And that really shouldn't be too hard to troubleshoot.

 

Quote

Great build. Looking forward to your refinements. 

Thank you, I appreciate the time you took to provide an organized response. (It was your idea after all)

Unfortunately it may be awhile before I get to post something new, which is why I at least wanted to post up the working prototype. Got a month of contract work coming up...I'm sure I'll be revisiting this when I get back...Or hopefully, someone else takes the idea and either straight improves upon the concept, or radically alters the concept it to make it even better.

[Colqhoun]

Solution for part 3.2: Errors due to lost state on buffers/filters

Memory toggle saves state across save/load.  Need a 200 second filter with an error of no more than 10 seconds? chain together 20 memory toggles with 10 second filter gates in between each

[Saturnus]

1 hour ago, Colqhoun said:

Solution for part 3.2: Errors due to lost state on buffers/filters

Memory toggle saves state across save/load.  Need a 200 second filter with an error of no more than 10 seconds? chain together 20 memory toggles with 10 second filter gates in between each

Or use an old fashioned water clock timer. Can be made accurate to within +/-1s and to almost any amount of time. And you can string almost any amount of sensors in the one tile gap at the top to get sequential trigger points where only the last sensor opens the doors and resets the clock.

[ruhrohraggy]

On 10/17/2018 at 2:01 AM, Saturnus said:

Or use an old fashioned water clock timer. Can be made accurate to within +/-1s and to almost any amount of time. And you can string almost any amount of sensors in the one tile gap at the top to get sequential trigger points where only the last sensor opens the doors and resets the clock.

Finally back from work, I'll see about integrating this into the master count-down timer for the doors to close, since that's the only one that really matters.

[ruhrohraggy]

Scanners are now what pick up incoming rockets...?!

Sweet! A new use for this idea...

So now we can have our bunker doors open exactly 40s before the rocket gets back AND tie it into our meteor network? Woohoo!

Time to refine this build some more and see if I can tie rocket automation into it reliably.

[ruhrohraggy]

Tied in the waterclock successfully. I intentionally saved during a time where the progress of my filter gate for closing the bunker doors was 1/2 way done, and then reloaded.

Water clock works like a charm. Next step : tie in rocket.

[Sigma Cypher]

Slow down ruhrohraggy - you're making us look bad

I've been thinking of minimizing things topside - no need to span the whole map with bunker doors since you only need 6 scanners so I am drawn to this minimalist design.  Not sure I share your environmental sensitivities regarding power saving but I admire the effort.  Suprised to learn that amount of solar panel overlap is ok.  Good to know!

Regarding the water clock - I'm a fan obviously - but I have the same problem with these as I do with the logic gate control version ... because logic gates control the door!  For example, I close the door between the pump and the reservoir with the rocket input ("go") line.  9 times out of ten (guessing) when I reload I find the door is open even though the rocket is gone and the go line should still be green.

How do you avoid this problem?  Manual control of the water clock mechanical airlock?  Or do I need to think more deeply about what state the buffers and filters will be in on reload and design them to fail safely?  The answer might be on the picture you just posted but I can't make it out.

One last question - the rocket detectors actually work now using the last stable build?  Or are you using experimental test branch?  The only Beta options I see on Steam are NONE, audio_logging_enabled and qol-1 testing.

Thank you for your contributions to the community.

[ruhrohraggy]

37 minutes ago, Sigma Cypher said:

Slow down ruhrohraggy - you're making us look bad

I've been thinking of minimizing things topside - no need to span the whole map with bunker doors since you only need 6 scanners so I am drawn to this minimalist design.  Not sure I share your environmental sensitivities regarding power saving but I admire the effort.  Suprised to learn that amount of solar panel overlap is ok.  Good to know!

Regarding the water clock - I'm a fan obviously - but I have the same problem with these as I do with the logic gate control version ... because logic gates control the door! 

How do you avoid this problem?  Manual control of the water clock mechanical airlock?  Or do I need to think more deeply about what state the buffers and filters will be in on reload and design them to fail safely?  The answer might be on the picture you just posted but I can't make it out.

One last question - the rocket detectors actually work now using the last stable build?  Or are you using experimental test branch?  The only Beta options I see on Steam are NONE, audio_logging_enabled and qol-1 testing.

Thank you for your contributions to the community.

Sorry, not trying to make anyone look bad (I know you're joking, but honestly I also have fun sharing and discussing ideas too!)

You can definitely choose to stay minimal up top. I plan on only having solar panels underneath the scanners, because they generate quite a bit of power, and at only 100kg extra steel per bunker door, I might as well just use bunker doors instead of bunker tiles, power them, and put solar underneath.

This build is also really resource intensive, so should only be a late-game goal, but the payoff is huge. You're using 1/28th the power for 100% network quality.

I avoid water-clock automation problems by not using logic gates to control the waterclock, because logic gates don't work through saves, which is the other reason to use a water-clock...lol.

All of my inputs are from hard output sources. You can't see it in the image above, but the input controlling the water clock is fed by my master scanner's output. There are no buffer, filter or memory gates between it, and the clock.

So in the case of the rocket, your hard automation output source is the rocket. On the stable branch, the rocket output signal turns on when it launches, and stays on until it returns. This is what is used to control the airlock door. You want the door shut when the rocket is away, and open when the rocket gets back.

[ruhrohraggy]

-Edit-

So I've been fiddling around with it for awhile and I've learned that controlling the rocket return trip is impossible for a silo-type setup using scanners.

I cannot think of a way around the dilemma...and there's one big fat obstacle in the way.

Meteor storms. If the pulsed array (or any scanner setup really) is off, or covered by bunker doors due to incoming meteors, then you won't be able to detect incoming rockets.

The reasons for this are :

1) Obviously, the doors are closed, scanners aren't scanning through bunker doors...(Or if they somehow make an exception for detecting rockets, that would be news to me...)

and 2) The best pre-emptive signal time you can get is 200 seconds, and the longest meteor shower lasts 400 seconds...So even if you wanted to just open the doors ANY time a rocket is incoming, it's still impossible, because you'd have to leave scanners exposed to incoming meteors, or you'd leave your silo wide-open, which totally defeats using bunker doors with rockets.

So this means bye bye to any bunker doors covering the rocket silo, because if it happens to land during a meteor storm, the doors will be closed.

So, with no way to prevent the stupid rocket from landing whenever it feels like it...it's completely moot.

I know that you can setup a timer for peace season / meteor season, but I refuse to do the math regarding when to launch the rocket so that it returns during a peace season.

Why Klei even bothered to make scanners detect rockets without giving you control over when they land is beyond me...Hopefully it's an oversight, or a non-priority issue that will get resolved soon.

[N00bieMeap]

I've been try to make a easier one of your but it's not actually easier
and feel bad, i can't make the effect: IF one detected meteor rain THEN that one on AND other off.
can you help me understand it?

The test

[ruhrohraggy]

1 hour ago, N00bieMeap said:

I've been try to make a easier one of your but it's not actually easier
and feel bad, i can't make the effect: IF one detected meteor rain THEN that one on AND other off.
can you help me understand it?

The test

Here's some advice from what I can see in your video.

Red signal is not "off". Red signal is "passive". The best way I can put it, is that a "passive" signal is telling your circuit that no "Active" signal is currently being sent. It's still sending a signal to tell your machine what to do...just not an active one :P.

What this implies is that an active signal will always override a passive signal if they are connected on the same wire...because...well, the signal is no longer passive anymore, it's active.

Put even more simply, if you connect green wire to red wire, they both become green wire.

A machine is "off" when it's input port is "passive", because as soon as you hook it up to an automation wire, it begins obeying your automation. If you have just a wire and nothing else attached to a machine, then the machine will obey the passive signal, and will stay "off".

You must use logic gates to invert active signals into passive signals, or you use logic gate to combine 2 signals into a signal you want. But if an active signal touches your passive signal, it will become active.

However, logic gates can also be used to control "signal flow". Signal will not "flow" backwards through a logic gate, you have an in, and an out in 1 direction. (Assuming you do not put a short in the logic gate)

Controlling the flow of signals is very important for more advanced automation, and it can keep them from interfering with each-other. I have made liberal use of this concept in the scanner automation you see in the picture below.

You have the inputs of your entire solar array hooked up to the outputs of your entire solar array...When 1 is on, they are all on.

Hopefully you now understand :D. And my automation is "simple", about as simple as you can get for this task....you should have seen what it looked like originally, before I worked out how to make better use of the Memory Gate.

Here, I'll do ya one more favor.

Here is the image of the current automation I used in my last play-through. I used debug to clear away some stuff so you could see it more clearly. This is as simple as I have been able to make it...

Try building this for yourself and see how it works. If you need numbers for gates, let me know and I'll make notes on this picture.

The scanners ran flawlessly for 500 cycles. I was very happy.

 

[ruhrohraggy]

And it just dawned on me...

So I'm actually full of crap. You can not only make this system simpler...You can make it more power efficient at the same time.

I only worked with 2 out of the 3 main possible avenues for automation...derp.

Mechanical Automation : Check.

Digital Automation : Check.

Power automation? : *Buzzer*

So, if we power all of the 6x Scanners on the same wire...and automate a power shutoff, we kill 2 birds with one stone.

Automation is now even more simple. AND, the master scanner will now pulse no matter what, even during the meteor shower. The buffer on the right inside the yellow box is set to 200 seconds...So the active pulsing scanner on the left has time to pick up the meteors before they hit and begin buffering...

The filter gate leading into the Memory gate is set at 171 seconds, which gives us a bit more safety in terms of automation lag.

Every time the master scanner picks up a signal during the shower, the 44 second buffer on the left holds onto it. Since my calculated ideal pulse time is 28 seconds, it has 16 seconds of leeway each time it picks up the signal after pulsing which is 15 seconds more than enough. The doors only open when the signal goes from Active -> Passive.

So I had to make some minor tweaks to account for the 28 seconds of possible error on the back end. The doors will open somewhere between 100-128 seconds after the last meteor shower...but...whatever.

I've already tested it...it works. Such gross. Much power savings.

 

[N00bieMeap]

last question... how do you actually send the signal to that lefty scanner that quick, mine detected rain -> on - off for some time -> bunker door open and close -> such power wasted. here it is:
The Test

sorry i was offline testing so i didn't build your system
p/s: can you a minimize the words abit? I'm lazy and not really good in English : p but i'll try to read

 

[ruhrohraggy]

15 minutes ago, N00bieMeap said:

last question... how do you actually send the signal to that lefty scanner that quick, mine detected rain -> on - off for some time -> bunker door open and close -> such power wasted. here it is:
The Test

sorry i was offline testing so i didn't build your system
p/s: can you a minimize the words abit? I'm lazy and not really good in English : p but i'll try to read

 

I can try to use more basic words and keep the sentences shorter, yeah. Sorry. I could tell you were non-native english...I tried , it's not easy [for me] to explain.

All scanners are on same network, all pick up meteor signal at same time. Right 5 scanners pick up signal then shut off. Signal is held by buffer gate in case left scanner missed signal due to lag. Buffer gate says : "If receiving active output signal and signal becomes "passive", continue active signal for some time, then "passive".

Try new system. It's much easier. I will update the thread and post a video.

[karyuendan08]

can you post the "full grid" please?

[Angpaur]

Here is my pulsing scanner automation setup:

Spoiler

It seems to be simplier, also to understand

What this setup achieves is low power consumption of scanners (it can vary depending on meteor rain frequency, the lowest during one cycle I saw was 51kJ). It closes bunker doors 1-8 seconds before meteors hit. When incoming signal is detected only the main scanner keeps pulsing, other 5 scanners power is disabled. When meteor rain stops other 5 scanners are not powered for another 99 seconds. 

[ruhrohraggy]

4 hours ago, Angpaur said:

Here is my pulsing scanner automation setup:

It seems to be simplier, also to understand

What this setup achieves is low power consumption of scanners (it can vary depending on meteor rain frequency, the lowest during one cycle I saw was 51kJ). It closes bunker doors 1-8 seconds before meteors hit. When incoming signal is detected only the main scanner keeps pulsing, other 5 scanners power is disabled. When meteor rain stops other 5 scanners are not powered for another 99 seconds. 

Did you see a few posts up? I have a more refined version now :P.

But people might not like the powerless automated airlock doors...And that's fine.

I had some random tired crap-spewing in here, but I said screw it.

Here is full autism mode engaged with a few cups of coffee. I've gone through my spreadsheet with a fine tooth comb. Make fun of me if you want, but it should be quite accurate.

Ignore the part in the center above the graphs, I'm still working through that. It's going to be designed to give you the minimum # of solar panels needed to operate # of bunker doors through an average 10 cycle meteor season. It will also compare continuous scanners, vs. pulsed scanners.

 

Spoiler

 

Naturally, your 8 second pulse time matches my re-worked data set for 18 Solar Panels. So that's good. I was off, more due to my solar panel #selection, and not the data... but now its fixed, I'll update it to match this system exactly :))

My initial 28 seconds of pulse was part of a different train of thought. But me, being me...forgot about it, and put some misinformation in the post instead of reviewing and updating like I should have. (For shame)

But I still want to know...how few solar panels can I use to power the bunker doors above the scanners. Because the whole point of pulsing is to save power...Is it even worthwhile to do so? (Probably not, solar panels are cheap, but hey...)

 

Also, It's Cool to see you got a working version without automated airlock doors.

5 hours ago, karyuendan08 said:

can you post the "full grid" please?

For spacing purposes? I could do that yeah...You can also use the solar panels to count tiles. The 2 together are 14 tiles long, and then there's a 2 tiles gap where the scanners sit above them, ~ 15 tiles or so above them.

or I can just give the save file...Here : Boatmurdered.sav

I'll get around to updating the thread when I'm less tired...

[Angpaur]

14 hours ago, ruhrohraggy said:

Did you see a few posts up? I have a more refined version now :P.

Yeah. This was a reason I posted mine, because it seems to me to be a bit simplier.